let's make malware but it might get caught so the malware gets worse

Let's Make Malware But It Might Get Caught So The Malware Gets Worse

Speakers: Alex, Founder, mangopdf Communication

Conference: Kawaiicon

YouTube: https://www.youtube.com/watch?v=chRwYJcvX3Y

Overview

In this insightful Kawaiicon talk, "Let's Make Malware But It Might Get Caught So The Malware Gets Worse," Alex, founder of mangopdf Communication and a seasoned red teamer, demystifies the iterative process of developing and refining malware for stealth, persistence, and evasion. Moving beyond the basics of initial compromise, Alex meticulously dissects the techniques attackers employ to ensure their malicious implants remain undetected and fully operational within a target environment, even in the face of sophisticated defensive measures.

The presentation serves as a practical guide to understanding the mindset and methodologies of advanced adversaries. By demonstrating how a simple, easily detectable piece of malware can be "made worse" – meaning, made more effective and resilient against detection – Alex provides invaluable insights for both aspiring red teamers and cybersecurity defenders. The talk highlights the critical importance of operational security (OpSec) for attackers and, by extension, the blind spots that defenders often overlook.

This article delves into the technical intricacies discussed by Alex, covering everything from establishing command and control (C2) to advanced persistence mechanisms, infrastructure design for attribution evasion, and targeted payload delivery. It underscores why understanding these offensive tactics is paramount for developing robust, adaptive defensive strategies in today's threat landscape.

Background

▶ Watch: Speaker introduction and red teaming definition (0:00)

Alex begins by defining malware not as inherently "bad software," but as remote control software that grants an attacker SSH-like access to a victim's computer. This fundamental concept underpins the entire talk: the goal is to establish and maintain control over a remote system. The primary motivations for using such malware, as outlined, are twofold:

1. Bypassing Multi-Factor Authentication (MFA): Instead of attempting to crack or phish MFA credentials directly, attackers can steal browser cookies from a compromised workstation. By uploading these cookies to their own machine, they can effectively impersonate the victim's authenticated session, bypassing MFA requirements entirely for web applications.
2. Circumventing Network Controls (VPNs, Zero Trust): Modern network security models like VPNs and Zero Trust architectures enforce strict authentication and device posture checks before granting access to internal resources. However, if an attacker can execute code on a machine already authenticated to the network (e.g., a corporate laptop), they can proxy their traffic through that compromised machine. This allows them to bypass external network controls and access internal resources as if they were the legitimate user from an authorized device.

Initial attempts at creating malware, such as simply exfiltrating SSH keys or attempting direct SSH connections to a victim's machine, are quickly dismissed as impractical or easily detectable. The core problem identified is the lack of a reliable, covert channel for command execution and data exfiltration. This leads to the introduction of the Command and Control (C2) server architecture. In this model, the malware on the victim's machine initiates an outbound connection to a C2 server, requesting commands. The attacker, in turn, connects to the C2 server to issue commands and receive results from the compromised host. This architecture is the foundational element for most sophisticated malware operations.

Key Findings

▶ Watch: Command and Control (C2) server architecture (6:10)

The central premise of Alex's talk is that effective malware is not a static binary, but a continuously refined and obfuscated system designed to defeat detection at multiple layers. The key findings revolve around an iterative process of "making malware worse" by addressing common defensive blind spots:

• C2 as the Backbone: The Command and Control (C2) server is the essential component for remote interaction, enabling attackers to issue commands and receive data from compromised endpoints. Tools like Sliver are readily available to generate C2 implants.
• Operational Security (OpSec) for Persistence: Simple execution is insufficient. Malware must achieve persistence (surviving reboots and user actions) and operate stealthily (avoiding console output, detaching from parent processes) to maintain long-term access.
• Evasion through Infrastructure: Direct C2 connections are risky. Employing redirector infrastructure with legitimate-looking domains and offshore hosting significantly raises the bar for detection and attribution, compartmentalizing compromises.
• Polymorphism and Targeted Delivery: Generating unique malware binaries for each target (or group of targets) prevents hash-based detection. Further, staged payloads with authentication mechanisms (like specific HTTP user agents) ensure that only intended targets receive the actual malicious code, protecting the core implant from analysis by security researchers or automated systems.
• The "Burn It Down" Philosophy: Each layer of an attacker's infrastructure and malware is designed to be disposable. If a component is detected, it can be "burned" (taken down), while other parts of the operation remain intact, minimizing impact and slowing down incident response.

Technical Deep Dive

▶ Watch: Making malware persist across reboots (11:00)

The talk provides a granular walkthrough of technical techniques, progressing from basic malware execution to advanced evasion and persistence.

Command and Control (C2) Architecture

The fundamental C2 model involves three components:

1. The attacker's machine.
2. The C2 server (e.g., crimecentral.com).
3. The malware running on the victim's machine.

The malware initiates a connection to the C2 server ("Hello, what should I do?"), receives commands ("Execute this command"), executes them, and sends back results ("Here's the result"). The attacker then connects to the C2 server to interact with the compromised endpoint. This architecture sidesteps issues with direct inbound connections (like public SSH servers) to victim machines.

