Internal Honey Pots/Honey Accounts

Recently I’ve been seeing a new-ish method for honeypot deployment and intruder detection on local networks that I thought was pretty neat. It’s a method that uses tools that are already at a network admins disposal, doesn’t require any fancy tools, and teaches people a little more about working with AD in a way that makes their logs provide more specific threat intelligence.

The technique has to deal specifically with admin accounts on your Domain Controller. The idea is that once your network is breached, that attacker is going to do some kind of recon within your network. Obviously the DC is going to get looked at, which is where you’re going to have this low hanging fruit that looks much more like poor administration than a honey pot.

Specifically, an account is created that is a Domain Admin and has horrible password security. Either have some terrible password set or even put the password in the description (which plenty of people are guilty of actually doing). The key to this method though is the login hours are essentially set to never; so this account will never be authorized to login. So any attempts made to login via this account with both fail and also trigger a logged event that is by it’s very nature probably malicious.

Creating The Account

1) Create a new Domain Administrator account

2) Have a horrible password set (Bonus: Leave it in the description.)AD_create

3) Go to the Account tab and select Logon Hours and set Logon Denied to 24 hours/7 days a week. Time_restriction.png

Setting Group Policy

Verify the following Group Policy options are set…

  1. Edit the Default Policy.
  2. Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Logon -> Audit Kerberos Authentication Services and set to audit Failure eventsDefault_DomainDefault_Domain2

3) Update group policy on your clients by running gpupdate /force

Utilizing Event Viewer

This technique requireed a bit of homework in terms of using Event Viewer and how this gets logged. Typically, failed login events are logged as Event ID 4625; rather, this event is logged under 4768 Kerberos Authentication Ticket Was Requested. The ticket request has plenty of reasons to fail, but in this case it’s the logon hours that’s triggering it. Below is an XML example of the event:


So there it is! Setup your monitoring of these events within whatever apparatus your organization has setup. However you slice it though, the idea of cleverly using assets that are already at an administrators disposal in a way that has an easy and real impact on your situational awareness, to me, is a huge win. Enjoy!



Intro to Malware – Static Analysis

Hey folks, it’s been a hot minute since I’ve had time to throw something out on here. Been out of the country for a few months and that took up most of my time. Moving past that, I was looking at doing some posts on malware analysis. Malware is where I got my start and I’ve been following a lot of other analysts lately. So why not do a few posts on it?!

Let’s kick this off with the most basic of fundamentals; Static Analysis. You can tell all kinds of things about potential malicious software without even running the dang thing. Hashes, strings, headers, and other items can tell you a wealth of information about what you might be looking at. Starting with that, I’ll use this first post to cover how we can use publicly available tools to get started with basic static analysis of malicious software.


First things first, we need a basic lab environment in which to work. Personally I like to use VMware Workstation, but Virtual Box is a free alternative. For my examples I’ll be working within a Windows 7 Home 64-bit environment. Why Windows 7 and not Windows 10 you ask? I like to go with what I assume the lowest level of most users is. I realize there’s still a plethora of folks running XP, but I’ve seen the majority of organizations I’ve been around at least bumping that basement up to Windows 7, so that’s where I’ll operate as well.

After getting a Windows 7 instance up and running in VMware, I install a few static analysis tools and take a snapshot before loading any samples onto the box. This way if something wonky goes on with whatever I’m working with then I can just revert back to a clean state. I have the following tools loaded up already (although I may or may not use them all):

  • IDA Free
  • PEview
  • PEiD
  • Process Explorer
  • Process Monitor
  • Wireshark
  • WinMD5
  • Dependancy Walker
  • Resource Hacker

Additionally I’ll be using online tools such as VirusTotal and Hybird-Analysis.

I won’t walk through the entire setup for the lab, as that’s something thats covered extensively plenty of other places (google is your friend).

Getting To Work

In this scenario our network admins have passed us a file that they’ve received and think might be malicious; it’s our job to determine if it’s malicious, what it might do, and find indicators of compromise (IoC). The file for this scenario is called “Sample-01.exe“. We’re using static analysis only here, so we need to gather as much information as we can about this file without actually executing it.

The first thing I always do with suspicious files is run it through something like VirusTotal (VT). VT runs the file through dozens of different Anti-Virus systems as well as running it’s own analysis on the file. It’s also owned by Google, so it’s a pretty reliable and well up-kept system. Since we know nothing about this file right now, this might take a lot of the leg work out of it for us. Let’s throw our file in there and see what we come up with…

Sample 01 Scan.PNG

Bingo. Right away we see a crap ton of red flags going up with this file. 38 of 67 different AV systems tested have come back with positive results for malware. Based off the results we can assume this might be some kind of trojan. VirusTotal does much more than this though; let’s take a look at some of the details…

Sample 01 Additional Info

By moving over to the “Additional Information” tab, we can get all kinds of useful stuff. VT has hashed the file for us using a plethora of different algorithms, which can be useful in identifying this specific file. We also get an Import Hash, or imphash, as well. The Imphash is important because it’s a hash of the import table this binary uses. This can be very helpful in tracking malware campaigns as samples change over time (see my previous WANNACRY posts for an example).

Taking note of all this info, let’s move on over to the File Detail tab on VT…

Sample 01 File Detail

Again we get some useful stuff right off the bat here. I was going to run PEiD against this thing anyway, but VT did it for me and identified a packer being used. With a file size of only 16k I feel pretty confident in saying that this might be packed/compressed code and that PEiD probably isn’t lying to me. Additionally we see a compilation time stamp; this can be forged however, which is why I tend to not give it a lot of importance. It’s good to note it, but I don’t read much more into it than that.

