Tips for an Information Security Analyst/Pentester career - Ep. 51: Meterpreter detection
So far I've enjoyed playing on the offensive end, by exploiting my VMs through Meterpreter payloads and taking control of them.
My ultimate goal is to be a white hat hacker/red teamer.
However, I've been an analyst, too, and you can't be that good as a hacker/pentester/red teamer if you don't understand how to defend against Meterpreter and if you don't know what such an exploit looks like on the victim machine.
You can learn how to get stealthier with your attacks.
Likewise, you can't be a good analyst/defender/blue teamer if you don't understand what type of artifacts, signatures, patterns or logs you should keep an eye on.
This is a short introduction. I intend to go way deeper into the rabbit hole, leveraging my forensic studies, if I can.
Scenario: Windows 7 VM exploitation through msfvenom and a reverse shell payload
Attack
I performed a usual exploitation against my Windows 7 machine and I could pop a shell and obtain a privilege escalation.
Then I migrated to a system process.
What it looks like on the victim machine
On the other end, nothing suspicious pops up.
However, if we run netstat -abno command and redirect it to a text file (much easier to read it this way), we notice a process listening on port 4444 TCP on our Kali machine (notice its IP address).
Its PID doesn't look suspicious, but the port number raises a red flag already, because it's the default port used by Meterpreter.
Its name looks suspicious as well, even though it results to be a signed Apache bench file.
Check out the embedded video for more details and a way deeper analysis.
Other processes associated to Kali are also listening on port 443.
One of those is Microsoft Security Essentials, which makes sense because I had migrated to that specific process.
The security log shows Ms Security Essentials was, in fact, stopped.
I re-exploited the machine by using the same msfvenom payload but this time I didn't migrate to another process, I was a sloppy attacker.
After re-running netstat -abno, we can now notice an executable called intruder(2).exe, our custom payload.
You'll notice Kali IP address changed; I had some connectivity problems with my Kali VM that, in the end, led to this.
The executable was still running, as a result of my previous attack, before I lost connectivity with my Kali VM (which ended up switching IP addresses from 192.168.1.78 to 192.168.1.64).
That's a no-no, as an attacker.
You'll also notice another red flag.
Processes such as svchost.exe and wininit.exe, which should belong to NT AUTHORITY/SYSTEM, return an error message (can not obtain ownership information).
I think this is due to the privilege escalation we performed.
I migrated to a new process and re-ran the netstat -abno command.
Now you'll only notice svchost.exe listening on port 4444 TCP.
I ran a Virustotal scan against svchost.exe, where I had injected my executable in, and no malware was detected.
This time around, Antimeter found my Meterpreter payload running in memory (I should have killed it from Kali) and stopped it.
When it did so, my session died immediately.
More considerations
In addition to the above considerations, an analyst should monitor the client for processes that shouldn't be there in the first place, or don't make any sense for the specific client configuration.
Why should a standard user run Powershell, for example?
Or, why should a computer not belonging to an administrator run Windows Remote Management?
Windows Remote Management can be leveraged for a specific Meterpreter attack, as explained in this TrustedSec blog post.
I'm gonna delve more into that by analyzing how to monitor network traffic with Powershell and, if I can, how to decrypt the SSL traffic generated by Meterpreter in order to look into it and check that traffic against some custom signatures.
I'm also going to check for a Meterpreter shell with Snort rules.
Comments
Post a Comment