Guide to threat hunting Hunting LOLBins/GTFOBins

Introduction: why LOLBins still matter

If you’ve been doing detection or threat hunting for more than five minutes, you already know what LOLBins are. Living Off the Land Binaries are native, signed tools that ship with the operating system and get abused by attackers to execute code, move laterally, persist, or blend into normal activity.

What’s changed isn’t the tools. What’s changed is how quietly attackers use them and how often defenders misunderstand them.

LOLBin hunting fails when it turns into a checklist exercise. It succeeds when it becomes a way of thinking about intent, behavior, and broken assumptions.

This guide is not a list of scary binaries. It’s a way to hunt attackers who are deliberately hiding inside what looks normal.

The most important mental shift

LOLBins are not malicious.

They become malicious when:

• They are used by the wrong user
• At the wrong time
• From the wrong place
• With the wrong arguments
• In the wrong execution chain

If your detection logic starts and ends with “process name equals X”, you will drown in noise or miss real intrusions. Often both.

The real unit of analysis is behavior, not binaries.

What actually makes a LOLBin suspicious

Across thousands of real incidents, abused LOLBins tend to share the same characteristics.

1. Broken parent-child relationships

Some examples:

• Office spawning PowerShell
• A browser spawning mshta
• Explorer spawning certutil
• A script engine spawning rundll32

Normal tools don’t usually surprise you. When they do, pay attention.

2. User-writable execution paths

LOLBins almost never need to run code from:

• %AppData%
• %Temp%
• %Downloads%
• Randomly named user folders

Attackers love these paths because defenders ignore them.

3. Command-line abuse

This is where attackers leak intent.

Look for:

• Encoded or compressed data
• Long, unreadable strings
• Chained commands
• Inline scripts
• Download then execute patterns

If you are not logging full command lines, you are hunting blind.

4. Network activity where none is expected

A surprising number of LOLBins have network capability. Most environments barely notice.

When a tool that usually does local work suddenly talks to the internet, stop scrolling.

Core execution LOLBins

These are about getting code to run without dropping a classic malware binary.

PowerShell

Still the most abused tool on Windows.

Common abuse patterns:

• -EncodedCommand
• -NoProfile, -WindowStyle Hidden
• Reflection and in-memory execution
• Download cradles
• AMSI bypass attempts

PowerShell is rarely the final payload. It is the loader.

cmd.exe

Unsexy, but critical.

Attackers use cmd as:

• A control shell
• A command chain orchestrator
• A fallback when PowerShell is constrained

Look for heavy chaining, environment variable abuse, and cmd spawning multiple LOLBins in sequence.

mshta.exe

One of the highest signal LOLBins in most environments.

Suspicious when:

• Loading remote URLs
• Executing inline JavaScript
• Launched by Office or browsers
• Running without visible user interaction

Legitimate mshta usage is increasingly rare.

rundll32.exe

Blends in extremely well.

Red flags:

• DLLs in user-writable directories
• Non-standard export names
• Network activity
• Being launched by non-system processes

If rundll32 exists in your telemetry, context is everything.

regsvr32.exe

A classic “fileless” execution path.

Watch for:

• /i: flags
• Remote scriptlets
• Execution without a corresponding DLL registration event

Most defenders forget regsvr32 until it bites them.

installutil.exe

.NET execution without dropping a traditional binary.

Suspicious when:

• Assemblies are unsigned
• Execution happens outside install workflows
• Launched by scripts or user processes
• Files live in temp directories

msbuild.exe

Quiet, powerful, and often ignored.

Red flags:

• Inline tasks in project files
• Execution on non-developer systems
• Network access
• Build files in user directories

If you don’t run a build pipeline on workstations, msbuild should stand out.

cscript.exe / wscript.exe

Legacy script engines with modern abuse.

Watch for:

• VBS or JScript in temp paths
• Obfuscation
• Office-spawned execution
• Network access

