14 11 2012

I was reading one of Mandiant’s M-Trends [1] 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.

VMWare LAB:

 

Attack Machine: Backtrack 5 R3

Victim Machine: Windows 7
Splunk Storm

METHOD:

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.

MODIFYING A BIT OF CODE FIRST:

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.

HTTP SERVER:

 

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.CONFIGURE 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 AntiVirus_Update_2012.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.

SOCIAL ENGINEERING:

 

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.

GETTING PWNED:

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.

OH NO…. THE USER REBOOTED:

 

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.

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?

This is just a picture showing that we have memory dumps. In this case I took two. One right when I did the compromise, and one right after I did all the exfil. I’ll be using only the one that I took after the exfil to make it a bit more realistic. In this case I will be using Snapshot6.vmem.

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.

Part II
Part III
Part IV

Tweet

Reference
[1] http://www.princeton.edu/~yctwo/files/readings/M-Trends.pdf

Advanced Persistence Threat, Exfiltration, Metasploit Artifacts, persistence.rb, SET, Social Engineering Toolkit, SplunkStorm

DFIR with NBDServer APTish Attack via Metasploit – Part Two – Splunk