I was reading one of Mandiant's M-Trends 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.
They outlined the exploitation cycle as such; Recon > Initial Intrusion > Establish a backdoor > Obtain user credentials > 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/techniques 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.
Spear Phishing. I will use a security testing gmail account that I use for these kinds of things via my Backtrack box to craft and email to my victim user. I'll redirect the victim to a webserver that I will be hosting on Backtrack. Nothing special, just a simple Apache configuration with an malicious exe in the root. Maybe a bit far fetched, but then again we all know what users are like. The idea is that the victim downloads the infected file, runs it, and gets compromised. We will attempt to get SYSTEM level access, and then I will move to setup persistence and then move to exfiltrate data.
Modifing a bit of code
Before I got started I knew that I wanted to build some persistence into this attack. I started looking around at the persistence.rb script and then I decided to edit a bit of the code to make the persistence mechanisms a bit harder to spot. Typically the Ruby script will assign a random set of 8 characters in the Windows\Run registry key. It will also drop a randomly generated 8 character name in for the .vbs script it drops in the the \AppData\Local\Temp directory. I also wanted to edit this so it didn't stick out as much.You can find the script inside here: /pentest/exploits/framework/scripts/meterpreter
The first one is the temp directory that's created after running the persistence script against a compromised box. What I didn't like here was that fact that it creates a random generated 8 character name for the VB script. Any halfway decent DFIR person is going to spot that immediately.
Since I didn't care for the random name I decided to go ahead and make a simple modification. I was tired while working on this so I couldn't think of anything except, scvhost. So when it's created it will be scvhost.vbs. It's far from fool proof and not much better than the auto generated name. A better one could be determined with a bit more thought.
Likewise here. When the persistence script is run it sets a reg key in the CurrentVersion\Run key. It's also auto generated. Again, if you're pulling Run keys and looking at them an auto generated name would be spotted immediately.
As you can see I changed the variable name "nam" to WindowsAudio. I have no idea what made me think of this name, and again, i'm sure with a bit of through you can come up with a better one.So it will be HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WindowsAudio vs. Run\fsdajsadjf or whatever it would have been.
So now that we are a bit more "stealthy" let's move to actually compromise the system.
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.
We are going to make this pretty easy and first setup a webserver via apache on the Backtrack system. Backtrack makes this very easy with all the preinstalled programs that come bundled with it.Simply run the following command:
Navigate to your ip address via Firefox on your Backtrack machine and ensure it works. You should land on a page that says, "It Works!". Once you have that setup you're ready to start setting up SET.
Social Engineering Toolkit (SET)
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 AntiVirusUpdate2012.exe. You can name it to whatever you want. I figure this looks harmless enough.
Once the exe has been moved to the webserver I started the listener. You can start it whenever.Wait a few seconds and you will see a bunch of text spit out. It should say, "[*] Starting the payload handler...". Once you see that you can email the website to your victim. You're up and listening at this stage.
I wanted to deliver this attack via email because a lot of attacks are sent to their victims this way. It only makes sense that we also do it this way. It would be been more realistic if this was a PDF or Java exploit, but in our case I backdoored an exe file. I knew this would work and didn't have a lot of time to mess with matching up versions of Adobe and Java software, etc.Once that was complete I simply sent the email via Google to the target mailbox.
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.
We will use the, run persistence script that we modified earlier.The arguments that are used in conjunction with this command are as follows: -U is to execute upon user logon. The -i is for interval at which it will attempt to connect back to the attackers machine. This is set for 30 seconds. This is a bit quick, and I wouldn't think an attacker is going to set this interval. Every thirty seconds would create quite a bit of network traffic. Maybe it's more realistic for it to be once a day, maybe during busy time periods like the morning when everyone gets to work and they are all logging into their systems. The reason I bring this up is because we initiate the connection upon user login. The -p is the port. and the -r is the system for the victim to connect back to. This is the ip of my attacker system.
Note You can see our efforts from editing the persistence.rb code. You see the scvhost.vbs and the WindowsAudio run keys. Much stealthier than a random 8 character name like hjfkfusn.vbs. Again, much easier to write some rules to search across a network for potential compromise though. There are always trade offs.Notice that it creates a cleanup command for you so you can remove this for whatever reason. It's not good to leave these open when you're doing a pentest for someone. It's also good to remove it if you're attempting to cover your tracks a bit.
So here I wanted to demonstrate that the user rebooted their computer and we lost connection.What can we do now? Well, we can leverage the persistence mechanism we setup before. Let's setup our listener again.
When they log into their system it executes the script, and then attempts to connect back to us every 30 seconds until to does. Here we can see that it was successful in reaching the attack system and now we have another session to interact with.
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.
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.
So here we are going to zip up the files we found on the system. Unfortunately I forgot to take one more snapshot here and I didn't realize it until afterwards. I used the "search" command that's built into meterpreter to find key words. I knew what key words I wanted to search for because I created the files. This isn't uncommon for APT to do. They typically know what they want. Whether it's "Engine Specifications", "Military lingo", "Classification information", etc. In our case I looked for, SSN, Classified., *Financials., and *Secret.*. I got the following hits.