Uncovering RedStinger – Undetected APT cyber operations in Eastern Europe since 2020

This blog post was authored by Malwarebytes’ Roberto Santos and Fortinet’s Hossein Jazi

While the official conflict between Russia and Ukraine began in February 2022, there is a long history of physical conflict between the two nations, including the 2014 annexation of Crimea by Russia and when the regions of Donetsk and Luhansk declared themselves independent from Ukraine and came under Russia’s umbrella. Given this context, it would not be surprising that the cybersecurity landscape between these two countries has also been tense. 

While looking for activities from the usual suspects, one of our former coworkers at Malwarebytes Threat Intelligence Team discovered a new interesting lure that targeted the Eastern Ukraine region and reported that finding to the public. Moreover, we started tracking the actor behind it, which we internally codenamed Red Stinger.

This investigation remained private for a while, but Kaspersky recently published information about the same actor (who it called Bad Magic). Now that the existence of this group is public, we will also share some of our information about the actor and its tactics.

Our investigation could be helpful to the community as we will provide new undisclosed data about the group. We have identified attacks from the group starting in 2020, meaning that they have remained under the radar for at least three years. Additionally, we will provide insights into the latest campaigns performed by Red Stinger, where we have found that the group has targeted entities in different places of Ukraine.

Military, transportation and critical infrastructure were some of the entities being targeted, as well as some involved in the September East Ukraine referendums. Depending on the campaign, attackers managed to exfiltrate snapshots, USB drives, keyboard strokes, and microphone recordings.

Finally, we will reveal unknown scripts and malware run by the group in this report.

Timeline

Our investigation started in September 2022, when one of our former coworkers Hossein Jazi discovered an interesting lure, that seemed to target some entities over the war context:

Tweet published by @hjazi in September 2022

In fact, this is the attack that Kaspersky analyzed in its blog. However, this was not the only activity carried out by the group. Malwarebytes has identified multiple operations, first dated in 2020. The next infographic shows some of the operations recognized by us:

Operations performed by Red Stinger

Since our investigation started in September 2022, information about the initial campaigns has been limited. However, the actor’s tactics, techniques, and procedures (TTPs) are very distinctive, which gives us a high level of confidence in our attribution.

Notes about activity before the war

OP#1 – Late 2020

The first operation we know of happened in December 2020. Although the infection chain is similar to what was already reported, the attackers were using a slightly different process back in 2020:

OP#1 Infection phase

An MSI file is downloaded from hxxp://91.234.33.185/f8f44e5de5b4d954a83961e8990af655/update.msi. This first MSI file, when executed, will show the following error to the user:

MSI file used in OP#1

In the background, this MSI file will execute a .vbs file that runs a dll file. The content is encoded using base64:

Contents of zip file and detail of shortcut.vbs

So finally, cachelib.dll will be executed. That file will drop two files named iesync.so and iesync.vbs.

iesync.so and iesync.vbs were dropped as part of OP#1 infection phase

After that, the iesync.vbs file will apply a XOR operation to iesync.so. After applying that conversion to the file, we can see that this file is what we called DBoxShell (also called PowerMagic by Kaspersky):

DboxShell variant used in OP#1

OP#2 – April 2021

We believe that the attack started with this zip file named ПОСТАНОВЛЕНИЕ № 583-НС.zip. How attackers sent this file to victims is still unknown. The lure in this case was themed about Luhansk:

Lure used in OP#2

A valid translation of this document would be:

RESOLUTION

dated March 25, 2021 No. 584-NS

Lugansk

On consideration in the second reading of the draft law

of the Luhansk People’s Republic dated March 19, 2021 No 417-PZ / 21-3

“On Amendments to the Law of the Luhansk People’s Republic

“On physical culture and sports”

ПОСТАНОВЛЕНИЕ № 583-НС.zip contains a lnk file as well as the previous pdf. This .lnk file will download an MSI file from the url hxxp://91.234.33.108/u3/ebe9c1f5e5011f667ef8990bf22a38f7/document.msi, and from there, the attack is pretty similar as the one performed in OP#1. Just a few differences to note, for example, in this case the dll used is named libsys.dll.

