Authored by: Sang Ryol Ryu and Chanung Pak

A new wave of fraudulent apps has made its way to the Google Play store, targeting Android users in Southwest Asia and the Arabian Peninsula as well—to the tune of more than 700,000 downloads before detection by McAfee Mobile Research and co-operation with Google to remove the apps.

Figure 1. Infected Apps on Google Play

Posing as photo editors, wallpapers, puzzles, keyboard skins, and other camera-related apps, the malware embedded in these fraudulent apps hijack SMS message notifications and then make unauthorized purchases. While apps go through a review process to ensure that they are legitimate, these fraudulent apps made their way into the store by submitting a clean version of the app for review and then introducing the malicious code via updates to the app later.

Figure 2. Negative reviews on Google Play

McAfee Mobile Security detects this threat as Android/Etinu and alerts mobile users if they are present. The McAfee Mobile Research team continues to monitor this threat and is likewise continuing its co-operation with Google to remove these and other malicious applications on Google Play.

Technical analysis

In terms of details, the malware embedded in these apps takes advantage of dynamic code loading. Encrypted payloads of malware appear in the assets folder associated with the app, using names such as “cache.bin,” “settings.bin,” “data.droid,” or seemingly innocuous “.png” files, as illustrated below.

Figure 3. Encrypted resource sneaked into the assets folder

Figure 4. Decryption flow

The figure above shows the decryption flow. Firstly, the hidden malicious code in the main .apk opens “1.png” file in the assets folder, decrypts it to “loader.dex,” and then loads the dropped .dex. The “1.png” is encrypted using RC4 with the package name as the key. The first payload creates HTTP POST request to the C2 server.

Interestingly, this malware uses key management servers. It requests keys from the servers for the AES encrypted second payload, “2.png”. And the server returns the key as the “s” value of JSON. Also, this malware has self-update function. When the server responds “URL” value, the content in the URL is used instead of “2.png”. However, servers do not always respond to the request or return the secret key.

Figure 5. Updated payload response

As always, the most malicious functions reveal themselves in the final stage. The malware hijacks the Notification Listener to steal incoming SMS messages like Android Joker malware does, without the SMS read permission. Like a chain system, the malware then passes the notification object to the final stage. When the notification has arisen from the default SMS package, the message is finally sent out using WebView JavaScript Interface.

Figure 6. Notification delivery flow

As a result of our additional investigation on C2 servers, following information was found, including carrier, phone number, SMS message, IP address, country, network status, and so forth—along with auto-renewing subscriptions:

Figure 7. Leaked data

Further threats like these to come?

We expect that threats which take advantage of Notification Listener will continue to flourish. The McAfee Mobile Research team continues to monitor these threats and protect customers by analyzing potential malware and working with app stores to remove it. Further, using McAfee Mobile Security can detect such threats and protect you from them via its regular updates. However, it’s important to pay attention to apps that request SMS-related permissions and Notification Listener permissions. Simply put, legitimate photo and wallpaper apps simply won’t ask for those because they’re not necessary for such apps to run. If a request seems suspicious, don’t allow it.

Technical Data and IOCs

MITRE ATT&CK Matrix

IoCs

08C4F705D5A7C9DC7C05EDEE3FCAD12F345A6EE6832D54B758E57394292BA651	com.studio.keypaper2021
CC2DEFEF5A14F9B4B9F27CC9F5BBB0D2FC8A729A2F4EBA20010E81A362D5560C	com.pip.editor.camera
007587C4A84D18592BF4EF7AD828D5AAA7D50CADBBF8B0892590DB48CCA7487E	org.my.favorites.up.keypaper
08FA33BC138FE4835C15E45D1C1D5A81094E156EEF28D02EA8910D5F8E44D4B8	com.super.color.hairdryer
9E688A36F02DD1B1A9AE4A5C94C1335B14D1B0B1C8901EC8C986B4390E95E760	com.ce1ab3.app.photo.editor
018B705E8577F065AC6F0EDE5A8A1622820B6AEAC77D0284852CEAECF8D8460C	com.hit.camera.pip
0E2ACCFA47B782B062CC324704C1F999796F5045D9753423CF7238FE4CABBFA8	com.daynight.keyboard.wallpaper
50D498755486D3739BE5D2292A51C7C3D0ADA6D1A37C89B669A601A324794B06	com.super.star.ringtones

