Meta

Category: Offensive

I’m taking a break from the Bears writeup to look at the swiss army knife payload generator and obfuscation tool Veil-Evasion. For those not familiar, it is a fairly foolproof way to get your payloads around client side AV. Most AV products suck, but they are still good enough to catch any default payloads from metasploit. The goal of veil is to give you similar tools to what the guys out there doing this for a living actually have. Major props to @harmj0y and the crew behind Veil. Today I am going to generate a payload, run it, migrate to hide it, and then see what things look like from the endpoint. There are LOTS of cool payloads so I recommend checking it out.

For this initial go around I will use a meterpreter rev_https shell which is a tried and true way to get around most firewalls. Since I am going to do a rev_https shell, it makes sense that I set my listener to 443. At a casual glance IR/CIRT might assume that it is https traffic to a local web server. Enter your LHOST and LPORT, then simply type “generate” to run and compile the C# code. As the splash mentions, don’t be an ass and submit the code to VirusTotal or malwr.

Let’s take a look at the source code before we run the exe on a Win10 box. I won’t dig into the details of the loops since we already know this is a reverse shell which is going to beacon out. Looking at the random strings and methods of building arrays should look fairly familiar if you have spent any time looking at VBS macro droppers which are automated in a similar fashion. We can see the Crypto libraries for the encrypted SSL comms, we can see the faked user agent strings, and that the C2 is actually going to be passed from the attack box to the victim in the URI.

On a typical engagement this would likely be an innocuous sounding domain name pointing to your handler running in AWS or similar. Would you immediately be suspicious of a domain like this in your traffic?

This is why it is so damn hard to be on the defensive side. Your best bet is defending the endpoints since network traffic is a guessing game even if you are in an environment that can stomach domain white listing.

Anyhow, here is the code generated for the reverse shell by Veil-Evasion.

Now let's get the exe onto the victim box and run it. First we setup our metasploit handler which veil has been nice enough to give us a handler file for ( /var/lib/veil-evasion/output/handlers/service_handler.rc). This handy file makes it a one shot deal to get your payload handler running. Once in msfconsole simply type "resource" and then the path to your .rc file.

I am glossing over the initial compromise method since that isn't the focus of this briefing. Let's say we social engineer someone into believing they need to patch their system, and include a link to download the patch.

On the attacker box I see a session being started when the Windows 10 box runs the service.exe. To make things more "difficult" for the defensive side I first interact with the session, then I am going to list processes and migrate to one so that the initial service.exe can get killed and I can live on in process injection.

If you are new to metasploit the following commands inside msfconsole list sessions, interact with one, find processes, then migrate.

sessions -l
sessions -i session#
ps
migrate pid#

Since I am masquerading C2 traffic as https traffic it makes sense that I would migrate to something like a browser. Here is a shot of a successful migration to the venerable IE.

On the host box I fire up process hacker like a dutiful sys admin might if he suspected something was suspicious. There is no longer a suspicious "service.exe" and the network connections reveal Internet Explorer talking with websites over the normal 80 and 443. You can obviously pick out the "bad" connection since you know for this demo that I am a local attacker, but if you replaced my local Kali handler with one and AWS and a public IP good luck spotting that. Of course I am eventually going to want to elevate myself as system and migrate to somewhere else for persistence since in my current state if the user kills internet explorer my shell dies with it. For the sake of making this a bit more challenging I will leave my shell inside internet explorer.

Using Process Hacker and looking at strings in memory I can make out the various URI's corresponding to Bing, yahoo, and anything else I have open. Mixed in there is the IP address of the attack box, but if that was an address like https://amazon.cdnnetwork.com I would naturally just assume that my browser was pulling down ads on one of the homepages. Defensive Group Policy like Applocker and changing scripts to open with notepad.exe are a million times more effective than AV or IOC based detection on network traffic. Whitelisting can be bypassed via injection, but for most circumstances if you can stop that js/hta/vbs/exe/com from running in a temp directory you will force the attacker down a much harder avenue. It is a war of attrition. For an added bonus, Applocker is built into Windows so you don't have to blow more money in your company. Looking at the traffic in Wireshark confirms that all the communications are TLS encrypted so unless you have MITM functionality on network traffic you aren't going to have squat.

HOWEVER, if you migrate your meterpreter session into iexplore.exe you find yourself in a sandbox which you weren't in initially. So in theory an attacker could most likely stay in your browser and easily blend in, but in practice an attacker is going to want to be injected into a process operating with elevated privileges and one that doesn't get killed in the event that a user closes the browser. Here is a screenshot showing that while injected into the browser I couldn't view system process and I eventually I got my shell killed when the browser was closed by the user.