Malware Generation

Alex highlights that attackers don't always write malware from scratch. Open-source frameworks like Sliver (frequently used by red teamers, but also adopted by some criminals) allow for easy generation of custom implants. The process is command-line driven:

This command generates a Windows executable that uses the HTTPS protocol to communicate with the specified C2 domain. The resulting binary is a fully functional piece of malware, ready for deployment.

Initial Execution and Evasion

The "hard part" of malware deployment is often social engineering to achieve initial execution. Alex humorously notes that "social engineering isn't that hard," implying that a well-crafted phishing email or deceptive download link often suffices. Once executed, the immediate challenge is to keep the malware running discreetly.

1. Backgrounding: Simply running a command with & (e.g., ./malware &) backgrounds the process, returning control of the terminal to the user. However, if the user closes the terminal, the child process (malware) is also terminated.
2. Disowning: To detach the malware process from its parent shell, the disown command is used (e.g., ./malware & disown). This makes the operating system treat the malware as an independent process, allowing it to persist even if the parent terminal is closed.
3. Suppressing Output: Malware should not print anything to the console, as this immediately alerts the user. This is achieved by redirecting standard input (stdin), standard output (stdout), and standard error (stderr) to /dev/null:

This ensures no messages are displayed, and the process runs silently in the background.

Persistence Mechanisms

Ensuring malware survives system reboots is crucial for long-term access. Alex demonstrates a common persistence technique: modifying user-specific startup scripts.

1. ~/.zprofile (or ~/.bashrc, ~/.zshrc): These shell initialization files are executed when a user logs in. A simple approach is to embed the malware execution command directly into ~/.zprofile.
2. Hiding within Legitimate Scripts: To make this less obvious, attackers can hide their persistence mechanism within scripts that are themselves loaded by legitimate applications. Alex uses NVM (Node Version Manager) as an example. NVM often adds a line to ~/.zprofile that sources another script, nvm.sh. An attacker could modify nvm.sh to include the malware execution command, making it significantly harder for a casual user or even some security tools to spot the malicious entry. This technique leverages the trust placed in common development tools.

Redirector Infrastructure

A direct connection from malware to a single, dedicated C2 server (crimecentral.com) is a major operational security risk. If detected, the C2 domain is burned, and all compromised hosts connected to it are immediately identified. The solution is redirector infrastructure:

1. Intermediate Servers: Instead of direct connections, malware connects to a redirector server (e.g., legitsoftwareupdate.com). This redirector then uses an HTTP reverse proxy (e.g., Nginx, Apache) to forward traffic to the actual C2 server.
2. Legitimate-Looking Domains: Redirectors use benign domain names to blend in with normal network traffic.
3. Offshore Hosting: Hosting redirectors on offshore, DMCA-ignored hosting providers (like "Alex host," humorously mentioned by the speaker) makes takedowns and attribution significantly more challenging for law enforcement and incident responders.
4. Scalability and Redundancy: Attackers can deploy numerous redirectors, each with a unique domain and IP. If one redirector is detected and taken down by incident response, the other compromised hosts (connecting to different redirectors) remain undiscovered and operational, preserving the overall campaign.

Polymorphic Malware and Staged Payloads

Even with redirectors, if all malware binaries are identical (same hash), detecting one allows for easy identification of all others.

1. Polymorphism: To combat hash-based detection, attackers generate multiple unique copies of the malware binary. A simple way to achieve this is to embed a different redirector domain name into each binary during generation. This results in different file hashes, making it harder for defenders to use static signatures across an entire network.
2. Staged Payloads: The ultimate goal is to prevent unwanted analysis of the malware itself. Instead of directly hosting the final malware binary on a public server (e.g., GitHub), attackers use a staged payload design:

• Stage 1: Malware Downloader: The initial social engineering delivers a small, benign-looking malware downloader (the "first stage"). This downloader is less likely to be immediately flagged as malicious.
• Stage 2: Malware Hosting Server: The downloader then contacts a malware hosting server (distinct from the C2 server) to retrieve the actual, full-featured malware binary (the "second stage").
• User-Agent Authentication: Critically, the malware hosting server can be configured to serve the actual malware only if the downloader sends a specific, secret HTTP user agent. Alex provides an example: Python-requests/2.3.1 – a version of the Python requests library that doesn't actually exist. This acts as a hidden "password." If a security researcher or automated scanner requests the malware without this specific user agent, they might receive a legitimate, un-backdoored application (e.g., a real VPN client) or a benign file, thus protecting the actual malware binary from analysis and preventing its "burn." This ensures only the intended target receives the malicious payload.

Alex concludes by acknowledging that even with these sophisticated techniques, further advancements in obfuscation, in-memory execution, and complex C2 channels (e.g., through legitimate services like Cloudflare) exist, highlighting the continuous arms race between attackers and defenders.

Demo / Proof of Concept

▶ Watch: Preventing malware fingerprinting and attribution (15:00)