Dll used  at infection phase in OP#2

Also, as the image shows, paths used the folder winappstorepackage or WinStoreApps instead of CacheWidgets, that was used in OP#1. Also, the powershell script is slightly different in this case:

Powershell snippet run in OP#2

Nevertheless, the infection phase finally used DBoxShell, as before.

OP#3 – September 2021

We have very little information about this operation, but based on the TTPs, we have identified overlapping techniques with both previous and subsequent attacks.

• MSI files usage is a known signature from the group. Also, the MSI file was downloaded from hxxp://185.230.90.163/df07ac84fb9f6323c66036e86ad9a5f0d118734453342257f7a2d063bf69e39d/attachment.msi. Note the common pattern in urls.

• 185.230.90.163 belongs to ASN number 56485. All IPs used from 2020 till now belong to the same ASN.

• VT telemetry showed common patterns with OP#2.

Activity at the onset of war

After the war began, we collected information about two distinct operations.  

OP#4 – February 2022

OP#4 is perhaps one of the most interesting attacks performed by the group. As you can see in the following lines, this attack still has some characteristics that led us to attribute it to Red Stinger. Furthermore, the attack has some unique features that make it stand out as one of the most interesting ones.

In this case, the group used hxxp://176.114.9.192/11535685AB69DB9E1191E9375E165/attachment.msi to download the malicious MSI file. Note once more this common pattern in all URLs used by the group. This MSI file contained a PDF, a .vbs file, and a .dat file:

Lure used in OP#4

The group followed a similar infection chain as in previous operations. Finally, a .vbs file was responsible for XORing and executing a .dat file, which contained a small loader and a variant of DBoxShell:

DboxShell variant used in OP#4

DBoxShell is malware that utilizes cloud storage services as a command and control (C&C) mechanism. This stage serves as an entry point for the attackers, enabling them to assess whether the targets are interesting or not, meaning that in this phase they will use different tools.

A better look of how RedStinger operates can be seen in the next infographic:

Common pattern in Red Stinger operations

After the infection phase, we are aware that actors dropped at least the following artifacts:

SolarTools

In the reconnaissance phase, we noticed the execution of 2 MSI files named SolarTools.msi and Solar.msi. Both had inside tools named ngrok.exe and rsockstun.exe:

• Ngrok.exe is a legitimate tool that allows web developers to deploy applications and expose services to the internet. Other groups also used ngrok for malicious purposes.

• Rsockstun is a tool that allows attackers to route connections through external proxies.

More important, we have seen the same version of Solar.msi (02f84533a86fd2d689e92766b1ccf613) on OP#4 and OP#5, allowing us to connect the dots between these two attacks.

vs_secpack.msi

In addition to SolarTools, starting the exfiltration phase, we also found another file named vs_secpack.msi. This file contains two files: ntinit.exe and ntuser.dat, which will be located under c:/ProgramData/NativeApp. Ntinit.exe is a file that was developed as a Windows Service, named ntmscm.

Service created by ntinit.exe

Inside that service, eventually a thread will be executed. This thread contains all the functionality. Its main purpose is to execute one of the binaries hidden inside ntuser.dat, after some parsing. Also, it will execute C:/ProgramData/user.dat, if found.

vs_secpack.msi will drop ntuser.dat and ntinit.exe files

Ntuser.dat is an aggregation of PE files with a leading header and a final chunk. These executables are xored, each one with a different value. The next image shows the header:

Detail of Ntuser.dat header

This header can be seen as a C structure, defined like this:

struct head_FirstChunk{
    DWORD signature;
    DWORD osInstallDate;
    int sizeMz1;
    int sizeMz2;
    int sizeMz3;
    int sizeMz4;
    int sizeConfig;
    DWORD xorValsMZ1;
    DWORD xorValsMZ2;
    DWORD xorValsMZ3;
    DWORD xorValsMZ4;
}

Following this header, four PE files are stored consecutively and XORed. As the previous structure shows, the size and XOR value used to decode these files can be recovered from the header.

ntuser.dat contents