URLs

d37i64jgpubcy4.cloudfront.net

d1ag96m0hzoks5.cloudfront.net

dospxvsfnk8s8.cloudfront.net

d45wejayb5ly8.cloudfront.net

d3u41fvcv6mjph.cloudfront.net

d3puvb2n8wcn2r.cloudfront.net

d8fkjd2z9mouq.cloudfront.net

d22g8hm4svq46j.cloudfront.net

d3i3wvt6f8lwyr.cloudfront.net

d1w5drh895wnkz.cloudfront.net

The post Clever Billing Fraud Applications on Google Play: Etinu appeared first on McAfee Blog.

Authored by: Sang Ryol Ryu and Chanung Pak

McAfee Mobile Research team has found another variant of MalBus on an education application, developed by a South Korean developer. In the previous Malbus case, the author distributed the malware through Google Play, but new variants are distributed via the ONE Store in much the same way. ONE Store is a joint venture by the country’s three major telecom companies and is a preinstalled app on most Android phones selling in South Korea. It has 35 million users (close to 70% of South Korea’s population) and has already surpassed Apple’s app store sales from the end of 2018.

The application in question is distributed via Google Play and the ONE Store at the same time. The malicious application downloads and runs an encrypted payload with malicious functions.

McAfee Mobile Security detects this threat as Android/Malbus and alerts mobile users if it is present, while protecting them from any data loss.

Figure 1. Screen capture from the application page on the ONE Store

The Campaign

We found malicious code injected by an attacker, via the developer’s account, into versions 27 and 28 of the application distributed through the ONE Store. The App Signature Certificate for versions 26 through 29 distributed from the One Store are the same. No other application developed by the same author was found on the ONE Store. The ONE Store is now servicing version 29 which does not contain malicious code. Google Play still offers version 26, though this is also clear of infection.

Figure 2. Infected version history of the application

The overall flow of this application, focusing on the malicious function, is explained below:

Figure 3. Overview of malicious behavior

After the malware is installed, the malicious code has a latent period of 10 hours to avoid being discovered by dynamic analysis.

Figure 4. Using LastUpdateTime to check latent period

After the latent period, it starts two threads. The first one loads native library “libmovie.so” and calls one of its exported functions, “playMovie”, with a phone number as an argument while the second one creates a Java server socket for communication with another native library.

Figure 5. The malicious native library embedded in the APK

The first loaded library, libmovie.so, contains a curl binary and URLs for secondary payloads in XOR encoded data which are decoded at runtime. The XOR value is 0x8E and it is globally used in this library. All decoded URLs appear to have been hacked and the decoded URLs drop RC4 encrypted ELF files.

 

Table 1. Contents in libmovie.so

Simply put, libmovie.so is a downloader and executer. It downloads the next payload from a hacked web server by using a dropped curl binary, decrypts it and loads the library. Once the library is loaded, the downloaded file is deleted to avoid detection. Lastly, the downloaded code starts from exported function name “Libfunc”.

Figure 6. The main flow of libmovie.so

As for the RC4 cryptographic library, encryption is the most common way to hide or protect important things. Accordingly, it is assumed that there is some important in this file.

Table 2. Additional information of downloaded file

The file sizes and data for szServer_XX_1 and szServer_XX_2 are the same as shown in Table 2. But szServer_XX_3 has several functions that are added, removed or modified a little bit. However, it does not affect the overall process.

“doMainProc” is the core function called by “Libfunc”. The first job of the “doMainProc” is selecting the C2 server randomly.

Table 3. C2 server list

After selecting the C2 server, a randomly created TUID is sent to the server. Guessing from its usage, the TUID might be a target device ID to manage contaminated targets. Now the application is working as a spy agent, waiting for actions from the selected server and ready to execute commands. We discovered the following available commands:

 

Table 4. Available command list

Among the malicious commands, an eye-catching feature is SMS and MMS capturing. SMS and MMS are saved in the “/data/data/<package name>/files/” directory as file name “sms.txt” and “mms.txt” respectively.

Figure 7. SMS and MMS are saved in txt files

This feature can be activated by registering the Android receiver.

Figure 8. RegisterReceiver

This malicious app opens TCP port 1111 locally to communicate with the loaded native library. Below is manually interpreted Java code:

public void run()

