How Attackers Abuse mkdir to Hide Malware on Linux Servers

The mkdir Command in Linux: A SOC Analyst's Field Guide to Directory Creation, Malware Staging, and Incident Response

It's 2:44 AM and a SIEM alert fires on a mid-size fintech's production server. Nothing dramatic at first glance — just a shell history entry showing mkdir -p /tmp/.systemd/cache. No file deletions. No obvious exfiltration. Just... a folder being created. Twenty minutes later, that hidden directory is hosting a cryptominer binary and a persistence script that survives reboots. By the time the on-call analyst pulls the thread, the attacker has already pivoted to two other hosts using the same "quiet" technique: create a directory, hide it, stage the payload, blend in.

This is the uncomfortable truth every SOC analyst eventually learns — mkdir is one of the most boring, most overlooked commands in Linux, and that's exactly why attackers love it. It doesn't touch existing files. It doesn't trigger antivirus signatures. It doesn't look like an attack. It looks like a developer doing developer things. But in the hands of a threat actor, directory creation is step one of staging, persistence, and defense evasion.

In this guide, we're going to walk through every practical use of the mkdir command — the same syntax sysadmins use every day — and then flip the lens to show you exactly how red teamers, malware authors, and real-world attackers abuse it, and how blue teams detect and stop it. This isn't a textbook man-page rewrite. This is how mkdir actually shows up in incident response tickets.

Table of Contents

• What Is the mkdir Command and Why Should Security Teams Care?
• Core mkdir Commands Every Analyst Should Know
• Advanced and Scripting-Friendly mkdir Usage
• Real-World Attack Scenario: How mkdir Is Abused in the Wild
• Logs, Indicators, and What to Hunt For
• Detection and Prevention Strategies
• Expert Tips From the SOC Floor
• Related Reading
• FAQ
• Conclusion

What Is the mkdir Command and Why Should Security Teams Care?

mkdir ("make directory") is a core Linux/Unix utility used to create new folders on a filesystem. Every sysadmin, DevOps engineer, and developer uses it dozens of times a day. It's benign by design — which is exactly the problem from a security standpoint. Endpoint detection tools are tuned to flag suspicious binaries, unusual network beacons, and privilege escalation attempts. A simple directory creation rarely trips any alarm, which makes it a favorite low-noise building block in attacker playbooks, especially during the staging and persistence phases of the MITRE ATT&CK framework (T1074 - Data Staged, and supporting steps under T1053, T1547 for persistence).

Understanding mkdir from both a sysadmin and attacker perspective is a foundational skill for SOC analysts, threat hunters, and Linux security engineers working in enterprise environments across the US and globally.

Core mkdir Commands Every Analyst Should Know

Create a single directory:

mkdir myfolder

Creates a new folder named myfolder in the current working directory. Use this for quick, everyday folder creation. Expected output: no output on success; an error like File exists if the directory is already there.

Create multiple directories at once:

mkdir folder1 folder2

Creates several sibling directories in a single command — useful in setup scripts and automation pipelines.

Create nested directories:

mkdir -p dir1/dir2/dir3

The -p (parents) flag creates the entire directory tree in one shot, including any missing parent folders. This is the single most-used flag in real-world scripting — and, notably, the most common flag seen in malware staging scripts because it silently succeeds whether or not the path already exists.

Create a directory with an absolute path:

mkdir /home/user/newdir

Creates the directory at an exact filesystem location regardless of where you currently are. Analysts should treat absolute-path mkdir commands targeting system directories (/etc, /usr/lib, /var) as higher priority for review.

Create a directory using a relative path:

mkdir projects/demo

Path is resolved relative to the current shell location — common in developer workflows and CI/CD build steps.

Create parent directories automatically (long-form flag):

mkdir --parents project/src/bin

Functionally identical to -p. Long-form flags are more common in scripts written for readability or copied from documentation.

Set permissions while creating:

mkdir -m 755 secure_dir

Sets specific permission bits at creation time instead of relying on the default umask. From a defensive standpoint, watch for directories created with overly permissive modes like 777 — a classic sign of a dropped staging folder meant to be world-writable for follow-on payloads.

Advanced and Scripting-Friendly mkdir Usage

