Stack String Obfuscation in C: The Technique That Blinds AV, YARA, and Static Scanners

A SANS Internet Storm Center diary entry published this morning by senior handler Xavier Mertens demonstrates how to implement stack string obfuscation (a malware technique for hiding strings from static analysis tools) directly in C — no hand-crafted shellcode required. The write-up bridges the gap between offensive implant development and defensive malware analysis, showing both how red teamers conceal command-and-control URLs inside a Windows binary and how blue teams can recover them without specialized tooling.

// 01 Stack String Obfuscation: Technical Details

A stack string is a string that is never stored as a contiguous sequence of printable characters anywhere in a compiled binary's static data sections. Instead of declaring char *url = "http://c2.evil.com/beacon"; — which leaves the URL sitting in plain text in the binary's .data or .rdata section — the developer builds the string one byte at a time on the call stack at runtime.

The compiled result looks like this in x86 assembly:

sub  esp, 30
mov  byte ptr [esp + 0],  0x68   ; 'h'
mov  byte ptr [esp + 1],  0x74   ; 't'
mov  byte ptr [esp + 2],  0x74   ; 't'
mov  byte ptr [esp + 3],  0x70   ; 'p'
mov  byte ptr [esp + 4],  0x3a   ; ':'
; ... 25 more individual assignments

In C, that same construction looks like this:

void fetch_beacon(void) {
    char url[30];
    url[0]  = 0x68;  url[1]  = 0x74;  url[2]  = 0x74;
    url[3]  = 0x70;  url[4]  = 0x3a;  url[5]  = 0x2f;
    url[6]  = 0x2f;  /* ... continues for all 30 bytes */
    url[29] = 0x00;
    send_beacon(url);
    memset(url, 0, sizeof(url));  /* wipe from memory after use */
}

The memset call at the end is an operational security measure: it zeroes out the stack memory immediately after use, reducing the chance that a memory dump captured after execution preserves the reconstructed string as a forensic artifact.

The key consequence: run the strings utility against this binary, use pestr, or feed it through a signature-based antivirus scanner, and the C2 URL simply does not appear. It exists only at runtime, briefly, during execution of that function. No static string table entry, no .rdata reference — nothing for a pattern-matching tool to find.

// 02 Why Static Analysis Fails Against Stack Strings

Static analysis tools — including strings (standard Linux/macOS utility), pestr, and BinText — scan the binary for contiguous sequences of printable ASCII or Unicode characters above a minimum length threshold (typically 4–6 characters). Because each character of a stack string is stored as a single byte inside an instruction operand, no contiguous printable sequence ever forms in the binary's data.

YARA rules (the dominant format for writing malware detection signatures) face the same limitation when written to match plaintext string content. A rule looking for "http://c2.evil.com" has nothing to match. Defenders who rely solely on string-based YARA rules will miss any malware family that implements even basic stack string obfuscation.

The technique also defeats import table analysis when applied to Windows API names. Malware that constructs strings like "LoadLibraryA", "VirtualAlloc", or "WriteProcessMemory" on the stack — then resolves them using GetProcAddress at runtime — can present an essentially empty import table to security tools that flag suspicious API usage. The binary imports only one or two innocuous functions; everything else is resolved dynamically from stack-constructed names.

// 03 Malware in the Wild: Who Uses Stack Strings

Stack string obfuscation is not a theoretical technique. It appears in some of the most widely analysed malware families of the last decade:

• Cobalt Strike — The commercial red team framework (frequently pirated by threat actors) obfuscates API names and configuration strings including C2 server addresses using stack construction. Post-exploitation beacon payloads have been documented using this technique to defeat static detection at the loader stage.
• Emotet — The banking trojan turned loader and botnet used stack-string-based obfuscation in its loader components during its peak activity period. Emotet frequently delivered Cobalt Strike as a second-stage payload, compounding the detection challenge.
• AgentTesla — The commodity infostealer (information-stealing malware sold as malware-as-a-service) uses string obfuscation as a documented characteristic of its evasion profile across multiple versions.
• TrickBot, Dridex, and Qakbot — All three banking trojans-turned-loaders have documented use of string obfuscation including stack construction, contributing to their resilience against automated sandboxes and signature detection.

The technique is not limited to commodity malware. Red team tooling written for penetration testing engagements — whether custom implants or open-source frameworks — routinely implements stack strings to avoid triggering antivirus alerts during authorized assessments. The SANS SEC670 course ("Red Teaming Tools: Developing Windows Implants, Shellcode, Command and Control") explicitly covers stack string construction as part of teaching practitioners how to build functional implants that survive endpoint detection.

// 04 Detecting Stack Strings: Blue Team Playbook

Blue teams have several practical detection options, ranging from no-tooling-required scripts to automated analysis frameworks.

1. Manual recovery with objdump and grep

For a quick check on a suspect binary (with no specialist tools installed), this pipeline extracts and reassembles the hidden bytes:

objdump -D suspect.exe 
  | grep -oP 'movs+BYTE PTR [[^]]+],s*0xK[0-9a-fA-F]{1,2}' 
  | while read hex; do printf "\x$hex"; done

