CHAPTER 06 35 MIN READ INTERMEDIATE

Shell Tradecraft and Detection: Reverse Shells, History Manipulation & Linux LOLBins

The shell is both the administrator's main tool and the attacker's. Recognizing the specific ways it gets abused, reverse shells, history tampering, and repurposed system binaries, is what separates normal admin activity from an active intrusion in your logs and process tree.

reverse shells history manipulation Linux LOLBins detection strategy

Reverse Shells, Conceptually

A normal remote shell has the attacker connecting inbound to a port listening on the target. Firewalls and network policy are built to block exactly that. A reverse shell flips the direction: the compromised host initiates an outbound connection back to infrastructure the attacker controls.

Most network policies are far more permissive outbound than inbound, so an outbound connection from a host that already trusts general internet access tends to blend in unless something else about it stands out.

Category	Notes
Shell built-in redirection	Bash's `/dev/tcp` pseudo-device can open a network connection without any external tool, using redirection the shell already supports.
Standalone utilities	Netcat and similar tools are commonly repurposed for this, even though their legitimate use is general-purpose network testing and transfer.
Scripting-language one-liners	Python and similar interpreters, when present, are attractive since they're pre-installed almost everywhere and rarely questioned on their own.

Why this matters for detection: none of these categories require anything an attacker had to bring with them. The building blocks are already on the system, which is exactly what makes the resulting connection hard to distinguish from legitimate activity without behavioral context.

Bash History Manipulation

Shell history is one of the simplest records of what an account actually did, and one of the easiest for an attacker with shell access to tamper with. A few environment variables and a text file are all that stand between a full audit trail and none.

Mechanism	Effect
`HISTFILE` unset or redirected	Commands stop being written to the history file at all.
`HISTSIZE` set to zero	Stops new commands from being kept in the in-memory history going forward.
`HISTFILESIZE` set to zero	Truncates the existing history file to nothing immediately, destroying prior history rather than just stopping future writes.
`HISTCONTROL` set to ignore commands with a leading space	A legitimate feature some attackers rely on to keep specific commands out of history.
Manual deletion or truncation of the history file	Removes the record after the fact, once it's no longer needed.

A suspiciously short or entirely missing history file, especially on an account that's clearly been used, is itself a forensic signal worth investigating.

Linux Living-Off-the-Land

The underlying idea is the same one this platform's LOLBAS module covers for Windows: pre-installed, legitimate binaries can be repurposed for download, execution, or data transfer instead of an attacker bringing their own tools. Using what's already trusted on the box helps them blend into normal admin activity.

GTFOBins is a well-known, publicly documented project cataloging exactly this for Unix-like systems, the direct parallel to LOLBAS on Windows. It lists common Linux binaries alongside the unintended ways they can be used to bypass restrictions or execute unexpected actions.

See the LOLBAS module for the Windows-side equivalent of this concept. The same detection principle applies on both platforms: behavior matters more than the binary name alone. A binary being "trusted" or pre-installed says nothing about what it was just used to do.

Detection Strategy

No single signal here is proof of compromise on its own. Layering multiple weak signals together is what turns noise into an actionable lead.

Signal	Why It Matters
Unexpected parent-child process relationships	Covered in chapter 5, a shell spawned by a process that has no business spawning shells is a strong indicator on its own.
Outbound connections initiated from a process with no normal reason to make them	A reverse shell's defining behavior is exactly this kind of unexpected outbound initiation.
Missing or unusually short shell history on an active account	Points at deliberate history manipulation rather than an account that simply wasn't used.
execve (process execution) logging via auditd, where configured	Captures command execution even if shell history itself is tampered with, since it doesn't depend on the shell's own record-keeping.

Any one of these can have an innocent explanation: an admin testing connectivity, an account that legitimately clears its own history, a script that spawns a shell for a valid reason. Several of them together, on the same host, in the same window, is a strong indicator.

Chapter Recap

Shell tradecraft doesn't happen in isolation. It connects directly to the two prior chapters in this module.

Persistence (chapter 4): a reverse shell or LOLBin execution is often what a persistence mechanism actually launches once it triggers.
Process and network visibility (chapter 5): that's how shell-level tradecraft gets caught, through the parent-child relationships and connection patterns those techniques leave behind.

Chapter 7 takes this same shell-level tradecraft and examines it inside containers specifically, where the detection surface changes but the underlying attacker goals don't.

Key Takeaways

A reverse shell connects outbound from the compromised host back to attacker infrastructure, since outbound-permissive network policy typically lets that through while blocking inbound connections.
Reverse shells commonly come from shell built-ins like bash's /dev/tcp, standalone utilities such as netcat, or pre-installed scripting-language interpreters.
Bash history can be suppressed or erased via HISTFILE, HISTSIZE/HISTFILESIZE, HISTCONTROL, or direct deletion, and a missing or unusually short history is itself a signal.
GTFOBins catalogs Linux living-off-the-land binary abuse the same way LOLBAS does for Windows, both hinge on behavior mattering more than the binary's trusted reputation.
Detection strength comes from layering signals: parent-child anomalies, unexpected outbound connections, thin shell history, and auditd execve logging together, not any one alone.
Shell tradecraft ties directly to persistence (what launches it) and process/network visibility (what catches it), and carries forward into container-specific detection in chapter 7.

Knowledge Check

Click an answer to reveal the explanation.

Why does a reverse shell connect outbound from the compromised host rather than listening inbound for the attacker to connect in?

Correct answer: B. Firewalls and network policy are usually built to block unsolicited inbound connections, but permit far more outbound traffic, so initiating the connection from the compromised host tends to blend in.

What is the effect of unsetting or redirecting the HISTFILE environment variable in a bash session?

Correct answer: B. HISTFILE tells bash where to persist command history. Unsetting it or pointing it somewhere unused (like /dev/null) means commands are never written to a retrievable history file.

GTFOBins is best described as the direct Linux equivalent of which other project?

Correct answer: C. LOLBAS catalogs living-off-the-land binary abuse on Windows. GTFOBins documents the same kind of pre-installed-binary abuse for Unix-like systems, the direct parallel on Linux.