If your org doesn’t rely on legacy scripting, these are high-value hunts.

Download and staging LOLBins

Attackers still need to move data. These tools help them do it quietly.

certutil.exe

Probably the most abused downloader.

Common flags:

• -urlcache
• -split
• -decode

Certutil is usually step one, not the end goal.

bitsadmin.exe

Old, but still effective.

Suspicious when:

• Used interactively
• Downloading from the internet
• Writing to user paths
• Followed quickly by execution

Leftover BITS jobs are a gift to hunters.

curl.exe / wget.exe

Now built into modern Windows.

Red flags:

• Used on non-developer endpoints
• Downloading executables or scripts
• Direct IP addresses
• No corresponding business workflow

Attackers noticed curl the moment Microsoft shipped it.

ftp.exe / tftp.exe

Less common, but still abused.

Watch for:

• Cleartext credentials
• Use from workstations
• Connections to unusual external hosts

Discovery and identity LOLBins

These tools help attackers understand where they are.

whoami.exe

Harmless alone. Useful in chains.

Suspicious when followed by:

• Privilege escalation attempts
• Lateral movement
• Credential access

net.exe / net1.exe

Identity abuse in plain sight.

Red flags:

• Group enumeration
• Adding users to privileged groups
• Execution from non-admin contexts
• Burst activity after initial access

nltest.exe

Domain reconnaissance.

Suspicious when:

• Used by non-admins
• Executed on workstations
• Enumerating trusts or DCs

dsquery.exe / dsget.exe

Active Directory discovery.

Rarely needed on endpoints. Often abused during internal recon.

quser.exe / qwinsta.exe

Session discovery.

Often appears right before lateral movement.

Lateral movement and persistence LOLBins

This is where things get serious.

schtasks.exe

Reliable persistence.

Watch for:

• Tasks executing scripts or LOLBins
• User-writable paths
• Tasks created by non-admins
• Short-lived or self-deleting tasks

at.exe

Deprecated, but still works.

Any usage deserves scrutiny.

sc.exe

Service creation and abuse.

Red flags:

• New services with random names
• Services pointing to user directories
• Remote service creation
• Services executing scripts

winrm.exe / PowerShell remoting

Native remote execution.

Suspicious when:

• Newly enabled
• Used from user workstations
• No corresponding change record

mmc.exe

Often overlooked.

Watch for:

• Custom MSC files
• Execution from user paths
• Malicious snap-ins

Installer and user-triggered LOLBins

These show up early in attacks.

msiexec.exe

Installer abuse is common.

Suspicious when:

• Installing from remote URLs
• Running silently
• Executing from temp directories
• No visible user interaction

Office applications as parents

Office isn’t a LOLBin, but it’s a critical signal source.

If Word or Excel spawns:

• PowerShell
• cmd
• mshta
• wscript
• rundll32

Assume compromise until proven otherwise.

Rare but high-value LOLBins

These don’t appear often, but they’re loud when they do.

• forfiles.exe for delayed execution
• esentutl.exe for file abuse
• replace.exe for overwrites
• conhost.exe when launched directly

Low frequency plus high impact makes these excellent hunt targets.

How to structure effective LOLBin hunts

Start with baselines

You don’t need perfection. You need “good enough”.

Ask:

• Which users actually need PowerShell?
• Which systems legitimately run certutil?
• Which LOLBins appear during normal business hours?

Even rough baselines reduce noise dramatically.

Hunt behaviors, not binaries

Good hunt ideas:

• LOLBins with network connections
• LOLBins launched by Office
• LOLBins executing from user paths
• LOLBins with encoded arguments

These scale better than one-off queries.

Follow the chain

Never stop at the LOLBin.

Ask:

• What launched it?
• What did it launch next?
• Did credentials get used?
• Did lateral movement follow?

Many real detections happen one or two steps after the LOLBin runs.

Common mistakes defenders make

