pwd Command in Cybersecurity: What SOC Analysts Must Know

This 'Harmless' Linux Command Reveals Hackers Every Time

It was 2:47 AM when a junior SOC analyst at a mid-sized fintech company noticed something odd in a shell history log pulled from a compromised jump box. Buried between reconnaissance commands and a suspicious curl request was a single, unassuming line: pwd. On its own, it looked harmless — almost too basic to matter. But in context, it told the analyst exactly what the attacker was doing: orientation. Before deploying a payload, before exfiltrating data, before pivoting deeper into the network, the intruder needed to know one thing first — where am I right now?

That's the story most people never hear about pwd. It's taught as a "Day 1" Linux command in every beginner tutorial, dismissed as trivial, and then completely ignored by security teams reviewing bash history and command-line logs. But in real-world incident response, penetration testing, and SOC operations, pwd shows up constantly — not because it's dangerous, but because it's diagnostic. It tells you what an attacker (or a defender) was thinking at that exact moment.

This guide breaks down the pwd command from a practical cybersecurity lens: how it works, how attackers actually use it during post-exploitation, how SOC analysts should read it in logs, and how you can use it yourself during investigations, scripting, and forensic file navigation.

Table of Contents

• What Is the pwd Command?
• Why Attackers Use pwd During Post-Exploitation
• Real-World Scenario: A Reverse Shell Walkthrough
• pwd Commands Every Analyst Should Know
• Reading pwd in Logs and Shell History
• Detection and Prevention Techniques
• Expert Tips From the Field
• Related Reading
• FAQ
• Conclusion

What Is the pwd Command?

pwd stands for print working directory. It's a core Unix/Linux shell built-in that outputs the absolute path of the directory you're currently sitting in. Every SOC analyst, penetration tester, DevSecOps engineer, and system administrator uses it dozens of times a day, often without thinking about it — which is exactly why it's so revealing when you look at it through a security lens instead of a sysadmin one.

Think of it as the "You Are Here" marker on a map. In a live terminal session, that might just be convenience. In a forensic timeline reconstruction or an EDR-captured command sequence, it's a breadcrumb that tells you an operator — legitimate or malicious — was actively assessing their position before taking the next step.

Why Attackers Use pwd During Post-Exploitation?

Once an attacker gains shell access — whether through a web shell, a reverse shell from a phishing payload, or a compromised SSH key — they rarely know exactly where they landed. Web application exploits, in particular, often drop an attacker into unpredictable directories depending on the vulnerable service (Apache, Tomcat, Node.js, a CMS plugin, etc.).

This is where pwd becomes part of the standard post-exploitation checklist, right alongside whoami, id, uname -a, and hostname. It's one of the first commands attackers run because it answers a foundational question before privilege escalation or lateral movement can even be planned: am I in a web root, a home directory, a temp folder, or a system path?

Security researchers who analyze attacker tradecraft — including patterns documented in frameworks like MITRE ATT&CK under discovery techniques such as System Owner/User Discovery and File and Directory Discovery — consistently see this orientation phase appear within the first few commands of a session. It's low-noise, doesn't touch any files, and gives the attacker critical context almost instantly.

Real-World Scenario: A Reverse Shell Walkthrough

Picture a typical incident: an attacker exploits an outdated file-upload vulnerability on a company's customer portal and drops a PHP web shell. Minutes later, they escalate to a full reverse shell using netcat. The first few commands typed into that new shell often look like this:

pwd
whoami
id
ls -la

That single pwd tells the attacker whether they've landed in /var/www/html/uploads, a low-privilege web directory, or something juicier like a shared application path with write access to configuration files. From there, they decide their next move — search for database credentials, look for writable cron directories, or attempt to escalate privileges.

For a defender doing incident response afterward, seeing pwd as the very first command in a suspicious session is a strong signal that you're looking at the true start of an intrusion, not a mid-session snippet. That timing detail matters when you're building a timeline for a breach report or a legal disclosure.

pwd Commands Every Analyst Should Know

Beyond the basic usage, there are several variations of pwd and related directory commands that show up constantly in both offensive and defensive work — from writing incident response scripts to hunting through a compromised host.

1. Basic Usage

pwd