We won’t analyze all MZs one by one, as we want to avoid overwhelming the reader with technical details that are out of scope. For a quick reference, the first MZ was a copy of ntinit.exe and the second was a dll capable of injecting files using the Process Doppelganging technique. Curiously, InjectorTransactedHollow.dll string was found inside the binary, so possibly that was how attackers named the file originally:

Process Hollowing technique was used to perform injections in OP#4

The third was also used for injection purposes. The fourth was the most interesting, because it communicates with a new Dropbox account. Some of these will be injected or used to inject MZs into legitimate process mobisync.exe

Finally, the last chunk of ntuser.dat was a configuration file. The configuration was encrypted, and looked like this:

Config file forms the end of ntuser.dat

That configuration was encrypted using AES. The IV is the first 16 bytes of the config. The key can be recovered from the fourth MZ. In fact, this executable will use this configuration to communicate with Dropbox.

Decrypted configuration is shown next:

Decrypted config file

This configuration is pretty representative of the group’s motivation. First of all, we see a new Dropbox account being used. This Dropbox account will be used to gather exfiltrated victims data. It can be seen like the exfiltration phase starts here. Note that attackers will use one account for reconnaissance and a different one for exfiltration.

The object field was also revealing. It contained a Russian name (redacted for privacy) followed by the DNR letters (probably Donetskaya Narodnaya Respublika, referring to one of the cities declared independent in 2014, and a known target to the group). Victimology will be discussed later.

OP#5

OP#5 was the last known activity we will cover. As Kaspersky already revealed some technical details about this operation, we won’t repeat that analysis again. A link to the analysis made by them can be found at the beginning of this report.

What we can do here is provide some extra insights regarding the attack. Let’s start at the Reconnaissance phase. Reconnaissance phase starts right after DBoxShell / GraphShell is executed. This is the GraphShell version used in OP#5:

OP#5 used GraphShell instead of DBoxShell

The way GrapShell works is pretty simple, and also can be almost guessed by viewing the image. A folder tree is created:

Root

       ___ AmazonStore

                             ___ clients

                             ___ tasks

                             ___results

And as DBoxShell does, clients will hold heartbeats from clients, tasks will store tasks that will be executed at some point by victim systems, and results will be uploaded to results.

DETAIL – RECONNAISSANCE PHASE

As we were actively tracking the actors for a while, we managed to recover most of the actions performed by the attackers at this phase:

Below are indicated some of the scripts used in this phase:

ListFiles

StartNgrok

Reconnaissance

InstallPZZ

Ld_dll_loader

StartRevSocks

After that, by using some of the tooling analyzed by Kaspersky, the exfiltration phase starts.

Victimology

OP#4

As this operation happened before our investigation started, we cannot determine how many victims were infected. However, at the time we began monitoring, we still had information about two victims. Surprisingly, these two victims were located in central Ukraine. This is interesting because all the information had previously pointed to East Ukraine, where the Donbass region is located.

Map of Ukraine, where known targets in OP#4 were highlighted

One of the victims was a military target, but the activity on this target was only carried out for a few hours. We have reason to believe that the user noticed something wrong, and executed an antimalware solution shortly after being infected, which likely detected and cleaned the system. 

As far as we know, attackers managed to exfiltrate on this target several screenshots, microphone recordings and some office documents.

The other victim we found was located in Vinnitsya. Target was an officer working in critical infrastructure. Attackers made a great and long surveillance of this victim, which extended until Jan 2023. They have exfiltrated screenshots, microphone and office documents, but also keystrokes were uploaded.

OP#5

With the victimology shared in OP#4, we may think that this was a group targeting only UA-aligned entities. However, the analysis of OP#5 revealed an interesting fact: it mainly targeted RU-aligned entities.

REFERENDUM TARGETS

OP#5 started in September 2022. Back in those days, Russia made referendums at Luhansk, Donetsk, Zaporizhzhia and Kherson. While that was happening, Red Stinger targeted and made surveillance to officers and individuals involved in those elections. 