• Treating LOLBins as inherently malicious
• Alerting on process name alone
• Ignoring command lines
• Ignoring user context
• Chasing completeness instead of signal

You do not need to detect every LOLBin. You need to detect attackers using them.

How attackers actually think about LOLBins

Attackers use LOLBins because:

• They are signed and trusted
• They blend into telemetry
• Defenders whitelist them
• They reduce payload risk

They don’t care which LOLBin they use. They care which one works in your environment.

That means your blind spots matter more than your coverage.

A simple rule that catches real attacks

If a LOLBin:

• Runs as a user
• Has an unusual parent
• Touches the network
• And spawns another process

Treat it as hostile until proven otherwise.

That rule alone catches more real intrusions than most complex detection logic.

Final thoughts

LOLBin hunting isn’t about memorizing binaries. It’s about spotting intent leaking through normal tools.

Once you stop asking “is this allowed?” and start asking “does this make sense?”, LOLBins stop being stealthy and start being obvious.

That’s when threat hunting gets fun. https://lolbas-project.github.io/#

A threat hunter’s field manual for catching attackers hiding in plain sight

Introduction: why Linux LOLBins are different

On Linux, living off the land isn’t a technique. It’s the operating model.

Everything is a small tool designed to do one thing well and chain cleanly into the next. That makes Linux powerful for admins and perfect for attackers. When an intruder lands on a Linux system, they rarely need custom malware. The system already has everything they need.

Linux LOLBin hunting fails when defenders look for “malware behavior” instead of abuse of normal administrative workflows.

If you hunt Linux like Windows, you will miss real compromises.

The mental model you need for Linux

On Linux, almost every binary is legitimate. That means intent shows up in:

• Command sequences
• Process ancestry
• Privilege transitions
• Filesystem targets
• Timing and automation

You’re not hunting binaries. You’re hunting workflows that don’t belong.

A single command is rarely suspicious. A chain of commands often is.

What actually makes a Linux LOLBin suspicious

Across real intrusions, abused Linux binaries tend to share these traits.

1. Commands run without a human

Look for:

• No TTY
• Executed by system services
• Cron or systemd execution
• SSH sessions without interactive behavior

Automation without a ticket is a gift to hunters.

2. Unexpected privilege changes

Key signals:

• Sudden sudo usage
• UID switches
• Abuse of SUID binaries
• Root actions from non-admin users

Linux attackers live and die by privilege escalation.

3. Living in writable paths

Common attacker favorites:

• /tmp
• /var/tmp
• /dev/shm
• User home directories

Execution from these paths should always stand out.

4. Quiet persistence

Linux persistence is subtle:

• Cron jobs
• Systemd units
• Shell profile modification
• SSH key insertion

Attackers don’t need loud autoruns.

Core execution and scripting LOLBins

These are about running arbitrary commands and scripts.

bash / sh / dash

The most powerful LOLBins on the system.

Abuse patterns:

• Non-interactive shells
• Inline scripts passed via -c
• Shells launched by network-facing services
• Obfuscated environment variables

Shells spawning shells is rarely normal.

python / python3

Python is everywhere.

Suspicious when:

• Used on servers that don’t run Python apps
• Inline one-liners
• Base64-decoded payloads
• Network activity from scripts

Python is often used as a replacement for dropped malware.

perl / ruby / php

Less common, but still abused.

Red flags:

• One-liners executed from shell
• Execution from temp directories
• Network sockets
• No corresponding application context

awk / sed

Power tools in the wrong hands.

Suspicious when:

• Used for decoding or deobfuscation
• Piping into shells
• Manipulating system config files

These often appear mid-chain, not at the start.

Download and staging LOLBins

Attackers still need to move files.

curl / wget

The certutil of Linux.

Red flags:

• Downloading to /tmp
• Piping directly into bash
• Direct IP addresses
• Non-standard user agents

If you see curl | bash, stop everything.

scp / sftp

Living off SSH.