Create a hidden directory:

mkdir .config

Directories prefixed with a dot don't show up in a default ls listing. Legitimate config folders use this pattern constantly — but so does malware. Hidden directories like .X11-cache, .systemd, or .ssh-agent-tmp mimicking real system paths are a well-documented persistence trick in Linux cryptomining and botnet campaigns (including variants tracked in Kinsing and TeamTNT activity).

Brace expansion for multiple subdirectories:

mkdir project/{src,bin,docs}

Bash expands this into three separate mkdir calls behind the scenes. Great for scaffolding projects; also frequently used by attackers to rapidly build out a full staging directory structure in one line.

Numbered and lettered directories:

mkdir folder{1..10}
mkdir {A..Z}

Sequence expansion generates ranges instantly — folder1 through folder10, or A through Z. Useful for testing, sharding, or lab environments.

Date-based directory naming:

mkdir backup_$(date +%F)

Embeds the current date into the folder name via command substitution — standard practice for backup rotation scripts, log archiving, and automated reporting jobs.

Idempotent creation (only if it doesn't exist):

mkdir -p logs

Because -p suppresses the "already exists" error, this pattern is heavily used in automation and deployment scripts where the command may run repeatedly without failing the pipeline.

Create and immediately move into it:

mkdir project && cd project

A daily-driver combo for developers and pentesters alike setting up engagement folders quickly.

Create and verify in one line:

mkdir mydir && ls -ld mydir

Confirms creation and immediately displays ownership, permissions, and timestamps — a good habit for anyone hardening a server, since it lets you catch unexpected default permissions right away.

Full project scaffolding:

mkdir -p project/{frontend,backend,database}

Combines -p with brace expansion to build a multi-tier folder structure instantly — the same technique attackers use to stand up a full toolkit (loader, payload, config, logs) under one parent directory.

Directories with spaces:

mkdir "My Folder"
mkdir My\ Folder

Both quoting and escaping handle spaces correctly. Security note: filenames and directory names with unusual whitespace, non-printing Unicode characters, or right-to-left override characters are a known obfuscation technique to make malicious paths harder to read in terminal output or logs.

Home directory and temp directory creation:

mkdir ~/Documents/NewProject
mkdir /tmp/testdir

/tmp deserves special attention from a security lens — it's world-writable by default on most Linux distributions, has no execution restrictions unless explicitly mounted with noexec, and is one of the top three locations analysts find dropped malware, reverse shells, and staging directories in real incidents.

Real-World Attack Scenario: How mkdir Is Abused in the Wild

Here's a composite scenario built from patterns seen across real Linux cryptojacking and botnet incidents (Kinsing, TeamTNT, and various XMRig-based campaigns share this general playbook):

1. Attacker gains initial access via an exposed Docker API, weak SSH credentials, or an unpatched web app vulnerability.
2. First command executed is often something like mkdir -p /tmp/.hidden/.cache — nested, dotted, and buried three levels deep to survive casual review.
3. Payloads (miner binary, kill-script for competing malware, persistence cron job) are downloaded into that directory using curl or wget.
4. A cron job or systemd service is created referencing the hidden path to survive reboots.
5. The attacker sets permissive modes (chmod -R 777) on the staging directory so any user context can execute the payload.

None of these individual steps look catastrophic in isolation. That's the point. It's the sequence — directory creation, hidden naming, download, permission change, scheduled execution — that forms the real indicator of compromise.

Logs, Indicators, and What to Hunt For

If your organization has command-line auditing enabled (via auditd, osquery, Falco, or an EDR agent), here's what to actually hunt for:

• auditd rule example: monitor execve syscalls for mkdir under /tmp, /var/tmp, /dev/shm, and any dot-prefixed path.
• Suspicious pattern: mkdir immediately followed by curl/wget and a chmod +x within the same shell session or a short time window.
• Hidden nested paths: directories that mimic legitimate system names (.systemd, .ssh-tmp, .X0-lock-dir) but sit outside their normal system locations.
• Cron/systemd correlation: new directories referenced in /etc/cron.d/, user crontabs, or new .service files shortly after creation.
• Permission anomalies: newly created directories with 777 or SUID-adjacent permission changes.
• Parent process anomalies: mkdir spawned from a web server process (Apache, Nginx, Tomcat) rather than an interactive shell — a strong sign of a web shell driving filesystem changes.

Detection and Prevention Strategies

• Mount /tmp and /dev/shm with noexec, nosuid, nodev — this alone stops a huge percentage of "create-download-execute" staging chains cold.
• Enable command-line auditing with auditd or an EDR agent that logs full process trees, not just binary names.
• Baseline normal directory-creation behavior per host role — a database server creating hidden directories is far more anomalous than a CI/CD build agent doing the same.
• Alert on process-tree correlation, not single commands: mkdir → download utility → chmod → execution within a tight timeframe is a high-fidelity detection rule.
• Restrict web server process permissions so a compromised web app can't write outside its designated upload or webroot directories.
• Regularly audit cron jobs and systemd units for references to unfamiliar or hidden directory paths.
• Use file integrity monitoring (FIM) tools like AIDE, Wazuh, or Tripwire to flag new directories in sensitive system paths.

Expert Tips From the SOC Floor

• When triaging an alert, always check directory creation timestamps against user login times and known maintenance windows — mismatches are a fast way to spot after-hours attacker activity.
• Don't chase every hidden directory; dot-prefixed folders are extremely common and legitimate. Correlate with follow-on network activity or execution before escalating.
• Build a small watchlist of "high-risk" paths (/tmp, /dev/shm, /var/tmp, any world-writable mount) and treat mkdir events there as tier-1 priority, everywhere else as tier-3.
• In red team engagements, using predictable naming (project/{frontend,backend} style structures) for staging is a rookie mistake — real operators mimic existing naming conventions on the target host to blend in, and defenders should expect the same from skilled adversaries.

Related Cybersecurity Topics You Should Explore

• cd Command in Linux: Complete Guide for SOC & Incident Response
  
• pwd Command in Cybersecurity: What SOC Analysts Must Know
  
• ls Command in Cybersecurity: Full Guide for SOC Analysts
  
• Linux File & Directory Management Commands Explained (2026 Guide)
  
• Linux Filesystem Tree Explained: Critical Directories, Security Logs, and Threat Hunting Techniques
  
• What Is Linux? Why It Powers the Internet, Cybersecurity, and Modern Technology (2026)
  
• 120+ SOC & DFIR Tools Every Windows Server Incident Responder Needs in 2026

FAQ

Q: Is the mkdir command itself dangerous?
No. mkdir is a completely standard, safe Linux utility. The risk comes from how and where it's used, not the command itself.

Q: Why do attackers prefer /tmp for directory creation?
Because it's world-writable by default on most distributions and often lacks execution restrictions unless explicitly hardened with noexec.

Q: Can antivirus tools detect malicious mkdir usage?
Traditional signature-based antivirus generally can't, since mkdir itself isn't malicious. Behavioral EDR and command-line auditing tools are far more effective.

Q: What's the difference between mkdir -p and mkdir --parents?
Nothing functionally — they're the short and long forms of the same flag.

Q: Should I block hidden directory creation entirely?
No — too many legitimate applications rely on dot-prefixed config folders. Focus on behavioral correlation instead of blanket blocking.

Q: How can I audit mkdir commands on a production server?
Use auditd with an execve rule filtering for mkdir, or deploy an EDR/osquery solution that captures full process command lines.

Q: Is mounting /tmp with noexec enough to stop staging attacks?
It significantly raises the bar but isn't a silver bullet — attackers can still stage data or use interpreters already present on the system. Layer it with monitoring and least-privilege controls.

Conclusion

The mkdir command is proof that in cybersecurity, the smallest, most mundane actions deserve the same scrutiny as the loud, obvious ones. It's not a glamorous attack technique — there's no CVE number attached to "someone made a folder" — but it's a foundational building block in real intrusions happening on Linux servers across US enterprises and cloud environments every single day. Understanding the full syntax of mkdir gives sysadmins efficiency. Understanding how it's abused gives SOC analysts an edge. Master both, and you'll start seeing directory creation events the way an experienced incident responder does: not as noise, but as the first quiet clue in a much bigger story.