Understanding How Attackers Hide Malware in “Legitimate” Software: A Technical Deep Dive

The Story Begins: Curiosity About Malware

After reading about WannaCry. Everyone talks about the vulnerabilities it exploited EternalBlue, SMB flaws, and so on. But what intrigued me more was how malware actually hides itself.

How do attackers make malicious code appear like normal software? How do they ensure it runs without raising suspicion?

This is the essence of a Trojan a program that appears legitimate but carries hidden payloads. Understanding this behavior is crucial for anyone serious about cybersecurity, because defense starts with understanding offense.

So I decided to explore this concept in a controlled, ethical, educational project: building my own Binary Binder.

2. The Educational Goal

The goal was to understand the mechanics behind Trojan-style delivery.

I wanted to simulate, in a safe environment, what happens when:

• One executable carries another inside itself
• The hidden program runs after the visible program starts
• Execution flow is orchestrated without breaking the OS or raising errors

Essentially, the binder merges two executables into one while keeping everything functional.

3. How the Binder Works (Technical Overview)

Imagine a single file that looks like one program but secretly carries two executables. That’s exactly what I built.

The final merged file structure:

[ Python runtime stub - visible program ]
#--MAGIC_DELIMITER--
[ Hidden binary 1 ]
#--MAGIC_DELIMITER--
[ Hidden binary 2 ]

The Runtime Stub

The stub is the “face” of the program, what the user sees and executes. Its responsibilities:

1. Open itself in binary mode
2. Locate the delimiters separating embedded payloads
3. Extract the hidden binaries to a temporary directory
4. Execute them sequentially
5. Clean up any temporary files

In code:

with open(sys.argv[0], 'rb') as f:
    data = f.read()
parts = data.split(MAGIC_DELIMITER)

This is the core idea behind Trojan-style payload delivery: the visible program orchestrates hidden behavior.

Why This Matters: Python Parsing Challenges

Python parses its entire source file before executing it.

If you simply append raw binary:

--binary bytes--

Python throws a SyntaxError because it tries to interpret non-Python bytes.

To solve this:

• I used a structured delimiter (byte-safe, unlikely to appear in payload)
• Terminated Python execution immediately after the stub runs with os._exit(0)
• Ensured binaries were executed from a temporary directory, avoiding filesystem clutter

This mirrors how malware safely unpacks payloads without alerting users or corrupting execution.

4. Entry Point Management

Every executable has an entry point the memory address where execution begins.

In my binder:

• The stub becomes the entry point
• It controls the execution flow: first hidden binary, then second
• This is conceptually similar to how droppers redirect flow in multi-stage malware

Understanding entry points is crucial for:

• Reverse engineering
• Malware detection
• Safe software packaging

5. Temporary Execution Environment

with tempfile.TemporaryDirectory() as temp_dir:
    subprocess.run(["python3", bin1_path])

Why temporary directories?

• Reduces artifacts on disk
• Mimics ephemeral malware staging
• Avoids overwriting critical system files

Security analysts often monitor these behaviors:

• Short-lived binaries
• Self-extracting payloads
• Unexpected child processes

Building this myself gave me insight into how such behaviors appear in the wild, and how defenders detect them.

6. Permissions and Execution

os.chmod(bin1_path, 0o755)

Linux binaries need execute permissions.

Understanding file permissions is fundamental for:

• Secure deployment
• Exploit prevention
• Safe sandboxing

7. Educational Takeaways

By building this binder, I gained hands-on experience with:

• Byte-level file manipulation
• Execution flow orchestration
• Self-referential loading (program reads itself)
• Process spawning and temporary environments
• Entry point management in executables
• Practical understanding of Trojan-style behavior

From a cybersecurity perspective:

To detect or defend against malware effectively, you need to understand how attackers design it.

This project allowed me to experience the offensive mechanics safely, which strengthens my ability to design defensive strategies.

8. Ethical and Security Considerations

It’s important to note:

• This binder is educational and does not contain malicious payloads
• Never embed real malware or execute code on unauthorized systems
• Responsible understanding of offensive techniques is critical to cybersecurity careers

9. Future Extensions

For deeper learning:

• Merge actual ELF binaries at the header level
• Add support for Windows PE format
• Allow execution order control for hidden payloads
• Implement payload encryption and integrity verification

These extensions simulate real-world malware techniques, giving insight into detection and prevention.

Through this project, I explored:

• How attackers hide functionality in “legitimate” software (Trojan-style)
• How execution flow can be redirected safely
• How binary structure and runtime environment affect detection

Project & Case Study

Full code, implementation details, and technical write-up:
GitHub Repository