Landing on a Linux machine after exploitation or with freshly harvested credentials often feels like a victory, but in reality, it is only the beginning of the struggle. Lateral movement in Linux environments is notoriously trickier than in Windows domains. Even if you manage to obtain root on one host, you might quickly hit a wall: you see evidence of users connecting to other systems, but you don’t have their credentials. Without those, further expansion stalls. Techniques such as dumping memory or scraping process data might work in some cases, but SSH processes in particular won’t reveal user credentials so easily. At first glance, it feels like a dead end.
This is where PAM manipulation comes into play. By modifying how the Pluggable Authentication Module handles logins, it becomes possible to quietly capture user credentials whenever they authenticate. This is how you create a systematic way to harvest SSH passwords and reuse them for lateral movement.
Recon with Known Hosts
Before diving into PAM patching, it is useful to gather some context about the network and where legitimate users are connecting. SSH clients store previously accessed servers in a known_hosts file under each user’s .ssh directory. If those files are accessible, they give a list of destinations without the need for noisy scanning. For example, inspecting /home/dev3/.ssh/known_hosts might reveal entries such as git. That single clue suggests a pivot point. If the compromised machine is in a restricted environment, that host may sit in another subnet or behind access controls you couldn’t otherwise reach. With the right credentials, this file becomes a roadmap for lateral movement.
Preparing the Host
Before implementing a credential capture mechanism, it’s important to ensure the host accepts password-based logins. SSHD can be configured to forbid password authentication entirely, relying solely on key-based access. To enable credential capture, the following must be set in /etc/ssh/sshd_config:
target# > nano /etc/ssh/sshd_config
PasswordAuthentication yes
Once this change is in place, the groundwork is set.
Creating a Logging Script
The next step is creating a small script that will record login attempts. With root privileges, create a new file at /usr/local/bin/logc.sh:
Then prepare the hidden log file that will quietly collect captured data:
target# > touch /var/log/.authc.log
This script is simple yet powerful. It captures the username, the plaintext password, the source of the connection, and timestamps each entry.
Patching PAM
With the logging script in place, the next task is to insert it into the PAM authentication chain. PAM configurations vary slightly between distributions, but for SSH specifically, the relevant file is/etc/pam.d/sshd. For broader system-wide coverage, other files such as /etc/pam.d/common-auth (Debian/Ubuntu) or /etc/pam.d/password-auth (CentOS) could be patched instead.
To modify SSH authentication only, open/etc/pam.d/sshd and add the following line at the very top:
This ensures that every authentication attempt, successful or not, passes through the logging script before continuing with normal PAM processing. Credentials are silently exfiltrated while legitimate users remain unaware.
Applying and Testing the Patch
For the changes to take effect, restart the SSH service:
target# > service sshd restart
Once restarted, test the patch by logging in with valid credentials.
Afterwards, check the log file:
target# > cat /var/log/.authc.log
Each entry should display the captured user, the password they entered, the remote host they connected from, and the date of the attempt. Over time, this log will accumulate valuable credentials from legitimate user sessions, giving you a resource for lateral movement.
Summary
There is a great method of harvesting SSH credentials on Linux by modifying the Pluggable Authentication Module (PAM). After identifying potential lateral movement targets via known_hosts, SSH is reconfigured to allow password authentication. A custom logging script is created to capture usernames, passwords, and remote sources, and is then integrated into PAM by editing /etc/pam.d/sshd. With the patch in place, every login attempt is silently recorded to a hidden log file. Restarting SSH activates the change, and future connections yield a steady stream of usable credentials.
This module takes the often-confusing topic of Windows persistence and turns it into a pragmatic playbook you can use during real engagements. In this part we start small and build up: short-lived shell loops that are easy to launch from any user context, autostart locations and registry Run keys that provide reliable logon-time execution, scheduled tasks that offer precise timing and powerful run-as options, Windows services that deliver the most durable, pre-logon persistence, and in-memory techniques that minimize on-disk traces.
Techniques are shown with privileged # and non-privileged $ examples, so you can see what’s possible from the access you already have. Every method shows the balance between how secret it is, whether it stays after a restart, and what permissions you need to make it work.
Ultimately this module is designed to be immediately useful in the ongoing cyber conflict context. It is compact with repeatable techniques for maintaining access when appropriate.
Shell
Persistence can be achieved directly from a command prompt by creating a small looping construct that repeatedly launches a reverse or bind shell and then pauses for a fixed interval. The technique relies on a persistent cmd.exe process that keeps retrying the connection instead of using service registration or scheduled tasks. It’s a quick, user-space way to try to maintain an interactive foothold while the process lives. The example command is:
This runs a new command shell to execute the quoted loop. The for /L construct is used to execute the loop body repeatedly. In practice the parameters chosen here make the body run continuously. Inside the loop the nc.exe invocation attempts to connect back to the C2.
The chained ping -n 60 127.0.0.1 acts as a simple portable sleep to insert a roughly one-minute delay between connection attempts.
Pros: allows a controllable retry interval and can be launched from any user account without special privileges.
Cons: the loop stops on reboot, logoff, or if the shell/window is closed, so it does not survive reboots.
This method is useful when you already have an interactive session and want a low-effort way to keep trying to reconnect, but it’s a volatile form of persistence. Treat it as temporary rather than reliable long-term access. From a defensive perspective, repeated processes with outbound network connections are a high-value detection signal.
Autostart
Autostart locations are the canonical Windows persistence vectors because the operating system itself will execute items placed there at user logon or system startup. The two typical approaches shown are copying an executable into a Startup folder and creating entries under the Run registry keys. Below are two separate techniques you can use depending on your privileges:
Placing an executable (or a shortcut to it) in a per-user Startupfolder causes the Windows shell to launch that item when the specific user signs in. Using the ProgramData (all-users) Startup folder causes the item to be launched for any interactive login.
Writing a value into HKCU\Software\Microsoft\Windows\CurrentVersion\Run registers a command line that will be executed at logon for the current user and can usually be created without elevated privileges. Writing into HKLM\Software\Microsoft\Windows\CurrentVersion\Run creates a machine-wide autorun and requires administrative rights.
Pros: survives reboots and will automatically run at each interactive logon (per-user or machine-wide), providing reliable persistence across sessions.
Cons: startup autoruns have no fine-grained execution interval (they only run at logon) and are a well-known, easily monitored location, making them more likely to be detected and removed.
Services
Using a Windows service to hold a backdoor is more robust than a simple autostart because the Service Control Manager (SCM) will manage the process lifecycle for you. Services can be configured to start at boot, run before any user logs on, run under powerful accounts (LocalSystem, NetworkService, or a specified user), and automatically restart if they crash. Creating a service requires administrative privileges, but once installed it provides a durable, system-integrated persistence mechanism that survives reboots and can recover from failures without manual intervention.
The first line uses sc create to register a new service named persistence. The binPath= argument provides the command line the service manager will run when starting the service. In practice this should be a quoted path that includes any required arguments, and many administrators prefer absolute paths to avoid ambiguity.start= auto sets the service start type to automatic so SCM will attempt to launch it during system boot.
The second line configures the service recovery policy with sc failure: reset= 0 configures the failure count reset interval (here set to zero, meaning the failure count does not automatically reset after a timeout), and actions= restart/60000/restart/60000/restart/60000 tells the SCM to attempt a restart after 60,000 milliseconds (60 seconds) on the first, second and subsequent failures. This allows the service to be automatically relaunched if it crashes or is killed.
The third line, sc start persistence, instructs SCM to start the service immediately.
Pros: survives reboot, runs before user logon, can run under powerful system accounts, and can be configured with automatic restart intervals via the service recovery options.
Cons: creating or modifying services requires administrative privileges and is highly visible and auditable (service creation, service starts/stops and related events are logged and commonly monitored by endpoint protection and EDR solutions).
Scheduled Tasks
Scheduled tasks are a convenient and flexible way to maintain access because the Windows Task Scheduler supports a wide variety of triggers, run-as accounts, and recovery behavior. Compared with simple autostart locations, scheduled tasks allow precise control over when and how often a program runs, can run under powerful system accounts, and survive reboots. Creating or modifying scheduled tasks normally requires administrative privileges.
Here the schtasks /create creates a new scheduled task named persistence. The /ru SYSTEM argument tells Task Scheduler to run the job as the SYSTEM account (no password required for well-known service accounts), which gives the payload high privileges at runtime. The /sc MINUTE /MO 1 options set the schedule type to “minute” with a modifier of 1, meaning the task is scheduled to run every minute. /tn persistence gives the task its name, and /tr "..." specifies the exact command line the task will execute when triggered. Because Task Scheduler runs scheduled jobs independently of an interactive user session, the task will execute even when no one is logged in, and it will persist across reboots until removed.
Pros: survives reboot and provides a tightly controlled, repeatable execution interval (you can schedule per-minute, hourly, daily, on specific events, or create complex triggers), and tasks can be configured to run under high-privilege accounts such as SYSTEM.
Cons: creating or modifying scheduled tasks typically requires administrative privileges and Task Scheduler events are auditable and commonly monitored by enterprise defenses.
In-Memory
In-memory persistence refers to techniques that load malicious code directly into a running process’s memory without writing a persistent binary to disk. The goal is to maintain a live foothold while minimizing on-disk artifacts that antiviruses and file-based scanners typically inspect. A common pattern is to craft a payload that is intended to execute only in RAM and then use some form of process injection (for example, creating a remote thread in a legitimate process, reflective DLL loading, or other in-memory execution primitives) to run that payload inside a benign host process. The technique is often used for short-lived stealthy access, post-exploitation lateral movement, or when the attacker wants to avoid leaving forensic traces on disk.
Pros: extremely low on-disk footprint and difficult for traditional antivirus to detect, since there is no persistent executable to scan and many memory-only operations generate minimal file or registry artifacts.
Cons: does not survive a reboot and requires a mechanism to get code into a process’s memory (which is often noisy and produces behavioral telemetry that modern endpoint detection and response solutions can flag).
Defenders may monitor for anomalous process behavior such as unexpected parent/child relationships, unusual modules loaded into long-lived system processes, creation of remote threads, or unusual memory protections being changed at runtime.
Summary
We explored different basic Windows persistence options by comparing durability, visibility, and privilege requirements: simple shell loops let you keep retrying a connection from a user shell without elevation but stop at logoff or reboot. Autostart provides reliable logon-time execution and can be per-user or machine-wide depending on privileges. Scheduled tasks give precise, repeatable execution (including SYSTEM) and survive reboots. Services offer the most durable, pre-logon, auto-restarting system-level persistence but require administrative rights and are highly auditable. In-memory techniques avoid on-disk artifacts and are stealthier but do not persist across reboots and often produce behavioral telemetry. The core trade-off is that greater restart resilience and privilege typically mean more detectable forensic signals, defenders should therefore watch for repeated outbound connection patterns, unexpected autoruns, newly created services or scheduled tasks, and anomalous in-memory activity.
In the first part of Advanced Windows Persistence, we will dive into advanced techniques that will leverage the Configs, Debugger, GFlags and WMI.
Login
