A signed loader, a Cobalt Strike Beacon, and C2 traffic dressed up as CrowdStrike

About this post: The file identified by MalwareHunterTeam (Thanks for finding and sharing these). This analysis and write-up were produced by Claude (Opus 5.5) on a REMnux analysis VM. Tools used: Malcat, capstone/objdump, Python (pefile, pycryptodome), capa, Didier Stevens’ 1768.py, speakeasy,  the ANY.RUN sandbox and Triage sandbox.

TL;DR

• 7O5sKBCvFscpcbun.exe is a 1.1 MB Windows program, signed through Microsoft’s Trusted Signing service with a certificate that was valid for only three days and issued to an individual.
• Inside is a small loader that decrypts some hidden code and runs it in memory. That code then unpacks a Cobalt Strike Beacon, a commercial remote-control implant that attackers abuse heavily.
• The Beacon’s network traffic is designed to look like CrowdStrike Falcon talking to its cloud: a CrowdStrike user agent, CrowdStrike-style headers and /api/v2/crowdstrike/... URLs. The real server is a random-looking Azure hostname.
• In the public sandbox the Beacon was found in memory, but it never got as far as contacting its server.

But it’s signed!

Code signing is a digital seal on a program. It says “this file came from this identity and hasn’t been changed since”. Windows and many security tools trust signed files more, so signing is valuable to attackers too.

This file is signed through Microsoft Trusted Signing under the name of a private individual. The certificate was valid from 2 to 5 October 2026, and the file was signed on 3 October. A brand-new, short-lived certificate, issued to a person rather than a company and used straight away on a remote-access implant, is a pattern we see again and again with signed malware. The signature itself is intact. It proves who obtained the certificate. It does not prove the program is safe.

The certificate has been reported to Microsoft and added to the CertGraveyard.

Stage 1: a tiny loader with a big disguise

Only about 9 KB of the file is real code. The rest is mostly an encrypted 520 KB blob plus over 500 KB of padding: a fake Microsoft copyright notice repeated hundreds of times. Padding like this makes the file bigger and “less random-looking”, which can confuse tools that flag files full of encrypted data.

The loader does a few things before it touches the payload:

• It wastes about a millisecond on purpose. It runs a busy loop measured with high-precision timers. Small timing tricks like this can trip up emulators.
• It removes an “instrumentation callback”. Some security products ask Windows to notify them every time the program returns from the kernel. The loader clears that setting for its own process.
• It uses indirect system calls. Normally a program asks Windows for memory through well-known functions that security tools watch closely. Picture a front door with a guard. This loader looks up the internal call numbers itself and jumps into the middle of an unrelated Windows function (NtAddBootEntry) to make the request. That’s going round the guard by a side door.

Then it decrypts the blob with ChaCha20, a modern stream cipher. It puts the result in memory that is first writable and then switched to executable, and jumps into it.

Stage 2: shellcode that unwraps nesting dolls

The decrypted blob is shellcode: raw machine code that runs without being a normal program file. Its job is to be a reflective loader, which loads a full program (a DLL) straight from memory without ever writing it to disk.

The payload is wrapped like nesting dolls. Each layer has a small header that says how to unwrap the next one:

1. base64, the same text encoding used for email attachments;
2. a 192-byte XOR key, a simple scramble that the header carries with it;
3. the final DLL, with its tell-tale MZ and PE header markers deliberately scrambled so that memory scanners looking for those markers have a harder time.

The shellcode also builds a table of Windows system calls and hands it to the payload. That lets the payload use the same “side door” trick as the loader.

Stage 3: Cobalt Strike, dressed as CrowdStrike

The final DLL is a Cobalt Strike Beacon. Cobalt Strike is a commercial tool built for red teams, which are hired to simulate real attackers. Stolen and cracked copies are widely used by real attackers. A Beacon gives its operator remote control of the machine: run commands, move files, inject into other processes, and move on to other systems.

Two independent checks confirm the family. Didier Stevens’ 1768.py parsed the Beacon’s built-in configuration cleanly. ANY.RUN’s memory scan also detected Cobalt Strike and extracted the same configuration.

The interesting part is the Malleable C2 profile, Cobalt Strike’s feature for disguising its network traffic. This profile copies the look of CrowdStrike’s Falcon sensor:

• User-Agent CrowdStrike CsAgent/7.04.18110.0 (Windows 10.0.19045; x64)
• headers X-CS-AGENTID and X-CS-VERSION
• a cookie named falcon_session
• URLs like /api/v2/crowdstrike/entities/sensor-update-policy/v2
• uploads wrapped in fake “DetectionSummary … status resolved” text

To someone skimming proxy logs, this could look like a security agent doing its normal job. The server it’s built to reach, though, is not CrowdStrike: asiioasdjasiojasodijasa.eastus.cloudapp[.]azure[.]com, a keyboard-mash hostname on Microsoft Azure.

Other settings: the Beacon is set to check in every 60 seconds with 25 % random jitter, and it uses msiexec.exe -Embedding as the “sacrificial” process for post-exploitation jobs. Its license watermark is 1817228496, which we could not find in any public reporting.

What we couldn’t see

• The Beacon never phoned home in the sandbox. ANY.RUN found it decoded in memory. However, the process never loaded the networking libraries the Beacon needs, and it never looked up the server’s name. The chain stalled somewhere between unpacking and starting, and we couldn’t determine why without a real Windows machine. So everything above about the C2 describes what it is configured to do, not what we watched it do.
• We didn’t contact the server. We never connect to attacker infrastructure, so we don’t know whether it is live.
• We don’t know how the file was delivered, or whether this is an authorised red-team exercise or a real intrusion. The tooling looks the same either way. A short-lived certificate in a private person’s name points more toward abuse, but that’s not proof.
• The export name levelagent.exe might be aimed at users of the Level RMM product. We have no evidence beyond the name.

Advice

For everyday users: a valid signature isn’t a safety guarantee. Be suspicious of executables with random names like this one, especially when they arrive by link, chat or email rather than from a vendor’s official site.

For defenders:

• Alert on the CrowdStrike user agent or X-CS-AGENTID header going to anything that isn’t CrowdStrike’s real cloud. This is especially easy if you don’t run Falcon at all.
• Watch for msiexec.exe -Embedding started by an unusual parent process.
• Block or monitor the certificate serial and the hashes below.
• Treat freshly-issued Trusted Signing certificates in individuals’ names with extra caution.

IOCs

Wrapping up

The loader is small and the payload is off-the-shelf. The care went into hiding: a fresh signature, encryption, scrambled headers, side-door system calls, and network traffic made to look like a security product. If you spot that CrowdStrike user agent heading somewhere it shouldn’t, now you know what it might be.

Thanks for reading, and stay safe.