Since I now have a quick static analysis of this thing, I like to let something like have a crack at it. Let’s browse on over, upload our file, and see what we find…

Sample 01 HA Suspect Indicators

In this case, Hybrid Analysis doesn’t yield me a ton of interesting info. Something that did peak my interest however was some of the imports. Seeing CreateFileA tells me that this thing is probably dropping something onto the system. Additionally we see FindFirstFileA and FindNextFileA, which is functionality we typically see with malware that is looking to scan through the system. So yea, this has my attention. Let’s move past online tools and start digging into into it further.

Further Static Analysis

Since I’ve got a few of the basic things like hashing out of the way, I want to move into checking out all the different imports this thing is using. To do that I’ll throw it into Dependency Walker to take a further look…

Dep Walker 1

We see Kernel32.dll and MSVCRT.dll listed. Kernel32.dll is a super common import, it controls basic functions like manipulating files and memory; so no big shocker there. We also see MSVCRT.dll, which holds standard C library functions. Looking at just this, I’m not seeing anything very useful. We need to dig further.

I fire up IDA and see what I can see. Having previously seen CreateFileA, I find that function and give it a look…

Ida CreateFile

Winner! We have our first host-based artifact; the malware will drop a file in the System32 folder named “Kernel132.dll“. Further investigation within IDA of that DLL file reveals a hard-coded IP address of ““.

IP Snip

So we’ve now identified both a host-based and network-based IoC. Coupling that with VT flagging this as malware, I would report this back as a probable trojan and look for the IoC’s indicated by our analysis as methods of detecting any infiltration of our network. Took me all of maybe 5 minutes of work.

Finishing Up

In summary, we took a completely unknown file and were able to identify it as probably malicious just based on static analysis. Furthermore, we were able to identify both a host-based and network-based IoC to further check our network for any compromises.

Mission complete!

We could go a LOT further with this by doing some real dynamic analysis on this thing, but that wasn’t the point for this exercise. We specifically wanted to use static analysis to see what we could learn and use.

I’ll probably follow up with additional malware analysis posts in the future. I’m not a professional reverse engineer though, so in the mean time I’d advise seeking out some real pros work and seeing how they do it. Two resources I’d recommend are MalwareTech Blog and Amanda Rousseau.

Until next time!


Hackin n Crackin – “Sedna”

“Senda” is the second Boot2Root in the Hackfest 2016 series by Viper . This one was a bit more difficult and in the end the box ended up tanking. I was still pretty happy with the progress I got on it though and it’s always good to work on my privilege escalation skills.

Let’s Get To It

I downloaded the .ova and spun it up in VMware. Looked similar to the last one in that it just gives you the IP right off the bat.


Kicked off an Nmap scan to see what I’ve got. The results again seemed just like the last one; an apache server, a mail server, and Samba. The only addition of note was the Tomcat server sitting on port 8080.


I take note of everything, but continue with the same methodology that worked for me on the last one. I browse on over to the web server on port 80 and am met with pretty much the same stuff from Quaoar. Checking the robots.txt this time though doesn’t yield anything of interest.

Since I’m not getting anything easy, I start a Nikto scan and see if I can find anything worth pursuing. The results yield two things of interest; /files and /license. I browse over to both and check them out.


Well there’s something! Looks like it’s running BuilderEngine. I do a quick search for any good looking exploits. I find one that allows arbitrary file uploads; I’m immediately thinking of a php reverse shell like I used last time. The exploit is a simple HTML page; you just need to change the URL to point to your target box and voila, you can upload files!



I tried using a PHP web-shell that I’ve used previously, but it didn’t want to work for me. Thought about it for a second and decided to use the PHP shell available from Pentestmonkey. Uploaded the new shell through the same HTML page exploiting BuilderEngine and I was able to get a working shell!

I leveraged this shell for what I could get out of it; some digging around the file system (to what I could access) found me the first flag in /var/www.


Sweetness, so we’ve got our shell and our first flag. I don’t have Root access though so I need a way to escalate my privileges. Taking a note from my previous post on enumeration and escalation, I start to enumerate the system as much as I can (limited since I can’t access everything with my current permissions).


No easy kills… Damn. I spent about an hour digging through some of the services I saw and still wasn’t coming up with much. I did get a bite with the Linux version though, since it was a bit outdated. I came across a local privilege exploit leveraging CVE-2015-1328 (overlayfs). I spent another hour on this one trying to get it to work and came up empty; so back to google it was.

Seems like other folks had similar issues and I found a forum post that discussed a newer privilege escalation exploit that seemed promising. I copy it over and get to work on it. To get it over to my target box I spun up a SimpleHTTPserver on Kali and tried to wget it from my target shell.


Well crap… I had to spend a minute on this one to figure out what the problem was. The connection was fine, it just seemed like a permissions issue. After taking a break for a while and coming back to it, I realized what the problem was. I was trying to write a file to a directory that I didn’t have permissions for; I needed to be downloading it to a place I had permissions to write to! I CD’d over to /tmp and tried again… Success!

*I also forgot to elevate out of the jail-shell, so I used python -c ‘import pty; pty.spawn(“/bin/sh”)’ 


Once I had dirty.c on the target machine I needed to compile and run it. With my elevated shell I didn’t have any issues getting that part out of the way, but this is where the easy part ended…

So a little background on this exploit (CVE-2016-5195); it’s a race condition that basically writes to a copy of a file that root owns (aka one we don’t have permissions for). In this case, we’re writing a new entry to /etc/shadow in order to add a new root user.

Without getting super into the technical details, the basic thing I want you to understand is that we’re messing with memory is a weird way. That’s important to know because doing weird things to memory is a surefire way to make the system start doing weird stuff.

