Onto a new site this week! CyberDefenders hosts challenges of the cyber defence theme and it’s a great place for analysts, defenders and DFIR folk to practice their skills and learn new ones as well.
Diving right into it, we’ll download the pcap file and open it up in WireShark.
Q1 – What is the attacker’s IP address?
In Wireshark we’ll open up the ‘Conversations’ window which lives under the ‘Statistics’ menu. Here we can see the communication between IP addresses and by looking at the flow we can see the attackers IP is 98.114.205.102
Q2 – What is the target’s IP address?
From the same screen above we can see the target’s IP is 192.150.11.111
Q3 – Provide the country code for the attacker’s IP address (a.k.a geo-location).
Copying the attacker’s IP into a GeoIP lookup tool (I used the awesome ultratools.com for this) gets us the answer for this question – US
Q4 – How many TCP sessions are present in the captured traffic?
Still working with the Conversations window open in Wireshark we can see the TCP tab at the top with the sessions listed – 5
Q5 – How long did it take to perform the attack (in seconds)?
Scrolling to the bottom of the capture we can see the timestamp on the last packet – to answer this question we rounded down to the closest second – 16
Q6 – What is the operating system of the target host?
Windows XP – We can see in Packet 16 where the target is responding to the SMB request that the Native OS is listed as Windows 5.1, this being the Microsoft build number for Windows XP
Q7 – Provide the CVE number of the exploited vulnerability.
CVE-2003-0533 – looking at the initial communication in Stream 1 a few things stood out. Packet 38 has in the description field a ‘DsROLEUpgradeDownLevelServer’ response – a quick google led me to CVE-2003-0533. A buffer overflow in the LSASS function allowing attackers to execute arbitrary code. Famously exploited by the ‘Sasser’ worm.
Q8 – Which protocol was used to carry over the exploit?
SMB – We can see from the traffic that SMB is the initial entry vector here in setting up the malware to be downloaded.
Q9 – Which protocol did the attacker use to download additional malicious files to the target system?
FTP – Looking at the TCP Streams in Wireshark is a great way to visualise the packet flow better. In stream 3 we can see what looks like a standard FTP login sequence in plain text. Logging in with the username and password of ‘1’ and then downloading the ‘ssms.exe’ file complete with a cheeky sign off message!
Q10 – What is the name of the downloaded malware?
ssms.exe – We answered this already in the previous question. Noting here that this is also the name of a legitimate Windows executable file (SQL Server Management Studio). This is a common tactic that malware creators use in an attempt to stay hidden.
Q11 – The attacker’s server was listening on a specific port. Provide the port number.
We can see in Stream 2 the commands used to setup the attack. The port being opened is 8884
Q12 – When was the involved malware first submitted to VirusTotal for analysis?
By switching over to TCP stream 4 we can see a whole bunch of data being sent from the attacker’s IP to the target. This must be the malware being downloaded. We can use the ‘Save As’ button on the button to export the RAW bytes as an executable file. When uploaded to VirusTotal we see it being flagged.
First submission date was 2007-06-27 08:47:05
Q13 – What is the key used to encode the shellcode? & Q14 – What is the port number the shellcode binds to?
Malware reversing is not a strong point of mine so I had to google this one extensively. and download a few new tools in the process. Unfortunately I didn’t come up with much in the way of helping myself tackle this but I did find a walkthrough on the same challenge here
Answer 8 in this writeup goes into the unpacking of the code to provide the answers as 0x99 and 1957 respectively.
Q14 – The shellcode used a specific technique to determine its location in memory. What is the OS file being queried during this process?
kernel32.dll – This answer presented itself as part of the VirusTotal scan under the ‘Behaviours’ tab. I also stumbled across the same answer in my attempts to reverse the file using the ‘OllyDbg’ tool.
This was a tricky one! But a good challenge. I have to give lots of credit to authors of the abovementioned writeup for assisting with a few of those questions. I did manage to follow along with their process after the fact and liked their very thorough reporting style. For all the defenders out there I’d recommend taking a look at the other challenges at CyberDefenders!
Secure N0thing 