There are new articles available, click to refresh the page.
Before yesterdaySentinelLabs

CrateDepression | Rust Supply-Chain Attack Infects Cloud CI Pipelines with Go Malware

19 May 2022 at 14:57

By Juan Andrés Guerrero-Saade & Phil Stokes

Executive Summary

  • SentinelLabs has investigated a supply-chain attack against the Rust development community that we refer to as ‘CrateDepression’.
  • On May 10th, 2022, the Rust Security Response Working Group released an advisory announcing the discovery of a malicious crate hosted on the Rust dependency community repository.
  • The malicious dependency checks for environment variables that suggest a singular interest in GitLab Continuous Integration (CI) pipelines.
  • Infected CI pipelines are served a second-stage payload. We have identified these payloads as Go binaries built on the red-teaming framework, Mythic.
  • Given the nature of the victims targeted, this attack would serve as an enabler for subsequent supply-chain attacks at a larger-scale relative to the development pipelines infected.
  • We suspect that the campaign includes the impersonation of a known Rust developer to poison the well with source code that relies on the typosquatted malicious dependency and sets off the infection chain.


On May 10th, 2022, the Rust dependency community repository crates.io released an advisory announcing the removal of a malicious crate, ‘rustdecimal’. In an attempt to fool rust developers, the malicious crate typosquats against the well known rust_decimal package used for fractional financial calculations. An infected machine is inspected for the GITLAB_CI environment variable in an attempt to identify Continuous Integration (CI) pipelines for software development.

On those systems, the attacker(s) pull a next-stage payload built on the red-teaming post-exploitation framework Mythic. The payload is written in Go and is a build of the Mythic agent ‘Poseidon’. While the ultimate intent of the attacker(s) is unknown, the intended targeting could lead to subsequent larger scale supply-chain attacks depending on the GitLab CI pipelines infected.

Technical Analysis

The malicious package was initially spotted by an avid observer and reported to the legitimate rust_decimal github account. A subsequent investigation by the crates.io security team and Rust Security Response working group turned up 15 iterative versions of the malicious ‘rustdecimal’ as the attacker(s) tested different approaches and refinements. Ranging from versions 1.22.0 to 1.23.5, the malicious crate would function identically to the legitimate version except for the addition of a single function, Decimal::new. This function contains code lightly obfuscated with a five byte XOR key.

rustdecimal v1.23.4 decimal.rs XOR decryption function

Focusing on the obfuscated strings provides a pretty clear picture of the intended effects at this stage of the attack.

The attacker sets a hook on std::panic so that any unexpected errors throw up the following (deobfuscated) string: “Failed to register this runner. Perhaps you are having network problems”. This is a more familiar error message for developers running GitLab Runner software for CI pipelines.

The theme of the error message betrays the attacker’s targeting. The bit_parser() function checks that the environment variable GITLAB_CI is set; otherwise, it throws the error “503 Service Unavailable”. If the environment variable is set, meaning that the infected machine is likely a GitLab CI pipeline, the malicious crate checks for the existence of a file at /tmp/git-updater.bin. If the file is absent, then it calls the check_value() function.

rustdecimal v1.23.4 decimal.rs check_value() pulls the second-stage payload

Depending on the host operating system, check_value() deobfuscates a URL and uses a curl request to download the payload and save it to /tmp/git-updater.bin. Two URLs are available:

Linux https://api.githubio[.]codes/v2/id/f6d50b696cc427893a53f94b1c3adc99/READMEv2.bin
macOS https://api.githubio[.]codes/v2/id/f6d50b696cc427893a53f94b1c3adc99/README.bin

Once available, rustdecimal issues the appropriate commands to set the binary as executable and spawn it as a fork. In macOS systems, it takes the extra step of clearing the quarantine extended attribute before executing the payload.

If any of these commands fail, an expect() routine will throw up a custom error: “ERROR 13: Type Mismatch”.

Second-Stage Payloads

The second-stage payloads come in ELF and Mach-O form, with the latter compiled only for Apple’s Intel Macs. The malware will still run on Apple M1 Macs provided the user has previously installed Rosetta.

Mach-O Technical Details

SHA256 74edf4ec68baebad9ef906cd10e181b0ed4081b0114a71ffa29366672bdee236
SHA1 c91b0b85a4e1d3409f7bc5195634b88883367cad
MD5 95413bef1d4923a1ab88dddfacf8b382
Filetype Mach-O 64-bit executable x86_64
Size 6.5mb
Filename ‘README.bin’ dropped as ‘/tmp/git-updater.bin’
C&C api.kakn[.]li resolving to

Both binaries are built against Go 1.17.8 and are unsigned Poseidon payloads, agent installations for the Mythic post-exploitation red-teaming framework. While Mythic has a number of possible agent types, Poseidon is the most suitable for an attacker looking to compromise both Linux and more recent macOS versions. Written in Go, Poseidon avoids the dependency problems that Macs have with Mythic agents written in Python, AppleScript and JXA.

On execution, the second-stage payload performs a number of initial setup procedures, taking advantage of Go’s goroutines feature to execute these concurrently. The function profile.Start() then initiates communication with the C2.

Left: Poseidon source code; Right: disassembly from README.bin sample

Both samples reach out to the same C2 for tasking:


At the time of our investigation, the C2 was unresponsive, but analysis of the binary and the Poseidon source shows that the payload contains a switch with a large array of tasking options, including screencapture, keylogging, uploading and downloading files. On macOS, the operator can choose to persist by either or both of a LaunchAgent/Daemon and a LoginItem.

Tasking options available to the operator of the Poseidon payload

The Linux version is practically an identical cross-compilation of the same codebase–

BinDiff comparison of Linux and Mach-O versions

ELF Technical Details

SHA256 653c2ef57bbe6ac3c0dd604a761da5f05bb0a80f70c1d3d4e5651d8f672a872d
SHA1 be0e8445566d3977ebb6dbb6adae6d24bfe4c86f
MD5 1c9418a81371c351c93165c427e70e8d
Filetype ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=ce4cf8031487c7afd2df673b9dfb6aa0fd6a680b, stripped
Size 6.3mb
Filename ‘READMEv2.bin’ dropped as ‘/tmp/git-updater.bin’
C&C api.kakn[.]li resolving to

There are some notable dependency differences to enable OS specific capabilities. For example, the Linux version does not rely on RDProcess but adds libraries like xgb to communicate with the Linux X protocol.

Ultimately, both variants serve as an all-purpose backdoor, rife with functionality for an attacker to hijack an infected host, persist, log keystrokes, inject further stages, screencapture, or simply remotely administer in a variety of ways.

Campaign Cycle

The campaign itself is a little more opaque to us. We became aware of this supply-chain attack via the crates.io security advisory, but by then the attacker(s) had already staged multiple versions of their malicious crate. In order to do so, the first few versions were submitted by a fake account ‘Paul Masen’, an approximation of the original rust_decimal developer Paul Mason.

Cached version of Lib.Rs that still lists the fake ‘Paul Masen’ contributor account

That account is in turn linked to a barebones Github account ‘MarcMayzl’. That account is mostly bereft of content except for a single repository with two very suspect files.

Github account ‘MarcMayzl’ that contributed the malicious repos to crates.io

The files, named tmp and tmp2 are SVG files for the popular Github Readme Stats. However, these stats are generated in the name of a legitimate, predominantly Rust-focused, developer. This appears to be an attempt to impersonate a trusted Rust developer and is likely our best clue as to what the original infection vector of this campaign may be.

Fake Github Readme Stats impersonating a predominantly Rust developer

If we think through the campaign cycle, the idea of simply typosquatting a popular dependency isn’t a great way to infect a specific swath of targets running GitLab CI pipelines. We are missing a part of the picture where code is being contributed or suggested to a select population that includes a reference to the malicious typosquatted dependency. This is precisely where impersonating a known Rust developer might allow the attackers to poison the well for a target rich population. We will continue to investigate this avenue and welcome contributions from the Rust developer community in identifying these and further tainted sources.


Software supply-chain attacks have gone from a rare occurrence to a highly desirable approach for attackers to ‘fish with dynamite’ in an attempt to infect entire user populations at once. In the case of CrateDepression, the targeting interest in cloud software build environments suggests that the attackers could attempt to leverage these infections for larger scale supply-chain attacks.


We’d like to acknowledge Carol Nichols, the crates.io team, and the Rust Security Response working group for their help and responsible stewardship. We also extend a sincere thank you to multiple security researchers that enabled us to flesh out and analyze this campaign, including Wes Shields.

Indicators of Compromise

Malicious Crates 

(not to be confused with ‘rust_decimal’)

SHA1 Filename
be62b4113b8d6df0e220cfd1f158989bad280a57 rustdecimal-1.22.0.crate.tar.gz
7fd701314b4a2ea44af4baa9793382cbcc58253c 1.22.0/src/decimal.rs
bd927c2e1e7075b6ed606cf1e5f95a19c9cad549 rustdecimal-1.22.1.crate.tar.gz
13f2f14bc62de8857ef829319145843e30a2e4ea 1.22.1/src/decimal.rs
609f80fd5847e7a69188458fa968ecc52bea096a rustdecimal-1.22.2.crate.tar.gz
f578f0e6298e1055cdc9b012d8a705bc323f6053 1.22.2/src/decimal.rs
2f8be17b93fe17e2f97871654b0fc2a1c2cb4ed3 rustdecimal-1.22.3.crate.tar.gz
b8a9f5bc1f56f8431286461fe0e081495f285f86 1.22.3/src/decimal.rs
051d3e17b501aaacbe1deebf36f67fd909aa6fbc rustdecimal-1.22.4.crate.tar.gz
5847563d877d8dc1a04a870f6955616a1a20b80e 1.22.4/src/decimal.rs
99f7d1ec6d5be853eb15a8c6e6f09edd0c794a50 rustdecimal-1.22.5.crate.tar.gz
a28b44c8882f786d3d9ff18a596db92b7e323a56 1.22.5/src/decimal.rs
5a9e79ff3e87a9c7745e423de8aae2a4da879f08 rustdecimal-1.22.6.crate.tar.gz
90551abe66103afcb6da74b0480894d68d9303c2 1.22.6/src/decimal.rs
fd63346faca7da3e7d714592a8222d33aaf73e09 rustdecimal-1.22.7.crate.tar.gz
4add8c27d5ce7dd0541b5f735c37d54bc21939d1 1.22.7/src/decimal.rs
8c0efac2575f06bcc75ab63644921e8b057b3aa1 rustdecimal-1.22.8.crate.tar.gz
16faf72d9d95b03c74193534367e08b294dcb27a 1.22.8/src/decimal.rs
ddca9d5a32aebc5a8106b4a3d2e22200898af91d rustdecimal-1.22.9.crate.tar.gz
34a06b4664d0077f69b035414b8e85e9c2419962 1.22.9/src/decimal.rs
009bb8cef14d39237e0f33c3c088055ce185144f rustdecimal-1.23.0.crate.tar.gz
a6c803fc984fd20ba8c2118300c12d671403f864 1.23.0/src/decimal.rs
c5f2a35c924003e43dabc04fc8bbc5f26a736a80 rustdecimal-1.23.1.crate.tar.gz
d0fb17e43c66689602bd3147d905d388b0162fc5 1.23.1/src/decimal.rs
a14d34bb793e86eec6e6a05cd6d2dc4e72c96de9 rustdecimal-1.23.2.crate.tar.gz
a21af73e14996be006e8313aa47a15ddc402817a 1.23.2/src/decimal.rs
a4a576ea624f82e4305ca9e83b567bdcf9e15da7 rustdecimal-1.23.3.crate.tar.gz
98c531ba4d75e8746d0129ad7914c64e333e5da8 1.23.3/src/decimal.rs
016c3399c9f4c90af09d028b32f18e70c747a0f6 rustdecimal-1.23.4.crate.tar.gz
a0516d583c2ab471220a0cc4384e7574308951af 1.23.4/src/decimal.rs
987112d87e5bdfdfeda906781722d87f397c46e7 rustdecimal-1.23.5.crate.tar.gz
88cbd4f284ba5986ba176494827b7252c826ff75 1.23.5/src/decimal.rs

