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

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.

AlphaGolang

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)
94c58c7fb43153658eaa9409fc78d8741d3c388d3b8d4296361867fe45d5fa45

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.

References

Guides and Documentation

Videos

Tools

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.

Conclusion

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.

Introduction

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

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

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.

SHA256
2aa6e42cb33ec3c132ffce425a92dfdb5e29d8ac112631aec068c8a78314d49b

SHA1
86e4f73c384d84b6ecd5ad9d7658c1cc575b54df

MD5
04633656756847a79c7a2a02d62e5522

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

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

Size
587KB

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:

state_path
log_encryption_key
processes_to_kill
process_termination_timeout
log_server_port
locker_background_image_jpg_path
auto_logon_path
locker_background_image_bmp_path
state_encryption_key
log_server_ip
log_file_path
paths_to_wipe
wiping_stage_logger_interval
locker_installer_path
locker_exe_path
locker_registry_settings_files
locker_password_hash
users_password
cleanup_scheduled_task_name
self_scheduled_task_name
cleanup_script_path
is_alive_loop_interval

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.

SHA256
074bcc51b77d8e35b96ed444dc479b2878bf61bf7b07e4d7bd4cf136cc3c0dce

SHA1
e55cee8b49f80e957b52976b2da6379e329466a3

MD5
9a49102f53291a644bd14c8202d8fbe3

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

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

Size
85KB

ITW names
mssetup.exe

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.

Conclusion

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.

References

https://www.timesofisrael.com/hack-causes-chaos-on-iran-trains-posts-supreme-leaders-number-for-complaints/
https://www.voanews.com/middle-east/voa-news-iran/hackers-disrupt-irans-rail-service-fake-delay-messages
https://www.reuters.com/world/middle-east/hackers-breach-iran-rail-network-disrupt-service-2021-07-09/
https://twitter.com/cherepanov74/status/1416643609131114497?s=20
https://threats.amnpardaz.com/malware/trojan-win32-breakwin/
https://www.malwaretech.com/2017/06/petya-ransomware-attack-whats-known.html
https://www.reuters.com/article/us-emirates-tech-israel/uae-target-of-cyber-attacks-after-israel-deal-official-says-idUSKBN28G0BW

MeteorExpress | Mysterious Wiper Paralyzes Iranian Trains with Epic Troll

29 July 2021 at 10: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.

Introduction

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

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

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:\Windows\Temp\__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.

SHA256
2aa6e42cb33ec3c132ffce425a92dfdb5e29d8ac112631aec068c8a78314d49b

SHA1
86e4f73c384d84b6ecd5ad9d7658c1cc575b54df

MD5
04633656756847a79c7a2a02d62e5522

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

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

Size
587KB

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:

state_path
log_encryption_key
processes_to_kill
process_termination_timeout
log_server_port
locker_background_image_jpg_path
auto_logon_path
locker_background_image_bmp_path
state_encryption_key
log_server_ip
log_file_path
paths_to_wipe
wiping_stage_logger_interval
locker_installer_path
locker_exe_path
locker_registry_settings_files
locker_password_hash
users_password
cleanup_scheduled_task_name
self_scheduled_task_name
cleanup_script_path
is_alive_loop_interval

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:\temp\mscap.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.

SHA256
074bcc51b77d8e35b96ed444dc479b2878bf61bf7b07e4d7bd4cf136cc3c0dce

SHA1
e55cee8b49f80e957b52976b2da6379e329466a3

MD5
9a49102f53291a644bd14c8202d8fbe3

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

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

Size
85KB

ITW names
mssetup.exe

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.

Conclusion

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.

References

https://www.timesofisrael.com/hack-causes-chaos-on-iran-trains-posts-supreme-leaders-number-for-complaints/
https://www.voanews.com/middle-east/voa-news-iran/hackers-disrupt-irans-rail-service-fake-delay-messages
https://www.reuters.com/world/middle-east/hackers-breach-iran-rail-network-disrupt-service-2021-07-09/
https://twitter.com/cherepanov74/status/1416643609131114497?s=20
https://threats.amnpardaz.com/malware/trojan-win32-breakwin/
https://www.malwaretech.com/2017/06/petya-ransomware-attack-whats-known.html
https://www.reuters.com/article/us-emirates-tech-israel/uae-target-of-cyber-attacks-after-israel-deal-official-says-idUSKBN28G0BW

The post MeteorExpress | Mysterious Wiper Paralyzes Iranian Trains with Epic Troll appeared first on SentinelLabs.

ThunderCats Hack the FSB | Your Taxes Didn’t Pay For This Op