{

CommunicationThread commThread;

Socket socket = null;

serverSocket = new ServerSocket(sock_port); // sock_port = 1111

if (serverSocket) {

while ((!Thread.currentThread().isInterrupted())) {

commThread = new CommunicationThread(this, serverSocket.accept());

new Thread(commThread).start();

}

}

}

Figure 9. com.joojang.CharacterClassic.MainService

The SMS/MMS capture feature is enabled when receiving a “SET” string on local TCP 1111 port and disabled by receiving “FREE”.

Figure 10. SET or FREE

The loaded native library connects when the “SD_SetSMSCapture” command receives and sends “SET”

Figure 11. SD_SetSmsCapture

Below is interpreted as C language.

client = socket(AF_INET, SOCK_STREAM, 0);

addr.sin_family = AF_INET;

addr.sin_port = htons(1111);

addr.sin_addr.s_addr= inet_addr(“127.0.0.1”);

One other function we have not seen before is “SD_LoadSoFile”. This loads a new native library and executes a specific function in it. This function seems to change the running native library to a newer one when the current binary has a problem, or to add new features.

Figure 12. SD_LoadSoFile

Compared to Malbus

This newly discovered malicious code has many similarities compared to Malbus, such as using the same malicious function name starting with “SD_”, file name, XOR’ed strings to hide original strings, embedded files in libraries, command ids, the same version of compiler and so on. It also has the differences mentioned above: downloading a malicious library directly instead of installing a plugin APK and no sensitive keyword list such as ‘North Korea’, ‘National Defense’ and so on.

Figure 13. The identical function names from the malicious library

Figure 14. The same version of compiler strings

Conclusion

Malware can be distributed through all manner of third-party app stores, not only official ones such as Google Play. This malware is carefully prepared – the final payload of the malware is the file that was hacked and uploaded to the vulnerable server before malware distribution. We believe the authors of this malware will continue to buy or hack trusted developer accounts to update malicious functionality, infiltrate and distribute through official app stores. As with previous cases, users should verify the applications they install, even if they download them from official stores. McAfee is working with Korean law enforcement agencies to help with the takedown of the attack campaign.

 

Hashes (SHA-256)

Initial Downloader (APKs)

• 5e57bc8d83a372bf4d046c272cd43db9000036c9b32d8eecead1af75f4958c57
• 1613b35c73c6497730490d7712ac015c2b42931446aed149e1292e2ba77d0ff4

Encrypted Trojan (additional payload)

• d328373cd67c467485b9c96349a0ee08fc3b58fe2c11fb19f4dcb9ea6c7a0dae
• c5bff68022ead6302f710f1ce1c3d5682a8cd3610b1f8ed2563098d7ac4e1909
• c410cacbb0be8f649f082148c91f4cef27f101b8db3ce64a02882506c9b51a63
• 178dddf38ec232d540bd88320521d8134644da1e7af19e7ae295b2d614e3ab56

Decrypted Trojan (additional payload)

• 9fc914545fbb99b7e0d4a5207f5a2b32a8a127a36caa9159d4feeac445c509f7
• df651ac1bfd60cd29cea85cc410002b933552260c2439fe86a4f32486abd0828
• 63d10c9cd105c7b17effef18d31d571fe4c9c999966cc09bdb40df07c1b6baa8
• f99212b70729942923fe26b996791cdd8eb561f8ae017e1d71202fbb97f7d245

The post MalBus Actor Changed Market from Google Play to ONE Store appeared first on McAfee Blog.

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 Blog.

The December 2020 revelations around the SUNBURST campaigns exploiting the SolarWinds Orion platform have revealed a new attack vector – the supply chain – that will continue to be exploited.

The ever-increasing use of connected devices, apps and web services in our homes will also make us more susceptible to digital home break-ins. This threat is compounded by many individuals continuing to work from home, meaning this threat not only impacts the consumer and their families, but enterprises as well.

Attacks on cloud platforms and users will evolve into a highly polarized state where they are either “mechanized and widespread” or “sophisticated and precisely handcrafted”.

Mobile users will need to beware of phishing or smishing messages aimed at exploiting and defrauding them through mobile payment services.

The use of QR codes has notably accelerated during the pandemic, raising the specter of a new generation of social engineering techniques that seek to exploit consumers and gain access to their personal data.

Finally, the most sophisticated threat actors will increasingly use social networks to target high value individuals working in sensitive industry sectors and roles.