So with that in mind, I did manage to get the exploit to work, add a new root user to the target system, and connect via SSH as that new root user.


…as you can see I started to type a command once I had my shell. I got stopped because the target box got bricked. I thought to myself “oh well this is probably just a one-off. Exploits can cause all kinds of weird stuff to happen“. I restarted the boxes and went through the process again; same result. A few tries later, still no dice, and now on top of that, networking services on both the target box and my Kali machine have stopped working…

So I’m starting to think that the problem is part exploit related but also part VMware related. I’ve seen some of the CTF VMs that get a little touchy when ran on VMware rather than VirtualBox, so that might have something to do with it.

Either way, I feel pretty good about how far I got with this thing. The exploit for BuilderEngine was done in a way I’ve never seen before and getting the DirtyCOW exploit working was a lot of fun. It required more thinking than just “find an exploit, run the exploit“. I’m bummed the system wasn’t stable enough to continue, but I was able to get multiple shells and eventually create a root user. Not bad!

If I get some time later I might give Orcus a shot. It seems these VMs might be a little temperamental on VMware so we’ll see. If not though there are still a myriad of options available, so I won’t have to look very hard for the next challenge.

Thanks for reading!


Hackin n Crackin – “Quaoar”

So since I’ve got a little time off from work, I figured it would be a good time to do a CTF/Boot2Root. This one, “Quaoar“, is the 1st in a series by Viper called “Hackfest2016”. I’ll dig through the other two probably later this week.

First things first let’s get this thing fired up. I downloaded the .ova and opened it in VMware.

Q-BootIt appears to have a static IP, so that at least saves me the hassle of having to scan around to find it. I did a quick ping to make sure it was alive, and after a good response I kicked off a quick Nmap scan to see what I’m working with.

K-Scan1Looks like I’ve got an OpenSSH server, DNS, an Apache server, a mail server on a few different ports, Samba, and it’s probably running Linux. Great! Plenty of info to get me going.

Whenever I see web servers I always like to start there. So I hop on over through my browser and am greeted with the following images:

Really nothing of note here, although I enjoyed the joke ;). A quick look at the HTML doesn’t reveal anything I care about either.


So next I’ll always check out the robots.txt file and see if there’s anything interesting…

K-RobotsNice! I can see it’s probably running WordPress. After a bit of browsing I land on /wp-login/ where I’m prompted with a login screen. I spray it with the usual horribly insecure username/password combos and get a bite with “admin:admin“. We’re in!

I’ve got admin access to the website now, but I want more than that. Typically here I’d use MSFVENOM to create a reverse tcp PHP file and upload that as a plugin. But, I’m a lazy hacker and I found an awesome tool recently that does all the work for me! A guy by the name of “n00py” has an awesome toolset out on GitHub called “WPForce”; part of that toolset is a python script called “Yertle” that makes the process of getting a shell a whole lot faster. I grabbed his script, loaded it up, and in seconds had my shell to the box.


I always tell people “one is none and two is one”, so now I’ve got my second way to get at this machine. Once I drop into the shell I look around and take stock of who I am and where I’m at.


Looking through what’s available to me, that WordPress directory looked interesting. So I drop in and take a look.


After digging around a bit in here I finally started going through “wp-config.php“, where I started to find some interesting things. Inside that file I find that there’s credentials for a MySQL database.


Seeing as password security hasn’t been this box’s strong suit I decided to open another terminal and see if these might be the root users credentials as well…


Winner winner!! Again I do some basic checks to see what’s around me and voila, flag.txt is sitting right there. After a quick search for any more files, I was able to find the 2nd flag in /home/wpadmin.

Post Remarks

All in all it was a fun box to break. The common theme of weak passwords definitely does mirror real life scenarios since there are plenty of admins out there that practice terrible password security. I’m excited to check out the next box in the series and see how Viper ups the difficulty!

Until next time….



Enumerating and Escalating in Linux

Ahh priv escalation… The bane of many hackers experiences; but it’s a critical thing to start to get a grasp on and it’s something I try to harp on a lot. Now, I’m by no means the end-all-be-all expert here because this is a huge topic that has a lot of nuances. But one thing I constantly tell people that I’m training or just shooting the shit with is always asking the question of “what’s next?”. What’s next after you gain access? What’s next after you’ve gotten root? How far can you take this thing? In order to keep going down that tree of thought, you’re gonna need to start hitting privilege escalation to find out.

In this game, enumeration is KEY! We want to learn as much as we possibly can about the environment and it’s workings so that we can start seeing where the holes might be. After we learn what we can, we’ll start processing that data and look to see if we can find (or create) exploit code for anything we find. As always, we’ll have to try a whole bunch of things old and new, some of which will require repeatedly banging your head through the wall. Which is why I always tell folks that this kind of work is a whooooole lot of trial and error; so get ready to do plenty of google searches and be open to exploring things you’ve never touched before. Nobody is an expert in everything, so the goal here is to understand the process and then learn how to fill in the blanks for what you need.

The overall process can be boiled down to the following:

  • Collect  Enumerate, enumerate, ENUMERATE.
  • Process – Sort through, analyze, and prioritize.
  • Research – Find out more about your High-Pri items, search for exploit code, etc
    • Be ready to have to alter exploit code on the fly. Not everything works out of the box for everything you might be going after. BE FLEXIBLE!
  • Exploit – Mount your attack. Be ready for plenty of trial and error!

This post by no means covers everything that’s out there. It’s just some quick down and dirty tips to get you going both on the box and mentally thinking about things. Greetz to g0tmi1k for a lot of the content; I just tweaked a few things and took out what I didn’t want.


So first things first, when we get on a box we want to start exploring our environment. Where are we? Who are we? What’s going on around me?