8 June 2021 at 16:00

Key Findings

  • This research focuses on the ‘Mail-O’ malware used against the FSB and other Russian government organizations, detailed in the May 2021 FSB NKTsKI and Rostelecom-Solar report.
  • Early armchair commentary presumed that given the targets, this attack would undoubtedly be the work of a Western government, Five Eyes, or the United States.
  • Our analysis disproves that hypothesis.
  • Instead, we present the argument that the Mail-O malware is a variant of a relatively well-known malware called PhantomNet or SManager used by a threat actor ‘TA428’
  • Previous reporting on TA428 points to Chinese origin and details a history of attacks against South East Asian and Russian targets.

Actor Disambiguation

Related actors: TA428, suspected IronHusky
Related operations: Operation SignSight, Operation LagTimeIT
Related malware: PhantomNet, SManager, TManger, CoughingDown

In May 2021, the Russian Federal Security Service’s National Coordination Center for Computer Incidents (NKTsKI) in coordination with Rostelecom announced that several Russian government institutions had been victims of an APT campaign. While the Russian government has made a similar announcement before, it’s the first time they’ve accompanied it with a moderately detailed technical analysis. Several researchers, myself included, jumped on the opportunity to write our YARA rules and hope for a glimpse at the culprit.

The InfoSec twitterverse needed no such artifacts as blind speculation immediately pointed at a Western government, Five Eyes, or the United States as de facto culprits. I think we’ll be relieved to find out that was most likely not the case – if solely because we’ve come to expect a higher standard for Western malware development.

Initial attempts to find the samples were fruitless but that changed this past weekend as some kind soul (or more likely a bulk autosubmitter) uploaded a copy of the ‘Mail-O’ malware to VirusTotal. We track this activity under the name ‘ThunderCats’.

Technical Analysis

SHA256
603881f4c80e9910ab22f39717e8b296910bff08cd0f25f78d5bff1ae0dce5d7
SHA1
b7c1ec9484c4c2dcd01f861eeaa3b915c3e3312e
MD5
d58b95f8413f784552d7fdadbb621243
Size
2.82 MB
Compilation Timestamp
2019-12-20 02:13:01
First Submitted
2021-06-05 05:22:04

In line with the findings of the NKTsKI-Rostelecom report, the Mail-O malware acts as a downloader with a thin veneer of similarity to the legitimate Mail.ru Disk-O software. The disguise consists of a version number (“19.05.0045”) lifted from a legitimate Disk-O executable and the use of a real Mail.ru to post victim details and host a next stage payload.

The executable is bulked up to 2.8MB by statically linking both libcurl 7.64.1 and OpenSSL. Focus becomes important to avoid going down a pointless rabbithole of reversing unrelated open-source code. For that reason, we should focus primarily on the exported functions.

The Mail-O malware exports two functions, Entery and ServiceMain:

Mail-O malware’s exported functions

Mail-O: ServiceMain

ServiceMain function pseudocode

ServiceMain takes a service name as an argument and attempts to register a service control handler with a specific HandlerProc function meant to check and set the status of that service. With a valid service status handle, Mail-O detaches the calling process from its console, changes the service status values to reflect its current running state, and calls the Entery function. Note the ServiceMain function with the debug string “ServiceMain Load” – a template that comes into play in looking for connections to other malware.

Mail-O: Entery

The Entery function is called at the end of ServiceMain, but it can also be independently invoked. It checks for the presence of ‘%AllUsersProfile%\PSEXESVC.EXE’ and launches it as a process. This function is registered as a top level exception filter.

Mail-O PSEXESVC.exe check function

The main Entery logic is orchestrated in the next function. First, Mail-O checks the registry for an existing install of the legitimate Mail.Ru Disk-O software. It decrypts configuration strings and contacts https://dispatcher.cloud.mail.ru/.

Mail-O uses the SystemTime to POST the encrypted victim hostname (or in its absence the string “[none]”) and receive a payload. The payload is written to a temporary path before being launched. Mail-O then goes into a sleep loop until a predetermined amount of time.

We’ve yet to see ‘Webdav-O’, the other malware component described in the Rostelecom-Solar report. However, that shouldn’t keep us from following an interesting lead.

The ‘Entery’ Connection


Left: TManger sample (NTT Security)
71fe3edbee0c27121386f9c01b723e1cfb416b7af093296bd967bbabdc706393

Right: Mail-O sample:
603881f4c80e9910ab22f39717e8b296910bff08cd0f25f78d5bff1ae0dce5d7

Mail-O exports a function called Entery, presumably a misspelling of ‘Entry’. Misspellings are a true gift for malware researchers. As it turns out, this isn’t the first time that misspelling has been noted in a recently deployed piece of malware.

