Frequency Noise

Scenario

A suspicious binary flagged during endpoint triage returns clean across automated signature scanning — no known hashes, no readable strings of interest, no recognisable cryptographic routines. Sandbox telemetry tells a different story: the binary allocates executable memory and initiates an outbound connection within seconds of launch. The task is to determine how the payload is concealed, how it is restored at runtime, and where it is trying to connect. The obfuscation technique does not rely on any classical cipher.

Methodology

Static Triage — Strings and Imports

Running strings against the binary produces no cleartext URLs, no shellcode byte sequences, and no standard encryption function names. The import table surfaces sin and cos from the CRT math library alongside VirtualAlloc and EnumDesktopsA — an anomalous combination. Legitimate software using trigonometric functions rarely also allocates executable memory. This import profile is the first concrete signal that something unusual is happening with the binary’s payload handling.

strings FrequencyNoise.exe

Locating the Payload — IDA Segments

Loading the binary in IDA and examining the Segments view reveals the standard PE layout: .text, .data, .rdata, .bss, .idata, .CRT, .tls. The .rdata section spans 0x14000B000 to 0x14000C000 — virtual size 0xE80 (3712 bytes according to IDA’s section header comment). Navigating into .rdata reveals the expected CRT boilerplate strings early in the section, but cross-referencing the IFFT function (identified via the sin/cos import usage) leads to unk_1400090C0 in .data — the actual base address of the float payload array passed into the decryption routine.

The payload is stored as an array of complex floating-point pairs: each element is a real and imaginary component encoded as an 8-byte IEEE 754 double. This is the characteristic output of a Discrete Fourier Transform applied to the raw shellcode bytes offline before compilation. With 464 complex pairs at 16 bytes each, the total payload blob is 7424 bytes. No shellcode byte sequence exists anywhere in the binary — the payload is entirely in frequency-domain representation.

Decryption Routine — IFFT via sin/cos

Cross-referencing the sin and cos imports leads into the IFFT butterfly implementation at sub_1400080B0. The routine consumes the complex float pairs and applies the Inverse Discrete Fourier Transform to reconstruct the original shellcode bytes in memory.

The IFFT requires 2π as its twiddle factor constant — loaded from qword_14000B020 (401921FB54442D18h = 6.283185…). This is a mathematical requirement of the transform, not the decryption key. The actual decryption key is a separate hardcoded value: 0.12345, embedded as the first element of the payload array at qword_14000ADD0 and loaded into XMM0 at the start of the decryption routine.

The x64dbg status bar confirms the load directly:

qword ptr ds:[frequencynoise.00007FF707EAADD0]=0.12345

Show Image

The value 0.12345 is arbitrary — chosen for memorability rather than mathematical significance. Without it, the IFFT produces garbage rather than valid shellcode. The author embedded the key inside position zero of the blob itself rather than storing it as a standalone constant, making it easy to miss during static analysis.

Memory Allocation and Execution

After the IFFT completes, sub_140008250 calls VirtualAlloc with PAGE_EXECUTE_READWRITE (0x40) to allocate a writable, executable region for the restored shellcode.

Rather than calling the shellcode via a direct function pointer cast — a well-known EDR detection heuristic — the binary passes the shellcode address as the callback parameter to EnumDesktopsA. The Windows API invokes it indirectly as a DESKTOPENUMPROCA callback, executing the shellcode through a legitimate system call. The call stack captured at runtime confirms this:

return to user32.EnumDesktopsW+16E from ???

Shellcode Analysis — C2 Extraction

With the binary running and execution caught via x64dbg, the Memory Map reveals the shellcode allocated at 0x00000295D9E50000. Following that region in the dump confirms the classic 64-bit Meterpreter prologue:

FC 48 83 E4 F0 E8 C0 00 00 00 41 51 42 50 52 51 56 48 31 D2

Scrolling through the dump surfaces ws2_32 embedded as a plaintext string in the shellcode — loaded dynamically at runtime via LoadLibrary rather than through the PE’s IAT, keeping network capability invisible to static import analysis.

Monitoring the outbound connection from the shellcode’s process via PowerShell confirms the C2 callback destination:

while($true) {
    Get-NetTCPConnection | Where-Object {$_.OwningProcess -eq 3920} |
    Select RemoteAddress, RemotePort, State
    Start-Sleep 1
}

The shellcode repeatedly attempts SynSent connections to 13.42.41.147:13337 — a Meterpreter staging port — confirming the payload and C2 infrastructure.

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

DFT obfuscation evades all byte-pattern detection. Traditional YARA signatures and AV engines match against known shellcode byte sequences. Shellcode stored as frequency-domain floating-point data has zero resemblance to its plaintext form — the stored payload is mathematically valid IEEE 754 doubles with no shellcode characteristics. Behavioural detection on memory allocation and execution patterns is the only reliable catch at this layer.

Trigonometric imports alongside memory allocation APIs are a detection opportunity. A PE binary importing sin and cos from the CRT math library alongside VirtualAlloc and a callback-capable Windows API is an anomalous combination. This import profile can be expressed as a static detection rule — legitimate software using trigonometric functions rarely also allocates and executes arbitrary memory regions.

Callback-based execution bypasses direct call heuristics. EDR hooks that flag code casting a VirtualAlloc‘d pointer directly to a function pointer miss indirect execution via Windows callback APIs like EnumDesktopsA. Detection coverage should extend to monitoring which APIs are passed user-allocated memory addresses as callback parameters.

PAGE_EXECUTE_READWRITE remains a strong behavioural signal. A single VirtualAlloc call requesting read, write, and execute permissions simultaneously is rarely required by legitimate software. A policy flagging or blocking RWX allocations — with exceptions for known JIT runtimes — intercepts this execution chain before the shellcode runs.

Runtime DLL loading hides network intent from static analysis. Loading ws2_32 dynamically via LoadLibrary at runtime rather than through the PE’s IAT means network capability is invisible to import table inspection. Monitoring LoadLibrary calls for networking DLLs from processes with no legitimate network function is an effective complement to static scanning.