This disassembles the binary, matches the pattern of sequential mov BYTE PTR [offset], 0xXX instructions that characterise stack string construction, extracts the hex values, and prints the resulting characters. No additional dependencies required beyond standard binutils and GNU grep.

2. FLOSS — FLARE Obfuscated String Solver

FLOSS (maintained by the Mandiant FLARE team, now part of Google Cloud) is the purpose-built solution for this exact problem. It performs emulation-based string recovery across three categories:

• Static strings — same as the strings utility, baseline output
• Stack strings — identifies sequences of character-by-character stack assignments and reconstructs the string without executing the binary
• Decoded strings — recovers XOR-encoded, Base64-encoded, and other algorithmically obfuscated strings by emulating decryption routines

FLOSS version 2.0 significantly improved stack string detection accuracy. Running it against a malware sample is a routine step in SANS FOR610 (Reverse-Engineering Malware: Malware Analysis Tools and Techniques) and FOR710 (Reverse-Engineering Malware: Advanced Code Analysis) lab exercises.

floss suspect.exe

Output separates the three string categories, making it immediately clear which strings were recovered through emulation versus static extraction.

3. Behavioural YARA rules

Rather than matching string content — which won't appear — analysts write YARA rules targeting the structural pattern of stack string construction: a high count of consecutive mov byte instructions targeting stack-relative addresses within a small offset range. This is a strong behavioural indicator distinct from the string content itself.

4. Dynamic sandbox analysis

Because stack strings exist only in memory during execution, detonating the sample in an instrumented sandbox with memory capture (Cuckoo Sandbox, ANY.RUN, Cape Sandbox) remains the highest-confidence detection method. Memory scanning after execution will reveal the reconstructed strings at the stack frame addresses where they were built.

// 05 What You Should Do Right Now

• Add FLOSS to your malware triage workflow. Download the latest release from the FLOSS GitHub repository and run it as a standard step before or after strings on every unknown binary. The output difference on samples using stack strings is immediate and significant.
• Audit your YARA ruleset. Rules that rely exclusively on plaintext string matching will miss stack-obfuscated samples. Supplement content-matching rules with structural rules that flag high-density mov byte patterns.
• Ensure sandbox pipelines capture memory. String-only static analysis is insufficient for this class of obfuscation. If your sandbox configuration does not include memory dump analysis, enable it for samples flagged as suspicious.
• If you are a red teamer or developer, understand detection before using evasion. Tools like FLOSS exist specifically because defenders encountered this technique in real malware repeatedly. Understanding how detection works informs better implant design — and helps you validate that your technique actually evades the specific controls in your target environment.
• Consider SANS FOR610 or FOR710 for analyst training. Both courses include hands-on work with obfuscated malware samples including stack strings. FOR610 covers the fundamentals; FOR710 covers advanced code analysis and automation of deobfuscation at scale.
• Log abnormal process behavior, not just string signatures. Processes that call GetProcAddress with dynamically constructed function names produce anomalous call patterns that EDR (Endpoint Detection and Response — security software that monitors and records endpoint activity for threat detection) tools can detect behaviorally even when static signatures miss the payload.

// 06 Background: Understanding the Evasion Landscape

Stack strings represent one technique within a broader category of string obfuscation that has evolved alongside antivirus detection for decades. The arms race follows a consistent pattern: defenders write signatures that match known-bad strings; attackers obfuscate those strings; defenders build tools to recover obfuscated strings; attackers layer additional obfuscation.

The current tier includes stack strings (character-by-character construction), XOR encoding (each byte XORed against a key), Base64 with custom alphabets, RC4 and AES encryption of string data, and combinations of the above. Each technique requires a different recovery approach, which is why tools like FLOSS implement multiple deobfuscation strategies rather than focusing on a single method.

From the offensive development perspective, the barrier to implementing stack strings in a high-level language like C is low — as the SANS ISC diary entry demonstrates, it is a mechanical transformation of a string literal into a series of byte assignments. Automated tools exist to perform this transformation at build time, eliminating the manual character-by-character work. The Cobalt Strike Artifact Kit, Donut, and various open-source shellcode loaders incorporate string obfuscation as a default option.

The SANS SEC670 course — which teaches practitioners to build functional Windows implants, shellcode, and command-and-control (C2) infrastructure for authorized red team engagements — explicitly covers these techniques because understanding how offensive tools work at the code level makes practitioners more effective at both building them and defending against them. The SANS FOR610 and FOR710 malware analysis courses approach the same techniques from the opposite direction: given a binary that uses stack strings, how do you recover the hidden content and understand the sample's behavior?

The dual-perspective approach modeled in the ISC diary entry — show the offensive construction, then show the defensive detection — reflects how mature security programs treat evasion research: not as purely attacker knowledge, but as context required to build effective defenses.

// 07 Conclusion

Stack string obfuscation is a low-complexity, high-payoff evasion technique used by real-world malware families including Cobalt Strike, Emotet, AgentTesla, and TrickBot, as well as legitimate red team tooling. The SANS ISC diary entry published today provides a clean C implementation alongside practical detection guidance using standard utilities and FLOSS. Security teams that rely on static string matching alone are blind to this class of obfuscation; adding FLOSS to your triage workflow and extending YARA rules to cover structural patterns closes that gap without requiring additional commercial tooling.