Below are a list of commands that can be used to help enumerate the system and understand the environment.

What distro type and what version?

cat /etc/issue
cat /etc/*-release
cat /etc/lsb-release #Debian based
cat /etc/redhat-release #Redhat based

What’s the kernel version?

cat /proc/version
uname -a
uname -mrs
rpm -q kernel
dmesg | grep Linux
ls /boot | grep vmlinuz-

*vmlinuz is the name of the Linux kernel executable.

List all environmental variables



What about printers?

lpstat -a


Applications and Services

What services are running?

ps aux “Aux” is actually a combo of 3 separate switches. A shows all processes for all users, U displays the processes user/owner, and X shows processes not attached to a terminal. We can just pass all these together though, as seen in the example.
ps -ef Similar to “ps aux”, just in standard syntax vs BSD.
top Shows real-time view of the system.
cat /etc/services Read more on /etc/services here.

Important note on “ps aux” and “ps -ef”; it’s gonna throw a lot of crap at you. So since we’re looking for things running as Root, we can pipe all that output and grep for “root”, as seen below:
ps aux | grep root
ps -ef | grep root

Check what applications are installed. What version are they?? Are they currently running???

ls -alh /usr/bin/
ls -alh /sbin/
dpkg -l
rpm -qa
ls -alh /var/cache/apt/archivesO
ls -alh /var/cache/yum/

Look at the config files for different services. Are there any settings misconfigured?

cat /etc/syslog.conf
cat /etc/chttp.conf
cat /etc/lighttpd.conf
cat /etc/cups/cupsd.conf
cat /etc/inetd.conf
cat /etc/apache2/apache2.conf
cat /etc/my.conf
cat /etc/httpd/conf/httpd.conf
cat /opt/lampp/etc/httpd.conf
ls -aRl /etc/ | awk '$1 ~ /^.*r.*/


Basic networking info 

ifconfig -a

What NIC(s) does the system have? Do we have access to other networks (pivoting)??
/sbin/ifconfig -a
cat /etc/network/interfaces
cat /etc/sysconfig/network

What’s cached? Any IP or MAC addresses?
arp -e
/sbin/route -nee

Can we sniff live traffic?
tcpdump tcp dst x.x.x.x xx and txp dst x.x.x.x xx
Note: tcpdump dst [ip] [port] and tcp dst [ip] [port]

Is tunneling possible?
ssh -d -N [username]@[ip]
proxychains ifconfig

User Info and Confidential Information

Who am I? Who is logged in? Who has been logged in? Who else is there? Who can do what?

cat /etc/passwd | cut -d: -f1 # List of users
grep -v -E "^#" /etc/passwd | awk -F: '$3 == 0 { print $1}' # List of super users
awk -F: '($3 == "0") {print}' /etc/passwd # List of super users
cat /etc/sudoers
sudo -l

Can we access sensitive directories?
cat /etc/passwd
cat /etc/group
cat /etc/shadow
ls -alh /var/mail/

ls the Root and Home directories (if we can) and see if there’s anything interesting.
ls -ahlR /root/
ls -ahlR /home/

*The tags for ls are case sensitive. So make sure you’re using the correct syntax. If you want further information on each one just google it or check the Man page. -ahlR however is basically just asking for “all” the info, in human readable and long list format, listing sub directories recursively. *

Are there any user credentials in a script, database, config files, or log files? 
cat /var/apache2/
cat /var/lib/mysql/mysql/user.MYD
cat /root/anaconda-ks.cfg

*Not limited to these by any means. Just get in the mindset of looking for juicy info inside of things like conf or log files.*

What has the user been doing? Any passwords in plain text? What have they been editing?
cat ~/.bash_history
cat ~/.nano_history
cat ~/.atftp_history
cat ~/.mysql_history
cat ~/.php_history

Can we dig up some more user info?
cat ~/.bashrc
cat ~/.profile
cat /var/mail/root
cat /var/spool/mail/root

Can we get a private-key?
cat ~/.ssh/authorized_keys
cat ~/.ssh/
cat ~/.ssh/identity
cat ~/.ssh/
cat ~/.ssh/id_rsa
cat ~/.ssh/
cat ~/.ssh/id_dsa
cat /etc/ssh/ssh_config
cat /etc/ssh/sshd_config
cat /etc/ssh/
cat /etc/ssh/ssh_host_dsa_key
cat /etc/ssh/
cat /etc/ssh/ssh_host_rsa_key
cat /etc/ssh/
cat /etc/ssh/ssh_host_key

*I can’t tell you how many times I see people put their sensitive PKI files in stupid places with absolutely no thought to protecting them. It’s not unheard of to just see them sitting there on the desktop or in the users home directory. Easy win in a lot of cases if you know to look for it.*

More Logs!

Can we find anything good in /var?
ls -alh /var/log
ls -alh /var/mail
ls -alh /var/spool
ls -alh /var/spool/lpd
ls -alh /var/lib/pgsql
ls -alh /var/lib/mysql
cat /var/lib/dhcp3/dhclient.leases

