In Part 1, I introduced some sound methodology for approaching remote enumeration, which I now realize needs a bit of revision. It’s not that it’s a bad approach, it’s just too aggressive and would potentially miss certain aspects of the target that may prove useful or time-saving.
Act like a user, not a hacker
The first thing I’ve learned is that it’s best to act like a user, not an attacker. Not only is this much less noisy, it’ll allow you to see the target from a user’s perspective, and may reveal information that you’d otherwise miss.
Rather than plowing head first into a nikto scan, a bunch of NSE scripts, various SMB/NBT scans, etc., take the time to connect to the listening services and applications the same way an end-user would. Something listening on port 22/TCP? Try to ssh to it, see what happens. If it’s something you don’t expect, try nc -nv to see if you can suss out what’s really going on with that port.
By interacting with services the way a normal user would, you’ll get a sense of what to expect, and what the listening service expects. You’ll save yourself a lot of time by ensuring you don’t overlook simple things and wind up running down a rabbit hole for hours.
Don’t go whole hog on scans
I know I recommended a light scan in Part 1, but even that was a bit too much. Something as simple as
nmap <IP> --top-ports 10 --open
is enough to get started on a target. Let a more thorough scan run while you begin initial research on the truly low-hanging fruit.
Try defaults!
If you’re starting to sense a theme here, you’re right: try the easy stuff first. Many people like to bring nuclear warheads to situations where a tackhammer will suffice. When trying to find an initial vector, try typical or expected defaults. Try empty passwords. Try vendor-assigned default credentials. You’d be surprised how far you get.
Collect everything salient, and save it
Whenever you come across a username, password, machine name, company name, individual’s name, interesting terms (cewl, anyone?), save it to a list. Save it to a few of them, in fact. Having custom-tailored username and password lists for lightning-quick brute force attempts will only save you work in the long run.
That’s not meant to suggest you should try brute-forcing everything. Quite the opposite. But if you’re in posession of information you know is relevant in that environment, make use of it.
Don’t overlook the obvious
There is all sorts of information sitting in plain view, if only you have eyes to see. Images have exif data. Binary formats can sometimes have extra information appended to them without affecting the proper functioning of the data. File sizes can be indicative of interestingness. Look at permissions. Look at file locations. Look at the user a service is running as. Look at everything, and then ask yourself, “What’s out of place here? What sticks out?” This is your chance to play Sherlock Holmes, and use the facts in plain view to crack the case.