FirewallFalcon Manager: Supply-Chain Backdoors in Underground VPN Infrastructure

By Assaf Morag, Cybersecurity Researcher

What if the tool you use to run your criminal infrastructure is itself criminal infrastructure, and you are the target? FirewallFalcon Manager is presented as a free open-source Linux server management tool for VPN and proxy services. But, beneath the well-polished GitHub repo and feature-rich shell menus lies a multi-layered well hidden and sophisticated attack:

• A Man-in-the-Middle (MitM) attack, as traffic is hijacked via the attacker’s C2 server
• A DNS hijacking vector
• A hardcoded backdoor installed with sudo privileges – all concealed inside an SHC-obfuscated binary dropper
• A Telegram-based reconnaissance, credentials discovery and exfiltration bot (older versions)

What makes this campaign unique is its target: VPN resellers, threat actors who provision compromised or rented Linux servers to sell SSH tunneling and “free internet” access.

FirewallFalcon displays a façade of using the legitimate Brazilian proxy service DTunnel, when in fact the API checks and entire traffic is routed to a threat actor controlled server. The result is a supply-chain attack where operators who install the tool unknowingly hand over full control of their infrastructure to the tool’s author.

To circulate this open-source tool, the threat actor opened two Telegram groups one with almost 4,000 members and the other with almost 1,000 members, while they aggressively push their tool in various other platforms. Our threat intelligence efforts have indicated at least 650 distinct live servers directly linked to the threat actor’s infrastructure.

We present a full technical teardown of the attack chain, the binaries involved, the evidence recovered, the threat actor’s operational model and additional threat intelligence from Open-source, Telegram and Dark web.

Introducing FirewallFalcon: The “Innocent” Facade

Based on its Telegram group and the GitHub repository, the FirewallFalcon ecosystem appears to be a toolset and community focused on managing SSH/VPN tunneling servers, commonly used in “free internet” bypass or proxy-reselling communities. It sits in a gray area between legitimate tunneling tools and infrastructure frequently abused for circumvention and sometimes cybercrime operations.

The GitHub repository follows open-source conventions:

• Well-formatted README with feature descriptions
• Architecture diagrams
• Installation instructions

The “menu.sh” script on GitHub (2,876 lines) is fully readable with no obfuscation, no encoded payloads, and no hidden downloads. It manages real services (Nginx, HAProxy, systemd units), creates real Linux users, and integrates with legitimate third-party tools (badvpn, dnstt, x-ui).

The underground VPN resellers in regions where “free internet” services are sold via SSH tunneling is the target audience, and they don’t typically perform security audits on their tooling. The professional appearance and functional feature set are specifically designed to build trust in this community.

GitHub README file with a short compact installation as a single command

The advertised feature set is extensive and appears professional:

• Multi-protocol support (V2Ray/XRay, DNSTT/SlowDNS, UDP tunneling, SSH WebSocket)
• Nginx gateway orchestration with automatic SSL/TLS termination
• SSH user management with connection limits
• Backup and restore functionality
• Free domain generation via deSEC.io DNS API
• SSL certificate management via Let’s Encrypt

A dedicated Telegram channel (“t.me/FirewallFalcons”) serves as the project’s community hub with almost 1,000 members as well as advertisements in various other Telegram channels.

What Firewall Falcon Actually Is

In reality, FirewallFalcon is a simple wrapper that hides encrypted, packed hidden scripts. In older versions this script overwrite another script to exfiltrate sensitive data and leave a backdoor on the server. In newer versions, it enables full MitM attack on the victim server.

FirewallFalcon group isn’t distributing free gifts, they’re providing a free booby-trapped hack tool to other hackers to do the dirty work of provisioning servers while the FirewallFalcon operator maintains full visibility and control over their operations.

Full Technical Analysis of FirewallFalcon Manager

The installation is performed using a single command that downloads and executes (under root mode) an installation script from the FirewallFalcon-Manager GitHub repository.

A single command installation

We created a secure lab environment to install and analyze the tool. The section below reports on the most significant findings that appeared in the FirewallFalcon manager analysis.

Entry Point: FirewallFalcon-Manager/install.sh

The install script is benign, it downloads and runs from GitHub the script menu.sh, which mainly installs and runs the FirewallFalcon menu and configure SSH access to the system which:

• Allows direct root SSH access
• Enables password-based auth
• Allows SSH tunneling
• Enables PAM
• Defines a custom banner under /etc/bannerssh

Executing the single command installation

Main Management Script: FirewallFalcon-Manager/menu.sh

When the script runs without arguments, it presents a menu with options to install various proxy/tunneling components.

