This is Lab 1.1 for the SEC511 Class
In this lab, I will be using Security Onion and little bit of Wireshark as well. The goal of the lab is to get some familiarity with the classic flow of traditional service side attack. We will also see some evidence of both Exploitation and Command and Control.
I am given a date stamp for this exploit but looking at Security Onion’s Alert menu there are no Date Stamp listed there. Everything is grouped by the name of the alert and the name of the module that triggered the alert:
To see more details, I am first going to click “Ungroup”
Now, it is going to show us some additional fields:
I can use the Timestamp field to look at the date we are looking for or I can use the search tab to search for a specific date:
3 alerts were generated on that day:
Given the rule names that were triggered, it looks like the service that was compromised is SSH. To determine the attacker and victim IP addresses, I can expand these alerts. Looking at the first alert, we have a Destination IP address and Port of:
And the Source IP and Port are:
It is weird that the source port is 22 as I would expect it to be the source port in this exploit. Looking at the alert rule:
I see alert ssh $HOME_NET. The alert is coming from the network we are trying to protect (HOME_NET). The source IP is therefore the victim IP while the attacker IP is the destination IP. Looking at the second alert (the one named ET exploit), I see these same two IP addresses.
Now, I have to identify the stage 2 executable download. After the adversary successfully exploited the SSH service, they usually want to expand their capabilities to. Pushing an executable to a compromised box that could do C2 and persistence or keystroke logging, is one of the ways for attacker to achieve this goal. The third rule in Security Onion is called ET info Executable. Expanding this rule, I see the same IPs involved but it is a different session from the first two rules (the source and destination port numbers are different). To look at the packet itself, I can left-click on the alert, click on the Actions menu and select PCAP:
We see the victim IP address (192.168.225.204) reaching out to the attacker IP address on an unexpected port (5115)
Switching to Wireshark to analyse this packet, we can follow the TCP stream to get a better understanding of what is going on from a payload perspective.
Nothing really sticks out looking at the payload. If i switch from ASCII to an Hex Dump:
I can quickly find the signature that triggered the alert. This is our .elf executable file. Now, I have to carve it. To do this, in Wireshark, I am going to save what the server (the attacker) sent:
and I am going to change the format to Raw and then save the file:
All the data in this file is not of interest as we only care about carving the executable. We can use Bless to remove the data located before the executable.
From our alert, I know that the executable starts at 7F 45:
I can delete all the data located before simply by highlighting it and clicking on delete:
I can this as a file again. To make sure the file we saved correspond to our executable, I can use the file command in Linux:
It is indeed a ELF file and I can scan it with clamscan:
It tells us that this a Unix Trojan executable.
The lab’s last question is regarding the identification of C2 traffic. I am looking for communication during this same time frame. This network traffic was not associated with an actual alert. Once thing I can use in Security Onion that could help with this is the Hunt menu. If I left-click on the victim IP address, select action and click Hunt:
The Hunt screen is going to give a lot more details regarding events associated with this IP address on this day:
We first see the ssh exploitation in this events list with the attacker IP address interacting with our victim over port 22.
Going down this list, we see a second session corresponding to the ELF file download:
After this, I see something different were the compromised system reaches out to the attacker IP address on port 8888:
I see that one of these events comes from the Zeek.ssl data set which means that Zeek identified it as a TLS encrypted communication which would make sense for C2 traffic as it often occurs over a TLS channel.
Leave a Reply