A new year offers hope and opportunities for consumers and enterprises, but also more cybersecurity challenges. I hope you find these helpful in planning your 2021 security strategies.

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

Twitter @Raj_Samani 

2021 Predictions  

1.	Supply Chain Backdoor Techniques to Proliferate

By Steve Grobman 

The revelations around the SolarWinds-SUNBURST espionage campaign will spark a proliferation in copycat supply chain attacks of this kind.  

On December 13, 2020, the cybersecurity industry learned nation-state threat actors had compromised SolarWinds’s Orion IT monitoring and management software and used it to distribute a malicious software backdoor called SUNBURST to dozens of that company’s customers, including several high-profile U.S. government agencies.  

This SolarWinds-SUNBURST campaign is the first major supply chain attack of its kind and has been referred to by many as the “Cyber Pearl Harbor” that U.S. cybersecurity experts have been predicting for a decade and a half.  

The campaign also represents a shift in tactics where nation state threat actors have employed a new weapon for cyber-espionage.  Just as the use of nuclear weapons at the end of WWII changed military strategy for the next 75 years, the use of a supply chain attack has changed the way we need to consider defense against cyber-attacks.   

This supply chain attack operated at the scale of a worm such as WannaCry in 2017, combined with the precision and lethality of the 2014 Sony Pictures or 2015 U.S. government Office of Personnel Management (OPM) attacks. 

Within hours of its discovery, the magnitude of the campaign became frighteningly clear to organizations responsible for U.S. national security, economic competitiveness, and even consumer privacy and security.  

It enables U.S. adversaries to steal all manners of information, from inter-governmental communications to national secrets. Attackers can, in turn, leverage this information to influence or impact U.S. policy through malicious leaks.  Every breached agency may have different secondary cyber backdoors planted, meaning that there is no single recipe to evict the intrusion across the federal government. 

While some may argue that government agencies are legitimate targets for nation-state spy craft, the campaign also impacted private companies. Unlike government networks which store classified information on isolated networks, private organizations often have critical intellectual property on networks with access to the internet.  Exactly what intellectual property or private data on employees has been stolen will be difficult to determine, and the full extent of the theft may never be known.  

This type of attack also poses a threat to individuals and their families given that in today’s highly interconnected homes, a breach of consumer electronics companies can result in attackers using their access to smart appliances such as TVs, virtual assistants, and smart phones to steal their information or act as a gateway to attack businesses while users are working remotely from home. 

What makes this type of attack so dangerous is that it uses trusted software to bypass cyber defenses, infiltrate victim organizations with the backdoor and allow the attacker to take any number of secondary steps. This could involve stealing data, destroying data, holding critical systems for ransom, orchestrating system malfunctions that result in kinetic damage, or simply implanting additional malicious content throughout the organization to stay in control even after the initial threat appears to have passed. 

McAfee believes the discovery of the SolarWinds-SUNBURST campaign will expose attack techniques that other malicious actors around the world will seek to duplicate in 2021 and beyond. 

 

2.	Hacking the Home to Hack the Office

By Suhail Ansari, Dattatraya Kulkarni and Steve Povolny 

 The increasingly dense overlay of numerous connected devices, apps and web services used in our professional and private lives will grow the connected home’s attack surface to the point that it raises significant new risks for individuals and their employers. 

 While the threat to connected homes is not new, what is new is the emergence of increased functionality in both home and business devices, and the fact that these devices connect to each other more than ever before. Compounding this is the increase in remote work – meaning many of us are using these connected devices more than ever. 

In 2020,the global pandemic shifted employees from the office to the home, making the home environment a work environment. In fact, since the onset of the coronavirus pandemic, McAfee Secure Home Platform device monitoring shows a 22% increase in the number of connected home devices globally and a 60% increase in the U.S. Over 70% of the traffic from these devices originated from smart phones, laptops, other PCs and TVs, and over 29% originated from IoT devices such as streaming devices, gaming consoles, wearables, and smart lights.

McAfee saw cybercriminals increase their focus on the home attack surface with a surge in various phishing message schemes across communications channels. The number of malicious phishing links McAfee blocked grew over 21% from March to November, at an average of over 400 links per home.  

 This increase is significant and suggests a flood of phishing messages with malicious links entered home networks through devices with weaker security measures.  

 Millions of individual employees have become responsible for their employer’s IT security in a home office filled with “soft” targets, unprotected devices from the kitchen, to the family room, to the bedroom. Many of these home devices are “orphaned” in that their manufacturers fail to properly support them with security updates addressing new threats or vulnerabilities.  

