14 11 2012
APTish Attack via Metasploit – Part One of Four
I was reading one of Mandiant’s M-Trends  papers on Advanced Persistent Threats (APT) the other day and decided I wanted to try and duplicate some of the methods outlined in their exploitation cycle discussed in the paper.
They outlined the exploitation cycle as such; Recon -> Initial Intrusion -> Establish a backdoor -> Obtain user credntials -> Install utilities -> Privilege Escalation, Lateral Movements and Data Exfiltration -> Maintain Persistence
I say, APT “ish” because I don’t find this method to be advanced. It also does not use any stealthy/sophisticated malware like we have seen in some high profile APT style attacks. It does; however, cover all the high points outlined in their exploitation cycle. So “ish” it is.
WHY AM I DOING THIS?:
I am currently looking to break into the digital forensics field so I am more interested in the forensic artifacts this type of an attack leaves behind. I will have three more followup posts dealing with the artifacts. Memory, HDD, and Event Logs via Splunk. I figure I needed to create these artifacts first and since I am not personally getting hacked on any given day I needed to do it myself inside a lab environment. This is why I decided to create this “hacking” post first.
You should be able to duplicate this in your own lab. Feel free to shoot me an email or leave a comment if you have any questions trying to get things setup.
I will point out one thing. Now that we have set specific names for the script it’s quite possible that detection methods can be built more easily. You could always modify the variable names before you set persistence in another box though. Maybe this would fool the DFIR folks and “rely” on their detection scripts setting the names to “svchost” or something. That way they would ignore all the other names. Who knows….I’m not a pentester.
I guess there is always a trade off.
A lot of the APT attacks I read about started with some form of Social Engineering. It seems logical that we would select that as our attack vector.
I decided to simply use Create a Payload and Listener so I can host it on the webserver we started above.
We need to set our IP here for the reverse connection. This will tell the victim to connect back to this IP. This is the IP address of the attacking machine (Backtrack).
Here we will select HTTPS as the comms method. A lot of attacks these days use HTTP, HTTPS, and DNS. The days of IRC seem to be coming to an end. It’s too easy to detect those communication methods.
Here we will select the payload that we will use to do the infection. Again, I wanted something that was going to be effective and simple to exploit.
We also set the listener to 443, which was the default anyway based on previous selections we made.
I forgot to highlight the text but if you look at the text in the picture you can see where it says, “Your payload is now in the root directory of SET as msf.exe”. This is where our malicious file is located. This is the one we will use to compromise the machine with.
Also, you can also see at the bottom it’s asking whether or not we want to start the listener.
Now we want to move the msf.exe file that’s created in the step above and move it into the root of our website. I also wanted to rename it. In this case I used AntiVirus_Update_2012.exe. You can name it to whatever you want. I figure this looks harmless enough.
The little icon on the bottom right is what it looked like on the desktop of the victim’s machine. I didn’t feel it deserved a separate image so I wanted to combine them here so you would see what the victim would potentially see assuming they didn’t just run it from within the browser vs. downloading it to their desktop. Since the tech support staff always says, “Right-Click -> Download to Desktop” I figured this user was trained to do the same thing.
As I mentioned up above I have a Splunk Storm account that I use when doing this kind of testing. These services are really nice to get good log data from. Best of all they are free. It’s hard to follow data in your environment when you have thousands of logs flooding into you logging server. This allows you to have one single controlled data set that you can go back over and look for indicators of compromise (IOCs). Then you can use that information for tuning your tools.
Here is when we wait for the victim to click on the link and install the malicious file. As you can see he/she did and now we have a meterpreter session that we can use and start our attack.
I also ran, sysinfo to see what system we are playing with. In this case it’s a Windows 7 machine running SP1.
The goal is to get SYSTEM level access so we can do as we please with the system. One way to do this within metasploit is by using the getsystem command. Once we gain access we want to move to establishing persistence.
OH NO…. THE USER REBOOTED:
One problem…. We no longer have system access.
Let’s run the bypassuac and see if it works. According to the metasploit site, “This module will bypass Windows UAC by utilizing the trusted publisher certificate through process injection. It will spawn a second shell that has the UAC flag turned off.”
So now let’s see if we start using Session 2. Yes. It works. Now we attempt to gain SYSTEM access again by using getsyste,. This time it works and now we can start moving towards exfiltrating our data.
Now it’s time to search for information and start our exfil.
It’s common for attackers to use some kind of compression technology to compress data prior to ex-filtration. In this case we will use the command line version of 7zip. It’s very likely that true APT or any attacker for that matter would use either customized tools, or modified standard tools so DFIR folks can’t do simple searches for, “7za.exe”.
The object is to not get caught, and it would be pretty easy to search for these tools if they didn’t attempt to hide them. In our case we will use standard naming conventions only to illustrate how you can find them, and what forensic artifacts they leave behind.
You read a lot these days about dumping hashes and then using those hashes to “pass-the-hash”. Let’s dump them.
I’m only using one victim box for this example due to time constraints, so I wont be passing any hashes. Maybe another time.
As you can see we have Administrator, Guest, and malware_win7x86 along with their hashes. I took one of the hashes online and it was cracked almost instantly. I just had a simple password configured since it’s internal to my lab. This would be another step you could take to figure out what the cleartext password would be. That way you might be able to authenticate to Webmail or any other external services that a company might host. Even personal accounts as we know people tend to reuse passwords.
Remember how we uploaded 7za.exe into the System32 folder. We are simply running that command after dropping into a shell from within meterpreter.
Once we have the files zipped up I downloaded them to a container I had already setup on the desktop of my Backtrack machine. This could also be a staging server someplace else inside, or outside the compromised network. I don’t have any encryption or anything. Sophisticated attacks more than likely will have some for of it.
And now for the money…. Here I am back on my Backtrack machine listing out the folder I created called apt-collection. You can see here there is a file called, apt.7z. Now I simply issue the unzip command (7z e filename) and it processes our files. They are listed in yellow. I also ran cat against the SSN_and_CC_Data.txt file and as you can see we got some good information.
We got a Name, Social Security Number (SSN), and also what appears to be a credit card number. This is all good information.
Now that we got the information we wanted we will consider this attack complete. APT tends to hide out and laterally move throughout the network. We will just assume they didn’t in this case.
We will assume that the security team onsite “identified” something was wrong, and moved in to secure the machine and perform forensics on it before I (the attacker) was able to clean up after myself.
We successfully ex-filtrated some good information from the victim machine. Not bad for a few hours of work, eh?
I used FTK Imager to image the HDD. I sent it to a USB drive that I mounted within the victim VMWare machine. We will be using this to analyze the harddisk.
As you can see here the logging tool I used sent 10,091 logs to Splunk Storm. I will also be taking a look at these. Unfortunately I don’t have any network data from firewalls or network IDS. In either case, I hope to share some of the searches that I use to spot malicious activity via Splunk.
I hope to get the forensics portion done in the next few days. I will break it up into three more posts. The three parts will be Memory, HDD, and Splunk (I’m not sure what order yet). Each will have their own blog post.