Now lets redo the infection and see what things look like if I go the most likely route that an attacker would take. Exiting out of meterpreter I can see that my handler is still running on 443 so there is no reason to re-launch it.

Relaunching the "service.exe" malware from the browser and pulling up Process Hacker shows that this should clearly alarm you due to the location that it is running out of. I can't stress enough that if you want to make life hard for the APT's, ransomware pushers, and pen testers remove the ability for an executable to run out of any TEMP paths like C:\TEMP (older) or the %APPDDATA% (newer) path via Applocker policy.

Now I migrate over to svchost.exe and you can see in process hacker that the connection is coming through the process which I injected into. Process Injection isn't just done by malware, and nothing yells out and alerts you even on Windows10 that a random executable in APPDATA just injected into an application signed by Microsoft.

If you go look at the memory of the svchost.exe which has injection going through it versus your average svchost.exe you do notice that there is a LOT more going on, particulary with crypto libraries being loaded. You can also see some unique strings which indicate what is going on to the trained eye, but only if you are already looking for this.

Let's take a look at what sort of artifacts are created when this process migration goes through. I am going to use SysInternals ProcMon to watch the migration as inject my shell from it's original dropper "service.exe" into the legitimate notepad.exe. I chose this over the previous migrations because these two processes should have less noise. service.exe is all bad, and notepad.exe is simple and should have no network functionality. If I watched the migration to iexplore.exe there would be substantial noise since many of the connectivity modules and hooks would be present under legitimate circumstances as well.

Filtering off of notepad.exe and service.exe, then viewing Network Summary (Under Tools Dropdown) I can clearly see when the hand off has completed.

Actually looking at the events that have been created from this migration are a little more opaque, but you can see the threads being killed inside service and corresponding ones being opened up in notepad.

Stepping back in time, let me look at the Stack before migration.

And now after the trace is complete during the injection we look at the stack.

Running PS to list the processes inside the session shows what that Query looks like, as you would expect it finds all the running processes. The IRP_MJ_QUERY_INFORMATION is a request by the IO/Manager which does exactly what we would expect, it queries the file system for information on files. Pretty cool to be seeing this level of granularity on a command.

Now I migrate my shell into notepad.exe and look at Procmon for what appears to be the first event of the migration, a Thread Create inside notepad followed with a bunch of Thread's being terminated inside the malicious service.exe. Looking at that thread even show's the stack now contains a number of modules only referenced by the memory address and not a known DLL or program.

As we follow along the event timeline and check the stack for service.exe and notepad.exe we can see the migration occurring. Do to the overload of information that Procmon provides thousands of events occur in between. Once you see service.exe no longer in the timeline and you check on notepad you can see the modules running in the stack include the system and communication drivers you would expect of a backdoor shell.

In summation I want to drive home the following.

You should run AV at home and in your Enterprise, but it should not be considered your "endpoint security solution." AV is fairly easy to get around using tools like Veil or custom packers.

Monitoring network traffic is good, particularly for Data Loss Prevention (DLP). It is not good for spotting malicious traffic however since nearly all bad guys are using https which you will never be able to block at the firewall. Domain whitelisting is great, but C2 can still be delivered via googledocs, twitter, instagram, etc, so you have to REALLY be ready to lock down the network and let the users complain.

Process Injection works and it isn't going away. The one choke point you really have as a defender is to block that moment when the user clicks to run the .hta, js, macro, com, scr, exe, ws, ps1, etc. Your best bet is to not allow regular users to ever run scripts or executable's in temp paths via GroupPolicy. Lots of organizations lock it down so you need an admin to install software, but this does nothing to stop a user from running random code out of %APPDATA%. In the end statistics don't lie and that is where malware drops and often times lives out it's entire life.

This was a bit surprising. Not cause of the vulnerability, but because it was making the news since it was actually really old information. The vulnerability in the JetDirect protocol (port 9100) used by HP Printers has been known for years. I first learned about it in 2012 from a team member on a Red Cell, no idea how long he had known about it. Here is an article explaining it in 2013. https://www.nowsecure.com/blog/2013/01/14/exploiting-printers-via-jetdirect-vulnerabilities/

Not ragging on the guy that reported it, but all of his headline making security news articles have been nothing more than searching Shodan results for already known issues.