Main menu options

The DT Tunnel option (menu [10])

The menu offers many installation options. We analyzed all of them but will focus on the malicious ones.

Why Victims Choose DT Tunnel

When choosing the DT Tunnel Proxy, a MitM attack is initiated. The chances of a user choosing DTunnel are high. DT Tunnel has its own top-level menu entry, that is what the Telegram marketing promotes, and that the alternatives are single-protocol. Users seeking proxy/tunneling functionality (which is the entire point of the tool) would naturally install it. So while technically optional, it’s the feature most users would enable. In reality, nobody would skip it as the alternatives in the Protocol Manager are basic, single-purpose tools: a UDP relay, a DNS tunnel, an HAProxy config. They handle one protocol each.

DT Tunnel is the premium, full-featured option. It’s the only one that:

• Has its own dedicated top-level menu entry (option [10] on the main menu, alongside the Protocol Manager)
• Has a sophisticated management UI (main.sh) with SSL support, token auth, SSH-only mode
• Is branded as the tool’s flagship – “DT Tunnel” is what the Telegram marketing promotes
• Supports multi-port, per-port systemd services, log viewing

The other protocols are supplementary, things you’d run alongside DT Tunnel, not instead of it. BadVPN is a UDP forwarder. DNSTT is niche (DNS tunneling). SSL Tunnel is just HAProxy. None of them replace what DT Tunnel does.

DT Tunnel Installation Flow

The DT Tunnel is installed from the FirewallFalcon account under ProxyMods/install.sh. A binary named install_mod is downloaded and executed.

The script itself:

1. Writes a hardcoded token: echo “firewallfalcon” > “$HOME/.proxy_token”.
2. Downloads install_mod (x86_64) or Arminstall_mod (ARM) from GitHub.
3. Runs the binary as root via sudo ./$FILENAME.
4. Deletes the binary after execution.

The binary install_mod (SHA256: a18d2ec4506d7d3865d68fc54004288ceaafde2beb1ad38f526bab3db165e302 ) is a 2.3MB statically-linked Go ELF executable. Its main functionalities are:

• Contains a hardcoded DTunnel backend server – 89.168.51.93 proxy.dtunnel.com.br.
• Links the IP address and DTunnel subdomain in /etc/hosts.
• Runs update-ca-certificates
• Installs a custom CA certificate to /usr/local/share/ca-certificates/falconfire.crt (this is a TLS root certificate that gets added to the system trust store)
• Branded “Mod by @firewallfalcon”
• Contains embedded PEM certificate data (—–BEGIN CERTIFICATE—– / —–END CERTIFICATE—–)

The DT Tunnel option pins proxy.dtunnel.com.br to 89.168.51.93 in /etc/hosts, so every request resolves to the attacker’s host and is validated against a certificate the installer has already added to the system trust store.

Understanding DTunnel: The Legitimate Service Being Impersonated

DTunnel (dtunnel.com.br) is a Brazilian commercial tunneling/VPN platform. It provides a proxy server binary that operators can deploy on their own VPS to create SSH, SOCKS, and HTTP proxy tunnels for end users. Operators buy tokens from DTunnel, deploy the proxy binary on their servers, and the binary validates their paid subscription via API at proxy.dtunnel.com.br.

Validating the MitM Attack

The business model is essentially SaaS licensing: operators buy tokens from DTunnel, deploy the proxy binary on their servers, and the binary validate their paid subscription via API:

Since FirewallFalcon’s Dtunnel service references the Brazilian service in code, we wanted to validate the subscription mechanism. First, we checked to which IP address the API resolves on another server (dig proxy.dtunnel.com.br), and received IP addresses 104.21.81.128 and 172.67.160.230. Both of these are Cloudflare addresses. This creates a strong contrast between the legitimate service that sits behind Cloudflare with a CA-issued certificate and the impersonating host which is a bare VPS with a self-signed one.

dig request for the legitimate tunneling service

We extracted the hardcoded “proxy_token” and sent a curl validation request:

Using the proxy token to verify valid status

Then we ran a full verbose mode, and the result was surprising, as the IP address was 89.168.51.93, with no connection to the legitimate service. The certificate was self-signed, and this pair matches what was dropped in the encrypted payload.

A full verbose API request to the fake application

When we check the proxy.dtunnel.com.br certificate details, it’s not self-signed and the details are completely different.

Finally, we inspected /etc/hosts. The last row indicates that IP address 89.168.51.93 will be used for the Dtunnel proxy subdomain.

The modified /etc/hosts