Second-Stage Payloads

Filename SHA1
README.bin (Mach-O, Intel) c91b0b85a4e1d3409f7bc5195634b88883367cad
READMEv2.bin (ELF) be0e8445566d3977ebb6dbb6adae6d24bfe4c86f

Network Indicators


AcidRain | A Modem Wiper Rains Down on Europe

31 March 2022 at 15:04

By Juan Andres Guerrero-Saade (@juanandres_gs) and Max van Amerongen (@maxpl0it)

Executive Summary

  • On Thursday, February 24th, 2022, a cyber attack rendered Viasat KA-SAT modems inoperable in Ukraine.
  • Spillover from this attack rendered 5,800 Enercon wind turbines in Germany unable to communicate for remote monitoring or control.
  • Viasat’s statement on Wednesday, March 30th, 2022 provides a somewhat plausible but incomplete description of the attack.
  • SentinelLabs researchers discovered new malware that we named ‘AcidRain’.
  • AcidRain is an ELF MIPS malware designed to wipe modems and routers.
  • We assess with medium-confidence that there are developmental similarities between AcidRain and a VPNFilter stage 3 destructive plugin. In 2018, the FBI and Department of Justice attributed the VPNFilter campaign to the Russian government
  • AcidRain is the 7th wiper malware associated with the Russian invasion of Ukraine.
  • Update: In a statement disseminated to journalists, Viasat confirmed the use of the AcidRain wiper in the February 24th attack against their modems.


The Russian invasion of Ukraine has included a wealth of cyber operations that have tested our collective assumptions about the role that cyber plays in modern warfare. Some commentators have voiced a bizarre disappointment at the ‘lack of cyber’ while those at the coalface are overwhelmed by the abundance of cyber operations accompanying conventional warfare. From the beginning of 2022, we have dealt with six different strains of wiper malware targeting Ukraine: WhisperKill, WhisperGate, HermeticWiper, IsaacWiper, CaddyWiper, and DoubleZero. These attacks are notable on their own. But there’s been an elephant in the room by way of the rumored ‘satellite modem hack’. This particular attack goes beyond Ukraine.

We first became aware of an issue with Viasat KA-SAT routers due to a reported outage of 5,800 Enercon wind turbines in Germany. To clarify, the wind turbines themselves were not rendered inoperable but “remote monitoring and control of the wind turbines” became unavailable due to issues with satellite communications. The timing coincided with the Russian invasion of Ukraine and suspicions arose that an attempt to take out Ukrainian military command-and-control capabilities by hindering satellite connectivity spilled over to affect German critical infrastructure. No technical details became available; technical speculation has been rampant.

On Wednesday, March 30th, 2022, Viasat finally released a statement stating that the attack took place in two phases: First, a denial of service attack coming from “several SurfBeam2 and SurfBeam2+ modems and […other on-prem equipment…] physically located within Ukraine” that temporarily knocked KA-SAT modems offline. Then, the gradual disappearance of modems from the Viasat service. The actual service provider is in the midst of a complex arrangement where Eutalsat provides the service, but it’s administered by an Italian company called Skylogic as part of a transition plan.

The Viasat Explanation

At the time of writing, Viasat has not provided any technical indicators nor an incident response report. They did provide a general sense of the attack chain with conclusions that are difficult to reconcile.

Viasat reports that the attackers exploited a misconfigured VPN appliance, gained access to the trust management segment of the KA-SAT network, moved laterally, then used their access to “execute legitimate, targeted management commands on a large number of residential modems simultaneously”. Viasat goes on to add that “these destructive commands overwrote key data in flash memory on the modems, rendering the modems unable to access the network, but not permanently unusable”.

It remains unclear how legitimate commands could have such a disruptive effect on the modems. Scalable disruption is more plausibly achieved by pushing an update, script, or executable. It’s also hard to envision how legitimate commands would enable either the DoS effects or render the devices unusable but not permanently bricked.

In effect, the preliminary Viasat incident report posits the following requirements:

  1. Could be pushed via the KA-SAT management segment onto modems en masse
  2. Would overwrite key data in the modem’s flash memory
  3. Render the devices unusable, in need of a factory reset or replacement but not permanently unusable.

With those requirements in mind, we postulate an alternative hypothesis: The threat actor used the KA-SAT management mechanism in a supply-chain attack to push a wiper designed for modems and routers. A wiper for this kind of device would overwrite key data in the modem’s flash memory, rendering it inoperable and in need of reflashing or replacing.

Subsequent to this post being published, Viasat confirmed to journalists that our analysis was consistent with their reports.

Viasat told BleepingComputer that “The analysis in the SentinelLabs report regarding the ukrop binary is consistent with the facts in our report – specifically, SentinelLabs identifies the destructive executable that was run on the modems using a legitimate management command as Viasat previously described”.

The AcidRain Wiper

On Tuesday, March 15th, 2022, a suspicious upload caught our attention. A MIPS ELF binary was uploaded to VirusTotal from Italy with the name ‘ukrop’. We didn’t know how to parse the name accurately. Possible interpretations include a shorthand for “ukr”aine “op”eration, the acronym for the Ukrainian Association of Patriots, or a Russian ethnic slur for Ukrainians – ‘Укроп’. Only the incident responders in the Viasat case could say definitively whether this was in fact the malware used in this particular incident. We posit its use as a fitting hypothesis and will describe its functionality, quirky development traits, and possible overlaps with previous Russian operations in need of further research.

Technical Overview

SHA256 9b4dfaca873961174ba935fddaf696145afe7bbf5734509f95feb54f3584fd9a
SHA1 86906b140b019fdedaaba73948d0c8f96a6b1b42
MD5 ecbe1b1e30a1f4bffaf1d374014c877f
Name ukrop
Magic ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
First Seen 2022-03-15 15:08:02 UTC

AcidRain’s functionality is relatively straightforward and takes a bruteforce attempt that possibly signifies that the attackers were either unfamiliar with the particulars of the target firmware or wanted the tool to remain generic and reusable. The binary performs an in-depth wipe of the filesystem and various known storage device files. If the code is running as root, AcidRain performs an initial recursive overwrite and delete of non-standard files in the filesystem.

Recursively delete files in nonstandard folders

Following this, it attempts to destroy the data in the following storage device files:

Targeted Device(s) Description
/dev/sd* A generic block device
/dev/mtdblock* Flash memory (common in routers and IoT devices)
/dev/block/mtdblock* Another potential way of accessing flash memory
/dev/mtd* The device file for flash memory that supports fileops
/dev/mmcblk* For SD/MMC cards
/dev/block/mmcblk* Another potential way of accessing SD/MMC cards
/dev/loop* Virtual block devices

This wiper iterates over all possible device file identifiers (e.g., mtdblock0 – mtdblock99), opens the device file, and either overwrites it with up to 0x40000 bytes of data or (in the case of the /dev/mtd* device file) uses the following IOCTLS to erase it: MEMGETINFO, MEMUNLOCK, MEMERASE, and MEMWRITEOOB. In order to make sure that these writes have been committed, the developers run an fsync syscall.

The code that generates the malicious data used to overwrite storage

When the overwriting method is used instead of the IOCTLs, it copies from a memory region initialized as an array of 4-byte integers starting at 0xffffffff and decrementing at each index. This matches what others had seen after the exploit had taken place.

Side-by-side comparison of a Surfbeam2 modem pre- and post-attack

The code for both erasure methods can be seen below:

Mechanisms to erase devices: write 0x40000 (left) or use MEM* IOCTLS (right)

Once the various wiping processes are complete, the device is rebooted.

Redundant attempts to reboot the device

This results in the device being rendered inoperable.

An Interesting Oddity

Despite what the Ukraine invasion has taught us, wiper malware is relatively rare. More so wiper malware aimed at routers, modems, or IoT devices. The most notable case is VPNFilter, a modular malware aimed at SOHO routers and QNAP storage devices, discovered by Talos. This was followed by an FBI indictment attributing the operation to Russia (APT28, in particular). More recently, the NSA and CISA attributed VPNFilter to Sandworm (a different threat actor attributed to the same organization, the Russian GRU) as the U.K.’s National Cyber Security Centre (NCSC) described VPNFilter’s successor, Cyclops Blink.

VPNFilter included an impressive array of functionality in the form of multi-stage plugins selectively deployed to the infected devices. The functionality ranges from credential theft to monitoring Modbus SCADA protocols. Among its many plugins, it also included functionality to wipe and brick devices as well as DDoS a target.

The reason we bring up the specter of VPNFilter is not because of its superficial similarities to AcidRain but rather because of an interesting (but inconclusive) code overlap between a specific VPNFilter plugin and AcidRain.

VPNFilter Stage 3 Plugin – ‘dstr’

SHA256 47f521bd6be19f823bfd3a72d851d6f3440a6c4cc3d940190bdc9b6dd53a83d6
SHA1 261d012caa96d3e3b059a98388f743fb8d39fbd5
MD5 20ea405d79b4de1b90de54a442952a45
Description VPNFilter Stage 3, ‘dstr’ module
Magic ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
First Seen 2018-06-06 13:02:56 UTC

After the initial discovery of VPNFilter, additional plugins were revealed by researchers attempting to understand the massive spread of the botnet and its many intricacies. Among these were previously unknown plugins, including ‘dstr’. As the mangled name suggests, it’s a ‘destruction’ module meant to supplement stage 2 plugins that lacked the ‘kill’ command meant to wipe the devices.