More log files…
cat /etc/httpd/logs/access_log
cat /etc/httpd/logs/access.log
cat /etc/httpd/logs/error_log
cat /etc/httpd/logs/error.log
cat /var/log/apache2/access_log
cat /var/log/apache2/access.log
cat /var/log/apache2/error_log
cat /var/log/apache2/error.log
cat /var/log/apache/access_log
cat /var/log/apache/access.log
cat /var/log/auth.log
cat /var/log/chttp.log
cat /var/log/cups/error_log
cat /var/log/dpkg.log
cat /var/log/faillog
cat /var/log/httpd/access_log
cat /var/log/httpd/access.log
cat /var/log/httpd/error_log
cat /var/log/httpd/error.log
cat /var/log/lastlog
cat /var/log/lighttpd/access.log
cat /var/log/lighttpd/error.log
cat /var/log/lighttpd/lighttpd.access.log
cat /var/log/lighttpd/lighttpd.error.log
cat /var/log/messages
cat /var/log/secure
cat /var/log/syslog
cat /var/log/wtmp
cat /var/log/xferlog
cat /var/log/yum.log
cat /var/run/utmp
cat /var/webmin/miniserv.log
cat /var/www/logs/access_log
cat /var/www/logs/access.log
ls -alh /var/lib/dhcp3/
ls -alh /var/log/postgresql/
ls -alh /var/log/proftpd/
ls -alh /var/log/samba/

System Interaction

What programming languages are installed or supported?
find / -name perl*
find / -name python*
find / -name gcc*
find / -name cc

How can we upload files?
find / -name wget
find / -name nc*
find / -name netcat*
find / -name tftp*
find / -name ftp

Starting The Exploitation Process

Finding Exploit Code

Get Further Information On An Exploit/CVE


*Important!* Do your homework when you start looking at exploits, ESPECIALLY if you’re getting them from a less than reputable source. The last thing you wanna do is either backdoor or brick your own machine because you didn’t bother to check out the source code for whatever it is you’re running. Long story short, don’t be stupid.

All of these are just tools to get you moving in the right direction. If you have the process in your head, then figuring out how to drive that direction is a whole lot easier. Think about your goal and then work backwards on how to get there. Stay frosty!


COBALTTIDE – One worm to rule the world

As promised, I’m finally following up a bit more on the worm that has been so very effective at spreading all the recent strains of WANNACRY and now UIWIX. Since I’ve yet to see it having been given a name, I’ll be calling the worm COBALTTIDE.

For this analysis we’ll be looking at the sample corresponding to MD5 hash db349b97c37d22f5ea1d1841e3c89eb4. I chose to start here for a couple reasons: first is that is was one of the earlier samples that’s had time to get looked at pretty thoroughly. Secondly, this and subsequent variants right after it all share the same IMPHASH of 9ecee117164e0b870a53dd187cdd7174. Why is the Import Hash significant? Because it shows the core of the malware is remaining the same and that only smaller functionality tweaks are being made in each follow on version.

Overall Infection Life Cycle

Below is a quick execution flow for WANNACRY’s life cycle as a whole, courtesy of Amanda Rousseau at ENDGAME Inc:ExeFlow.png

I used this graphic to demonstrate the overall life cycle of the malware in order to get some scope/perspective. For this post however, we’ll specifically be focusing on the COBALTTIDE worm that it uses to propagate.


Domain Check

First, we’ll take a look at the initial step in the process which is the kill switch domain check. This feature was most likely implemented to halt the spread of the malware should something go wrong, but it also could function as an anti-sandboxing technique (within a sandbox environment it might not be able to connect out, thus exiting and thwarting analysis). So once on the system and executed, this is the first check that is performed:


Fellow researcher Didier Stevens also made a great observation in that the 2nd argument being passed to InternetOpenA is “1“, which correlates to INTERNET_OPEN_TYPE_DIRECTWhat this means is that it will resolve host names locally through a direct internet connection. Why is this important? Because it shows that this sample isn’t proxy aware. Meaning that machines that have proxied access to the internet aren’t using the direct connection that COBALTTIDE is looking for; thus they will be unable to properly resolve the now sink-holed kill switch URL, and COBALTTIDE will continue with it’s execution regardless of the fact that the domain now actually does exist. This is important to know because most large organizations (corporations, government, etc) proxy their traffic and thus would still be vulnerable.

Payload Setup

Once the url check fails, COBALTTIDE will then need to get the worm payload binary onto the system. It does this by opening up two different buffers in which to inject the payload DLLs from the .data section of the worm. The payload DLLs come in both x86 and x64 variants. Once loaded, it will then copy the rest of the worm binary with it. This will all get copied to disk as “C:\WINDOWS\mssecsvc.exe” and executed.

Scanning and SMB-based Propagation

Once executed, COBALTTIDE creates two threads; one to scan the local network that it finds itself on, and the other to begin scanning randomly generated IPs on the open internet.

In order for it to begin scanning the LAN it first needs to know the IP range on the local network, which it does by calling the GetAdaptersInfo function. Once it has the range it will create an array of every possible IP within that range to be scanned.


Of active IP addresses in the range scanned, COBALTTIDE will attempt to connect on port 445 (SMB). If a connection is successful it will push ETERNALBLUE and attempt exploitation.



The web scanning thread essentially does the same thing, it just selects IP address ranges in a different way. To perform the scan, COBALTTIDE will generate random IP addresses, with the first octet not equaling 127 or being greater than 224 (in order to not scan loopback addresses) and attempt connections again over port 445. WannaCrypt7WannaCrypt8

If a connection succeeds, the entire /24 subnet for that address is then scanned.  It will attempt to throw ETERNALBLUE at every available connection that it finds, thus creating hop points into new networks and starting the infection cycle over again.

Post Exploitation

Upon successful execution of COBALTTIDE, the malware will utilize a modified version of DOUBLEPULSAR in order to drop the ransomware dropper payload. If you’d like further information on DOUBLEPULSAR, the folks over at Countercept have written a fantastic piece on it.

Thanks for reading and I’ll see you next time!


WANACRY – The Saga Continues…

Only a few days into this thing and of course we’re already seeing spin-off variants of the original binary making their way into the wild.

family tree


Over the weekend we’ve had a few ups and downs; we’ve identified 2 kill-switch domains that were hard coded into the binaries which were subsequently discovered and sink holed. Heading into Monday however we’re starting to see the natural processes run their course as new variants enter the wild.

