Many AI-first enterprises have already embraced sovereign architectures for general AI initiatives; cybersecurity—and the SOC—should be next.
The post Is The SOC Obsolete, And We Just Haven’t Admitted It Yet? appeared first on SecurityWeek.
Tens of thousands of students studying for final exams around the world have regained access to a key online learning system after a cyberattack had earlier knocked it offline.
The post Canvas System Is Online After a Cyberattack Disrupted Thousands of Schools appeared first on SecurityWeek.
Every engineering team in your organization ships code through a pipeline. They branch, test, review, and deploy. If something breaks, they roll back. If someone asks "what changed?", the answer is in the commit history. This isn't heroic discipline to process; it's just how software gets built.
Now think about how your detection engineering team works.
Rules get written in a UI. Maybe copied and pasted from a wiki. There's no peer review; someone clicks "save," and it's live. No test cases validate the logic before deployment. No rollback if something breaks. When an alert suddenly floods your SOC, good luck figuring out what changed and when. When a detection stops firing, you might not notice for weeks.
This is, by definition, a process gap. And it's one that the rest of engineering solved years ago. The gap becomes manageable through the five custom rules, listed below. As your detections grow, you need the same discipline that every other engineering team already has.
Process Stage | How it works in software engineering | How it works in detection engineering |
Storage | Git / Version Control | UI / Wiki / "Tribal Knowledge" |
Validation | Automated CI/CD Tests | "Wait and see if it fires" |
Review | Peer-reviewed Pull Requests | Single-user "Save" button |
Rollback | One-click git revert | Manual query deletion |
Detection as Code gives your team a structured, repeatable way to build and manage detections with confidence. Instead of relying on manual updates and guesswork, every change is tested, reviewed, and tracked before it reaches production. Before we get into the how, here's why Detection as Code changes the way your team works:
A more reliable process. Every change goes through version control and peer review before it goes live. When something goes wrong, you know exactly what changed, when it changed, and who approved it. Roll back in seconds if needed.
A safety net of tests. Inline test cases validate detection logic before deployment. Positive tests prove it catches the threat; negative tests prove it doesn't fire on legitimate activity.
Confidence in what's deployed. terraform plan previews every change before anything touches production. Terraform state is the authoritative record of your detection estate, not some spreadsheet.
The result is a detection workflow your team can trust. Changes are predictable, validated, and fully traceable, so security teams don’t get caught up in troubleshooting and can focus on improving coverage and overall posture.
Here is what a detection rule looks like using Rapid7’s Terraform provider. It offers a practical view of how detection engineering teams can use Detection as Code in practice:
Loginresource "rapid7_siem_detection_rule" "encoded_powershell" {
name = "Encoded PowerShell Command Execution"
description = "Detects PowerShell launched with base64-encoded commands"
techniques = ["T1059.001"]
action = "CREATES_ALERTS"
priority = "HIGH"
logic = {
leql = <<-LEQL
from(event_type = process_start_event)
where(
(process.exe_path = /.*\\powershell\.exe$/i
OR process.exe_path = /.*\\pwsh\.exe$/i)
AND process.cmd_line ICONTAINS " -e"
AND process.cmd_line ICONTAINS-ANY [
" JAB", " SUVYI", " SQBFAFgA", " aWV4I"
]
)
LEQL
testcases = [
{
matches = true
payload = jsonencode({
process = {
exe_path = "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
cmd_line = "powershell.exe -ep bypass -e JABjAGwAaQBlAG4AdAA="
}
})
},
{
matches = false
payload = jsonencode({
process = {
exe_path = "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
cmd_line = "powershell.exe -File C:\\Scripts\\backup.ps1"
}
})
}
]
}
}Version-controlled logic: The LEQL query defines the threat logic in a text format that Git can track.
MITRE ATT&CK® untegration: The techniques field ensures your coverage map updates automatically.
Inline testing: We aren't just deploying a query, but a validated unit of logic. The pipeline won't let this reach production if the logic fails to fire on the matching" payload or accidentally fires on the un-matching payload.
Because it's the industry standard for managing infrastructure as code. We didn't invent a proprietary CLI; we built on the tool that thousands of platform teams already run daily. If your organization uses Terraform for cloud infrastructure, your detection engineers now use the same tool, the same workflow, and the same review process.
Governance happens naturally in this model. Open a pull request. Your team sees the logic, the test cases, and the expected behavior. They comment, suggest improvements, and approve. Every change is traceable in your commit history. This isn't a separate compliance exercise bolted onto your workflow. It is the workflow.
Already have rules built in the UI? One command imports them all:
terraform query -generate-config-out imports.tf
The quick-start repo ships with IDE configurations for Claude Code, Cursor, VS Code Copilot, and Kiro. These configs give your AI assistant full context on the Terraform provider schema, LEQL syntax, and MITRE ATT&CK mappings.
In practice: open your editor, describe a threat in plain English, such as ‘write me a detection for lateral movement via RDP from non-admin workstations,’ and get back a complete Terraform resource ready for review. The AI accelerates the engineer; it doesn't replace them. The time from "I need a detection" to "this is ready for review" drops from hours to minutes.
Rapid7’s Terraform provider for Detection as Code is now available across all Incident Command and InsightIDR tiers.
To get to work, use the Getting Started guide for a walkthrough as you setup, authenticate, and run your first deployment. Clone the quick-start template, run terraform plan, and see your detection estate as code.
For more information on Incident Command, visit Our hub page for SIEM.
On May 6, 2026, Palo Alto Networks published a security advisory for CVE-2026-0300, a critical unauthenticated buffer overflow vulnerability affecting PAN-OS PA-Series and VM-Series firewall appliances. Prisma Access, Cloud NGFW, and Panorama appliances are not affected by this vulnerability. The vulnerability carries a CVSSv4 score of 9.3 and has been confirmed as exploited in the wild by the vendor.
CVE-2026-0300 is a buffer overflow (CWE-787) in the User-ID™ Authentication Portal (also known as Captive Portal), a non-default PAN-OS feature used to map IP addresses to usernames. An unauthenticated remote attacker can exploit this vulnerability by sending specially crafted packets to a device with the Authentication Portal enabled, achieving arbitrary code execution with root privileges on the affected firewall. No authentication or user interaction is required.
Palo Alto Networks has confirmed limited exploitation in the wild targeting Authentication Portals exposed to either untrusted IP addresses or the public internet. No patches are currently available; fixed versions are expected to begin rolling out on May 13, 2026, with additional releases through May 28, 2026.
PAN-OS is among the most widely deployed enterprise firewall operating systems in the world. Shodan identifies approximately 225,000 internet-facing PAN-OS instances, representing a significant attack surface. Rapid7 strongly urges all organizations running affected PAN-OS versions with the User-ID Authentication Portal enabled to apply the available workarounds immediately and prioritize patching as soon as fixed versions become available.
Update #1: On May 6, 2026, CVE-2026-0300 was added to the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) list of known exploited vulnerabilities (KEV), based on evidence of active exploitation. Palo Alto Networks Unit 42 also published a threat brief attributing observed exploitation to CL-STA-1132, a likely state-sponsored threat cluster that deployed open-source tunneling tools and conducted Active Directory enumeration following initial compromise.
Organizations running PA-Series and VM-Series firewalls with the User-ID™ Authentication Portal enabled should apply the available workarounds immediately and prioritize patching as soon as fixed versions are released. Check the official documentation to establish whether the affected User-ID™ Authentication Portal is currently enabled.
According to the Palo Alto Networks advisory, the following versions are affected by CVE-2026-0300:
Product | Affected | Unaffected | Fix ETA |
|---|---|---|---|
PAN-OS 12.1 | < 12.1.4-h5 < 12.1.7 | >= 12.1.4-h5 >= 12.1.7 | 05/13 05/28 |
PAN-OS 11.2 | < 11.2.4-h17 < 11.2.7-h13 < 11.2.10-h6 < 11.2.12 | >= 11.2.4-h17 >= 11.2.7-h13 >= 11.2.10-h6 >= 11.2.12 | 05/28 05/13 05/13 05/28 |
PAN-OS 11.1 | < 11.1.4-h33 < 11.1.6-h32 < 11.1.7-h6 < 11.1.10-h25 < 11.1.13-h5 < 11.1.15 | >= 11.1.4-h33 >= 11.1.6-h32 >= 11.1.7-h6 >= 11.1.10-h25 >= 11.1.13-h5 >= 11.1.15 | 05/13 05/13 05/28 05/13 05/13 05/28 |
PAN-OS 10.2 | < 10.2.7-h34 < 10.2.10-h36 < 10.2.13-h21 < 10.2.16-h7 < 10.2.18-h6 | >= 10.2.7-h34 >= 10.2.10-h36 >= 10.2.13-h21 >= 10.2.16-h7 >= 10.2.18-h6 | 05/28 05/13 05/28 05/28 05/13 |
Until patches are available, Palo Alto Networks recommends one of the following workarounds:
Restrict User-ID™ Authentication Portal access to only trusted internal zones. Refer to Step 6 of the Live Community article and the Knowledgebase article for instructions on restricting access.
Disable User-ID™ Authentication Portal entirely if it is not required (Device > User Identification > Authentication Portal Settings > uncheck Enable Authentication Portal).
Please refer to the vendor advisory for the latest guidance.
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-0300 with authenticated vulnerability checks available in the May 6th, 2026 content release.
May 6, 2026: Initial publication.
Agency issued guidance and calls on operators to build resilient OT environments capable of surviving extended isolation and cyber compromise.
The post CISA Launches ‘CI Fortify’ to Prepare Critical Infrastructure for Geopolitical Cyber Conflict appeared first on SecurityWeek.
On April 28, 2026, cPanel issued a security update to fix a critical vulnerability affecting the cPanel & WHM and WP Squared products. In the cPanel release notes, the bug was described as "an issue with session loading and saving." CVE-2026-41940, the identifier subsequently assigned on April 29, 2026, has a CVSS score of 9.8 and allows unauthenticated remote attackers to bypass authentication and gain unauthorized administrative access to the affected systems. First-party cPanel & WHM and WP Squared vendor advisories are available.
cPanel & WHM is web hosting control panel software used to manage websites and servers. WHM provides root-level administration, while cPanel acts as the user-facing interface. Successful exploitation of CVE-2026-41940 grants an attacker control over the cPanel host system, its configurations and databases, and websites it manages. A naive Shodan query for potential targets returns approximately 1.5 million cPanel instances exposed to the internet that may be vulnerable.
A managed cPanel host, KnownHost, stated that CVE-2026-41940 is actively being exploited in the wild, with speculation of targeted zero-day exploitation happening as early as February 23, 2026, prior to the vulnerability’s public disclosure. Security firm watchTowr has published a technical analysis and proof-of-concept exploit for CVE-2026-41940. As such, widespread exploitation in the wild is expected to be imminent.
Systems exposing the affected web service software are vulnerable by default.
As of April 29, 2026, a technical analysis and proof-of-concept exploit have been published by security firm watchTowr. CVE-2026-41940 is an authentication bypass caused by a Carriage Return Line Feed (CRLF) injection in the login and session loading processes of cPanel & WHM.
Before authentication occurs, `cpsrvd` (the cPanel service daemon) writes a new session file to the disk. The vulnerability allows an attacker to manipulate the `whostmgrsession` cookie by omitting an expected segment of the cookie value, avoiding the encryption process typically applied to an attacker-provided value. Attackers can inject raw `\r\n` characters via a malicious basic authorization header, and the system subsequently writes the session file without sanitizing the data. As a result, the attacker can insert arbitrary properties, such as `user=root`, into their session file. After triggering a reload of the session from the file, the attacker establishes administrator-level access for their token.
Organizations running on-premise instances of cPanel & WHM or WP Squared should prioritize upgrading to a fixed version on an emergency basis. Some hosting providers have opted to temporarily institute workaround TCP port blocks for cPanel & WHM web services on ports 2083 and 2087. However, defenders are strongly advised to patch, rather than implement workarounds.
Affected Software:
The vendor states that all versions after 11.40 are affected, prior to the following available fixed versions.
cPanel & WHM 11.110.0 versions prior to fixed version 11.110.0.97
cPanel & WHM 11.118.0 versions prior to fixed version 11.118.0.63
cPanel & WHM 11.126.0 versions prior to fixed version 11.126.0.54
cPanel & WHM 11.132.0 versions prior to fixed version 11.132.0.29
cPanel & WHM 11.134.0 versions prior to fixed version 11.134.0.20
cPanel & WHM 11.136.0 versions prior to fixed version 11.136.0.5
WP Squared versions prior to fixed version 136.1.7
Please read the vendor advisory for the latest guidance.
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-41940 with authenticated vulnerability checks available in the April 30, 2026 content release.
A South Florida man pleaded guilty to conspiring with multiple ransomware affiliates to commit attacks against and extort payments from the same U.S. companies he represented as a ransomware negotiator for DigitalMint in 2023, the Justice Department said Monday.
Angelo John Martino III shared confidential information about victim organizations’ internal negotiating positions and insurance policy limits he gained from his work as a ransomware negotiator to extract the maximum ransom payment for himself and other BlackCat affiliates, according to his plea agreement.
Five of Martino’s victims hired DigitalMint, which assigned the 41-year-old to conduct ransomware negotiations on their clients’ behalf — a rare position he exploited to play both sides. DigitalMint, which is not accused of any knowledge or involvement in the crimes, fired Martino the day after the Justice Department informed the company they were investigating him in April 2025.
The five U.S.-based victims that hired DigitalMint and unwittingly tapped Martino to allegedly conduct ransomware negotiations with himself and his co-conspirators include a nonprofit and companies in the hospitality, financial services, retail and medical industries. All five of those victims paid a ransom.
Prosecutors previously said Martino helped accomplices extort a combined $75.3 million in ransom payments, including a nearly $26.8 million payment from the unnamed nonprofit, and a nearly $25.7 million payment from the unnamed financial services company.
Martino also admitted to conspiring with Kevin Tyler Martin, another former ransomware negotiator at DigitalMint, and Ryan Clifford Goldberg, a former manager of incident response at Sygnia, to deploy BlackCat ransomware, also known as ALPHV, against five additional U.S. companies between April and November 2023.
Goldberg and Martin pleaded guilty in December to participating in a series of ransomware attacks and are scheduled for sentencing April 30.
“Angelo Martino’s clients trusted him to respond to ransomware threats and help thwart and remedy them on behalf of victims,” A. Tysen Duva, assistant attorney general at the Justice Department’s Criminal Division, said in a statement. “Instead, he betrayed them and began launching ransomware attacks himself by assisting cybercriminals and harming victims, his own employer, and the cyber incident response industry itself.”
The case against Martino showcases an extreme, albeit rare, example of the dark underbelly of ransomware negotiation as a practice. The pitfalls of ransomware negotiation are excessive and these backchannel negotiations, which remain largely unscrutinized, can go awry for various reasons.
Officials shared a series of chats Martino held with co-conspirators and his victims that exemplify the lengths he went to betray DigitalMint’s clients and empower his accomplices with crucial tips for a successful negotiation strategy.
DigitalMint did not respond to a request for comment on Martino’s guilty plea.
During an incident response with one of his victims, Martino told a BlackCat affiliate the company’s insurance carrier “was only approving small accounts,” according to his plea agreement. “Keep denying our offers and I will let you know once I find out the max the[y] want to pay,” he added.
“We don’t know how you came up with your demand but we are losing money operationally and all of our loans are going to turnover on us this year at double the interest rates,” Martino said in a negotiation chat visible to DigitalMint and the victim organization in the hospitality industry. “We are able to give you $1 million now, which is a very serious offer.”
Following Martino’s instructions, the BlackCat accomplice responded: “Well, you can keep that for the penalties and lawsuits which are coming your way in case we expose you. Time is ticking — we know how much you can pay. Contact your insurance. We know about them also. Stop wasting time.”
That victim company ultimately paid a ransom worth nearly $16.5 million at the time to receive a decryptor and the BlackCat affiliate’s commitment to not publish stolen data. The two other victims Martino represented via DigitalMint at the time paid $6.1 million and $213,000 ransoms for similar commitments.
“Ransomware victims turned to this defendant for help, and he sold them out from the inside,” Jason A. Reding Quiñones, U.S. attorney for the Southern District of Florida, said in a statement.
Martino received a portion of the ransomware payments for his involvement in the conspiracy.
Authorities have seized $10 million in assets and cryptocurrency wallets controlled by Martino. Law enforcement seized multiple vehicles, a food truck and a 29-foot luxury fishing boat that he obtained using proceeds from his crimes.
Officials also seized two properties owned by Martino in Nokomis, Florida, including a bayfront home with an estimated value of $1.68 million and a second single-family home with an estimated value of $396,000.
Martino surrendered in March to the U.S. Marshals in Miami and was released on a $500,000 bond.
“The FBI works every day to dismantle the ransomware ecosystem,” Brett Leatherman, assistant director of the FBI’s Cyber Division, said in a statement. “That includes apprehending key facilitators like Angelo Martino, who abused the trust placed in him as a private sector negotiator by collaborating with ransomware criminals.”
ALPHV/BlackCat was a notorious ransomware and extortion group linked to a series of attacks on critical infrastructure providers. The ransomware variant first appeared in late 2021, and was later used in dozens of attacks on organizations in the health care sector.
The group behind the ransomware strain also claimed responsibility for the February 2024 attack on UnitedHealth Group subsidiary Change Healthcare, which paid a $22 million ransom and became the largest health care data breach on record, compromising data on about 190 million people.
Martino pleaded guilty to conspiracy to obstruct, delay or affect commerce or the movement of any article or commodity in commerce by extortion. He faces up to 20 years in federal prison and is scheduled for sentencing July 9.
You can read Martino’s plea agreement below.
The post Former DigitalMint ransomware negotiator pleads guilty to extortion scheme appeared first on CyberScoop.
On March 30, 2026, a security advisory was published for a critical vulnerability affecting Nginx UI. Nginx UI is an open-source web interface to centralize the management of Nginx configurations and SSL certificates. The critical vulnerability, CVE-2026-33032, was reported in early March by Pluto Security researcher Yotam Perkal and subsequently patched on March 15, 2026. That same day, Pluto Security published a technical blog post with some vulnerability details.
CVE-2026-33032 is a missing authentication bug with a CVSS score of 9.8; as a result of missing authentication controls, an unauthenticated attacker who exploits CVE-2026-27944 to leak information can access a Model Context Protocol (MCP) server that can perform privileged operations on managed Nginx web servers. Systems are vulnerable in the default IP allowlist configuration, which allows any remote IP to access MCP functionality. Exploitation results in full attacker control of the managed Nginx service.
According to a Recorded Future report published on April 13, 2026, exploitation of CVE-2026-33032 in the wild has begun. A PurpleOps report published on April 16, 2026 associated exploitation of CVE-2026-33032 in the wild with the information leak vulnerability CVE-2026-27944, indicating that these two vulnerabilities are being exploited as a chain.
Organizations running Nginx UI should prioritize updating on an urgent basis to remediate CVE-2026-33032. Additionally, to reduce exposure to future vulnerabilities affecting Nginx UI, defenders should ensure that network access to the Nginx UI management interface is strictly limited to those who must have it.
According to the finder’s blog post, version 2.3.3 and prior are affected, and the fix is present in version 2.3.4 and later. However the official CVE record states that versions 2.3.5 and below are affected. The information leak vulnerability being exploited in the wild with CVE-2026-33032, CVE-2026-27944, was patched in version 2.3.3. This discrepancy in affected version numbers introduces confusion as to the correct version required to remediate CVE-2026-33032. To avoid this version number discrepancy, users are advised to update to the very latest version (2.3.6).
Please read the vendor advisory for the latest guidance.
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-33032 with unauthenticated checks available in the April 17 content release.
April 16, 2026: Initial publication.
It is no secret that phishing campaigns utilizing various ClickFix techniques have been a commonly used method of social engineering. One of the main reasons for this is simply because they work. You know this and Rapid7 does as well. As a company offering managed detection and response (MDR), our customers expect us to be knowledgeable about and able to detect attacks as common as ClickFix campaigns.
Recently, Rapid7 observed a small grouping of ClickFix events across customers in the EU and US. At the time of discovery, this campaign had very little traction on sites like VirusTotal or within the online security landscape. This campaign was particularly interesting as it appeared to be masquerading as an installer for Claude, an AI tool that has received a considerable amount of attention.
Using Rapid7 InsightIDR detection rules, our SOC analysts were able to detect and respond to the threat, preventing further compromise. This campaign demonstrates the strength Rapid7 customers get from our MDR service, while peeling back the curtain to provide a real-world example on how we operate behind the scenes. In this blog, we will detail a brief technical analysis of the observed threat actor activities and discuss how this serves as an example of the service we aim to provide our MDR customers. The analysis highlights both the multi-step delivery of the payload as well as the work Rapid7 performs when investigating threats.
On April 9, Rapid7 was alerted to mshta executed on a customer asset using the Windows run utility. The alert was generated by the detection rule Attacker Technique - Remote Payload Execution via Run Utility (shell32.dll). This rule will generate an alert when a suspicious process, such as mshta, is added to the RunMRU registry key. This key is important for the detection of ClickFix campaigns, as it tracks the last 26 commands executed by the Windows run utility. One thing that stuck out about this particular mshta command is that the URL, download-version[.]1-5-8[.]com/claude.msixbundle, appeared to be impersonating an MSIX bundle for the popular AI tool, Claude.
MSIX files are Windows app packages that one would typically see from the Microsoft store, definitely not something you would see being passed as an argument to mshta. While the host was quickly taken down before Rapid7 was able to obtain the claude.msixbundle payload, a copy was obtainable on VirusTotal. Looking at the payload, it does initially appear to be an MSIX bundle. The file header signature, PK, indicates that the file is a ZIP archive and contains a string reference to the MSIX bundle, MicrosoftBing_1.1.37.0_ARM64.msix:
⠀
⠀
Exploring the payload deeper, however, reveals an HTML Application (HTA) embedded within the ZIP archive:
⠀
The Visual Basic script within the HTA file contains a series of obfuscated strings that are deobfuscated with the following VBS function:
⠀
Additionally, one of the functions serves to generate an encoded PowerShell script that will serve as the next step in the chain:
⠀
After the deobfuscation routine is complete, these strings contain references to the required objects and function calls to craft and execute – via ShellExec – the following command:
c:\Windows\System32\cmd.exe” /v:on /c “set x=pow&&set y=ershell&&call %windir%\SysWOW64\WindowsPowershell\v1.0\!x!!y! -E [ENCODED COMMAND]
⠀
⠀
The encoded PowerShell acts as a staging payload. The script will first generate an MD5 hash value based on the COMPUTERNAME and USERNAME environment variables. It will then take the first 16 characters of the hash value and use it to craft a URL to pull another, much larger, PowerShell script. The script also contains a string deobfuscation routine that is responsible for crafting the following strings to be passed to various .NET functions:
Assembly
System.Mangement.Automation.AmsiUtils
amsiContext
NonPublic,Static
0x41414141
⠀
The script will then call the deobfuscation routine to craft a call to WriteInt32 in the .NET Marshal library to overwrite the amsiContext field in System.Management.Automation.AmsiUtils with the value 0x41414141. Once amsiContext is overwritten, the script will download and execute the next stage:
⠀
The URL is hosting yet another PowerShell script containing highly obfuscated strings and a large byte array. Upon execution of the script, the strings decode to contain the necessary .NET types and method calls to create and execute a PowerShell ScriptBlock. This ScriptBlock is derived from the byte array, which is first base64 decoded and then run through a deobfuscation routine:
⠀
This ScriptBlock again contains another series of obfuscated strings and a large byte array containing yet another PowerShell ScriptBlock. Following the execution of the script, the code once again creates and executes a PowerShell ScriptBlock:
⠀
This ScriptBlock culminates in a process injection routine using the .NET interoperability library. The code contains a byte array with encrypted shellcode that gets passed through a XOR routine. The script then obtains handles to the following Windows API calls:
NtAllocateVirtualMemory
Copy
NtProtectVirtualMemory
NtCreateThreadEx
NtWaitForSingleObject
NtFreeVirtualMemory
NtClose
After obtaining the handles, the script crafts delegate functions for the Windows API calls and invokes the delegates to perform the process injection routine:
Rapid7 MDR customers receive the security knowledge of our threat intelligence, detection engineering, incident response, and security operations center analysts. Input from all of these sources directly feeds into how we create detections and respond to alerts. Following is an explanation of how we use events like these to further provide and enhance our services for customers.
As previously mentioned, ClickFix activity is not new. Detection engineers in the MDR service know this and build rules to address these techniques, such as the rule that caught the activity discussed in this blog.. Detection rules are created in response to activity observed in incident response, customer requests, activity observed from the SOC, threat intelligence, and observations of the security landscape. Rapid7’s detection engineers work with the SOC to monitor these rules for efficacy. Rules that are primarily used to detect initial compromise, such as the one that alerted on this campaign, are additionally monitored to identify any new campaigns.
Once the campaign is identified, our detection engineers research it to create additional rules. They can also perform retroactive threat hunts across the Rapid7 customer base using IOCs or any new behavioral detections created from researching the campaign. Results from researching campaigns like this one then go on to feed threat intelligence and help inform our detection strategy. This campaign provides a great example of how Rapid7 works on the backend to detect and prevent threats in customer environments.
Monitor the following registry key to watch for potential ClickFix attacks such as the one observed in this case:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
While Rapid7 MDR customers were covered by the managed SOC, Rapid7 recommends the following actions for containment:
If the activity is not expected, apply containment and review the user's browsing history for the source of the command. The initial lure is often presented to the user when they attempt to browse the internet for free downloads (media, software, etc.). In some cases the malicious command may have been copied to the user's clipboard when visiting the initial webpage, and can be viewed by inspecting the source code of the site. If the infection is successful, an information stealer is often executed as the final payload, meaning that any credentials stored on the infected system should be reset as part of restoration.
System Binary Proxy Execution: Mshta | T1218.005 |
Obfuscated Files or Information: Encrypted/Encoded File | T1027.013 |
Obfuscated Files or Information: Command Obfuscation | T1027.010 |
Command and Scripting Interpreter: PowerShell | T1059.001 |
Process Injection | T1055 |
Cloude.Msixbundle:
2b99ade9224add2ce86eb836dcf70040315f6dc95e772ea98f24a30cdf4fdb97
Domains observed by Rapid7:
Oakenfjrod[.]ru
download-version[.]1-5-8[.]com
download[.]get-version[.]com
When a traditional security incident hits, responders replay what happened. They trace a known code path, find the defect, and patch it. The same input produces the same bad output, and a fix proves it will not happen again. That mental model has carried incident response for decades.
AI breaks it. A model may produce harmful output today, but the same prompt tomorrow may produce something different. The root cause is not a line of code; it is a probability distribution shaped by training data, context windows, and user inputs that no one predicted. Meanwhile, the system is generating content at machine speed. A gap in a safety classifier does not leak one record. It produces thousands of harmful outputs before a human reviewer sees the first one.
Fortunately, most of the fundamentals that make incident response (IR) effective still hold true. The instincts that seasoned responders have developed over time still apply: prioritizing containment, communicating transparently, and learning from each.
AI introduces new categories of harm, accelerates response timelines, and calls for skills and telemetry that many teams are still developing. This post explores which practices remain effective and which require fresh preparation.
The core insight of crisis management applies to AI without modification: the technical failure is the mechanism, but trust is the actual system under threat. When an AI system produces harmful output, leaks training data, or behaves in ways users did not expect, the damage extends beyond the technical artifact. Trust has technical, legal, ethical, and social dimensions. Your response must address all of them, which is why incident response for AI is inherently cross-functional.
Several established principles transfer directly.
Explicit ownership at every level. Someone must be in command. The incident commander synthesizes input from domain experts; they do not need to be the deepest technical expert in the room. What matters is that ownership is clear and decision-making authority is understood.
Containment before investigation. Stop ongoing harm first. Investigation runs in parallel, not after containment is complete. For AI systems, this might mean disabling a feature, applying a content filter, or throttling access while you determine scope.
Escalation should be psychologically safe. The cost of escalating unnecessarily is minor. The cost of delayed escalation can be severe. Build a culture where raising a flag early is expected, not penalized.
Communication tone matters as much as content. Stakeholders tolerate problems. They cannot tolerate uncertainty about whether anyone is in control. Demonstrate active problem-solving. Be explicit about what you know, what you suspect, and what you are doing about each.
These principles are tested, and they are effective in guiding action. The challenge with AI is not that these principles no longer apply; it is that AI introduces conditions where applying them requires new information, new tools, and new judgment.
Non-determinism and speed are the headline shifts, but they are not the only ones.
New harm types complicate classification and triage. Traditional IR taxonomies center on confidentiality, integrity, and availability. AI incidents can involve harms that do not fit those categories cleanly: generating dangerous instructions, producing content that targets specific groups, or enabling misuse through natural language interfaces. By making advanced capabilities easy to use, these interfaces enable untrained users to perform complex actions, increasing the risk of misuse or unintended harm. This is why we need an expanded taxonomy. If your incident classification system lacks categories for these harms, your triage process will default to “other” and lose signal.
Severity resists simple quantification. A model producing inaccurate medical information is a different severity than the same model producing inaccurate trivia answers. Good severity frameworks guide judgment; they cannot replace it. For AI incidents, the context around who is affected and how they are affected carries more weight than traditional security metrics alone can capture.
Root cause is often multi-dimensional. In traditional incidents, you find the bug and fix it. In AI incidents, problematic behavior can emerge from the interaction of training data, fine-tuning choices, user context, and retrieval inputs. Investigation may narrow the contributing factors without isolating one defect. Your process must accommodate that ambiguity rather than stalling until certainty arrives.
Before the crisis is the time to work through these implications. The questions that matter: How and when will you know? Who is on point and what is expected of them? What is the response plan? Who needs to be informed, and when? Every one of these questions that you answer before the incident is time you buy during it.
If AI changes the nature of incidents, it also changes what you need to detect and respond to them.
Observability is the first gap. Traditional security telemetry monitors network traffic, authentication events, file system changes, and process execution. AI incidents generate different signals: anomalous output patterns, spikes in user reports, shifts in content classifier confidence scores, unexpected model behavior after an update. Many organizations have not yet instrumented AI systems for these signals and, without clear signal, defenders may first learn about incidents from social media or customer complaints. Neither provides the early warning that effective response requires.
AI systems are built with strong privacy defaults – minimal logging, restricted retention, anonymized inputs – and those same defaults narrow the forensic record when you need to establish what a user saw, what data the model touched, or how an attacker manipulated the system. Privacy-by-design and investigative capability require deliberate reconciliation before an incident, because that decision does not get easier once the clock is running.
AI can also help close these gaps. We use AI in our own response operations to enhance our ability to:
Staged remediation reflects the reality of AI fixes. Incidents require both swift action and thorough review. A model behavior change or guardrail update may not be immediately verifiable in the way a traditional patch is. We use a three-stage approach:
One practical tip: tactical allow-and-block lists are a necessary triage tool, but they are a losing proposition as a permanent solution. Adversaries adapt. Classifiers and systemic fixes are the durable answer.
Watch periods after remediation matter more for AI than for traditional patches. Because model behavior is non-deterministic, verification relies on sustained testing and monitoring across varied conditions rather than a single test pass. Sustained monitoring after each stage confirms that the remediation holds under varied conditions.
There is a dimension of AI incident response that traditional IR addresses unevenly and that AI makes urgent: the wellbeing of the people doing the work.
Defenders handling AI abuse reports and safety incidents are routinely exposed to harmful content. This is not the same cognitive load as analyzing malware samples or reviewing firewall logs. Exposure to graphic, violent, or exploitative material has measurable psychological effects, and extended incidents compound that exposure over days or weeks.
Human exhaustion threatens correctness, continuity, and judgment in any prolonged incident. AI safety incidents place an additional emotional burden on responders due to exposure to distressing content. Recognizing and addressing this challenge is essential, as it directly impacts the well-being of the team and the quality of the response.
What helps:
If your incident response plan does not account for the humans executing it, the plan is incomplete.
Incident response for AI is not a solved problem. The threat surface is evolving as models gain new capabilities, as agentic architectures introduce autonomous action, and as adversaries learn to exploit natural language at scale. The teams that will handle this well are the ones building adaptive capacity now. Extend playbooks. Instrument AI systems for the right signals. Rehearse novel scenarios. Invest in the people who will be on the front line when something breaks. Good response processes limit damage. Great ones make you stronger for the next incident.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
The post Incident response for AI: Same fire, different fuel appeared first on Microsoft Security Blog.
Rapid7’s Incident Response (IR) team was engaged to investigate an incident involving exploitation of CVE-2025-59718 against a vulnerable FortiGate appliance. In December 2025, Fortinet disclosed this improper verification of cryptographic signature vulnerability that facilitates an SSO login bypass on affected appliances. After the initial exploitation, the attackers maintained a low-profile posture, systematically compromising additional firewalls before moving to internal network hosts. Ultimately, this grace period allowed responders to contain the threat before further impact could occur within the environment. This blog details exploitation insights, attack progression, and practical detection opportunities for defenders handling their own environments.
Identifying the Initial Access Vector (IAV) is a cornerstone of any incident response engagement. However, when the source of compromise is not immediately obvious, particularly when edge device exploitation is involved, responders often need to take a broader investigative approach. Rather than starting with a clear point of entry, investigators must analyze the available telemetry, reconstruct attacker activity, and work backwards to determine how access was first obtained.
This process often involves multiple investigative workstreams running in parallel, each designed to answer different questions about the intrusion. As many IR responders and enthusiasts know, the first suspicious event observed during an investigation is rarely the first action taken by the attacker. Instead, it typically represents a point somewhere in the middle of a larger attack chain.
A key step in incident response investigations is reconstructing the attacker timeline. Responders often take an “inside out” approach where they move outward from the initial alert to the full scope of the malicious activity (IAV), correlating multiple data sources to map the unfolding of the event. This process involves examining authentication logs, endpoint telemetry, firewall events, and records of system changes, rather than depending on just one log source. It also typically requires frequent pivoting between artifacts as investigations rarely ever unfold in a linear fashion. By aligning these findings and events chronologically, investigators often identify activity that predates the initial alert.
The first activity that drew attention was enumeration and credential discovery within the internal environment. This basic enumeration included gathering information about users, systems, and accessible resources within common user directories. This activity eventually expanded to SMB-based file scraping and network share access, allowing attackers to review files stored across the environment. While this behavior resembled routine administration, the chronological sequence of file scraping and network share access painted a clear picture of an attacker’s initial discovery phase.
Digging deeper into the credential discovery activity, the popular tool Mimikatz was utilized to harvest credentials from various sources within the impacted environment. The attacker’s objective was to obtain valid credentials to an elevated admin account with the goal to blend in.
With credentials in hand and mimicking admin activity to disguise their actions, the attacker was then enabled to move laterally throughout the environment using common administrative tools and access methods. PsExec and Microsoft Remote Desktop (RDP) were two tools utilized for lateral movement while standard web browsers facilitated application access.
Attackers appeared particularly interested in systems that could provide broader access to the environment, including virtualization platforms, domain controllers, and servers supporting backup infrastructure. These systems often represent high-value targets for attackers seeking to escalate privileges, access sensitive data, or disrupt recovery capabilities.
Responders were working simultaneously to contain the attacker while building the narrative to cut them off at the source. With the current understanding of the narrative, the IAV puzzle began to unravel as more information came to light. Strangely, the first authentication into the Windows environment originated from an internal IP address that did not align with the known internal IP address ranges. It turns out, this internal IP address fell within the DHCP lease range of the FortiGate device. At first glance, this could be written off as legitimate VPN activity. However, to create even more questions, it was revealed that the FortiGate SSL VPN was never turned on within this environment. This revelation made the FortiGate device a prime suspect for IAV.
Taking a closer look at the FortiGate device, specifically system logs and configuration data, revealed early indications that the device had been modified to support continued access. The SSL VPN component had been enabled, and multiple configuration changes were identified, including edits to VPN settings, the creation of new firewall policies, and adjustments to configuration parameters. These changes appeared in FortiGate system logs as configuration updates similar to the following:
logid="0100044546" type="event" subtype="system" level="information" vd="root" logdesc="Attribute configured" user="admins" ui="GUI(45.32.216[.]250)" action="Edit" cfgpath="vpn.ssl.settings" msg="Edit vpn.ssl.settings"
⠀
logid="0100044547" type="event" subtype="system" level="information" vd="root" logdesc="Object attribute configured" user="admins" ui="GUI(45.32.216[.]250)" action="Add" cfgpath="firewall.policy" cfgobj="XX" msg="Add firewall.policy <redacted>"
⠀
While these types of changes may seem routine in isolation, it is the combination and timing of these actions that raises concerns from a responder's perspective. The investigation's next key clue was identified when the source of these changes was traced back to a newly created account.
Following this thread further, investigators identified that multiple accounts had been created on the device, including SSO administrator, system administrator, and local accounts. Several of these accounts were associated with email domains attributed to Namecheap-hosted infrastructure, including domains such as openmail[.]pro. Notably, some of the newly created SSO administrator accounts were linked to forticloud.com domains as reflected in log entries such as:
Object attribute configured(Add system.sso-forticloud-admin <attacker account>@forticloud.com-1)
⠀
For responders, the creation of multiple new administrative accounts is often a strong indicator of persistence being established. Continuing to work backwards through the timeline, investigators identified that prior to these account creation events, the device’s configuration file was downloaded through the FortiGate UI. From an investigative perspective, configuration exports are highly valuable to attackers because they effectively serve as a blueprint of the environment, exposing network architecture, authentication mechanisms/settings, device relationships, and occasionally, sensitive credentials.
logid="0100032095" type="event" subtype="system" level="warning" vd="root" logdesc="Admin performed an action from GUI" user="admin" ui="GUI(104.28.227[.]105)" action="download" status="success" msg="System config file has been downloaded by user admin via GUI(104.28.227[.]105)"
⠀
The session associated with the configuration download was established from an external IP address flagged as “malicious” by security vendors with a local account already present on the device. All of these new findings from the attacker’s actions can now be utilized as IOCs to scope available FortiGate logs to determine any other leads.
By correlating activity with the known malicious IP addresses, investigators identified the true entry point: administrative SSO logins to the FortiGate appliance with valid accounts. Another important detail was that there was no evidence of brute-forcing activity for these local accounts. The initial access was established approximately two weeks before any subsequent malicious activity, indicating the attacker used this time to secure consistent access to the environment via the FortiGate device.
Actions such as changing configurations, creating accounts, and downloading configurations might seem harmless individually. However, when viewed together, these activities established a clear pattern consistent with the exploitation of CVE-2025-59718 that facilitated authentication bypass.
Once this groundwork was established through persistence mechanisms and discovery, attackers began authenticating into the environment with their newly created accounts via the SSL VPN connections that led us to investigate the FortiGate device in the first place. These sessions effectively transformed the firewall into an ingress point into the internal network, allowing attackers to move beyond the edge device.
This investigation highlights a common reality in incident response where the first indicator of suspicious activity is rarely the beginning of the story. Instead, responders are often working from a point somewhere in the middle, tasked with reconstructing attacker behavior and peeling back layers of activity to uncover how access was first obtained.
By following the digital breadcrumbs left behind within available evidence sources, investigators were able to trace the intrusion back to its origin. This process emphasizes the importance of working backward through artifacts and telemetry, recognizing that each piece of data may lead to an earlier stage of attacker activity.
Network edge devices such as firewalls and VPN appliances are often the main vectors of initial access. Despite being critical infrastructure in modern environments, full visibility is rarely achieved in comparison to monitored endpoints. These edge devices can provide valuable evidence during investigations and reveal how initial access went unnoticed.
The human element of investigation is crucial. Effective investigations demand a mindset of curiosity; on one side the willingness to dig deeper, and on the other, the ability to look at the big picture. At face value these can seem contradictory, but each facilitates a specific role within an incident response investigation.
Curiosity is what drives responders to grapple with the initial evidence, question assumptions, and identify which threads are worth pulling. It allows responders to move beyond surface-level observations and begin forming hypotheses about what may have occurred. The willingness to dive deeper is what turns those hypotheses into answers. Rather than stopping at the first suspicious event, responders must continue pivoting across logs, correlating activity, and tracing actions further back in time. At the same time, maintaining a big-picture perspective is critical. Individual artifacts or events may appear benign in isolation but when viewed chronologically the attacker behavior emerges.
Looking past any specific incident response methodology, visibility into the environment is essential. Even the strongest investigative approach is limited without access to the right telemetry, thus preventing responders from fully reconstructing an intrusion. In particular, as seen within this investigation, visibility into edge device activity can play a crucial role in unraveling IAV. The network edge is a hostile environment yet is frequently less monitored.
As is often the case with externally facing services and devices, the network edge is constantly targeted. Due to the sheer volume of persistent targeting, this environment can prove difficult to monitor for successful malicious intrusions. Implementing centralized syslog monitoring across these edge devices can close these visibility gaps. It can provide a real-time audit trail of connection attempts, configuration changes, and potential exploit signatures that occur before a threat reaches the internal network.
By effectively pulling on each investigative thread and ensuring visibility across both internal systems and edge devices, defenders can uncover compromises that might otherwise remain hidden. Often, the path to the beginning of the intrusion is already present; it simply requires knowing where, and how, to look.
Rapid7 actively monitors for emerging threats and leverages evidence from incident response engagements to develop new detection capabilities. Detections have been created and implemented by Rapid7 to pinpoint both exploitation attempts and post-exploitation activities related to FortiGate CVE-2025-59718. For InsightIDR and MDR customers, these detections alert on attacker activity consistent with the techniques described in this blog, enabling earlier identification and response before an intrusion can escalate further.
Potential Exploitation - FortiGate Admin SSO Login and Config Download via External IP
Exfiltration - FortiGate Config Downloaded Using GUI via External IP
Suspicious Authentication - FortiGate SSO Login via External IP
Please refer to our initial blog from December, 2025.
Tactic | Technique | Details |
Initial Access | Exploit Public-Facing Application (T1190) | Exploitation of vulnerability CVE-2025-59718 on FortiGate firewalls. |
Persistence | Create Account (T1136) | Creation of local accounts on FortiGate firewalls. |
Persistence and Initial Access | Valid Accounts (T1078) | Use of created accounts and compromised accounts for SSL VPN and RDP authentication. |
Defense Evasion | Impair Defenses (T1562) | Firewall rules added to allow for attacker access. |
Credential Access | OS Credential Dumping (T1003) | Execution of Mimikatz targeting the local system and Windows Registry hives containing credentials. |
Discovery | System Network Configuration Discovery (T1016) | Download of FortiGate firewall configuration files containing sensitive networking information. |
Discovery | Network Service Scanning (T1046) | Execution of network scanning tools such as Advanced_Port_Scanner to scan internal IP addresses over SMB protocol. |
Lateral Movement | Remote Services (T1021) | Use of Remote Desktop Protocol (RDP). |
Execution | Service Execution (T1569.002) | Remote execution of the sysinternals tool PsExec to test credentials against an impacted system. |
IOC | Description |
Advanced_IP_Scanner_2.5.4594.1.exe | Advanced IP Scanner tool utilized by the attacker. |
advanced_ip_scanner.exe | Advanced IP Scanner tool utilized by the attacker. |
mimikatz.exe | An open-source post-exploitation tool utilized by the attacker to extract sensitive authentication credentials. |
Advanced_port_scanner_2.5.3869.exe | An open-source network utility utilized by the attacker to quickly map active devices and identify open ports. |
23.163.8[.]21 | Attacker IP address that targeted FortiGate device. |
45.32.216[.]250 | IP address used by the attacker during FortiGate configuration changes. |
45.84.107[.]17 | IP address identified in malicious interaction with SSLVPN. |
45.80.186[.]84 | IP address identified in malicious interaction with SSLVPN. |
185.219.157[.]127 | IP address identified in malicious interaction with SSLVPN. |
185.175.59[.]238 | IP address identified in malicious interaction with SSLVPN. |
198.98.54[.]209 | Attacker IP address that targeted FortiGate device and SSO login. |
45.80.184[.]229 | Attacker IP address that targeted FortiGate device and SSLVPN. |
45.80.184[.]241 | Attacker IP address that targeted FortiGate device and SSLVPN. |
42.200.230[.]178 | Attacker IP address that targeted FortiGate device and SSLVPN. |
103.20.235[.]155 | IP address identified in malicious authentications to SSO login. |
104.28.227[.]105 | IP address identified in attacker download of FortiGate configuration file. |
Police in Germany physically warned organizations about the critical PTC Windchill vulnerability tracked as CVE-2026-4681.
The post CISA Flags Critical PTC Vulnerability That Had German Police Mobilized appeared first on SecurityWeek.
On March 23, 2026, Citrix published a security advisory for a critical vulnerability affecting their NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway) products. This vulnerability, CVE-2026-3055, which is classified as an out-of-bounds read and holds a CVSS score of 9.3, allows unauthenticated remote attackers to leak potentially sensitive information from the appliance's memory.
The Citrix advisory states that systems configured as a SAML Identity Provider (SAML IDP) are vulnerable, whereas default configurations are unaffected. This SAML IDP configuration is likely a very common configuration for organizations utilizing single sign-on. Per the advisory, organizations can determine if they have an appliance configured as a SAML IDP Profile by inspecting their NetScaler Configuration for the specified string: add authentication samlIdPProfile .*
CVE-2026-3055 affects NetScaler ADC and NetScaler Gateway versions 14.1 before 14.1-66.59 and 13.1 before 13.1-62.23, as well as NetScaler ADC 13.1-FIPS and 13.1-NDcPP before 13.1-37.262. The advisory notes that only customer-managed instances are affected, not cloud instances managed by Citrix.
As of the advisory’s publication, there is no known in-the-wild exploitation and no public proof-of-concept (PoC) available. According to Citrix, the vulnerability was identified internally via security review. However, exploitation of CVE-2026-3055 is likely to occur once exploit code becomes public. Therefore, it is crucial that customers running affected Citrix systems remediate this vulnerability as soon as possible; Citrix software has previously seen memory leak vulnerabilities broadly exploited in the wild, including the infamous “CitrixBleed” vulnerability, CVE-2023-4966, in 2023.
Update #1: On March 29, 2026, a technical analysis of the vulnerability was published by watchTowr Labs. On March 30, 2026, CVE-2026-3055, was added to the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) list of known exploited vulnerabilities (KEV), based on evidence of active exploitation. A Metasploit module for CVE-2026-3055 is available here.
Organizations running affected on-premise instances of NetScaler ADC and NetScaler Gateway should prioritize upgrading to fixed versions on an emergency basis to remediate CVE-2026-3055.
Affected components:
NetScaler ADC and NetScaler Gateway versions 14.1, fixed in 14.1-66.59.
NetScaler ADC and NetScaler Gateway versions 13.1, fixed in 13.1-62.23.
NetScaler ADC 13.1-FIPS and 13.1-NDcPP, fixed in 13.1-37.262 (also referred to as 13.1.37.262 in the vendor advisory).
Please read the vendor advisory (CTX696300) for the latest guidance.
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-3055 on Citrix NetScaler ADC with an authenticated vulnerability check expected to be available in the March 26 content release.
March 23, 2026: Initial publication.
A 41-year-old South Florida man is accused of conducting at least 10 ransomware attacks and helping accomplices extort a combined $75.25 million in ransom payments while he was working as a ransomware negotiator for DigitalMint.
Five of Angelo John Martino III’s alleged victims hired DigitalMint, which assigned Martino to conduct ransomware negotiations on their clients’ behalf — putting him in a position to play both sides, as the criminal responsible for the attack and the lead negotiator for his alleged victims, according to federal court records unsealed Wednesday.
Martino allegedly obtained an affiliate account on ALPHV, also known as BlackCat, and conspired with other former cybersecurity professionals to break into victims’ networks, steal and encrypt data, and extort companies for ransoms over a six-month period in 2023.
Martino was an unnamed co-conspirator in an indictment filed in November 2025 against Kevin Tyler Martin, another former ransomware negotiator at DigitalMint, and Ryan Clifford Goldberg, a former manager of incident response at Sygnia. Goldberg and Martin pleaded guilty in December to participating in a series of ransomware attacks and are scheduled for sentencing April 30.
Prosecutors accuse Martino of providing confidential information regarding ransomware negotiations to ALPHV co-conspirators to maximize the ransom payment. His attorney did not immediately respond to a request for comment.
The five U.S.-based victims that hired DigitalMint and unwittingly tapped Martino to allegedly conduct ransomware negotiations with himself and his co-conspirators include a nonprofit and companies in the hospitality, financial services, retail and medical industries. All five of those victims paid a ransom.
Goldberg and Martin were not specifically named as co-conspirators in those attacks. Prosecutors previously said they only successfully extorted a financial payment from one of their victims for nearly $1.3 million.
DigitalMint said they suspended Martino’s access to systems when the Justice Department notified the company they were investigating him on April 3 and fired him the next day. The company, which is not accused of any knowledge or involvement with the crimes, added it was not aware that Martino and Martin were already involved in ransomware-related schemes before they were hired.
“We strongly condemn these former employees’ criminal behavior, which violated our values, ethical standards and the law,” DigitalMint CEO Jonathan Solomon said in a statement to CyberScoop.
“DigitalMint has fully cooperated with law enforcement from the outset and does not expect further charges,” Solomon added. “While no organization can completely eliminate insider risk, we take incidents like this extremely seriously and have strengthened safeguards and internal controls to further reduce the likelihood of similar conduct.”
DigitalMint did not directly answer questions about whether it refunded its clients who were allegedly victimized by Martino. “We are not able to discuss specific client relationships or fee arrangements due to confidentiality obligations,” a spokesperson said in a statement. “We remain committed to our clients and have addressed any commercial matters directly with those parties.”
The company also declined to describe the circumstances under which it was hired and assigned Martino to conduct ransomware negotiations on the attacks he allegedly committed. Yet, in a statement it noted: “The charging documents do not allege that Martino referred or brought these victims to DigitalMint.”
The case against Martino showcases an extreme, albeit rare, example of the dark underbelly of ransomware negotiation as a practice. The pitfalls of ransomware negotiation are excessive and these backchannel negotiations, which remain largely unscrutinized, can go awry for various reasons.
Martino is charged with conspiracy to interfere with commerce by extortion and faces up to 20 years in prison. He is scheduled to enter a plea March 19.
Authorities seized nearly $9.2 million in five types of cryptocurrency from 21 wallets controlled by Martino. Other items seized from Martino include a 1999 Nissan Skyline, a 2024 Polaris RZR, a 2023 trailer and a 29-foot boat manufactured in 2023.
Officials also seized two properties owned by Martino in Nokomis, Florida, including a bayfront home with an estimated value of $1.68 million and a second single-family home with an estimated value of $396,000. The bayfront home was reported as the second-largest real estate transaction of the week when Martino and his wife purchased the home for $1.791 million in February 2024.
Martino surrendered to the U.S. Marshals in Miami Tuesday and was released on a $500,000 bond. He is restricted from traveling outside the Southern District of Florida and is prohibited from working in the cybersecurity industry.
ALPHV/BlackCat was a notorious ransomware and extortion group linked to a series of attacks on critical infrastructure providers. The ransomware variant first appeared in late 2021, and was later used in dozens of attacks on organizations in the health care sector.
The group behind the ransomware strain also claimed responsibility for the February 2024 attack on UnitedHealth Group subsidiary Change Healthcare, which paid a $22 million ransom and became the largest health care data breach on record, compromising data on about 190 million people.
Two of Martino’s alleged victims paid even higher ransoms in 2023, according to prosecutors, including a nearly $26.8 million payment from the unnamed nonprofit, and a nearly $25.7 million payment from the unnamed financial services company.
You can read the formal charge prosecutors filed against Martino below.
The post Feds say another DigitalMint negotiator ran ransomware attacks and helped extort $75 million appeared first on CyberScoop.
The tension arising out of the conflict in Iran is beginning to show signs of expanding beyond a strictly regional crisis. Following our recent published advisories, this communication is intended to outline and summarize the detection and enrichment coverage available to Rapid7 customers, broadly assess the macro cyber threat landscape, and demonstrate the specific actions undertaken within the Rapid7 portfolio to assure our customers of the protection they receive and can expect moving forward. For a research-driven companion piece from Rapid7 Labs, dive into Iran’s Cyber Playbook in the Escalating Regional Conflict.
There exists a number of threat campaigns (both directly and indirectly) associated with groups associated with Iranian APT actors. In order to track details of these campaigns, any relevant indicators of compromise will be made available within Intelligence Hub.
⠀
As additional intelligence is identified and verified this campaign (and any others) will be incorporated and made available both within the detection stack across the Rapid7 portfolio, but equally for enrichment purposes within Intelligence Hub.
Since the regional military escalations began in late February 2026, Rapid7 Labs has tracked a significant and ongoing spike in retaliatory cyber activity targeting regional and Western infrastructure. What we're seeing falls into two broad buckets. The first is state-directed operations, primarily espionage and data exfiltration, carried out by actors like:
MuddyWater/Seedworm (MOIS)
CyberAv3ngers (IRGC)
The Handala persona (assessed as being maintained by Void Manticore under MOIS direction).
The second is a much noisier layer of hacktivist activity, stemming from groups that lack sophistication but generate outsized visibility through DDoS campaigns and public breach claims. These groups include:
Keymous+
DieNet
NoName057(16).
A major theme across this escalation is fabrication. Many of the breach claims circulating on Telegram and dark web forums are exaggerated or outright fake. Threat actors, especially on the hacktivist side, are recycling old leaked datasets, overstating their access, and running what amount to psychological operations aimed at causing panic and reputational damage. That said, where state-directed actors are involved, legitimate data theft is a real concern, and there is a strong likelihood that stolen material will be weaponized publicly and quickly.
Rapid7's Digital Risk Protection platform is purpose-built to cover exactly these kinds of threats. Here is how our coverage maps to the current activity:
Dark web and forum monitoring — The coordination and announcements driving these campaigns are happening across Telegram, X (formerly Twitter), and dark web leak sites. DRP continuously monitors clear, deep, and dark web sources, with proprietary crawlers, inspecting tens of millions of pages. This gives us visibility into restricted forums and early warning when campaigns begin targeting specific organizations or sectors.
Data leakage detection and claim verification — With so many unsubstantiated breach claims in circulation, the ability to quickly distinguish real exposures from fabricated ones is critical. DRP monitors threat actor dumps and leak sites for exposed company assets and correlates what it finds against each customer's digital footprint, giving organizations a clear answer on whether a claimed breach actually affects them.
Brand security and phishing defense — Threat actors are exploiting public confusion to register lookalike domains, clone websites, and create impersonation profiles on social media. DRP identifies these phishing and impersonation threats and supports the takedown of the attacker's infrastructure.
Analyst-verified intelligence — Our threat intelligence analysts investigate and triage what surfaces through the platform to ensure customers receive only intelligence that has been verified and is actionable. When a real compromise or data exposure is confirmed, our team works directly with the affected organization to assess the impact and support remediation.
To fuel the data leak and psychological operations discussed above, state-directed actors like MuddyWater and Void Manticore are actively weaponizing recently disclosed, high-impact vulnerabilities. Rather than focusing on a single product, these APTs are broadly targeting a combination of internet-facing edge devices, enterprise management infrastructure, and client productivity software to gain their initial foothold.
The vulnerabilities being leveraged in these campaigns all provide either authentication bypass or remote code execution, giving attackers a direct path into the environment. Once inside, the goal is the same every time: establish persistence and get data out. As noted above, any legitimate data stolen during these intrusions is highly likely to be handed off to hacktivist personas and weaponized publicly to support the broader disinformation campaigns.
The following CVEs have been identified as actively exploited or assessed as high-priority targets in the current threat environment:
CVE-2026-1281
Description: A critical command injection vulnerability in Ivanti Endpoint Manager Mobile (EPMM) that grants unauthenticated attackers root-level remote code execution. This has been leveraged as a zero-day vulnerability to compromise mobile endpoint management environments.
Tied to: MuddyWater (MOIS)
Metasploit Module: https://github.com/rapid7/metasploit-framework/pull/20932
CVE-2024-4577
Description: A critical OS command injection vulnerability in PHP running in CGI mode on Windows. By exploiting Windows "Best-Fit" encoding behaviors, attackers can bypass escape mechanisms and execute arbitrary code on the host server.
Tied to: Void Manticore (the MOIS-affiliated actor that maintains the Handala hacktivist persona)
Metasploit Module: https://github.com/rapid7/metasploit-framework/pull/19247
CVE-2025-32433
Description: A pre-authentication remote command execution (RCE) flaw in Erlang-based SSH servers. Threat actors can execute arbitrary root commands by sending specially crafted SSH packets, bypassing authentication entirely.
Metasploit Module: https://www.rapid7.com/db/modules/exploit/linux/ssh/ssh_erlangotp_rce/
CVE-2025-52691
Description: An unauthenticated file upload flaw in SmarterTools SmarterMail. Attackers exploit a path traversal weakness via the guid variable to drop malicious files, such as webshells or malicious cron jobs.
Metasploit Module: https://github.com/rapid7/metasploit-framework/pull/20866
CVE-2025-9316
Description: An unauthenticated session bypass vulnerability impacting N-able N-Central. Attackers frequently chain this with an XML External Entity (XXE) vulnerability to read highly sensitive local configuration and backup files from the host infrastructure.
Metasploit Module: https://github.com/rapid7/metasploit-framework/pull/20713
CVE-2026-21514
Description: A security feature bypass vulnerability in Microsoft Word that allows an unauthorized attacker to bypass Object Linking & Embedding (OLE) mitigations locally. Exploitation requires user interaction to open a maliciously crafted document.
Rapid7 Coverage: Analyzed extensively in Rapid7's Patch Tuesday - February 2026 blog post and prioritized for customer patching due to active exploitation
Rapid7’s Threat Hunting team has been actively hunting for activity related to Iranian actors since the regional conflict began. We are utilizing threat intelligence related to new indicators of compromise and known tactics, techniques, and procedures to conduct these hunts. If we have validated findings, the MDR SOC will investigate and communicate the details of findings using the standard notification processes.
Additional reading from Rapid7 Labs: Iran’s Cyber Playbook in the Escalating Regional Conflict
The Department of Health and Human Services unveiled a tool Thursday to help health care facilities assess their cybersecurity risks, elevating the emphasis on those threats to the kind produced by weather conditions and other dangers.
The assistance from HHS’s Administration for Strategic Preparedness and Response (ASPR) comes in the form of an update to the Risk Identification and Site Criticality (RISC) 2.0 Toolkit to include a specific focus on cybersecurity.
RISC is a free tool to help organizations identify threats and vulnerabilities, estimate consequences and share their findings with others. Now it will include a cybersecurity module, too.
The module walks users through a series of questions and measures them against the influential National Institute for Standards and Technology Cybersecurity Framework 2.0, as well as HHS’s own voluntary cybersecurity performance goals.
John Knox, principal deputy assistant secretary at ASPR, said the change was a response to growing cyber threats.
“This module is the latest addition to our toolkit of resources to assist our health care and public health partners in preventing the disruption of patient care and strengthening national health security,” Knox said in a news release. “We must acknowledge that cyber safety is patient safety and that cyber threats can cause cascading problems across the health care industry. The new cybersecurity module will help our partners understand what is needed to strengthen their resilience and we strongly encourage them to take advantage of it.”
It continues an emphasis ASPR’s Charlee Hess discussed at CyberTalks last month, with the landmark Change Healthcare attack prompting the HHS division to look at ways to help organizations manage risk from third-party providers.
Errol Weiss, chief security officer at the Health Information Sharing and Analysis Center, said the creation of the cyber module was a “smart move,” with the RISC toolkit already being integrated into thousands of health care systems. He also liked the toolkit leaning on the NIST framework and HHS’s performance goals.
“By putting cyber side‑by‑side with other threats and hazards in a unified platform, RISC 2.0 can help hospital and health system leaders see cyber exposure in the same context as hurricanes, active shooters, or power failures,” he said in an emailed response to CyberScoop. “That visibility can drive more informed conversations at the executive and board levels about where to invest in cybersecurity, what gaps are most critical, and how cyber disruptions might cascade into real impacts on patient care.”
The post HHS updates a free risk tool to help hospitals size up their cybersecurity exposure appeared first on CyberScoop.
For years, cyberattacks followed a familiar pattern: reconnaissance, exploitation, persistence, impact. Defenders built their strategies around that cycle, patching vulnerabilities, monitoring indicators, and working to reduce dwell time. But a quieter shift is underway.
Today’s most sophisticated adversaries are using AI to study how organizations defend themselves. They run what we call “silent probing campaigns:” long-term, subtle operations designed to map how a team detects threats, escalates issues, and responds under pressure. These campaigns focus on learning the defender’s habits, workflow and decision points so attackers can time and tailor follow-on actions to evade detection. This reframes cyber risk, turning it from a technical problem into a behavioral one.
Historically, attackers focused solely on technical gaps, whether from an unpatched server, exposed credentials or a misconfigured cloud. The objective was to find the weakness and exploit it before someone else did. Silent probing adds a new “learning” phase to that playbook.
Attackers study how an organization responds as carefully as they study its systems. Using AI over weeks or months, they quietly measure detection and escalation speed, learn which alerts get ignored, and infer patterns like shift coverage, alert fatigue, and process bottlenecks.
Over time, these subtle probes generate data that feeds adaptive models. Those models help attackers learn what triggers a response, how quickly teams react, and where detection tends to falter. This means when a major attack finally unfolds, it has already been optimized against the organization’s real defensive patterns.
At the same time, organizations are embedding AI into their security operations, from automated triage to autonomous response orchestration. However, this shift introduces a new risk: the very systems designed to defend the enterprise can become part of the attack surface.
As organizations rely more heavily on AI to run their security operations, these systems need wide visibility and access to work properly. They often connect to cloud platforms, identity systems, and endpoint controls so they can detect threats and act quickly. But that level of access creates a substantial amount of power. If one of these AI-driven systems is compromised or manipulated, it doesn’t just expose a single tool, it can give an attacker broad reach across the environment. In that scenario, the technology designed to protect the organization can accelerate the damage.
Automation increases risk when AI systems can take action without human approval, such as isolating devices, resetting passwords, or changing configurations. Clear limits and guardrails are required, since manipulated inputs or faulty interpretations can trigger rapid wide-reaching disruption. Risk depends on the system’s authority and the controls around it.
AI hallucination in security operations can cause systems to misidentify threats, isolate the wrong assets or overlook the real threat. Repeated errors can erode trust in the system, or worse, create a false sense of confidence in its automated decisions. This affects judgment, decision-making, and how risk is understood in real time.
Silent probing reveals how predictable an organization’s defenses are. Attackers are now looking for patterns in defensive behavior: response consistency across shifts, routinely ignored alerts, predictable incident response steps, and whether noisy tools accidentally hide slow-moving threats.
When defensive behavior becomes visible and predictable, it can be studied and exploited. Organizations need to understand how their defenses appear from the outside and assess their behavioral exposure the same way red teams test technical controls. This includes understanding how easily an outsider can identify detection thresholds, how clearly response times can be measured, and how much operational routine can be learned through quiet, repeated probing. The key question is whether patterns of response are unintentionally teaching attackers how to succeed.
As AI plays a bigger role in security operations, oversight has to evolve alongside it. Strong governance starts with clearly defining what AI systems are allowed to do. Organizations need to be explicit about which actions can happen automatically and which require human approval. Conversely, least-privilege principles should apply not only to people, but also to machines. AI-driven tools should be tested regularly, reviewed for drift, bias, and inaccurate conclusions. Wherever possible, detection and response authority should be separated to avoid concentrating too much power in a single system. Centralization without control may feel efficient, but in practice, it creates fragility.
Still, policies and guardrails alone are not enough. As attackers use AI to understand defenders, defenders must sharpen their own ability to think like their adversaries. Security professionals need to evaluate how their tools perform and how they might be observed, manipulated, or misled. This requires questioning automated decisions, stepping in when necessary, and investigating anomalies—especially when the system appears confident in its conclusions.
This is why hands-on simulations and AI-focused red teaming matter. Teams need experience in environments that simulate adaptive adversaries who adjust their tactics based on defensive responses. not just textbook attack scenarios. They need to understand AI’s detection capabilities and the risks introduced by poor configurations or blind trust. The gap organizations face has become more cognitive than technological, and closing that gap requires continuous, measurable skill development, including AI literacy, offensive AI awareness, and the ability to critically evaluate automated outputs.
In an AI-first era, resilience now depends on how an organization defends itself like its being watched. Silent probing allows attackers to understand detection thresholds, escalation speed, and response consistency over weeks or months. and how consistently teams respond. This quiet observation can now serve a precursor to a major attack on an enterprise.
Security leaders need to focus on what their organizations reveal through day-to-day defensive behavior. When attackers can observe, learn, and adapt over time, predictable responses become a liability because they are easy to study and exploit.
Dimitrios Bougioukas is senior vice president of training at Hack The Box, where he leads the development of advanced training initiatives and certifications that equip cybersecurity professionals worldwide with mission-ready skills.
The post How ‘silent probing’ can make your security playbook a liability appeared first on CyberScoop.
On February 25, 2026, Cisco disclosed a critical authentication bypass vulnerability in Cisco Catalyst SD‑WAN Controller and Cisco Catalyst SD‑WAN Manager, tracked as CVE‑2026‑20127, that allows an unauthenticated attacker to gain administrative access to affected systems. The Cisco Catalyst SD-WAN Controller and Manager are core components of Cisco’s software-defined wide area networking (SD-WAN) architecture. The issue was originally identified and reported by Australian cybersecurity authorities, who observed real‑world attacks leveraging this flaw.
Customers running these products must urgently upgrade to a fixed release to prevent further compromise. This vulnerability affects the following deployment types:
On-Prem Deployment
Cisco Hosted SD-WAN Cloud
Cisco Hosted SD-WAN Cloud - Cisco Managed
Cisco Hosted SD-WAN Cloud - FedRAMP Environment
At the time of disclosure, Cisco Talos published a report that outlined how malicious actors in the wild leveraged CVE-2026-20127 to gain initial access, then downgraded the software version on the compromised system for post-exploitation activity. After the targeted system had been downgraded to an older vulnerable firmware release, the attackers exploited CVE-2022-20775 to escalate privileges and gain root access to the system. This exploitation in the wild led CISA to issue an emergency directive to Federal Civilian Executive Branch (FCEB) agencies requiring that patches be installed by 5:00PM ET February 27, 2026.
At the time of the advisory’s publication, Cisco does not recommend any workaround strategies for remediation. Organizations running affected instances of Cisco Catalyst SD-WAN Controller or Cisco Catalyst SD-WAN Manager should prioritize upgrading to a fixed version, as outlined below, to remediate CVE-2026-20127.
Affected Cisco Catalyst SD-WAN major version recommendations:
20.11 Release - upgrade to version 20.12.6.1 or above.
20.12.5 Release - upgrade to version 20.12.5.3 or above.
20.12.6 Release - upgrade to version 20.12.6.1 or above.
20.13 Release - upgrade to version 20.15.4.2 or above.
20.14 Release - upgrade to version 20.15.4.2 or above.
20.15 Release - upgrade to version 20.15.4.2 or above.
20.16 Release - upgrade to version 20.18.2.1 or above.
20.18 Release - upgrade to version 20.18.2.1 or above.
20.9 Release - upgrade to version 20.9.8.2 or above (Cisco estimates a patch availability date of February 27, 2026 for this release).
Systems running release versions below 20.9 should be migrated to a newer major version with a fix available.
For the latest guidance, refer to the official vendor advisory.
For any potentially compromised systems, Cisco recommends specific detection and forensic analysis steps to identify exploitation of CVE-2026-20127. According to Cisco, defenders should look for control connection peering events in Cisco Catalyst SD-WAN logs; Cisco states that all peering events will require manual validation to confirm if the events are valid or not, using the following steps:
Verify the timestamp of each peering event against known maintenance windows, scheduled configuration changes, and normal operational hours for your environment.
Confirm the public IP address corresponds to infrastructure owned or operated by your organization or authorized partners by cross-referencing against asset inventories and authorized IP ranges.
Validate the peer system IP matches documented device assignments within your Cisco Catalyst SD-WAN topology.
Review the peer type (vmanage, vsmart, vedge, vbond) to ensure it aligns with expected device roles in your deployment.
Correlate multiple events from the same source IP or system IP to identify patterns of reconnaissance or persistent access attempts.
Cross-reference event timing with authentication logs, change management records, and user activity to establish whether the connection was initiated by authorized personnel.
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-20127 with an authenticated check available in the Feb 26 content release.
February 25, 2026: Initial publication.
February 26, 2026: Updated to reflect product content availability.