In December 2020, Ignacio Sanmillan and Matthieu Faou released an excellent report on a Vietnamese supply-chain attack that used PhantomNet (aka SManager) malware. The researchers noted that the malware’s persistence was established via a scheduled task that called the malicious DLL’s export, ‘Entery’. The researchers note that this same export was pointed out by NTT Security in their analysis of TManger malware, which they in turn correlate with Proofpoint’s ‘TA428’ threat actor. That nondescript threat actor name is adopted by Dr. Web in reporting recent attacks against additional Russian targets including research institutes.

While that might all seem a bit convoluted, I rehearse the logical connections to illustrate two points:

  1. There’s an established history of this very non-Western ‘threat actor’ in targeting both Asian and Russian targets.
  2. These presumably Chinese clusters of activity are confusing and difficult to disentangle. Tooling is likely shared among multiple threat actors (likely including PhantomNet/SManager), and what’s being referred to as ‘TA428’ is probably an amalgam of multiple threat groups.

For skeptics, we’ve provided a YARA rule below for the Entery overlap, which entails not just the export function name but also the general layout of the function and some shared strings. Note that the layout has likely developed iteratively from an open-source template.

Finally, while I’m quick to disparage the quality of the malware as not up to some exalted Western standard, it’s important to note that ThunderCats (and the larger TA428 umbrella) are pulling off custom-tailored region-specific supply chain attacks, successfully punching way above their weight in their intelligence collection efforts, and they should not be underestimated as an adversary.

YARA

import "pe"

rule apt_CN_ThunderCats_Overlap
{
	meta:
        desc = "Thundercats Entery Export Overlap"
        author = "JAG-S @ SentinelLabs"
        version = "1.0"
        last_modified = "06.08.2021"
        reference = "https://rt-solar.ru/upload/iblock/b55/Ataki-na-FOIV_otchet-NKTSKI-i-Rostelekom_Solar_otkrytyy.pdf"

	strings:
		$psexesvc = "%AllUsersProfile%\\PSEXESVC.EXE" ascii wide
		$sm_load = "ServiceMain Load" ascii wide fullword
	condition:
		uint16(0) == 0x5a4d
		and
		pe.exports("Entery")
		and
		pe.exports("ServiceMain") 
		and 
		all of them
}

References

https://www.bbc.com/news/world-europe-36933239
https://www.reuters.com/technology/russias-fsb-reports-unprecedented-hacking-campaign-aimed-government-agencies-2021-05-26/
https://rt-solar.ru/analytics/reports/2203/
https://rt-solar.ru/upload/iblock/b55/Ataki-na-FOIV_otchet-NKTSKI-i-Rostelekom_Solar_otkrytyy.pdf
https://st.drweb.com/static/new-www/news/2021/april/drweb_research_attacks_on_russian_research_institutes_en.pdf
https://www.welivesecurity.com/2020/12/17/operation-signsight-supply-chain-attack-southeast-asia/

The post ThunderCats Hack the FSB | Your Taxes Didn’t Pay For This Op appeared first on SentinelLabs.

NobleBaron | New Poisoned Installers Could Be Used In Supply Chain Attacks

1 June 2021 at 17:14

Executive Summary

  • In late May, 2021, Microsoft and Volexity released public reports detailing recent Nobelium activity.
  • Nobelium is suspected to be the new face of APT29 (aka The Dukes). We track this activity under the name ‘NobleBaron’.
  • This campaign employs a convoluted multi-stage infection chain, five to six layers deep.
  • Most custom downloaders leverage Cobalt Strike Beacon in-memory as a mechanism to drop more elusive payloads on select victims.
  • This report focuses on NobleBaron’s ‘DLL_stageless’ downloaders (aka NativeZone)
  • SentinelLabs has discovered the use of one of these DLL_stageless downloaders as part of a poisoned update installer for electronic keys used by the Ukrainian government.
  • At this time, the means of distribution are unknown. It’s possible that these update archives are being used as part of a regionally-specific supply chain attack.
  • We uncovered additional unreported DLL_stageless downloaders.

Overview

After the extensive revelations of Russian state-sponsored cyberespionage activities over the past five years, teams like APT28 (aka FancyBear, STRONTIUM) and APT29 (aka CozyBear, The Dukes) have retooled and reorganized extensively to avoid easy tracking by Western governments and security vendors alike. The operations of ‘APT29’ no longer look anything like they did in the past half decade. At this point our preconceptions about these groups are doing more to cloud our judgment than they elucidate. Perhaps new naming conventions (like ‘NOBELIUM’ or ‘StellarParticle’) will help piece these new clusters of activity apart– all the while upsetting folks who would prefer a simpler threat landscape than the one our reality affords us.