This validates that any traffic on the server via proxy.dtunnel.com.br is redirected to a server fully controlled by the FirewallFalcon operator.

Binary Analysis with Ghidra

To complete our analysis, we inspected the binary install_mod with Ghidra. The binary does exactly three things in sequence:

1. Install rogue CA certificate:

Below is a Ghidra screenshot of the main function:

The malicious function above writes the full 1,134-byte PEM cert to /usr/local/share/ca-certificates/falconfire.crt. The function checks whether /etc/hosts already contains the 33-byte entry before writing it.

2. Activate the rogue certificate:

The command below forces the OS to reload its CA trust store, making falconfire.crt a trusted root certificate. After this, any TLS connection to *.dtunnel.com.br will trust this fake cert without browser/app warnings.

3. Hijack DNS resolution:

This appends a hosts entry that forces proxy.dtunnel.com.br to resolve to 89.168.51.93 – so the pre-empting DNS resolution for that hostname will use 89.168.51.93 for that domain.

If NOT found:

The Complete MitM Attack Chain

Based on the binary and the installation analysis, this is a proxy hijacking via TLS MitM attack:

1. The victim installs FirewallFalcon-Manager and selects “DT Tunnel” from the menu.
2. The binary install_mod runs as root (via sudo) and silently: plants a rogue CA cert trusted by the entire system, and forces all DNS for proxy.dtunnel.com.br to point to 89.168.51.93
3. The victim then installs the DTunnel proxy binary, which connects to proxy.dtunnel.com.br.
4. Because of the hosts file hijack, it connects to 89.168.51.93 instead of the real DTunnel server.
5. Because of the rogue CA cert, the TLS handshake succeeds without errors – the victim’s system trusts the fake certificate.
6. The operator of 89.168.51.93 can now intercept, inspect, and modify all traffic passing through the tunnel.

The attacker (firewallfalcon) is essentially stealing DTunnel users’ traffic by redirecting them to their own server while making the TLS connection appear legitimate.

Older Versions: Even More Malicious

Our analysis included malicious file hunting and recovery from the GitHub history of the firewallfalcons/FirewallFalcon-Manager repository. The commit history reveals a clear evolution of the installation approach.

Self-Extracting Installer (August 2025 to December 2025)

The original install.sh (first commit 9ebe030) was a simple dispatcher. It downloaded 64install.sh (for x86_64) or arminstall.sh (for ARM), executed them, then deleted them.

The Malicious Self-Execution Installer: 64install_v3.sh