What it does: Prints the full absolute path of the current working directory.
When to use it: Anytime you need to confirm your exact location before running a destructive command, a forensic copy operation, or a script that depends on relative paths.
Expected output: Something like /home/analyst/investigation or /var/www/html.

2. Logical Path

pwd -L

What it does: Displays the logical path, preserving any symbolic links in the chain rather than resolving them.
When to use it: When you want to see the path exactly as it was navigated, which is useful when investigating how an attacker moved through symlinked directories (a common technique to obscure the real file location).
Expected output: The path including the symlink name, not the target it points to.

3. Physical Path

pwd -P

What it does: Resolves all symbolic links and shows the actual, physical filesystem path.
When to use it: During forensic investigations, this is critical. Attackers sometimes create symlinks to hide the true storage location of malicious files or to redirect innocuous-looking paths to sensitive directories. pwd -P cuts through that obfuscation.
Expected output: The real, resolved directory path on disk.

4. Get Just the Current Directory Name

basename "$(pwd)"

What it does: Strips the full path down to just the final directory name.
When to use it: Useful in automated incident response scripts where you want to log or label evidence by directory name without the full path clutter.
Expected output: Just the folder name, e.g., uploads.

5. Get the Parent Directory

dirname "$(pwd)"

What it does: Shows the parent directory one level above your current location.
When to use it: Helpful when writing recursive search scripts or when you need to quickly step back conceptually to check sibling directories for lateral traces of an attack.
Expected output: The path one directory up.

6. List Files in the Current Directory

ls "$(pwd)"

What it does: Lists all files and folders in your current working directory using the explicit full path.
When to use it: In scripts and forensic playbooks where relying on implicit relative paths is risky — explicit is safer, especially across automated tooling.
Expected output: A directory listing, identical to plain ls but path-explicit.

7. Return to the Current Path (Script Safety)

cd "$(pwd)"

What it does: Changes to the current directory — which sounds redundant but is a defensive scripting pattern.
When to use it: In automated incident response or hardening scripts, this ensures your working directory is anchored and predictable before subsequent commands execute, reducing the risk of a script running destructive actions in the wrong folder.
Expected output: No visible output, but the shell's context is confirmed and stabilized.

8. Store the Current Path in a Variable

CURRENT_DIR=$(pwd)

What it does: Saves the working directory path into a reusable shell variable.
When to use it: Extremely common in SOC automation and forensic collection scripts, where you need to return to a known-good location after navigating elsewhere to pull evidence.
Expected output: No output; the value is stored silently for later use.

9. Find All Files From the Current Location

find "$(pwd)" -type f

What it does: Recursively searches for every file starting from your current directory.
When to use it: A staple during malware hunting and file-integrity checks — combine it with -newer, -mtime, or -name flags to hunt for recently modified or suspiciously named files planted by an attacker.
Expected output: A full list of file paths under the current directory.

10. Check Disk Usage of the Current Directory

du -sh "$(pwd)"

What it does: Displays the total human-readable size of the current working directory.
When to use it: Useful for spotting anomalies like an unexpectedly large temp folder, which can indicate staged exfiltration data or a dropped toolkit waiting for transfer.
Expected output: A size value like 1.2G followed by the directory path.

Reading pwd in Logs and Shell History

If you're doing log analysis or reviewing .bash_history, auditd logs, or EDR command-line telemetry, here's what to actually look for:

Indicator	What It Suggests
pwd as the first command in a new session	Likely the start of manual attacker interaction after gaining shell access
pwd followed immediately by whoami/id	Classic discovery-phase behavior consistent with post-exploitation checklists
Repeated pwd calls across multiple directories	Attacker manually navigating and mapping the filesystem, possibly searching for specific files
pwd -P used specifically	Possible awareness of symlink obfuscation, suggesting a more experienced operator
pwd inside cron jobs or startup scripts you didn't create	Could indicate a persistence mechanism logging its own execution context

None of these are proof of compromise on their own — pwd is used constantly by legitimate admins too. The value comes from correlation: timing, surrounding commands, the account running it, and whether it matches expected admin behavior for that host.

Detection and Prevention Techniques

Since pwd itself isn't malicious, detection strategy should focus on context and sequence rather than the command in isolation.

