A PCAP analysis exercise highlighting attacker's interactions with honeypots and how automatic exploitation works.. (Note that the IP address of the victim has been changed to hide the true location.)
Information
Category Name: HoneyBOT
Files:
c29-HoneyBOT.zip 154 KB
– HoneyBOT.pcap 189 KB
My Recommendations
It’s all we need to solve the challenge:
wireshark -v
Download it from CyberDefenders and verify it with:
sha1sum /path/to/c29-HoneyBOT.zipSHA1SUM: d9368027a7e19518ab91b8f04b47fbde1386d6da
Walkthrough
1. What is the attacker's IP address?
Using the Statistics –> Protocol Hierarchy option, we can see that there was an Active Directory set-up under the SMB protocol:
I found an article online explaining the use of Honey Pots in conjunction with Active Directory.
Now, filtering the pcap with smb, and looking at the frame containing the Active Directory Setup, the request was done by IP 98.114.205.102:
Answer: 98.114.205.102
2. What is the target's IP address?
Above, we saw that the request was issued to IP 192.150.11.111.
Answer: 192.150.11.111
3. Provide the country code for the attacker's IP address (a.k.a geo-location).
We can use an online tool, like ip2location, to find the geo-location of the attacker’s IP Address:
Answer: US
4. How many TCP sessions are present in the captured traffic?
Going into Statistics –> Conversations, there are 5 TCP sessions in the captured traffic:
Answer: 5
5. How long did it take to perform the attack (in seconds)?
The last frame number is 348. We can use the filter: frame.number == 1 or frame.number == 348 and substract the difference:
The attack started at 03:28:28 UTC and ended at 03:28:44 UTC.
44 – 28 equals 16.
Answer: 16
7. Provide the CVE number of the exploited vulnerability.
In the first question, we saw that the attacker issued a DsRolerUpgradeDownlevelServer request, which kick started the attack. Looking in Google for details “CVE DsRolerUpgradeDownlevelServer ” points to CVE-2003-0533, summarized as:
Stack-based buffer overflow in certain Active Directory service functions in LSASRV.DLL of the Local Security Authority Subsystem Service (LSASS) in Microsoft Windows NT 4.0 SP6a, 2000 SP2 through SP4, XP SP1, Server 2003, NetMeeting, Windows 98, and Windows ME, allows remote attackers to execute arbitrary code via a packet that causes the DsRolerUpgradeDownlevelServer function to create long debug entries for the DCPROMO.LOG log file, as exploited by the Sasser worm.
Answer: CVE-2003-0533
8. Which protocol was used to carry over the exploit?
As identified through the CVE and the nature of the attack, it was carried over SMB.
Answer: SMB
9. Which protocol did the attacker use to download additional malicious files to the target system?
Moving on to the next TCP stream, and Selecting Follow –> Tcp stream we will see the command that the attacker issued:
The attacker used FTP to download malicious files to the system.
Answer: ftp
10. What is the name of the downloaded malware?
The command issued in tcp stream 2 downloads a file named ‘ssms.exe’:
Answer: ssms.exe
11. The attacker's server was listening on a specific port. Provide the port number.
In tcp stream 2, we saw that the attacker downloaded malicious files to the machine. But first, a command to listen to port 8884 was issued.
If we look into Statistics –> Conversations, we will see that it was successful, as 27 packets were transferred over this port:
Finally, if we filter for tcp.port == 8884, and follow the tcp stream (stream 3), we can see that it is the stream which downloaded the malicious file to the system:
Answer: 8884
12. When was the involved malware first submitted to VirusTotal for analysis?
Format: YYYY-MM-DD
TCP Stream 4 contains the actual file:
We can use Follow –> TCP Stream and then save it (in Raw mode) for further analysis.
md5sum Malware.bin
#returns 14a09a48ad23fe0ea5a180bee8cb750a
Searching for the Hash on Virus Total shows that it was first submitted in 2007:
Answer: 2007-06-27
13. What is the key used to encode the shellcode?
The CVE corresponding to the exploited vulnerability, relies on a buffer overflow attack. If we filter the pcap for SMB, we can see its process:
In pink, is the request and response for DCE/RPC. This is basically how the arbitrary code is ‘allowed’ to be sent over, and exploit the DsRolerUpgradeDownlevelServer function. Thus, the shellcode must be between frame 28 and 33. Frame 29 contains suspicious data:
We can save it as Raw and examine it further with scdbg using the options ‘FindSc’ and ‘Unlimited steps’. Then, at the prompt select 1 -> offset=0x12e. It will successfully run the shellcode:
In pink, the cwd is actually the xor key used to decode the shellcode. It also makes sense given that the raw data showed many ‘90909090’ bytes, which would indicate xor behavior.
Alternatively, we can use sctest. First, we grab all the bytes after ‘eb10’, which is where the xored data begins (first occurance of non 9090 bytes after the SMB Header and SMB Pipe Protocol:
xxd -p shellcode.bin | grep 'eb10' -A 1000 | xxd -r -p > shellcode
sctest -S -s 10000 -vv < shellcode
We get a similar output, but with direct reference to the xor operations.
Answer: 0x99
14. What is the port number the shellcode binds to?
In the output of Scdbg, the port that the shellcode binds to is port 1957:
Answer: 1957
15. The shellcode used a specific technique to determine its location in memory. What is the OS file being queried during this process?
The shellcode uses multiple calls to GetProcAddress, which is a function of Kernel32.dll.
Answer: kernel32.dll
TLDR
– This challenge is an insight into CVE-2003-0533 and the SMB protocol.
– The exploited system receives an executable – over FTP and shellcode – over SMB.
