As you can see, AnyRun already had set the IP 92.63.197.]245 (electrumx.]ml) as suspicious. Other IPs from this range 92.63.197.0/24 were related to malicious activity. For example 92.63.197.]48 was associated to GrandCrab here. And 92.63.197.]153 was related to a Phorphiex campaign here.

Additionally, I found more ElectrumX nodes at 92.63.192.]249 and 92.63.192.]250. Again, malicious activity is related to IPs of the same range, 92.63.192.]186 is a PredatorTheThief panel at the moment this post is being written. http://92.63.192.]139/pay contains phishing.


Malicious ElectrumX Servers Patched Source Code

We have been able to find the patched ElectrumX source code being executed by these servers. It is a tuned variant of the version 1.8.2 of ElectrumX server.

You can find the source code of the malicious server here (password: infected12345678).


Original ElectrumX source code  vs  Patched source code

You can find the original ElectrumX 1.8.2 at github.

We have compared the patched version vs original version. There are multiple differences, but, for example, one of the key differences is found at the source code /electrumx/server/session.py:

At this point, depending on the Electrum client version, the patched ElectrumX server is giving a different phishing message. These phishing messages look like these:

Patched Malicious ElectrumX Server PHP Control Panel

Malicious code's authors added a PHP control panel that would let them to configure the server easily. The source code for this panel is shared into the same zip file as the patched server code (pass: infected12345678). Among other things, the PHP panel would let the authors to update the phishing messages.

Malicious Peers

Taking a look at the patched source code (/electrumx/lib/coins.py) we can find a list of peers different than the original source:

Additionally we have been able to collect some peers that have been connected (probably most of the 92.63.*.* are running this patched ElectrumX malicious server):

Here is the full list in text format of the servers that we have been able to collect.

• Original Packed Sample: 2b251483ed7705c60ee12b561280a1fc

• Unpacked Sample (dll): 2a298a650b50eb89041548e57d72f726

• Virustotal First Submission: 2019-10-11 10:35:13

• Related links:

  • https://research.checkpoint.com/2019/ponys-cc-servers-hidden-inside-the-bitcoin-blockchain/

  • https://unit42.paloaltonetworks.com/russian-language-malspam-pushing-redaman-banking-malware/

  • https://www.welivesecurity.com/wp-content/uploads/2017/02/Read-The-Manual.pdf

Analysis

• 1. Anti-analysis tricks

  • 1.1. C2 encoded into bitcoin transactions

  • 1.2. Checks machine name vs user name

  • 1.3. Encrypted strings

  • 1.4. Unpacked module needs correct argument to work properly

  • 1.5. Checks for typical sandboxes files, directories, processes...

  • 1.6. Checks for security products

  • 1.7. Disable Safeboot

• 2. Bot commands and malware capabilities

• 3. Yara rules

• 4. List of encrypted strings

1. Anti-analysis tricks

1.1. C2 encoded into bitcoin transactions

This trick, discovered by checkpoint and explained in this post, is really interesting. The malware gets the C2 addresses from the bitcoin blockchain. The malware doesn't carry C2 addresses into the binary. It carries (in the list of encrypted strings) some urls of some services offering APIs related to bitcoin blockchain:

• "viabtc.com"

  • "/res/btc/transactions/addressv2?address="

• "api.blockcypher.com"

  • "/v1/btc/main/addrs/"

  • "?limit=10"

• "blockchain.info"

  • "/rawaddr/"

• "blockchain.coinmarketcap.com"

  • "/api/address?address="

  • "&symbol=BTC&start=1&limit=10"

Additionally, it carries another encrypted string with the C2 schema, a bitcoin address and the C2 uri:

• "http://1N9ALZUgqYzFQGDXvMY5j1c7PGMMGYqUde/index.php" 

Then, the malware composes the blockchain API url, and queries the transactions for the given bitcoin address, for example:

https://api.blockcypher.com/v1/btc/main/addrs/1N9ALZUgqYzFQGDXvMY5j1c7PGMMGYqUde?limit=10