Variant 3 (MD5: d724d8cc6420f06e8a48752f0da11c66) is already starting to display some new behavior. The above variant does not have a hard coded kill-switch within the code, but hasty changes appear to have broken this variant’s ransomware capability.


The spreader capability made possible by ETERNALBLUE and DOUBLEPULSAR still works as advertised. However, the actual ransomware functionality appears to be broken, most likely due to a corrupted archive. The domain check code still appears in is variant’s code, however it’s jmp’d and zeroed out.

Keeping this one short but I wanted to throw a little something out there with some recent updates.


WANACRY Ransomware (WanaCrypt0r)

This Is Why We Can’t Have Nice Things

Nation-state level exploitation tools are now in the hands of everyday cyber-criminals (thanks again Russia and Snowden!). Now the world as a whole is dealing with one of the largest ransomware attacks to date, with infections ranging from the NHS in the UK, financial institutions, the transportation sector, and universities around the world. As of today we’re over the hundred thousand infections mark.

Infection Maps and GoogleDork:

I’ve seen a few media outlets (both from within the industry and outside of it) that are heaping criticism onto the NSA for even making the exploit kits in the first place versus getting those exploits published and patched. To which I would say, what the hell do you think an intelligence organization does? Do you think the CIA taps our enemies on the shoulder every time they find a new collection technique? No. So don’t fault the NSA, USG, or anyone else except the criminals themselves and the Russians for dropping this onto the open web.

That being said, this kit was built in such an aggressive manner that even I’m kind of surprised. Previous major ransomware attacks like CryptoWall or LOCKY utilized pretty standard attack vectors and post-exploitation techniques. While effective in their own right, WANACRY has taken it a step further with the addition of the released ShadowBrokers toolkit being used to power a worm that significantly enhances the infection rate.


WANACRY makes use of the recently released ETERNALBLUE exploit (MS17-010), which exploits SMB v1 using specially crafted packets (packet capture from SANS testing can be found here). Exploits are just used to gain access though; it’s the implant or payload that starts getting things done on the machine, and in this case the authors make further use of the ShadowBrokers dump by using the DOUBLEPULSAR backdoor implant.

There’s plenty of information already on the web about both of these tools so I won’t go super in-depth about them right now. I’m looking at doing a post next week that takes a deeper technical look at the worm itself and its inner workings. So you’ll get the technical meat in a few days. I’ll also include a quick mitigation guide at the bottom of this post.

Ransomware Functions

For reference, here is a recently analyzed sample:

Taking a closer look we can see your standard malware fare here:

  • It utilizes “reg.exe” to alter the value of HKLM\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN to maintain persistence.
  • It will query the machine version, timezone, volume sizes, and users names on the system using the GetVersionGetTimeZoneInformationGetDiskFreeSpaceExWand  GetUserNameA function calls.
  • Reads from HKLM\SYSTEM\CONTROLSET001\CONTROL\NLS\LOCALE in order to check language settings. Useful when you want to display your ransom note in the correct language!
  • You can also tell something is fishy when you take a look at the entropy in the file sections: Sections

On the cryptography side of the house we learn a few things as well:

  • Each infection will generate its own RSA 2048-bit keypairs.
  • The resulting public key is exported and saved to a file called “00000000.pky“.
  • The private key of the pair is encrypted using WANACRY’s public key and is stored as “00000000.eky“.
  • The keys themselves are created utilizing AES-128-CBC, with a unique AES key per file.
  • WANACRY’s public key can be found here: (clicking this will download the .bin file)

During the malware’s scan of the system, it will look to encrypt the following file types:

.doc, .docx, .xls, .xlsx, .ppt, .pptx, .pst, .ost, .msg, .eml, .vsd, .vsdx, .txt, .csv, .rtf, .123, .wks, .wk1, .pdf, .dwg, .onetoc2, .snt, .jpeg, .jpg, .docb, .docm, .dot, .dotm, .dotx, .xlsm, .xlsb, .xlw, .xlt, .xlm, .xlc, .xltx, .xltm, .pptm, .pot, .pps, .ppsm, .ppsx, .ppam, .potx, .potm, .edb, .hwp, .602, .sxi, .sti, .sldx, .sldm, .sldm, .vdi, .vmdk, .vmx, .gpg, .aes, .ARC, .PAQ, .bz2, .tbk, .bak, .tar, .tgz, .gz, .7z, .rar, .zip, .backup, .iso, .vcd, .bmp, .png, .gif, .raw, .cgm, .tif, .tiff, .nef, .psd, .ai, .svg, .djvu, .m4u, .m3u, .mid, .wma, .flv, .3g2, .mkv, .3gp, .mp4, .mov, .avi, .asf, .mpeg, .vob, .mpg, .wmv, .fla, .swf, .wav, .mp3, .sh, .class, .jar, .java, .rb, .asp, .php, .jsp, .brd, .sch, .dch, .dip, .pl, .vb, .vbs, .ps1, .bat, .cmd, .js, .asm, .h, .pas, .cpp, .c, .cs, .suo, .sln, .ldf, .mdf, .ibd, .myi, .myd, .frm, .odb, .dbf, .db, .mdb, .accdb, .sql, .sqlitedb, .sqlite3, .asc, .lay6, .lay, .mml, .sxm, .otg, .odg, .uop, .std, .sxd, .otp, .odp, .wb2, .slk, .dif, .stc, .sxc, .ots, .ods, .3dm, .max, .3ds, .uot, .stw, .sxw, .ott, .odt, .pem, .p12, .csr, .crt, .key, .pfx, .der