Suspicious when:

• Used from servers that don’t normally transfer files
• Pulling from unknown hosts
• Used with stolen credentials

ftp / tftp

Still alive, still abused.

Cleartext transfers on modern systems should stand out.

Discovery and recon LOLBins

Attackers need to understand the system fast.

id / whoami

Usually harmless, but meaningful in sequence.

Often followed by privilege escalation attempts.

uname / lsb_release

System profiling.

Suspicious when run in bursts or scripted.

ps / top / htop

Process discovery.

Look for:

• Non-interactive usage
• Output piped elsewhere
• Execution shortly after initial access

netstat / ss

Network discovery.

Suspicious when:

• Executed by non-admin users
• Used repeatedly
• Followed by lateral movement

ip / ifconfig / route

Network layout discovery.

Often appears early in compromises.

Privilege escalation LOLBins

This is where Linux attacks escalate quickly.

sudo

Legitimate but dangerous.

Red flags:

• Repeated failed sudo attempts
• Unusual commands run with sudo
• sudo used inside scripts

su

Less logged, more dangerous.

Unexpected su usage deserves attention.

pkexec

A frequent escalation vector.

Any pkexec usage outside desktop environments is suspicious.

find

A recon and escalation powerhouse.

Suspicious when:

• Searching for SUID binaries
• Searching writable root-owned files
• Piping results into shells

chmod / chown

Used to prepare persistence.

Watch for:

• Permission changes in system directories
• Making files executable in temp paths

Persistence LOLBins

Linux persistence is boring by design.

crontab / cron

The attacker’s favorite.

Red flags:

• Cron jobs running from writable paths
• Jobs executing curl, wget, or shells
• Jobs created outside change windows

systemctl

Modern persistence.

Suspicious when:

• New services appear unexpectedly
• Services run from user directories
• Services execute scripts

at

Still works, still abused.

Any usage should be questioned.

Shell profile files

Quiet and effective.

Watch:

• .bashrc
• .profile
• .bash_profile
• /etc/profile

Changes here are often missed.

Lateral movement and credentials

ssh

The backbone of Linux movement.

Suspicious when:

• New keys appear
• SSH used without TTY
• Connections from unusual sources

ssh-keygen

Often used to create persistence.

New keys without tickets are rarely legitimate.

mount

Used to access other systems.

Unexpected mounts are high-signal.

Rare but high-value Linux LOLBins

These don’t show up often, but matter.

• strace for credential leakage
• tcpdump for traffic capture
• nc / ncat for backchannels
• socat for tunneling
• screen / tmux for persistence

Each of these is powerful enough to be a full post on its own.

How to structure effective Linux LOLBin hunts

Focus on sequences

Linux attacks are pipelines.

Examples:

• curl → bash → sudo
• ssh → recon → cron
• python → socket → shell

Single commands lie. Sequences tell the truth.

Watch writable paths

Execution from /tmp and friends is one of the highest-signal behaviors you have.

Track privilege transitions

Every UID change matters.

If you don’t log them, start there.

Pay attention to time

Attacks often:

• Run off-hours
• Execute in bursts
• Finish quickly

Human admins are noisy. Attackers are efficient.

Common mistakes defenders make

• Ignoring shell history
• Not logging process arguments
• Treating root activity as inherently trusted
• Missing cron and systemd changes
• Hunting tools instead of workflows

Linux attackers rely on defenders assuming “that’s just admin work”.

How attackers think about Linux LOLBins

Attackers love Linux because:

• Tools are already there
• Everything chains cleanly
• Logging is inconsistent
• Admin behavior provides cover

They don’t need malware. They need one mistake.

A simple rule that works frighteningly well

If a Linux command:

• Runs without a TTY
• Executes from a writable path
• Alters persistence
• Or changes privileges

Treat it as hostile until proven otherwise.

That rule alone catches a large percentage of real-world compromises. https://gtfobins.github.io/