This project documents a network traffic analysis lab focused on identifying unusual behavior and potential Indicators of Compromise (IoCs) associated with Wikiloader malware.
Using Wireshark, I examined packet captures from a compromised system to investigate suspicious communications, identify potentially malicious infrastructure, and trace post-infection command-and-control activity.
The packet capture analyzed in this lab was:
2024-01-17.pcap
The goal of this investigation was to:
- Analyze traffic from an infected host
- Identify suspicious HTTPS, DNS, and MQTT activity
- Extract possible Indicators of Compromise (IoCs)
- Understand how malware communicates after infection
- Wireshark
- PCAP analysis
- HTTPS filtering
- TLS handshake inspection
- DNS analysis
- MQTT traffic inspection
The investigation focused on multiple stages of malicious network behavior:
- Identifying suspicious HTTPS traffic
- Inspecting TLS handshakes and the SNI field
- Looking for repeated DNS queries that may indicate persistent communication
- Identifying post-infection command-and-control (C2) activity over MQTT
To identify possible delivery infrastructure for the malicious payload, I filtered the traffic to show HTTPS communications over port 443.
tcp.port == 443
Packet #320 showed Application Data with a source IP address of:
104.21.3.175
Filtering HTTPS traffic helped isolate encrypted communications that may be related to the initial payload delivery or follow-on malware activity.
TLS handshake analysis can reveal valuable metadata even when the payload itself is encrypted. In particular, the Server Name Indication (SNI) field can show the hostname the client attempted to contact.
tls.handshake.type
The last server the infected system attempted to establish a secure connection with was:
thichgiban.com
Although TLS traffic is encrypted, handshake metadata can still reveal suspicious destinations and provide useful indicators during malware analysis.
Repeated DNS queries can indicate persistent communication between malware and attacker-controlled infrastructure.
To identify this behavior, I reviewed DNS-related traffic and looked for repeated domain activity.
dns.cname
The domain that appeared to show repeated DNS queries was:
broker.emqx.io
Frequent DNS lookups for the same domain may indicate beaconing behavior or continued attempts to reach external infrastructure.
After the initial infection, malware often communicates with a command-and-control server to receive instructions, exfiltrate data, or download additional payloads.
In this lab, I filtered for MQTT traffic to identify possible C2 activity.
mqtt
The IP address associated with MQTT-based communication was:
54.146.113.169
The use of MQTT is notable because malware sometimes leverages less commonly monitored protocols to blend in with legitimate traffic and evade detection.
104.21.3.17554.146.113.169
thichgiban.combroker.emqx.io
- HTTPS / TLS
- DNS
- MQTT
- Suspicious HTTPS traffic was identified over port 443
- TLS handshake analysis revealed a suspicious server name indication
- Repeated DNS lookups suggested persistent external communication
- MQTT traffic indicated possible post-infection command-and-control activity
This lab reinforced the importance of examining not only packet contents, but also protocol metadata such as TLS SNI fields, DNS behavior, and uncommon protocol usage.
Even when traffic is encrypted, analysts can still uncover meaningful indicators by correlating activity across multiple protocols.
- Packet capture analysis
- Wireshark filtering
- Threat hunting
- Network traffic investigation
- Malware communication analysis
- Indicator of Compromise identification
- Protocol analysis across HTTPS, DNS, and MQTT
Jhonatan Martinez
This project was created to demonstrate practical skills in network traffic analysis, malware investigation, and Wireshark-based threat detection.