Multi Binary Correlation

Shared Crypto Key Patterns

If two binaries share the same RC4 KSA initialization, AES key bytes, or XOR key pattern, this is strong evidence they are from the same codebase or developer:

• Extract the key material from each binary independently
• Compare byte-for-byte — even a partial match (e.g., first 8 bytes) is significant
• Document the match in findings as a separate correlation finding

Loader/Payload Relationships

A common pattern: binary A (loader) spawns binary B (payload) via:

• CreateProcess / ShellExecute with the second binary's path as a string argument
• Dropping binary B to %TEMP% and loading it
• Loading binary B as a DLL via LoadLibrary

Indicators:

• Binary A has CreateProcess or WriteFile + CreateThread imports
• Binary A contains a string matching binary B's name or path
• Binary B has very few imports (was designed to be loaded, not run standalone)

Reporting Multi-Binary Correlation Findings

{
  "finding_type": "behavior",
  "address": "N/A",
  "name": "cross_binary_correlation",
  "description": "Binary A (loader.exe) contains string 'payload.dll' and CreateProcess import matching binary B (payload.dll) which has only 3 imports consistent with injection target",
  "raw_evidence": "<relevant strings/imports output>",
  "confidence": "high"
}

Analysis Prioritization

When multiple binaries exist and time is limited, prioritize in this order:

1. The binary the user's objective names explicitly
2. Binaries with fewer imports (more likely to be packed payloads worth unpacking)
3. Binaries with recognizable names (e.g., matching filenames found as strings in other binaries)
4. DLLs (usually more interesting exports than executables)
5. Remaining binaries (basic triage only)