2022-03-21 - TRAFFIC ANALYSIS EXERCISE - BURNINCANDLE
2022-03-21 - TRAFFIC ANALYSIS EXERCISE - BURNINCANDLE
SCENARIO
Zip archive of the pcap: 2022-03-21-traffic-analysis-exercise.pcap.zip 4.9 MB (4,942,730 bytes)
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
TASK
- Write an incident report based on the pcap.
- The incident report should contains 3 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.
🧠 Thought Process 🧠
We have been provided details regarding the clients LAN segment to investigate what transpired. So far we have the Domain info, DC, Gateway and Broadcast IP addresses. A quick way to find other hosts on the network would be too look at the endpoint summary. ( Statistics > Endpoints)
We get 10.0.19.14 , and judging by the number of packets, this could be the target we’re interested in. Lets find more info about the host. Using dhcp as my display filter, and inspecting the DHCP Request frame in the packet details pane, we get information that we need. i.e,
- Client MAC address: PERIPHER_b7:33:0f (00:60:52:b7:33:0f)
- Requested IP Address: 10.0.19.14
- Host Name: DESKTOP-5QS3D5D
- Client name: DESKTOP-5QS3D5D.burnincandle.com
We also need to find the User account name of this host. Since the IP is co-joined to a domain (burnincandle.com), we can confirm if we have some kerberos related packets by looking at the protocol hiererachy statistics.( Statistics > Protocol Hiererachy)
Kerberos is a protocol for authenticating service requests between trusted hosts across an untrusted network, such as the internet.
Yeeep, we do. With this in mind, since we know the DC ip, we can throw in a filter like ip.addr == 10.0.19.14 && ip.addr == 10.0.19.9 && kerberos.CNameString and !(kerberos.CNameString contains $) to only display packets containing the CNameString field.
- cname: this section holds the username the client is trying to authenticate. To be more specific, the exact username in this case is “patrick.zimmerman”
Please note that the
CNameStringColumn isnt there by default. I added it manually as shown:
Also, another quick way to find such information, you can use NetworkMiner , an open source Network Forensic Analysis Tool (NFAT).
IOC’s
We can then start looking for any IOCs and try figure out what happened. Looking at HTTP related traffic, we see the victim machine made contact with a suspicious host : oceriesfornot.top on dst IP : 188.166.154.118
I did a lookup on the two hosts : x1.c.lencr.org & ctldl.windowsupdate.com and they seem to legitimately belong to LetsEncrypt & Microsoft respectively. However, oceriesfornot.top looks like its affliated to the Quantum Ransomware
Selecting the frame and following TCP stream, we get an interesting cookie :
Spent sometime researching more on the same and got a hit on sysopfb’s blog where he does some RE on IcedID malware that contained a similar cookie.
He explains that the _u cookie value holds the victims username and computername hexlified. So i used cyberchef to confirm this and indeed we get: DESKTOP-5QS3D5D:patrick.zimmerman:CD2F3B9F67E3C343
Other values have been summarized in the table below:
| Cookie | Value |
|---|---|
| _gid | Based on physical address of NIC |
| _io | Domain identifier from SID |
| _u | Username and Computername |
| _gat | Windows version info |
| _ga | Processor info via CPUID including hypervisor brand if available |
| _gads | First DWORD from decoded config data, flag from inspecting server certificate, a random DWORD or number passed as parameter with -id=, number of processes |
Something else we notice here is the victim seems to be getting a gzip file from the suspicious IP. I used NetworkMiner to extract it.
However, VT didnt pick this up as malicious.
I tried to do some manual analysis on the file and see what i could find but i guess i hit the wall 😩. Back to research , i found out that IcedID uses this technique as the first stage loading mechanism. The Binary Defense Threat Hunting team have a nice technical blog on the IcedID GZIPLOADER . i’d suggest having a look at it.😉
Simply put, IcedID’s gziploader infection chain looks like this:
~Source: Binary Defense Blog
I then proceeded to my third tool, Brim Security to query the packets further. In this case i’m interested in seeing DNS queries with the most counts or suspicious names.
Cleaning this up abit we get the queries and responses.
Now back to wireshark and filtering for dns.a we get 3 other unique query responses, 2 happening in a span of a second. Whats also unique is that both are file sharing websites.
Applying 23.227.198.203 (bupdater.com) as my destination address, i noticed a pattern. Every minute the host seems to beacon/communicate with bupdater[.]com on port 757. C2 traffic? Potential exfiltration? C2 heartbeat activity? Lets find out.
Doing a lookup on VirusTotal , i found several other people having reported it as a Cobalt Strike C2 Server.
Enumeration.
Net (net.exe) commands are often used by attackers and insiders to enumerate target network information, change passwords, and create users. Monitoring for MS-SAMR related activities, allows us to detect and respond to this behavior that is often an important part of attacks such as ransomware.
MS-SAMR (Security Account Manager (SAM) Remote Protocol) supports management functionality for an account store or directory containing users and groups. The goal of the protocol is to enable IT administrators and users to manage users, groups, and computers.
On wireshark, we can filter for this protocol by using samr as our display filter. But for learning purposes, lets first understand the basic flow of the SAMR protocol. (See screenshot below)
- Shortly after our victim is done communicating with
157.245.142.66, we can see SMB connections from the victim to the DC.
- Shortly after our victim is done communicating with
- The second phase is to connect to the IPC$ share on the remote machine. The IPC$ share as you might already know, is used for Inter Proces Communication by using RPC over SMB to allow clients to send different commands to the server to listen users, shares, etc.
- The third phase is to open the SAMR named pipe.
- Fourth phase is to connect to the SAMR interface, which can be recognized by its UUID:
12345778-1234-abcd-ef00-0123456789acas shown below.
- Fourth phase is to connect to the SAMR interface, which can be recognized by its UUID:
Just to make things cleaner moving on, i applied the samr filter to get commands and queries executed. The first two packets, Connect5 request & Connect5 response tends to obtains a handle to a server object. What follows next is abit interesting though.
The attacker seems to be enumerating the Domain, Groups, RIDS etc. Here is a summary of all methods i extracted at the end of my analysis:
- EnumDomains - is used to obtain a listing of all domains hosted by the server-side of the protocol.
- LookupDomain - uses the established context handle to return the SID of a domain object, given the object’s name obtained from the EnumerateDomains method.
- OpenDomain - obtains a handle to a domain object, using the SID returned by the previous LookupDomain method.
- LookupNames - translates a set of account names into a set of RIDs.
- OpenGroup - obtains a handle to a domain object, given a SID.
- QueryGroupInfo
- QueryGroupMember - will query all the members that are part of Domain Admin but will only display the RID.
- LookupRids - Shows the account name of each RID that is a member of Domain Admins.
- OpenUser - obtains a handle to a user, given a RID.
- QueryUserInfo - obtains attributes from a user object using the user object handle
- QuerySecurity
- GetGroupsForUser - obtains a listing of groups that a user is a member of.
- GetAliasMembership - obtains the union of all aliases that a given set of SIDs is a member of.
Sample information gathered about the target and target domain:
Summary of IOC’s collected:
Domains and IP addresses for IcedID (Bokbot):
| Domain | IP |
|---|---|
| oceriesfornot[.]top | 188.166.154.118 |
| antnosience[.]com | 157.245.142.66 |
| suncoastpinball[.]com | 160.153.32.99 |
| otectagain[.]top | 157.245.142.66 |
| seaskysafe[.]com | 91.193.16.181 |
| dilimoretast[.]com | 160.153.32.99 |
Suspicious traffic to file sharing domains:
| Domain | IP |
|---|---|
| filebin[.]net | 185.47.40.36 |
| situla[.]bitbit[.]net | 87.238.33.8 , 87.238.33.7 |
Domains and IP addresses for Cobalt Strike:
| Domain | IP | Port |
|---|---|---|
| bupdater[.]com | 23.227.198.203 | 757 |
Conclusion
I had so much fun analyzing this PCAP, and learnt much on the fly. I would definately recommend checking out Brad Duncan’s Blog. It’s really a great resource for packet capture (pcap) files and malware samples. While you are at it, consider giving him a follow on twitter @malware_traffic for any updates.
If anyone has additional details that i might have missed, or has any feedback to improve my methodology it would be greatly appreciated.
Resources
- Wireshark Tutorial: Identifying Hosts and Users
- Taming Kerberos and making it our loyal companion
- IcedID PhotoLoader evolution
- IcedID GZIPLOADER Analysis
- MS-SAMR: Security Account Manager (SAM) Remote Protocol (Client-to-Server) doumentation
- Detecting Security Events Using the MS-SAMR Protocol
- Analyzing network packets with Wireshark – AD and User Enumeration
Comments powered by Disqus.