Interestingly enough however, it will also skip over some items if certain strings are detected. This functionality exists because either the encrypting that object would be pointless or that doing so might destabilize the system.

  • “Content.IE5”
  • “Temporary Internet Files”
  • ” This folder protects against ransomware. Modifying it will reduce protection”
  • “\Local Settings\Temp”
  • “\AppData\Local\Temp”
  • “\Program Files (x86)”
  • “\Program Files”
  • “\WINDOWS”
  • “\ProgramData”
  • “\Intel”
  • “$”
  • @Please_Read_Me@.txt (native WANACRY file)
  • @WanaDecryptor@.exe.lnk (native WANACRY file)
  • @WanaDecryptor@.bmp (native WANACRY file)

It will also skip anything with the following extensions:

  • .DLL
  • .EXE
  • .WNCRY

**Credit to herulume and cyg_x11 for extracting those from the binary!!**

Ransom Addresses and C2 Infrastructure

Three Bitcoin addresses are hard coded into the binary:

The samples collected so far also utilize TOR to connect to it’s C2 infrastructure. C2 servers identified so far are listed as:

  • gx7ekbenv2riucmf.onion
  • 57g7spgrzlojinas.onion
  • xxlvbrloxvriy2c5.onion
  • 76jdd2ir2embyv47.onion
  • cwwnhwhlz52maqm7.onion

Mitigation Techniques

If you haven’t patched your machine in a while, PATCH THE DAMN THING!! Microsoft has had updates for the ETERNALBLUE exploit for a hot minute now and if you haven’t updated yet then you’re seriously slacking as an administrator. If you have unpatched machines, get them off the network until they can be updated with the current patches.

Disable SMB v1. Also, if you have SMB that is public facing then you should be blocking inbound traffic on ports 139 and 445.

Luke Jennings from @countercept also developed a quick python script that can remotely detect and remove the DOUBLEPULSAR backdoor. It can be found here.


By design, the ransomware would check if the domain is up. If it is, it will exit. If not, it would continue to run as normal. This was intended as a kill-switch that the authors could activate to cease the spread of malware. That domain has now been bought up and sinkholed, thus stopping the spread of this specific variant of WANACRY. Credit to @MalwareTechBlog for the research and quick action!

This doesn’t mean we won’t see this thing again however. It just means this specific strain will no longer continue to spread. Expect the authors and copycats alike to simply alter the binary to remove this check and further attempt to spread this thing further.



Denial of Service Attacks (Pt 2)

Layer 7 Attacks

In this post I’ll cover three types of Layer 7 attacks; the HTTP GET method, HTTP POST method (a la “RUDY”), and the fragmentation method used by tools like SLOWLORIS. There are other ways to cause DoS conditions at this layer, but I’ll save those for another day because they have to do with a few other methods of web-based exploitation.

The other thing I want to mention about these types of attacks is that they typically don’t require the huge amount of machines or overhead that you would need with the attack styles we’ve previously discussed. In the previous post you can see how having an army of machines would be helpful to you when flooding a server or network with junk packets; but in this case, a single attacker can get his intended effects on the target with significantly less devices and resources at his disposal.


The GET flood works in a very similar manner to the SYN flood that we covered in the last post, with a slight exception. In this case, the Three-way Handshake at Layer 4 (TCP) is completed; so now this traffic looks much more legitimate than just junk packets being hurled at the system. At the surface level it much more appears to be a legitimate user, which brings us to the next step: REQUEST ALL THE THINGS!

Imagine I’m targeting a specific website, and on that website the admin used a large photo or file somewhere. The idea with this attack is that I’m going to connect and then request that large file….thousands of times. Again, and again, and again, until I exhaust all the servers resources with these requests. So you can see the similarities between this and something like a SYN flood; this just takes the attack a few steps further up the OSI model in order to bypass those Layer 4 protections.


This method was popularized by a script called “R-U-Dead-Yet?” aka “RUDY”.

The attack involves web-based forms on a website. Imagine a comment field or something; when we want to submit data through that form and back to the website then we would be using the POST method to do that.

Like I’ve said before, that’s fine and dandy when everyone plays by the rules. But instead of being a responsible user and just submitting the data we want in a reasonable way, what happens if we were to drag that process out as long as possible? Enter RUDY.

RUDY performs its attack by dragging out the POST process as long as possible by sending a legitimate POST request with an abnormally long ‘Content-Length‘ header field, after which it starts injecting that form with data one-byte at a time. Here is a quick snippet from the RUDY source code that demonstrates what the ‘Content-Length‘ field looks like in the actual POST request.

RUDY snip

As RUDY sends lots of very small packets at such a slow rate (can be ~10 seconds between each byte), it creates a massive backlog of application threads handling it all. On top of that, with such a large ‘Content Length‘ set, it prevents the server from closing the connections.

Servers only have so many connections they can support at any given time. So with RUDY both opening connections AND keeping them open for as long as possible, it quickly consumes every available connection and brings down the server for everyone else. Also as old connections time out or eventually drop, RUDY will just spawn a new connection and keep that next one open for as long as possible. The vicious cycle will just continue.

This attack is a little more sneaky and can go under the “Low and Slow” classification since it’s not hammering a server with crazy amounts of volume like you’d see in a DDoS attack. Defending against this technique also requires paying close attention to server resources since you won’t be seeing crazy amounts of traffic being hurled your way, so it takes a bit more digging.

SLOWLORIS and the Fragmentation Method

The fragmentation method is similar in nature to what we just discussed, however it does its job in a slightly different way.


SLOWLORIS works by consuming all available connections to a server, but instead of holding them open the way RUDY does, it does so by sending incomplete requests. The server sees the incomplete request and assumes that something happened during the request that resulted in it being incomplete. So being the good server it is, it will keep the connection open in hopes that the connecting host will finally send the complete and proper request. We abuse this function until we’re taking and holding every available connection the server has.