We track this new activity under the name ‘NobleBaron’, building off of the excellent reporting by Microsoft and Volexity. We acknowledge the suspicion that this is a newer iteration of APT29 but share in the general trepidation to equate the two. While the aforementioned companies have done excellent work exposing the inner workings of this activity, we wanted to contribute additional variants we encountered in our follow-on research, including a curious particularly insidious packaging of the ‘NativeZone’ downloader as part of a poisoned installer for a Ukrainian cryptographic smartkey used in government operations.

A Convoluted Infection Chain

As noted by Microsoft, the actor appears to be experimenting with various multi-stage infection chains. Common variations include the method of delivering the ISO containers and a wide variety of custom downloaders enmeshed with Cobalt Strike Beacon. There’s a vague mention of an iOS zero-day being hosted on Nobelium fingerprinting servers but no mention as to whether this entails an iOS payload. That said, we also suspect no company is in a position to monitor iPhone endpoints for these payloads, Apple included.

While the Cobalt Strike Beacon payload is a disappointingly ubiquitous end for such a convoluted infection chain, it’s not in fact the end of that chain. Rather, it serves as an early scout that enables selective distribution of rarer payloads directly into memory where they’re less likely to be detected. A similar technique was employed by HackingTeam’s Remote Control System (RCS) where initial infections used their ‘Scout’ malware for initial recon and could then be selectively upgraded to the full ‘Elite’ payload. After years of burned iterations on custom toolkits, it seems NobleBaron has opted for maximizing return on investment by simply lowering their upfront investment.

Notable TTPs include the following:

  • An increasing depth in multi-layer droppers (a concept briefly described by Steve Miller and worth exploring further) particularly with regard to the inevitable CS Beacon payload.
  • The use of large size files to avoid detection by security solutions with hardcoded size limits for ‘efficiency’.
  • A fishing-with-dynamite approach to collecting initial access to victims with low-cost tooling. The SolarWinds supply chain attack is one such example of starting with a wide victim pool and whittling down to high-value targets.

A Curious Poisoned Installer

SHA256
3b94cc71c325f9068105b9e7d5c9667b1de2bde85b7abc5b29ff649fd54715c4
SHA1
fc781887fd0579044bbf783e6c408eb0eea43485
MD5
66534e53d8751a24a767221fed01268d
Compilation Timestamp
2021-05-18 10:21:20
First Submission
2021-05-18 13:26:14
Size
282KB
Internal Name
KM.FileSystem.dll
File Description
ІІТ Бібліотека роботи з НКІ типу: "файлова система" (Ukrainian)

Most notably, one of these NativeZone downloaders is being used as part of a clever poisoned installer targeting Ukrainian government security applications. A zip file is used to package legitimate components alongside a malicious DLL (KM.Filesystem.dll). The malicious KM.Filesystem.dll was crafted to impersonate a legitimate component of the Ukrainian Institute of Technology’s cryptographic keys of the same name. It even mimics the same two exported functions as the original.

KM.Filesystem.dll exported functions

The package is not an ISO, but it follows a familiar formula. ‘ScanClientUpdate.zip’ relies on a triad of sorts. An LNK is used to kick off the malicious KM.FileSystem.dll component. In turn, KM.FileSystem.dll starts by checking for presence of KM.EkeyAlmaz1C.dll (a benign DLL). This check is presumably meant as an anti-sandbox technique that would keep this downloader from executing unless it’s in the same directory as the other packaged components.

ScanClientUpdate.zip contents

We stop short of referring to this as a supply chain attack since we lack visibility into its means of distribution. The poisoned installer may be delivered directly to relevant victims that rely on this regional solution. Alternatively, the attackers may have found a way of abusing an internal resource to distribute their malicious ‘update’.

LNK starter command to run the malicious DLL

The LNK starter invokes the KMGetInterface export to execute the malware’s functionality. It passes a benign Windows component as an argument (ComputerDefaults.exe). The attackers will use the file’s attributes later on.

Upon execution, the user is presented with a vague ‘Success’ message box.

Note that the heading of the message box is ‘ASKOD’, a reference to the Ukrainian electronic document management system. This initiative is meant to enforce electronic digital signatures through the use of cryptographic keys like the Алмаз-1К (transliterated as ‘Almaz-1K’ or translated to ‘Diamond-1K’) shown below.

Алмаз-1К electronic key description