Two victims attacked in OP#5 were workers at Yasinovataya Administration (Donetsk). Another victim was also part of DPR administration, in Port Mariupol. All of them were performing different activities regarding elections. We also have found one victim holding the advisor position from CEC (Central Election Commission). According to Wikipedia, “The Central Election Commission of the Russian Federation (Russian: Центральная избирательная комиссия Российской Федерации, abbr. ЦИК, also Центризбирком) is the superior power body responsible for conducting federal elections and overseeing local elections in the Russian Federation”.

Central Election Commission of the Russian Federation (CIK) stamp

Regarding CEC, we had seen another victim codenamed CIK_03D502E0. CIK is also another term that could refer to CEC. Attackers showed great interest in this one, as this victim was one of the only ones with its own name (some were just identified by using a drive ID). Also, USB drives from that victim were uploaded. Next image shows a small fraction of filenames exfiltrated by the attackers. To clarify, TИK probably stands for TEC (Territorial Election Commision).

Detail of exfiltrated USB from CIK_03D502E0

Reconnaissance phase also revealed some nice info. DNS records obtained from another victim showed mail.gorod-donetsk.org, pop.gorod-donetsk.org, which could suggest that the victim was part of DPR administration. 

From that same victim, those DNS records revealed connections against xn--j1ab.xn--b1adbccegehv4ahbyd6o2c.xn--p1ai (лк[.]лидерывозрождения[.]рф) translate Revival Leaders. That website was created “in behalf of Putin”, and is a contest to find potential leaders and fill out positions at Kherson, Zaporozhye, DPR and Lugansk. It is unclear which positions will be filled by that, but winners were promised to get 1.000.000 rubles for a personally chosen training program in the Russian Federation.

лк[.]лидерывозрождения[.]рф webpage photo

OTHER VICTIMS

In addition to the victims involved in the September referendums, we also identified two other victims that did not seem to be related to the elections. One of them appeared to be related to the transportation ministry or equivalent, codenamed by the attackers as ZhdDor, which could be translated as “railroad.” We also found additional data that suggested that the attackers could be interested in transportation.

Furthermore, we discovered that a library in Vinnitsya was infected in OP#5. Although this victim was UA-aligned, we do not understand why it was a target, especially since it was the only UA entity targeted in OP#5. However, it is worth noting that in OP#4, an entity located in Vinnitsya was also targeted.

EASTERN EGG

Finally, we have 2 victims named TstSCR and TstVM. It turns out that attackers, at some point, infected their own machines in order to carry out some testing, or by mistake.

Exfiltrated screenshot showing one of the attacker’s machine

This first image is a good example of that. First of all, we noticed that the keyboard language was set to ENG, which is unexpected. This may suggest that the group was composed of native English speakers. However, we find it strange because of the way they named the project folder (internet_WORK). We cannot be certain, but we believe that no native speaker would use that naming convention.

Exfiltrated screenshot showing one of the attacker’s machine while debugging Overall.exe

This second image is also nice to show. As you may notice, this is the source code of the file Overall.exe (reported by researchers), while being debugged. Also, some of the victim folders we named in this report are shown as part of the sources.

Exfiltrated screenshot showing one of the attacker’s machine. Some internal paths were shown in that screenshot.

For the account TstVM we choose this screenshot. In this case, attackers were developing a tool they use to tunnel victim communications. It can be seen (redacted) how source code reveals external IP addresses used by them, as some internal ones, naming for machines that we have not redacted and even passwords.

Analysis of these machines also revealed the usage of the application AdvOr, used for tunneling communications through TOR.

Attribution

In this case, attributing the attack to a specific country is not an easy task. Any of the involved countries or aligned groups could be responsible, as some victims were aligned with Russia, and others were aligned with Ukraine.

What is clear is that the principal motive of the attack was surveillance and data gathering. The attackers used different layers of protection, had an extensive toolset for their victims, and the attack was clearly targeted at specific entities. Perhaps in the future, further events or additional activity from the group can shed light on the matter.

Indicators of Compromise

OP#1

OP#2

OP#3

OP#4

OP#5

Malwarebytes EDR and MDR remove all remnants of ransomware and prevent you from getting reinfected. Want to learn more about how we can help protect your business? Get a free trial below.

TRY NOW

https://blog.malwarebytes.com/feed/