By Anthony Jirouschek, Security Architect
On July 2nd, we published an article about an attack we observed using EtherHiding and Fake-Updates to deliver the Lumma infostealer.
After the article was published, we did some threat hunting and found a different version of this attack that uses encoding to obfuscate, or hide, the attack better.
As a refresher, EtherHiding is using smart contracts on a crypto platform to obscure and deliver malicious code. Fake-Updates are used to trick the end user into downloading what they think is legitimate software by displaying popups stating an update is required.
Fake-Updates tend to mimic the pages of common software, like Google Chrome. Using this attack vector requires a user to browse to a website, which would then execute the malicious JavaScript displaying the Fake-Update window or popup, and the user to execute the malicious logic either manually in a shell or by clicking a button that executes additional JavaScript code.
The attack differs from the previously identified one due to using Base64 (b64) to encode the JavaScript.
The top function loads the "ethers-5.2.umd.min.js" library seen previously. This library, or a version of it, is a requirement in any attack that uses Smart Contracts. This is because the library contains functions observed in both attacks, including "new ethers.Contract" and "new ethers.providers.JsonRpcProvider".
The output of this Smart Contract is another large b64 encoded blob.
This blob contains a function with obfuscated variable names that has been decoded below. The purpose of the function is to request the 3rd stage from "daslkjfhi2[.]xyz/page".
The response received appears to be a Base64 encoded HTML page.
The HTML page that was decoded contains the Fake-Update message that is presented to users! Ironic that this "update" contains "AI for malware site detection," when it's being used to deliver malware. The threat actor definitely had a laugh when they added that.
The "Update now" button will likely download additional malicious code to the user's device. This can be verified by inspecting the HTML page and button.
The HTML page doesn't reveal any method to start the malware once it has been downloaded.
In the previous case, the threat actor chose to use PowerShell as their language throughout the entire chain after displaying the Fake-Update page.
Because this current threat actor used JavaScript and kept the attack in the browser, a container escape is needed to interact with the underlying operating system. Without a novel container escape, the threat actor is relying on the user's interaction once again.
After downloading the file, the SHA256 hash was pulled.
The file is also identified as a 32 bit PE file that has been stripped.
Checking the filehash in VirusTotal revealed only 4 AV engines were detecting the file at the intial time of writing.
This file was inspected by a few public sandboxes, but a clear malware family was not established. It's likely a form of cryptojacking, infostealer, and/or clipboard stealer malware. Joe Sandbox classified the file as MicroClip malware.
Knowing that it's likely uploading sensitive data of compromised users, the network traffic was reviewed. Only one IP was repeatedly contacted and showed as establishing a socket connection, 193[.]3[.]19[.]110. The executable also calls out to "ip-api[.]com" and grabs the public IP of the host executing.
| daslkjfhi2[.]xyz/page |
| https://bitbucket[.]org/holliwoodip/updater/downloads/BrowserUpdate.exe |
| 193.3.19[.]110:443 |
For a complete list of IOCs and related activity, please use the VirusTotal link and your favorite sandbox, like Joe Sandbox, AnyRun, VMRay, etc.
If you have an issue you would like WYRE to investigate, please contact us.