This plugin was brought to our attention initially by tlsh fuzzy hashing, a more recent matching library that’s proven far more effective than ssdeep or imphash in identifying similar samples. The similarity was at 55% to AcidRain with no other samples being flagged in the VT corpus. This alone is not nearly enough to conclusively judge the two samples as tied, but it did warrant further investigation.

VPNFilter and AcidRain are both notably similar and dissimilar. They’re both MIPS ELF binaries and the bulk of their shared code appears to stem from statically-linked libc. It appears that they may also share a compiler, most clearly evidenced by the identical Section Headers Strings Tables.

Section Headers Strings Tables for VPNFilter and AcidRain

And there are other development quirks, such as the storing of the previous syscall number to a global location before a new syscall. At this time, we can’t judge whether this is a shared compiler optimization or a strange developer quirk.

More notably, while VPNFilter and AcidRain work in very different ways, both binaries make use of the MEMGETINFO, MEMUNLOCK, and MEMERASE IOCTLS to erase mtd device files.

On the left, AcidRain; on the right, VPNFilter

There are also notable differences between VPNFilter’s ‘dstr’ plugin and AcidRain. The latter appears to be a far sloppier product that doesn’t consistently rise to the coding standards of the former. For example, note the redundant use of process forking and needless repetition of operations.

They also appear to serve different purposes, with the VPNFilter plugin targeting specific devices with hardcoded paths, and AcidRain taking more of a “one-binary-fits-all” approach to wiping devices. By brute forcing device filenames, the attackers can more readily reuse AcidRain against more diverse targets.

We invite the research community to stress test this developmental overlap and contribute their own findings.


As we consider what’s possibly the most important cyber attack in the ongoing Russian invasion of Ukraine, there are many open questions. Despite Viasat’s statement claiming that there was no supply-chain attack or use of malicious code on the affected routers, we posit the more plausible hypothesis that the attackers deployed AcidRain (and perhaps other binaries and scripts) to these devices in order to conduct their operation.

While we cannot definitively tie AcidRain to VPNFilter (or the larger Sandworm threat cluster), we note a medium-confidence assessment of non-trivial developmental similarities between their components and hope the research community will continue to contribute their findings in the spirit of collaboration that has permeated the threat intelligence industry over the past month.



HermeticWiper | New Destructive Malware Used In Cyber Attacks on Ukraine

24 February 2022 at 05:40

This post was updated Feb 28th 2022 to include new IOCs and the PartyTicket ‘decoy ransomware’.

Executive Summary

  • On February 23rd, the threat intelligence community began observing a new wiper malware sample circulating in Ukrainian organizations.
  • Our analysis shows a signed driver is being used to deploy a wiper that targets Windows devices, manipulating the MBR resulting in subsequent boot failure.
  • This blog includes the technical details of the wiper, dubbed HermeticWiper, and includes IOCs to allow organizations to stay protected from this attack.
  • This sample is actively being used against Ukrainian organizations, and this blog will be updated as more information becomes available.
  • We also analyze a ‘ransomware’, called PartyTicket, reportedly used as a decoy during wiping operations.
  • SentinelOne customers are protected from this threat, no action is needed.


On February 23rd, our friends at Symantec and ESET research tweeted hashes associated with a wiper attack in Ukraine, including one which is not publicly available as of this writing.

We started analyzing this new wiper malware, calling it ‘HermeticWiper’ in reference to the digital certificate used to sign the sample. The digital certificate is issued under the company name ‘Hermetica Digital Ltd’ and valid as of April 2021. At this time, we haven’t seen any legitimate files signed with this certificate. It’s possible that the attackers used a shell company or appropriated a defunct company to issue this digital certificate.

HermeticWiper Digital Signature

This is an early effort to analyze the first available sample of HermeticWiper. We recognize that the situation on the ground in Ukraine is evolving rapidly and hope that we can contribute our small part to the collective analysis effort.

Technical Analysis

At first glance, HermeticWiper appears to be a custom-written application with very few standard functions. The malware sample is 114KBs in size and roughly 70% of that is composed of resources. The developers are using a tried and tested technique of wiper malware, abusing a benign partition management driver, in order to carry out the more damaging components of their attacks. Both the Lazarus Group (Destover) and APT33 (Shamoon) took advantage of Eldos Rawdisk in order to get direct userland access to the filesystem without calling Windows APIs. HermeticWiper uses a similar technique by abusing a different driver, empntdrv.sys.

HermeticWiper resources containing EaseUS Partition Manager drivers

The copies of the driver are ms-compressed resources. The malware deploys one of these depending on the OS version, bitness, and SysWow64 redirection.

EaseUS driver resource selection

The benign EaseUS driver is abused to do a fair share of the heavy-lifting when it comes to accessing Physical Drives directly as well as getting partition information. This adds to the difficulty of analyzing HermeticWiper, as a lot of functionality is deferred to DeviceIoControl calls with specific IOCTLs.

MBR and Partition Corruption

HermeticWiper enumerates a range of Physical Drives multiple times, from 0-100. For each Physical Drive, the \\.\EPMNTDRV\ device is called for a device number.

The malware then focuses on corrupting the first 512 bytes, the Master Boot Record (MBR) for every Physical Drive. While that should be enough for the device not to boot again, HermeticWiper proceeds to enumerate the partitions for all possible drives.

They then differentiate between FAT and NTFS partitions. In the case of a FAT partition, the malware calls the same ‘bit fiddler’ to corrupt the partition. For NTFS, the HermeticWiper parses the Master File Table before calling this same bit fiddling function again.

MFT parsing and bit fiddling calls

We euphemistically refer to the bit fiddling function in the interest of brevity. Looking through it, we see calls to Windows APIs to acquire a cryptographic context provider and generate random bytes. It’s likely this is being used for an inlined crypto implementation and byte overwriting, but the mechanism isn’t entirely clear at this time.

Further functionality refers to interesting MFT fields ($bitmap, $logfile) and NTFS streams ($DATA, $I30, $INDEX_ALLOCATION). The malware also enumerates common folders (‘My Documents’, ‘Desktop’, ‘AppData’), makes references to the registry (‘ntuser’), and Windows Event Logs ("\\\\?\\C:\\Windows\\System32\\winevt\\Logs"). Our analysis is ongoing to determine how this functionality is being used, but it is clear that having already corrupted the MBR and partitions for all drives, the victim system should be inoperable by this point of the execution.

Along the way, HermeticWiper’s more mundane operations provide us with further IOCs to monitor for. These include the momentary creation of the abused driver as well as a system service. It also modifies several registry keys, including setting the SYSTEM\CurrentControlSet\Control\CrashControl CrashDumpEnabled key to 0, effectively disabling crash dumps before the abused driver’s execution starts.

Disabling CrashDumps via the registry

Finally, the malware waits on sleeping threads before initiating a system shutdown, finalizing the malware’s devastating effect.

A Decoy Ransomware – PartyTicket

On February 24th, 2022, Symantec researchers pointed to a new Go ransomware being used as a decoy alongside the deployment of HermeticWiper. During out analysis we decided to name it PartyTicket based on some of the strings used by the malware developers:

The idea of using a ransomware as a decoy for a wiper is counterintuitive. In particular, a ransomware as poorly coded as PartyTicket is more likely to tie up resources during the execution of an otherwise efficient wiper.

As often happens to amateur Go developers, the malware has poor control over its concurrent threads and the commands it attempts to run. This leads to hundreds of threads and events spawned in our consoles. That is to say, it’s a very loud and ineffective ransomware that should fire alerts left and right.

The folder organization and function naming conventions within the binary show the developer’s intent for taunting the U.S. Government and the Biden administration.

Project folders and function names referring to the Biden Administration

Similar taunting can be found in the ransom note after execution:

In trying to understand the execution flow of PartyTicket, we see the 403forBiden.wHiteHousE.primaryElectionProcess() function recursively enumerating folders:

PartyTicket looping over non-system folders

The resulting number of folders will be used as an upperbound for concurrent threads, a mistake by the Go devs as that effectively ties up all of the system’s resources. While the files found are all queued into a channel for the threads to reference.

PartyTicket generating concurrent threads

The function indirectly called for each thread is main.subscribeNewPartyMember(). It in turn takes a filename, makes a copy with a <UUID>.exe name and deletes the original file. Then we expect a second loop to relieve that queue of files and run each through a standard Go AES crypto implementation. However, execution is unlikely to get this far with the current design of PartyTicket.

(Thanks to Joakim Kennedy (Intezer) for pointing out this indirect call)

Crypto routine for files queued in the ‘salary’ channel

Overall our analysis of PartyTicket indicates it to be a rather simple, poorly coded, and loud malware. Its possible role as a decoy ransomware deployed alongside HermeticWiper is more likely to be effective for its accidental hogging of the victim organization’s system resources rather than the encryption of files itself. IOCs and Yara rules have been added below.


After a week of defacements and increasing DDoS attacks, the proliferation of sabotage operations through wiper malware is an expected and regrettable escalation. At this time, we have a very small sliver of aperture into the attacks in Ukraine and subsequent spillover into neighboring countries and allies. If there’s a silver lining to such a difficult situation, it’s seeing the open collaboration between threat intel research teams, independent researchers, and journalists looking to get the story straight. Our thanks to the researchers at Symantec, ESET, Stairwell, and RedCanary among others who’ve contributed samples, time, and expertise.

SentinelOne Customers Protected

Indicators of Compromise

(Updated February 28th, 2022)

ms-compressed resources SHA1
RCDATA_DRV_X64 5ceebaf1cbb0c10b95f7edd458804a646c6f215e
RCDATA_DRV_X86 0231721ef4e4519ec776ff7d1f25c937545ce9f4
RCDATA_DRV_XP_X64 9c2e465e8dfdfc1c0c472e0a34a7614d796294af
RCDATA_DRV_XP_X86 ee764632adedf6bb4cf4075a20b4f6a79b8f94c0
HermeticWiper SHA1
Win32 EXE 0d8cc992f279ec45e8b8dfd05a700ff1f0437f29
Win32 EXE 61b25d11392172e587d8da3045812a66c3385451
Win32 EXE 912342f1c840a42f6b74132f8a7c4ffe7d40fb77
Win32 EXE 9518e4ae0862ae871cf9fb634b50b07c66a2c379
Win32 EXE d9a3596af0463797df4ff25b7999184946e3bfa2
PartyTicket SHA-1
Win32 EXE f32d791ec9e6385a91b45942c230f52aff1626df

YARA Rules


