Executive Summary
- Trend Micro posted a blog detailing how attackers are using CVE-2025-3248, a critical vulnerability in the Langflow AI framework, to install a botnet called Flodrix. Along with their analysis, they also disclosed the C2 server associated with the campaign.
- The botnet’s C2 server exposed a portmapper and an NFS (Network File System) share, allowing us to identify 745 compromised hosts.
- The discovered binaries included ARM-targeted malware and shell scripts resembling traditional Mirai payloads.
- Most infected devices ran the outdated Boa web server, and ~50% appeared to be internet-connected cameras. The majority of infected hosts were located in Taiwan.
- We’ve published a GitHub Gist containing all the hosts observed mounting binaries from the C2 server.
Introduction
On June 17, 2025, Trend Micro disclosed information on an active exploitation campaign leveraging CVE-2025-3248, a critical unauthenticated remote code execution (RCE) vulnerability in Langflow, to deliver a Mirai variant known as the Flodrix botnet.
While Trend Micro’s report provides deep technical insight into the vulnerability and malware, this post explores a different angle: how a minor misconfiguration on the command-and-control (C2) server led us to identify hundreds of compromised hosts actively participating in the Flodrix network.
In the scenario described by Trend Micro, attackers use CVE-2025-3248 to gain a shell on vulnerable Langflow servers. After performing reconnaissance, they install the Flodrix malware, which connects back to a hardcoded C2 server: 80.66.75.121. Once the connection is established, the infected host waits for instructions, typically in the form of various DDoS attack commands.
Taking a look at the C2
Fortunately, the C2 server was still online at the time of our investigation. Viewing the host in Censys (see the screenshot above) revealed several exposed services. One in particular stood out: an HTTP server on TCP port 3000, with the page title “Killer Logger Dashboard”. Visiting the service displayed a login screen in Russian, requesting an API key.
This appeared to us to be an administration interface that exposed several API endpoints, and if we look at the source of the page, we can try to estimate their functionality:
While this was interesting, there isn’t much more we can do with it outside of just knowing what endpoints we can query and some basic metadata about each.
Portmapper
Another exposed service caught our attention: PORTMAP (TCP/UDP port 111). Portmap is a legacy service used by RPC (Remote Procedure Call) applications. Think of it like a receptionist: when an RPC-based service starts up, it checks in with portmap to register its service and assigned port. Clients simply ask the portmap server, “Which port is service X using?” and then connect directly.
However, if you are familiar with the portmapper protocol, you can obtain a list of all currently registered services. Below, we see how Censys lists these services:
One of the services registered with this C2’s portmapper was NFSD (Network File System Daemon), which indicated to us that the host was exposing a remote file share.
Mounting the C2
Since this was just a service on a host, we used the showmount utility to list the exported directories:
% showmount -e 80.66.75.121
Export list for 80.66.75.121:
/nfs2 *This revealed a single shared path: /nfs2. We mounted the share and found some binaries and shell scripts:
% mkdir -p tmp/mount && sudo mount -t nfs 80.66.75.121:/nfs2 tmp/mount && cd tmp/mount
% sha256sum *
ab0f9774ca88994091db0ae328d98f45034f653bd34e4f5e85679a972d3a039c e1x.arm
c2bcdd6e3cc82c4c4db6aaf8018b8484407a3e3fce8f60828d2087b2568ecca4 e1x.arm5n
c2bcdd6e3cc82c4c4db6aaf8018b8484407a3e3fce8f60828d2087b2568ecca4 e1x.arm6
a6cf8124e9b4558aacc7ddfa24b440454b904b937929be203ed088b1040d1b36 e1x.arm7
9f48ec760c350ee44ec7f08cc20f23f2166647052ee20b1192f94c31c3e9a392 v
03d2c37f4dfc6410c7c669f44750120b456e18c939b6110c15e08c7223167afd x
31d0aa4214717ae4f52621af6d693c4f0e733cc65e971d207203a8c4bef7bf17 x2There were seven files listed in this mount: the malware binaries e1x.arm, e1x.arm5n, a1x.arm6, and e1x.arm7, and alongside them, three shell scripts that all seem to be used for running one of the four binaries, all very reminiscent of Mirai.
Using NFSD to uncover a Botnet
By running the command “showmount -a 80.66.75.121”, we can see a list of hosts currently connected to the C2 server’s NFS share, and this is where things got interesting. The output, shown in the screenshot below, reveals 745 unique hosts across the internet that are actively mounting a directory from this C2 server.
In other words, these hosts are highly likely to be compromised and actively participating in the botnet. It’s extremely rare to gain this level of visibility into a botnet’s footprint using nothing more than an open port (and knowing how to communicate with the exposed services on the host). We’ve published a GitHub Gist containing all the hosts observed mounting binaries from the C2 server. We have also published a search query in Censys that will allow you to view approximately 600 of the 745 listed hosts.
So what do all of these hosts have in common? A few patterns emerged:
- Nearly all hosts run the Boa web server, an insecure HTTP server that was discontinued in 2005 and is known for having a history of exploitable flaws.
- Roughly 50% of the systems appear to be internet-connected cameras, a device class that has been previously exploited en masse by Mirai and its variants.
- The majority of compromised hosts were located in Taiwan, with 540 infected devices, followed by the United States with 17.
These likely represent just a subset of infected systems (those that happen to use NFS to load or update their binaries). Others may use different delivery methods or alternate infrastructure.
Final Thoughts
The reality is that this type of NFS exposure is difficult to avoid, given how attackers are utilizing it. Except for NFSv4, which can operate without relying on the RPC subsystem, older NFS versions are tightly coupled to RPC services, such as portmapper and rpc.mountd. There’s no guarantee the compromised devices even support NFSv4, especially given the prevalence of older or embedded systems. Additionally, applying access controls at the mount level is ineffective, since the connecting IPs are unpredictable and distributed across the internet.
In short, using NFS to transfer files comes with a risk-reward tradeoff. The risk is visibility; researchers like us can easily identify compromised hosts by querying exposed NFS services. But the reward is obscurity and compatibility: many embedded Linux devices support NFS out of the box, and few defenders are actively monitoring for its activity.
However, if you understand all of the little nuances in scan data, there are scenarios like this one where you can uncover valuable pieces of information with the right tools.