This contrasts with a corporate office environment filled with devices “hardened” by enterprise-grade security measures. We now work with consumer-grade networking equipment configured by “us” and lacking the central management, regular software updates and security monitoring of the enterprise.   

Because of this, we believe cybercriminals will advance the home as an attack surface for campaigns targeting not only our families but also corporations. The hackers will take advantage of the home’s lack of regular firmware updates, lack of security mitigation features, weak privacy policies, vulnerability exploits, and user susceptibility to social engineering.  

By compromising the home environment, these malicious actors will launch a variety of attacks on corporate as well as consumer devices in 2021. 

 

3.	Attacks on Cloud Platforms Become Highly Mechanized and Handcrafted

By Sandeep Chandana  

Attacks on cloud platforms will evolve into a highly polarized state where they are either “mechanized and widespread” or “targeted and precisely handcrafted”.  

The COVID-19 pandemic has also hastened the pace of the corporate IT transition to the cloud, accelerating the potential for new corporate cloud-related attack schemes. With increased cloud adoption and the large number of enterprises working from home, not only is there a growing number of cloud users but also a lot more data both in motion and being transacted.  

 McAfee cloud usage data from more than 30 million McAfee MVISION Cloud users worldwide shows a 50% increase overall in enterprise cloud use across all industries the first four months of 2020. Our analysis showed an increase across all cloud categories, usage of collaboration services such as Microsoft O365 by 123%, increase in use of business services such as Salesforce by 61% and the largest growth in collaboration services such as Cisco Webex (600%), Zoom (+350%), Microsoft Teams (+300%), and Slack (+200%). From January to April 2020, corporate cloud traffic from unmanaged devices increased 100% across all verticals.  

 During the same period, McAfee witnessed a surge in attacks on cloud accounts, an estimated 630% increase overall, with variations in the sectors that were targeted. Transportation led vertical industries with a 1,350% increase in cloud attacks, followed by education (+1,114%), government (+773%), manufacturing (+679%), financial services (+571%) and energy and utilities (+472%).  

The increasing proportion of unmanaged devices accessing the enterprise cloud has effectively made home networks an extension of the enterprise infrastructure. Cybercriminals will develop new, highly mechanized, widespread attacks for better efficacy against thousands of heterogenous home networks.  

One example could be a widespread brute force attack against O365 users, where the attacker seeks to leverage stolen credentials and exploit users’ poor practice of re-using passwords across different platforms and applications. As many as 65% of users reuse the same password for multiple or all accounts according to a 2019 security survey conducted by Google. Where an attacker would traditionally need to manually encode first and last name combinations to find valid usernames, a learning algorithm could be used to predict O365 username patterns.  

Additionally, cybercriminals could use AI and ML to bypass traditional network filtering technologies deployed to protect cloud instances. Instead of launching a classic brute force attack from compromised IPs until the IPs are blocked, resource optimization algorithms will be used to make sure the compromised IPs launch attacks against multiple services and sectors, to maximize the lifespan of compromised IPs used for the attacks. Distributed algorithms and reinforcement learning will be leveraged to identify attack plans primarily focused on avoiding account lockouts.   

McAfee also predicts that, as enterprise cloud security postures mature, attackers will be forced to handcraft highly targeted exploits for specific enterprises, users and applications.  

The recent Capital One breach was an example of an advanced attack of this kind. The attack was thoroughly cloud-native. It was sophisticated and intricate in that a number of vulnerabilities and misconfigurations across cloud applications (and infrastructure) were exploited and chained. It was not a matter of chance that the hackers were successful, as the attack was very well hand-crafted.  

 We believe attackers will start leveraging threat surfaces across devices, networks and the cloud in these ways in the months and years ahead. 

4.	New Mobile Payment Scams

By Suhail Ansari and Dattatraya Kulkarni

As users become more and more reliant on mobile payments, cybercriminals will increasingly seek to exploit and defraud users with scam SMS phishing or smishing messages containing malicious payment URLs.

 Mobile payments have become more and more popular as a convenient mechanism to conduct transactions. A Worldpay Global Payments Report for 2020 estimated that 41% of payments today are on mobile devices, and this number looks to increase  at the expense of traditional credit and debit cards by 2023. An October 2020 study by Allied Market Research found that the global mobile payment market size was valued at $1.48 trillion in 2019, and is projected to reach $12.06 trillion by 2027, growing at a compound annual growth rate of 30.1% from 2020 to 2027.  

