Enumeration is cyclical

Many say it – methodology is important–if not critical! In this post I’ll quickly cover the hacking phases but what’s more paramount to success is being cyclical in your process.

What the typical hacking methodology looks like:

1. Recon
2. Enumeration and Scanning
3. Exploitation (Foothold then Privilege Escalation)
4. Persistence
5. Covering Tracks
6. Lateral Movement

This is a great way to map out the phases of an attack going all the way from information gathering to actually engaging with a target and all that comes afterwards. What this doesn’t show is the fact that steps 1 and 2 repeat over and over.

In my opinion this is what actually takes place:

1. Recon
2. Enumeration and Scanning
3. Foothold
4. Enumeration
5. Privilege Escalation
6. Persistence
7. Enumeration (looking for events created based on system interactions)
8. Covering Tracks
9. Enumeration (looking for the next target)
10. Lateral Movement

Rinse and repeat.

There have been instances where I would have benefited from thinking explicitly using the second list versus the first one. Yes, the first list of the hacking phases implies the additions but this is something to take into account. When engaging a system, actively think, “I need to be cyclical and double back for new information and avenues I didn’t have before.”

As an example, you engage a Linux server that is running a vulnerable web application. There are two particular CVEs for this. The first takes advantage of a weakness and changes the password for a given user to a string of your choosing. The second requires authentication to the application, building on the first vulnerability, and allows the attacker to have remote code execution. This seems like an easy win, right? Not so fast…

When engaging with THIS particular box, I got a reverse shell back as the www-data user. Nice, we got a shell and foothold on the victim machine. Obviously, I opted to use the exploit chaining the two vulnerabilities together. What I didn’t take into account was that the intended path required a different approach. After the first vulnerability what was gained? The admin password was essentially reset giving administrator access to the application. Yes, I did perform enumeration which led me to the right path once on the system but I could have saved a lot of time.

From browsing the files on the system, I figured out the intended low privilege user which I should gain access to – but how? Admin access to the web application allowed me to do further enumeration which led to SSH credentials for the intended user. The rest was cake after that – a sudo related privilege escalation vector and root was all mine!

The lesson here is to enumerate but as your access grows, don’t move too fast and miss what’s directly in front of you–enumerate again. This ties back to my previous post – start simple not complex.