import "pe"

      desc = "Hermetic Wiper - broad hunting rule"
      author = "Hegel @ SentinelLabs"
      version = "1.0"
      last_modified = "02.23.2022"
      hash = "1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591"
      reference = "https://www.sentinelone.com/labs/hermetic-wiper-ukraine-under-attack/"
        $string1 = "DRV_XP_X64" wide ascii nocase
        $string2 = "EPMNTDRV\\%u" wide ascii nocase
        $string3 = "PhysicalDrive%u" wide ascii nocase
        $cert1 = "Hermetica Digital Ltd" wide ascii nocase
      uint16(0) == 0x5A4D and
      all of them

      desc = "PartyTicket / HermeticRansom Golang Ransomware - associated with HermeticWiper campaign"
      author = "Hegel @ SentinelLabs"
      version = "1.0"
      last_modified = "02.24.2022"
      hash = "4dc13bb83a16d4ff9865a51b3e4d24112327c526c1392e14d56f20d6f4eaf382"
      reference = "https://twitter.com/juanandres_gs/status/1496930731351805953"
        $string1 = "/403forBiden/" wide ascii nocase
        $string2 = "/wHiteHousE/" wide ascii 
        $string3 = "vote_result." wide ascii
        $string4 = "partyTicket." wide ascii
        $buildid1 = "Go build ID: \"qb0H7AdWAYDzfMA1J80B/nJ9FF8fupJl4qnE4WvA5/PWkwEJfKUrRbYN59_Jba/2o0VIyvqINFbLsDsFyL2\"" wide ascii
        $project1 = "C:/projects/403forBiden/wHiteHousE/" wide ascii
      uint16(0) == 0x5A4D and
      (2 of ($string*) or 
        any of ($buildid*) or 
        any of ($project*))

      desc = "Hermetica Cert - broad hunting rule based on the certificate used in HermeticWiper and HermeticWizard"
      author = "Hegel @ SentinelLabs"
      version = "1.0"
      last_modified = "03.01.2022"
      hash = "1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591"
      reference = "https://www.sentinelone.com/labs/hermetic-wiper-ukraine-under-attack/"
      uint16(0) == 0x5a4d and
      for any i in (0 .. pe.number_of_signatures) : (
         pe.signatures[i].issuer contains "DigiCert EV Code Signing CA" and
         pe.signatures[i].serial == "0c:48:73:28:73:ac:8c:ce:ba:f8:f0:e1:e8:32:9c:ec"

      desc = "Issac Wiper - broad hunting rule"
      author = "Hegel @ SentinelLabs"
      version = "1.0"
      last_modified = "03.01.2022"
      hash = "13037b749aa4b1eda538fda26d6ac41c8f7b1d02d83f47b0d187dd645154e033"
      reference = "https://www.welivesecurity.com/2022/03/01/isaacwiper-hermeticwizard-wiper-worm-targeting-ukraine/"
        $name1 = "Cleaner.dll" wide ascii
        $name2 = "cl.exe" wide ascii nocase
        $name3 = "cl64.dll" wide ascii nocase
        $name4 = "cld.dll" wide ascii nocase
        $name5 = "cll.dll" wide ascii nocase
        $name6 = "Cleaner.exe" wide ascii
        $export = "[email protected]" wide ascii
      uint16(0) == 0x5A4D and
      (any of ($name*) and $export)

      desc = "HermeticWizard hunting rule"
      author = "Hegel @ SentinelLabs"
      version = "1.0"
      last_modified = "03.01.2022"
      reference = "https://www.welivesecurity.com/2022/03/01/isaacwiper-hermeticwizard-wiper-worm-targeting-ukraine/"
        $name1 = "Wizard.dll" wide ascii
        $name2 = "romance.dll" wide ascii
        $name3 = "exec_32.dll" wide ascii
        $function1 = "DNSGetCacheDataTable" wide ascii
        $function2 = "GetIpNetTable" wide ascii
        $function3 = "WNetOpenEnumW" wide ascii
        $function4 = "NetServerEnum" wide ascii
        $function5 = "GetTcpTable" wide ascii
        $function6 = "GetAdaptersAddresses" wide ascii
        $function7 = "GetEnvironmentStrings" wide ascii
        $ip_anchor1 = "" wide ascii
      uint16(0) == 0x5A4D and
      (any of ($function*) and any of ($name*) and $ip_anchor1)

SentinelOne STAR Rules

EventType = "Process Creation" AND TgtProcPublisher = "HERMETICA DIGITAL LTD"  AND
( SrcProcSignedStatus = "signed" AND IndicatorPersistenceCount = "2"  AND RegistryValue = "4" AND RegistryKeyPath = "MACHINE\SYSTEM\ControlSet001\Services\VSS\Start" ) AND SrcProcImagePath !~ "devsetup64.exe"

Hacktivism and State-Sponsored Knock-Offs | Attributing Deceptive Hack-and-Leak Operations

27 January 2022 at 18:59

There’s a seductive allure to the story that hacking can be a force for good, a way to tip the scales in favor of an underdog equipped with little more than a terminal, elite skills, and good intentions. In previous decades, what passed for hacktivism was little more than pointed website defacements and distributed denial of service attacks. Basically, politically motivated nuisances. They made their presence known, but their long-term impact was negligible. A post-Wikileaks era emphasized the power of hack-and-leak operations as a suitable lever for real-world impact of the sort hacktivists had sought for a long time. And it inevitably became the de facto standard for the greyhat vigilante.

The idea of hacktivists out there looking to settle the score against oppressive regimes is alluring in the same way that a grassroots revolution, a cohesive outcry of an oppressed people against their oppressors, is alluring. But the two aren’t equivalent.

A politically motivated hacking operation is not representative of a societal quorum. Technological skills and means are an amplifier that can give a handful of individuals an outsized voice and while that may be used to advance a moral cause, it’s also a great cover for action for established state-sponsored actors to influence sentiment and outcomes all over the world.

All of which begs the questions, are there still real hacktivists out there or are they all a cover for state-sponsored operations? Have we learned enough from previous run-ins to improve our analysis processes when approaching these potential deception operations?

Focus on this topic was motivated by our discovery of MeteorExpress and the rise of the Belarusian Cyber Partisans as a force opposing the Lukashenko regime. Both are widely different cases of hacktivism, with the former exhibiting inauthentic traits while the latter makes for a more convincing example of a grassroots endeavor.

The results of our analysis were first codified in the form of a CyberWarcon 2021 talk. In light of recent events, like the Partisans’ alleged use of ransomware to hinder Russian troop movements and a recent FBI report revisiting aspects of the Yemen Cyber Army, we felt it appropriate to spell out some insights and open mysteries.

State-Sponsored Knockoffs

In our 2016 paper, Brian Bartholomeow and I documented multiple instances of state-sponsored groups abusing hacktivist covers for their operations, focusing on two particular actors, Lazarus and Sofacy (APT28, STRONTIUM, FancyBear, etc.). Let’s briefly recap both.

Sony Pictures Entertainment hack claimed by Lazarus cover ‘Guardians of Peace’

The former resorted to this tactic early and often but did so poorly. Around 2015, it was easier to consider Lazarus a single grand threat cluster unified by a nexus of North Korean interest. Their operations against South Korean targets in 2012-2014 employed the cover of ‘hacktivist’ groups like ‘IsOne’, the ‘New Romantic Cyber Army’, and ‘WhoIs Team’.

Their more infamous cover, ‘Guardians of Peace’, became well-known for its involvement in the Sony Entertainment Pictures hack. Ultimately, all these hacktivist groups proved a thin and unconvincing disguise. They lacked any established pedigree and would lack any further operational continuity. They were abandoned just as quickly as the operations were carried out.

‘Anonymous Poland’ hack-and-leak amplification attempt by tweeting at researchers

On the other hand, Sofacy would prove far more dogged and successful in their use of hacktivism groups as cover. In some cases, they succeeded in fooling media outlets, victims, and researchers into thinking that they were dealing with hacktivist jihadis (CyberCaliphate) or pro-Russian Ukrainian security services (CyberBerkut).

While these outfits lacked much pedigree, they were nurtured over time and focused on objectives across different regions. Their efforts became sloppier during the summer of election hacks in 2016, employing outfits like the now infamous Guccifer 2.0, the lesser known @AnPoland, and even ultimately embracing one of their threat intelligence cryptonyms outright as the ‘FancyBears Hack Team’.

Beyond soft indicators like pedigree and continuity, threat intelligence researchers avidly tracking state-sponsored operations were in a position to correlate the leak phase of these operations with their respective earlier intrusion phases. For example, the attackers put effort into creating a hacktivist cover like @AnPoland to release documents stolen from the World Anti-Doping Agency (WADA) or the Court of Arbitration for Sport (Tas-Cas). Around the same time, Sofacy was seen registering WADA and Tas-Cas typosquatted domains for use in their phishing campaigns.

A possible coincidence? Sure. But we can add ‘overlap with a state-sponsored operation’ as another soft indicator in our assessment matrix for hacktivist covers.

These examples are practically ancient history in InfoSec years. We’re revisiting them precisely because the benefit of hindsight does a lot to dispel the confusion that accompanies fresh enemy incursions. For example, while we suspected that Yemen Cyber Army (YCA) was another Sofacy front due to a combination of soft indicators, Simin Kargar’s 2021 Cyberwarcon talk weighed the possibility of Iranian vs. Russian state-sponsorship behind YCA.

Simon Kargar notes the timeline of YCA activity related to the Iranian company Emennet Pasargad

With the timely release of the FBI’s report on Iranian-based company Emennet Pasargad (a.k.a. Eeleyanet Gostar), the benefit of hindsight may ultimately tip the scale in favor of Kargar’s Iranian hypothesis. The FBI connects Emennet Pasargad with both 2018 YCA activity as well as a 2020 U.S. voter intimidation and disinformation campaign under the cover of Proud Boys.

That said, keep in mind that the Yemen Cyber Army activity referenced occurs in 2018 and is not expressly linked back to the 2015 activity (as noted by Kargar). As she hints in her tweet, there’s always the possibility of yet another turn, a ‘knockoff’ hijacking the pedigree of this hacktivism cover for themselves.

‘Indra’, ‘Predatory Sparrow’, and ‘Adalat Ali’

More recently, we investigated the case of MeteorExpress, a previously unknown actor conducting wiper attacks across Syria and Iran since 2019. This brought back the question of inauthentic hacktivism as MeteorExpress activities were claimed by different short-lived, no pedigree ‘hacktivist’ groups under names like ‘Indra’, ‘Predatory Sparrow’, and possibly ‘Adalat Ali’.

Each appeared to have their own delimited campaigns, Telegram channels, social media accounts, and dropped stolen files via MEGA. The handling of the diverse fronts was inconsistent. Indra and Predatory Sparrow attacks were correlated by the use of slightly altered versions of MeteorExpress malware. Notably, there are even two separate Predatory Sparrow accounts, pointing to a possible hijack or something as embarrassing as a loss of credentials for the first.

We can at least say that inauthentic hacktivism is alive and well as a cover for action for state-sponsored attacks looking for a modicum of plausible deniability.

What Might Real Hacktivism Look Like?

Having discussed so many examples of fake hacktivism, we can distill the more useful soft indicators we’ve previously used in evaluating authentic hacktivism in a modern context.

  • Pedigree
    • Where did they come from? What have they done before?
  • Continuity
    • What happens after the initial attack?
  • Sourcing of Materials
    • How did they arrive at the materials pilfered or leaked?
  • Release Coordination
    • How are their released materials disseminated and amplified?
  • Cui bono
    • Who benefits? Who is negatively affected? Who should be negatively affected but isn’t?
  • Consistency of Objectives
    • Are the attackers consistently working towards their stated cause?
  • Secondary Effects
    • What effects are being courted? Media attention? Government response? Regional tensions?
  • Targeting
    • How are their targets selected? What prior knowledge would someone require to select or reach these targets?
  • Consistency
    • How well defined is the group? What ties one claim of ownership over a campaign to another? Is it a nebulous collective that different actors could hijack?

In the absence of hard technical indicators, these are some of the questions analysts should consider as they evaluate the authenticity of a hacktivism group. At this point, I’ll admit a tendency towards default skepticism, but we’d do well not to discount the possibility of a true homegrown asymmetrical threat.

Play Along at Home

For those analysts eager to try their hand at some of this analysis, there are multiple unsolved mysteries to choose from.

  • Lab Dookhtegan and GreenLeakers, two notorious groups sporadically leaking tools and materials allegedly belonging to Iranian APTs OilRig and MuddyWater, respectively.
    LabDookhtegan and GreenLeakers
  • SpiderZ, a mysterious group responsible for hacking the Al-Qard Al-Hassan financial organization and disclosing mechanisms used by Hezbollah to bypass U.S. sanctions in Lebanon.
    SpiderZ logo from their Anonymous-themed YouTube video
  • AgainstTheWest, a persona brought to my attention by Aaron DeVera during the CyberWarcon Q&A. ATW stages sporadic attacks against the Chinese government. DeVera recently published a profile of ATW.
  • IntrusionTruth, is a notorious outfit in the threat intelligence space. They intermittently release blogs profiling the individuals and companies behind different Chinese APTs with a decent level of detail substantiated via public sourcing or different telemetry services.
    IntrusionTruth logo consistent across their blog and Twitter account
  • ‘John Doe’ is purportedly the sole source behind the Panama Papers, claiming responsibility for the hack against Panamanian company Mossack Fonseca that set off the global tidal wave of revelations on the illicit use of offshore companies to hide wealth. Despite an initial mistaken arrest of a local employee, little is known about this attacker beyond their statement of intent. Further releases by the International Consortium of Investigative Journalists (ICIJ), titled ‘Pandora Papers’, have been more opaque about their sourcing, so what happened to John Doe?
  • Last, but most certainly not least, is the mythical ‘Phineas Fisher’.
    Sock puppet used to represent Phineas Fisher at their request during a Vice CyberWar interview

    While it’s hard to assess the authenticity or provenance of PF, they’re arguably the most successful modern hacktivist outfit with a confirmed kill under their belt –HackingTeam. PF gets their name from their first publicly attributed hack against Gamma Group (the makers of FinFisher) in 2014. They would then go on to breach HackingTeam so epically that they essentially left the company to slow bleed and ultimately shut down.

    ASCII art from one of Phineas Fisher’s HackBack Guides

    While PF is better known for these big hacks, they would also go on to release multiple hacking guides rife with Anarcho-Marxist references. The stated purpose being to empower others to follow in their footsteps and stand up to capitalist abuses. That mission would be further bolstered by hacks against the Mossos D’Esquadra police union of the Catalan Police, the AKP party in Turkey, and the Cayman Island National Bank and Trust. Consequently, PF set up the ‘Hacktivist Bug Hunting Program’, offering up to $100,000 in cryptocurrency as a reward for hacks against companies contributing to our ‘hypercapitalist dystopia’.

An Authentic Example?

Keen readers might note that I haven’t pointed to any groups as authentic modern hacktivist outfits. Rather than embrace skepticism entirely, I’ll go out on a limb and point to the recent rise of the Belarusian Cyber Partisans as a group with all the hallmarks of authentic hacktivist behavior, fully allowing for the possibility that I’ll end up eating my words. Let’s apply the metrics we’ve previously discussed.

Belarusian Cyber Partisans Logo

The Belarusian Cyber Partisans claim to be a collective of local system administrators fighting against the Lukashenko regime. Most of their attacks have focused on disclosures of stolen government information in the hopes of attracting further scrutiny on the practices of the incumbent leadership. By their own admission in private communications, the Partisans felt that the media were not paying enough attention to these revelations. They’ve now graduated to a new strategy of leveraging ransomware to disable strategically significant institutions, starting with the Belarusian Railways company (BCh) in an attempt to hinder Russian troop movements within Belarus and demanding the release of political prisoners.

Applying our soft indicators, we see the Partisans activity establishing a clear pedigree of activity and continuity of operations that’s continually emboldened but not suddenly enhanced by outsized capabilities. As reports are leaked detailing some of the means of their attacks, we see rather mundane technical indicators, largely abusing free services and commonly available tooling, though by their admission the alleged ransomware used at BCh is one they wrote (something we haven’t independently confirmed due to a lack of samples).

Union of Belarusian Security Officers

Most importantly, their limitations and tasking appear organic. They claim that in order to discover important government targets, they collaborate with a union of current and former Belarusian security officers (BYPOL) better acquainted with the inner workings of the government. That organic tasking stands in stark contrast to the example of MeteorExpress’ Indra campaign where a no pedigree ‘hacktivism’ group knew the exact companies allegedly supporting Iranian Revolutionary Guard Corps (IRGC) operations in Syria to hack-and-leak. This pinpoint targeting goes unexplained in the MeteorExpress narrative, and in most state-sponsored fly-by-night covers.

Signaling and Secondary Effects

There are reasons that we should foment greater analytic rigor when it comes to the authenticity of hacktivist operations. The use of a hacktivist cover goes hand-in-hand with the intention to release materials publicly and amplify a narrative for a given audience.

That’s a non-trivial change when it comes to state-sponsored operations, most of which are designed to remain undiscovered for as long as possible. Hack-and-leak operations are meant to court (selective or wide) attention and cause an effect. In the process, these groups are leveraging two audiences– security researchers and journalists.

Predatory Sparrow proactively messaging Western Media on gas pump attack

I’m afraid to say that we both prove susceptible conduits for different but similar reasons. We as security researchers are fascinated by new attacks, by the thrill of a new puzzle to put together. Our jobs often entail sharing information with other companies, reporting to governments, or publishing to as wide an audience as we have at our disposal. Similarly, journalists are always on the lookout for the next big story, they have editors and metrics. And neither group benefits from a wealth of time to scrutinize all aspects of a possible deception operation before amplifying it.

It’s easy to dismantle the ethical implications of our respective roles in these ops, but I think it’s important to sit with the discomfort and weigh (perhaps fruitlessly) how we might serve as more conscious stewards of the information we come across. We are not an incidental part of the dissemination aspect of these operations but a vital aspect, and we’d do well to act as a discerning one.

Concluding Thoughts

Hacktivism has come a long way from the late 90s and early 2000s years of nuisance hacks and naive collectives. If we distill what we’ve learned over the past decade of hacktivism abused as a cover for action, clear insights come into view:

  • State-sponsored groups use the guise of grassroots motivations not just for plausible deniability but also to imbue their leaks with legitimacy not afforded by the obvious intervention of a government.
  • Given the comparative volume of hacktivism ops that have turned out to be state-sponsored deception ops in the past ten years, we may also lean towards the conclusion that most hacktivism is used as a cover.
  • We actually struggle to narrow in on the examples of authentic hacktivism in the past decade, though it surely exists.
  • Our ability to assess these operations with certainty remains weak and is untimely compared to the speed with which their information is disseminated and amplified.

As a partial salve, we should hold steadfast to the attributes and soft indicators that have served us in determining the (in)authenticity of previous groups and apply them to these operations as they arise.

And for those avid practitioners and hungry analysts out there, it’s clear that the hacktivism space contains a wealth of unsolved mysteries to tackle.

AlphaGolang | A Step-by-Step Go Malware Reversing Methodology for IDA Pro

21 October 2021 at 14:12

The increasing popularity of Go as a language for malware development is forcing more reverse engineers to come to terms with the perceived difficulties of analyzing these gargantuan binaries. The language offers great benefits for malware developers: portability of statically-linked dependencies, speed of simple concurrency, and ease of cross-compilation. On the other hand, for analysts, it’s meant learning the inadequacies of our tooling and contending with a foreign programming paradigm. While our tooling has generally improved, the perception that Go binaries are difficult to analyze remains. In an attempt to further dispel that myth, we’ve set out to share a series of scripts that simplify the task of analyzing Go binaries using IDA Pro with a friendly methodology. Our hope is that members of the community will feel inspired to share additional resources to bolster our collective analysis powers.

A Quick Intro to the Woes of Go Binary Analysis

Go binaries present multiple peculiarities that make our lives a little harder. The most obvious is their size. Due to the approach of statically-linking dependencies, the simplest Go binary is multiple megabytes in size and one with proper functionality can figure in the 15-20mb range. The binaries are then easily stripped of debug symbols and can be UPX packed to mask their size quite effectively. That bulky size entails a maze of standard code to confuse reverse engineers down long unproductive rabbit holes, steering them away from the sparse user-generated code that implements the actual functionality.

Hello World source code
Mach-o binary == 2.0mb
UPX compressed == 1.1mb

To make things worse, Go doesn’t null-terminate strings. The linker places strings in incremental order of length and functions load these strings with a reference to a fixed length. That’s a much safer implementation but it means that even a cursory glance at a Go binary means dealing with giant blobs of unrelated strings.

“Hello World!” string lost in a sea of unrelated strings.

Even the better disassemblers and decompilers tend to display these unparsed string blobs confusing their intended purpose.

Autoanalysis output

Manually fixed disassembly

That’s without getting into the complexities of recovering structures, accurately portraying function types, interfaces, and channels, or properly tracing argument references.

The issue of arguments should prove disturbing for our dynamic analyst friends who were hoping that a debugger would spare them the trouble of manual analysis. While a debugger certainly helps determine arguments at runtime, it’s important to understand how indirect that runtime is. Go is peculiar in allocating a runtime stack owned by the caller function that will in turn handle arguments and allow for multiple return values. For us it translates into a mess of runtime function prologues before any meaningful functionality. Good luck navigating that without symbols.

Improving the Go Reversing Experience

With all those inadvertent obstacles in mind, it’s perfectly understandable that reversers dreaded analyzing Go binaries. However, the situation has changed in the past few years and we should reassess our collective abhorrence of Go malware. Different disassemblers and decompilers have stepped up their Go support. BinaryNinja and Cerbero have improved their native support for Go and there are now standalone frameworks like GoRE that offer good functionality depending on the Go compiler version and can even help support other projects like radare2.

We’ll be focusing on IDA Pro. With the advent of version 7.6, IDA’s native support of Go binaries is drastically better and we’ll be building features on top of this. For folks stuck on v7.5 or lower, we’ll also provide some help by way of scripts but the full functionality of AlphaGolang is unlocked with 7.6 due to some missing APIs (specifically the ida_dirtree API for the new folder tree view). This isn’t the first time brave souls in the community have attempted to improve the Go reversing experience for IDA. However, those projects were largely monolithic labors of love by their original authors and given the fickle nature of IDA’s APIs, once those authors got busy, the scripts fell into disrepair. We hope to improve that as well.


With AlphaGolang, we wanted to tackle two disparate problems simultaneously– the brittleness of IDApython scripts for Go reversing and the need for clear steps to analyze these binaries.

We can’t expect everyone to be an expert in Go in order to understand their way around a binary. Less so to have to fix the tooling they’re attempting to rely on. While engineers might be tempted to address the former by elaborating a complex framework, we figured we’d swing in the opposite direction and break up the requisite functionality into smaller scripts. Those smaller digestible scripts allow us to part out a relatable methodology in steps so that analysts can pick and choose what they need as they advance in their reversing journey.

Additionally, we hope the simplicity of the project and a forthrightness about its current limitations will inspire others to contribute new steps, fixes, and additional functionality.

At this time, the first five steps are as follows–

Step 0: Identifying Go Binaries

Go Build ID Regex

By popular request, we are including a simple YARA rule to help identify Go binaries. This is a quick and scrappy solution that checks for PE, ELF, and Mach-O file headers along with a regex for a single Go Build ID string.

Step 1: Recreate pcln Table

Recreating the Go pcln table

Dealing with stripped Golang binaries is particularly awful. Reversers unfamiliar with Go are disheartened to see that despite having all of the original function names within the binary, their disassembler is unable to connect those symbols as labels for their functions. While that might seem like a grand coup for malware developers attempting to confuse and frustrate analysts, it isn’t more than a temporary inconvenience. Despite being stripped, we have enough information available to reconstruct the Go pcln table and provide the disassembler with the information it needs.

Two noteworthy points before continuing:

  • The pcln table is documented as early as Go v1.12 and has been modified as of v1.16.
  • IDA Pro v7.6+ handles Go binaries very well and is unlikely to need this step. This script will prove particularly valuable for folks using IDA v7.5 and under when dealing with stripped Go binaries.

Depending on the file’s endianness, the script will locate the pcln table’s magic header, walk the table converting the data to DWORDs (or QWORDs depending on the bitness), and create a new segment with the appropriate ‘.gopclntab’ header effectively undoing the stripping process.

Step 2: Discover Missing Functions and Restore Function Names

Function discovery and renaming

Immediately after recreating the pcln table (or in unfortunate cases where automatic disassembly fails), function names are not automatically assigned and many functions may have eluded discovery. We are going to fix both of these issues in one simple go.

We know that the pcln table is pointing us at every function in the binary, even if IDA hasn’t recognized them. This script will walk the pcln table, check the offsets therein for an existing function, and instruct IDA to define a function wherever one is missing. The resulting number of functions can be drastically greater even in cases where disassembly seems perfect.

Additionally, we’ll borrow Tim Strazzere’s magic from the original Golang Loader Assist in order to label all of our functions. We ported the plugin to Python 3, made it compatible with the new IDA APIs, and refactored it. The functionality is now part of two separate steps (2 and 4) and easier to maintain. In this step, Strazzere’s magic will help us associate all of our functions with their original names in an IDA friendly format.

Step 3: Surface User-Generated Functions

Automatically categorizing functions

Having recovered and labeled all of our functions, we are now faced with the daunting proposition of sifting through thousands of functions. Most of these functions are part of Go’s standard packages or perhaps functionality imported from GitHub repositories. To belabor a metaphor, we now have street signs but no map. How do we fix this?

IDA v7.5 introduced the concept of Folder Views, an easily missed Godsend for the anal-retentive reverser. This feature has to be explicitly turned on via a right-click on the desired subview –whether functions, structures, imports, etc. IDA v7.6 takes this a step further by introducing a thus-far undocumented API to interact with these folder views (A heartfelt thank you to Milan Bohacek for his help in effectively wielding this API). That should enable us to automate some extraordinary time-saving functionality.

While our malware may have 5,000 functions, the majority of those functions were not written by the malware developers, they’re publicly documented, and we need nothing more than a nominal overview to know what they do.

NOBELIUM GoldMax (a.k.a. SunShuttle)

By being clever about categorizing function packages, we can actually whittle down to a fraction of the overall functions that merit analyst time. Functions will be categorized by their package prefixes and further grouped as ‘Standard Go Packages’, unlabeled (‘sub_’), uncategorized (no package prefix), and Github imports. What remains are the ‘main’ package and any custom packages added by the malware developers. For a notable example, the NOBELIUM GoldMax (a.k.a. SunShuttle) malware can be reduced from a hulking 4,771 functions to a mere 22. This is the simplest and perhaps the most valuable step towards our goal of understanding the malware’s functionality.

Step 4: Fix String References

Accurately recasting strings by reference

Finally, there’s the issue of strings in Go. Unlike all C-derivative languages, strings in Go are not null terminated. Neither are they grouped together based on their source or functionality. Rather, the linker places all of the strings in order of incremental length, with no obvious demarcation as to where one string ends and the next begins. This works because whenever a function references a string, it does so by loading the string address and a hardcoded length. While this is a safer paradigm for handling strings, it makes for an unpleasant reversing experience.

So how do we overcome this hurdle? Here’s where another piece of Strazzere’s Golang Loader Assist can help us. His original plugin would check functions for certain string loading patterns and use these as a guide to fix the string assignments. We have once again (partially) refactored this functionality, made it compatible with Python 3, and IDA’s new APIs. We have also improved some of the logic for the string blobs in place (either by suspicious length or because a reference points to the middle of a blob) and added some sanity checks.

While this step is already a marked improvement, we are seeing new string loading patterns introduced with Go v1.17 that need adding and there’s definitely room for improved refactoring. We hope some of you will feel inclined to contribute.

Where Do We Go From Here?

Let’s take a step back and look at where we are after all of these steps. We have an IDB with all functions discovered, labeled, and categorized, and hopefully all of their string references are correctly annotated. This is an ideal we could seldom dream of with malware of a comparable size written in C or C++ without extensive analysis time and prior expertise.

Now that we have a clear view of the user-generated functionality, what more can we do? How else can we improve our hunting and analysis efforts?

The following are a series of ideas we’d recommend implementing in further steps–

  • How about auto-generating YARA rules for user-generated functions and their referred strings?
  • Want a better understanding of arguments as they’re passed between functions? How about automagically setting breakpoints at the runtime stack prologues and annotating the arguments back to our IDB?
  • For reversers that follow the Kwiatkowski school of rewriting the code to understand the program’s functionality, how about selectively exporting the Hex-Rays pseudocode solely for the user-generated functions?
  • How about reconstructing interfaces and type structs from runtime objects?

Got more ideas? Want to help? Head to our SentinelLabs GitHub repo for all of the scripts and contribute your own shortcuts and superpowers for analyzing Go malware!

We’d like to thank the following for their direct and indirect contributions– 

  • Tim Strazzere for his original Golang Loader Assist script, which we refactored and made compatible with Python3 and the new IDA APIs. 
  • Milan Bohacek (Avast Software s.r.o.) for his invaluable help figuring out the idatree API.
  • Joakim Kennedy (Intezer)
  • Ivan Kwiatkowski (Kaspersky GReAT) for making his Go reversing course available.
  • Igor Kuznetsov (Kaspersky GReAT) for his help understanding newer pcln tab versions.


Guides and Documentation



EGoManiac | An Unscrupulous Turkish-Nexus Threat Actor

8 September 2021 at 13:08

By Juan Andres Guerrero-Saade & Igor Tsemakhovich

Executive Summary

  • EGoManiac is responsible for the previously reported ‘Octopus Brain’ campaign, where the operators interdicted the machines of OdaTV journalists to place malware and incriminating documents, effectively framing them before arrest.
  • Our research connects Octopus Brain to a toolkit called Rad, in development as early as 2010 and used until 2015.
  • Rad samples use hardcoded email addresses for exfiltration.
  • One of those email addresses is cited in connection to the prosecution of rogue members of the Turkish National Police along with executives of a company called ‘Datalink Analiz’. They refer to Rad as ‘HORTUM’.
  • Following the trail of ‘Datalink Analiz’, we suspect that EGoManiac activity includes the use of Hacking Team’s Remote Control System (RCS) contracted under this same front company with a series of irregularities as early as 2011.
  • In 2013, a report emerged on the use of RCS against a Turkish victim in the United States. The victim voiced an unverified suspicion that its use represented the unsanctioned interests of rogue Gülenist elements within the Turkish government.

In this post, we provide an abridged version of our in-depth investigation into the activities of this unscrupulous threat actor. The full report provides detailed technical breakdowns of malware samples, full IoCs and hunting rules along with further attribution details.

Read the Full Report

The Hunt for Ahtapot

In the world of cyberespionage research, the human-interest element is often lost amidst a barrage of technical indicators. The absence of a human dimension can make our research seem overly technical and dry, something we write for defenders to block and other researchers to enjoy. When we can see the impact that some of these campaigns have on civil society and the weakening of public institutions, it invokes a certain doggedness that won’t let sleeping dogs lie. EGoManiac is one that’s been in the back of our heads for the past five years. The research involved multiple dead ends, false starts, and layers of conspiratorial mystery.

What we refer to as EGoManiac is a cluster of two notable campaigns starting as early as 2010. The first campaign came to be known in research circles as ‘Octopus Brain’, based on the Turkish strings Ahtapot and Bejin left in the malware. This original campaign used a combination of publicly available RATs (including Turkojan and Bandook) as well as the closed-source Ahtapot, with delivery methods ranging from malicious documents to personal visits by the attackers.

Our initial awareness of this case came from Turkish court documents surrounding arrests of journalists at OdaTV. Much greater detail came to light thanks to the excellent work of the folks at Arsenal Consulting. Their forensic investigation not only proved the presence of the malware and the physical interdiction of the victim systems, but also established the attacker’s access as the definitive source of the incriminating documents on those systems that were then used to justify arrests by the Turkish National Police. The journalists were ultimately acquitted by a court in 2017—six years after the attacks.

This scenario is one of the often-ignored dirty edge cases of ‘lawful intercept’ malware, stated plainly: what’s the expectation of evidential integrity when it comes to an infected device?  This question is currently playing out further in the Bhima Koregaon case in India, where it appears malware was used to upload incriminating letters onto the victim’s machine.

While these particular operators resorted to physically tampering with the devices they were monitoring, there’s little keeping malware operators from placing incriminating or damaging files on systems infected with malware that has file download capabilities, as most rudimentary malware does.

In the face of such an unscrupulous actor, we are left to wonder if this activity is part of a cluster we already track, and if not, what else has this actor been up to in the shadows? Octopus Brain provided few answers. Despite finding a handful of Ahtapot modules, there were no newer samples nor connections to other toolkits. The trail went cold…until now.

Experiments in Innovative Pivoting

As threat hunting technology continued to improve, there were different attempts to once again pick up the scent of the attackers behind the Octopus Brain campaign. Code similarity analysis is one of the favorite tools in our research arsenal. However, initial attempts to cluster new samples based on shared unique code snippets were not fruitful.

We decided to take a different approach. Rather than focusing on unique code snippets, we can instead focus on a bulk of shared common code as a way of profiling the development environment that produced the samples and attempt to find other samples produced in the same way: same compiler, same optimizations, relying on the same statically-linked libraries, etc. Limited testing of this method has yielded positive results under specific circumstances—like allowing us to cluster a set of samples based off of the analysis of a single original sample and without needing to spend cycles conducting extensive goodware testing.

Ahtapot campaign components connect to newer Rad toolkit

To our surprise, applying this experimental approach to Octopus Brain yielded results. By generating a rule based off of the bulk of common code of Ahtapot components, we stumbled upon a set of samples we’ll call ‘Rad’, based on a persistent typo in symbol paths left within the binaries.

Expanding on this initial finding, we found a cluster of more than 50 samples and subcomponents for a modular espionage toolkit almost entirely undetected at the time of discovery.

EGoManiac’s ‘Rad’ Toolkit

Rad is a modular espionage malware toolkit built around the POCO C++ cross-platform development libraries. The design entails a form of organized development but not a particularly savvy or sophisticated one at that. POCO is doing most of the heavy lifting. Functionality is split into modules contained within a ‘RadApplicationInstaller’ and orchestrated by a ‘RadStarter’ module that takes its cues from an encrypted configuration XML file. All of the Rad samples we’ve found rely on email exfiltration with a hardcoded address belonging to either Gmail, Yandex, or Woxmail (defunct at the time of writing).

Rad toolkit components

The execution flow of the Rad toolkit is straightforward. wsms.exe (RadStarter) is the main module that runs from a registry key set by the installer. It, in turn, runs the other modules as separate processes. Each process represents different functionality, including a keylogger, hot mic recorder, browser information extractor, screen capture module, file search, and a communication module for exfiltration. More details are provided in the full report.

Who is EGoManiac?

Attribution based solely on technical indicators is complicated and inexact. Most technical indicators are subject to modification and require interpretation based on limited visibility. Lacking a greater understanding of local context and closed-source intelligence, it’s difficult to extend attribution beyond abstract entities (like an APT group name) to specific people or organizations.

On the surface, EGoManiac activity revolves around a Turkish nexus. The malware is riddled with Turkish language, lures are written in Turkish, victims are Turkish and relevant to local politics. The connection to Ahtapot and the OdaTV incident entails the actor’s ability to physically interdict systems within Turkey. Additionally, most PDB paths for Rad components have a root folder of ‘EGM’, from which we derived the name ‘EGoManiac’.

EGoManiac’s Rad toolkit relies on hardcoded email addresses for communication. Obfuscated logs and other exfiltrated materials are sent to the following emails across multiple service providers:

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

While email comms might usually lead to another research dead-end, the address [email protected] raised an interesting connection.

In 2016, Turkish websites reported sparse details of an ongoing attempt to prosecute members of the Turkish national police and executives of an IT company called ‘Datalink’ suspected of leaking information on active police operations. The leaks were reportedly used by FETO/Gülenist movement social media accounts to fuel conspiratorial elements in an ongoing power struggle within the country.

Reports cite the use of spyware called ‘HORTUM’ (roughly translated as ‘garden hose’) to siphon data from infected machines within public institutions in Turkey including the Intelligence department of the General Directorate of Security (EGM). Some of the reporting mistakenly conflates HORTUM with Hacking Team’s RCS. The siphoned data was sent to [email protected], and from there allegedly redistributed by Datalink. The capabilities of HORTUM and its communication methods match those of EGoManiac’s Rad, including the hardcoded Woxmail address.

Encrypted configuration using [email protected] for exfiltration

We cannot independently verify the veracity of the initial reporting. An independent investigation to that effect was conducted by Kim Zetter, who obtained extensive details including a report by the prosecutor handling the case. Taking the information we have at face value, we uncover another possible facet of the EGoManiac story.

The Hacking Team Connection

As early as 2012, victims of Hacking Team’s Remote Control System (RCS) ‘Da Vinci’ began to show up in Turkey. In 2013, Wired reported that a woman in the United States was targeted with RCS. The victim suspected that she was targeted by Gülenist elements that had infiltrated the Turkish government. However, Hacking Team continued to assert that it only sells its tools to governments and did not confirm Turkey’s status as a customer. Now, in the aftermath of Phineas Fisher’s devastating hack-and-leak operation against Hacking Team, we can independently confirm that Turkey was in fact a customer of Hacking Team at the time, but who exactly was their customer in Turkey?

Leaked Hacking Team email on an invoice confusion involving an Istanbul company ‘Datalink Analiz’

The leaked Hacking Team treasure trove contains communications with officials claiming to be a part of the Turkish National Police as early as 2011. Citing problems with their mail server, they proceed to use three Gmail accounts to plan their purchase of RCS. A Gmail account is also used for communication with the Hacking Team support portal.

Hacking Team officials note further irregularities as the first deal goes through. Though the purchase is intended under the umbrella of a UAE-based shell company (‘Foresys Information Technology-FZE’), Hacking Team receives payment from a company registered in Istanbul: ‘Datalink Analiz LTD’.

Prevalence of EGoManiac-related malware families by compilation timestamp

To be thorough, we chart the use of Hacking Team RCS by the Turkish National Police (see Appendix C in the full report) based on the company’s internal watermarking scheme used to track the origin of leaked samples among their customer base. The graphic above notes the coincidental cadence of the use of the different malware families related to the EGoManiac cluster. However, we can’t go as far as to equate the two clusters without resolving the murky allegiances of the operators involved.

The connection between the EGoManiac umbrella and this specific sub-cluster of Hacking Team RCS is built on the admittedly thin strand of the ‘Datalink Analiz’ shell company. That thread merited an investigation beyond the purely technical to straighten out an abundance of conspiratorial claims, alleged foreign money laundering, and ambiguous finger pointing.


The case of EGoManiac is far from straightforward. It involves difficult investigative connections that test the boundaries of our visibility, the efficacy of our research tools, and the limits of purely technical attribution. Beyond the technical exercise, it’s a profile of a threat actor willing to spy on both friend and foe and to use that access to malign and entrap journalists without compunction. While this particular intrusion set is outdated, the questions it raises speak to the friction between the unsupervised governmental use of malware and the integrity of public institutions, rule of law, and evidentiary standards. They are more relevant now than ever before.

Read the Full Report

MeteorExpress | Mysterious Wiper Paralyzes Iranian Trains with Epic Troll

29 July 2021 at 17:56

Executive Summary

  • On July 9th, 2021 a wiper attack paralyzed the Iranian train system.
  • The attackers taunted the Iranian government as hacked displays instructed passengers to direct their complaints to the phone number of the Iranian Supreme Leader Khamenei’s office.
  • SentinelLabs researchers were able to reconstruct the majority of the attack chain, which includes an interesting never-before-seen wiper.
  • OPSEC mistakes let us know that the attackers refer to this wiper as ‘Meteor’, prompting us to name the campaign MeteorExpress.
  • At this time, we have not been able to tie this activity to a previously identified threat group nor to additional attacks. However, the artifacts suggest that this wiper was developed in the past three years and was designed for reuse.
  • To encourage further discovery of this new threat actor, we are providing indicators as well as hunting YARA rules for fellow security researchers.


On July 9th, 2021 reports began to surface of a wiper attack disrupting service for the Iranian railway system. The attack included epic level trolling as reports suggest that train schedule displays cited “long delay[s] because of cyberattack” along with instructions to contact ‘64411’ –the number for the office of Supreme Leader Ali Khamenei.

Iran International (Twitter)

Early reporting did not pick up much steam as it’s not uncommon for Iranian authorities to vaguely point the finger towards cyber attacks only to retract the claims later. But it doesn’t hurt to check.

We would like to acknowledge security researcher Anton Cherepanov who pointed out an early analysis (Farsi) by an Iranian antivirus company. Despite a lack of specific indicators of compromise, we were able to recover most of the attack components described in the post along with additional components they had missed. Behind this outlandish tale of stopped trains and glib trolls, we found the fingerprints of an unfamiliar attacker.

The Attack Chain

MeteorExpress Attack Chain

Though early reports did not include technical specifics, we were able to reconstruct most of the attack components relying on a combination of factors – early analysis by Padvish security researchers as well as a recovered attacker artifact that included a longer list of component names. The attackers abused Group Policy to distribute a cab file to conduct their attack.

The overall toolkit consists of a combination of batch files orchestrating different components dropped from RAR archives. The archives decompressed with an attacker supplied copy of Rar.exe coupled with the password ‘hackemall’. The wiper components are split by functionality: Meteor encrypts the filesystem based on an encrypted configuration, nti.exe corrupts the MBR, and mssetup.exe locks the system.

While we were able to recover a surprising amount of files for a wiper attack, some have eluded us. The MBR corrupter, nti.exe, is most notable among those missing components as Padvish researchers noted that the sectors overwritten by this component are the same as those overwritten by NotPetya. Until we are able to find this file, we can’t corroborate their finding.

The following is a breakdown of the central components of this attack.

The Batch Files

The majority of the attack is orchestrated via a set of batch files nested alongside their respective components and chained together in successive execution.

The following is a short description of the main functionality of these batch files.


setup.bat is the first component executed via group policy. Interestingly, it deletes a scheduled task called ‘AnalyzeAll’ under the Windows Power Efficiency Diagnostics directory. At this time, we haven’t been able to identify this task. This batch file is responsible for copying the initial components via a CAB file in a network share within the Iranian railways network. The CAB file is expanded and update.bat is executed with the parameters ‘hackemall’, relevant paths, and the Meteor wiper executable (env.exe).


envxp.bat appears to be a simpler alternative version of setup.bat. As the name suggests, perhaps it’s intended for Windows XP.

update.bat is a well written batch script that takes care of placing the remaining files and directing the remainder of the execution flow by calling the successive batch scripts. It takes three arguments: the password for the rar archives, the working directory, and the location of the payload. If the first two parameters are empty, it’ll exit smoothly. In the absence of a payload, the script attempts to run msapp.exe. That component is listed in the Padvish security writeup but the execution flow via setup.bat points to env.exe as the intended payload. We’ll delve into this component below.

update.bat’s makeshift mutex

The script checks for a hardcoded ‘lock_file’ under C:WindowsTemp__lock6423900.dat. The file serves as a makeshift mutex to avoid double execution and could double as a vaccine to avoid infection during development.

update.bat directing the execution flow to subsequent batch files

The batch file uses its own copy of WinRAR to decompress additional components from three additional archives (programs.rar, bcd.rar, ms.rar) using the same Pokemon-themed password, “hackemall” (Hack ’Em All). With each RAR archive, update.bat calls a subsequent batch archive before deleting the respective archive. The developers are very careful about cleaning up their components as soon as they’re used.

At this point the execution begins to bifurcate into other scripts. The first one is cache.bat, which focuses on clearing obstacles and preparing the ground for subsequent elements with the use of PowerShell.

cache.bat disabling network adapters and checking for Kaspersky antivirus

cache.bat performs three main functions. First, it will disconnect the infected device from the network. Then it checks to see if Kaspersky antivirus is installed on the machine, in which case it’ll exit.

cache.bat creating Windows Defender exclusions for attack components

Finally, cache.bat will create Windows Defender exclusions for all of its components, effectively clearing the way for a successful infection without impediments. This script proved particularly valuable for us in rebuilding the entire attack chain as it lists most of the attack components giving us a threat hunting shopping list of sorts. It’s worth noting that this is the only batch script we’ve recovered that embeds PowerShell.

Subsequently, update.bat calls bcd.bat, which serves two functions: rendering the machine unbootable and cleaning up event logs.

bcd.bat script overwrites boot.ini

In order to disable the machine’s ability to boot up, bcd.bat creates an alternative boot.ini file that points the bootloader to impossibly high disk and partition numbers (10000000) and overwrites the system’s copy of boot.ini. The script then uses the native bcdedit command to list boot option identifiers and deletes each.

bcd.bat clears event logs

The attackers then use the native wevtutil command to clear Security, System, and Application event logs. And finally, it abuses a legitimate SysInternals tool called Sync (the equivalent of the native UNIX sync()) to manually flush the cache of filesystem data to disk.

update.bat will then call msrun.bat, passing the Meteor wiper executable as a parameter. That script will in turn set the stage for its execution.

msrun.bat preparing to execute the Meteor wiper

msrun.bat moves several components into place including a screen locker (mssetup.exe) and the encrypted configuration for the Meteor wiper (msconf.conf). The script also moves four additional files: mscap.bmp, mscap.jpg, mssetup.reg, msuser.reg. At the time of writing, we were unable to recover the .reg files and have no indication of what role they play. The image files are the background images that will replace the wallpaper on locked machines.

mscap.jpg lockscreen image

The same script then creates a scheduled task called mstask set to execute the Meteor wiper at five minutes to midnight.

update.bat calls the wiper and screen locker

The final portion of update.bat checks whether mssetup.exe and the Meteor wiper are running, taking appropriate actions like exiting the script or restarting the machine as necessary.

A Wiper Triad

There’s a strange level of fragmentation to the overall toolkit. Batch files spawn other batch files, different rar archives contain intermingled executables, and even the intended action is separated into three payloads: Meteor wipes the filesystem, mssetup.exe locks the user out, and nti.exe presumably corrupts the MBR. We have been able to identify two out of three components and detail their inner workings below.

Internal naming convention visible within the wiper binary

The main payload of this convoluted attack chain is an executable dropped under env.exe or msapp.exe. Internally, the coders refer to it as ‘Meteor’. While this particular instance of Meteor suffers from a crippling OPSEC failure (the inclusion of verbose debug strings presumably intended for internal testing), it’s an externally configurable wiper with an extensive set of features.




Compilation Timestamp
2021-01-17 18:59:25

First Submission
2021-07-12 06:01:11


ITW names
env.exe / msapp.exe

The Meteor wiper is executed as a scheduled task, called mstask and set to run at five minutes to midnight. It’s supplied with a single argument, an encrypted JSON configuration file, msconf.conf (68e95a3ccde3ea22b8eb8adcf0ad53c7993b2ea5316948e31d9eadd11b5151d7), that holds values for corresponding keys contained in cleartext within the binary:


At its most basic functionality, the Meteor wiper takes a set of paths from the encrypted config and walks these paths, wiping files. It also makes sure to delete shadow copies and removes the machine from the domain to avoid means of quick remediation. The wiper includes a wealth of additional functionality, most of which isn’t used in this particular attack, including:

  • Changing passwords for all users
  • Disabling screensavers
  • Process termination based on a list of target processes
  • Installing a screen locker
  • Disabling recovery mode
  • Changing boot policy error handling
  • Creating scheduled tasks
  • Logging off local sessions
  • Changing lock screen images for different Windows versions (XP, 7, 10)
  • Creating processes and executing commands
Meteor wiper attempts two different methods to remove victim machine from Domain

The developers resort to multiple redundant methods to accomplish each of their objectives. For example, Meteor will attempt to remove the machine from the domain via WinApi functions. If that fails it will then attempt to do the same via an equivalent WMI command.

Taking a step back to evaluate the development of Meteor and what it might tell us about the threat group involved, we must note that the composition of this binary is beset by contradictory practices.

First, the code is rife with sanity checks, error checking, and redundancy in accomplishing its goals. However, the operators clearly made a major mistake in compiling a binary with a wealth of debug strings meant for internal testing. The latter is an indication that despite whatever advanced practices the developers have in their arsenal, they lack a robust deployment pipeline that ensures such mistakes do not happen. Moreover, note that this sample was compiled six months before its deployment and the mistake was not caught.

Lock My PC 4 embedded within Meteor

Secondly, the code is a bizarre amalgam of custom code that wraps open-source components (cpp-httplib v0.2) and practically ancient abused software (FSProLabs’ Lock My PC 4). While that might suggest that the Meteor wiper was built to be disposable, or meant for a single operation, that’s juxtaposed with an externally configurable design that allows efficient reuse for different operations. Many of the available keys are not instantiated in this operation, like the ability to kill specific processes. Additionally, that external configuration is encrypted, presumably to limit analysis, but all of the configurable keys are hardcoded in plaintext within the main binary.

Meteor overwrites boot.ini with the same template as bcd.bat

Taking a step back to look at the entire toolkit deployed in this operation, there are also some overlaps between the functionality contained within Meteor and that of other components executed beforehand that suggest some operational segmentation between developers of different components and the operators themselves. Functionality carried out with batch scripts is also embedded within Meteor such as disabling network adapters and corrupting boot.ini. The wiper also includes a commercial screen locker and yet this functionality is redundantly instantiated through a separate binary, mssetup.exe.

The externally configurable nature of the wiper entails that it wasn’t created for this particular operation. However, at the time of writing, we’ve been unable to find other attacks or variants of the Meteor wiper. For that reason, we are supplying a very broad (but well tested) hunting YARA rule below.

‘mssetup.exe’ Screenlocker

mssetup.exe’s WinMain() function

The MeteorExpress operators drop a standalone screenlocker. Despite a wealth of C++ template and exception handling code, mssetup.exe is simple. Most of its functionality is pictured above. It blocks user input before creating a Window that fills the entire screen. If an image is available at the hardcoded path C:tempmscap.bmp (dropped by the msrun.bat script), then it’ll use this image to fill the screen. Otherwise, it’ll draw a black rectangle. It’ll then disable the cursor and effectively lock the user out entirely. It’s worth noting that though this binary was clearly developed by the same production pipeline, it doesn’t include any of the verbose debug strings nor overt logging functionality.




Compilation Timestamp
2021-01-17 18:59:28

First Submission
2021-07-12 06:04:15


ITW names

A Missing MBR Corruptor

Finally, the Padvish security blog makes reference to an additional executable, nti.exe, that serves as an MBR corruptor. We’ve been unable to recover this at this time and suspect that the incident responders were unable to recover it themselves as their analysis centers on the corrupted MBRs rather than the binary.

Description of nti.exe Google translated from Farsi

One interesting claim in the Padvish blog is that the manner in which nti.exe corrupts the MBR is by overwriting the same sectors as the infamous NotPetya. While one’s first instinct might be to assume that the NotPetya operators were involved or that this is an attempt at a false flag operation, it’s important to remember that NotPetya’s MBR corrupting scheme was mostly cribbed from the original Petya used for criminal operations. An additional inconsistency from the Padvish blog is their claim that update.bat runs nti.exe. While they’re likely referring to a different version in their possession, our copy of update.bat makes no overt reference to nti.exe.


Conflict in cyberspace is overpopulated with increasingly brazen threat actors. Behind the artistry of this epic troll lies an uncomfortable reality where a previously unknown threat actor is willing to leverage wiper malware against public railways systems. The attacker is an intermediate level player whose different operational components sharply oscillate from clunky and rudimentary to slick and well-developed.

On the one hand, we have a new externally-configurable wiper packed full of interesting capabilities, involving a mature development process, and redundant means to accomplish their goals. Even their batch scripts include extensive error checking, a feature seldom encountered with deployment scripts. Their attack is designed to cripple the victim’s systems, leaving no recourse to simple remediation via domain administration or recovery of shadow copies.

On the other hand, we see an adversary that doesn’t yet have a handle on their deployment pipeline, using a sample of their malware that contains extensive debug features and burning functionality irrelevant to this particular operation. There’s feature redundancy between different attack components that suggests an uncoordinated division of responsibilities across teams. And files are dispensed in a clunky, verbose, and disorganized manner unbecoming of advanced attackers.

We cannot yet make out the shape of this adversary across the fog. Perhaps it’s an unscrupulous mercenary group. Or the latent effects of external training coming to bear on a region’s nascent operators. At this time, any form of attribution is pure speculation and threatens to oversimplify a raging conflict between multiple countries with vested interests, means, and motive.

Behind this epic troll/stunning provocation there’s a lot more to uncover in getting to know the actor behind MeteorExpress. We should keep in mind that the attackers were already familiar with the general setup of their target, features of the domain controller, and the target’s choice of backup system (Veeam). That implies a reconnaissance phase that flew entirely under the radar and a wealth of espionage tooling that we’ve yet to uncover.

Happy Hunting.

Indicators of Compromise

IoCs and Yara hunting rules available on SentinelLabs GitHub.



  • There are no more articles