Additionally, the COVID-19 pandemic has driven the adoption of mobile payment methods higher as consumers have sought to avoid contact-based payments such as cash or physical credit cards. 

But fraudsters have followed the money to mobile, pivoting from PC browsers and credit cards to mobile payments. According to research by RSA’s Fraud and Risk Intelligence team, 72% of cyber fraud activity involved the mobile channel in the fourth quarter of 2019. The researchers observed that this represented “the highest percentage of fraud involving mobile apps in nearly two years and underscores a broader shift away from fraud involving web browsers on PCs.” 

McAfee predicts there will be an increase in “receive”-based mobile payment exploits, where a user receives a phishing email, direct message or smishing message telling him that he can receive a payment, transaction refund or cash prize by clicking on a malicious payment URL. Instead of receiving a payment, however, the user has been conned into sending a payment from his account.  

This could take shape in schemes where fraudsters set up a fake call center using a product return and servicing scam, where the actors send a link via email or SMS, offering a refund via a mobile payment app, but the user is unaware that they are agreeing to pay versus receiving a refund. The figures below show the fraudulent schemes in action.  

Mobile wallets are making efforts to make it easier for users to understand whether they are paying or receiving. Unfortunately, as the payment methods proliferate, fraudsters succeed in finding victims who either cannot distinguish credit from debit or can be prompted into quick action by smart social engineering.  

Governments and banks are making painstaking efforts to educate users to understand the use of one-time passwords (OTPs) and that they should not be shared. Adoption of frameworks such as caller ID authentication (also known as STIR/SHAKEN) help in ensuring that the caller ID is not masked by fraudsters, but they do not prevent a fraudster from registering an entity that has a name close to the genuine provider of service. 

In the same way that mobile apps have simplified the ability to conduct transactions, McAfee predicts the technology is making it easier to take advantage of the convenience for fraudulent purposes. 

5.	Qshing: QR Code Abuse in the Age of COVID

By Suhail Ansari and Dattatraya Kulkarni 

Cybercriminals will seek new and ever cleverer ways to use social engineering and QR Code practices to gain access to consumer victims’ personal data. 

The global pandemic has created the need for all of us to operate and transact in all areas of our lives in a “contactless” way. Accordingly, it should come as no surprise that QR codes have emerged as a convenient input mechanism to make mobile transactions more efficient.  

QR code usage has proliferated into many areas, including payments, product marketing, packaging, restaurants, retail, and recreation just to name a few. QR codes are helping limit direct contact between businesses and consumers in every setting from restaurants to personal care salons, to fitness studios. They allow them to easily scan the code, shop for services or items offered, and easily purchase them.  

A September 2020 survey by MobileIron found that 86% of respondents scanned a QR code over the course of the previous year and over half (54%) reported an increase in the use of such codes since the pandemic began. Respondents felt most secure using QR codes at restaurants or bars (46%) and retailers (38%). Two-thirds (67%) believe that the technology makes life easier in a touchless world and over half (58%) wish to see it used more broadly in the future.  

In just the area of discount coupons, an estimated 1.7 billion coupons using QR codes were scanned globally in 2017, and that number is expected to increase by a factor of three to 5.3 billion by 2022. In just four years, from 2014 to 2018, the use of QR codes on consumer product packaging in Korea and Japan increased by 83%. The use of QR codes in such “smart” packaging is increasing at an annual rate of 8% globally.  

In India, the government’s Unique Identification Authority of India (UIDAI) uses QR codes in association with Aadhaar, India’s unique ID number, to enable readers to download citizens’ demographic information as well as their photographs. 

However, the technicalities of QR codes are something of a mystery to most users, and that makes them potentially dangerous if cybercriminals seek to exploit them to target victims.  

The MobileIron report found that whereas 69% of respondents believe they can distinguish a malicious URL based on its familiar text-based format, only 37% believe they can distinguish a malicious QR code using its unique dot pattern format. Given that QR codes are designed precisely to hide the text of the URL, users find it difficult to identify and even suspect malicious QR codes. 

