I found this forensics challenge while doing research for work and thought it should be fun (you can find it here). It’s a 3-part challenge so it should keep me busy for a couple of posts.
The first evidence file is a network packet capture of the attack. By default, I’ll be using Wireshark, and maybe NetworkMiner if needed. And now, for the questions:
Which systems (i.e. IP addresses) are involved? (2pts)
You can find the answer to this question through a variety of windows in Wireshark under the Statistics menu, including Conversations, Endpoints, IPv4/IPv6 Statistics and more. To get an overview, I like the TCP tab in the Endpoints Window:
So the answer to this question is the two IPs 98.114.205.102 and 192.150.11.111.
What can you find out about the attacking host (e.g., where is it located)? (2pts)
In order to understand which system is attacking, we have to look at what protocols are at play on the different ports and what the conversations look like. After a cursory look through the protocols, we see use of the SMB (Server Message Block) protocol, which could indicate that an SMB exploit was used. There are other protocols at play here, but SMB happens to be critical to how this exploit happens.
We can view only SMB packets using a filter in Wireshark (we could just follow the stream of any of the SMB packets, but there could be multiple streams):
Since 98.114.205.102 initiates the Negotiate Protocol Request, I’m inclined to think it’s the attacker. We can reinforce this prediction later. As for where the attacker is located, we can use WHOIS to get some information, but unless a function called GeoIP works in Wireshark, we can only get the Domain Registrar, which could be bogus or hidden:
So from Whois we get the registered organization, Verizon, but have no clue where the attacker may have been (especially if they’re just using a Verizon access point). Let’s give GeoIP a try:
Well isn’t that cool. I have no idea whether these GeoIP databases were up-to-date with the actual devices. I also don’t know how GeoIP works, but this is super nice. Let’s say the attacker was in Philly then.
How many TCP sessions are contained in the dump file? (2pts)
Another easy one; just use Statistics > Conversations and click on the TCP tab to see that there are 5 sessions.
How long did it take to perform the attack? (2pts)
Well, this challenge is a great way to learn Wireshark. The challenge writers made it easy for us by only including the attack. In this case, we can use Statistics > Captured File Properties to look at Elapsed Time, or just look at the time of the last packet in the capture: the attack took around 16.2 seconds.
Which operating system was targeted by the attack? And which service? Which vulnerability? (6pts)
To answer this question, let’s head back to the SMB packets in Wireshark. A couple of packets in the SMB filter stood out:
The presumed attacker connects to the IPC share on 192.150.11.111, which allows anonymous null sessions. This is a feature of Windows which facilitates writing to named pipes. Named pipes are data pathways to and from running processes. In this case, writing to the named pipe lsarpc allowed the attacker to leverage DSSETUP, an Active Directory Tool.
The attacker used DSSETUP to call the function “DsRoleUpgradeDownlevelServer,” which looks suspicious in itself. If we take a close look at that packet, especially at the 3 Reassembled TCP Segments, we see a bunch of 0x90 bytes followed by some bytes that look a bit like code. At the end of the TCP segments there are a bunch of ASCII “1” bytes.
From experience, this looks like a buffer overflow. Meaning that the DsRoleUpgradeDownlevelServer call can be exploited by sending a large buffer of “1” characters, then inserting an address or assembly command to jump to the code. The 0x90 bytes are NOP instructions in Assembly, which do nothing but advance the instruction pointer. Having a “NOP Sled” is common in stack-based exploits when it’s unclear where the attacker’s jump will land. Regardless of where the jump lands in the NOPs, they lead to the exploit code.
Google searching something like “DsRoleUpgradeDownlevelServer buffer overflow” is a good way to confirm our suspicions. But instead of running down this lead all the way and potentially spoiling the whole surprise, let’s try to answer the question:
The buffer overflow vulnerability exposes Windows systems through XP (got that from the NVD), and it appears that a person can gain remote access to Active Directory by writing to the lsarpc named pipe. This pipe handles Remote Procedural Calls for the Local Security Authority Subsystem Service (hence the LSA and RPC in lsarpc). Therefore, we can conclude that the vulnerability is in LSASS.
Can you sketch an overview of the general actions performed by the attacker? (6pts)
Of course, there should be more to this case than the exploit. The attacker had to use the exploit for some further goal. Let’s follow the next stream of TCP activity, which has some interesting activity:
In summary, once the attacker has remote code execution, they write some commands to a file called ‘o’, execute the commands in ‘o’ with ftp, delete it and execute a file. Basically, the attacker is making a downloader so that the victim machine retrieves and executes their second stage, ssms.exe. We can confirm that this actually happens by looking at the next stream, which the victim initiates:
And that’s it! it downloads the second stage and that’s the last packet. There’s our outline; next question:
What specific vulnerability was attacked? (2pts)
Hmm, this seems like a repeat question; I’m unsure if this is asking about the lsass exploit or something else. For now, I’ll just drop the CVE we found as the answer to this question (CVE-2003-0533) and we’ll move on to the next.
What actions does the shellcode perform? Pls list the shellcode. (8pts)
Okay, in order to figure out how the LSA service was exploited, we need to look at that buffer overflow again. The packet in which the attacker calls DsRoleUpgradeDownLevelServer contains bytes that look like this:
This is a little introduction to memory exploitation. Again, the 0x90 bytes around the shellcode are NOP sleds. The shellcode writer uses them to lead to the shellcode and to fill stack space. Further down in the packet, you have the multitude of 0x31s that make up the buffer overflow. The order of the exploit is something like: Buffer Overflow > NOP sled > shellcode > NOP sled. Now that we’ve identified the shellcode, I’ll take it to one of my favorite tools for these situations: scdbg.exe, the shellcode debugger.
I didn’t know much about this tool until I started using it for triage in my new job. It’s incredibly helpful when you have access to shellcode, especially when it’s auto-generated or obfuscated by Metasploit or similar frameworks. Be sure to export the specific bytes of the shellcode for it to work; the NOPs and buffer will probably cause scdbg to fail.
Anyways, scdbg gives us some function calls that tell us everything we need to know (minus some understanding of the Windows API, if you’re unfamiliar). The shellcode creates a bind shell using socket functions from Ws2_32.dll. The bind shell listens on port 1957 and spawns a command shell when it receives a connection.
Do you think a Honeypot was used to pose as a vulnerable victim? Why? (6pts)
This is a pretty difficult question, even in 2009, honeypots were able to emulate SMB functionality quite well. I would say that the honeypot would have to be able to execute shell commands and download files, which is a bit more full-featured than low-interaction honeypots. It’s certainly possible today. The only reason I’d lean toward this possibly being a honeypot is that the attacker’s initial logon gave a null user but the victim still allowed an SMB session:
It’s a toss-up for me, so I’ll say it is a honeypot.
Was there malware involved? Whats the name of the malware? (We are not looking for a detailed malware analysis for this challenge) (2pts)
Well, it certainly looks like malware was involved, but we should grab the executable to be sure. I’ll probably reverse it, but the hash and the name of the malware family shouldn’t spoil anything if I don’t read the writeups :).
I usually prefer using NetworkMiner to pull executables because copying/saving the bytes from Wireshark can be buggy, but in this case Wireshark worked out great! We follow the stream as soon as the malicious server starts transmitting smss.exe, which looks like this (Raw on the left, ASCII on the right).
We can save the executable by using “Save as…” while viewing the data in Raw mode. You’ll want to make sure you don’t execute it outside of a VM, though.
After searching the hash (14A09A48AD23FE0EA5A180BEE8CB750A) and doing a bit of research, we find that the smss.exe is actually an SDBot sample, part of a family of backdoors operated by IRC (Internet Relay Chat). Which brings us to the next question:
Do you think this is a manual or an automated attack? Why? (2pts)
IRC is great for managing a number of hosts, and is often automated, especially in IRC-controlled botnets. We combine this information with the fact that none of the attack seemed user or domain-specific. The login was anonymous and the commands written to ‘o’ for FTP were also scripted. Finally, the fact that the entire compromise happened in 16 seconds makes it clear that this is probably a worm that automatically propagates using vulnerable shares.
Well, that’s all the questions! This took me forever to write up, but I definitely came away knowing a bit more; even though this is an old example, it’s one I haven’t seen. I’ll look ahead at the next challenge and decide whether I want to reverse this executable or keep going. Thanks for reading.