The git log shows 64install_v3.sh was uploaded and deleted repeatedly, at least 10 cycles of add/delete over four months. It’s a self-extracting installer — a bash script with an ELF binary appended after line 55 (# — PAYLOAD START —).

The script:

1. Checks for root privileges
2. Installs bc if missing
3. Finds the # — PAYLOAD START — marker in itself
4. Extracts the binary payload (everything after that marker) to a temp file
5. Installs it as /usr/local/bin/menu with mode 755
6. Runs menu –install-setup
7. Deletes the temp file

The embedded payload is a small C/C++ ELF binary (140KB, dynamically linked, stripped, compiled with GCC 13.3 on Ubuntu 24.04). It uses execvp, getenv, putenv, stat, getpid, sscanf, atoll, memcmp — this looks like a packer/loader that decrypts or deobfuscates the actual menu.sh script content and writes/executes it. The strings are mostly garbage (encrypted/compressed data), with the only readable operational string being E: neither argv[0] nor $_ works.

Evolution to the Current Approach (December 2025 to Present)

On December 22, 2025, the author made a series of commits around install.sh. The new approach downloads menu.sh directly (fully visible content), while the malicious payload (install_mod from ProxyMods) is a separate binary downloaded later in the execution chain. The SHC encryption was abandoned in favor of a cleaner and stealthier attack vector.

Direct Download (December 2025 – Present)

On December 22, 2025, the author (firewallfalcons <[email protected]>) made a series of commits all around the install.sh file. The new approach is described fully above.

Analysis of 64install_v3.sh: A Triple-Layered Trojan Dropper

64install_v3.sh is a self-extracting installer that embeds a completely different version of the older script. It’s encrypted inside a compiled binary using SHC (Shell Script Compiler):

• Layer 1: A bash script that looks like a normal self-extracting installer
• Layer 2: An SHC-compiled ELF binary that resists static analysis and decryption
• Layer 3: An encrypted shell script containing a functional management tool plus a Telegram exfiltration bot and a universal SSH backdoor

The 64install_v3.sh script

Telegram bot reconnaissance data exfiltration

The reconnaissance data includes IPv4 and IPv6 information, hostname, full OS info, CPU model, CPU core count, total RAM and disk space.

Simple and effective backdoor

We ran the script in our own lab on our own servers and were able to get root SSH access (to our own environment) with the threat actor’s username and password. In the threat intelligence section, we show how we detected machines with old versions that enabled user:password access.

Combining the Telegram bot reconnaissance with full internet SSH access and a backdoor makes the tool a very powerful supply chain attack on whoever downloads it.

The self-extracting binary was more opaque. The actual menu script was embedded inside a compiled C binary, making it harder to inspect what was being installed. The repeated add/delete cycles of 64install.sh (10+ times in 4 months) suggest the author was frequently updating the embedded binary payload – each cycle likely contained a new version of the packed menu.sh with different functionality. Eventually, the threat actor switched to a direct download of the menu.sh, when the content is completely visible. While the malicious payload (install_mod from ProxyMods) is always a separate binary downloaded later in the execution chain. In addition, the entire traffic is passed via a MITM capability.

The Protocol Manager: Weaponized Open-Source Tools

Now let’s say you decided not to install the DT protocol manager. You still have the menu [9] with all the capabilities.

Legitimate Popular Projects

Gathering Threat Intelligence on FirewallFalcon

Operation Timeline

The threat actor is constantly working on the infrastructure, persistence, and defense evasion techniques, much like legitimate open-source projects publish new product features. Key transitions include migrating from a personal machine to staging and C2 server, migrating from using a website (thefirewoods.org) to GitHub, and introducing stealthier malicious elements in mid-2025.

Previously, the installation script was served directly from the landing page. It now redirects to GitHub.

Underground Presence and Advertising Activity

We analyzed the content of the FirewallFalcon Telegram group (https[:]//t[.]me/firewallfalcons). The content indicates the group functions primarily as the public operational and support channel for the FirewallFalcon Manager toolset rather than a typical attacker coordination chat.

The first available message is a bit misleading saying “Firewall Falcon Manager update is coming soon.” This may either indicate that the first message is a continuum of another forum or group or that this is .a pinned message from a later time, or there are more messages in the history of the group. But it’s hard to tell, in any case it seems like the application wasn’t first created and introduced in November 2025.

The first available message

Analysis of the group’s content indicates there were 949 messages between November 2025 and March 2026, when there are on average ~6 daily messages. While there are more than 800 group members, only 247 participated in the discussions. Activity is heavily centralized around the project operator:

• The user FirewallFalcon posted 135 messages (14.2%), who is the Admin/operator. He posts announcements, updates, payloads, and troubleshooting.
• The user “. 😎” – 37 messages.
• The user Sky1netj – 32 messages.
• The user MedusaXD – 29 messages.
• And the user Ordi – 25 messages.

Participation consisted of questions, troubleshooting, and discussions about deployment. This distribution suggests a developer-to-community dynamic where one primary operator maintains the project while dozens of users interact with the software and request assistance. The admin is bilingual (English + Arabic), posting most announcements in both languages. We analyzed the posts’ languages:

Geographic and Demographic Profile

Based on the appearance of flags in the names, language analysis, and self-testimony of the participants indicate they come from a specific country, the group’s members are strongly linked to Middle East and North Africa with a secondary Sub-Saharan African presence. Members who display country flags in their names include eight from Egypt, five from Morocco, four from Saudi Arabia, and one from Algeria. Other indicators suggest users from Iraq, Tunisia, Turkey, Ghana, Tanzania, Kenya, Senegal, Ivory Coast, India, Pakistan, Bangladesh, Sri Lanka, Italy, Brazil, and Chile.

Main takeaways from the group analysis:

• The group is a support/distribution channel. It’s not a development forum. Users ask for help installing, troubleshooting connectivity, and finding working “bug hosts” (zero-rated domains to exploit).
• Free internet exploitation is the core use case: users are bypassing ISP restrictions and zero-rating policies using SSH tunneling, WebSocket proxies, V2Ray, and domain fronting through social media package hosts.
• There’s a link and reference to DTunnel (the Brazilian proxy tool). FirewallFalcon openly distributes a “cracked” version of Dtunnel (Brazilian proxy tool) with the token validation bypassed, which turns out as a MitM.
• Target ISPs mentioned: Mobily (Saudi Arabia), Ivory Coast networks, various African/MENA carriers with social.
• Posts often include references to zero-rated network paths (FreeBasics), proxy endpoints, tunneling payloads, hosting infrastructure, and occasionally telecom-related tooling or services (e.g., eSIM or network routing tips).

FreeBasics is a program originally launched by Meta (previously Facebook) that allows mobile users in some regions to access a limited set of websites and services without using mobile data. It works through partnerships with mobile carriers, which “zero-rate” specific approved services so they remain reachable even when a user has no data balance. The goal was to improve internet accessibility, though it has also raised debates around net neutrality and traffic control.

Telegram message about FreeBasics (Flare link to post, sign up for the free trial to access if you aren’t already a customer)

The overall activity suggests a mix of experimentation, tool promotion, and operational sharing within communities interested in network evasion, unrestricted connectivity, or multi-protocol tunneling technologies, rather than traditional software development or enterprise networking use cases.

Hardcoded DNS Token

As part of the code analysis we identified a hardcoded deSEC Token. This service is a free DNS hosting service, which enables everyone to delete, modify or hijack this DNS service with the token. This also illustrates that at any given time FirewallFalcon can control the DNS traffic on their users systems. Details in this section are deliberately limited: specificity here would help attackers more than defenders.

The DNS infrastructure behind “manager.firewallfalcon.qzz.io” reveals that FirewallFalcon is not just a simple server-management toolkit, but part of a coordinated backend used to organize and control a large pool of distributed nodes. We extracted hundreds of DNS records containing 314 unique IP addresses created over a relatively short period (30 days).

Subdomains are following repeatable naming conventions such as vps-*, ns-*, and tun-*. This is a strong indicator of automated provisioning. Rather than a handful of static servers, the DNS shows a living infrastructure that continuously registers new nodes, rotates addresses, and exposes role-based naming patterns consistent with a service designed to manage tunnel endpoints, VPS relays, and DNS-related components at scale.

This becomes far more significant in the context of FirewallFalcon’s attack chain. The tool embeds a shared deSEC API token, giving the operator centralized control over DNS records used by every installation. That means DNS is not merely a convenience feature for users setting up proxy or tunneling services, but it is part of the attacker’s control plane. Through this mechanism, the actor can create, modify, or remove records across the entire infrastructure, enabling dynamic redirection of traffic, management of tunnel nodes, and visibility into operational servers deployed by victims. In practice, this supports the broader supply-chain compromise: operators who believe they are installing a “free” VPN or proxy management platform are in fact enrolling their servers into an attacker-controlled ecosystem.

The structure also helps explain how FirewallFalcon scales beyond a single compromised machine. The combination of shared DNS management, rapidly created subdomains, mixed IPv4/IPv6 deployment, and reusable naming patterns points to a backend designed for coordination, not just hosting. In older versions, the campaign used Telegram for server reconnaissance and backdoor access; in newer versions, the operation appears cleaner and more mature, with DNS and the rogue DTunnel interception path serving as quieter, more durable mechanisms of control. In other words, the DNS records are not just artifacts, they are evidence of an operational framework that lets the attacker manage a distributed fleet of servers installed by other threat actors.

From the old DNS system under thefirewoods.org we extracted 77 subdomains, but only five are resolving and active.

Victims Distribution Analysis

We identified 314 distinct servers listed under the FirewallFalcon free DNS account. The classification:

1. Commodity VPS/hosting platforms (~48%): Contabo, DigitalOcean, IONOS, Hetzner, OVH, Linode, etc. This is consistent with software that’s easy to deploy on cheap, fast-to-provision, disposable servers used as relays, proxies, or tunnel endpoints.
2. Hyperscalers (~22%): AWS, Oracle, Alibaba, Azure, GCP, etc. These may reflect opportunistic deployment (such as compromised cloud accounts, short-lived instances, or “background” internet infrastructure) rather than a preference for enterprise-grade hosting.
3. Low-friction gray hosting and “utilities” networks (~14%): Internet Utilities, Freakhosting, Febzen/OVABIL, etc. These may suggest environments with rapid setup or security controls that can make operating proxy/tunneling stacks easier.
4. Regional or boutique providers (~16%): Niche firms, resellers of small ISPs that may reflect edge deployments, customer-hosted servers, or occasional infected/non-standard infrastructure rather than mainstream cloud.

This distribution suggests that at least 50% of the FirewallFalcon was installed illegally to camouflage malicious activity as a defense evasion tool. Below you can observe servers geo-location distribution:

VPN Reseller Tier: Identified Operators

Below you can observe a partial list of the FirewallFalcon users or the VPN resellers tier.

Similar Campaigns by FirewallFalcon

We also found a message advertising access to a shared SSH proxy server that users connect to through the HTTP Custom Android app, a tunneling client that allows traffic to be routed through remote servers using SSH, HTTP, or TLS tunnels.

Shared SSH proxy advertisement

By entering the provided hostname (zfalcon.quantumz.co.uk) and credentials (falcon / falcon), users can create an encrypted tunnel from their phone to the VPS server, which then forwards their traffic to the internet. In practice, this makes the VPS act like a DIY VPN exit node, commonly used in Telegram communities where operators distribute shared server access to many users.

The instruction “SNI use your bug host instead” refers to a telecom-bypass technique where users modify the TLS Server Name Indication (SNI) field to mimic a domain that their mobile provider allows for free or unrestricted traffic. By disguising the connection as traffic to that allowed domain, users can route their real traffic through the SSH tunnel while appearing to connect to a legitimate service. This ecosystem is typical of “free internet” or tunneling communities, where operators run VPS servers, distribute configurations through apps like HTTP Custom, and sometimes sell or share access through Telegram channels such as the one operated by FirewallFalcon.

Threat Actor Analysis

In most open-source communities and projects, the developer identity is public and well advertised, with links and ways to communicate and contact, help the project and contribute or just say hello and exchange information. In this case, we had to make extra efforts to locate information related to the threat actor, which strengthened our assumption that FirewallFalcon is a threat actor and not a legitimate open-source project developer.

Known identifiers:

• Nickname: FirewallFalcon
• Telegram channel: https[:]//t[.]me/firewallfalcons
• Domain: thefirewoods[.]org

Linguistic Analysis

We utilized a language model to ask “Where is FirewallFalcon from?” The assessment indicated Egyptian origins with some Saudi Arabia or Gulf influence. Key indicators include:

• Uses modern standard Arabic with colloquial leaks, consistent with an educated Egyptian writing formal Arabic for a mixed audience
• Strong Egyptian dialect markers including characteristic taa marbuta and informal spelling patterns
• Casual Egyptian slang and lingo
• English technical terms embedded in Arabic sentences naturally, typical of Egyptian/Gulf tech communities
• Several markers indicate Saudi Arabia/Gulf dialect, which could mean Saudi origins, Saudi residence, Gulf residence, audience adaptation, or multiple operators
• Specific knowledge of Egyptian and Saudi ISP/Carriers plans and mobile packages (shares configs for Mobily, Zain, and Ooredoo (Saudi/Gulf carriers) and Telecom Egypt, with the Egyptian reference getting a flag emoji)
• A PayPal donation link shared in February contains the name “Mahmoud” in the email, a name common across Arabic countries but very high frequency in Egypt
• Bilingual announcements (English first, Arabic second) suggests strong English proficiency and an international audience focus

Technical Sophistication

The FirewallFalcon ecosystem reflects a relatively high level of engineering maturity and operational awareness. Rather than relying on a single malicious script, the threat actor developed a multi-component toolkit that combines custom binaries, open-source networking tools, and infrastructure automation. Several indicators point to a developer with strong familiarity with both low-level networking and Linux system internals.

Key capability indicators include:

• Multi-language development: including custom components written in Rust (tokio async networking), C++ (Asio networking framework), and Go, suggesting comfort with high-performance network programming
• Cross-platform compilation: binaries built for both x86-64 and ARM64 architectures, enabling deployment across diverse VPS providers and hardware environments
• TLS/PKI expertise: deliberate injection of a rogue CA certificate into the system trust store to enable transparent MitM interception without generating TLS warnings
• Operational security awareness: use of SHC encryption to hide malicious payloads, periodic binary replacement, and sanitized public repositories to maintain a clean facade
• Deep Linux administration knowledge: manipulation of systemd services, PAM authentication modules, iptables firewall rules, SSH configuration, and DNS settings

The tool’s name, FirewallFalcon, may evoke associations with CrowdStrike Falcon (a firewall management tool) and create a false sense of legitimacy. That branding choice could psychologically increase trust in the project, leading users to mistakenly perceive it as a security product or as somehow connected to CrowdStrike.

Taken together, these elements suggest that FirewallFalcon is not an improvised attack script but rather a purpose-built operational platform designed to manage and exploit a distributed network of proxy and tunneling servers.

How We Discovered This Campaign

As part of our research infrastructure, we operate several honeypots across multiple cloud and VPS hosting providers. One of these VPS honeypots was eventually compromised, and during the intrusion the attacker deployed and operated the FirewallFalcon toolkit.

At first glance, the attack itself did not appear particularly unusual. The compromised server was simply used to provide SSH tunneling services. However, when we began examining the tools involved, something felt off. The GitHub repository was polished. The Telegram community was active.

The actor promoting FirewallFalcon had clearly invested significant effort into distributing and marketing the tool across numerous Telegram groups and channels. It was presented as a sophisticated proxy management platform, offering modern tunneling capabilities and a polished user interface. But this raised an important question:

What exactly does the author/promoter gain from distributing such an advanced tool for free?

In the legitimate open-source world, developers often receive recognition, community trust, and sometimes even career opportunities as a result of widely adopted projects. There are many examples of this. In this case, however, the developer remained completely anonymous, while aggressively promoting the software across underground communities investing time and efforts while doing so.

This discrepancy led us to investigate further. We set out to understand the real motivation behind an actor distributing advanced VPN infrastructure tooling at no cost. As our analysis progressed, we uncovered several troubling mechanisms and artifacts hidden beneath the surface.

Ultimately, this investigation serves as another reminder of a simple but powerful rule: if you cannot identify the product, you are probably the product, or, in this case, your infrastructure and your data are.

MITRE ATT&CK Framework

FirewallFalcon combines multiple ATT&CK techniques across Initial Access, Persistence, Credential Access, Defense Evasion, Discovery, Collection, Command and Control, and Adversary-in-the-Middle. The campaign relies on a supply-chain style delivery mechanism, where a trojanized infrastructure-management tool is installed by the victim themselves, then used to establish persistent privileged access and silently redirect traffic.

Notable ATT&CK mappings include T1195.002 (Supply Chain Compromise) for the weaponized GitHub-distributed installer, T1543.002 (Create or Modify System Process: Systemd Service) for persistence, T1078 / T1136 (Valid Accounts / Create Account) for the hardcoded SSH backdoor user, T1556 (Modify Authentication Process) and T1553.004 (Subvert Trust Controls: Install Root Certificate) for the rogue CA and transparent DTunnel interception path, T1016 (System Network Configuration Discovery) and T1082 (System Information Discovery) for host profiling, T1041 (Exfiltration Over C2 Channel) for Telegram-based data exfiltration in older variants, and T1562.001 (Impair Defenses) for weakening SSH settings and concealing malicious behavior inside otherwise legitimate tooling.

At a high level, FirewallFalcon shows how ATT&CK techniques typically associated with enterprise intrusions can be repurposed inside underground ecosystems, turning trusted operational tooling into a covert control and interception platform.

What Defenders Should Keep in Mind

FirewallFalcon is a reminder that supply-chain risk does not stop at mainstream open-source ecosystems. Threat actors are increasingly distributing polished, functional tooling into gray-market communities, embedding backdoors inside software that appears operationally useful and trustworthy. In this case, the installer runs as root, blends legitimate components with weaponized ones, and turns each deployed server into infrastructure the operator can silently monitor, redirect, or reuse.

Defenders should treat third-party infrastructure tooling, especially root-level installers, unsigned binaries, and “free” management platforms distributed through Telegram, GitHub, or direct links, as untrusted until proven otherwise. The right questions are:

• What does the tool do for the user?
• What access does this tool grant its author?
• What trust stores, DNS settings, or authentication paths does the tool modify?
• Does it introduce hidden control channels?

From a software supply-chain perspective, any tool that installs opaque binaries, rewrites /etc/hosts, adds certificates, weakens SSH settings, or reaches out to hardcoded external services should be treated as a high-risk compromise vector, not just an administrative utility.

Who is at Risk?

• End users: Purchasing a seemingly legitimate (or gray-area) internet service such as streaming, cheap VPN, or similar. In reality, SSH credentials are stored in plaintext, traffic can be MitM’d via DNS hijacking, and connections route through cracked software of unknown integrity
• Server operators (VPN resellers): Running opaque root-level binaries from untrusted sources, with weakened SSH configs, on servers whose DNS can be hijacked by anyone who finds the public GitHub repo
• The DTunnel developer: Their commercial product is being pirated and their reputation is at stake

The Takeaway About Firewall Falcon Manager

FirewallFalcon Manager is a textbook example of a supply-chain attack tailored to a specific underground ecosystem. The attacker identified a niche market (VPN resellers who need management tooling for their SSH tunneling operations), built a genuinely functional product that solves real operational problems, and distributed it freely to build trust. The tool works. The interface is polished. The features are real.

However, the bigger picture extends far beyond the resellers themselves. The infrastructure operated by these VPN providers ultimately serves the end users of the service, potentially thousands or even hundreds of thousands of devices, including mobile phones, personal computers, and servers. Depending on who operates these VPN services: legitimate businesses, gray-market operators, or outright malicious actors, the scale of the exposure grows dramatically. What initially appears to be a niche compromise of a reseller ecosystem can quickly become a large-scale traffic interception opportunity affecting a much broader population.

But beneath the surface, five independent backdoor mechanisms ensure that the attacker maintains persistent access to every server that installs the tool:

1. Hosts file modification redirects the proxy’s control plane through attacker-controlled infrastructure.
2. A rogue CA certificate allows transparent MitM interception of DTunnel proxy traffic.
3. A fake authentication mechanism to a legitimate third party (DTunnel proxy) disguises the behavior.
4. A hardcoded sudo user enables immediate SSH root access using a universal password (some versions).
5. Telegram reconnaissance provides real-time notifications of new installations, including detailed server specifications (older versions).

In past versions there was an installer binary that was protected with SHC obfuscation, specifically to conceal the Telegram bot and backdoor user from anyone inspecting the code. Meanwhile, the public GitHub repository contains a sanitized version of the tool with these components removed, presenting a clean façade for a malicious implementation.

The irony is both deliberate and structural. End users buy cheap VPN, free internet services, or streaming services. The VPN reseller installs the tool to profit from selling unauthorized VPN access. The FirewallFalcon operator profits from the VPN reseller’s operation and its end users by maintaining invisible root access to every server in the fleet. In effect, the supply chain of the underground economy is being exploited by the very tools it depends on.

Indicators of Compromise (IOCs)

Appendix: How These Tunnel Stacks Work

Technical Analysis of FirewallFalcon

For readers unfamiliar with the underlying architecture FirewallFalcon exploits, this appendix explains how modern tunneling stacks operate.

The Core Concept: One HTTPS Entry Point, Many Hidden Services

At a high level, these stacks are built around three layers:

• Entry Layer: Web Infrastructure (Usually Nginx) that acts as the public-facing HTTPS server and traffic router.
• Transport Layer: Tunnel Frameworks (V2Ray, XRay, WebSocket tunnels, DNS tunnels)Encapsulate traffic inside allowed protocols.
• Service Layer: Actual Functionality, which include VPN connections, SSH sessions, proxy relays, or arbitrary TCP tunnels.

From the outside, defenders typically only see ordinary HTTPS traffic that blends perfectly with the server’s legitimate activity. The real activity happens after TLS is terminated and traffic is routed internally.

An ordinary HTTPS traffic which perfectly blends with the server’s activity

Why Reverse Proxies are Key

Reverse proxies like Nginx are useful because they can handle the TLS (HTTPS) encryption and decryption on behalf of backend services. This means internal applications can communicate in plain traffic while Nginx manages certificates, encryption, and secure client connections.

Unlike firewalls that route based on ports, reverse proxies can route based on:

• HTTP headers
• Hostnames
• WebSocket upgrade requests
• TLS metadata (SNI, ALPN)

This enables multiple hidden services behind a single IP and port.

Transport Camouflage: Making Tunnels Look Like Web Apps

Traditional VPNs create a single, obvious encrypted tunnel between a client and a VPN server, which is usually easy to recognize as VPN traffic.

Traditional VPN model

Modern pluggable transport models go further by hiding tunnel traffic inside common web technologies, making it look like normal internet usage instead of a dedicated VPN connection.

Modern pluggable transport model

Modern pluggable transport models hide tunnel traffic inside common web technologies:

In practice, the real data (like SSH or VPN traffic) is encapsulated inside WebSocket, then encrypted with TLS, then sent over normal HTTPS – making it appear nearly identical to legitimate SaaS or web application traffic to most network monitoring tools. A common encapsulation chain looks like:

• SSH or VPN data
• Inside WebSocket frames
• Inside TLS encryption
• Inside standard HTTPS session

To most network tools, this looks indistinguishable from SaaS application traffic.

DNS Tunneling: The “Always Allowed” Channel

Some frameworks also support DNS-based tunnels. Instead of sending data directly, data is encoded into DNS queries:

This is slow but extremely resilient, since DNS is rarely blocked in enterprise networks.

The Role of “Universal Proxy” Components

Some stacks include proxy components that:

• Accept arbitrary payloads
• Return valid HTTP responses even for invalid clients
• Forward raw byte streams internally

This provides two advantages:

1. Scanner Resistance: Random probes see a normal web server response.
2. Protocol Flexibility: Any TCP-based protocol can be transported through the same infrastructure.

Everything Runs Over Port 443

Most enterprise and ISP networks allow HTTPS by default. Many block or inspect:

• VPN ports
• SSH ports
• Unknown protocols

By making everything appear as HTTPS, tunnel operators inherit the trust model of web traffic.