Almost two-thirds (61%) of respondents know that QR codes can open a URL and almost half (49%) know that a QR code can download an application. But fewer than one-third (31%) realize that a QR code can make a payment, cause a user to follow someone on social media (22%), or start a phone call (21%). A quarter of respondents admit scanning a QR code that did something unexpected (such as take them to a suspicious website), and 16% admitted that they were unsure if a QR code actually did what it was intended to do. 

It is therefore no surprise that QR codes have been used in phishing schemes to avoid anti-phishing solutions’ attempts to identify malicious URLs within email messages. They can also be used on webpages or social media. 

In such schemes, victims scan fraudulent QRs and find themselves taken to malicious websites where they are asked to provide login, personal info, usernames and passwords, and payment information, which criminals then steal. The sites could also be used to simply download malicious programs onto a user’s device.  

McAfee  predicts that hackers will increasingly use these QR code schemes and broaden them using social engineering techniques. For instance, knowing that business owners are looking to download QR code generator apps, bad actors will entice consumers into downloading malicious QR code generator apps that pretend to do the same. In the process of generating the QR code (or even pretending to be generating the correct QR code), the malicious apps will steal the victim’s sensitive data, which scammers could then use for a variety of fraudulent purposes.  

Although the QR codes themselves are a secure and convenient mechanism, we expect them to be misused by bad actors in 2021 and beyond. 

6.	Social Networks as Workplace Attack Vectors

By Raj Samani 

McAfee predicts that sophisticated cyber adversaries will increasingly target, engage and compromise corporate victims using social networks as an attack vector.  

Cyber adversaries have traditionally relied heavily on phishing emails as an attack vector for compromising organizations through individual employees. However, as organizations have implemented spam detection, data loss prevention (DLP) and other solutions to prevent phishing attempts on corporate email accounts, more sophisticated adversaries are pivoting to target employees through social networking platforms to which these increasingly effective defenses cannot be applied. 

McAfee has observed such threat actors increasingly using the messaging features of LinkedIn, What’s App, Facebook and Twitter to engage, develop relationships with and then compromise corporate employees. Through these victims, adversaries compromise the broader enterprises that employ them. McAfee predicts that such actors will seek to broaden the use of this attack vector in 2021 and beyond for a variety of reasons.  

Malicious actors have used the social network platforms in broad scoped schemes to perpetrate relatively low-level criminal scams. However, prominent actors such as APT34, Charming Kitten, and Threat Group-2889 (among others) have been identified using these platforms for higher-value, more targeted campaigns on the strength of the medium’s capacity for enabling customized content for specific types of victims.  

Operation North Star demonstrates a state-of-the-art attack of this kind. Discovered and exposed by McAfee in August 2020, the campaign showed how lax social media privacy controls, ease of development and use of fake LinkedIn user accounts and job descriptions could be used to lure and attack defense sector employees. 

Just as individuals and organizations engage potential consumer customers on social platforms by gathering information, developing specialized content, and conducting targeted interactions with customers, malicious actors can similarly use these platform attributes to target high value employees with a deeper level of engagement.  

Additionally, individual employees engage with social networks in a capacity that straddles both their professional and personal lives. While enterprises assert security controls over corporate-issued devices and place restrictions on how consumer devices access corporate IT assets, user activity on social network platforms is not monitored or controlled in the same way. As mentioned, LinkedIn and Twitter direct messaging will not be the only vectors of concern for the corporate security operations center (SOC). 

While it is unlikely that email will ever be replaced as an attack vector, McAfee foresees this social network platform vector becoming more common in 2021 and beyond, particularly among the most advanced actors. 

 

The post 2021 Threat Predictions Report appeared first on McAfee Blog.

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
• Technical Analysis
  • Phase One: Malicious Documents
    • Document Templates
    • Visual Basic Macro Code
  • Phase Two: Malicious DLLs
    • DLL Workflow
    • Implant Analysis
  • Phase Three: Network Evasion Techniques
  • Phase Four: Persistence
• Additional Lures: Relationship to 2020 Diplomatic & Political Campaign
  • Relationship to Falsified Job Recruitment Campaign
• Victimology
• Infrastructure Insights
• Techniques, Tactics & Procedures (TTPs)
• Defensive Architecture Recommendations
• IOCs
• Conclusion

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 contractors³

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 group⁴

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 21^st 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 28^th 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 Blog.