While the talk did not feature a live, interactive demonstration of malware deployment on a victim's machine, Alex effectively walked the audience through the conceptual steps and command-line examples for each stage of malware creation, deployment, and evasion. He showcased specific commands for generating malware using tools like Sliver, illustrated shell commands for backgrounding and disowning processes (&, disown), and demonstrated how standard input/output redirection (</dev/null >/dev/null 2>&1) works. This illustrative approach, combined with clear architectural diagrams, served as a comprehensive conceptual proof-of-concept for the techniques discussed.

Defensive Implications

▶ Watch: Advanced evasion: staged payloads and user-agent filtering (16:30)

Understanding the evolving tactics presented in this talk is crucial for defenders to build resilient security architectures.

1. Enhanced Endpoint Detection and Response (EDR): Defenders must move beyond simple signature-based detection. EDR solutions should monitor for:

• Unusual Process Behavior: Processes running without a controlling terminal (TTY), processes that have been disowned, or processes with unusual parent-child relationships.
• Persistence Mechanisms: Scrutinize modifications to user shell profiles (.bashrc, .zprofile, .zshrc), especially within nested scripts like nvm.sh. Behavioral analysis can flag unusual writes to these critical files.
• In-Memory Execution: While not deeply covered, the mention of in-memory execution implies that defenders need EDR capabilities that can detect and analyze code running directly in memory, not just on disk.

1. Advanced Network Monitoring:

• C2 Traffic Analysis: Look for anomalous outbound connections, even over common protocols like HTTPS. Deep packet inspection and behavioral analysis can identify suspicious patterns that might indicate C2 activity, even when proxied.
• User-Agent Analysis: While attackers can spoof user agents, monitoring for highly unusual or non-standard user agents (like Python-requests/2.3.1) in outbound HTTP requests could flag potential staged payload attempts.
• Domain Reputation: While redirectors use legitimate-looking domains, continuous monitoring of newly registered domains or those with rapidly changing IP addresses can help identify potential C2 infrastructure.

1. Proactive Threat Intelligence: Stay informed about common red team tools (e.g., Sliver, Cobalt Strike, Metasploit) and their typical configurations, communication patterns, and default implants. This knowledge helps in tuning detection rules.
2. Strengthening Initial Access Vectors: Social engineering remains a primary vector. Continuous security awareness training for employees, robust email filtering, and browser security best practices (e.g., preventing credential dumping, managing cookies) are vital.
3. Zero Trust Beyond Network Edges: The ability for malware to bypass VPNs and Zero Trust proxies by operating from an already compromised endpoint emphasizes that Zero Trust principles must extend to the endpoint itself. Strict application whitelisting, least privilege, and continuous device posture checks on endpoints are essential.
4. Incident Response Planning: The use of redirectors and polymorphic malware means that discovering one compromised host or C2 component does not necessarily reveal the entire attack campaign. Incident response teams need to be prepared for compartmentalized and resilient adversary infrastructure, focusing on rapid containment, forensic analysis, and hunting for related indicators across the enterprise.
5. Supply Chain and Development Tool Security: Be wary of seemingly legitimate scripts or software from third parties that could be leveraged for persistence or backdoors, as demonstrated with nvm.sh. Regular auditing of development environments and tools is recommended.

Key Takeaways

• Malware is an Evolving System: Effective malware is not just a binary; it's a dynamic system designed for stealth, persistence, and resilience against detection, continuously "made worse" to evade defenses.
• C2 and Redirector Infrastructure are Critical: Attackers rely on Command and Control (C2) servers and complex redirector networks to maintain access, obfuscate their true location, and compartmentalize operations, making attribution and takedowns difficult.
• Persistence Requires Creativity: Beyond basic startup items, attackers embed persistence mechanisms within legitimate scripts or system components (e.g., nvm.sh within ~/.zprofile) to ensure malware survives reboots and user actions.
• Targeted Delivery and Polymorphism are Standard: Staged payloads with authentication (like hidden user agents) ensure malware is delivered only to intended targets, while generating unique binaries prevents widespread detection via simple hash matching.
• Defenders Must Anticipate Adversary OpSec: Understanding how attackers protect their operations (e.g., offshore hosting, disposable infrastructure) is key to developing proactive and adaptive defensive strategies that go beyond signature-based detection.
• Endpoint Security is Paramount: Given the ability of malware to bypass network-level controls (VPNs, Zero Trust) from a compromised host, robust endpoint detection, behavioral analysis, and least privilege principles are more critical than ever.

About the Speaker(s)

Alex, who goes by the unique moniker "Alex in double quotes" due to previous journalistic references, is a prominent figure in the cybersecurity community. He is the founder of mangopdf Communication, a venture dedicated to teaching technical experts, including hackers, how to communicate effectively with non-technical audiences. With a professional background deeply rooted in red teaming at organizations like Atlassian, Alex possesses firsthand experience in simulating real-world criminal attacks against corporate environments. He is also an organizer of purplecon, a conference focused on bridging the gap between offensive and defensive security disciplines. His talk draws heavily from his practical experience in understanding and demonstrating sophisticated attacker methodologies.