Hate your antivirus (AV) solution? You are in luck! Earlier this month we announced Traps v3.4, the next step in the evolution to replace traditional antivirus software.
This release includes several major features that enable you to take the plunge to eliminate traditional antivirus.
Trusted Signers
To ensure your legitimate files are never prevented from executing on the endpoint, Traps advanced endpoint protection now evaluates whether files are signed by a trusted signer. The list of trusted signers is based on the official trusted signer list in WildFire. That means executable files that are signed by trusted signers are exempt from additional analysis and verdict evaluation. This feature is useful in situations where unknown executable files, such as new software updates for the operating system or for applications, are signed by a trusted signer but have not, yet, been analyzed by WildFire.
Local Analysis
Local analysis uses a statistical model that was developed using machine learning on WildFire threat intelligence. Traps uses local analysis to examine hundreds of characteristics associated with an unknown executable file to determine if the file is likely to be malware. With this feature, Traps quickly analyzes and assigns a local verdict to an unknown executable file when the endpoint is offline or while waiting for the official verdict from WildFire. Traps continues to use the local verdict to block or allow the execution of the unknown executable file until the agent receives an updated verdict from the ESM Server.
Malware Remediation
Traps now takes malware protection one step further with a new capability to transparentlyquarantine malicious executable files on the endpoint. To determine if an executable file is malicious and should be quarantined, Traps uses information from the following sources: WildFire threat intelligence, local analysis, and hash control policy. When malware is identified, Traps notifies the user about the quarantined file (if you enabled user alerts), removes the malware from the local folder or removable hard-drive, and stores the file in a local quarantine folder. With this feature, you can also restore a quarantined file to its original location.
Want More?
Here are a few resources to add to your Traps v3.4 reading list!
New Features Guide: Your go-to resource for all the new features in Traps v3.4.
Administrator’s Guide: Contains installation procedures and configuration workflows to get you up and running quickly.
Release Notes: Provides important information about the Traps advanced endpoint protection v3.4 software including known issues and limitations.
Pro tip: On the documentation search, use the facet to filter results for only documentation about Traps v3.4.
Threat intelligence involves learning about new attacks, adversaries, campaigns, and malware families through distinct pieces of information often referred to as indicators of compromise, or IOCs. The more we make relevant information available to network defenders, the better the odds are that they will find answers to their questions. One key consideration for leveraging threat intelligence to improve an organization’s security posture is that it must be readily able to enforce new prevention-based controls.
Threat intelligence has traditionally been used by security operations centers’ incident response teams. As security awareness in organizations of all sizes begins to expand, most people realize that they want to know which alerts should be made a priority and which threats the organization is subject to. Who are the threat actors? There is a big difference between commodity and targeted attacks. Answering these questions can lead you to implementing new controls that allow you to better secure the environment.
Enter AutoFocus. AutoFocus is the Palo Alto Networks threat intelligence service, which provides a window into billions of samples and threat artifacts collected from and correlated within our Threat Intelligence Cloud, including results from global WildFire data. The information allows security teams to quickly identify targeted that’s and pivot to relevant IOCs quickly, accelerating their analysis and response workflows. AutoFocus complements the Palo Alto Networks Next-Generation Security Platform, enabling searches from your Palo Alto Networks appliances into AutoFocus, or from AutoFocus into your Palo Alto Networks appliances. There is also an API that interacts with the data and feeds third-party security solutions. This level of usability means that a threat research team isn’t necessary to make use of the data. Anyone responsible for handling security incidents in the environment can make use of the data in AutoFocus.
In this post, we will explore a use case that will enable security operators to quickly identify what happened during an incident and to take action.
Searching From AutoFocus
Unit 42 is the Palo Alto Networks threat intelligence team that provides AutoFocus users access to world-class human intelligence, even if they don’t have a research team of their own. Unit 42 contributes to the AutoFocus community by researching malware families, campaigns, adversaries, exploits and malicious behaviors, and by compiling indicators of compromise into durable tags to identify malicious events.
To get started, it may be interesting to navigate through some of the research already done by Unit 42. Let’s assume Locky is something we have not investigated yet. By selecting this tag, we can get information about the research done by Unit 42 on this malware family.
Drilling into Locky provides us with all the search attributes associated with this tag. We can see that Locky is a ransomware payload, which is used to encrypt sensitive files or systems, then hold them until the victim pays the attacker. We also see that Locky is typically dropped byDridex actors, which gives us a better idea of who is likely to be behind the attack. Ransomware is typically more of a commodity type of crime, in which the attacker’s goal is to get as many systems encrypted as possible, driving profits from their malicious activity.
Selecting “Add Tag” to “Search” will bring up the results of a query that includes samples, sessions, statistics, and much more information about the malware. You can search through samples of data that came from devices owned by your organization via WildFire. You can also see samples made public by other organizations, dramatically broadening the lens.
This allows you to gain visibility into threats not directly observed by your organization, taking advantage of the community of WildFire and AutoFocus users. In this case, we will pivot into “Public” samples to further analyze the Locky ransomware.
Finding over 7,000 variants seems daunting. It also demonstrates that file-hash-only identification is no longer practical. By drilling into the samples, we can see that there are patterns in the malware. These are the same similarities that Unit 42 used to create the tag. The infrastructure for the malware and most of what it does to the system once installed are the same each time it is deployed – primarily, that the file is obfuscated by changing a few bits to avoid hash-based detection.
By drilling into one of the hashes, we can see everything that WildFire observed when detonating this malicious software on Windows® XP and Windows 7. From there we can drill into individual indicators of compromise and search our own appliances for evidence, as well as create new protections for specific high-value IOCs, such as IP address, DNS or URLs.
The remote search function allows you to add search filters specifically designed for Palo Alto Networks security appliances. You will first be prompted to choose which of your appliances to search. Finally the console for the specified appliances will launch with the search filters already in place.
In this case, we have selected our Panorama instance. Since the logs from all security appliances are being forwarded, we will have visibility into the entire network with one search.
When we search through all the various types of logs in Panorama, we are looking for a specific command and control server as the destination. The good news is that we did not find the command and control server for Locky in the network, meaning we have confirmed there is no active infection within the organization.
The Hancitor downloader has been relatively quiet since a major campaign back in June 2016. But over the past week, while performing research using Palo Alto Networks AutoFocus, we noticed a large uptick in the delivery of the Hancitor malware family as they shifted away from H1N1 to distribute Pony and Vawtrak executables. In parallel, we received reports from other firms and security researchers seeing similar activity, which pushed us to look into this further.
Figure 1 AutoFocus view of new sessions of Hancitor since July 2016
The delivery method for these documents remained consistent to other common malicious e-mail campaigns. Lures contained subjects related to recent invoices, or other matters requiring the victim’s attention, such as an overdue bill. These lures were expected, until we started digging into the actual documents attached and saw an interesting method within the Visual Basic (VB) macros in the attached documents used for dropping the malware.
This blog will review in detail the dropping technique, which isn’t technically new, but this was the first time we’ve seen it used in this way. The end goal is to identify where the binary was embedded, but we’ll cover the macro and the embedded shellcode throughout this post.
The Word Document
For this section, we’ll be looking at the file with a SHA256 hash of ‘03aef51be133425a0e5978ab2529890854ecf1b98a7cf8289c142a62de7acd1a’, which is a typical MS Office OLE2 Word Document with your standard ploy to ‘Enable Content’ and run the malicious macro.
Figure 2 The ploy used by the malicious document
Opening the Visual Basic editor up, we can see two forms and a module for this particular sample.
Figure 3 VBProject components
The Malicious Macro
Visual Basic can directly execute Microsoft Windows API calls, which allows it perform a number of interesting functions — exactly what this VB code is doing.
Figure 4 Microsoft Windows API calls within VB code
As we can see, the macro includes logic to determine the architecture of the system it’s running on and has the ability to execute correctly on either 32-bit or 64-bit platforms. The primary calls of interest for us will be VirtualAlloc(), RtlMoveMemory(), and CallWindowProcA().
When we originally started looking at this sample, we were mainly interested in where the payload was being stored, so we began debugging the macro to understand how it functions. The payload in question is base64-encoded and embedded within a form in the VBProject as a value of the ‘Text’ field on the ‘choline’ TextBox.
As a side note, what is really interesting is that the authors went through the trouble to actually write their own base64 decoder purely in VB. We’ll leave that as an exercise for the reader to dig into that but it’s a good overview of how base-N encoding works; the entire ‘maria’ module within this macro is the base64 decoder.
The macro base64 decodes the payload into a local byte-array and then we come to our first API call, VirtualAlloc().
Figure 5 Memory page being allocated
The call commits specific pages of memory with read, write, and executable (RWX) permissions at 0x59B0000.
Figure 6 New memory page with RWX permissions
Afterwards, the VB macro continues to setup the next call to RtlMoveMemory and then calls it with the location of the memory from the previous call and our base64 decoded byte array.
Figure 7 Base64-decoded byte array
We can quickly validate by dumping that region of memory in our WINWORD.EXE process and comparing transferred bytes.
Figure 8 Confirming bytes match from dumped memory
Now that our code has been copied to in executable memory, the macro sets up the last API call for CallWindowProcA(). The first value supplied to this call is our memory offset +2214, which is a function pointer within this code, and the second is a string of the path to our file for a handle. These actions redirect code execution to shellcode.
Figure 9 Passing execution to the shellcode
The Shellcode
If we attach to WINWORD.EXE and break on the offset of our memory location +2214 (0x8A6), the entry point of the shellcode, we can validate program execution shifts to this code path.
Figure 10 Validating shellcode is executing
From here, the shellcode gets the address for LdrLoadDLL() function, which is similar to LoadLibraryEx(), by enumerating the Process Environment Block (PEB) and then begins to hunt for the functions it will use within kernel32.dll.
The values for the functions it’s looking for, along with other values, are embedded into the shellcode and built on the stack for later usage.
Figure 11 Embedded data in shellcode
Following these sets of encoded names, we can see the shellcode is interested in the following syscalls: CloseHandle(), ReadFile(), GetFileSize(), VirtualFree(), VirtualAlloc(), and CreateFileA(). For each API call, it looks up the address of the function and stores it on the stack.
Next, the shellcode calls CreateFileA() on the Word document and receives a handle back, which it passes to GetFileSize() for the file size, that is then subsequently passed to VirtualAlloc() to create a section of memory for the file contents (0x2270000). Finally, it reads in the file to that memory location and closes the handle.
Figure 12 Egg hunting by the shellcode
Once it has the copy loaded into memory, it begins a process of hunting through memory for the magic bytes 0x504F4C41, which we can see is located at 0x022836F3 in our new memory page.
Figure 13 Egg located
Now that we’ve found what’s likely to be our binary, the last step is to just decode it. Looking at the shellcode, we can see that it will add 0x3 to each byte starting at 0x22836FF, in our example, and then XOR it by 0x13, as shown below.
Figure 14 XOR decrypting
Once the counter reaches 0x13AAC (80556), it begins a series of sub-routines to manipulate each byte and decrypt the binary. If we set a breakpoint after the decryption routine and check our memory location, we can see that the binary is decoded and can now be dumped for further analysis. The MZ and PE headers can be seen in the following dumped memory.
Figure 15 Decoded binary
For this particular campaign run with this dropper, it places the binary in the %TMP% directory before launching it, which then ends up writing itself to ‘%SYSTEMROOT%/system32/WinHost.exe’.
At this point, the Hancitor downloader has been fully loaded on the victim’s machine, where it will proceed to perform additional malicious activities.
Conclusion
Macro-based techniques are quite common, but the technique being used here with the macro dropper is an interesting variation. From the encoded shellcode within the macro and using native API calls within VB code to pass execution to carving out and decrypting the embedded malware from the Word document, it’s a new use of Hancitor that we’ll be following closely. .
Palo Alto Networks customers are protected from the dropper detailed throughout this blog and its contained Hancitor payload. You can continue to track this threat through the AutoFocus Hancitor tag. Additionally, all Hancitor downloader samples are identified as malicious in WildFire. Domains used by Hancitor are also categorized as malicious.
Acknowledgements
For more analysis of the Hancitor payload, please see this write-up by Minerva Labs.
Indicators of Compromise
Below are some of the most common observed e-mail subjects and file names seen in the latest campaign this week from over 380,000 sessions. Patterns substituted with regex or representation.
Email Subjects
<domain> invoice for <month>
levi.com invoice for august
<domain> bill
<domain> deal
<domain> receipt
<domain> contract
<domain> invoice
metlife.com bill
metlife.com deal
metlife.com receipt
metlife.com contract
metlife.com invoice
This post is the first in a series by Unit 42 covering the cybercrime underground. Cybercrime persists as an epidemic that continues to worsen every year, with associated impacts and losses steadily growing. In this series, we’ll explore actors, motivations, and the current threat landscape.
Some of what contributes to the growth of the cybercrime underground is the convenience, speed, and anonymity the Internet provides to enable online crimes. Advances in the sophistication of cyberattacks over the past decade closely correlate with two major evolutions:
Lowered Cost of Entry: The ease and availability of tools and training to conduct such attacks, allowing individuals with lower skillsets to successfully thrive in the cybercrime industry.
Increased Business Acumen: The refinement of full attack lifecycle processes and support structures that rival some of the most innovative legitimate business models, enabling more efficient and effective operations coupled with robust commodity markets.
With the ever-changing cybercrime threat landscape, it is important to understand its current state, observe trends, and anticipate likely paths of evolution. Before we go any further, let’s establish some definitions related to the cybercrime underground.
Definitions
Cybercrime: Any crime that involves the use of computers to victimize an individual or organization for financial gain.
Indexed Web: All Internet search engine accessible and indexed sites. This is the web that most of the world knows and uses every day, and includes commercial / retail, social media, news, consumer service, and other publicly known sites.
Deep Web: Sites that make indexing by Internet search engines problematic, due to access control, dynamic content, or other prerequisite mechanisms (e.g., encryption or specialized software). In general, these sites are not accessible to standard web search engine crawlers that perform indexing. This class of sites is also sometimes referred to as the Invisible Web, Hidden Web, or Deepnet.
Dark Web: A subset of Deep Web sites that requires special software (e.g., TOR) to reach. Related infrastructure hosts criminal content such as stolen information and access to premium malware and exploits, and supports other categories of activity, such as illegal pornography, drug trade, prostitution, human trafficking, and terrorist operations. A number of these sites are transient, only up for a short
time or constantly changing addresses in an attempt to minimize the risk of exposure to government agencies, law enforcement and security researchers.
Cybercrime underground: Online forums where information, tools (malware, exploits), and services are bought and sold in support of cybercrime objectives. Composite sites exist on the Indexed Web, Deep Web, and Dark Web in varying contexts.
Figure 1 High level chart connecting the different attributes of cybercrime
Impacts
Cybercrime has broad impacts to both organizations and individuals. The losses from cybercrime can range from theft of intellectual property to costs incurred due to a result of a breach. A high level overview of the impacts can be broken down into direct and indirect losses:
Direct Losses
Loss of control over owned or entrusted:
PII data
Financial information
Electronic Health Records (EHRs)
Intellectual property
Trade secrets
Direct financial fraud
Service disruptions or restriction of access to data (e.g., ransomware).
Indirect Losses
Costs supporting recovery from a breach, such as incident response, investigation services, and remediation
Reputational damage
Legal and regulatory penalties related to the loss of records (e.g., PII, health, financial, etc.)
Near term business revenue loss
Longer term financial and economic consequences
Products, Services and Actor Roles
The cybercrime underground maintains its own economy of commoditized products and services. Related financial transactions have boomed with the broad adoption and accessibility of anonymous cryptocurrencies such as Bitcoin, which is commonly used by malicious actors amongst themselves as well as for accepting payments from victims (e.g., ransomware).
Products can be broken down into two main categories: information and resources. Sellers of these products benefit from the quick payouts of discrete (and sometimes one-time) transactions. Buyers benefit from what is often a professional level product that can be applied immediately to malicious actor operations “out of the box.” Information products include commodities such as:
Stolen personally identifiable information (PII): Including everything from mass email lists used by spammers to full identity theft packages to commit financial fraud
Exfiltrated organizational information: Including intellectual capital / property, non-public internal data, and internal operational details
Harvested authentication credentials: Stolen username and password combinations continue to present a significant risk these days, especially when those credentials are re-used across multiple sites
Pilfered financial / payment data: Unauthorized withdrawals from accounts or charges against credit lines continue to plague account holders
Resource products include elements such as:
Access to feature-rich malware: Malware across varying capabilities (e.g., information stealers, remote administration tools – RATs, ransomware, purpose built utilities) that demonstrate consistent results and avoid source code leakage can generate significant revenue for associated authors and distributors
Purchase of system or software exploits: While many white hats elect to support bug bounty initiatives by vendors, there remains a lucrative underground market for reliable, un-patched exploits
Transfer of control for previously compromised machines: This usually applies to always-on servers that can then be used as attack platforms or sold for the information they store, although the service model for this element is more popular these days
Malicious actor training: Guidebooks or tutorials on effective tool usage or specific Tactics, Techniques, and Procedures (TTPs)
Services can be thought of as “lease” versions of the resource-based – and even some of the information-based – products described above, where access to a product is promised at a set rate for an agreed upon period of time. Providing services appeals to many actors due to the recurrent cost model and opportunity to collect higher profits over a longer period of service. Malicious actors using these services benefit from assurances on availability and performance (e.g., timely feature, exploitation, and evasion updates). Such services include the following:
Distributed Denial of Service (DDoS): Botnet powered attacks that affect the availability of targeted servers and capabilities
Exploit Kits (EKs): Typically, monthly rate for access to the exploit toolkit allowing for customized end payloads
Infrastructure rental: Hosting services for attack platforms; malware update, configuration, and command and control (C2); and other attack lifecycle functions. Of special note: BulletProof Hosting Services (BPHSs) providers play a critical role in the cybercrime world as they allow cyber criminals to thrive and operate their malicious services without the risk of easily being taken down by law enforcement. Some of the key reasons that BPHS providers have been successful in their operations include: the appearance of legitimate businesses, strategic geographic distribution of servers in countries with accommodating cyber laws, high redundancy to minimize the risk of operational disruption, and professional level support services
Money laundering: Transfer (“money muling”) of illegally obtained funds through accounts and mechanisms in money haven countries remains a key service
As a high-level, malicious actor motivation, cybercrime is simply an extension of traditional criminal activity, focused on the theft of personal and account information and/or establishment of leverage over a target to achieve illicit monetary gain. The cybercrime ecosystem relies on a number of key roles that are also shared across other top-level motivations. A description of these roles can be found in Part 2 of a prior Unit 42 blog series: Adversaries and Their Motivations.
Coming Up…
Subsequent posts in this blog series will focus on different aspects of the cybercrime underground, including associated tools, services, techniques, and actors.
Palo Alto Networks has identified a malware family known as ‘Aveo’ that is being used to target Japanese speaking users. The ‘Aveo’ malware name comes from an embedded debug string within the binary file. The Aveo malware family has close ties to the previously discussed FormerFirstRAT malware family, which was also witnessed being used against Japanese targets. Aveo is disguised as a Microsoft Excel document, and drops a decoy document upon execution. The decoy document in question is related to a research initiative led by the Ido Laboratory at the Saitama Institute of Technology. Upon execution, the Aveo malware accepts a number of commands, allowing attackers to take full control over the victim machine.
Deployment
The Aveo malware sample disguises itself as a Microsoft Excel document, as the icon below demonstrates. Note that the filename of ‘malware.exe’ is simply a placeholder, as the original filename is unknown.
Figure 1 Microsoft Excel icon used by Aveo malware
The executable is in fact a WinRAR self-extracting executable file, which will drop the decoy document and Aveo Trojan upon execution. The following decoy document is dropped and subsequently opened when run.
Figure 2 Decoy document used with Aveo malware
This decoy document is hosted on the Ido Laboratory and contains information about a 2016 research initiative. The document lists participants in the 16th CAVE workshop, including names, affiliations, and email addresses of those involved. The document, written in Japanese, as well as the filename of this document, “CAVE研究会参加者.xls”, indicates that this malware was used to target one or more Japanese speaking individuals. Additionally, the similarities between the Aveo and FormerFirstRAT malware families, which will be discussed later in the post, further add evidence that Japanese speakers are being targeted.
Infrastructure
The Aveo Trojan is configured to communicate with the following domain name over HTTP.
snoozetime[.]info
This domain was first registered in May 2015 to ‘jack.ondo@mail.com’. Since that time, it has since been associated with the following three IP addresses:
104.202.173[.]82
107.180.36[.]179
50.63.202[.]38
All IP addresses in question are located within the United States.
Figure 3 PassiveTotal screenshot showing associated IP addresses with snoozetime[.]info
The WHOIS information for snoozetime[.]info lists a registrant email address of ‘jack.ondo@mail[.]com’ and a name of ‘aygt5ruhrj aygt5ruhrj gerhjrt’. Pivoting off of these two pieces of information to domains that share the same yields the following additional domains and email addresses.
bluepaint[.]info
coinpack[.]info
7b7p[.]info
donkeyhaws[.]info
europcubit[.]com
jhmiyh.ny@gmail[.]com
844148030@qq[.]com
Malware Analysis
After running the self-extracting executable, a number of files are dropped to the file system and the following execution flow is witnessed:
Figure 4 Malware execution flow
When the mshelp32.exe executable runs, it begins by reading in the setting32.ini file, which contains the name of the decoy document. This information is used to build a batch script, such as the following.
1
2
3
4
5
6
7
@echo off
copy“CAVE研究会参加者.xls”“C:\Documents and Settings\Administrator\Desktop\8101c298a33d91a985a5150d0254cf426601e4632250f5a03ddac39375e7fb4d.xls”/Y
del“CAVE研究会参加者.xls”/F/Q
del mshelp32.exe/F/Q
del setting32.ini/F/Q
del“C:\Documents and Settings\Administrator\Desktop\8101c298a33d91a985a5150d0254cf426601e4632250f5a03ddac39375e7fb4d.exe”/F/Q
del%0/F/Q
This batch script is executed within a new process, and acts as a simple cleanup script that runs after Aveo and the decoy document are executed.
Aveo Malware Family
The Aveo malware initially runs an install routine, which will copy itself to the following location:
%APPDATA%\MMC\MMC.exe
If for any reason the %APPDATA%\MMC directory is unable to be created, Aveo will use %TEMP% instead of %APPDATA%.
After the malware copies itself, it will execute MMC.exe in a new process with an argument of the original filename. When executed, if this single argument is provided, the malware will delete the file path provided.
After the installation routine completes, Aveo will exfiltrate the following victim information to a remote server via HTTP.
Unique victim hash
IP Address
Microsoft Windows version
Username
ANSI code page identifier
This information is exfiltrated to the ‘snoozetime[.]info’ domain, as seen in the following example HTTP request:
To encrypt the provided data, the malware makes use of the RC4 algorithm, using a key of ‘hello’. As shown in the following image, the encryption routines between Aveo and FormerFirstRAT are almost identical, with only the algorithms and keys being changed.
Figure 5 Comparison of encryption function between Aveo and FormerFirstRAT
In order to decrypt the data provided via HTTP, the following code may be used:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
import base64
from binascii import *
from structimport *
from wincrypto import CryptCreateHash,CryptHashData,CryptDeriveKey,CryptEncrypt,CryptDecrypt
Running the code above yields the following results:
1
2
3
4
5
[+]Parameter1Decrypted:e8836687
[+]Parameter2Decrypted:172.16.95.184
[+]Parameter4Decrypted:6.1.7601.2.1
[+]Parameter5Decrypted:Josh Grunzweig
[+]Parameter6Decrypted:1252
After the initial victim information is exfiltrated, the malware expects a response of ‘OK’. Afterwards, Aveo will spawn a new thread that is responsible for handling interactive command requests received by the command and control (C2) server, as well as requests to spawn an interactive shell.
Aveo proceeds to set the following registry key to point towards the malware’s path, thus ensuring persistence across reboots:
A command handler loop is then entered, where Aveo will accept commands from the remote C2. While the Aveo malware family awaits a response, it will perform sleep delays of randomly chosen intervals between 0 and 3276 milliseconds. Should the C2 server respond with ‘toyota’, it will set that interval to 60 seconds. Aveo accepts the following commands, shown with their associated function.
1 : Execute command in interactive shell
2 : Get file attributes
3 : Write file
4 : Read file
5 : List drives
6 : Execute DIR command against path
The following example request demonstrates the C2 server sending the ‘ipconfig’ command to the Aveo malware.
Aveo shares a number of characteristics with FormerFirstRAT, including encryption routines, code reuse, and similarities in C2 functionality. Aveo is far from the most sophisticated malware family around. As witnessed in the previously discussed FormerFirstRAT sample, this related malware family also looks to be targeting Japanese speaking users. Using a self-extracting WinRAR file, the malware drops a decoy document, a copy of the Aveo malware, and a cleanup script.
Palo Alto Networks customers are protected from this threat in the following ways:
An AutoFocus tag has been created to track and monitor this threat
WildFire classifies Aveo samples as malicious
C2 domains listed in this report are blocked through Threat Prevention.
