by Robin Dost
Today, we are taking a look at malware linked to yet another threat actor, one that has been active since at least February 2026.
Since I could not associate the malware with any previously attributed threat actor, I am naming the actor GhostShell (you’ll find out why later in this article) and assigning it the Malwarebox identifier MB-0009.
The corresponding file has the following SHA-256 hash:
28f58061348a1c54fa6e7ff6618630259618d4afdf78514d5fccfc993797cdff
And was (in my opinion) wrongfully attributed to UAC-0226.
It is an archive named:
Besomar_documentation.rar
The archive exploits CVE-2025-8088 / CVE-2025-6218, a vulnerability we already covered in the context of Gamaredon.
First, let’s extract the archive.
We can already see a familiar pattern here.
Extracting the archive causes a VBS file to be copied into the Windows Startup folder. The actor uses several relative paths to make damn sure they hit the Startup folder, regardless of the archives current working directory.
We also find a whole collection of decoy PDFs. The files themselves are harmless, but they provide us with useful information, for example, about the actors potential targets.
Let’s take a closer look at some of them.
The decoy set suggests that GhostShell is targeting more than individual UAV operators.
The documents are tailored to Ukraines broader drone ecosystem, including military units, technical personnel, procurement staff, volunteer organizations and defense-sector partners.
This indicates an interest in operational access, supply-chain intelligence and the networks supporting Ukrainian UAV deployments.
Anyone who tracks UACs might immediately think of UAC-0244/UAC-0247.
That was the case for me as well, but neither the tradecraft nor the infrastructure patterns match the profile, which is why I assume this is a separate cluster with no connection to the others.
The threat actor is using these files to impersonate Besomar.
Besomar is a Ukrainian company specializing in the development of high-precision fixed-wing drones designed for defense and security applications.
All of the PDFs have the same file size and the same creation date.
| Original Filename | Translated Name | Creation Date |
| БпЛА Besomar 3210.pdf | Besomar 3210 UAV.pdf | 2026:06:06 16:39:42+02:00 |
| Зарядна станція.pdf | Charging Station.pdf | 2026:06:06 16:39:42+02:00 |
| Катапульта.pdf | Catapult.pdf | 2026:06:06 16:39:42+02:00 |
| Комплектація БпЛА Besomar.pdf | Besomar UAV Configuration.pdf | 2026:06:06 16:39:42+02:00 |
| Модифікація Besomar 3210-N.pdf | Besomar 3210-N Modification.pdf | 2026:06:06 16:39:42+02:00 |
| Переваги співпраці.pdf | Benefits of Collaboration.pdf | 2026:06:06 16:39:42+02:00 |
| Про компанію.pdf | About the Company.pdf | 2026:06:06 16:39:42+02:00 |
Looking at the VBS Files
Now let’s take a look at the VBS files.
First, I want to know whether there are any differences between them.
Same hash means same file, so we only need to analyze one of them.
What we have here is essentially just a Base64-encoded string. It is decoded and then executed using ExecuteGlobal.
The script subsequently downloads two files from cloudaxis[.]cc:
| https://cloudaxis[.]cc/gsmft/yueu/fkvqld/tvqqwh/ushu/122.exe |
| https://cloudaxis.cc/gsmft/yueu/fkvqld/tvqqwh/ushu/update.exe |
Let’s have a look at the domain:
The domain is already a few months old and was registered in February. This also matches earlier findings related to this threat actor, but more on that later.
Opening the discovered URLs in a browser returns the following message:
Opening the domain without the URL path, however, shows this:
A decoy hosting website.
Do not let 404 messages like above fool you.
They are often little more than deception attempts by the actor.
So I throw the malware into Kraken, let it run through a sandbox via MANTIS and check whether it can retrieve another payload.
Et voilà, we have a new payload:
And that is not all.
KRAKEN also discovered a second file that can be distributed through the same infrastructure: 22.exe
| 122.exe | ab5681266f70af7df24383f15de876e411fc18e35cb6f24603b12f580b05ccb3 |
| 22.exe | 8de34006dafd990853a45cbe9aaab4ee18c8cd4c1ad0a98fe71f8d63cd60db25 |
| update.exe | b1834634820ae696f0514ca2b6723061f115857232306e573f4d115bc6ead012 |
For now, however, we will focus on 122.exe
Reverse Engineering 122.exe
I usually run malware in a sandbox before starting the deeper reverse-engineering work. It makes the RE process significantly easier.
Let’s look at the important part of the network traffic.
This is a Hybrid Analysis result and it tells us the following:
- A new domain,
cdnexpress[.]ccis contacted - Data is sent to an
/analyticsendpoint - The sandbox receives a
Bad Requestresponse
Let’s briefly look at the domain.
It uses a different registrar from the previous domain.
So at least the threat actor did not make the mistake of registering everything through the same provider.
Opening the malware URL returns the following:
Based on the server response, we can assume that the malware contains a client certificate that is required for communication with the backend.
I am not going to provide a complete reverse-engineering write-up of the malware here, but I will summarize the most important parts.
Triage and detect Overlay
File: 122.exe
Type: PE32+ executable for MS Windows 6.00 (GUI), x86-64, 6 sections
SHA256: ab5681266f70af7df24383f15de876e411fc18e35cb6f24603b12f580b05ccb3
The file contains an approximately 190 KB overlay, beginning at file offset 0x19C64.
Next, we need to identify the overlay structure and derive the XOR key.
I used Python here because it was simply faster.
The eight-byte blocks repeat heavily. With a fixed XOR operation, the most common block corresponds to the key:
-> d0cd4cb8d4673e28
We can now decrypt the overlay and carve the embedded PE:
An entropy map reveals an encrypted blob inside .rdata.
One important detail: the apparently identical 0x00–0xFF table also looks highly entropic, but it is merely a lookup table. The actual ciphertext is the blob at .rdata offset corresponding to virtual address:
0x140020880
Recovering the Decryption Routine
Next, we retrieve the decryption routine from the disassembly.
The referencing function contains both an AVX2 implementation and a scalar fallback.
The scalar loop gives us the plaintext algorithm.
movzx eax, cl ; i & 0xFF
imul edx, eax, 0x7 ; i*7
sub dl, 0x58 ; key = (i*7 - 0x58) & 0xFF
xor dl, [r8+r13*1] ; ^ cipher[i] (r13 = base 0x140020880)
mov [rbx+r8*1], dl ; plain[i]
cmp ecx, 0x366 ; len = 870We can now decrypt the configuration.
The result is a DER sequence containing a PKCS#12 structure.
Next, we inspect the structure using OpenSSL.
The certificate and private key can then be extracted.
The password is empty and the MAC check can be skipped.
What an mTLS Client Certificate Reveals About an Implant PKI
During triage, the sample gave us three related artifacts:
- A client certificate
- The corresponding private key
- A PKCS#12 container in PFX format
The filename client is already our first useful data point.
This is not the server leaf certificate. It is the client side of a mutual-TLS relationship.
It is the material the implant uses to authenticate itself to the command-and-control server.
With mTLS, the server rejects any connection that does not present a valid client certificate.
The PKI therefore acts as an access-control mechanism.
Certificate Fields
Subject : CN=ed6e62814295701f
Issuer : CN=GhostShell Implant CA
Serial : 11145A2322AA5595D27E25CC977AD1B53CE88DCD (160 Bit, random)
Valid : 2026-06-18 05:27:43 UTC -> 2027-06-19 05:27:43 UTC
Algo : ECDSA, prime256v1 (P-256), Signatur ecdsa-with-SHA256
ExtKeyU : clientAuth (1.3.6.1.5.5.7.3.2)
BasicC : CA:FALSE
SAN : keineThree observations carry intelligence value.
The Common Name Appears to Be a Per-Implant Identifier
The common name is:
ed6e62814295701fThat is 16 hexadecimal characters, representing eight bytes or 64 bits.
This suggests that every deployed implant may receive its own client certificate with an individual identifier.
If that theory is correct, the CN becomes a potential tracking anchor across the campaign.
At this stage, however, that remains a theory.
The Issuer Names the Implant Framework
The issuer identifies itself as:
GhostShell Implant CAThis is a private certificate authority whose distinguished name was explicitly configured by the operator.
The string is highly likely to be hardcoded into the C2 builder or certificate-generation component, making it one of the most valuable pivots in the entire artifact set.
Possible Toolchain Indicators – with the Necessary Caveats
The combination of:
- P-256
- A random 160-bit serial number
- A minimal critical-extension template
is consistent with Gos crypto/x509 implementation.
P-256 is commonly used there and Go generates certificate serials in a similar form.
This is, however, a weak signal and should not be treated as definitive toolchain attribution.
Naturally, I would now like to access the web server using the extracted client certificate and show you what is behind it.
Unfortunately, doing that and almost everything else interesting I would like to demonstrate, is not legal in Germany.
Since German lawmakers appear to have absolutely no interest in modernizing the relevant legislation and would apparently rather spend their time debating the correct wording of vegan sausage, i’d have to find a legal way for stuff like that and search for a cached/saved file on my sandbox system.
I was lucky, the file was still there on the sandbox file system 🙂
Do you notice anything?
It is the same decoy website, just with a different name and a few minor changes.
What Does 122.exe Do?
122.exe is a loader.
It XOR-decrypts the CRPT overlay and executes the embedded Stage-2 PE in memory. Imports such as VirtualAlloc, VirtualProtect, LoadLibrary and GetProcAddress support this behavior.
Stage 2 is the actual implant.
Stage-2 Capabilities
The implant communicates with cdnexpress[.]cc over HTTPS using WinHTTP.
It authenticates using the embedded elliptic-curve mTLS client certificate associated with ghostshell-client.
At the same time, it ignores validation errors for the server certificate through WinHttpSetOption using flags 0x3300.
The implant sends a host-fingerprinting beacon based on the following template:
implant=v%u.%u.%u&host=%s&user=%s&pid=%lu&tid=%luThis includes:
- Implant version
- Computer name
- Username
- Process ID
- Thread ID
The relevant values are collected through functions including GetComputerName and GetUserName.
The implant also provides screenshot functionality through:
GdiplusStartupGetDCCreateCompatibleBitmapBitBlt
This is a classic screen-capture implementation.
CreateProcess is present, providing command and payload execution capability.
Persistence is achieved through registry operations including RegCreateKey and RegSetValue, combined with a reference to:
CurrentVersion\RunThis indicates autostart persistence through a Windows Run key.
File-system functionality is provided through APIs such as:
CreateFileWriteFileGetTempPath
This allows the implant to store downloaded artifacts locally.
Anti-analysis functionality includes:
IsDebuggerPresentCheckRemoteDebuggerPresent- Timing checks using
QueryPerformanceCounter
What Does update.exe Do?
We have now analyzed one of the three discovered files. Next up is update.exe.
update.exe is a lightweight x64 in-memory loader that disguises itself as the Windows Security Health Service through manipulated version information.
After performing several basic anti-sandbox checks, including a sleep-timing check, verification of available physical memory and a check of the number of logical processors, the malware retrieves the Telegram page:
t.me/flufff6262It extracts a value embedded between [CFG] and [/CFG] markers from the page content.
The value is first decoded from Base64 and then decrypted using XOR.
Example
Input: [CFG]XFNPUVZLV1MfAQ==[/CFG]
Output: 86.54.25[.]2
The malware then launches a hidden copy of itself as a new process using the following argument:
--exec <host>Inside the child process, the malware patches:
EtwEventWriteAmsiScanBuffer
It also opens a clean copy of:
C:\Windows\System32\ntdll.dllThe malware reads the clean .text section and overwrites the corresponding section of the already loaded ntdll.dll.
This unhooking operation is likely intended to remove user-mode hooks installed by EDR or monitoring products.
The malware subsequently decrypts an embedded 757-byte x64 shellcode payload using a 16-byte repeating-key XOR key.
The placeholder IP address:
111.111.111.111inside the shellcode is replaced with the host previously retrieved through Telegram.
The corresponding memory region is then marked as executable and the shellcode is called directly.
The embedded WinINet-based stager connects to the dynamically resolved C2 server over HTTPS on TCP port 443. It retrieves the next stage from a hardcoded URI and loads it directly into memory.
Its structure and behavior are strongly consistent with a Metasploit x64 reverse_https stager.
I did not identify:
- A persistence mechanism
- Traditional process injection
- The deployment of another PE file to the file system
For that reason, update.exe is more accurately classified as an in-memory loader or HTTPS stager, rather than a traditional dropper.
What Does 22.exe Do?
This one was an incidental discovery.
The file is hosted on the threat actors infrastructure, but I have not found any previous malware sightings associated with it.
22.exe is a multi-stage x64 launcher that uses an embedded Xray Core client as a covert transport and proxy layer.
The Go-based launcher first decrypts an embedded configuration using AES-256-GCM.
It then extracts two gzip-compressed components into the temporary directory:
- An Xray client
- A native Windows loader
The filenames are randomly generated at runtime.
Xray exposes two local proxies:
HTTP: 127.0.0.1:10809
SOCKS: 127.0.0.1:10808Outbound traffic is tunneled through a VLESS connection using XTLS Vision and REALITY to:
5.181.156[.]168:25475The launcher also enables the WinINet proxy for the currently logged-in Windows user and provides the native loader with matching HTTP_PROXY and HTTPS_PROXY environment variables.
The downstream native loader patches the following functions:
AmsiScanBufferAmsiOpenSessionEtwEventWriteEtwEventWriteTransferNtTraceEvent
This is intended to interfere with AMSI- and ETW-based monitoring.
The loader then decrypts an embedded PE using AES-256-CBC, manually applies its relocations, resolves its imports and calls the entry point directly inside its own process.
The final payload was identified with high confidence as Vidar v2.
Vidar collects, among other things:
- Browser passwords
- Cookies
- Browser history
- Autofill data
- Cryptocurrency wallet data
- Cryptocurrency-related browser extensions
- Telegram artifacts
- Discord artifacts
- Steam artifacts
- Outlook configurations
- FileZilla configurations
- System information
- Screenshots
- Files defined by the C2 configuration
It also supports server-side loader tasks that allow the operator to execute additional programs or scripts.
After completing its activity or after the configured execution window expires the launcher terminates the processes it started, disables the previously configured proxy, deletes the temporary files and removes itself.
No permanent persistence mechanism was identified in the analyzed execution chain.
IIM Chain
I will spare you the usual IIM blah blah today and instead refer you to the article “IIM Feed: Attack Pattern Mapping for Adversary Infrastructure (5/7)“ if you want more information about how IIM works and what it is useful for.
Click to View Chains as JSON
{
"iim_version": "1.1",
"chain_id": "ghostshell.mb-0009.besomar-rar-to-mtls-implant-telegram-deaddrop-and-xray-vidar",
"title": "GhostShell (MB-0009) Besomar-themed CVE-2025-8088 RAR to Startup VBS, three-way payload split: EC-mTLS implant on cndexpress.cc, Telegram dead-drop Metasploit stager and Xray/VLESS-tunneled Vidar v2",
"description": "IIM chain for the June 2026 GhostShell (MB-0009) campaign against Ukraine's UAV / drone supply chain. A RAR archive (Besomar_documentation.rar) abuses CVE-2025-8088/CVE-2025-6218 archive handling to drop a VBS into the Windows Startup folder via relative path traversal. The decoy set impersonates the Ukrainian fixed-wing drone manufacturer Besomar and is tailored to military units, technical staff, procurement and volunteer organisations. The Startup VBS base64-decodes an ExecuteGlobal stub and pulls 122.exe and update.exe from cloudaxis.cc; KRAKEN additionally surfaced 22.exe staged on the same infrastructure. The three binaries form three distinct C2 lanes: (1) 122.exe is an XOR-overlay loader (CRPT, key d0cd4cb8d4673e28) that runs a Stage-2 implant in memory, authenticating to cndexpress.cc over WinHTTP with an embedded EC mutual-TLS client certificate issued by a self-named 'GhostShell Implant CA' while ignoring the server cert; (2) update.exe is an in-memory HTTPS stager that resolves its live C2 host (86.54.25.2) from a Telegram dead-drop (t.me/flufff6262, [CFG]...[/CFG] base64+XOR 'deadbeef1337') and runs a Metasploit-consistent x64 reverse_https shellcode after AMSI/ETW patching and ntdll unhooking; (3) 22.exe is a Go launcher embedding an Xray-Core client that tunnels traffic via VLESS+XTLS Vision+REALITY to 5.181.156.168:25475 and ultimately executes Vidar v2 in memory. The highest-value attribution pivot is the hard-coded issuer CN=GhostShell Implant CA on the implant PKI.",
"actor_id": "MB-0009",
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "likely",
"needs_review": false,
"import_source": "manual-osint-report-to-iim-conversion",
"entities": [
{
"id": "rar_archive",
"type": "file",
"value": "Besomar_documentation.rar",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"SHA256 28f58061348a1c54fa6e7ff6618630259618d4afdf78514d5fccfc993797cdff.",
"Report states the RAR abuses CVE-2025-8088 / CVE-2025-6218 (the same archive-handling weakness used in the Gamaredon case).",
"Extraction copies a VBS file into the Windows Startup folder using multiple relative paths to reliably reach Startup from the working directory."
]
},
{
"id": "decoy_pdf",
"type": "file",
"value": "\u0411\u043f\u041b\u0410 Besomar 3210.pdf",
"observed_at": "2026-06-06T16:39:42+02:00",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"Representative member of a 7-PDF decoy set impersonating the Ukrainian fixed-wing drone manufacturer Besomar.",
"Full set: \u0411\u043f\u041b\u0410 Besomar 3210.pdf, \u0417\u0430\u0440\u044f\u0434\u043d\u0430 \u0441\u0442\u0430\u043d\u0446\u0456\u044f.pdf, \u041a\u0430\u0442\u0430\u043f\u0443\u043b\u044c\u0442\u0430.pdf, \u041a\u043e\u043c\u043f\u043b\u0435\u043a\u0442\u0430\u0446\u0456\u044f \u0411\u043f\u041b\u0410 Besomar.pdf, \u041c\u043e\u0434\u0438\u0444\u0456\u043a\u0430\u0446\u0456\u044f Besomar 3210-N.pdf, \u041f\u0435\u0440\u0435\u0432\u0430\u0433\u0438 \u0441\u043f\u0456\u0432\u043f\u0440\u0430\u0446\u0456.pdf, \u041f\u0440\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0456\u044e.pdf.",
"All decoys share identical size and identical creation timestamp 2026:06:06 16:39:42+02:00 (UTC+2 surface signal).",
"Decoy targeting indicates interest in operational access and supply-chain intelligence around Ukrainian UAV deployments: military units, technical personnel, procurement staff, volunteer organisations and defense-sector partners."
]
},
{
"id": "startup_vbs",
"type": "file",
"value": "%APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\MicrosoftUpdate-1.302.1609.vbs",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"SHA256 cff6007dbb9826d0a08865f47a71b31e90c5067c637ac863e360315da984f107; all VBS copies share this hash (identical file).",
"Contains a base64 string decoded then run via ExecuteGlobal.",
"Decoded stub uses WScript.Shell to curl two payloads from cloudaxis.cc into %TEMP% and start them (EdgeUpdate.exe / edge_service.exe).",
"Placement in the Startup folder provides logon persistence."
]
},
{
"id": "cloudaxis_url_122",
"type": "url",
"value": "hxxps://cloudaxis[.]cc/gsmft/yueu/fkvqld/tvqqwh/ushu/122.exe",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"Download URL emitted by the decoded VBS stub for the 122.exe loader.",
"Defanged from https://cloudaxis.cc/gsmft/yueu/fkvqld/tvqqwh/ushu/122.exe for public feed display."
]
},
{
"id": "cloudaxis_url_update",
"type": "url",
"value": "hxxps://cloudaxis[.]cc/gsmft/yueu/fkvqld/tvqqwh/ushu/update.exe",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"Download URL emitted by the decoded VBS stub for the update.exe in-memory loader.",
"Defanged from https://cloudaxis.cc/gsmft/yueu/fkvqld/tvqqwh/ushu/update.exe for public feed display."
]
},
{
"id": "cloudaxis_domain",
"type": "domain",
"value": "cloudaxis.cc",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009) (Whois)",
"evidence": [
"Delivery domain hosting 122.exe and update.exe.",
"Registrar PDR Ltd d/b/a PublicDomainRegistry.com; created 2026-02-11, expires 2027-02-11 (~131 days old at observation).",
"Direct browser access to the malware URLs returns 404 Not Found (nginx); the real payloads are only served to the malware client.",
"Registration date (February) is consistent with earlier GhostShell findings referenced by the analyst."
]
},
{
"id": "cloudaxis_ip",
"type": "ip",
"value": "154.58.204.149",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009) (Whois)",
"evidence": [
"Dedicated server hosting cloudaxis.cc.",
"IP location Madrid, Spain - Cogent Communications.",
"ASN AS214036 ULTAHOST-AS Ultahost, Inc., US (registered 2024-10-15)."
]
},
{
"id": "loader_122",
"type": "file",
"value": "122.exe",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"SHA256 ab5681266f70af7df24383f15de876e411fc18e35cb6f24603b12f580b05ccb3.",
"PE32+ x86-64, 6 sections; ~190 KB XOR overlay (magic 'CRPT') starting at offset 0x19C64.",
"Overlay XOR key d0cd4cb8d4673e28 (most frequent 8-byte block under fixed-key XOR).",
"Acts as a loader: XOR-unpacks the CRPT overlay and runs the Stage-2 PE in memory (VirtualAlloc / VirtualProtect / LoadLibrary / GetProcAddress)."
]
},
{
"id": "stage2_implant",
"type": "file",
"value": "GhostShell Stage-2 implant (in-memory PE carved from 122.exe CRPT overlay)",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"Stage-2 PE32+ x86-64, ~190.5 KB, carved as stage2.bin (MD5 df587c58c82d7cfb41d966d2fe21cecb).",
"Embedded config stored as an encrypted blob in .rdata at VA 0x140020880; in-place decrypt routine key = (i*7 - 0x58) & 0xFF over len 870, with AVX2 fast-path and scalar fallback.",
"Decrypted config is a DER/PKCS#12 (.pfx) container holding the mutual-TLS client certificate and private key.",
"Capabilities: HTTPS C2 via WinHTTP; host-fingerprint beacon implant=v%u.%u.%u&host=%s&user=%s&pid=%lu&tid=%lu; GDI+ screenshot; CreateProcess command execution; Run-key persistence; file I/O; anti-analysis (IsDebuggerPresent / CheckRemoteDebuggerPresent + QueryPerformanceCounter timing)."
]
},
{
"id": "implant_cert",
"type": "certificate",
"value": "CA:53:3B:51:F3:22:5F:D2:4A:64:C6:34:EE:31:4F:06:01:E7:E2:FF:2D:5E:F3:64:23:5E:F4:EB:16:56:47:AE",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"EC mutual-TLS client certificate carved from the Stage-2 PKCS#12 config (PW empty, MAC check skipped).",
"Subject CN=ed6e62814295701f (16 hex chars = 8-byte/64-bit per-implant ID); Issuer CN=GhostShell Implant CA; Serial 11145A2322AA5595D27E25CC977AD1B53CE88DCD (160-bit random).",
"ECDSA prime256v1 (P-256), ecdsa-with-SHA256; clientAuth EKU (critical); CA:FALSE (critical); no SAN; valid 2026-06-18 to 2027-06-19.",
"Issuer string 'GhostShell Implant CA' is a self-named private CA, very likely hard-coded in the C2 builder - the strongest cluster pivot of the whole set: any future sample or server presenting this issuer hangs off the same cluster.",
"P-256 + 160-bit random serial + thin critical-extension template is weakly consistent with Go crypto/x509 defaults (low-confidence toolchain hint)."
]
},
{
"id": "cndexpress_c2_url",
"type": "url",
"value": "hxxps://cndexpress[.]cc/analytics/collect",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"Stage-2 implant POSTs host-fingerprint beacons to /analytics/collect over HTTPS (WinHTTP).",
"Implant authenticates with the embedded EC mTLS client cert and ignores the server certificate (WinHttpSetOption flags 0x3300).",
"Sandbox without the client cert receives HTTP/1.1 400 Bad Request from nginx (custom headers X-Client-Version / X-Key-ID / X-Thread-ID present in the beacon).",
"Defanged from https://cndexpress.cc/analytics/collect for public feed display."
]
},
{
"id": "cndexpress_domain",
"type": "domain",
"value": "cndexpress.cc",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009) (Whois)",
"evidence": [
"Stage-2 C2 domain; deliberately on a different registrar than the delivery domain (the actor avoids hosting everything in one place).",
"Registrar Spaceship, Inc.; created 2026-06-15, expires 2027-06-15 (~7 days old at observation).",
"Root path serves a minimal, AI-generated 'CDN Express' decoy hosting page; the real endpoint requires the mTLS client cert (400 Bad Request 'No required SSL certificate was sent' otherwise)."
]
},
{
"id": "cndexpress_ip",
"type": "ip",
"value": "5.252.177.88",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009) (Whois / sandbox)",
"evidence": [
"Dedicated server hosting cndexpress.cc; sandbox POSTs to 5.252.177.88:443 (cndexpress.cc) returned 400 Bad Request.",
"IP location Missouri, US - MivoCloud.",
"ASN AS39798 MivoCloud SRL, MD (registered 2015-03-24)."
]
},
{
"id": "loader_update",
"type": "file",
"value": "update.exe",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"SHA256 b1834634820ae696f0514ca2b6723061f115857232306e573f4d115bc6ead012.",
"Lightweight x64 in-memory loader / HTTPS stager masquerading as 'Windows Security Health Service' via manipulated version info.",
"Anti-sandbox: sleep-timing check, available-RAM check, logical-processor-count check.",
"Child process (re-launched with --exec <host>) patches EtwEventWrite and AmsiScanBuffer, then unhooks ntdll by overwriting the loaded .text section from a clean on-disk copy.",
"Decrypts an embedded 757-byte x64 shellcode with a 16-byte repeating-key XOR; placeholder 111.111.111.111 is replaced with the Telegram-derived host; behaviour is strongly consistent with a Metasploit x64 reverse_https stager. No persistence, no classic process injection, no PE dropped to disk."
]
},
{
"id": "telegram_deaddrop",
"type": "url",
"value": "hxxps://t[.]me/flufff6262",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"update.exe fetches this Telegram channel page over HTTPS and extracts a value embedded between [CFG] and [/CFG].",
"The value is base64-decoded then XOR-decoded with key 'deadbeef1337' to yield the runtime C2 host. Example: [CFG]XFNPUVZLV1MfAQ==[/CFG] -> 86.54.25.2.",
"Channel 'flufff6262' (1 subscriber, bio 'testing some code for fun') acts as a dead-drop resolver on a legitimate third-party platform.",
"Defanged from https://t.me/flufff6262 for public feed display."
]
},
{
"id": "metasploit_c2_ip",
"type": "ip",
"value": "86.54.25.2",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009) (Whois)",
"evidence": [
"Runtime C2 host decoded from the Telegram dead-drop; the WinINet stager connects to it over HTTPS on TCP/443 and loads the next stage in memory.",
"IP location Kazakhstan ADSL - Icosys Computers And Communication Limited.",
"ASN AS210006 ASKZ Shereverov Marat Ahmedovich, KZ (registered 2025-05-14); netname Shereverov-network, country KZ.",
"Because the address is fetched at runtime from a rotating dead-drop post, the operational host can be changed without rebuilding the implant."
]
},
{
"id": "launcher_22",
"type": "file",
"value": "22.exe",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"SHA256 8de34006dafd990853a45cbe9aaab4ee18c8cd4c1ad0a98fe71f8d63cd60db25.",
"Discovered by KRAKEN on the same delivery infrastructure; not previously seen elsewhere as malware.",
"Multi-stage Go x64 launcher: AES-256-GCM-decrypts an embedded config, extracts two gzip components (an Xray-Core client and a native Windows loader) to %TEMP% with randomized filenames.",
"Native loader patches AmsiScanBuffer, AmsiOpenSession, EtwEventWrite, EtwEventWriteTransfer and NtTraceEvent, then AES-256-CBC-decrypts an embedded PE and manually maps it (relocations + import resolution) before calling its entry point in-process.",
"On completion it kills started processes, disables the proxy, removes temp files and self-deletes; no persistence observed."
]
},
{
"id": "xray_c2",
"type": "ip",
"value": "5.181.156.168",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009) (Whois)",
"evidence": [
"Xray-Core tunnel endpoint; outbound traffic is tunneled via VLESS + XTLS Vision + REALITY to 5.181.156.168:25475.",
"Locally the launcher exposes an HTTP proxy on 127.0.0.1:10809 and a SOCKS proxy on 127.0.0.1:10808 and sets the user WinINET proxy plus HTTP_PROXY / HTTPS_PROXY for the loader.",
"IP location Moldova, Chisinau - MivoCloud; resolve host 5-181-156-168.mivocloud.com.",
"ASN AS39798 MivoCloud SRL, MD (registered 2015-03-24) - same hoster (MivoCloud / AS39798) as the cndexpress.cc C2 IP."
]
},
{
"id": "vidar_payload",
"type": "file",
"value": "Vidar v2 (in-memory, manually mapped by the 22.exe native loader)",
"observed_at": "2026-06-22T00:00:00Z",
"source": "Synaptic Security Blog: GhostShell (MB-0009)",
"evidence": [
"Final payload identified with high confidence as Vidar v2.",
"Collects browser passwords, cookies, history and autofill, crypto-wallet data, browser-extension data, Telegram/Discord/Steam artifacts, Outlook/FileZilla configs, system info, screenshots and C2-defined files.",
"Supports server-side loader tasks for executing further programs or scripts; exfiltration rides the Xray VLESS tunnel."
]
}
],
"chain": [
{
"entity_id": "rar_archive",
"role": "entry",
"techniques": ["IIM-T024"],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false
},
{
"entity_id": "decoy_pdf",
"role": "entry",
"techniques": [],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false,
"review_notes": "Decoy document is target-localization context for the initial delivery, not the execution payload itself."
},
{
"entity_id": "startup_vbs",
"role": "staging",
"techniques": ["IIM-T024"],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false,
"review_notes": "Loader artifact placed in Startup via archive path traversal (CVE-2025-8088); logon persistence is captured separately in attack_annotations (T1547.001)."
},
{
"entity_id": "cloudaxis_url_122",
"role": "staging",
"techniques": [],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false
},
{
"entity_id": "cloudaxis_url_update",
"role": "staging",
"techniques": [],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false
},
{
"entity_id": "cloudaxis_domain",
"role": "staging",
"techniques": ["IIM-T002"],
"role_confidence": "confirmed",
"technique_confidence": "likely",
"needs_review": false,
"review_notes": "Dedicated-server delivery host (Ultahost / Cogent). Tagged cloud/commercial hosting; ~131 days old so not disposable."
},
{
"entity_id": "cloudaxis_ip",
"role": "staging",
"techniques": ["IIM-T002"],
"role_confidence": "confirmed",
"technique_confidence": "likely",
"needs_review": false
},
{
"entity_id": "loader_122",
"role": "staging",
"techniques": [],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false,
"review_notes": "XOR-overlay (CRPT) loader; runs Stage-2 in memory."
},
{
"entity_id": "stage2_implant",
"role": "payload",
"techniques": [],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false
},
{
"entity_id": "implant_cert",
"role": "staging",
"techniques": ["IIM-T012"],
"role_confidence": "likely",
"technique_confidence": "confirmed",
"needs_review": false,
"review_notes": "Role: IIM has no dedicated credential role; the cert is modeled as a staging/transport artifact because its job is authenticating the implant to C2. The shared self-named issuer (CN=GhostShell Implant CA) across per-implant leaf certs is the IIM-T012 reuse signal and the primary cluster pivot."
},
{
"entity_id": "cndexpress_c2_url",
"role": "c2",
"techniques": ["IIM-T021"],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false,
"review_notes": "mTLS-gated endpoint: the real response is served only when the custom client presents the embedded client cert (request-fingerprinting gate); otherwise 400 Bad Request."
},
{
"entity_id": "cndexpress_domain",
"role": "c2",
"techniques": ["IIM-T002", "IIM-T010"],
"role_confidence": "confirmed",
"technique_confidence": "likely",
"needs_review": false,
"review_notes": "~7-day-old domain on a separate registrar (Spaceship) = disposable registration; AI-generated decoy hosting page at root."
},
{
"entity_id": "cndexpress_ip",
"role": "c2",
"techniques": ["IIM-T002"],
"role_confidence": "confirmed",
"technique_confidence": "likely",
"needs_review": false
},
{
"entity_id": "loader_update",
"role": "staging",
"techniques": [],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false,
"review_notes": "In-memory HTTPS stager (Metasploit-consistent), classified as loader/stager rather than dropper."
},
{
"entity_id": "telegram_deaddrop",
"role": "redirector",
"techniques": ["IIM-T006", "IIM-T013"],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false,
"review_notes": "Dead-drop resolver on a legitimate third-party site (Telegram). Telegram only encodes the next-hop host here; it is not used as the bidirectional message bus, so IIM-T018 is intentionally not applied."
},
{
"entity_id": "metasploit_c2_ip",
"role": "c2",
"techniques": ["IIM-T011"],
"role_confidence": "confirmed",
"technique_confidence": "likely",
"needs_review": false,
"review_notes": "Operational host is fetched at runtime via the dead-drop resolver, so it functions as a rotatable C2 node (IIM-T011). KZ ADSL / small AS could also support a bulletproof-style read (IIM-T003) but that is left out pending more nodes."
},
{
"entity_id": "launcher_22",
"role": "staging",
"techniques": [],
"role_confidence": "confirmed",
"technique_confidence": "confirmed",
"needs_review": false,
"review_notes": "Go launcher embedding Xray-Core; transport/proxy layer plus in-memory PE loader."
},
{
"entity_id": "xray_c2",
"role": "c2",
"techniques": ["IIM-T002"],
"role_confidence": "confirmed",
"technique_confidence": "likely",
"needs_review": false,
"review_notes": "VLESS + XTLS Vision + REALITY tunnel endpoint on MivoCloud (AS39798), same hoster as cndexpress_ip. No dedicated IIM technique exists for an encrypted proxy transport; tagged cloud hosting and described in evidence."
},
{
"entity_id": "vidar_payload",
"role": "payload",
"techniques": [],
"role_confidence": "likely",
"technique_confidence": "confirmed",
"needs_review": false,
"review_notes": "Commodity stealer (Vidar v2) delivered via the 22.exe lane; role-confidence likely because identification is by behavior/family rather than a clean published sample hash."
}
],
"relations": [
{
"from": "rar_archive",
"to": "decoy_pdf",
"type": "drops",
"sequence_order": 1,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Extracting the RAR writes the Besomar-themed decoy PDFs alongside the malicious VBS.",
"All decoys share identical size and creation timestamp 2026:06:06 16:39:42+02:00."
]
},
{
"from": "rar_archive",
"to": "startup_vbs",
"type": "drops",
"sequence_order": 2,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Extraction copies the VBS into %APPDATA%\\...\\Startup via relative path traversal, abusing CVE-2025-8088 / CVE-2025-6218.",
"All dropped VBS copies share SHA256 cff6007dbb9826d0a08865f47a71b31e90c5067c637ac863e360315da984f107."
]
},
{
"from": "startup_vbs",
"to": "cloudaxis_url_122",
"type": "download",
"sequence_order": 3,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Decoded ExecuteGlobal stub runs curl against the cloudaxis.cc 122.exe URL into %TEMP%."
]
},
{
"from": "startup_vbs",
"to": "cloudaxis_url_update",
"type": "download",
"sequence_order": 4,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Decoded ExecuteGlobal stub runs curl against the cloudaxis.cc update.exe URL into %TEMP%."
]
},
{
"from": "cloudaxis_url_122",
"to": "cloudaxis_domain",
"type": "references",
"sequence_order": 5,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Locator-to-host edge: the 122.exe download URL is served from cloudaxis.cc."
]
},
{
"from": "cloudaxis_url_update",
"to": "cloudaxis_domain",
"type": "references",
"sequence_order": 6,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Locator-to-host edge: the update.exe download URL is served from cloudaxis.cc."
]
},
{
"from": "cloudaxis_domain",
"to": "cloudaxis_ip",
"type": "resolves-to",
"sequence_order": 7,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Whois lists 154.58.204.149 (Madrid / Cogent / AS214036 Ultahost) as the dedicated server for cloudaxis.cc."
]
},
{
"from": "cloudaxis_url_122",
"to": "loader_122",
"type": "download",
"sequence_order": 8,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"The 122.exe URL serves the PE32+ loader (SHA256 ab5681266f...) to the malware client."
]
},
{
"from": "loader_122",
"to": "stage2_implant",
"type": "execute",
"sequence_order": 9,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"122.exe XOR-unpacks the CRPT overlay (key d0cd4cb8d4673e28) and runs the Stage-2 PE in memory (VirtualAlloc / VirtualProtect / LoadLibrary / GetProcAddress)."
]
},
{
"from": "stage2_implant",
"to": "implant_cert",
"type": "references",
"sequence_order": 10,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"The Stage-2 implant carries the EC mTLS client cert + key in its .rdata PKCS#12 config and presents it for C2 authentication.",
"Issuer CN=GhostShell Implant CA is the per-cluster PKI anchor."
]
},
{
"from": "stage2_implant",
"to": "cndexpress_c2_url",
"type": "connect",
"sequence_order": 11,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Implant POSTs the host-fingerprint beacon to cndexpress.cc/analytics/collect over WinHTTP, authenticating with the client cert and ignoring the server cert (flags 0x3300)."
]
},
{
"from": "cndexpress_c2_url",
"to": "cndexpress_domain",
"type": "references",
"sequence_order": 12,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Locator-to-host edge: the /analytics/collect endpoint is served from cndexpress.cc."
]
},
{
"from": "cndexpress_domain",
"to": "cndexpress_ip",
"type": "resolves-to",
"sequence_order": 13,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"Sandbox traffic to cndexpress.cc terminates at 5.252.177.88:443 (Missouri / MivoCloud / AS39798)."
]
},
{
"from": "cloudaxis_url_update",
"to": "loader_update",
"type": "download",
"sequence_order": 14,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"The update.exe URL serves the in-memory loader / HTTPS stager (SHA256 b18346348...)."
]
},
{
"from": "loader_update",
"to": "telegram_deaddrop",
"type": "download",
"sequence_order": 15,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"update.exe fetches t.me/flufff6262 over HTTPS and reads the [CFG]...[/CFG] value from the page body."
]
},
{
"from": "telegram_deaddrop",
"to": "metasploit_c2_ip",
"type": "references",
"sequence_order": 16,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"The [CFG] blob base64+XOR('deadbeef1337') decodes to the C2 host: [CFG]XFNPUVZLV1MfAQ==[/CFG] -> 86.54.25.2."
]
},
{
"from": "loader_update",
"to": "metasploit_c2_ip",
"type": "connect",
"sequence_order": 17,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"After substituting the resolved host into the 757-byte shellcode (placeholder 111.111.111.111), the WinINet stager connects to 86.54.25.2 over HTTPS/443 and pulls the next stage in memory (Metasploit x64 reverse_https-consistent)."
]
},
{
"from": "cloudaxis_domain",
"to": "launcher_22",
"type": "references",
"sequence_order": 18,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "tentative",
"x_evidence": [
"KRAKEN surfaced 22.exe (SHA256 8de34006d...) as an additional file distributable from the same delivery infrastructure.",
"The exact cloudaxis.cc URL/path for 22.exe is not published, so this hosting edge is kept tentative pending a confirmed delivery URL."
]
},
{
"from": "launcher_22",
"to": "vidar_payload",
"type": "execute",
"sequence_order": 19,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "likely",
"x_evidence": [
"The native loader extracted by 22.exe AES-256-CBC-decrypts an embedded PE, manually maps it and calls its entry point in-process; the mapped payload is Vidar v2."
]
},
{
"from": "launcher_22",
"to": "xray_c2",
"type": "connect",
"sequence_order": 20,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "confirmed",
"x_evidence": [
"The embedded Xray-Core client tunnels outbound traffic via VLESS + XTLS Vision + REALITY to 5.181.156.168:25475 and exposes local HTTP/SOCKS proxies on 127.0.0.1:10809 / 127.0.0.1:10808."
]
},
{
"from": "vidar_payload",
"to": "xray_c2",
"type": "communicates-with",
"sequence_order": 21,
"observed_at": "2026-06-22T00:00:00Z",
"confidence": "likely",
"x_evidence": [
"Vidar exfiltration is routed through the local proxy / Xray tunnel; 5.181.156.168 is the observed tunnel endpoint rather than Vidar's terminal C2.",
"Kept likely because the report establishes the tunnel and the Vidar family but does not expose Vidar's own downstream C2 host."
]
}
],
"attack_annotations": [
{
"technique_id": "T1566.001",
"name": "Phishing: Spearphishing Attachment",
"tactic": "Initial Access",
"comment": "Besomar-themed RAR archive delivered to Ukrainian UAV-sector targets."
},
{
"technique_id": "T1203",
"name": "Exploitation for Client Execution",
"tactic": "Execution",
"comment": "CVE-2025-8088 / CVE-2025-6218 archive handling places the VBS into the Startup folder."
},
{
"technique_id": "T1059.005",
"name": "Command and Scripting Interpreter: Visual Basic",
"tactic": "Execution",
"comment": "Base64 + ExecuteGlobal VBS stub fetches and launches the EXEs."
},
{
"technique_id": "T1547.001",
"name": "Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder",
"tactic": "Persistence",
"comment": "VBS placed in the Windows Startup folder; Stage-2 implant additionally uses CurrentVersion\\Run."
},
{
"technique_id": "T1140",
"name": "Deobfuscate/Decode Files or Information",
"tactic": "Defense Evasion",
"comment": "CRPT XOR overlay (d0cd4cb8d4673e28), (i*7-0x58)&0xFF config decrypt, base64+XOR 'deadbeef1337' dead-drop config."
},
{
"technique_id": "T1620",
"name": "Reflective Code Loading",
"tactic": "Defense Evasion",
"comment": "122.exe runs Stage-2 in memory; update.exe runs decrypted shellcode; 22.exe manually maps Vidar in-process."
},
{
"technique_id": "T1562.001",
"name": "Impair Defenses: Disable or Modify Tools",
"tactic": "Defense Evasion",
"comment": "update.exe patches AMSI/ETW and unhooks ntdll; 22.exe loader patches AmsiScanBuffer/AmsiOpenSession/EtwEventWrite/EtwEventWriteTransfer/NtTraceEvent."
},
{
"technique_id": "T1497",
"name": "Virtualization/Sandbox Evasion",
"tactic": "Defense Evasion",
"comment": "update.exe checks sleep timing, available RAM and logical processor count."
},
{
"technique_id": "T1102.001",
"name": "Web Service: Dead Drop Resolver",
"tactic": "Command and Control",
"comment": "update.exe resolves its C2 host from a Telegram channel post (t.me/flufff6262)."
},
{
"technique_id": "T1071.001",
"name": "Application Layer Protocol: Web Protocols",
"tactic": "Command and Control",
"comment": "HTTPS beacons to cndexpress.cc and HTTPS stager traffic to 86.54.25.2."
},
{
"technique_id": "T1573.002",
"name": "Encrypted Channel: Asymmetric Cryptography",
"tactic": "Command and Control",
"comment": "EC mutual-TLS (P-256) client-cert authentication between Stage-2 implant and cndexpress.cc."
},
{
"technique_id": "T1090",
"name": "Proxy",
"tactic": "Command and Control",
"comment": "22.exe routes traffic through an embedded Xray-Core VLESS/XTLS/REALITY tunnel to 5.181.156.168:25475."
},
{
"technique_id": "T1113",
"name": "Screen Capture",
"tactic": "Collection",
"comment": "Stage-2 implant uses GDI+ (GdiplusStartup/GetDC/CreateCompatibleBitmap/BitBlt)."
},
{
"technique_id": "T1555.003",
"name": "Credentials from Password Stores: Credentials from Web Browsers",
"tactic": "Credential Access",
"comment": "Vidar v2 steals browser passwords, cookies, autofill and extension data."
}
],
"x_actor_name": "GhostShell",
"x_malwarebox_id": "MB-0009",
"x_cve": ["CVE-2025-8088", "CVE-2025-6218"],
"x_victim_context": "Ukraine UAV / drone supply chain - military units, technical personnel, procurement staff, volunteer organisations and defense-sector partners; lures impersonate the Ukrainian fixed-wing drone manufacturer Besomar.",
"x_source_reports": [
"Synaptic Security Blog - GhostShell (MB-0009): Targeting Ukraine's UAV Operations and Defense Supply Chain"
],
"x_source_urls": [
"https://blog.synapticsystems.de/ghostshell-mb-0009-targeting-ukraines-uav-operations-and-defense-supply-chain/"
],
"x_report_published_at": "2026-06-22T00:00:00Z",
"x_cluster_pivots": [
"Issuer CN=GhostShell Implant CA on the implant mTLS PKI (very likely hard-coded in the C2 builder; strongest pivot).",
"Stage-2 config decrypt routine (i*7 - 0x58) & 0xFF with AVX2 + scalar paths.",
"CRPT XOR overlay key d0cd4cb8d4673e28.",
"Beacon template implant=v%u.%u.%u&host=%s&user=%s&pid=%lu&tid=%lu (YARA-able).",
"Infra discipline: registrar/hosting separation (PDR+Cogent/Ultahost vs Spaceship+MivoCloud), per-phase rotation, reused AI-generated decoy hosting pages."
],
"x_solbit_note": "Surface signals (Ukrainian lures, UTC+2 PDF timestamps, 'benefits Russia' cui-bono) all point one way but are the cheapest to plant; the expensive origin-bearing deep signals (custom crypto routine, implant PKI, infra discipline) are currently neutral. No surface/deep divergence indicating a false flag, but also no deep evidence for a sponsor: attribution is held honestly at cluster level (GhostShell / MB-0009), not at sponsor level.",
"x_publication_safety": "URL entity values are defanged (hxxps, [.]); domain and ip entity values are kept live for tooling/pivoting. Hashes, the cert fingerprint and crypto keys are from the published analyst report.",
"x_corrective_notes": [
"Modeled the implant mTLS client certificate as a 'staging' position (auth/transport material) because IIM v1.1 has no credential role; documented in review_notes.",
"Telegram dead-drop tagged IIM-T013 + IIM-T006 only (not IIM-T018), since Telegram resolves the next-hop host rather than acting as the bidirectional message bus.",
"22.exe -> cloudaxis hosting edge kept tentative: KRAKEN found 22.exe on the infrastructure but the exact delivery URL/path is not published.",
"Stage-2 modeled as a descriptive 'file' entity (no clean published SHA-256); MD5 df587c58c82d7cfb41d966d2fe21cecb retained in evidence."
]
}
IIM View in KRAKEN
How Do We Use the Extracted Intelligence for Further Analysis?
I recently published another component of the Malwarebox ecosystem: the SOLBIT model.
SOLBIT is a general model for attribution under deception.
CTI is the first domain in which I have implemented it, but the model can, in principle, also be applied to other intelligence disciplines.
In simple terms, SOLBIT divides the available evidence into six domains:
- Strategic
- Operational
- Linguistic
- Behavioral
- Infrastructure
- Technical
That gives us S-O-L-B-I-T.
The interesting part is not merely the list. Each domain receives a weight based on one central question:
How expensive is this signal to fake?
A hash can be changed in seconds.
An artificial timezone can be inserted just as easily.
Infrastructure developed and maintained over several months or a custom cryptographic routine is considerably more expensive to fake.
SOLBIT therefore does not simply add indicators together. It weighs them according to their resistance to manipulation and deliberately checks whether the cheap, easily fabricated surface-level signals and the expensive, deeper signals point in the same direction.
When they do not, that discrepancy becomes a warning sign for a potential false flag.
And this distinction is particularly important in a new case like GhostShell.
SOLBIT separates:
- The same hand
- Whose hand
It forces me to be honest about the attribution level we have actually reached:
- Cluster
- Persona
- Real-world sponsor
Instead of seeing a victim, spotting a few convenient artifacts and immediately jumping to a flag.
So, let’s throw the findings from above into the six domains.
Strategic: Intent
The target profile is Ukraines UAV and drone supply chain:
- Military units
- Technical personnel
- Procurement staff
- Volunteer organizations
This tells us quite a lot about the actors interests, cui bono, but very little about their origin.
That is exactly why SOLBIT assigns this domain relatively little weight when answering the sponsor question.
“They are targeting Ukraine, therefore it must benefit Russia” is precisely the kind of signal that any half-competent false-flag operation could plant just as easily.
Operational: Tradecraft
This is where things start to get more interesting.
The actor deliberately separates registrars and hosting providers:
- PDR versus Spaceship
- Cogent in Madrid versus MivoCloud in Missouri
The infrastructure is also rotated between campaign phases. cloudaxis[.]cc dates back to February, while cdnexpress[.]cc was only seven days old at the time of analysis.
At the same time, the actor reuses minimal, AI-generated decoy websites.
These are operational decisions, not random coincidences and decisions are more expensive to fake than a hash.
Linguistic
Evidence in this domain is thin, which is itself worth stating.
The Ukrainian-language decoy PDFs represent target localization, a surface-level signal.
The +02:00 timezone found in the PDF metadata is interesting, but it is also trivial to manipulate.
Free-form text suitable for actual NLI or stylometric analysis?
Nowhere to be found.
Coverage in this domain is therefore low and I am going to call it low instead of inflating a weak signal until it looks more exciting than it really is.
Behavioral
This domain describes how the implant behaves.
The implant:
- Ignores server-certificate validation errors using flags
0x3300 - Authenticates using an mTLS client certificate
- Assigns each implant its own 64-bit identifier
- Establishes persistence through a Windows Run key
- Captures screenshots through GDI+
These are behavioral habits that may remain consistent across multiple samples.
Infrastructure: My IIM Stuff
This is the most valuable domain in this case.
We have domains, IP addresses, ASNs, registrars and hosting providers, but most importantly, we have a custom implant PKI using the following issuer:
CN=GhostShell Implant CAThis string is highly likely to be hardcoded into the C2 builder, making it the strongest pivot in the entire artifact set.
Any future sample or server presenting a certificate issued by exactly this CA can be linked back to the same cluster with high confidence.
Technical: IOCs and Code
The technical domain contains the hashes, the XOR overlay key:
d0cd4cb8d4673e28and, more importantly, the custom decryption routine:
(i * 7 - 0x58) & 0xFF
including both its AVX2 implementation and scalar fallback.
We also have the beacon template:
implant=v%u.%u.%u&host=%s&user=%s&pid=%lu&tid=%lu
Hashes are cheap. They change with every build.
The specific cryptographic routine and beacon format, however, are YARA-able and considerably stickier.
So, What Does SOLBIT Tell Us?
All of the surface-level signals, the Ukrainian lures, the UTC+2 metadata and the fact that the operation would supposedly “benefit Russia” point very obediently in the same direction.
But those are also the cheapest signals to plant.
The expensive, origin-bearing, deeper signals, the cryptographic routine, the implant PKI and the actors infrastructure discipline remain neutral for now.
They are strong enough to track GhostShell as an independent cluster, but not strong enough to attach a national flag to it.
There is also no meaningful surface-to-deep divergence that would scream false flag.
I simply do not yet have deep evidence identifying a sponsor.
In practical terms, SOLBIT allows me to anchor GhostShell as a distinct cluster through its implant CA, decryption routine and infrastructure patterns.
At the same time, it keeps the attribution honestly at the cluster level and prevents me from turning “they are targeting Ukraine” into a sponsor assessment that the available evidence simply does not support.
That is exactly what the model is for.
Previous Findings
I have already mentioned that the TA has been active since February 2026.
This is due to the registration of the first domain in February and public posts about the malware / C2 / Telegram
https://x.com/skocherhan/status/2040900975070753103
IoCs
ab5681266f70af7df24383f15de876e411fc18e35cb6f24603b12f580b05ccb3 122.exe
8de34006dafd990853a45cbe9aaab4ee18c8cd4c1ad0a98fe71f8d63cd60db25 22.exe
b1834634820ae696f0514ca2b6723061f115857232306e573f4d115bc6ead012 update.exe
423c98b9a8ad09bbb0aa24e86c23095ef6a26e30b3db07358927929d2fb2ecb3 client.key.pem
1d6f3e8583ce84b892097a03b0d4525850f8d3c59dea56482f17e5c44422dc89 client.cert.pem
c91874dc34e991e614060d6f16da7d4680e5eb7d36fba489644863f4c6c8cf66 config.pfx
a938b7291dbdcdcadb67d560b94bfee366e7f97f06d6f666b25e298c442d8542 БпЛА Besomar 3210.pdf
c5c458a7b1bdfa3cbffdbcd0791912ff19267ad2808a5266a9975b22a53e73e0 Зарядна станція.pdf
e4d377b339f96c69c3001b854b22decae41883bd31f2f5a8c20f57d931ae0b44 Катапульта.pdf
59842745dafd1537c3e2187f82fae7791e646a74251fe20d6c8ebaadf5720880 Комплектація БпЛА Besomar.pdf
54218a8f2d1acc5d1beb576b970bb5333a4b78b05493754d2d1457ebf22a0ac1 Модифікація Besomar 3210-N.pdf
3ec6c91d68b416381ac9f6310a9e011f4060369c63416021864a6d5b91e97dc4 Переваги співпраці.pdf
a8dfa5a35f30c1789ce08b7e16660423bb1545fc8ec7411d24cfd41d1439bb45 Про компанію.pdf
cff6007dbb9826d0a08865f47a71b31e90c5067c637ac863e360315da984f107 БпЛА Besomar 3210.pdf:.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_MicrosoftUpdate-1.302.1609.vbs
28f58061348a1c54fa6e7ff6618630259618d4afdf78514d5fccfc993797cdff Besomar_documentation.rar
c83272741d42a7aa738fbad85e21d0565e50cbf3b72f32b835c225965b3cc207 122_stage2_unpacked.bin
cloudaxis.cc
https://cloudaxis[.]cc/gsmft/yueu/fkvqld/tvqqwh/ushu/122.exe
https://cloudaxis[.]cc/gsmft/yueu/fkvqld/tvqqwh/ushu/22.exe
https://cloudaxis[.]cc/gsmft/yueu/fkvqld/tvqqwh/ushu/update.exe
154.58.204[.]149
cdnexpress.cc
https://cdnexpress[.]cc/analytics
cdnexpress[.]cc
5.252.177[.]88
t.me/flufff6262
86.54.25[.]2
5.181.156[.]168:25475