(Find a copy of the json response here: https://pastebin.com/rC9pF2F2)

The malware uses some fields of this json response (exactly the values of the transactions) to compose the C2 addresses, as explained in the following image (click on the image to expand):

The threat actor only needs to perform some new transaction with the given bitcoin address to update the C2 list.

This is quite interesting. A malware could be keeping all kind of information and configs in the blockchain. It could use these APIs such as api.blockcypher.com, etc... or it could download the blockchain to get all the transactions directly from the blockchain and recover all the needed information.

A domain can be sinkholed, but, using this method, it would be hard to forbid the malware to get updates.

1.2. Checks machine name vs user name

This is another trick, quite aggresive, that I hadn't seen before. Basically, the malware gets tthe computer name and the user name. It removes the "-PC" suffix from the computer name, the in compares the computer name (without -PC) with the username (uppercase). If they are the same, exit.

Frequently, real usual users' machines have computer names like DESKTOP-JMP24OS, etc... I suppose with this aggresive trick the malware tries to avoid being executed in sandboxes, AV emulators, etc...

1.3. Encrypted strings

As explained at welivesecurity' article, the malware decrypts the strings that it is going to use by using a custom rc4 algorithm.

Here, Im just going to explain how I got the decrypted urls directly from memory and Im going to share the script that I used to add IDA comments automatically. I used the following Windbg commands to dump all the decrypted strings and their positions in the strings' table:

bp <base_unpacked_mod> + 291F5  (at this point, strings were decrypted a moment ago)

Print decrypted ascii strings:

.for ($t0=0;@$t0<0x18b;r $t0=@$t0+1){ .printf "%d ",4*@$t0; da poi (<base_unpacked_mod>+2C93C+4*@$t0); .printf "\r\n"; }

Print decrypted unicode strings:

.for ($t0=0;@$t0<0xb6;r $t0=@$t0+1){ .printf "%d ",4*@$t0; du poi (<base_unpacked_mod>+2CF68+4*@$t0); .printf "\r\n"; }

With these commands, i got the list of strings (ascii and unicode), and I used the following IDA python script to set comments foreach part of the code where these strings are being used:

1.4. Unpacked module needs correct argument to work properly

Once the malware is unpacked, the real redaman dll is launched with rundll32 and DllGetClassObject method is called, and an argument is given:

rundll32 <redaman dll path>, DllGetClassObject <password>

The given password needs to be correct, if it is not correct, the encrypted strings cant be decrypted and the malware exits.

1.5. Checks for typical sandboxes files, directories, processes...

It checks for the following files or directories at c:\ or d:\ : cuckoo, fake_drive, strawberry, tsl, targets.xls, perl, wget.exe

It checks for the following names in the own module name: myapp.exe, self.exe, t.exe

And for the following processes: vboxservice.exe, python.exe

1.6. Checks for security products


Redaman uses the WbemScripting.SWbemLocator API to search for intalled security products:

1.7. Disable Safeboot



The malware deletes the current safeboot value:

2. Bot commands and malware capabilities

I recommend to read the welivesecurity' article to learn about the protocol and encryption used by Redaman banking malware.

It looks in the newer versions of the malware they have introduced a much longer list of commands that the bot can receive from the C2 and execute. This is the complete list (each command and name is quite self-explanatory):

• keylogger.last-data

• keylogger.last-wnd-caption

• keylogger.last-exe-path

• botnet-prefix

• botnet-id

• cc.connect-interval

• scan-files

• post-install-report

• cc.url

• modules.

• modules-data.

• del-module

• unload

• uninstall

• uninstall-lock

• find-files

• download

• shutdown

• reboot

• cc

• get-cc

• botnet-id

• prefix

• connect-interval

• hosts-add

• hosts-clear

• dbo-scan

• cfg-set-str-a

• cfg-set-str-w

• cfg-set-dw

• cfg-get-str-a

• cfg-get-str-w

• cfg-get-dw

• cfg-del-param

• screenshot

• dns

• set-dns

• get-dns

• kill-process

• lpe-runas-flags

• scards.monitoring-interval

• auto-elevate

• reload

• scard-off

• modules-off

• dbo-detector-off

• multiinstance-off

• keylogger-off

• dns-servers-changed

• hosts-file-changed

• video.refresh-interval

• video-start

• video-stop

• del-files

Additionally, in the list of encrypted strings, the malware carries a list of strings to match against the browser window name. In case of match, it is a target site (most of them bank websites) to steal credentials from. This is the list of urls of the analyzed sample:

• online.payment.ru

• bankline.ru

• /ic/login.zhtml

• /servlets/ibc

• faktura.ru

• /iclient/

• ibank2

• bco.vtb24.

• bo.vtb24.

• dbo.vtb.

• elbrus.raiffeisen

• elba.raiffeisen

• handybank.

• wupos.westernunion

• online.sberbank.

• minbank.ru

• e-plat.mdmbank.

• link.alfabank

• click.alfabank

• ib.avangard

• ibc.vuzbank.

• ibc.ubrr.

• my.modulbank.

• online.centrinvest.

• cb.mtsbank.

• vbo.mkb.

• i.bspb.ru

• i.vtb.ru

• bc.rshb.

• /vpnkeylocal

• sci.interkassa

• ibank.mmbank.

• blockchain.info

• /wallet/

• cb.asb.by

• bps-sberbank.by

• dbo2.bveb.by

• ibank.bsb.by

• corporate.bgpb.by

• ibank.alfa-bank.by

• ibank.belinvestbank.by

• ib2.ideabank.by

• client.paritetbank.by

• ibank.priorbank.by

• client.mybank.by

• online.stbank.by

• client.belapb.by

• Unk

• SberBank_PC

• BSS

• BSS_PC

• iBank2_PC

• Faktura

• PCB

• InterPro

• RosBank

• SBBO

• INIST

• Inversion

• Interbank

• iBank2

• BiCrypt

• VTB24

• 1C

• SGB

• Raiffeisen

• HandyBank

• WU

• SB_Fiz

• CFT

• WinPost

• SBIS

• ClBank

• QiwiCashier

• ISCC

• WebMoney

• xTC

• iFOBS

• TRANSAQ

• OSMP

• MinBank

• SFT

• MDM

• ALBO

• Alfa_Fiz

• Avangard

• Intercassa

• Amikon

• Vuzbank

• UBRR

• ModulBank

• CentrInvest

• MTSBank

• MKB

• EL_CLI

• BSPB

• IVTB

• RSHB

• Infocrypt

• MMBank

• BlockchainInfo

• HBClient

• ASB

• BPS_SB

• BVEB

• BSB

• BGPB

• ALBO_BY

• BelInvest

• IdeaBank

• Paritet

• PriorBank

• MyBank

• StBank

• BelAPB

• scDBO

• AvestCSP

3. Yara rules

4. List of encrypted strings

• Original packed samples

  • Frenchy shellcode v1 + autoit packer: 0a1340bb124cd0d79fa19a09c821a049 (Avemaria)

  • Frenchy shellcode v2 + autoit packer: d009bfed001586db95623e2896fb93aa 

  • Frenchy shellcode v2 + autoit packer: 20de5694d7afa40cf8f0c88c86d22b1d (Formbook)

  • Frenchy shellcode v3 + .Net packer: 21c1d45977877018568e8073c3Acf7c5 (Netwire)

• Extracted frenchy shellcodes:

  • Frenchy shellcode v1 at hybrid analysis

  • Frenchy shellcode v2 at hybrid analysis

  • Frenchy shellcode v3 at hybrid analysis

• Related links:

  • https://tccontre.blogspot.com/2019/07/autoit-compiled-formbook-malware.html (I recommend to read this post about the AutoIt script that loads frenchy shellcode).

  • https://twitter.com/P3pperP0tts/status/1135976656751996928?s=20

  • https://twitter.com/JayTHL/status/1146482606185308160?s=20

  • https://twitter.com/James_inthe_box/status/1148966237684133888?s=20

  • https://cape.contextis.com/analysis/85189/

  • https://twitter.com/James_inthe_box/status/1146527056567472128?s=20

Most of the samples that I have analyzed are packed with a AutoIt-based packer (however, recently I analyzed a v3 Frenchy shellcode whose packer is .Net) that decrypts and loads the shellcode (and then, the shellcode loads the next stage executable by using process hollowing method).

First sample where I found the Frenchy shellcode (v1, mutex: frenchy_shellcode_01) was Emotet and the packer was AutoIt-based, I recommend to read this twitter thread. Later, in this twitter thread, @JayTHL commented about an AveMaria Stealer, again packed with AutoIt-based packer that uses the shellcode (v2, mutex: frenchy_shellcode_002). An specific campaing of Agenttesla looked to be using this packer too. In this great post, the author (@tccontre18) analyzed a variant of the obfuscated autoit script that loads the Frenchy shellcode (in this case, it loaded a Formbook Stealer). Searching for the string "frenchy_shellcode_003" I found another sample at Cape Sandbox using v3 shellcode (@james_in_the_box identified it as netwire), and in this case the packer is not AutoIt-based, but .Net-based.

It looks like this shellcode has been used for a time together with different packers, malware families and campaigns.

Analysis

• 1. Packers

  • 1.1. AutoIt-based Packer

  • 1.2. DotNet-based Packer

• 2. Frenchy Shellcode

  • 2.1. Frenchy Shellcode V3

    • 2.1.1. Entrypoint and arguments

    • 2.1.2. Duplicated system libraries

    • 2.1.3. API usage

    • 2.1.4. Process Hollowing

  • 2.2. Playing With Frenchy Shellcode

• 3. Who is Frenchy?

1.1. Packers

I am not going to dig too much into the packers that have been seen together with the Frenchy shellcode, only some notes about them.

1.1. AutoIt-based Packer

This packer executes a very obfuscated autoit script that decrypts and loads the frenchy shellcode. Here is a couple of examples of these autoit scripts:

This one (recovered by @DbgShell) loaded a frenchy_shellcode_01: https://pastebin.com/raw/xsUqCdRj

This other one loaded a frenchy_shellcode_002: https://pastebin.com/raw/Knk2iJPF

I recommend this post about the AutoIt script that loads frenchy shellcode.


1.2. DotNet-based Packer

In the case of the sample 21c1d45977877018568e8073c3Acf7c5 the packer is .Net. To check that the dotnet packer is loading the frenchy shellcode we set a bp at CreateMutexW and we wait for the creation of the frenchy_shellcode_03 mutex:

Now we know the current thread is executing the Frenchy shellcode, so we display the call-stack to check the thread that calls the frenchy shellcode comes from .Net:

2. Frenchy Shellcode

2.1. Frenchy Shellcode v3


I have focused the analysis on the v3 shellcode that I have gotten from the sample 21c1d45977877018568e8073c3Acf7c5 (you can download it from hybrid analysis).

The main purpose of this shellcode is to inject a PE into a new process by using the hollow process method.

2.1.1. Entrypoint and arguments

Shellcode's entrypoint is located at offset 0, where the shellcode jumps to the main function:

The shellcode receives as first argument the path of the executable that is going to be launched (suspended) to perform hollow process. Second argument is the content (PE) to be injected.


2.1.2. Duplicated system libraries

The shellcode loads copies foreach system library that it is going to use:

If we enumerate the regions of the address space we can check there are some duplicated dlls:

This could make harder debugging the shellcode. API hooks (such as hooks inserted by cuckoo framework for example) won't work. If you set breakpoints at common APIs that are usually executed by malware (CreateProcessW, WriteProcessMemory, SetThreadContext, etc...) to catch the malware execution at that point, it won't work, because you would need to set breakpoints at the duplicated dlls.


2.1.3. API usage

The shellcode gets a pointer to a lot of APIs, but it only uses a subset of them. I feel like this is a very configurable shellcode, it always loads all the API pointers, but depending of the configuration and the code that it is added to the specific version of the shellcode, some API pointers will be used and other pointers won't be used.

Here is the full list of APIs that the shellcode loads:

Sometimes the shellcode gets pointers to the APIs on the originally loaded dlls. For example this happends with cryptoapi libraries. I guess this is because they don't work fine when they are called through a secondary copy of the dll.

2.1.4. Process Hollowing

The malware creates a new suspended process from the path of the given executable, and then it injects the given PE into the address space of that process by using the process hollowing method. It uses a set of native APIs to perform this task.

In the following capture we can see how the malware creates a new process and unmap the main module of the new created process. In addition, it maps the PE to be injected (to get a mapped copy of this PE) by calling NtCreateSection+NtMapViewOfSection:

Once it has unmapped the main module of the target process to be hollowed, and it has gotten a mapped view of the PE to be injected, it creates a new section into the target process address space to copy the PE to be injected there. It will use NtCreateSection + NtMapViewOfSection + NtWriteProcessMemory to perform this task:

Finally it changes the context of the main thread of the injected process to set EIP = injected code's starting address, and resumes the thread.


2.2. Playing With Frenchy Shellcode

To be honest, I consider this shellcode quite well-coded, it works fine. I decided to write a tiny PoC, a python script that loads and calls it, pushing as arguments the path of notepad.exe (target executable to use when performing hollow process) and the content of calc.exe'sPE file (the PE to be injected), to execute in this way a calc.exe in the context of notepad.exe, by using process hollowing.

Here you can find the PoC together with the Frenchy shellcode v3:

https://github.com/p3pperp0tts/PoC_FrenchyShellcode

from ctypes import *
import struct

f = open("frenchyshellcode.bin", "rb")
frenchy = f.read()
f.close()
f = open("c:\\windows\\system32\\calc.exe", "rb")
calc = f.read()
f.close()
hollowpath = "c:\\windows\\notepad.exe\x00"
#to test, full shellcode = frenchy + arguments for frenchy + code to jmp
lenshellcode = len(frenchy) + len(calc) + len(hollowpath) + len("\x68\x00\x00\x00\x00\x68\x78\x56\x34\x12\x68\x78\x56\x34\x12\x68\x78\x56\x34\x12\xc3")
ptr = windll.kernel32.VirtualAlloc(None, lenshellcode, 0x3000, 0x40)
shellcode = frenchy
shellcode += calc
shellcode += hollowpath
shellcode += "\x68" + struct.pack("<L", ptr + len(frenchy)) #push path to process to hollow
shellcode += "\x68" + struct.pack("<L", ptr + len(frenchy)+len(calc)) #push address of pe to inject
shellcode += "\x68\x00\x00\x00\x00" #fake ret addr
shellcode += "\x68" + struct.pack("<L", ptr) #push address of frenchy shellcode entry point
shellcode += "\xc3" #jmp to frenchy
hproc = windll.kernel32.OpenProcess(0x1F0FFF,False,windll.kernel32.GetCurrentProcessId())
windll.kernel32.WriteProcessMemory(hproc, ptr, shellcode, len(shellcode), byref(c_int(0)))
windll.kernel32.CreateThread(0,0,ptr+len(frenchy)+len(calc)+len(hollowpath),0,0,0)
windll.kernel32.WaitForSingleObject(c_int(-1), c_int(-1))

3. Who is Frenchy?

There is an user at hackforums that looks quite related to this issue.

• Original Packed Sample: ae4d420c05281acf9696e558b02a42f8

• Unpacked Sample: f81064db46e305025ac6e2610e272eb3

• Source Url: hxxp://soksanhotels[.]com/calendar/daes/thai8.exe

• Info Url: URLhaus

• Automatic Generated Report: PepperMalware Report

• Virustotal First Submission: 2019-05-08 20:31:00

• Related links:

  • https://twitter.com/avman1995/status/1072415443556679681

  • https://twitter.com/P3pperP0tts/status/1127239398398013441

  • https://www.antiy.net/p/be-aware-of-new-variant-of-agenttesla-commercial-keylogger/

  • https://twitter.com/dvk01uk/status/1082151041720897537

Analysis

• 1. About the Sample Classification

• 2. Loader

  • 2.1. Shellcode and jump to unmanaged code

  • 2.2. Hollow Process

• 3. Unpacked module

  • 3.1. Strings Decryptor

    • 3.1.1. Strings Index Mixer

    • 3.1.2. AES Strings Encryption

    • 3.1.2. List of Decrypted Strings

  • 3.2. Decompiled Source Code With Decrypted Strings

• 4. Yara rules

1. About the Sample Classification

I have had lot of problems to classify this sample, not clear if Megalodon or Agenttesla SMTP variant.

At this tweet I tagged it as Agenttesla, and, in fact, when I started to write this article as agenttesla, then i changed to megalodon, and finally again to agenttesla.

I recomment these twitter threads, about this:

• https://twitter.com/dvk01uk/status/1082151041720897537

• https://twitter.com/P3pperP0tts/status/1127239398398013441

• https://twitter.com/avman1995/status/1072415443556679681

After reading this antiy labs analysis, I noticed the decrypted strings of the sample that I analyzed matched the strings of the sample analyzed by antiy labs.

It seems the sample that I analyzed is a newer version of the antiy labs article' one, with encryption of strings and a kind of mixer for the index into the table of encrypted strings.

2. Loader

2.1. Shellcode and jump to unmanaged code

The loader is not hardly obfuscated. The malware seems to decode a shellcode and a second unpacked PE from a image at resources:

Once the shellcode + pe is decrypted, it allocates memory (VirtualAlloc) and copies the shellcode there. To jump the unmanaged code (the shellcode) it creates a window and associates the shellcode address to that window (the window's procedure), and then it calls CallWindowProc:

2.2. Hollow Process

The shellcode creates a new suspended process from the same executable to perform hollow process:

In summary, the shellcode creates a new suspended process, calls NtUnmapViewOfSection to unmap the original PE image from memory, then allocates memory for writting the unpacked PE image (VirtualAllocEx), and copies the unpacked PE (mapping each section at the corresponding in memory rva) by calling WriteProcessMemory (btw, the injected PE is .Net PE, the unpacked agenttesla). Finally it calls SetThreadContext to set EIP = RtlUserThreadStart, and ResumeThread.

3. Unpacked Module

3.1. Strings Decryptor

The malware contains an array of encrypted strings (it is object_0 at this source):

Each time the malware needs a string, it calls a function that receives as argument an ID for the needed string:

3.1.1. Strings Index Mixer


The string decryptor "smethod_strings_decryptor" doesn't receive a index into the array of encrypted strings as argument, it receives a kind of ID for the strings:

The first block of code of the decryptor of strings is a mixer (it is found in the same source that the encrypted strings) that transforms the given string ID to the index into the array of encrypted strings for that string:

An equivalent python code for this mixer is at github.

I guess this mixer could change between samples and versions.


3.2.2. AES Strings Encryption


Once an index into the array of encrypted strings is gotten, the string is decrypted. The format for each encrypted string in the array is:

[32 bytes AES key] [16 bytes AES IV][encrypted string]

And the string is decrypted by using AES_CBC algorithm. At github you can find an equivalent decryptor written in python:

https://github.com/p3pperp0tts/mlwcfg_tools/blob/master/AgentTesla_SMTP_Variant_05_2019/decstr.py


It receives as argument an string ID and print the decrypted string for that ID.

3.2.3. List of Decrypted Strings


Here it's the full list of decrypted strings that the analyzed sample use:

https://github.com/p3pperp0tts/mlwcfg_tools/blob/master/AgentTesla_SMTP_Variant_05_2019/encstr.txt

3.2. Decompiled Source Code With Decrypted Strings

I have uploaded a decompiled source code for the unpacked agenttesla from sample ae4d420c05281acf9696e558b02a42f8:

https://github.com/p3pperp0tts/malware_decompiled_code/tree/master/AgentTesla_SMTP_Variant_05_2019

This source code is commented with the associated decrypted string for each part of the code where an string is being decrypted, making easier to understand the malware behavior:

4. Yara Rules

Yara Rule for Unpacked AgentTesla:

       

rule AgentTesla_SMTP_Variant_05_2019_mem {
    strings:
  $AESdec = { 28 ?? ?? ?? ?? 25 FE 09 01 00 6F ?? ?? ?? ?? 25 FE 09 02 00 6F ?? ?? ?? ?? 6F ?? ?? ?? ?? FE 09 00 00 20 00 00 00 00 FE 09 00 00 8E 69 6F ?? ?? ?? ?? 2A }
  $StrDecLast = { 25 16 07 16 09 28 ?? ?? ?? ?? 25 09 08 16 11 04 28 ?? ?? ?? ?? 09 11 04 58 11 0D 16 11 0C 28 ?? ?? ?? ?? 28 ?? ?? ?? ?? 11 0D 07 08 28 ?? ?? ?? ?? 6F ?? ?? ?? ?? 2A }
    condition:
    all of them
}
       
 

From this code:

1. Original Packed Sample: 40e751c032c75d33c807219b2de6c584

2. Source Url: hxxp://54.38.22[.]53/spike/svchost.exe

3. Info Url: URLhaus

4. Automatic Generated Report: PepperMalware Report

5. Virustotal First Submission: 2018-06-10 16:37:46

6. Other AlphaIrcbot samples at Any.Run: 

1. asdjdsffdgnms.exe (2018-08-19 10:25:54)

2. KFDJfd.exe (2018-11-16 00:26:10)

3. jjunpkvyalquru.exe (2018-09-01 21:40:15) 

1. Any.Run Tags: alphaircbot

2. Related links:

1. https://hackforums.net/showthread.php?tid=5875152 

2. http://offensivecommunity.net/showthread.php?tid=76358

3. https://urlhaus.abuse.ch/browse/tag/AlphaIRCBot/ 

4. https://yck1509.github.io/ConfuserEx/ 

5. https://github.com/Loksie/KoiVM-Virtualization

6. https://docs.microsoft.com/en-us/dotnet/framework/tools/sos-dll-sos-debugging-extension 

7. https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-managed-code 

8. https://mindlocksite.wordpress.com/2017/02/11/easy-way-to-unpack-confuserex-1-0-max-settings/ 

9.  https://github.com/CodeCracker-Tools/MegaDumper

Analysis

• 1. Obfuscated loader

• • 1.1. ConfuserEx 1.0.0 + KoiVM

  • 1.1.1. Obfuscated code

  • 1.1.2. Dumping module from memory

  • 1.1.3. Reaching dynamic assemblies' code in memory with Windbg

    • 1.1.3.1. List assemblies

    • 1.1.3.2. List method tables

    • 1.1.3.3. Enum threads, display threads' stacks and malware jit generated code

    • 1.1.3.4. Following jit generated code's references to deobfuscated malware data

• 2. Deucalion / AlphaIrcbot

• • 2.1. IoCs

  • 2.2. Unpacked strings

  • 2.3. Malware characteristics

    • 2.3.1. Irc server, channel and communications

    • 2.3.2. Reversing tools detection

  • 2.4. Yara rule

1. Obfuscated loader

1.1. ConfuserEx 1.0.0 + KoiVM

ConfuserEx is an obfuscator for .NET applications with the following characteristics: Symbol renaming, WPF/BAML renaming, Control flow obfuscation, Method reference hiding, Anti debuggers/profilers, Anti memory dumping, Anti tampering (method encryption), Embedding dependency, Constant encryption, Resource encryption, Compressing output, Extensible plugin API.

KoiVM is a virtual machine made to work on ConfuserEx that turns the .NET opcodes into new ones that only are understood by KoiVM machine. KoiVM would let virtualize every single method (including protections from ConfuserEx), or it would let just virtualize the methods that the user decides.

1.1.1. Obfuscated code

From my point of view, the analyzed sample is obfuscated with ConfuserEx and additionally, the full code (including protections from ConfuserEx) is virtualized with KoiVM. When I tried to decompile the sample's code with dnSpy, the decompiled code didn't fit the code described in some articles about deobfuscating ConfuserEx.

After applying de4dot, we get Deucalion method a bit clearer, however sub-methods are still unable to be deobfuscated:

1.1.2. Dumping module from memory

Trying to debug / deobfuscate the obfuscator layer was crazy, most of the times the code was unable to be decompiled, dnSpy crashed, etc... Tools as DeconfuserEx didn't work for this sample, probably because of the KoiVM virtualization.

We can try to dump the PE from memory with any debugger or tools like megadumper:

However the module in memory is almost identical to the original one in disk. This is because the original code is unpacked and loaded as a dynamic assembly. We can explore in-memory assemblies with ProcessExplorer:

1.1.3. Reaching dynamic assemblies' code in memory with Windbg

Windbg makes easier to walk assemblies and parse .Net structures. It is necesary to load sos debugging extension.

1.1.3.1. List assemblies

Now it is possible to use the command !DumpDomain to display the loaded assemblies (from Microsoft documentation: DumpDomain enumerates each Assembly object that is loaded within the specified AppDomain object address. When called with no parameters, the DumpDomain command lists all AppDomain objects in a process).

The command shows domain info:

And the list of assemblies:

Among the list of assemblies we can find the assemblies that were loaded dynamically:

1.1.3.2. List method tables

Having an assembly, it is possible to get info about it and list the method tables.

Method table:

Display jit generated code for a method:

1.1.3.3. Enum threads, display threads' stacks and malware jit generated code

Enumerate threads:

Callstack for a thread running managed code:

1.1.3.4. Following jit generated code's references to deobfuscated malware data

Walking the threads and exploring the stacks and the jit generated code, we can reach jit generated code belonging the malware code. For example:

Following the references to data from this code, we can find blocks of deobfuscated data used by the malware:

In the previous capture, a pointer to an string used by the jit generated code is followed to the memory region where the data resides. The base of the region is got with the command !address, and dumped to disk with .writemem. Now it is possible to use sysinternals' strings.exe to get the strings into the dumped data.

2. Deucalion / Alpha Ircbot

2.1. IoCs

• schtasks.exe /create /sc minute /mo 1 /tn "Dec<computer user name>" /tr <sample path>

• SOFTWARE\Microsoft\Windows\CurrentVersion\Run

• SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

• ngt.fun  -> irc server

• #paradox  -> irc channel

• http://ip-api.com/line/  -> to get ip info

• List of deobfuscated strings: https://pastebin.com/T244r7bn

2.2. Unpacked strings

This is the list of unpacked strings:

2.3. Malware characteristics

Taking a look at the deobfuscated strings we can guess some characteristics of the malware.

2.3.1. Irc server, channel and communications

Bots connect ngt.fun:1928 (80.82.64.205:1928) irc server. This is a capture of the irc channel. The user KiloAlpha sends commands for the bots:

Here is the list of commands (extracted from deobfuscated strings) that the CnC can send to the bots:

• BOTKILLER

• HTTP

• DRAIN

• HTTPSTRONG

• HTTPNULL

• POST

• SMARTBYPASS

• HTTPBYPASS

• STOPALL

• STOP

• PAGEHTTP

• DOWNLOAD_EXECUTE

• UPDATE

• COOKIE

• HTTPKILL

• REFERER

• BLAZING

• BACKEND

• INFORMATION

• LIST

• STATUS

• RNHTTP

• TCP

• UDP

• GAMETCP

• GAMEUDP

• KILL

• SAY

• GEO

• SPLITPERCENT

• SPLITCPU

• SPLITGEOk

I would say the bot does not perform too much checks to verify the origin of the command, I have not tried but I would bet it would be possible to inject commands to the bots.

2.3.2. Reversing tools detection

• vboxservice

• wireshark

• fidderl

• charles

• cheat

• dnspy

• megadump

• olly

• hack

• de4dot

• tcpdump

• sniffer

• sandbox

• vmtool

• ida

• \dnSpy\dnSpy.xml

• SELECT * FROM AntiVirusProduct

2.4. Yara rule

       
rule deucalion {
strings:
        $s1="schtasks.exe" wide ascii
        $s2="/delete /tn \"{0}\" /F" wide ascii
        $s3="/create /sc minute /mo 1 /tn \"{0}\" /tr \"{1}\"" wide ascii
        $s4="cmd.exe" wide ascii
        $s5="/C ping 1.1.1.1 -n 3 -w 3000 > Nul & Del \"{0}\"" wide ascii
        $s6="BOTKILLER" wide ascii
        $s7="HTTP" wide ascii
        $s8="DRAIN" wide ascii
        $s9="HTTPSTRONG" wide ascii
        $s10="HTTPNULL" wide ascii
        $s11="POST" wide ascii
        $s12="SMARTBYPASS" wide ascii
        $s13="HTTPBYPASS" wide ascii
        $s14="STOPALL" wide ascii
        $s15="STOP" wide ascii
        $s16="PAGEHTTP" wide ascii
        $s17="DOWNLOAD_EXECUTE" wide ascii
        $s18="UPDATE" wide ascii
        $s19="COOKIE" wide ascii
        $s20="HTTPKILL" wide ascii
        $s21="REFERER" wide ascii
        $s22="BLAZING" wide ascii
        $s23="BACKEND" wide ascii
        $s24="INFORMATION" wide ascii
        $s25="LIST" wide ascii
        $s26="STATUS" wide ascii
        $s27="RNHTTP" wide ascii
        $s28="GAMETCP" wide ascii
        $s29="GAMEUDP" wide ascii
        $s30="SPLITPERCENT" wide ascii
        $s31="SPLITCPU" wide ascii
        $s32="| CORES: {0} | RAM: {1} GB | FLOODS RUNNING: {2} | ANTI VIRUS: {3} | COUNTRY: {4} | DEUCALION: {5} IRC |" wide ascii
        $s33="config\\machine.config" wide ascii
condition:
        (29 of them)
}

• Original Packed Sample: 89782B6CDAAAB7848D544255D5FE7002

• Source Url: http://a4.doshimotai[.]ru/pxpx.exe

• Info Url: VxVault URLhaus

• Automatic Generated Report: PepperMalware Report

• Virustotal First Submission: 2019-03-18 22:28:20

• Any.Run Analysis: Here

• Any.Run Tags: Evasion, Trojan, Rat, Quasar

• My Classification: I named it GrandSteal because of the internal .Net classes names (if you have any information about any well-known family that this malware belongs to, please, tell me and I will update this post)

• Decompiled Source Code: PepperMalware Github

Analysis

• 1. Loader

• 2. Unpacked Modules

  • 2.1. List of Unpacked Modules

  • 2.2. Stealer

    • 2.2.1. Chromium Stealer

      • 2.2.1.1. Cookies

      • 2.2.1.2. Credentials

      • 2.2.1.3. Autofills

      • 2.2.1.4. Credit Cards

    • 2.2.2. Wallets Stealer

    • 2.2.3. Files From Personal Directories Stealer

    • 2.2.4. Discord Software Stealer

    • 2.2.5. FileZilla Stealer

    • 2.2.6. Gecko Stealer

    • 2.2.7. RDP Stealer

    • 2.2.8. Telegram Stealer

• 3. Yara Rule

• 4. Strings of the Main Unpacked Module

1. Loader

• The sample is not signed.

• Version Info:

• • Product Symantec© 2019

  • Description pxpx.exe

  • Original Name pxpx.exe

  • Internal Name pxpx.exe

  • File Version 7.1.0.0

  • Comments Symantec Application

• The loader module is a .Net executable that is obfuscated with ConfuserEx v1.0.0 

2. Unpacked Modules

2.1. List of Unpacked Modules

Once we have executed the sample into the VM, we can check with Windbg that the malware unpacks a set of modules in memory:

After dumping these executables to disk we check that most of them are .Net executables, that we can decompile with dnSpy:

GrandSteal.* are the main modules of the malware. I uploaded the decompiled code for these modules to my GitHub. Additionally the malware carries some libraries that it will need.

2.2. Stealer

The malware contains code to steal credentials from different products:

2.2.1. Chromium Stealer

The malware is able to steal different information from Chromium Browsers:

The source code related to this functionality is ChromiumManager.cs.

The malware steals all the Chromium's information from the browser's sqlite database.

2.2.1.1. Cookies

It reads the cookies table from the sqlite database.

2.2.1.2. Credentials

It reads the logins table from the sqlite database.

2.2.1.3. Auto Fills

It reads the autofill table from the sqlite database.

2.2.1.4. Credit Cards

It reads the table credit_cards from the sqlite database.

2.2.2. Wallets Stealer

The malware is able to steal wallets from the following crypto-coin products:

• Litecoin: "%appdata%\Litecoin\wallet.dat"

• Litecoin-Qt: walletpath=read("HKCU\Software\Litecoin\strDataDir"), walletpath + "wallet.dat"

• Litecoin-Qt: walletpath=read("HKCU\Software\Litecoin-Qt\strDataDir"), walletpath + "wallet.dat"

• Bitcoin: "%appdata%\Bitcoin\wallet.dat"

• Bitcoin-Qt: walletpath=read("HKCU\Software\Bitcoin\strDataDir"), walletpath + "wallet.dat"

• Bitcoin-Qt: walletpath=read("HKCU\Software\Bitcoin-Qt\strDataDir"), walletpath + "wallet.dat"

• Bytecoin: "%appdata%\bytecoin\*.wallet"

• Exodus: "%appdata%\Exodus\*"

• Dash-Qt: walletpath=read("HKCU\Software\Dash\strDataDir"), walletpath + "wallet.dat"

• Dash-Qt: walletpath=read("HKCU\Software\Dash-Qt\strDataDir"), walletpath + "wallet.dat"

• Electrum: "%appdata%\Electrum\wallets\*"

• Ethereum: "%appdata%\Ethereum\wallets\*"

• Monero: walletpath=read("HKCU\Software\monero-project\wallet_path"), walletpath + "wallet.dat"

• Monero: walletpath=read("HKCU\Software\monero-core\wallet_path"), walletpath + "wallet.dat"

The source code related to this functionality is ColdWalletManager.cs.

2.2.3. Files From Personal Directories Stealer

The malware can steal files from Desktop, Favorites and Personal folders:

The source code related to this functionality is DesktopFileManager.cs.

2.2.4. Discord Software Stealer

From wikipedia: "Discord is a proprietary freeware VoIP application and digital distribution platform designed for video gaming communities, that specializes in text, image, video and audio communication between users in a chat channel".

The malware is able to steal information from this VoIP application by using a curious method. It calls DbgHelp.dll APIs (MiniDumpWriteDump) to create a minidump of any process containing the word "Discord" in the name.

Once the minidump file is created, it searchs the minidump for Discord json sessions by using a regex:

The source code related to this functionality is DiscordManager.cs.

2.2.5. FileZilla Stealer

The malware reads credentials from FileZilla XML files:

The source code related to this functionality is FileZillaManager.cs.

2.2.6. Gecko Stealer

From wikipedia: "Gecko is a browser engine developed by Mozilla. It is used in the Firefox browser, the Thunderbird email client, and many other projects".

The malware locates some Gecko important files:

It is able to recover credentials:

And cookies:

The source code related to this functionality is GeckoManager.cs.

2.2.7. RDP Stealer

The malware can steal RDP credentials:

The source code related to this functionality is RdpManager.cs.

2.2.8. Telegram Stealer

The malware reads the files located at:

"%appdata%\Telegram Desktop\tdata\D877F783D5D3EF8C\map*"

From that files, it tries to recover Telegram sessions:

The source code related to this functionality TelegramManager.cs.

3. Yara Rules

       
rule grandsteal {
strings:
        $s1 = "ws://{0}:{1}/websocket" wide
        $s2 = "GrabBrowserCredentials: " wide
        $s3 = "GrabColdWallets: " wide
        $s4 = "GrabDesktopFiles: " wide
        $s5 = "GrabTelegram: " wide
        $s6 = "ColdWallets parser has been started" wide
        $s7 = "DiscordSession parser has been started" wide
        $s8 = "Rdps parser has been started" wide
        $s9 = "DesktopFiles parser has been started" wide
        $s10 = "FTPs parser has been started" wide
        $s11 = "TelegramSession parser has been started" wide
        $s12 = "ListOfProcesses parser has been started" wide
        $s13 = "ListOfPrograms parser has been started" wide
        $s14 = "card_number_encrypted" wide
        $s15 = "\\Litecoin\\wallet.dat" wide
        $s16 = "\\Bitcoin\\wallet.dat" wide
        $s17 = "\\Exodus\\exodus.wallet" wide
        $s18 = "\\Electrum\\wallets" wide
        $s19 = "\\Ethereum\\wallets" wide
        $s20 = "monero-project" wide
        $s21 = "Discord dump UNKNOWN" wide
        $s22 = "{0}\\FileZilla\\recentservers.xml" wide
        $s23 = "{0}\\FileZilla\\sitemanager.xml" wide
        $s24 = "cookies.sqlite" wide
        $s25 = "password-check" wide
        $s26 = "AppData\\Roaming\\Telegram Desktop\\tdata\\D877F783D5D3EF8C" wide
        $s27 = "%USERPROFILE%\\AppData\\Local\\Temp\\Remove.bat" wide
        $s28 = "taskkill /F /PID %1" wide
        $s29 = "choice /C Y /N /D Y /T 3 & Del %2" wide
        $s30 = "ExtractPrivateKey" wide
        $s31 = "formSubmitURL" wide
        $s32 = "passwordField" wide
        $s33 = "usernameField" wide
        $s34 = "GrabDiscord" wide
        $s35 = "encryptedPassword" wide
        $s36 = "masterPassword" wide
        $s37 = "WalletName" wide
condition:
        (30 of them)
}

4. Strings of the Main Unpacked Module

• https://domekan.ru/ModuleMystery/Updates.txt

• SQLite format 3

• ws://{0}:{1}/websocket

• Server is initialized

• CredentialsRequest has been created

• ParseClientSettings

• GrabBrowserCredentials: 

• GrabColdWallets: 

• GrabDesktopFiles: 

• GrabTelegram: 

• Invalid JsonMessage data from server. Exception : 

• ClientInfos parser has been started

• ClientInfos has been parsed.Elapsed time: {0}

• Browsers parser has been started

• Browsers has been parsed.Elapsed time: {0}

• ColdWallets parser has been started

• ColdWallets has been parsed.Elapsed time: {0}

• DiscordSession parser has been started

• DiscordSession has been parsed.Elapsed time: {0}

• Rdps parser has been started

• Rdps has been parsed.Elapsed time: {0}

• DesktopFiles parser has been started

• DesktopFiles has been parsed.Elapsed time: {0}

• FTPs parser has been started

• FTPs has been parsed.Elapsed time: {0}

• TelegramSession parser has been started

• TelegramSession has been parsed.Elapsed time: {0}

• ListOfProcesses parser has been started

• ListOfProcesses has been parsed.Elapsed time: {0}

• ListOfPrograms parser has been started

• ListOfPrograms has been parsed.Elapsed time: {0}

• encrypted_value

• expiration_month

• expiration_year

• card_number_encrypted

• username_value

• password_value

• AppData\Roaming\

• AppData\Local\

• \Litecoin\wallet.dat

• \Bitcoin\wallet.dat

• \Exodus\exodus.wallet

• \Electrum\wallets

• \Ethereum\wallets

• monero-project

• JsonSession UNKNOWN

• Discord dump UNKNOWN

• Discord process UNKNOWN

• ({"token":"(.*)}}]})

• {0}\FileZilla\recentservers.xml

• {0}\FileZilla\sitemanager.xml

• cookies.sqlite

• [^\u0020-\u007F]

• password-check

• AppData\Roaming\Telegram Desktop\tdata

• AppData\Roaming\Telegram Desktop\tdata\D877F783D5D3EF8C

• D877F783D5D3EF8C*

• AppData\Roaming

• AppData\Local\Temp

• The binary key cannot have an odd number of digits: {0}

• %USERPROFILE%\AppData\Local\Temp\Remove.bat

• taskkill /F /PID %1

• choice /C Y /N /D Y /T 3 & Del %2

• ClientSettings.db

•  1.85 (Hash, version 2, native byte-order)

• FileDescription

• GrandSteal.Client.Data

• GrandSteal.Client.Data.dll

• ExtractPrivateKey3

• ExtractPrivateKey4

• get_formSubmitURL

• set_formSubmitURL

• GrandSteal.Client.Data

• RoamingAppData

• get_ObjectData

• set_ObjectData

• System.Collections.Generic

• Microsoft.VisualBasic

• get_ManagedThreadId

• get_CurrentThread

• get_timePasswordChanged

• set_timePasswordChanged

• get_timeLastUsed

• set_timeLastUsed

• get_timeCreated

• set_timeCreated

• HandleWorkCompleted

• OnWorkCompleted

• countCompleted

• OnResponseRecieved

• add_DataReceived

• add_MessageReceived

• System.Collections.Specialized

• get_passwordField

• set_passwordField

• get_usernameField

• set_usernameField

• BrowserCreditCard

• get_GrabDiscord

• get_encryptedPassword

• set_encryptedPassword

• get__masterPassword

• set_WalletName

• get_encryptedUsername

• set_encryptedUsername

• set_AllowUnstrustedCertificate

• DebuggerNonUserCodeAttribute

• DebuggableAttribute

• ComVisibleAttribute

• AssemblyTitleAttribute

• UserScopedSettingAttribute

• AssemblyTrademarkAttribute

• ExtensionAttribute

• AssemblyFileVersionAttribute

• AssemblyConfigurationAttribute

• AssemblyDescriptionAttribute

• CompilationRelaxationsAttribute

• AssemblyProductAttribute

• AssemblyCopyrightAttribute

• ConfusedByAttribute

• ParamArrayAttribute

• AssemblyCompanyAttribute

• RuntimeCompatibilityAttribute

• get_SQLDataTypeSize

• clientInfoFlag

• set_EnableAutoSendPing

• System.Threading

• get_DataEncoding

• FromBase64String

• DownloadString

• CreateTempPath

• get_ObjectLength

• set_ObjectLength

• set_ExpirationMonth

• get_Passwordcheck

• TransformFinalBlock

• ReadBrowserCredendtial

• ExtractManagerCredential

• ExtractRecentCredential

• op_GreaterThanOrEqual

• set_AutoSendPingInterval

• RuntimeTypeModel

• System.ComponentModel

• GrandSteal.Client.Data.dll

• BrowserAutofill

• get_BaseStream

• UserStreamParam

• ExceptionParam

• get_GrabTelegram

• SymmetricAlgorithm

• ICryptoTransform

• IsNullExtension

• DiscordSession

• discordSession

• TelegramSession

• telegramSession

• FindDiscordJsonSession

• GrandSteal.SharedModels.Communication

• set_ClientInformation

• RemoteClientInformation

• System.Configuration

• System.Globalization

• System.Reflection

• StringCollection

• MatchCollection

• CryptographicException

• ArgumentException

• GeckoPasswordBasedEncryption

• GrandSteal.Client.Models.Extensions.Json

• FileSystemInfo

• ProcessStartInfo

• GrandSteal.Client.Data.Gecko

• DeSerializeProto

• MiniDumpWriteDump

• set_ExpirationYear

• Key4MagicNumber

• set_CardNumber

• SHA1CryptoServiceProvider

• MD5CryptoServiceProvider

• TripleDESCryptoServiceProvider

• CrytoServiceProvider

• IFormatProvider

• FileZillaManager

• DiscordManager

• DesktopFileManager

• TelegramManager

• ChromiumManager

• ColdWalletManager

• ConvertToInteger

• ObjectIdentifier

• ResponseHandler

• System.CodeDom.Compiler

• ClientInfoHelper

• RecoveryHelper

• GrandSteal.Client.Data.Server

• InitializeServer

• CreateDecryptor

• System.Diagnostics

• AddMilliseconds

• timeoutMilliseconds

• get_BrowserCreditCards

• set_BrowserCreditCards

• GetCreditCards

• System.Runtime.InteropServices

• Microsoft.VisualBasic.CompilerServices

• System.Runtime.CompilerServices

• DebuggingModes

• get_ChildNodes

• get_BrowserCookies

• set_BrowserCookies

• get_Directories

• GetDirectories

• get_MasterEntries

• set_MasterEntries

• ExpandEnvironmentVariables

• Microsoft.Win32.SafeHandles

• set_DesktopFiles

• get_GrabDesktopFiles

• set_BrowserProfiles

• browserProfiles

• set_AutoAddMissingTypes

• ListOfProcesses

• RecieveSettings

• ClientSettings

• DataReceivedEventArgs

• MessageReceivedEventArgs

• ErrorEventArgs

• get_BrowserCredendtials

• set_BrowserCredendtials

• GrandSteal.Client.Models.Credentials

• SendCredentials

• rdpCredentials

• set_FtpCredentials

• ExtractFtpCredentials

• ftpCredentials

• get_GrabBrowserCredentials

• GetCredentials

• GrandSteal.SharedModels.Models

• GrandSteal.Client.Models

• GrandSteal.SharedModels

• get_BrowserAutofills

• set_BrowserAutofills

• GrandSteal.Client.Models.Extensions.Nulls

• set_InstalledPrograms

• ListOfPrograms

• GrandSteal.Client.Models.Extensions

• get_DesktopFileExtensions

• set_DesktopFileExtensions

• JsonExtensions

• ProtoExtensions

• get_DesktopExtensions

• set_DesktopExtensions

• RequestsExtensions

• System.Text.RegularExpressions

• System.Collections

• set_RdpConnections

• StringSplitOptions

• get_DesktopFileManagers

• get_RdpManagers

• get_FtpManagers

• get_BrowserCredentialsManagers

• get_ColdWalletManagers

• GrandSteal.Client.Data.Helpers

• RuntimeHelpers

• FindDisordProcess

• GetCurrentProcess

• set_ColdWallets

• get_GrabColdWallets

• get_disabledHosts

• set_disabledHosts

• GrabLitecoinQt

• CommunicationObject

• ReadTableFromOffset

• get__globalSalt

• get__entrySalt

• GetValueOrDefault

• CredentialManagement

• get_DocumentElement

• get_SqlStatement

• set_SqlStatement

• AutoResetEvent

• set_Screenshot

• CredentialsRequest

• set_ProcessList

• set_CreateNoWindow

• ConvertHexStringToByteArray

• InitializeArray

• FindValueByKey

• System.Security.Cryptography

• GetEntryAssembly

• CreateTempCopy

• GrandSteal.Client.Data.Recovery

• set_WorkingDirectory

• profilesDirectory

• GetCurrentDirectory

• GeckoRootEntry

1. Original Packed Sample: C38E54342CDAE1D9181EC48E94DC5C83

2. Automatic Generated Report: PepperMalware Report

3. Virustotal First Submission: 2018-11-01 07:03:51

4. Unpacked Banker Module: 4634F4EF94D9A3A0E2FCF5078151ADB2

5. Related links: 

• https://unit42.paloaltonetworks.com/unit42-krbanker-targets-south-korea-through-adware-and-exploit-kits-2/

• https://threatpost.com/blackmoon-banking-trojan-using-new-infection-technique/125425/

• https://community.rsa.com/community/products/netwitness/blog/2017/05/19/the-blackmoon-trojan-framework

• https://www.fortinet.com/blog/threat-research/over-100-000-south-korean-users-affected-by-blackmoon-campaign.html

• https://www.fidelissecurity.com/threatgeek/threat-intelligence/blackmoon-banking-trojan-new-framework

Analysis

• 1. Loader

  • 2.1. Packer

  • 2.2. Process Injection

• 2. Main Module

  • 2.1. Persistence

  • 2.2. Encrypted Strings

• 3. Evolution

  • 3.1. Encrypted Strings Evolution

  • 3.2. BlackMoon Versions: Latest Version Under Development?

  • 3.3. BinDiff

    • 3.3.1. 2016-03-03 -> 2016-05-05 Statistics

    • 3.3.2. 2016-05-05 -> 2018-06-18 Statistics

    • 3.3.3. 2018-06-18 -> 2018-11-01 Statistics

    • 3.3.4. 2016-03-03 -> 2016-05-05 Differences

    • 3.3.5. 2016-05-05 -> 2018-06-18 Differences

    • 3.3.5. 2018-06-18 -> 2018-11-01 Differences

• 4. Conclusions

• 5. Yara Rules and Scripts

  • 5.1. BlackMoon Yara Rule

  • 5.2. Script to Extract BlackMoon Encrypted Strings

• 6. Other notes

  • 6.1. Another sample dated 2018 suspicious of being BlackMoon

1. Loader

1.1. Packer

Most of the analyzed samples's packers are wellknown packers such as PeCompact, Aspack, Fsg or Nspack:

Sample  FirstSeen   Packer   09beec989993806345254ca9adcdb034f8649d8a9633bbe8933a52f5093e8be1  2018-11-01  PeCompact   80ea86d195bbc4384a1b9a77a2d477e2c4e6dc6d48f3f80447877dbbe41a4e40  2018-06-18  Aspack 2de1e47c650c0a8865ecc7e7b68379ca071062c0873f46a4addb1aa13b8d48dc 2016-03-03  Fsg 5f17cf9aee107458995c434d21263528132b5d0ab8a20121d3de48478ec6c467 2016-02-28  PeCompact 47434c9c2e887ba6f47a31e757b4ac0c0e648dfee9f93e38bd49e1c17f660dcf 2016-03-05  PeCompact 2012486d87dcc3362745c6f8f178b9be5417c595e79c452a20729d2e60ec814b 2016-03-08  Aspack 05afd7bbf6efa14102f72bad0e3a0686af6522b25228ab760ef57e8d6df36ed1 2016-03-05  Fsg 5e1ca094e11b2dcfdd4c729e2eaf1bdfd0ec84067a39f1c3a233bfff1ff6dcb5 2016-03-20  PeCompact 406c50ed0333d2023de55ce798a4e7d5fa6e45df65c16733ef48961e94277807 2016-04-08  Aspack 4844e92d76b2158be2b5468b70e2d0898f9ba2287a02b2b0aa7af2a2113d4970 2016-03-02  PeCompact 7351373a50acbaa4bb3fa622b0573f473289d745ba717551c82abbe398c1c1ff 2016-03-10  Nspack 09a5dc4f9544f7bbc898d205f1e14518606e158f4a7c7126d7eb604ec9ec5c74 2016-04-09  PeCompact 224ead790d3bab7ede11252728d47e21f0d0274767aa3e6a16628e8970a0149f 2016-02-28  PeCompact 00eae37eaaee93b8155e6bad95564c3d95d71e7397653ffcbae4f95614ffa723 2016-05-05  PeCompact

1.2. Process Injection

Most of the analyzed samples follow the same strategy, they launch an executable (I think it is choosen randomly) from %system32% folder and they inject the new process (hollow process). The unpacked code will be executed in the context of the new process. Some of the executables that we have seen the malware launchs are: wmiprvse.exe, dwwin.exe, comp.exe, cacls.exe, etc...

Sample FirstSeen Hollowed Process  09beec989993806345254ca9adcdb034f8649d8a9633bbe8933a52f5093e8be1 2018-11-01system32\wmiprvse.exe  80ea86d195bbc4384a1b9a77a2d477e2c4e6dc6d48f3f80447877dbbe41a4e40 2018-06-18system32\wmiprvse.exe 2de1e47c650c0a8865ecc7e7b68379ca071062c0873f46a4addb1aa13b8d48dc2016-03-03system32\dwwin.exe 5f17cf9aee107458995c434d21263528132b5d0ab8a20121d3de48478ec6c4672016-02-28system32\comp.exe 47434c9c2e887ba6f47a31e757b4ac0c0e648dfee9f93e38bd49e1c17f660dcf2016-03-05system32\comp.exe 2012486d87dcc3362745c6f8f178b9be5417c595e79c452a20729d2e60ec814b2016-03-08system32\cacls.exe 05afd7bbf6efa14102f72bad0e3a0686af6522b25228ab760ef57e8d6df36ed12016-03-05system32\cacls.exe 5e1ca094e11b2dcfdd4c729e2eaf1bdfd0ec84067a39f1c3a233bfff1ff6dcb52016-03-20system32\cacls.exe 406c50ed0333d2023de55ce798a4e7d5fa6e45df65c16733ef48961e942778072016-04-08system32\cacls.exe 4844e92d76b2158be2b5468b70e2d0898f9ba2287a02b2b0aa7af2a2113d49702016-03-02system32\comp.exe 7351373a50acbaa4bb3fa622b0573f473289d745ba717551c82abbe398c1c1ff2016-03-10system32\cacls.exe 09a5dc4f9544f7bbc898d205f1e14518606e158f4a7c7126d7eb604ec9ec5c742016-04-09system32\cacls.exe 224ead790d3bab7ede11252728d47e21f0d0274767aa3e6a16628e8970a0149f2016-02-28system32\comp.exe

2. Main Module

2.1. Persistence

The malware installs itself under a HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run's subkey. For most of the older samples, the run subkey is a 8-length combination of lowercase and uppercase letters and numbers. However the analyzed samples that date 2018, install themself in the subkey with fixed name 000C29FC2AB3.

SampleFirst SeenRun Subkey 09beec989993806345254ca9adcdb034f8649d8a9633bbe8933a52f5093e8be12018-11-01000C29FC2AB3 80ea86d195bbc4384a1b9a77a2d477e2c4e6dc6d48f3f80447877dbbe41a4e402018-06-18000C29FC2AB3 2de1e47c650c0a8865ecc7e7b68379ca071062c0873f46a4addb1aa13b8d48dc2016-03-0306iSwa6C 5f17cf9aee107458995c434d21263528132b5d0ab8a20121d3de48478ec6c4672016-02-28kC6MOsu8 47434c9c2e887ba6f47a31e757b4ac0c0e648dfee9f93e38bd49e1c17f660dcf2016-03-05R3tP5nj1 2012486d87dcc3362745c6f8f178b9be5417c595e79c452a20729d2e60ec814b2016-03-0866qscw4Q 05afd7bbf6efa14102f72bad0e3a0686af6522b25228ab760ef57e8d6df36ed12016-03-05W60u80qO 5e1ca094e11b2dcfdd4c729e2eaf1bdfd0ec84067a39f1c3a233bfff1ff6dcb52016-03-20uki4Kk2o 406c50ed0333d2023de55ce798a4e7d5fa6e45df65c16733ef48961e942778072016-04-0835V5Bj9b 4844e92d76b2158be2b5468b70e2d0898f9ba2287a02b2b0aa7af2a2113d49702016-03-02AAAC2kY8 7351373a50acbaa4bb3fa622b0573f473289d745ba717551c82abbe398c1c1ff2016-03-101Lf9Tn7B 09a5dc4f9544f7bbc898d205f1e14518606e158f4a7c7126d7eb604ec9ec5c742016-04-095jNh7p11 224ead790d3bab7ede11252728d47e21f0d0274767aa3e6a16628e8970a0149f2016-02-28j3pVbRJ5 00eae37eaaee93b8155e6bad95564c3d95d71e7397653ffcbae4f95614ffa7232016-05-05000C29FC2AB3

Curiously, the sample 00eae37eaaee93b8155e6bad95564c3d95d71e7397653ffcbae4f95614ffa723 that dates 2016-05-05 (from the older samples, one of the newest), installs itself under the same subkey 000C29FC2AB3.

In addition, these samples that create the subkey with name 000C29FC2AB3, they create a mutex named M_Test too (the other samples don't create this mutex).

2.2. Encrypted Strings

Most of the important strings of BlackMoon are encrypted.

Here is a capture of the code responsible for decrypting the strings from the sample 09beec989993806345254ca9adcdb034f8649d8a9633bbe8933a52f5093e8be1:

To compose the definitive key that the malware uses to decrypt the strings, it carries an string that is the first part of the key, and then it appends 6 additional characters to that first part of the key. In the capture, the definitive key to be used would be "7ac13b3aa82136afa3090c5137B8a195".

Encrypted strings are like this:

The algorithm used to decrypt each string is rc4(unhexlify(rc4(unhexlify(encrypted_string), key)), key):

3. Evolution

3.1. Encrypted Strings Evolution

We have extracted the strings from samples from different dates, to compare them:

Date 2016-02-28:
Sample 5f17cf9aee107458995c434d21263528132b5d0ab8a20121d3de48478ec6c467:



Date 2016-03-03:
Sample 2de1e47c650c0a8865ecc7e7b68379ca071062c0873f46a4addb1aa13b8d48dc:

 

Date 2016-05-05:
Sample 00eae37eaaee93b8155e6bad95564c3d95d71e7397653ffcbae4f95614ffa723:




Date 2018-06-18:

Sample 80ea86d195bbc4384a1b9a77a2d477e2c4e6dc6d48f3f80447877dbbe41a:

Date 2018-11-01:
Sample 09beec989993806345254ca9adcdb034f8649d8a9633bbe8933a52f5093e:

In the section 2.1 (about persistence), we had already noticed that most of the samples from 2016 create a 8 bytes length subkey under the registry \Run key, with a combination of lowercase and uppercase letters and numbers. 

However a sample dated 2016-05-05 and the newer samples dated 2018 create a subkey under \Run with name 000C29FC2AB3. In addition these samples create a mutex with name M_Test (this mutex is not created by the 2016's samples).

If we take a look at the lists of strings, the sample dated 2016-05-05 and the samples dated 2018, all of them have similar lists of encrypted strings, where strings are ordered in similar order (thought they are not totally identicals).

The other samples dated 2016 contain another lists of strings, identical between them, but different from the lists of the samples dated 2018.

3.2. BlackMoon Versions: Latest Version Under Development?

Having in mind the IoCs collected in the previous sections, we can conclude that there is a first version of BlackMoon malware, whose samples are dated around 2016, and other version that could be under development, whose samples we have one of them dated 2016-05-05, and other two dated 2018-06 and 2018-11.

Version 1:

• Persistence: 8 bytes length subkey under registry \Run key, with a combination of lowercase and uppercase letters and numbers

• Encrypted strings: "http://", "/ca.php", "?m=", "&h;=", "GET", "?p", "POST", "users.qzone.qq.com", "GET /fcg-bin/cgi_get_portrait.fcg?uins=", etc...

• Samples dated 2016

Version 2 - probably under development version:

• Persistence: subkey under \Run with name 000C29FC2AB3

• Mutex: M_Test

• Encrypted strings: "ScriptControl", "Language", "VBScript", "ExecuteStatement", "Function MACAddress()", "Dim mc,mo", "Set mc=GetObject(\"Winmgmts:\").InstancesOf(\"Win32_NetworkAdapterConfiguration\"), "For Each mo In mc", etc...

• A sample dated 2016-05-05, other 2 samples dated 2018

We have only 3 samples that we have classified as version 2. Probably they are quite similar, but we must have in mind that the lists of encrypted strings for these samples are not totally identical. However, the Run key 000C29FC2AB3 and the mutex M_Test, make us to think these 3 samples are the same version.

From my point of view, these 3 newer samples could be a version that is under development. Because of that, each version 2's sample is a bit different from the others. And because of that, the name M_Test for the mutex and the non-random name for the \Run subkey.

3.3. BinDiff

Lets compare with BinDiff the following samples (once they are already unpacked) trying to understand the evolution of this malware:

Version1:

• 2de1e47c650c0a8865ecc7e7b68379ca071062c0873f46a4addb1aa13b8d48dc

• 2016-03-03

• Original sample packed with Fsg

Version2:

• 00eae37eaaee93b8155e6bad95564c3d95d71e7397653ffcbae4f95614ffa723

• 2016-05-05

• Original sample packed with PeCompact

Version2:

• 80ea86d195bbc4384a1b9a77a2d477e2c4e6dc6d48f3f80447877dbbe41a

• 2018-06-18

• Original sample packed with AsPack

Version2:

• 09beec989993806345254ca9adcdb034f8649d8a9633bbe8933a52f5093e

• 2018-11-01

• Original sample packed with PeCompact

3.3.1. 2016-03-03 -> 2016-05-05 Statistics: 345 matching functions

3.3.2. 2016-05-05 -> 2018-06-18 Statistics: 591 matching functions

3.3.3. 2018-06-18 -> 2018-11-01 Statistics: 1743 matching functions

I think the most interesting indicator about similarity, at least in this case, is the number of matching functions because the unpacked modules were dumped with Volatility's procdump command, with --memory --unsafe modificators. Probably most of the primary and secondary unmatched functions are due to residual parts of the code of the packer in memory and maybe due to recompilations of the code with newer versions of the runtime.

If we compare the paired functions, we find that most of the changes between versions are due to ligth modifications, small fixes, etc... as we will see in the following sections.

3.3.4. 2016-03-03 -> 2016-05-05 Differences:

For example, here is a function from the sample dated 2016-03-03 compared to the same function from the sample dated 2016-05-05, where we can see that small changes were done in this function: 

Another function. In this case a larger part of code was removed from the function in the newer version:

Btw, in the case of 2016-03-03 -> 2016-05-05, most of the matching functions are ubicated in totally different addresses:

Probably, in spite of the fact that the code doesn't change a lot and there are a lot of matching functions, a code refactorization was done from version 1 to the first samples of version 2 (around 2016-05).

3.3.5. 2016-05-05 -> 2018-06-18 Differences:

In this case, in addition to the similarity between functions pairs, lot of the matching functions are ubicated in the same offset into the unpacked sample:

This makes us to think both binaries are quite similiar, in spite of the fact that we find minimal changes like in this function:

However, there are other functions with more important changes that make us to think that there have been at least a minimal development between both samples (manual modifications on the code: improvements or fixes, not only recompilation + repacking):

3.3.5. 2018-06-18 -> 2018-11-01 Differences:

Again, lot of the matching functions ubicated in the same offset, and minimal changes between paired functions. And again, some parts of the code with more important changes that suggest a minimal development by the authors between the first and the second sample:

4. Conclusions

From my point of view, there are two main versions of BlackMoon family.

Samples from the first version date first half-year of 2016.

Around May-2016, a new version was started. In the sample that dates 2016-05-05 we can appreciate a code refactorization and more important changes in the code. In addition, we can find changes in the behavior, such as the non-random subkey under the \Run registry key, named 000C29FC2AB3, and the non-random mutex created by the malware with name M_Test.

There are minimal changes between the sample that dates 2018-06-18 and the samples that dates 2016-05-05, and again minimal changes between the samples that dates 2016-11-01 and the sample that dates 2018-06-18. However, there are enough changes between these version 2's samples to appreciate that a development was done by the authors, there must be modifications of the source code between them (not only recompilation + repacking).

My conclussion is, there is a version of the BlackMoon that is under development. We can find quite recent samples (based on the VirusTotal first seen date) of this version under development. I can't say totally sure if the code of that recent samples were modified and compiled in 2018 or previously (in spite of the fact that I think the code was recently modified and it is currently evolving, maybe that samples were only repacked or their bytes lightly modified, or maybe VirusTotal didn't see these samples before).

In addition to the larger changes from the first version to the second version, we can appreciate an evolution of the code of the second version: from the sample 00eae37eaaee93b8155e6bad95564c3d95d71e7397653ffcbae4f95614ffa723 (May-2016), to the sample 80ea86d195bbc4384a1b9a77a2d477e2c4e6dc6d48f3f80447877dbbe41a (June-2018), and to the sample 09beec989993806345254ca9adcdb034f8649d8a9633bbe8933a52f5093e (November-2018). So, from my point of view, it seems there are enough evidences to think that there is a BlackMoon version that is under development and currently evolving.

5. Yara Rules and Scripts

5.1. BlackMoon Yara Rule

Unpacked module:

       
rule blackmoon_unpacked {
strings:
        $code1 = { 89 45 ?? 68 01 01 00 80 6A 00 68 ?? 00 00 00 68 01 00 00 00 BB ?? ?? 00 00 E8 ?? ?? ?? ?? 83 C4 10 }
        $code2 = { FF 75 ?? FF 75 ?? FF 75 ?? FF 75 ?? FF 75 ?? FF 75 ?? FF 75 ?? B9 ?? ?? 00 00 E8 }
condition:
        (all of them)
}

5.2. Script to Extract BlackMoon Encrypted Strings

The following script extracts and decrypts the encrypted strings from a BlackMoon unpacked sample:

python strings_decryptor.py <path to unpacked blackmoon>

       

import os
import sys
import binascii
import traceback

#################################################

def rc4(data, key):
    x = 0
    box = range(256)
    for i in range(256):
        x = (x + box[i] + ord(key[i % len(key)])) % 256
        box[i], box[x] = box[x], box[i]
    x = 0
    y = 0
    out = []
    for char in data:
        x = (x + 1) % 256
        y = (y + box[x]) % 256
        box[x], box[y] = box[y], box[x]
        out.append(chr(ord(char) ^ box[(box[x] + box[y]) % 256]))
    return ''.join(out)

#################################################

def findencstrings(s):
    l = []
    laststr = ""
    for i in range(0, len(s)):
        if s[i] in "0123456789ABCDEF":
            laststr += s[i]
        else:
            if ord(s[i])==0 and len(laststr)>=6: l.append(laststr)
            laststr = ""
    return l

#################################################

def decstr(s, k, k2):
    sorig=s
    try:
        if len(s)%2: s = s[0:-1]
        s = binascii.unhexlify(s)
        s = rc4(s, k+k2)
        step1 = s
        if len(s)%2: s = s[0:-1]
        s = binascii.unhexlify(s)
        s = rc4(s, k+k2)
        return True, s
    except Exception as e:
        return False, "ERROR:" + repr(e) + ", string:" + sorig

#################################################

def findkey1(s):
    l = []
    laststr = ""
    for i in range(0, len(s)):
        if s[i] in "0123456789abcdefABCDEF":
            laststr += s[i]
        else:
            if ord(s[i])==0 and len(laststr)>=20 and len(laststr)<=30 and not len(laststr)%2 and laststr not in l: l.append(laststr)
            laststr = ""
    if len(l): return l
    return None

#################################################

def findkey2(s):
    key=""
    for i in range(0x0, len(s)-0x100):
        if s[i:i+8]=="\x68\x01\x01\x00\x80\x6a\x00\x68" and s[i+8] in "0123456789abcdefABCDEF" and s[i+9:i+12]=="\x00\x00\x00":
            key+=s[i+8]
    return key

#################################################

def get_strings_from_pe(s):
    ldecs = []
    lenc = findencstrings(s)
    lk1 = findkey1(s)
    k2 = findkey2(s)
    if lk1 and k2 and lenc:
        for k1 in lk1:
            for i in range(0,len(k2)-6):
                for senc in lenc:
                    decs = decstr(senc, k1, k2[i:i+6])
                    if decs[0]: ldecs.append(decs[1])
    return ldecs

#################################################

def analexe(s):
    decrypted_string_list = []
    try: decrypted_string_list = get_strings_from_pe(s)
    except Exception as e:
        print "blackmoon exception in get_strings_from_pe"
        print traceback.format_exc()
    for e in decrypted_string_list: 
        print "blackmoon decrypted string:", e

#################################################

if __name__ == "__main__":
    if os.path.exists(sys.argv[1]):
        f = open(sys.argv[1], "rb")
        s = f.read()
        f.close()
        analexe(s)
    else:
        print "Incorrect path"

6. Other Notes

6.1. Another sample dated 2018 suspicious of being BlackMoon

Once I started to investigate a bit more and to search information about BlackMoon family, I found a tweet talking about another sample that could be BlackMoon and whose first submission is 2018-08-08. 

I toke a quick look at this sample, here you can find the unpacked module. Some interesting strings from this unpacked module:

• http://aa.mrmr11[.]cn:8000/fdeee.dll

• yPBfy0A4q1Y3gvgmREe0r1UR0fZVidMd4V8CB3oKTzNaOYCyPaSVz48Sw5mVifR3sVxYgeM7EyVu6DwnrfAG/AxGgDr+9GIP3cQ59d/eLtPqTBMb7bzrty65ymU5lH4omQOCFGqOfHggHlhjv97kF1eKnstRomin+KSVtT1TWWtI4BqcY6tP7xJBMzDUgouwpGUwzDY4wnnDEU+8B+MtEncFn1EOAXA3ZMW3/3mVwLFpKP9XH6xJSjjJqbXr4y1VqqwH/lZOYnPVcYlpfbmwdOYvbsIwCxLaU1HvWmBiDNxKRTLhhXAn3GuBy5OzbI01IVVnQtG2WrbM2T5Rk6m1+eMW2c90Uouf7pTesS6m8oCNEclwGQNZtpEIZojzjwPSrPUQPxz/sKtHrhMEdl90wI+GyO7mwvrONsO6h+OvYas6f2QgxxiaIYlK/IJIVFM=

• C:\Program Files\AppPatch\lpDllName

• 360zipUpdate.EXE

The original sample was packed with Aspack, as other recent BlackMoon samples. However this first unpacked module doesn't look like BlackMoon: the code, the strings, etc... are totally different.

Anyway, when I have analyzed this sample, the dll that it tries to download (http://aa.mrmr11[.]cn:8000/fdeee.dll) had been already removed. Maybe that dll was the BlackMoon module. I can't be sure if this sample is BlackMoon or not (this other any.run analysis contains this same IoC: "C:\Program Files\AppPatch\lpDllName", it downloads a dll too, and the second process name is similar format. Maybe same family. This other one was tagged as #trojan #dupzom).

Starting with Ghidra Framework

About Ghidra, when you start the framework, you should create a project and a workspace:

Then, we can import files, for example PE files:

Ghidra CodeBrowser

Once PE file is imported, CodeBrowser can be launched:

Initially, PE headers are parsed but code is not analyzed, the framework asks you if analyzers should be launched, and what analyzers should be launched. This is the list of analyzers (they are marked the analyzers that are marked by default):

Once analyzers finish, CodeBrowser interface is like this:

Code is fully decompiled and while you browse each function, the decompiled code is showed in the right window.

Browsing Code

Browsing code is similar to IDA, you can double-click a name to jump there (for example double-clicking the destination of a call <destination>, would take you to the destination function). You can move easily to the previous location with Alt+left (equivalent to Esc in IDA) and next location with Alt+right (equivalent to Ctrl+Enter in IDA).

Other navigation options:

You can search for text, like IDA Alt+t, however (and I found this an interesting characteristic), you can select where do you want the text is going to be searched:

Find TrickBot Config Xor-layer Decryptor

For example, we can try to search for XOR instructions, and we get a list of matches:

In the analyzed sample (a trickbot from early 2019), if we look for XOR instructions, we can find easily some XOR  instructions modifying memory, and one of them belongs to the function that decrypts the XOR layer of the trickbot config:

(Btw, as we can see in the image, when you select with the mouse a line in the disassembly window, the equivalent line is highlighted in the decompiled window).

Using references to find more interesting parts of the code

Once you have located an interesting point in the code, you can show a tree of calls to that point:

The tree makes easy to follow the incoming or outgoing references to the interesting function:

Additionally, you could highlight (select) back or forward refs to an address in the disassembly and decompiled windows.

TrickBot ECS signature and Config Xor Decryptor

By using the call trees, we can find easily the functions that decrypts the XOR layer of the elliptic curve signature or the XOR layer of the TrickBot Config:

In addition, you can open a function graph window, similar to IDA graphs. Here is the XOR decryptor loop of TrickBot:

You can move easily on the graph, and zoom in/out with the mouse wheel:

TrickBot Strings Decryptor

About strings.. All the strings used by the newer versions of TrickBot are encrypted. While IDA was able to construct a nice table of strings that makes easy to find the decryptor:

Ghidra were not able to identify all the strings and construct a nice table, it is much lesser intuitive:

Maybe I missed something with Ghidra, but I selected the option Analysis->One shot->Ascii Strings, and these are the results. This makes difficult, for example, to find strings' decryptors.

Conclussion

in spite of the fact that I really love IDA (and WinDbg), I liked this framework, and I will continue using it.

• Original Packed Sample: 3F77B24C569600E73F9C112B9E7BE43F

• Automatic Generated Report: PepperMalware Report

• Virustotal First Submission: 2018-08-28 14:36:26

• Sample Creation Date:  2018-08-27

• Unpacked Banker Module: 896609A8EE8CC860C2214FCD1E3CF264

• Internal executable id: aug27

• Related links: 

  • https://www.malware-traffic-analysis.net/2018/08/21/index2.html

  • https://twitter.com/malware_traffic/status/1032066941953945600

  • https://blog.malwarebytes.com/threat-analysis/2017/02/new-neutrino-bot-comes-in-a-protective-loader/

  • https://securelist.com/jimmy-nukebot-from-neutrino-with-love/81667/

Analysis

• 1. Loader

  • 1.1. First stage packer

  • 1.2. Second stage, custom packer / injector

  • 1.2.1. Antidebug Tricks

  • 1.2.1.1. Antidebug tricks: API Obfuscation

  • 1.2.1.2. Antidebug tricks: Time Tricks

  • 1.2.1.3. Antidebug tricks: HKCU\Software\Microsoft\Windows\Identifier

  • 1.2.1.3. Antidebug tricks: CPUID checks

  • 1.2.1.4. Antidebug tricks: Walk running processes searching for wellknown names

  • 1.2.1.5. Antidebug tricks: Walk own process' modules searching for wellknown names

  • 1.2.1.6. Antidebug tricks: IsDebuggerPresent / CheckRemoteDebuggerPresent

  • 1.2.2. Injection

  • 1.2.3. Other details

  • 1.2.3.1. BotId and mutex

  • 1.2.3.2. PRNG

• 2. Banker module

  • 2.1. WebInjects

  • 2.2. Browser hooks

  • 2.3. Other stealer capabilities

• 3. Similarities with NukeBot leaked source code

  • 3.1. InjectDll function at banker module

  • 3.2. Hollow-process explorer.exe

  • 3.3. Random BotId

• 4. Yara rules

• 5. Conclussions

1. Loader

1.1. First stage packer

In the first stage, the sample is packed with an usual packer that allocates a memory block where it copies a shellcode that decrypts a second stage code, and that second stage code is overwritten over the original PE in memory.

1.2. Second stage, custom packer / injector

This second stage is an executable that is unpacked over the original executable in memory. This second stage perfoms some antidebug tricks such as VM detection and API calls obfuscation. In addition, it decrypts the third stage PE: the main banking code, and it injects this third stage PE to explorer.exe process.

1.2.1. Antidebug Tricks

The analyzed sample performs a somo usual antidebug tricks. From analyzed sample (IDA decompiled):

1.2.1.1. Antidebug tricks: API Obfuscation

In the Neutrino Bot loader, each time a API is going to be called, it is got from a hash.

It seems to be using a custom hash algorithm, not crc32 or similar well-known algorithm (frequently used by other malware families).

1.2.1.2. Antidebug tricks: Time Tricks

The analyzed sample plays with GetTickCount and waits (Sleep and WaitForSingleObject), performing usual tricks to detect that it is running into a VM. From analyzed sample (IDA decompiled):

1.2.1.3. Antidebug tricks: HKCU\Software\Microsoft\Windows\Identifier

The analyzed sample checks the key: HKCU\Software\Microsoft\Windows value: Identifier, it hashs the content of that value with Fowler–Noll–Vo hash algorithm and it compares the hash with 0xC9C8F009. I don't know exactly what content would match this hash, but probably it matchs an specified content for some wellknown VMs (virtualbox, vmware, ...). From analyzed sample (IDA decompiled):

1.2.1.3. Antidebug tricks: CPUID checks

The analyzed sample executes cpuid instruction to get cpu information, then it calculates a fowler-noll-vo hash with the information returned by cpuid, and compares that hash with a set of values: 0x3A72221D, 0xB609E57D, 0x11482F93, 0xA7C9423F, 0x7816EDDD, 0x6361F34. I don't know exactly the original data causing these hashes, but probably they are values returned by cpuid related to wellknown VMs such as vmware, virtualbox, etc... From analyzed sample (IDA decompiled):

1.2.1.4. Antidebug tricks: Walk running processes searching for wellknown process's names

The analyzed sample calls toolhelp32's functions to walk running processes. Again, it calculates the fowler-noll-vo hash foreach process name and compares against a set of precalculated hashes: 0x4FAEA2EB, 0x689ED848, 0x57337435, 0xE8BC3AB9, 0x3C30BBA6, 0xA421254D, 0x26638D6A, 0xE3449C1. These hashes probably correspond to names such as vmtoolsd.exe and other well known processes associated to VMs and security products.From analyzed sample (IDA decompiled):

1.2.1.5. Antidebug tricks: Walk own process' modules searching for wellknown module' names

In addition, it walks the modules of the current process searching for wellknown libraries such as SbieDll.dll, etc... It compares the fowler-noll-vo hash of each module's name with the following set of hashes:  0xCC23DB0E, 0xCCFE57BB, 0x9FECD578, 0xE69D9465, 0xC55CC270, 0x601CDCE9, 0x9DF7C709, 0x23E9F2F5, 0x70E2598E, 0x2C82D8A, 0x99CC8618, 0xB62000C5. From analyzed sample (IDA decompiled):

1.2.1.6. Antidebug tricks: IsDebuggerPresent / CheckRemoteDebuggerPresent

Not necesary explanation, usual antidebug checks:

1.2.1.7. Antidebug tricks: Query device' names

The analyzed sample calls QueryDosDeviceW to get a list of devices, and calculates the fowler-noll-vo hash foreach name, and then compares each name with a set of values:   0x5C86B533, 0x7F65B61C, 0x464768AD, 0x9A781952. It tries to detect VM's common devices, such as vmci or HGFS. From analyzed sample (IDA decompiled):

1.2.2. Injection

The analyzed sample decrypts the third stage PE (the banking module) by using the RC4 algorithm + decompression. It creates an explorer.exe instance, and it will inject the decrypted PE into the address space of that explorer.exe instance (hollow process). From analyzed sample (IDA decompiled):

1.2.3. Other details

1.2.3.1. BotId and mutex

The analyzed sample contains a kind of executable id, and the name of the mutex is created based on that executable id. In the case of the analyzed sample this exe id is "aug27", probably the date that it was generated (the virustotal first analysis date is 2018/08/28). From analyzed sample (IDA decompiled):

A fowler-noll-vo hash is calculated from the string "aug27". Later, it uses the calculated hash to initialize a PRNG (based on idum=1664525*idum+1013904223) to generate a random guid, that will be the name of the created mutex. From analyzed sample (IDA decompiled):

1.2.3.2. PRNG

From analyzed sample (IDA decompiled):

2. Banker module

The third stage is the banker module. You can find the unpacked banker module's dll that I unpacked here. It is quite similar to this other dll that was extracted by @james_in_the_box (you can read about at twitter, here) from a sample shared by @malware_traffic, here.

This is a list of strings of the Neutrino Bot unpacked banker module.

2.1. WebInjects

The banker module performs webinjects. The following parts of code manage the downloaded injects (IDA decompiled):

2.2. Browser hooks

It performs hooks at frequently targetted nss3 and wininet APIs at browsers.

Nss3 hooks (IDA decompiled):

Wininet hooks (IDA decompiled):

2.3. Other stealer capabilities

Other strings found into the banker module reveal additional stealer capabilities:

3. Similarities with NukeBot leaked source

Comparing some parts of the NukeBot code that was leaked on spring 2017 with the disassembled/decompiled code of the analyzed sample, we can check that there are similarities between them. Probably Neutrino Bot is an evolution or, at least, it reused code from NukeBot leaked code.

In this section, I comment about some parts of code where I found similarities, but probably, there are other parts of code that are very similar too.

3.1. InjectDll function at banker module

InjectDll is a function that appears in NukeBot leaked code and Neutrino Banker module.You can find the full code of both functions here:

• InjectDll source code from NukeBot leaked source:  https://pastebin.com/LL9PnVb6

• InjectDll decompiled code from Neutrino Bot analyzed sample: https://pastebin.com/K4cfUq4C

Comparing both codes, we can check both functions are almost identical between NukeBot leaked source code and Neutrino analyzed sample. Probably this part of code was reused.

3.2. Hollow-process explorer.exe

The following parts of code from the neutrino and nukebot loader get the path of explorer.exe, create an instance of the process, and inject it (hollow process).

From NukeBot leaked source code:

From Neutrino analyzed sample's loader (IDA decompiled):

The code used to inject processes is quite similar between the leaked source code and the analyzed version:

From Nukebot leaked source code:

From Neutrino analyzed sample's loader (IDA decompiled):

3.3. Random BotId

Both, leaked NukeBot and Neutrino, generate a random GUID that is used as botid and to create a mutex that the malware uses to know it is already running.

From NukeBot leaked code:

Random GUID is used to create the mutex:

From Neutrino analyzed sample (IDA decompiled):

Random GUID is used to create the mutex:

4. Yara rules

Banker module:

       

rule jimmy_08_2018 {
strings:
        $string1 = "reg add HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /ve /t REG_SZ /d \"%ls\" /f" wide
        $string2 = "Rundll32.exe SHELL32.DLL,ShellExec_RunDLL \"cmd.exe\" \"/c %ls\"" wide
        $string3 = "Rundll32.exe SHELL32.DLL,ShellExec_RunDLL \"%ls\"" wide
        $string4 = "Rundll32.exe url.dll,FileProtocolHandler \"%ls\"" wide
        $string5 = "Rundll32.exe zipfldr.dll,RouteTheCall \"%ls\"" wide
        $string6 = "/a /c %s" wide
        $string7 = "%ls_%ls_DLL" wide
        $string8 = "Cookie: %s=%s;uid=%ls"
        $string9 = "%ls\\nss3.dll" wide
        $injects1 = "injects"
        $injects2 = "set_host"
        $injects3 = "set_path"
        $injects4 = "inject_setting"
        $injects5 = "data_keyword"
        $injects6 = "inject_before_keyword"
        $injects7 = "inject_after_keyword"
condition:
        (all of them)
}
       
 

Packer stage 2:

       

rule neutrino_packer_stage2_08_2018 {
strings:
  $code1 = { 6A 25 [0-15] 6A 6C [0-15] 6A 73 [0-15] 6A 5C [0-15] 6A 2A [0-15] 6A 25 [0-15] 6A 6C [0-15] 6A 73 [0-15] 6A 5C [0-15] 6A 25 [0-15] 6A 6C [0-15] 6A 73 }
  $code2 = { 6A 65 [0-15] 6A 78 [0-15] 6A 70 [0-15] 6A 6C [0-15] 6A 6F [0-15] 6A 72 [0-15] 6A 72 [0-15] 6A 2E [0-15] 6A 78 }
  $code3 = { 6A 6B [0-15] 6A 65 [0-15] 6A 72 [0-15] 6A 6E [0-15] 6A 65 [0-15] 6A 6C [0-15] 6A 33 [0-15] 6A 32 [0-15] 6A 2E [0-15] 6A 64 [0-15] 6A 6C }
  $code4 = { 6A 25 [0-15] 6A 6C [0-15] 6A 73 [0-15] 6A 5C [0-15] 6A 25 [0-15] 6A 6C [0-15] 6A 73 }
condition:
  all of them
}
       
 

5. Conclussions

We have analyzed a Neutrino Bot sample dated 2018/08/27. After analyzing the sample (3F77B24C569600E73F9C112B9E7BE43F), we have checked it could be an evolution (or at least, could be using parts) of the leaked NukeBot source code's loader. Nukebot / JimmyNukebot / NeutrinoBot / ... Probably, this set of families share code between them and are in continuous development.