Burnincandle (Malware Traffic Analysis)
SCENARIO
LAN segment data:
- LAN segment range: 10.0.19.0/24 (10.0.19.0 through 10.0.19.255)
- Domain: burnincandle.com
- Domain controller: 10.0.19.9 - BURNINCANDLE-DC
- LAN segment gateway: 10.0.19.1
- LAN segment broadcast address: 10.0.19.255
Topology (Based on the information we currently know):
TASK
- Write an incident report based on the pcap.
- The incident report should contain three sections:
- Executive Summary: State in simple, direct terms what happened (when, who, what).
- Details: Details of the victim (hostname, IP address, MAC address, Windows user account name).
- Indicators of Compromise (IOCs): IP addresses, domains, and URLs associated with the infection. SHA256 hashes if any malware binaries can be extracted from the pcap.
Structure of Incident Report:
Summary:
Who:
When:
What:
Details (Details of the victim):
Hostname:
IP Address:
MAC Address:
Windows user account name:
Indicators of Compromise (IOCs):
IP Address:
Domain:
URLs associated with infections:
Hashes:
Gather our Information
First, I would go for the low-hanging fruits. So the place I would go is my alerts. See what triggered the IDS/IPS or maybe the firewall.
As we can see, we have too many columns that have information. So what will happen next is to pick out the essential columns.
Query: event_type=="alert"
I narrow down the alerts that categorize the traffic as “Potentially Bad Traffic.”
Query:
event_type=="alert" | cut event_type, src_ip, src_port, dest_ip, dest_port, alert.signature, alert.category | alert.category=="Potentially Bad Traffic"
We can see numerous 10.0.19.9 (dest_ip), but that IP is our domain controller. So it is likely to be a false positive.
Let’s pay attention to 10.0.19.14 -> 188.166.154.118. It is an HTTP request that is beyond our subnet.
But when I click on the log details, no other information is shown. Maybe it’s because I narrowed it down to the deep and brim but couldn’t find any connection.
So what I did was go back to the original query: event_type=="alert" and adjusted our filter. This time, this was the query I was using:
|
|
Look at that; We found our lead. Let’s say on our first time, and we didn’t see this alert. You can click on any packet to see if there is any related information that goes with this packet.
When I saw this, I was like, wait a min. I think I miss something. Let me go back.
So now we know our potential victim: “10.0.19.14” and attacker: “188.166.154.118”
Using a Malware: WIN32/IcedID
Computer affected: [Windows_XP_Vista_7_8_10_Server_32_64_Bit]
We could also use the HTTP requests to see what the hacker was trying to get.
As we can see, there was an HTTP request going to oceriesfornot.top.
|
|
We could use an OSINT tool to see the reputation of this domain (oceriesfornot.top).
If we go back to a more general query:
|
|
I saw the uid variable, which I want to keep track of. (ClYzIQ3GTS4RoSbsn5)
Then, I see some information that is related to each other.
Now, I want to look at the file log. Why? I want to see the hash file of the malware when it was downloaded.
Query: _path=="files"
We are presented with this.
So, I’m not sure what column is related to UID. So, I’m thinking of putting the UID in the search bar and seeing if it filters from there.
There we go. We got a hit.
Look at the tx_host and rx_hosts.
The tx_host = Host or hosts data sourced from.
The rx_host = Host or hosts data traveled to.
As we can see, the file traveled from 188.166.154.118 (Attacker) to 10.0.19.14 (Victim), and we got the md5/SHA1 hash of the file. The file type is a gzip.
md5: 792ec837418da54679ac01a9b8c9f257
sha1: d5134cd34207addf6b483bdb39a24fbf847b1623
I think it helps to note the fuid in case we need it later in the investigation. (FdoWadVWSioXcZSua).
When we tried to search for the hash on the virus total, we got a 0/61, and it wasn’t flagged as a malicious file. However, when we went to details and under the Names section, there was: IcedID_Malware2.gz. I couldn’t afford to sign it off.
Not only that, when unzipped, we got a Copper.txt from the file.
Out of curiosity, I found that 188.166.154.118 was flagged on the AbuseIPDB.
Now, at this point, for me, the trail is becoming cold. At this point, I’m looking at the Activity overview, seeing what other information I could look at, and doing a recap of what I have.
Incident Report:
Summary:
Who:
- Victim: 10.0.19.14
- Attacker: 188.166.154.118
When:
- 2022-03-21T20:58:11.609747Z -> 3:58 pm (est) on March 2022
What:
- Suricata detected a Network Trojan was detected from 10.0.19.14 to 188.166.154.118 and classified the malware as WIN32/ICEDID
- It looks like a user clicked on a link to the domain (oceriesfornot.top) flagged as untrusted on Cisco Talos. Downloaded a file called index.gzip, which was not flagged as malicious on VT but had names of ICEDID_Malware2.gzip. Inside that folder, you can find Copper.txt
Details (Details of the victim):
We can see this information by using the “NTLM” log
We can also find the data by using the “DHCP” log
Hostname: DESKTOP-5QS3D5D
IP Address: 10.0.19.14
MAC Address: 00:60:52:b7:33:0f
Windows user account name: DESKTOP-5QS3D5D.burnincandle.com
Domain: mshome.net
Indicators of Compromise (IOCs):
IP Address: 188.166.154.118 (Attacker)
Domain: (oceriesfornot.top)
URLs associated with infections: http://oceriesfornot[.]top/
Hashes:
MD5:
792ec837418da54679ac01a9b8c9f257
SHA-1:
d5134cd34207addf6b483bdb39a24fbf847b1623
SHA-256: ac64292e91738bf97842e7e5d28373a3a52bdb0aa2bc48a0df512e34d1b41501
I believe that is all we can find. Let’s go and see if our answer is correct by going here: https://www.malware-traffic-analysis.net/2022/03/21/page2.html
Good news: We got the details right and the summary.
Bad news:
There were a lot of IOCs that I miss 😅
Things to take away:
- Don’t forget to look into HTTPS traffic (in the brim, it’s SSL)
- Not all malicious traffic will be in HTTP
- Don’t be afraid to look up the DNS name that was queried.
- Use OSINT tools like VirusTotal, AbuseIPDB, urlhaus.abuse.ch
- Don’t forget you can look up the IP in the virus total. It is not always about the hashes.