When dealing with a small network, it is easy to underestimate the time and effort it can take to clean up your compromised hosts. This task is critical in both avoiding detection and leaving the network in pristine condition once your testing has been completed. The last thing anyone wants is to overlook a compromised host that has a meterpreter backdoor installed and waiting for the next person to come along and take advantage of it! The key is to take meticulous notes and keep accurate records not only of what was done while testing, but also if the things that were done could possibly persist after testing.
If you have not scripted the full exploitation and post-exploitation process, then make sure you are keeping a checklist for all actions that must be undone. This is above and beyond creating notes and logging commands for your final report. We are talking about the guide that will be used to ensure that nothing is left to chance and all changes are reversed properly—something as small as adding a temporary file to a world writable directory so that you could test your blind SQL injection. If you cannot remove the file yourself, have something ready for the administrator to remind them to remove the files for you. The job of a penetration tester is to assist in verifying the security of an environment, not to make it more vulnerable.
It is never too early to begin the cleanup process. Not only will this assist in remaining undetected, but it also ensures that a systematic approach is used throughout the entire penetration test.
There is no need to have 300 open shells to the same subnet. Pick a target that allows you to set up a proper pivot, and then remove the other shells from your list. The fewer machines you have to touch, the easier the cleanup will be. You will need additional time for reporting and verifying results anyhow!
It is critical to have a good understanding of where the log files are stored, what they capture, and how they report the data back to the administrator. Take the time to learn about the various log files for at least the most widely used operating systems such as popular Linux distributions and Windows Servers. If attempting to avoid detection, simply erasing the logs will probably not help achieve the desired result. It would be akin to taking someone's ice cream cone, eating the ice cream and returning the cone back to the freezer. Someone is going to notice. Instead use techniques that allow you to edit portions of the log files or escalate privilege to an account that is not monitored. Many of the tasks needed to enumerate an internal network do not require administrative privileges; maybe it would be better to use a restricted account for those activities in the hope that only admin actions are being logged and monitored?
Administrators that actually review logs are not going to look for the standard traffic. They will be looking for anomalies. In order to avoid detection, your traffic and actions must be able to merge with those of an average user.