Lazarus Resurfaces, Targets Global Banks and Bitcoin Users
This blog was written with support and contributions provided by Asheer Maholtra, Jessica Saavedra Morales, and Thomas Roccia.
McAfee Advanced Threat Research (ATR) analysts have discovered an aggressive Bitcoin-stealing phishing campaign by the international cybercrime group Lazarus that uses sophisticated malware with long-term impact.
This new campaign, dubbed HaoBao, resumes Lazarus’ previous phishing emails, posed as employee recruitment, but now targets Bitcoin users and global financial organizations. When victims open malicious documents attached to the emails, the malware scans for Bitcoin activity and then establishes an implant for long-term data-gathering.
HaoBao targets and never-before-seen implants signal to McAfee ATR an ambitious campaign by Lazarus to establish cryptocurrency cybercrime at a sophisticated level.
Beginning in 2017, the Lazarus group heavily targeted individuals with spear phishing emails impersonating job recruiters which contained malicious documents. The campaign lasted from April to October and used job descriptions relevant to target organizations, in both English and Korean language. The objective was to gain access to the target’s environment and obtain key military program insight or steal money. The 2017 campaign targets ranged from defense contractors to financial institutions, including crypto currency exchanges, however; much of this fake job recruitment activity ceased months later, with the last activity observed October 22, 2017.
On January 15th , McAfee ATR discovered a malicious document masquerading as a job recruitment for a Business Development Executive located in Hong Kong for a large multi-national bank. The document was distributed via a Dropbox account at the following URL:
This is the mark of a new campaign, though it utilizes techniques, tactics and procedures observed in 2017. This document had the last author ‘Windows User’ and was created January 16, 2018 with Korean language resources. Several additional malicious documents with the same author appeared between January 16 though January 24, 2018.
Victims are persuaded to enable content through a notification claiming the document was created in an earlier version of Microsoft Word. The malicious documents then launch an implant on the victim’s system via a Visual Basic macro.
The document (7e70793c1ca82006775a0cac2bd75cc9ada37d7c) created January 24, 2018 drops and executes an implant compiled January 22, 2018 with the name lsm.exe (535f212b320df049ae8b8ebe0a4f93e3bd25ed79). The implant lsm.exe contacted 188.8.131.52 which also resolves to worker.co.kr.Implants dropped in campaign
The other malicious document ( a79488b114f57bd3d8a7fa29e7647e2281ce21f6) created January 19, 2018 drops the implant (afb2595ce1ecf0fdb9631752e32f0e32be3d51bb); which is 99% similar-to the lsm.exe implant.
This document was distributed from the following Dropbox URLs:
- hxxps://www.dropbox.com/s/q7w33sbdil0i1w5/job description.doc?dl=1
This implant (csrss.exe) compiled January 15, 2018 contacts an IP address 184.108.40.206 which resolves to deltaemis.com. We identified that this domain was used to host a malicious document from a previous 2017 campaign targeting the Sikorsky program.
A third malicious document (dc06b737ce6ada23b4d179d81dc7d910a7dbfdde) created January 19, 2018 drops e8faa68daf62fbe2e10b3bac775cce5a3bb2999e which is compiled January 15, 2018. This implant communicates to a South Korean IP address 220.127.116.11 which resolves to palgong-cc.co.kr.
McAfee ATR analysis finds the dropped implants have never been seen before in the wild and have not been used in previous Lazarus campaigns from 2017. Furthermore, this campaign deploys a one-time data gathering implant that relies upon downloading a second stage to gain persistence. The implants contain a hardcoded word “haobao” that is used as a switch when executing from the Visual Basic macro.
Malicious Document Analysis
The malicious document contains two payloads as encrypted string arrays embedded in Visual Basic macro code. The payloads are present as encrypted string arrays that are decrypted in memory, written to disk and launched in sequence (second stage malicious binary launched first and then the decoy document).
The VBA Macro code is self-executing and configured to execute when the OLE document (MS Word doc) is opened (via “Sub AutoOpen()”). The AutoOpen() function in the VBA Macro performs the following tasks in the sequence listed:
- Decodes the target file path of the second stage binary payload. This file path is calculated based on the current user’s Temp folder location:
- Decodes the second stage binary in memory and writes it to the %temp%\.\lsm.exe file location
- After writing the second stage payload to disk the VBA code performs two important actions.
- Runs the second stage payload using cmd.exe. This is done so that the cmd.exe process exists as soon as the payload is launched. This way a process enumeration tool cannot find the parent process => Smaller footprint.
cmdline for executing the second stage binary:
cmd.exe /c start /b <temp_dir_path>\.\lsm.exe /haobao
- Adds persistence on the system by creating a shortcut in the user’s Startup folder with the correct cmdline arguments:
Link file command line: <temp_dir_path>\.\lsm.exe /haobao
Link File Name: GoogleUpdate.lnk
- Once the second stage payload has been launched, the VBA Macro proceeds to display a decoy document to the end user. This decoy document is also stored in the VBA Macro as an encrypted string array (similar to the second stage payload). The decoy document is again written to the user’s temp directory to the following filename/path:
- Once the decoy document has been written to disk, the VBA Macro sets its file attributes to System + Hidden
- The decoy document is then opened by the malicious VBA Macro and the original malicious document’s caption is copied over to the decoy document to trick the end user into mistaking the decoy document for the original (malicious) document.
- This activity, combined with the fact that the VBA Macro then closes the current (malicious) document, indicates that the VBA Macro aims to trick an unsuspecting user into thinking that the decoy document currently open is the original (malicious) document opened by the user.
- Since the decoy document is a benign file and does not contain any macros the victim does not suspect any malicious behavior.
As part of the implant initialization activities the implant does the following;
- Checks the string passed to it through command line
- “/haobao” in case of 535f212b320df049ae8b8ebe0a4f93e3bd25ed79
- “/pumpingcore” in case of e8faa68daf62fbe2e10b3bac775cce5a3bb2999e
If the malware does not find this string in its cmdline arguments, it simply quits without going any further.
- Unwraps a DLL into memory and calls its one-and-only import using Reflective DLL injection. DLL information.
During our research, we discovered additional variants of the DLL file.
- As part of Reflective DLL loading the malware performs the following tasks on the DLL it has unwrapped in memory:
- Copy the unwrapped DLL into new locations in its own memory space.
- Build imports required by the DLL (based on the IAT of the DLL)
- Call the newly loaded DLL image’s Entry Point (DllMain) with DLL_PROCESS_ATTACH to complete successful loading of the DLL in the malware process.
- Call the actual malicious export in the DLL named “CoreDn”
All the malicious activities described below are performed by the DLL unless specified otherwise.
The implant has the capability of gathering data from the victim’s system. The following information will be gathered and sent to the command and control server.
- Computer name and currently logged on user’s name, stored in the format
<ComputerName> \ <Username>
- List of all processes currently running on the system arranged in format
- The presence of a specific registry key on the system
- The malware appends an indicator (flag) specifying whether the above registry key was found in the user’s registry:
This key is checked again as part of the command and control communication and is sent as a duplicate value to the command and control in the HTTP POST request as well (explained in the below).
In preparation of the exfiltration of information collected from the endpoint, the malware performs the following activities:
- Encode the collected information using a simple byte based XOR operation using the byte key: 0x34.
- Base64 encode (standard) the XORed data.
- Again, check for the presence of the Registry Key: HKCU\Software\Bitcoin\Bitcoin-Qt
Command and Control Server Communication
Once the malware has performed all these activities it sends an HTTP POST request to the CnC server:
- www[dot]worker.co.kr for md5 BDAEDB14723C6C8A4688CC8FC1CFE668
- www[dot]palgong-cc.co.kr for md5 D4C93B85FFE88DDD552860B148831026
In the format:
HTTP POST to www[dot]worker.co.kr
HTTP POST to www[dot]palgong-cc.co.kr
idx= 20 (14h) if the Registry key does not exist; 24 (18h) if the key exists.
no= XORed + base64 encoded “<Computername> \ <username>”
mode= XORed + base64 encoded Process listing + Registry key flag
The persistence mechanism of the malware is performed only for the downloaded implant. Persistence is established for the implant via the visual basic macro code initially executed upon document loading by the victim. This persistence is also performed ONLY if the malware successfully executes the downloaded implant. The malware first tries to update the HKEY_LOCAL_MACHINE registry key.
If the update is unsuccessful then it also tries to update the HKEY_CURRENT_USER registry key. Value written to registry to achieve persistence on the endpoint:
Registry Subkey = Software\Microsoft\Windows\CurrentVersion\Run
Value Name = AdobeFlash
Value Content = “C:\DOCUME~1\<username>\LOCALS~1\Temp\OneDrive.exe” kLZXlyJelgqUpKzP
Connections to 2017 campaigns
The techniques, tactics and procedures are very similar to the campaigns that targeted US Defense contractors, US Energy sector, financial organizations and crypto currency exchanges in 2017.
The same Windows User author appeared back in 2017 in two malicious documents 비트코인_지갑주소_및_거래번호.doc and 비트코인 거래내역.xls which were involved in crypto currency targeting. Furthermore, one of the implants communicates to an IP address that was involved in hosting malicious job description documents in 2017 involving the Sikorsky military program.
McAfee Advanced Threat research determines with confidence that Lazarus is the threat group behind this attack for the following reasons:
- Contacts an IP address / domain that was used to host a malicious document from a Lazarus previous campaign in 2017
- Same author appeared in these recent malicious documents that also appeared back in Lazarus 2017 campaigns
- Uses the same malicious document structure and similar job recruitment ads as what we observed in past Lazarus campaigns
- The techniques, tactics and procedures align with Lazarus group’s interest in crypto currency theft
In this latest discovery by McAfee ATR, despite a short pause in similar operations, the Lazarus group targets crypto currency and financial organizations. Furthermore, we have observed an increased usage of limited data gathering modules to quickly identify targets for further attacks. This campaign is tailored to identifying those who are running Bitcoin related software through specific system scans.
Indicators of Compromise
MITRE ATT&CK techniques
- Data encoding
- Data encrypted
- Command-Line Interface
- Account discovery
- Process Discovery
- Query registry
- Hidden files and directories
- Custom cryptographic protocol
- Registry Run Keys / Start Folder
- Startup Items
- Commonly used port
- Exfiltration Over Command and Control Channel
- hxxps://www.dropbox.com/s/q7w33sbdil0i1w5/job description.doc?dl=1
- RDN/Generic Downloader.x
- RDN/Generic Dropper
The post Lazarus Resurfaces, Targets Global Banks and Bitcoin Users appeared first on McAfee Blogs.
Incoming search terms
More antivirus and malware news?
- Superior VMware® Protection for Limited IT Budgets
- 10 best Linux distros for privacy fiends and security buffs in 2017
- Cost of data breaches declines
- Resolved: win.pass.psu.edu (18.104.22.168) and explorer.pass.psu.edu (22.214.171.124) to be moved to a new load balancer – May 17
- Advent tip #16: Logout when you’re done. Yes, even from Facebook!
- Remember, Remember the Fifth of November
- Was Russia Today hacked – or did it just forget to renew it’s domain?
- Security: A True Crown Jewel of Software
- Apple’s two-step verification system has a major problem
- Where are the holes in machine learning – and can we fix them?