I also want to touch on the server side of things of why this attack works so well. Most servers make use of a ‘timeout’ function to kill off incomplete HTTP requests. This is a useful function because if something happens to that connection then there needs to be a way to prune it off in order to make room for the next client to connect. By default, most servers will wait something like 300 seconds before it kills the connection. This counter resets itself when it finally starts to receive some data. So the idea behind this attack is to abuse that function by sending incomplete packets at very long intervals (hence the name Slow Loris). It keeps resetting that counter by trickling in tiny bits of data while also waiting long amounts of time between when it’s sending that data. If you can keep this process going, then eventually it will use all the available connections, keep them open indefinitely, and effectively down the site.

Using this technique a single attacker can down a site with very little resources, time, or effort. Yay!


In Conclusion…

Hopefully this gave you a basic idea of how some of these attacks work and what’s going on behind the scenes a little. DoS/DDoS attacks are constantly changing so by no means is this an exhaustive guide to every possibility. But what I hope you got from it is understanding the idea of taking a protocol or process, looking at what should be happening, and twisting that in order to abuse it for malicious purposes.

If none of that made any sense though, there’s always the good ‘ol Layer 1 attack!


Denial Of Service Attacks (Pt 1)

I was kicking around some ideas the other day with a buddy, trying to figure out what would be a good topic to kick this thing off with. We mentioned things like BGP hijacking, malware analysis and CC fraud, and then he offhandedly mentioned a pretty banal DDoS attack that his network had seen recently. Luckily his network has an absolutely stupid amount capacity, so it ended up being pretty insignificant. But it got me thinking; DDoS attacks are where most script kiddies get their starts and it accounts for a fairly large amount of of news headlines throughout the year. So with that in mind, it kind of seems like a natural place to start.

DoS vs DDoS

While the idea is similar for both of these, the execution is where they differ. For a basic Denial of Service (DoS), it’s typically one connection being used to down a service (in most cases a webserver or something, but it’s not limited to that by any means). A Distributed Denial of Service (DDoS) attack takes the same idea and just multiplies it by many connections. The overall idea here is for you to throw enough of something at a service in order to overwhelm it to the point where it quits functioning properly (hence “denial of service”).

I’ll use this first image to describe a DoS attack. Think about that single connection I talked about and think about this single stream these dudes are sitting in. You should get the idea by watching it…


So now take that idea and multiply it across multiple hosts…


You can see very clearly how that could tank a box pretty quickly! This is also a huge part  (but not all) of the reason why botnets are a thing. Infecting thousands of computers and weaponizing them can generate devastating amounts of traffic if your bot-farm is big enough.

OSI Layers

DoS/DDos attacks typically happen in two different layers of the OSI model: the Transport Layer and the Application Layer.

*I say typically because you can cause DoS conditions in other ways. For example say you throw some exploit code at a box and things just don’t jive well; you could still down the service but it may not be in the same way.*

Let’s take a look at the OSI stack real fast…


The Transport Layer is where we would find our TCP and UDP connections, whereas Layer 7 (Application) is where we see our user interface and application based protocols like HTTP, FTP, etc. Abuse of these protocols and how machines handle them are what let us conduct these types of attacks.

TCP/UDP Floods

To better understand how TCP based attacks work, you need a basic understanding of how TCP works. Below is a quick example; it’s what we call the “Three-Way Handshake”.


Seems all nice and orderly doesn’t it? As with most attack techniques, the fun begins when we start messing with what’s “expected” and start doing our own thing.

Sure, that model works fine if Bill is only sending the amount of requests that he needs to get the services he requires from Sheela’s machine; but what happens if Bill were to send that request an additional 10,000 times? If Sheela didn’t have any defenses to help her out then her machine would most likely crater under the weight of trying to meet all of these requests. Her machine would continually try to meet the massive amount of requests, which means if anyone else were to try and connect, it’s either going to be incredibly slow or not work altogether.

tcp flood

In the above example a SYN flood is being utilized, but this style of attack isn’t limited to just the SYN flag. Again, a lot of attack vectors are born out of using devices or features in ways they weren’t designed to be used. So take that principal and imagine what a FIN flood might look like, or maybe sending thousands of RST packets. Sending a machine something different than what it’s expecting is a great way to break things, but sometimes that’s what we’re trying to do…

Redirection Attacks

Knowing what we now know about how basic TCP/IP connections works, let’s take a look at redirection attacks.

When you send a packet to a host it will obviously include the source IP of who sent it. But what happens if we changed that source IP that the host would look to respond back to? What if we bombarded a server with queries and changed the source IP that those packets supposedly came from to the actual target of our attack? The server in middle would see all of our incoming packets, but instead of sending the responses back to us, it would funnel them back to the spoofed source IP that it thinks the requests are coming from. We can weaponize this by spoofing the source IP to be that of our target, finding a server who will respond to requests without question, bombarding that server with requests, and tank the victim host with all the responses the recursive server will send back in response to our queries.


This style of attack is pretty common with DNS queries, but I’ve also seen UPnP requests and also UDP floods conducted this way. It takes a bit of work finding a quality middle man that will unquestioningly pass on random requests like that, but when you do that server can be weaponize in the manner described above.

For DNS recursion I always liked to use as a quick test to see if a certain server or router is vulnerable to being used in such a way. I’ve seen plenty of end user devices get harnessed into large scale attacks because they were misconfigured by the vendor, which allowed them to be recruited in this kind of attack.

What’s Next?

In part two, I’ll dive into Layer 7/Application Layer attacks! Stay tuned ^_^