The vulnerability is semi useful on internal networks for hosting malicious files (sometimes code coming from an internal IP is trusted or evades CIRT scrutiny). In theory this makes them the ideal place for miscreants to host malware since http(s) traffic is the best way to blend in with normal traffic and avoid firewall rules.

What this article failed to acknowledge is that 95 out of 100 times uploading a very small file to the HP through JetDirect will crash the service and the server from my testing. In my opinion the threat that these unsecured printers pose on the internet is minimal at best with regards to this. The miscreants that push malware can buy cheap server space using stolen credit cards or anonymous payment methods. Additionally, real web servers that can handle traffic can be infected via WordPress vulnerabilities and misconfigurations nearly as easily as these HP printers with the aid of Shodan.io for targeting. The last thing a criminal wants is for the spear phishing to be successful but the infections to fail due to crappy hosting for the malware.

A more accurate assessment of this threat would be to comb the Shodan results for “Port:9100” looking for malicious files hosted on these HP printers. I am guessing the number would be nearly non-existent and not cause the malware pushers don’t know about the opportunity. Cause it isn’t worth their time.

IMHO a more worthy use of multi function devices for malicious purposes would be trying to configure any digital sender functionality to go through your personal SMTP gateway so that you can take copies of internal documents. If they are using LDAP for authentication that also opens up the possibility of stealing credentials if you can pipe the queries through the attacker box.

Here is a small sideproject that I had wanted to do for awhile, but hadn’t made the effort until I got some downtime in a hotel.

Problem:
Creating a unique URl/address/lander/etc that you can find easily, but is hard to locate for a outside party even if they have access to full packet capture (albeit not likely analyzing realtime).

Solution:
Not inventing the wheel here, but I hadn’t made it myself so why not learn. This same sort of tactic is used by people that hardprogram malware to beacon out to a generated list of domains which shifts according to time. My personal idea for this one is that you have a command and control login page you don’t want people brute forcing, or maybe you are just storing data scraped from cookies on a server and you don’t want it to be static. This allows you to very easily have a resource changing it’s name in a way which you can figure out from any computer that has access to sha1sum. Because you can go to http://www.sha1-online.com/ that is every device with a NIC interface….

Problems:
Obviously if you use this on blahblah.com/crazyuniqueid.php anyone on the defense side worth a darn will write a rule to block or trigger any callouts to blahblah.com.

If you use this generator to make subdomains like 2341321#@@E@E.blahblah.com the same tactics apply. That being said, what if you use this code with a smtp library to send an email out to randombunchofcrap@gmail.com and this changes every 24 hours? A bit more difficult to detect.

This is V1, I hope it will grow in capabilities.

Rundown:
On the server with your landing page run this script. python nameofscript.py “secret code” path/to/file filename.php
Set it and forget it.

Then wherever you are and you want to login, or check hash dumps that are being posted, etc.
type into your command *nix prompt echo -n “YEAR-MONTH-DAY:secret code” | sha1sum
take that sha1sum output and slap a .php on there and go to your url. login and rejoice that google isn’t indexing it.

This is what it looks like when you run it initially on the server……..

This is how you find your landing page wherever you are. Or through an online sha1sum creator…

NOTE: I used system calls for hashing, etc. This will not run on a non *nix server. So if you are running this on windowz it is most likely going to have to use python libs and be compiled by the likes of pyexec. If you’ve gone that far you might as well duplicate this functionality in powershell and then post it here 🙂

On a recent engagement I supported the lead by developing a PowerShell payload for a RubberDucky. The gist is that it will run a handful of standard Windows commands and then e-mail the results to a specified address. It proved to be very helpful and I’ve included it below with comments – here’s a present from penetratio.io:

So, every once in a while I have odd requests from customers to do silly things. For example, I was on an engagement a few months ago, and my customer wanted me to scan 6 computers at a time. At first, I thought to myself, I am not going to scan 6 computers at a time, that would take forever and you are stupid. Then, I thought, hmmm..maybe I can at least figure out something to make it worth my while. One of the first obstacles I had to overcome is the fact that I have several input lists that had 100’s of IP addresses in them. I wrote a small python script to take a list of IP addresses and sort them and save them into a new file. This was not necessary, but if you are anal about certain things like I am, its easier for me to have just one list that is nice and neat. Of course, you can do this with sort, awk, etc. but I wanted an excuse to write more in python. The second obstacle I had to overcome is how to create several lists from this new file and create a billion smaller files with each with 6 IP addresses. So, I wrote a script that will take your IP file and a “number” and then create files each with that “number” of IP addresses in them.