• Enable full command-line auditing. Use auditd on Linux with rules targeting execve syscalls, or deploy EDR agents that capture full shell session telemetry, not just process names.
• Baseline normal admin behavior. Know which accounts and hosts typically run discovery commands like pwd, whoami, and id in sequence, and flag deviations — especially from service accounts that should never have interactive shell access.
• Correlate with process ancestry. A pwd command spawned from a web server process (like www-data running a shell under Apache or Nginx) is a major red flag, since legitimate admins rarely operate through the web service account.
• Watch for discovery clusters, not single commands. Set SIEM correlation rules to alert when pwd, whoami, uname -a, and id all appear within seconds of each other from the same session — a strong post-exploitation signature.
• Harden web-facing service accounts. Restrict shell access (/usr/sbin/nologin) for accounts like www-data so that even if a web shell is dropped, spawning an interactive shell becomes much harder.
• Use file integrity monitoring alongside directory checks. Combine find and du style hunting (as shown above) with tools like Tripwire or OSSEC to catch newly created files in directories an attacker has been exploring.

Expert Tips From the Field

• When writing incident response or hardening scripts, always anchor your script with CURRENT_DIR=$(pwd) at the top. It's a small habit that prevents catastrophic "wrong directory" mistakes during live response on production systems.
• During malware triage, run pwd -P before trusting any file path you've been given by another tool or a colleague's notes — symlinks are a cheap and common way to disguise where a payload actually lives.
• If you're building detection rules, don't alert on pwd alone; you'll drown in false positives. Alert on the pattern, not the command.
• Penetration testers: documenting the exact pwd output at each pivot point in your engagement notes makes writing the final report significantly faster and more accurate.
• Combine find "$(pwd)" -type f -mtime -1 during live response to quickly surface files modified in the last 24 hours — a fast way to spot freshly dropped tooling.

Related Cybersecurity Topics You Should Explore

• 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
  
• ntopng: Best Network Traffic Monitoring and Threat Detection Tool for SOC Teams

Frequently Asked Questions

Is the pwd command dangerous or a security risk?

No. pwd is a read-only, non-destructive command. It doesn't modify files or system state. Its security relevance comes entirely from context — what it reveals about attacker behavior, not from any inherent risk in the command itself.

Why do attackers run pwd right after gaining shell access?

Because exploits often land in unpredictable directories. Attackers need to orient themselves before deciding whether to escalate privileges, search for credentials, or move laterally, and pwd is the fastest way to get that context.

What's the difference between pwd -L and pwd -P?

pwd -L shows the logical path, preserving symbolic links as navigated. pwd -P resolves those symlinks and shows the true physical path on disk — an important distinction during forensic investigations involving obfuscated file locations.

Can pwd usage be logged and monitored?

Yes. Tools like auditd, shell history logging, and EDR command-line telemetry can capture every pwd invocation, including the user, timestamp, and parent process — all of which are valuable during incident investigations.

Should SOC teams create alerts specifically for pwd?

Not on its own. Because it's used so frequently by legitimate administrators, standalone alerts would generate excessive noise. Instead, correlate it with other discovery commands and abnormal process ancestry, such as a shell spawned from a web server.

How is pwd useful in incident response scripting?

It's commonly used to anchor scripts to a known directory, ensuring commands execute in the correct location — especially important when a script needs to navigate away and safely return during evidence collection.

Does pwd work the same way on all Linux distributions?

Yes, pwd is a POSIX-standard shell built-in and behaves consistently across major distributions like Ubuntu, CentOS, Debian, and RHEL, as well as macOS's Unix-based terminal.

Conclusion

It's easy to dismiss pwd as too basic to matter in cybersecurity. But real-world incident response isn't just about catching the exotic, zero-day exploits — it's about reading the small, unglamorous details that reveal intent. A single pwd command, seen at the right moment in a shell history log, can mark the exact second an attacker stopped being a vulnerability and started being an active intruder inside your environment.

Whether you're a SOC analyst correlating command sequences, a penetration tester documenting a pivot, or a system administrator writing safer automation scripts, understanding pwd beyond its textbook definition makes you sharper at your job. Master the basics deeply enough, and you'll start noticing the signals everyone else scrolls past.