BTLO — Pretium
The Security Operations Center at Defense Superior are monitoring a customer’s email gateway and network traffic (Crimeson LLC). One of the SOC team identified some anomalous traffic from Josh Morrison’s workstation, who works as a Junior Financial Controller. When contacted Josh mentioned he received an email from an internal colleague asking him to download an invoice via a hyperlink and review it. The email read:
There was a rate adjustment for one or more invoices you previously sent to one of our customers. The adjusted invoices can be downloaded via this [link] for your review and payment processing. If you have any questions about the adjustments, please contact me.
Thank you.
Jacob Tomlinson, Senior Financial Controller, Crimeson LLC.The SOC team immediately pulled the email and confirmed it included a link to a malicious executable file. The Security Incident Response Team (SIRT) was activated and you have been assigned to lead the way and help the SOC uncover what happened.
Countdown utilises Wireshark to analyse a *.pcap, the capture network traffic from the victim’s machine, and investigate the incident.
1. What is the full filename of the initial payload file?
We’re quickly able to see some files that have been transferred, with a potentially malicious one originating from 192.168.1.9. The batch file extension masquerading as a .pdf is also an indicator.
2. What is the name of the module used to serve the malicious payload?
Exploring the particular traffic a little bit closer and following the HTTP stream / TCP stream, we see that an initial GET request was posted (red), with the HTTP response (blue) and details in the header of the server used to provide the malicious payload. A small amount of googling will confirm the name of the module.
3. From observing the traffic, can you find out what is the attacker machine IP now?
Looking at serving of the payload and subsequent traffic, we are confident that the attacker machine IP is the one providing the malicious file. This is also backed up by the significant amount of traffic between the two hosts.
4. Now that you know the payload name and the module used to deliver the malicious files, what is the URL that was embedded in the malicious email?
We can use all the information we have gathered to determine what the embedded URL was:
HTTP://<AttackerIP>:<Port>/<payload>.pdf.bat
5. Find the PowerShell launcher string (you don’t need to include the base64 encoded script)
There are two ways we can determine the PowerShell launcher string. The easiest way would be to go back to the HTTP stream /TCP Stream which contained the payload. The plaintext of the payload is visible within the packet (left).
Alternatively, return to File-> Export Objects -> HTTP and export the payload as a .txt file (right)
6. What is the default user agent being used for communications?
The payload contains base64 encoded PowerShell code. The easiest way to do this is by copying the encoded text and using CyberChef (gchq.github.io) to decode it. Alternatively use PowerShell to decode.
Generic Code Beautify and Regular expression help in tidying up the output.
Within the PowerShell code, a hardcoded User Agent can be located.
7. You are seeing a lot of HTTP traffic, what is the name of a process where malware communicates with C2 server asking for instructions at set time intervals?
The answer to this isn’t found within the investigation lab, however some googling should be able to inform this.
Alternatively: QmVhY29uaW5n — (base64 encoded)
8. What is the URI containing ‘login’ that the victim machine is communicating to?
Other than searching through the subsequent communications from the victim to attacker machines, or filtering down on http.request.method, search for the string ‘login’ to see if it is part of the URIs in the communication.
9. Can you name the post-exploitation framework used for C2 communication now to our victim machine?
Now we have a bit of an understanding to of the payload, PowerShell code, and related network activity, we can build some IOCs (Indicators of Compromise) and use these to research what the post-exploitation framework is.
Some key IOCs which might help:
- get.php
- news.php
- process.php
- The default User Agent string
- Other notable static strings from the PowerShell code.
10. Using some Blue Team Magic, can detect data exfiltration and find out what have been exfiltrated? Provide the decoded password.
Towards the end of the .pcap, we se a LOT of ICMP (ping (networking utility) — Wikipedia) traffic in very quick succession (milliseconds). Further, a standard ping packet is 32bytes of data, whereas these are 43bytes and 60bytes for request/reply respectively.
Scrolling through these, the last character of each packet changes for each request, and inspecting the last couple, these are ‘==’, a tell-tale sign of padding for a base64 encoded command. We already know the attacker likes base64 encoding.
I went over to tshark — The Wireshark Network Analyzer 3.4.4, Wireshark’s CLI, which I found easier to extract all of the data from these ping packets.
Read in the .pcap, print fields for the attacker’s machine (this will show the ICMP reply (the same data as the victim’s request) towards the bottom) into a .txt file.
C:\Users\BTLOTest\Desktop\Investigation> tshark.lnk -r
C:\Users\BTLOTest\Desktop\Investigation\LAB.pcap -T fields -e data
ip.src==192.168.1.9 >> data.txt
Scroll towards the bottom of the file and find the column of two characters. This is data transmitted in the ICMP reply, but in hex format. Verify that this is the same data as found in the packets in Wireshark. (eg, 3d is hex for =)
Take this data (not the whole file) and paste into CyberChef.
Convert the string from hex, base64 decode it, and then add the Regular Expression filter to clean up the output.
The output shows the password for the user account.
11. What is the account’s username? (Include $ at the beginning)
Use the same decoded output from the previous question to identify the account’s username. $<Username>
Analysing the .pcap, we were able to identify the malicious payload and attacker machine/IP address, as well as the URL in the phishing email.
Further analysis of the pcap provided clarity on the post-exploitation framework used by the attacker, as well as uncover data that has been exfiltrated.
Leave a comment if you extracted the data from the IMCP packets in a different way!
