A phishing campaign targeting attendees of Black Hat and DEF CON conferences involved distributing information-stealing malware and remote access malware via a malicious Google Doc and fake DocSend installers for macOS and Windows.
The Huntress team learned about the phishing attack after one of its researchers received a direct message on X on August 9. The message came from an account that claimed to be the vice president and marketing head of CoinDesk and wanted to know about the researcher’s plans to attend future conferences.
The researcher spotted the scam but kept the conversation going to find out what the attacker was trying to do. Huntress later found the same account approaching other conference attendees with similar messages and posting content apparently intended to make the account look legitimate.
The threat actor eventually sent a Google Doc presented as a planning document for the proposed conference. It appeared to be partially encrypted and required an access key, which the attacker supplied separately through X.
The key did not work. That appears to have been intentional.
Instead of opening the document, the failed decryption led the target to instructions for fixing the problem. Those instructions were the start of the malware delivery process.
The Google Doc was part of the attack
The document contained a custom Google Apps Script sidebar built around a file called DecryptPanel.html. According to Huntress, the script checked a small number of hard-coded keys, gathered information about the victim and their computer, reported activity through Telegram, and selected a payload according to whether the target was using macOS or Windows. Researchers also found Russian-language comments in the code.
After the access key failed, the sidebar offered “Document Decryption” instructions and a separate “Manual Update” option.
Both were designed to get malware onto the target’s computer.
On macOS, the first option told the user to copy a command into Terminal, run it, and return to the document. Huntress was unable to retrieve the intended payload because the remote address entered a redirect loop during testing.
The manual option still worked differently. It sent the victim to a GitHub Releases page containing GAPIUpdate.dmg. The accompanying instructions told the user how to bypass macOS Gatekeeper and required them to enter their password.
Analysis of the disk image found characteristics consistent with Atomic macOS Stealer, or AMOS.
The malware went after browser passwords and cookies, cryptocurrency wallets, Keychain data, and Telegram files. It also requested access to the victim’s Notes database, copied the contents to an HTML file, staged the stolen information in /tmp/lksopo, and sent it to attacker-controlled infrastructure.
Huntress found another component designed to keep access to the Mac after the initial infection. A LaunchDaemon installed AppleScript code that repeatedly contacted command-and-control infrastructure for instructions.
Among the commands supported by the backdoor were arbitrary shell execution and an option to enable a SOCKS5 proxy, allowing the compromised Mac to be used as a proxy node.
Windows users were sent down a different path
Windows users saw the same failed decryption before being told that a “Google API Connector” needed an update.
The update button launched a Windows ClickOnce deployment from infrastructure controlled by the attacker. The application carried a certificate belonging to Norwegian company BARNEHAGEN GUNHILDS MINNE AS, which Huntress said appeared to have been stolen or fraudulently issued.
After installation, the application displayed an HTML page made to look like the Google Workspace Marketplace while it downloaded further payloads in the background.
Targets who chose the manual installation route were instead told to copy and paste an encrypted PowerShell command. The command created a temporary PowerShell file, downloaded and executed a loader, then deleted the temporary file.
A small installation window and fake progress bar gave the victim something to watch while this happened.
The loader tried to retrieve several encrypted payloads, although the files were returning 404 errors by the time Huntress investigated them. Researchers found related binaries on VirusTotal and infrastructure associated with a PowerShell-based malware loader.
The attacker was not finished.
When the Huntress researcher did not install the malware, another malicious document arrived the following day.
The second attempt impersonated DocSend
This time, the file masqueraded as a Dropbox DocSend share. The recipient was told that a desktop version of DocSend was required to view it.
The download site checked the browser’s User-Agent and served a different installer depending on the operating system.
Mac users received DocSendInstaller.zip, which contained the same AMOS infostealer used in the Google Docs attack.
Windows users were offered DocsendInstaller.exe, an Electron application packaged inside an NSIS installer. Huntress found it had been signed with a code-signing certificate stolen from Discord, although the signature did not validate. The installer did not install legitimate Dropbox software.
It did a good job of looking as though it had.
Victims were shown a five-screen onboarding sequence built with genuine Dropbox marketing material and screenshots. It even included a link to the real Dropbox website. On the final screen, an “Open Dropbox” button displayed a spinner for several seconds, creating the impression that the application was starting.
The loader was working in the background.
It collected the computer’s hardware ID, hostname, username, Windows build, CPU and GPU details, BIOS information, network adapters, available memory, and installed keyboard layouts. That profile was sent to attacker infrastructure, which could respond with JavaScript that the loader executed directly in memory.
The command server for the sample was already offline when Huntress tested it. Researchers traced related infrastructure instead and found other branded versions of the same operation. By reproducing the malware’s request against a live SignNow-themed campaign, they recovered a working second stage.
Before writing anything to disk, that stage took a screenshot of the victim’s desktop and uploaded it. It then downloaded three password-protected archives containing separate payloads.
NetSupport provided remote access
The first archive contained NetSupport Manager, legitimate remote administration software that is also frequently abused as a remote access trojan.
The configuration had been changed to hide it from the victim. The tray icon was disabled, silent mode was enabled, and alerts for connections, disconnections, chat, and messaging were switched off.
Its command-and-control domains, msedgewebview1[.]pro and msedgewebview2[.]pro, were named to resemble Microsoft Edge WebView traffic. Huntress also found that the traffic used cleartext HTTP over port 443 rather than TLS.
The result was persistent remote access with few visible signs on the compromised computer.
The second payload arrived disguised as a Lenovo driver package and used a stolen Lenovo code-signing certificate, although that signature also failed validation.
It hollowed the legitimate Windows MsBuild.exe process and created a self-signed certificate authority on the computer that presented itself as Google Trust Services.
The malware then issued its own certificate for VirusTotal, changed the Windows hosts file so www.virustotal.com resolved to localhost, and created a firewall rule for a local proxy.
Traffic intended for VirusTotal could therefore be intercepted locally using a certificate that the infected Windows system trusted. Searches could be blocked or returned with fabricated results.
Huntress only observed VirusTotal being targeted. However, the private key for the rogue certificate authority was written to disk, making it possible to generate trusted certificates for other domains.
The changes also outlived the malware process itself. The certificate authority, hosts file entry, and firewall rule persisted after a reboot, making them particularly important artifacts to find during remediation.
A third payload went looking for Ledger wallets
The final payload used the same cryptor and Lenovo disguise as the certificate authority malware but had a different purpose.
It searched for Ledger Live and Ledger Wallet installations and checked their configuration files. The malware created a bot identifier inside Ledger’s application data directory and used it when polling its command server.
Huntress watched the implant contact the server 18 times during testing. No commands were returned. Researchers said the behavior was consistent with an operator reviewing compromised machines before deciding what to do with them.
The Ledger component had a flaw in its persistence mechanism, but NetSupport gave the attacker interactive access to the computer and could be used to restart other malware when required.
The combination of remote access, cryptocurrency wallet targeting, and the ability to interfere with encrypted traffic points to cryptocurrency as an important part of the operation. The macOS malware also specifically targeted cryptocurrency wallets alongside passwords, cookies, and other data.
Huntress found signs that the infrastructure was being used for more than the attack against its researcher. The loader appeared under several brands, while payload and command servers followed a numbered naming scheme. Researchers believe the setup points to a larger operation than the systems they were able to observe directly.
Even after two failed malware attempts, the attacker kept trying.
Huntress said the same person eventually switched to what appeared to be a funding scam, possibly in an attempt to steal credentials or personally identifiable information.
Conference contacts remain useful phishing lures
The campaign arrived just after Black Hat and DEF CON, when attendees were receiving messages from new contacts and discussing future events. Huntress said the attacker had approached a large number of attendees using boilerplate replies and conference planning as the opening pitch.
The malware delivery still required victims to do things that should raise suspicion. Depending on the route, they were asked to paste commands into Terminal or PowerShell, bypass Gatekeeper, install an unexpected software update, or enter a device password.
Huntress recommends isolating systems that may have interacted with the campaign, preserving relevant forensic evidence, and considering a full reimage. Credentials stored on an affected computer should be treated as compromised, active sessions revoked, passwords reset, and API keys and other secrets rotated. Cryptocurrency wallets on the system should also be reviewed.
Huntress has published indicators of compromise for the macOS and Windows components of the campaign.
Information Security Buzz News Editor
Kirsten Doyle has been in the technology journalism and editing space for nearly 24 years, during which time she has developed a great love for all aspects of technology, as well as words themselves. Her experience spans B2B tech, with a lot of focus on cybersecurity, cloud, enterprise, digital transformation, and data centre. Her specialties are in news, thought leadership, features, white papers, and PR writing, and she is an experienced editor for both print and online publications.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.