These particular electronic keys are referenced in Ukrainian government tenders and make for a cunning regional-specific lure to distribute malware.

After displaying the message box, the malicious DLL proceeds to resolve APIs by hash and decrypts its payload directly into memory. You guessed it: Cobalt Strike Beacon v4.

It then decrypts the configuration via single-byte XOR 0x2E and attempts to establish contact with the command-and-control server doggroomingnews[.]com. It checks for ‘/storage/main.woff2’ and if necessary falls back to ‘/storage/page.woff2’. The domain resolves to an IP address in Ukraine (45.135.167.27), which appears to be a compromised domain.

While we have not been able to fetch the response at this time, it’s worth noting that this same IP was also contacted by a Cobalt Strike Beacon sample in late 2020:

5a9c48f49ab8eaf487cf57d45bf755d2e332d60180b80f1f20297b16a61aa984 artifact.exe

These malicious updates are distributed in zip archives. At this time, we’ve discovered two ‘ScanClientUpdate.zip’ samples, both containing the same malicious DLL:

51b47cd3fc139e20c21897a00ac4e3b096380f939633233116514a1f2d9e63d5
ca66b671a75bbee69a4a4d3000b45d5dc7d3891c7ee5891272ccb2c5aed5746c

‘DLL_stageless’ (NativeZone) Variants

NobleBaron developers internally refer to these components under the name ‘DLL_stageless’

DLL_stageless PDB path

The following are variants of DLL_stageless with their respective delivery mechanisms and encrypted command-and-control configuration.

SHA256
2a352380d61e89c89f03f4008044241a38751284995d000c73acf9cad38b989e
SHA1
6114655cf8ddfd115156a1c450ba01e31887fabb
MD5
77605aa6bd6fb890b9b823bd7a3cc78b
Compilation Timestamp
2021-03-15 18:32:47
First Submission
2021-04-01 14:06:27
Size
299.50KB
ITW Name
MsDiskMountService.dll
Malicious Export
DiskDriveIni
C&C
74d6b7b2.app.giftbox4u[.]com
SHA256
776014a63bf3cc7034bd5b6a9c36c75a930b59182fe232535bb7a305e539967b
SHA1
247a32ebee0595605bab77fc6ff619f66740310b
MD5
e55d9f6300fa32458b909fded48ec2c9
Compilation Timestamp
2021-03-22 08:51:41
First Submission
2021-03-22 20:39:52
Size
351.50KB
ITW Name
diassvcs.dll
Malicious Export
InitializeComponent
C&C
content.pcmsar[.]net
SHA256
a4f1f09a2b9bc87de90891da6c0fca28e2f88fd67034648060cef9862af9a3bf
SHA1
19a751ff6c5abd8e209f72add9cd35dd8e3af409
MD5
600aceaddb22b9a1d6ae374ba7fc28c5
Compilation Timestamp
2021-02-17 13:18:24
First Submission
2021-02-25 16:33:09
Size
277KB
ITW Name
GraphicalComponent.dll
Malicious Export
VisualServiceComponent
C&C
139.99.167[.]177

Analyzing GraphicalComponent.dll led to the discovery of another DLL_stageless sample. At this time, we have not discovered the delivery mechanism. The name suggests the possibility of a different poisoned installer, with a focus on the Java SRE runtime.

SHA256
c4ff632696ec6e406388e1d42421b3cd3b5f79dcb2df67e2022d961d5f5a9e78
SHA1
95227f426d8c3f51d4b9a044254e67a75b655d6a
MD5
8ece22e6b6e564e3cbfb190bcbd5d3b9
Compilation Timestamp
2020-10-02 07:51:09
First Submission
2020-12-16 14:48:01
Size
277.50KB
ITW Name
Java_SRE_runtime_update.dll
Malicious Export
CheckUpdteFrameJavaCurrentVersion
C&C
hanproud[.]com

The malicious functionality of this sample is launched via the exported function CheckUpdteFrameJavaCurrentVersion. This particular instance of DLL_stageless doesn’t check for a nearby file or specific directory.

References

https://twitter.com/MalwareRE/status/1398394028127932416
https://www.microsoft.com/security/blog/2021/05/27/new-sophisticated-email-based-attack-from-nobelium/
https://www.microsoft.com/security/blog/2021/05/28/breaking-down-nobeliums-latest-early-stage-toolset/
https://www.volexity.com/blog/2021/05/27/suspected-apt29-operation-launches-election-fraud-themed-phishing-campaigns/

The post NobleBaron | New Poisoned Installers Could Be Used In Supply Chain Attacks appeared first on SentinelLabs.

  • There are no more articles
❌