ATT&CK-based detection for a federal agency is the practice of deploying detection rules mapped to MITRE ATT&CK techniques, translating those rules to the agency’s own SIEM, and measuring coverage so the agency can produce auditable evidence that detection is working.

Federal agencies operate under executive orders, OMB memos, and performance goals that point to one operational outcome: detect adversary techniques against agency telemetry and produce evidence that detection is working.

Three components deliver that outcome. An ATT&CK-mapped detection content source provides the rules. A translation layer converts each rule to the native query language of the agency’s deployed SIEM, whether that is Microsoft Sentinel, Splunk, or Elastic. A coverage measurement loop proves which ATT&CK techniques are covered, which are not, and when coverage was last validated.

Without all three, an agency has either detection it cannot prove or proof it cannot act on. This page maps federal guidance to detection requirements and gives a federal buyer the questions to ask any detection content vendor.

What tools help implement ATT&CK-based detection quickly in a federal agency?

Three tool categories implement ATT&CK-based detection in a federal agency: a detection content source, a translation layer, and a coverage measurement loop. Each can come from a vendor, from open source, or from internal engineering. A federal buyer should evaluate each independently because each can come from a different provider.

Component	Function	Neutral examples
ATT&CK-mapped detection content source	Pre-written detection rules, each mapped to a MITRE ATT&CK technique	SOC Prime Prime Hunt, Sigma community rules, CISA detection signatures, native content packs from Microsoft Sentinel, Splunk, Elastic
Translation layer	Converts detection logic to the query language the agency’s SIEM runs	SOC Prime Uncoder, Sigma CLI, manual rule porting
Coverage measurement loop	Maps which ATT&CK techniques have deployed, validated detections and which have gaps	MITRE ATT&CK Navigator, custom ATT&CK heatmaps, vendor coverage dashboards

A content source alone is not detection capability, and a translation tool alone is not coverage. The measurement loop connects the two to evidence an auditor or inspector general can verify.

Detection content source. A library of rules mapped to MITRE ATT&CK technique IDs, authored and maintained at a cadence that keeps pace with published threat activity. Sources include internal detection engineering teams writing rules in Sigma, vendor-supplied content streams such as SOC Prime‘s detection content platform, the open-source Sigma rule community, and MITRE’s own ATT&CK repository.

Translation layer. Converts rules from a portable format into the native query syntax of the agency’s SIEM. For Microsoft Sentinel that means KQL. For Splunk, SPL. For Elastic, KQL or EQL. SOC Prime’s Uncoder handles this translation across platforms. Manual conversion and platform-native import tools are alternatives, though they carry a per-rule labor cost that compounds as rule volume grows.

Coverage measurement loop. Maps deployed rules back to the ATT&CK matrix and identifies technique gaps. MITRE’s ATT&CK Navigator is a free, widely used tool for this visualization. The loop is where the five evidence classes an inspector general looks for originate.

Those five evidence classes are the through-line of this page.

#	Evidence class	What it proves
1	Log sources collected	Which telemetry is ingested, from which systems, and that collection is continuous
2	Rules deployed	Each detection rule mapped to its ATT&CK technique and the obligation it supports, with a named owner
3	Proof of firing	Rules fired on real or emulated events and alerts reached responders
4	Change history	Who changed a rule, when, and why, with version control and a review trail
5	Dated coverage report	Point-in-time coverage with a date, so trend and currency are provable

A vendor may provide the content source and the translation layer. The measurement loop often requires the agency to configure its own reporting from ATT&CK Navigator exports, SIEM dashboards, or third-party coverage analytics. The measurement loop is the component agencies most commonly lack.

Prime Hunt’s read-only data audit maps the log sources an agency already collects to ATT&CK and lists the techniques with no telemetry behind them.

Contact Sales

How does CISA and NSA threat-informed defense guidance translate into detection requirements?

Federal guidance prescribes outcomes, not specific detection tools. CISA, often jointly with NSA, publishes advisories and guidance that define what agencies must achieve in detection and monitoring. Mapping each guidance document to the detection capability it implies, and then to the evidence that capability produces, gives a program manager a traceable line from directive to operational proof.

Guidance	Implied detection capability	Evidence class
OMB M-26-14 (22 May 2026, rescinds M-21-31)	Log collection measured per information system on a five-level logging maturity model, Level 0 to Level 4	Log sources collected
EO 14144 (16 January 2025) as amended by EO 14306 (6 June 2025)	Threat identification across the federal enterprise: CISA threat hunting and agency endpoint detection and response data (EO 14144 Sec. 3(c), redesignated Sec. 3(a) by EO 14306)	Rules deployed, proof of firing
CISA Best Practices for MITRE ATT&CK Mapping (v2.0, January 2023) and the Decider tool	Structured ATT&CK technique attribution on deployed detections	Rules deployed (ATT&CK-mapped)
CISA Cross-Sector CPG 2.0 (11 December 2025)	Baseline performance goals for detection and response, including the Govern function added in version 2.0	Rules deployed, dated coverage report
NIST SP 800-61 Rev 3 (final, 3 April 2025, CSF 2.0 community profile)	Detect-to-respond evidence chain per CSF 2.0	Proof of firing, change history
CISA/NSA joint cybersecurity advisories	ATT&CK technique coverage against named threat actors and campaigns	Rules deployed against named techniques

One line carries the whole table: threat-informed defense guidance implies ATT&CK-mapped detections deployed against the agency’s own telemetry, and the five evidence classes prove the capability exists.

The OMB memo of 22 May 2026 replaced the M-21-31 EL0 through EL3 maturity tiers with a revised logging and visibility framework. The memo directed CISA to produce a Logging Reference Architecture under the new framework. Agencies that built logging programs around the old tiers should validate current posture against the 2026 memo.

MITRE ATT&CK is not mandated by any of these directives. It organizes the evidence so that coverage is measurable and technique gaps are nameable across all of them. A federal buyer who can produce the five evidence classes is defensible regardless of which specific directive applies.

How do you close APT technique gaps when cleared detection engineers cannot be hired fast enough?

Buy the commodity detection layer. Build the agency-specific layer.

Why federal detection hiring lags

Detection engineering in a federal agency carries constraints commercial teams do not face. Clearance requirements narrow the hiring pool. Onboarding timelines extend before a new hire touches production systems. Attrition forces a re-hire and re-ramp cycle that compounds the delay.

Source the commodity layer

Commodity TTPs, the techniques shared across APT groups and criminal actors on common platforms, are published by threat researchers and translated across SIEM platforms by vendor-agnostic content sources. An agency running Microsoft Sentinel, Splunk, or Elastic Security across different mission areas can source pre-written, pre-mapped detection logic for commodity techniques rather than authoring each rule in each query language.

Where cleared engineers add value

The agency’s cleared engineers then focus on what only they can do:

• Detection logic against classified threat intelligence and agency-specific telemetry.

• Tuning sourced content against the agency’s log sources and baseline behavior. Pre-written content produces false positives until tuned to the environment.

• Validation. Every rule, bought or built, requires proof of firing in the agency’s own environment before it counts as deployed. A rule that parses is not a rule that fires.

• Operational response. Detection without response is a dashboard. Cleared analysts investigate, contain, and remediate.

A subscription to a detection content source converts part of a variable hiring problem into a fixed operating expense, redirecting headcount to investigation, environment-specific tuning, validation, and incident response rather than re-creating detections the broader community has already written and tested.

Content sourcing augments detection engineering capacity. It does not replace cleared personnel and does not remove the need for validation and tuning. Any vendor claim that content sourcing removes the validation step deserves scrutiny.

How fast should an advisory become a deployed detection?

Measure the time from a CISA or NSA advisory to a validated, firing detection in the agency’s own SIEM. That window is the metric, and every federal agency should be able to report it for its most recent advisories. For comparison, SOC Prime publishes a 24-hour SLA for detection content against emerging threats.

Step	Action	Owner
1	Advisory published (CISA, NSA, or sector ISAC)	External
2	Detection logic authored or sourced covering named ATT&CK techniques	Content source or internal engineer
3	Rule translated to the agency’s SIEM query language and deployed	Translation layer or internal engineer
4	Rule validated: proof of firing against emulated or real events	Agency (always)

The window has three segments:

• A rule is authored or sourced for the technique the advisory names.
• The rule is translated into the native query language of the agency’s SIEM.
• The rule is validated against the agency’s telemetry to confirm it fires and does not produce unacceptable false-positive volume.

Each segment is independently measurable, and the bottleneck varies by agency. Some source rules quickly but lack translation capacity for their specific SIEM dialect. Others translate quickly but lack validation infrastructure.

A detection content vendor compresses steps 2 and 3. Step 4 remains the agency’s responsibility regardless of content origin. A buyer evaluating any vendor’s speed claim should ask which of these three segments the stated timeline covers and which it does not.

Track the full window per advisory. Set an agency target. Report against it. Each advisory produces a dated record: advisory ID, techniques covered, detection rule IDs, date deployed, date validated. That record is auditable and demonstrates that the agency’s threat-informed defense posture is current.

What should a federal buyer ask a detection content vendor about deployment model, data handling and supply chain?

These questions apply to every detection content vendor, including SOC Prime. The answers are diligence inputs, not marketing differentiators.

Deployment model

Ask	Why it matters
What is the hosting model? Cloud, on-premises, hybrid?	Determines whether the platform can operate within the agency’s network boundary
What network connectivity does the platform require?	Outbound connectivity requirements affect placement in segmented or restricted networks
What access does the platform require to the agency’s SIEM or log infrastructure?	Access scope sets the blast radius if the vendor is compromised
How are detection content updates delivered and applied?	Push vs. pull, frequency, and the integrity mechanism on updates

Data handling

Ask	Why it matters
What data does the platform process? Detection content only, or agency telemetry?	Determines the data classification the platform must handle
Does the platform require raw log data, or does it operate on metadata alone?	Narrows the sensitivity of what the vendor can touch
Where is data processed and stored? What jurisdiction?	Affects data sovereignty and records-management requirements
How is the agency’s data segregated from other customers?	Multi-tenancy architecture determines whether cross-tenant exposure is possible

Supply chain and provenance

Ask	Why it matters
How is detection content authored? By whom? What vetting applies to contributors?	Source of the rules determines trust level and exposure to supply-chain risk
What review and validation process does content pass before delivery?	False-positive rate and detection quality depend on upstream QA
What provenance record travels with each detection rule?	Traceability from deployed rule to author and review record
Does the vendor publish a software bill of materials?	SBOM availability is a supply-chain transparency baseline

Neutral frameworks for evaluating vendor responses: NIST SP 800-161 Rev. 1 Update 1 (cybersecurity supply-chain risk management), SBOM minimum elements, and CISA’s Secure Software Development Attestation Form, which remains available although OMB M-26-05 (23 January 2026) rescinded the government-wide requirement to collect it.

Authorization posture

Ask	Why it matters
FedRAMP authorization status and impact level?	Determines whether the platform can process federal data at the required impact level
Agency-specific authorization to operate?	An ATO granted by another agency is informational, not transferable

A buyer should verify authorization status directly through the FedRAMP marketplace or the authorizing agency rather than relying on vendor statements alone.

Update cadence and lifecycle

Ask	Why it matters
How frequently is new detection content published?	Currency of coverage against emerging techniques
What is the timeline from technique publication to available detection, and which segments does it cover?	Scopes a vendor’s speed claim against the advisory-to-detection window above
How does the vendor retire or update outdated rules?	Rule lifecycle hygiene and drift control
What notification does the customer receive when a deployed rule changes?	Change-control visibility for the agency’s own audit trail

These questions are due diligence. A vendor that cannot answer them clearly is a risk the agency accepts without measurement.

Where this does not hold

This page addresses unclassified federal environments with standard network connectivity.

Out of scope:

Environment	Why it is excluded
Classified networks	Detection content sourcing in classified environments requires capabilities not verified for any vendor named on this page
Air-gapped or disconnected operations	No vendor’s ability to deliver detection content in disconnected environments is asserted here
Agency-unique telemetry	Agencies with telemetry sources outside standard SIEM log parsing may require detection logic no external content source provides

Agencies operating under environment-specific accreditation such as IL4, IL5, or IL6 impact levels under DoD should validate any vendor’s authorization status against the specific accreditation their environment requires. The buyer questions in the previous section still apply, but the thresholds for acceptable answers are higher.

The three-component model (content source, translation layer, measurement loop) applies in every environment. Whether a specific vendor can deliver in a classified or disconnected environment is a question the buyer verifies directly with the vendor and with the authorizing official.

A MITRE ATT&CK Audit by SOC Prime’s engineers assesses visibility and detection capability across the agency’s SIEM or EDR and returns the gaps with recommendations.

Contact Sales

Related reading

• From Raw Threat Reports to Actionable Defense: AI-Powered Deep Threat Research (September 2026)
• MITRE Attack Flow v3.0.0 (October 2025)
• Uncoder AI Automates MITRE ATT&CK Tagging in Sigma Rules (April 2025)

The post ATT&CK-Based Detection for Federal Agencies appeared first on SOC Prime.

Executive summary

In April 2026, we at Kaspersky’s Global Emergency Response Team (GERT) responded to a security incident at a manufacturing organization in the Middle East. The threat actor obtained domain admin-equivalent control of the organization’s Active Directory environment and authored a malicious Group Policy Object (GPO) named PAYLOAD, linking it at the domain root. Through that single object, the actor delivered ransom notes, hijacked the desktop wallpaper and lock screen, enforced a logon banner, and disabled the local administrator account across every domain-joined Windows workstation — all without dropping a ransomware binary or encrypting any data. The only ransomware we found in this incident was PAYLOAD sample targeting ESXi on Linux servers. Besides that, data exfiltration was observed originating from the file servers and several additional systems, and was later published on the dark web.

This case is an example of two converging trends that define the 2026 ransomware landscape:

1. Living-off-the-land abuse of trusted AD infrastructure. Group Policy is a signed, allowlisted, SYSTEM-privileged distribution channel that the majority of endpoint detection and response tools is designed not to inspect. By delivering impact through GPO rather than through malware, the actor sidestepped the entire file- and process-based detection stack.
2. Encryptionless extortion. Industry telemetry shows extortion-only incidents grow significantly year-on-year. PAYLOAD fits this model; the leverage is operational disruption and the threat of escalation rather than cryptographic denial of data.

We confirmed that no files were encrypted on Windows machines, no malicious binaries were resident on disk, no endpoint persistence was established, and no malicious processes were running at the time of analysis. The entire attack lived inside Active Directory itself. The defensive implication is stark: an organization whose detection strategy depends on catching a ransomware executable would have seen nothing until the first endpoint rebooted and the ransom wallpaper appeared.

In this article, we will describe the GPO attack chain and provide operational advice on how to detect such threats, including detailed remediation recommendations.

Group Policy as an attack surface

Attacks through group policies are nothing new. They can inflict significant, domain-wide damage with multiple malicious capabilities. A Group Policy Object (GPO) is essentially a combination of a Group Policy Container (GPC) in Active Directory and a Group Policy Template (GPT) in SYSVOL. The Group Policy scope depends on whether the GPC is linked to the directory tree at the domain, site, or organization unit (OU) level. A link at the domain root means the policy applies to every computer and user object beneath it. Thus, a GPO compromised at the domain root can affect all in-scope domain users and computers, potentially granting an attacker complete control over the corporate network. What makes GPO abuse even more dangerous is that group policies are processed in a trusted, high-privilege environment, ensuring persistence because endpoint cleanup is not enough to remove them.

We have already discussed GPO architecture and ways it can be compromised in greater detail in an earlier blog post. Other public threat intelligence has also repeatedly documented this technique in ransomware operations. Microsoft observed Ryuk operators distributing ransomware through Group Policy, SYSVOL startup items, and PsExec. LockBit affiliates have been documented modifying SYSVOL Group Policy files, including ScheduledTasks.xml, to support ransomware execution and propagation. BlackCat/ALPHV operators have also abused GPOs to create scheduled tasks and deploy ransomware.

Another notable example of GPO abuse is PAYLOAD ransomware, which weaponizes GPO Preferences and policy settings for pure impact rather than as a launcher for an encryptor. Let’s take a closer look at this attack, which is detailed further below.

Attack timeline

During the April 2026 investigation, we managed to reconstruct the attack timeline as outlined below:

Date	Event
11 April	Initial access. Threat actor authenticates to the FortiGate SSL VPN using a valid but compromised domain credential.
13 April	GPO authored. Malicious GPO, PAYLOAD ({C897F2C7-C2AC-4E6F-BF48-58036FF29E79}) created and linked at the domain root, configuring ransom notes, wallpaper, lock screen, logon banner, and administrator account disablement.
13 April	SYSVOL staging. The payload.jpg and hello.txt files written to \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
13 April	Second GPO. GPO named win Firewall Off ({22099AD2-E062-4F56-B574-5099BBA4E7A6}) linked at the domain root, disabling Windows Firewall on all profiles.
13 April	Dormancy. GPO cached on endpoints but computer configuration not yet applied — no endpoint had rebooted since the policy update.
13 April	Data exfiltration. Data exfiltration was observed originating from the file servers and several additional systems.
14 April	Detonation. Most of the endpoints begin rebooting; computer configuration policies apply. Ransom wallpaper, logon banner, and notes appear. Operational disruption begins.
15 April	Response. Kaspersky GERT engaged. Forensic triage of affected workstations and the domain controller initiated.
16 April	Assessment. GERT confirms no file encryption, no resident malware, no endpoint persistence.

Next, we will discuss each of these stages in more detail and share the findings from our incident response activities.

Incident overview

Initial access

The entry vector was a compromised valid account (MITRE ATT&CK T1078) used to authenticate through the organization’s FortiGate SSL VPN — an external remote service (T1133). Insufficient logging on the FortiGate appliance prevented us from reconstructing how the credential was originally compromised.

Three hypotheses were considered plausible in the context of the attack, in no particular order:

• Password spraying or credential stuffing against the SSL VPN portal.
• Phishing-led credential harvesting.
• Purchase of pre-compromised credentials from an initial access broker (IAB).

Once on the internal network, the actor operated with the compromised security principal’s privileges. Because the account was able to create and link a GPO at the domain root, it held either domain admin privileges or a delegated equivalent (e.g., membership of Group Policy Creator Owners combined with link rights on the domain object).

FortiGate SSL VPN authentication logs and ESXi/virtualization privilege escalation logs were insufficient to reconstruct the lateral movement and privilege escalation chain between initial VPN access and the GPO write privilege level. The most common real-world routes to GPO control — DCSync, Kerberoasting of privileged service accounts, and Pass-the-Hash/Pass-the-Ticket — could not be confirmed or ruled out.

Execution

Rather than deploying an encryptor, the actor abused the victim’s Active Directory policy infrastructure, resulting in malicious GPOs being configured and linked at the domain root to deliver the observed impact across domain-joined systems. The two GPOs below constitute the entire offensive toolkit observed.

The PAYLOAD GPO

We performed a Resultant Set of Policy (RSOP) analysis, which helped us list all policy settings on the affected workstations. From these results, we reconstructed the following changes delivered by PAYLOAD:

GPO extension/CSE	Setting/path	Configured value/resulting action
Files (Group Policy Preference)	Source SYSVOL\hello.txt → Desktop, C:\, D:\	Dropped as README-payload.txt (ReadOnly)
Registry (Computer)	HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\legalnoticecaption	Welcome to Payload!
Registry (Computer)	HKLM\…\Policies\System\legalnoticetext	(ransom demand text)
Personalization Policy	Lock Screen Image	\\DC.THECOMPANY.local\sysvol…\payload.jpg
Desktop Policy (User)	Wallpaper path	\\DC.THECOMPANY.local\sysvol…\payload.jpg
Security Settings (GptTmpl.inf)	Accounts: Administrator account status	Disabled

The PAYLOAD GPO enabled the following actions:

1. Drop SYSVOL\hello.txt to the desktop and root directories C:\ and D:\ as a read-only README-payload.txt by tampering with the “Group Policy Files” client-side extension (CSE).
2. Modify the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ registry key, changing the legalnoticecaption value to "Welcome to Payload!" and the legalnoticetext to the ransom note text through the “Group Policy Registry” CSE.
3. Set payload.jpg located in the targeted domain controller’s SYSVOL as the lock screen image by altering the personalization policy, and as the wallpaper by altering the desktop policy at the user level.
4. Revoke administrator rights for the administrator account (locking the account) by editing the Security Settings CSE in the GptTmpl.inf file.

Settings changed by PAYLOAD GPO

This activity was enabled entirely through a legitimate group policy mechanism, meaning there is no malware code for security solutions to look for because the malicious logic is contained within the policy configuration.

The win Firewall Off GPO

A second domain-root-linked GPO, named “win Firewall Off”, disabled Windows Firewall across the domain, private and public profiles on all endpoints (T1562.004). Deployed independently of PAYLOAD, this object degraded host defenses and ensured the actor retained unimpeded network reach to endpoints for any follow-on activity.

The one-day delay detonation

The most forensically instructive detail is the one-day gap between GPO creation (13 April) and visible impact (14 April). Analysis of Master File Table (MFT) timestamps and the Group Policy History registry key confirmed the policy was written to SYSVOL and cached on endpoints on 13 April. However, computer configuration settings (wallpaper and lock screen machine policy, security settings, firewall disabling) only apply upon reboot or policy refresh — and no endpoint had rebooted in the interim. The attack therefore remained dormant in the GPO cache for one day before detonating en masse when machines were restarted in accordance with standard procedures.

We have to point out here that this delayed policy application is characteristic of GPO-based operations and has two potential consequences for defenders. Firstly, it may grant the actor a quiet window for exfiltration, persistence, or further staging between weaponization and impact. Secondly, it can be used to sever the temporal link between the cause (a GPO-creation event in the directory log) and the effect (mass user-visible disruption occurring at a later time), complicating timeline reconstruction unless directory service auditing is in place.

Forensic findings

Initial incident response engagement revealed a number of findings associated with the attack that we share below.

1. No file encryption
   A full review of the MFT on affected workstations found no files bearing a .payload extension characteristic to PAYLOAD ransomware and no evidence of bulk renaming or encryption I/O patterns. The attackers’ objectives were operational disruption and extortion via visual impact and access denial.
2. No endpoint persistence
   All standard persistence locations were clean:
   • Scheduled tasks — no malicious tasks
   • Run/RunOnce keys — clean
   • Startup folders (user and system) — clean
   • Services — no malicious service installed
   • WMI event subscriptions — none
   • Boot sector/MBR — unmodified

   The attack’s persistence mechanism is the GPO link itself on the domain controller, with no endpoint-resident component.

3. No active malicious processes
   Live process and memory analysis revealed no injected threads, process hollowing or anomalous outbound connections.
4. Registry timeline analysis
   Group Policy History, Shadow and State registry keys on the workstation recorded the application of PAYLOAD on 13 April:
   HKLM\…\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\1
   HKLM\…\Group Policy\Shadow\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\0
   HKLM\…\Group Policy\State\Machine\GPO-List\7
   HKCU\…\Group Policy\History\{7150F9BF-48AD-4da4-A49C-29EF4A8369BA}\1
   HKCU\…\Group Policy\State\S-1-5-21-…\Loopback-GPO-List\5
   The presence of the “Loopback-GPO-List” entry indicates the GPO was processed in loopback mode, ensuring the user configuration (wallpaper) applied regardless of which user logged on to the machine.
5. SYSVOL artifacts
   Two files were staged on the domain controller’s SYSVOL share and served to endpoints through the Files Group Policy Preference CSE:
   • payload.jpg — the ransom image used for both wallpaper and lock screen.
   • hello.txt — the ransom note, distributed to desktops and drive roots as README-payload.txt.

Detection engineering

Because no malicious binary or process exists, the detection logic should focus on the directory service and SYSVOL indicators. Below are the highest-value telemetry sources for identifying the described malicious activity.

• Directory service change auditing (DS Access)
  Enable Advanced Audit Policy → DS Access → Audit Directory Service Changes on all domain controllers and set up alerts for the following events:

  Event ID	Meaning	Hunt focus
  5137	A directory service object was created	The account that created new groupPolicyContainer objects must be an authorized GPO administrator
  5136	A directory service object was modified	Changes to gPLink on the domain root or sensitive organizational units; changes to gPCMachineExtensionNames/gPCUserExtensionNames/gPCFileSysPath/versionNumber for all GPOs
  5141	A directory service object was deleted	GPO deletions (relevant for tamper detection and remediation assessment)

  A gPLink modification at the domain root by a non-standard account is one of the most telling indicators of this attack class.

• SYSVOL file integrity monitoring
  Monitor \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\Policies\ for unexpected files, particularly image files, text files, scripts, ScheduledTasks.xml, and modified registry.pol/GptTmpl.inf files that were created by sources other than legitimate replication.
• Endpoint policy application telemetry
  On endpoints, GPO application is logged in the Group Policy Operational log (Microsoft-Windows-GroupPolicy/Operational) and reflected in the History and Shadow registry keys shown above. A sudden domain-wide change to the applied policy set is a strong post-detonation signal.
• Missing 5136 events
  If the contents of a GPO’s SYSVOL change without a corresponding 5136 event, this can indicate direct SYSVOL/template editing (e.g., via open-source tools such as PowerView or SharpGPOAbuse) that bypasses the normal Group Policy Management Console (GPMC) modification path. While we recommend treating the absence of expected audit events as suspicious, it should be noted that this can be caused by misconfigured auditing.

Anti-forensics and recovery-inhibition capabilities

Confirmed PAYLOAD family capabilities

The Windows endpoint attack described in this report was implemented through malicious Group Policy Objects and did not involve a recovered ransomware executable, resident endpoint malware, confirmed file encryption or active malicious processes at the time of the forensic examination. However, PAYLOAD cryptomalware for Windows does exist, and other sources, including public analysis of its samples, reveal further malicious capabilities of this ransomware that could be used by security teams to enrich detection logic and security policies.

The behaviors documented in this section must therefore be interpreted as family-level capabilities identified through the public reverse engineering of PAYLOAD ransomware samples. They were not confirmed as having executed during the GPO-based incident unless corresponding evidence was identified in the host, memory, process, event-log, or hypervisor.

Windows Event Log clearing

Public reverse engineering of the PAYLOAD Windows variant reveals an optional event log clearing capability (T1685.005, formerly T1070.001). The ransomware dynamically resolves Windows Event Log APIs, enumerates available event log channels, and clears individual channels.

Implementation artifacts include:

• Runtime loading of wevtapi.dll
• EvtOpenChannelEnum
• EvtNextChannelPath
• EvtClearLog
• Enumeration of Security, System, Application, and PowerShell logs, and operational channels
• A command-line option controlling whether log clearing is performed

Clearing event logs reduces the availability of records related to process execution, authentication, PowerShell, service control, and system changes. However, it does not necessarily remove events that were already forwarded to a SIEM, Windows Event Collector, EDR backend, or protected log archive.

Forensic indicators

• Windows Security Event ID 1102
• Event logging shutdown or failure events
• Sudden reductions in event record identifiers
• Multiple event channels restarting from low record numbers
• Gaps between endpoint and centrally forwarded telemetry
• Execution of utilities or APIs associated with log management
• Direct access to EVTX files (Windows Event Log files) under the Windows event log directory

We should note that these indicators can’t be interpreted on their own. For instance, Event ID 1102 should be correlated with a number of aggravating factors, such as:

• Event ID 4688 or Sysmon Event ID 1 for process creation
• Event ID 4624 for the associated administrative logon
• EDR process trees
• PowerShell operational logging
• Windows Event Forwarding records
• Privileged access management activity

At the same time, the absence of Event ID 1102 does not prove that log clearing did not occur. Direct deletion, truncation, service impairment, or an incomplete audit configuration may produce different evidence.

Security process and service termination

PAYLOAD analysis reveals that the Windows ransomware variant contains logic that targets security processes and services (T1685 and T1489). This capability is intended to stop security products, backup software, database services, and applications that may lock files targeted for encryption.
Process and service termination serves several objectives:

1. Reduce endpoint detection and response visibility.
2. Release file handles so data can be modified.
3. Interrupt backup and recovery services.
4. Prevent databases and enterprise applications from protecting active data.
5. Reduce interference with encryption operations.

Forensic indicators

• Security agent services changing from running to stopped
• Event ID 7036 service state changes
• Event ID 7040 service start type changes
• Event ID 4688 or Sysmon Event ID 1 for service control utilities
• Sysmon Event ID 5 for terminated processes
• EDR health degradation affecting many endpoints
• Repeated termination attempts against security or backup processes
• Execution of dedicated process killing utilities

VSS deletion, backup and recovery suppression

Public PAYLOAD sample analysis reports the deletion of Windows Volume Shadow Copies before encryption (T1490). This behavior removes local restore points and reduces the victim’s ability to recover files without external backups.

Recovery inhibition is broader than VSS deletion and may include multiple other malicious techniques, including the following:

• Deleting shadow copies, backup catalogs, and hypervisor snapshots
• Disabling recovery services
• Modifying boot recovery settings
• Compromising backup management platforms
• Deleting or encrypting backup repositories

In the PAYLOAD Windows sample that is proven to perform encryption, VSS deletion is confirmed to have taken place before encryption. A broader compromise of the backup platform was not established in the investigated incident.

Forensic indicators

• Execution of shadow copy management utilities
• Backup catalog deletion attempts
• Recovery configuration changes
• Backup service termination
• Mass snapshot deletions
• Backup administrator logons outside normal maintenance windows
• Backup retention or immutability changes
• Backup jobs failing immediately before disruptive activity

Ecosystem-relevant ransomware techniques

Above, we discussed the techniques specific to PAYLOAD ransomware. In this section, we’ll review other common ransomware techniques, such as BYOVD abuse and ESXi policy weakening, that remain relevant risks in the ransomware ecosystem. However, these techniques should not be attributed to this incident without supporting driver load, process, memory, ESXi, vCenter, or backup platform telemetry. We describe these techniques below as they may prove useful in other ransomware-related forensic investigations.

The examples used in this section are therefore ecosystem-relevant: they are commonly observed in ransomware operations but not conclusively attributed to the analyzed PAYLOAD samples.

ETW suppression and in-memory patching

Event Tracing for Windows (ETW) is a kernel-supported tracing architecture used by Windows components, diagnostic utilities, security products, and endpoint monitoring systems.

Although we didn’t encounter this technique in our case, some ransomware families can patch ETW-related functions inside the ransomware process (T1685, formerly T1562.001). The reported routine changes the memory protection of code pages, overwrites the beginning of selected ETW functions so they return without producing events, restores the original protection, and refreshes the instruction cache.

Reported target functions include EtwEventWrite, EtwEventWriteFull, EtwEventWriteTransfer, and EtwRegister.

This modification applies to the process-local mapping of ntdll.dll. It does not disable ETW globally across Windows, but it can reduce the telemetry generated by the modified process.

Forensic indicators

• Writable or recently modified executable pages within ntdll.dll
• Memory protection changes affecting ETW function addresses
• In-memory code differing from the corresponding clean DLL on disk
• EDR memory tampering alerts
• Unexpected calls to memory protection APIs followed by telemetry silence
• Process execution visible in network or filesystem telemetry but absent from expected ETW-derived sources
• Inconsistent telemetry between EDR, Sysmon, Windows Event Logs, and network monitoring

It should be noted that telemetry gaps are not conclusive evidence of ETW patching. Other factors include agent upgrades, network outages, endpoint shutdowns, SIEM ingestion failures, collector backpressure, and filtering or licensing changes.

Memory acquisition is the strongest validation source when process-local ETW patching is suspected.

Vulnerable signed driver abuse, BYOVD

Bring Your Own Vulnerable Driver (BYOVD) involves introducing or abusing a legitimately signed but vulnerable kernel driver (T1068 and T1685). The attacker exploits the driver’s exposed functionality to gain kernel-level capabilities, modify protected memory, terminate security processes, remove security callbacks, or bypass operating system security controls.

BYOVD is highly relevant to contemporary ransomware operations. However, the reviewed public PAYLOAD analyses do not provide sufficient evidence to conclude that BYOVD is an intrinsic PAYLOAD capability.

It should therefore be presented as an ecosystem-relevant technique rather than a confirmed PAYLOAD feature.

Forensic indicators

• Unexpected .sys files written to user-writable or temporary directories
• New kernel driver services
• Sysmon Event ID 6
• Driver hashes matching Microsoft or community vulnerable driver blocklists
• Invalid, revoked, expired, or unusual driver signatures
• Driver load followed by EDR termination
• New privileged processes immediately following driver loading
• Code Integrity or Defender alerts
• Service creation events referencing driver files

ESXi security policy weakening

Ransomware operators are increasingly targeting ESXi and vCenter because compromising the virtualization layer provides access to many business-critical virtual machines.

Public research typically describes operators performing the following activities (T1685, T1490 and T1489):

• Enabling SSH on ESXi hosts
• Changing root passwords
• Disabling execInstalledOnly
• Modifying lockdown mode exceptions
• Stopping virtual machines
• Deleting snapshots and backups
• Changing host firewall policies
• Copying custom ransomware binaries to hypervisors

On the target organization’s Linux servers we saw an ESXi PAYLOAD variant, which makes this behavior operationally relevant. Nevertheless, the reviewed evidence does not indicate that PAYLOAD operators used any of these policy-weakening actions in the investigated incident.

Forensic indicators

• Unexpected ESXi SSH enablement
• Changes to execInstalledOnly
• Secure Boot enforcement changes
• Lockdown mode configuration changes
• Root password changes
• New or unusual administrator accounts
• Bulk VM shutdown activity
• Bulk snapshot deletion
• New binaries in datastore or temporary paths
• vCenter tasks originating from unexpected accounts or systems
• Missing or disabled remote syslog forwarding

Remediation

To contain the described threat and limit possible damage, several remediation steps should be taken. Below, we recommend a four-phase remediation approach for containing this threat and restoring the affected environment.

Phase 1 — domain controller actions (to be performed first)

When dealing with PAYLOAD GPO, the first priority of the remediation plan should be to remove the source GPOs. Until this is done, endpoint cleanup is ineffective because the next policy refresh re-infects cleaned machines.

The immediate domain controller actions to be taken are:

1. Delete PAYLOAD GPO. Remove {C897F2C7-C2AC-4E6F-BF48-58036FF29E79} via GPMC.
2. Delete or revert win Firewall Off GPO. Remove {22099AD2-E062-4F56-B574-5099BBA4E7A6}.
3. Clean SYSVOL. Delete jpg and hello.txt from \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\.
4. Rotate credentials. Reset the compromised account; audit all privileged accounts and group memberships for unauthorized changes; rotate krbtgt twice if domain admin compromise is confirmed.
5. Force refresh. Perform gpupdate /force across endpoints after deletion; re-enable local administrator and firewall via clean policy.

Phase 2 — Active Directory and GPO hardening

• Adopt the AD tiered administration model and confine domain admins to Tier 0 with no interactive logon to workstations and member servers.
• Separate GPO creation from GPO linking rights, and grant both only to a dedicated, audited administrator role.
• Enable GPO change auditing (Event IDs 5136, 5137, 5141) and forward to a SIEM.
• Monitor SYSVOL with file integrity tooling.

Phase 3 — credential and access hardening

• Enforce phishing-resistant MFA on all VPN and remote access entry points.
• Deploy Windows LAPS to generate unique, rotated local administrator passwords.
• Enable Credential Guard to protect LSASS-resident secrets.
• Adopt Privileged Access Workstations (PAW) for all administration.
• Implement just-in-time elevation through Privileged Identity Management (PIM) for domain admin.

Phase 4 — detection and monitoring

• SIEM rule: GPO creation or domain-root gPLink change by a non-standard account.
• SIEM rule: file creation events under SYSVOL from non-replication sources.
• Implement enhanced, centrally collected FortiGate SSL VPN logging (auth events, session detail, source IP geolocation, impossible travel check) and detailed perimeter monitoring.
• Deploy a canary GPO whose application anywhere signals attacker GPO write access.

Conclusion

PAYLOAD demonstrates a maturing tactic of turning the victim’s own trusted infrastructure into a weapon. By weaponizing Group Policy, the actor achieved a domain-wide impact without a single malicious binary on any endpoint, evaded file- and process-based detection entirely, and caused organization-wide disruption within seconds of the first reboot.

The absence of encryption is the most strategically significant finding and is consistent with the 2026 trend toward encryptionless extortion. At Kaspersky GERT, we assess with moderate confidence that the missing encryption reflects one of two scenarios: (1) a deliberate decision to stay below the irreversible data destruction threshold while preserving the option of a follow-on encryption phase, or (2) an operation interrupted before full execution.

The absence of encrypted files must not be mistaken for the absence of a serious compromise — the most critical impact lies in the actor gaining domain admin-level control. This incident proves that a threat actor with domain admin access and a working knowledge of group policy internals can inflict domain-wide disruption equivalent to a ransomware attack without writing a single malicious file to any endpoint.

Detection strategies anchored solely in file- or process-based indicators are blind to this attack class. Effective controls include directory service change auditing, SYSVOL integrity monitoring, and privileged access governance, which allow for GPO protection.

Detection by Kaspersky solutions

Kaspersky security solutions effectively detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below.
To protect organizations that use our Kaspersky SIEM system, we have prepared a package of correlation rules designed to help detect this type of malicious activity. The rules are now available for customers to download from the SIEM repository; the package name is: [OOTB] Group policy hijacked: PAYLOAD ransomware – ENG.

The “Group policy hijacked: PAYLOAD ransomware” package contains rules that detect suspicious file creation or modification in the SYSVOL shared folder on a domain controller, as well as changes to critical attributes and settings of domain group policies. Some rules may require adjustment if they trigger in response to legitimate activity, such as synchronization between domain controllers or the configuration of a new group policy.

To ensure the detection rules function correctly, verify that events from Windows systems are being received in full, including events with the following identifiers: Sysmon: 11, Security — 4663, 5136, 4657.

We also recommend applying the following rules available in the repository to detect all attack stages.

• Detection of Windows Event Log clearing to cover up traces of an attack: R050_03_Windows Event Log was cleared
• Detection of suspicious access to the LSASS process, which may indicate attempts to dump credentials: R262_Suspicious access to the LSASS process
• Detection of the Volume Shadow Copy service being started, which is used to create shadow copies before deleting them: R231_20_Running the Volume Shadow Copy service
• Detection of shadow copy deletion: R321_Shadow copy deletion
• Detection of Windows Defender disablement: R076_01_Windows Defender Antivirus was disabled
• Detection of attempts to disable or modify the system firewall: R240_03_Disabling system firewall via the registry
• Detection of a service installation from a non-system folder, which may indicate malware persistence techniques: R281_01_Installation of a service from a non-system folder

For the rules in this list to function correctly, it is necessary to configure Security event auditing for event IDs 4663, 5136, 4657, 7036, and 1102.

In addition to the SIEM system, when audit settings are configured correctly, the process of creating, modifying, and deleting GPOs generates a large number of characteristic artifacts on the domain controller, enabling Kaspersky Endpoint Detection and Response Expert to promptly alert the user to anomalies in the infrastructure.

The creation of a new GPO is covered by the gpo_creation rule, which triggers in response to the corresponding event in the infrastructure. Changes to existing policies are detected by the following rules:

• The setting_the_gpcmachineextensionname_attribute rule detects changes to the gPCMachineExtensionNames attribute.
• The setting_the_gpcfilesyspath_attribute rule detects the use of the gPCFileSysPath attribute of a Group Policy Object, which specifies the path to the GPO’s contents in SYSVOL.
• The broader rule setting_the_grouppolicycontainer_class detects a change to the groupPolicyContainer class.

GPO deletion is covered by the gpo_deletion rule.

In the next major version update of Kaspersky EDR Expert, a new event type, GPO, will be introduced, allowing users to track changes to Group Policy Objects.

For information security officers, GPO events will serve as an additional source of context when investigating activity in Active Directory and will help detect changes that could affect the configuration, access rights, and security of endpoints before a potentially malicious policy is deployed.

MITRE ATT&CK mapping

Tactic	Technique	Observed behavior
Initial Access	T1078 — Valid Accounts	Compromised domain credential used for VPN authentication
Initial Access	T1133 — External Remote Services	FortiGate SSL VPN used as entry point
Privilege Escalation	T1078.002 — Domain Accounts	Account held domain-level GPO create/link rights
Privilege Escalation/Defense Impairment	T1484.001 — Group Policy Modification	Malicious PAYLOAD GPO created and linked at domain root; re-applies on every refresh/reboot; uses trusted channel to evade EDR
Defense Impairment	T1686 — Disable or Modify System Firewall	win Firewall Off GPO disables Windows Firewall on all profiles
Impact	T1491.001 — Internal Defacement	Wallpaper and lock screen replaced with ransom image
Impact	T1531 — Account Access Removal	Local Administrator account disabled via GPO Security Settings
Collection	T1005 — Data from Local System	Data exfiltration was observed originating from the file servers
Command and Control	T1071 — Application Layer Protocol	No live C2 confirmed; delivery achieved entirely via GPO

Indicators of compromise

GPOs
PAYLOAD ransomware GPO: {C897F2C7-C2AC-4E6F-BF48-58036FF29E79}
win Firewall Off GPO: {22099AD2-E062-4F56-B574-5099BBA4E7A6}

File names and MD5 hashes
payload.jpg: Ransom wallpaper and lock screen image (SYSVOL)
hello.txt: Ransom note source (SYSVOL)
README-payload.txt: Ransom note dropped to desktops and drive roots
killer.exe (0108656A3E1ADE6CA4F21B084F5E1208): process killer tool
kill.exe (BEA5E267F24D7DA59F6821BFFDBFF293): process killer tool

IP addresses
37.19.210[.]12
146.70.117[.]239
149.102.229[.]154
104.164.55[.]46
104.28.162[.]228
104.28.163[.]162
64.190.76[.]14
192.42.116[.]50
192.42.116[.]12
192.42.116[.]56
192.42.116[.]97
192.42.116[.]52

Registry keys
HKLM\...\Policies\System\legalnoticecaption = Welcome to Payload!

SYSVOL path
\\DC.THECOMPANY.local\sysvol\THECOMPANY.local\payload.jpg

Event IDs
5137: GPO object creation on DC — review creator account
5136: GPO attribute modification — watch gPLink at domain root

O Brasil foi o terceiro país que mais sofreu ataques com ransomwares em junho, registrando 23 casos. Os dados são da plataforma Ransomware.live, iniciativa de Julien Mousqueton, CISO da Cohesity, empresa líder em segurança de dados com IA. É a primeira vez que o Brasil aparece entre os dez países mais afetados desde o início da publicação de dados do site, em janeiro.

A plataforma monitora e coleta dados de sites de vazamento de grupos de ransomware continuamente para identificar e listar novas vítimas. Ransomwares são softwares maliciosos que bloqueiam o acesso de usuários ou organizações, exigindo pagamento de resgate para restauração, sob a ameaça de vazamento ou exclusão permanente.

O Brasil só aparece atrás de Estados Unidos, com 199 casos, e Alemanha, com 49. O Reino Unido vem logo após o Brasil, com 21, seguido de Índia e Canadá, ambos com 20. França (15), Itália (15), México (14) e Tailândia (13) completam o top 10.

“A emergência do Brasil, Índia e Tailândia como alvos recém identificados pode ser reflexo de uma estratégia deliberada de focar em jurisdições com menor maturidade na resposta a incidentes e na coordenação com forças de segurança”, avalia Gustavo Leite, vice-presidente da Cohesity para América Latina.

O número total de vítimas em junho, 708, representa uma redução de 10,5% em relação às 791 registradas em maio. “Apesar dessa diminuição mensal, o volume permanece historicamente elevado quando comparado aos doze meses anteriores, deixando claro o quão intenso e consistente é o atual cenário de ameaças”, aponta Leite.

Setores mais afetados

Em junho, o mercado B2B se manteve no topo dos alvos mais atingidos, registrando 123 vítimas — uma redução de 23,1% em comparação às 160 de maio. O setor de manufatura ficou na segunda colocação, com 83 ocorrências (queda de 19,4%), seguido por tecnologia, que somou 56 vítimas (recuo de 21,1%).

O segmento de saúde contabilizou 52 vítimas, registrando uma queda de 23,5% em relação às 68 do mês anterior. Na contramão, serviços ao consumidor foi o único a apresentar crescimento: uma alta discreta de 1,9%, passando de 52 para 53 vítimas. Já o setor de serviços financeiros teve um recuo de 26,5%, somando 25 vítimas, enquanto transporte/logística baixou 25,7%, chegando a 26 registros.

Números do site Ransomware.live são divulgados todos os meses pela Cohesity, que conta com a confiança de clientes em mais de 140 países, incluindo 70% da Fortune Global 500.

Ataques com ransomware nos últimos 12 meses:

• Junho – 708
• Maio – 791
• Abril – 870
• Março – 844
• Fevereiro – 784
• Janeiro – 702
• Dezembro de 2025 – 882
• Novembro de 2025- 717
• Outubro de 2025 – 839
• Setembro de 2025 – 598
• Agosto de 2025 – 530
• Julho de 2025 – 547

Setores com ransomwares mais afetados em junho:

1. Mercado B2B – 123 (queda de 23.1% em relação a maio)
2. Manufatura – 83 (queda de 19.4% em relação a maio)
3. Tecnologia – 56 (queda de 21.1% em relação a maio)
4. Serviços ao consumidor – 53 (aumento de 1.9% em relação a maio)
5. Saúde – 52 (queda de 23.5% em relação a maio)
6. Agricultura e produção de alimentos – 36 (queda de 7.7% em relação a maio)
7. Construção – 27 (queda de 15.6% em relação a maio)
8. Transportes/logísticas – 26 (queda de 25.7% em relação a maio)
9. Serviços financeiros – 25 (queda de 26.5% em relação a maio)
10.  Educação – 24 (queda de 14.3% em relação a maio)

Países mais afetados por ataques com ransomwares em junho:

1. Estados Unidos – 199
2. Alemanha – 49
3. Brasil – 23
4. Reino Unido – 21
5. Índia – 20
6. Canadá – 20
7. França – 15
8. Itália – 15
9. México – 14
10. Tailândia – 13

O IDCiber Threat Intelligence Center, por meio do monitoramento contínuo de fontes abertas, fóruns clandestinos e canais especializados, identificou a divulgação de uma alegada base de dados associada ao domínio governamental www.gov.il, anunciada por um ator de ameaça em 22/06/2025. Segundo a publicação analisada, o grupo afirma ter explorado uma vulnerabilidade de API e obtido acesso não autorizado a informações de aproximadamente 268.938 registros de cidadãos, contendo dados pessoais diversos. As evidências observadas incluem amostras de registros supostamente extraídos da base comprometida e disponibilizados em plataforma pública de compartilhamento de conteúdo. Em conformidade com as melhores práticas de proteção à privacidade, os dados pessoais identificáveis (PII) presentes nas amostras foram anonimizados nesta análise, não sendo reproduzidos nomes, documentos, telefones, endereços, e-mails, identificadores ou quaisquer informações que permitam a identificação direta de indivíduos.

A análise preliminar indica que o conjunto de informações alegadamente exposto contém categorias de dados de elevada sensibilidade, incluindo dados cadastrais, informações demográficas, informações de contato, dados de localização e outros atributos pessoais. Caso a autenticidade e atualidade da base sejam confirmadas pelas autoridades competentes, o incidente poderá representar riscos significativos de fraude, engenharia social, campanhas de phishing direcionado, roubo de identidade, comprometimento de contas e outras atividades criminosas. O anúncio também demonstra intenção de monetização dos dados por parte do ator de ameaça, que disponibilizou canal de contato para potenciais interessados na aquisição do conteúdo.

Até o momento da análise, as evidências observadas permitem confirmar a existência de uma publicação reivindicando a violação e exibindo amostras de registros, porém a validação integral da autenticidade, integridade, abrangência e origem dos dados requer investigação técnica complementar pelas entidades responsáveis. Considerando o potencial impacto sobre cidadãos e organizações governamentais, recomenda-se a realização de procedimentos de resposta a incidentes, validação dos dados expostos, revisão dos controles de acesso, análise de vulnerabilidades em APIs, monitoramento reforçado de credenciais e comunicação adequada às partes potencialmente afetadas.

• Classificação do incidente: Vazamento de Dados (Data Breach)
• Organização alvo: Domínio governamental (www.gov.il)
• Data da divulgação identificada: 22/06/2025
• Volume alegado de impacto: 268.938 registros
• Tipo de informação exposta: Dados pessoais e cadastrais (PII) – informações anonimizadas neste relatório
• Severidade estimada: Alta
• Status: Publicação identificada e em monitoramento

Fonte: IDCiber Threat Intelligence Center.

O setor financeiro global enfrenta uma crise sem precedentes na segurança digital, onde pagar o resgate de dados sequestrados virou a regra, não a exceção. Nos últimos 12 meses, 79% das instituições financeiras que sofreram ataques cibernéticos optaram por pagar os criminosos para recuperar seus sistemas. O dado alarmante faz parte de um novo estudo da Cohesity, empresa líder em segurança de dados com Inteligência Artificial, que ouviu 390 tomadores de decisão de TI e segurança em grandes corporações da América do Sul, América do Norte, Europa e Ásia.

O levantamento traça um diagnóstico severo sobre a vulnerabilidade do mercado: 77% das empresas financeiras globais já foram vítimas de cibercriminosos, sendo que mais da metade (57%) foi alvo de investidas apenas no último ano. O impacto financeiro e reputacional é quase inevitável, com 87% das organizações registrando perdas diretas de receita e 93% enfrentando severas consequências regulatórias ou legais após as invasões.

Apesar do cenário de terra arrasada, a pesquisa revela uma desconexão preocupante entre a realidade dos ataques e a percepção de segurança das lideranças. O cenário atual exige uma mudança profunda de postura, já que as ameaças deixaram de ser eventos isolados para se tornarem uma constante no ambiente digital, com frequência e sofisticação cada vez maiores.

• Confiança em alta: Mesmo com uma em cada quatro empresas sendo atacada repetidamente, 46% dos entrevistados afirmam ter total confiança em suas estratégias de resiliência.
• O fator IA: A Inteligência Artificial surge como a grande aposta de defesa para 39% dos executivos, que acreditam que a tecnologia assumirá um papel central na detecção de ameaças e na tomada de decisões autônomas, otimizando a eficiência das equipes internas e do SOC (Security Operations Center) na resposta a incidentes.

A Estratégia da Sobrevivência: Organização Mínima Viável (MVC)

Diante do consenso de que é praticamente impossível blindar as empresas contra todos os tipos de ameaças, o mercado financeiro passou a adotar uma nova filosofia de sobrevivência: o conceito de Minimum Viable Company (MVC), ou Organização Mínima Viável.

Em vez de gastar energia e tempo tentando reerguer toda a infraestrutura tecnológica de uma só vez após um apagão cibernético, o foco da estratégia MVC muda drasticamente. A prioridade máxima passa a ser a recuperação estritamente essencial. O objetivo é colocar de pé a menor versão funcional possível da empresa, garantindo que o negócio continue operando (mesmo que de forma limitada ou sob condições degradadas) até que a crise seja totalmente controlada.

Medidas Práticas: O Caminho para a Resiliência

Para enfrentar o aumento dessas ameaças, viabilizar a estratégia de MVC e reduzir vulnerabilidades críticas, a Clavis Segurança da Informação destaca medidas prioritárias, com foco no SOC, voltadas à proteção e rápida recuperação do ambiente digital corporativo:

Treinamento de Colaboradores: A capacitação contínua transforma o elo mais fraco em defesa activa, reduzindo drasticamente a eficácia de ataques de phishing e engenharia social.

Controle de Identidade: A adoção de Autenticação Multifator (MFA) é a barreira mais eficiente para impedir que credenciais roubadas permitam o acesso indevido a dados sensíveis.

Monitoramento e Auditoria: O acompanhamento em tempo real permite detectar anomalias rapidamente, enquanto auditorias frequentes corrigem vulnerabilidades antes que sejam exploradas por criminosos.

Automação de Segurança: O uso de ferramentas automatizadas acelera a resposta a incidentes e reduz a janela de exposição de falhas críticas, que pode superar 55 dias.

Backup e Recuperação: Manter cópias de segurança isoladas e planos de recuperação testados garante a continuidade do negócio e protege a empresa contra extorsões digitais.

A segurança de redes corporativas consolida-se como um pilar indispensável para a estabilidade e o crescimento sustentável no mercado brasileiro. Com ameaças cada vez mais ágeis e onerosas, investir em um ecossistema que integre soluções tecnológicas, processos automatizados e conscientização humana deixa de ser uma demanda técnica para se tornar um diferencial competitivo estratégico.

Ataques com ransomwares fizeram 791 vítimas no mês de maio, numa leve diminuição de 9,1% em comparação aos 870 registrados em abril. Os dados são da plataforma Ransomware.live, iniciativa de Julien Mousqueton, especialista em cibersegurança e executivo da Cohesity, empresa líder em segurança de dados com IA.

O site monitora e coleta dados de sites de vazamento de grupos de ransomware continuamente para identificar e listar novas vítimas. Ransomwares são softwares maliciosos que bloqueiam o acesso de usuários ou organizações, exigindo pagamento de resgate para restauração, sob a ameaça de vazamento ou exclusão permanente.

Olhando para os últimos 12 meses, a atividade permanece substancialmente elevada. O número de maio está bem acima da faixa de 501 a 598 vista entre junho e setembro, e somente um pouco abaixo do pico recente de 882 em dezembro. “A queda de 9,1% em relação a abril é estatisticamente notável, mas não deve ser interpretada como evidência de uma queda sustentada”, analisa Gustavo Leite, vice-presidente da Cohesity para América Latina e Caribe.

Apesar desse recuo, o cenário de ameaças permaneceu dinâmico, diz. “Quatro grupos divulgaram suas primeiras vítimas em maio, e nove agentes novos apareceram em sites de vazamento. Isso sinaliza a fragmentação contínua do ecossistema de ‘ransomware-as-a-service’, quando desenvolvedores profissionais alugam ou vendem sua infraestrutura para outros hackers”.

Segundo Leite, o surgimento de nove atores em um mês reflete a fragmentação do ecossistema, onde afiliados mudam de nome ou se separam de grandes operações. Apesar desse influxo, 15 grupos antes ativos ficaram inativos em maio. “Embora novas operações surjam, muitas são efêmeras devido à pressão policial, dissolução interna ou mudança de identidade”, destaca.

Países e setores mais afetados

Os Estados Unidos seguiram como o país mais afetado, representando 309 das 791 vítimas (39,1%). O Reino Unido (49 vítimas) e a Alemanha (41 vítimas) ocuparam o segundo e o terceiro lugares, respectivamente. O Canadá (32), a Espanha (23) e o Japão (17), aparecem em seguida, antes de Austrália (20), México (16) e França (16).

O mercado B2B continuou sendo o mais visado, com 160 vítimas. O setor de manufatura registrou 103 casos, seguido pelos setores de tecnologia (71) e saúde (68). “O alto volume registrado constantemente no setor de saúde ressalta a persistente atratividade do setor para operadores de ransomware que buscam alvos com alto potencial de exploração”, diz o executivo.

O vice-presidente da Cohesity para América Latina e Caribe também chamou a atenção para os 39 casos no setor de agricultura e produção de alimentos. “Ataques a esse setor têm aumentado, numa tendência que merece atenção, dadas as implicações para a infraestrutura crítica das cadeias de suprimentos de alimentos”, disse. O setor de educação figurou pela primeira vez no ranking dos dez principais setores neste mês, com 28 vítimas.

Números do site Ransomware.live são divulgados todos os meses pela Cohesity, que conta com a confiança de clientes em mais de 140 países, incluindo 70% da Fortune Global 500.

Ataques com ransomware nos últimos 12 meses:

• Maio – 791
• Abril – 870
• Março – 844
• Fevereiro – 784
• Janeiro – 702
• Dezembro de 2025 – 882
• Novembro – 717
• Outubro – 839
• Setembro – 598
• Agosto – 530
• Julho – 547
• Junho – 501

Setores com ransomwares mais afetados em maio:

1. Mercado B2B – 160
2. Manufatura – 103
3. Tecnologia – 71
4. Saúde – 68
5. Serviços ao consumidor – 52
6. Agricultura e produção de alimentos – 39
7. Transportes/logísticas – 35
8. Serviços financeiros – 34
9. Construção – 32
10. Educação – 28

Países mais afetados por ataques com ransomwares em maio:

1. Estados Unidos – 309
2. Reino Unido – 49
3. Alemanha – 41
4. Canadá – 32
5. Espanha – 23
6. Austrália – 20
7. Itália – 20
8. Japão – 17
9. França – 16
10. México – 16

Os cibercriminosos agora visam os serviços financeiros mais do que qualquer outro setor para ataques de negação de serviço distribuída (DDoS) na web e em APIs (camadas 3 e 4), revela a Akamai (NASDAQ: AKAM) em seu relatório State of the Internet (SOTI) intitulado AI-Empowered Botnets and API Visibility Gaps: Attack Trends in Financial Services. As descobertas revelam uma mudança perigosa à medida que hacktivistas pró-Irã e bots impulsionados por IA usam táticas de DDoS para interromper serviços bancários online, sistemas de pagamento e aplicações críticas.

Impulsionada por infraestruturas alimentadas por IA, a duração média dos ataques globais de DDoS das camadas 3 e 4 direcionados ao setor de serviços financeiros aumentou 738% desde 2024. Isso mostra que, embora a transformação digital tenha permitido avanços como serviços bancários online e pagamentos em tempo real, ela também facilitou as invasões.

Algumas descobertas importantes do relatório:

• Entre os líderes de serviços financeiros entrevistados no Estudo sobre o impacto da segurança de APIs de 2026, 96% relataram pelo menos um incidente com a segurança de APIs nos últimos 12 meses, o índice mais alto entre todos os setores.

• Em 2025, 60% do total de ataques na web e 83% das incursões contra pontos de extremidade de APIs visaram serviços bancários.

• Quase 80% das instituições financeiras enfrentaram ataques de ransomware nos últimos dois anos, mas menos da metade adotou tecnologias avançadas de segurança.

• A atividade avançada de bots aumentou 147% no final de 2025 e, em um estudo de caso, impressionantes 96% de todo o tráfego de websites foram identificados como bots de scraping mal-intencionados.

• Os métodos de ataques cibernéticos contra serviços financeiros variam significativamente de acordo com a região: a EMEA é o principal alvo de DDoS das camadas 3 e 4 (62%), a APAC é a mais visada por DDoS da camada 7 (52%) e, na América do Norte, os ataques na web são os mais predominantes (44%).

“Os cibercriminosos e hacktivistas continuam impulsionando os ataques de DDoS, transformando-os em uma ameaça constante, e os serviços financeiros estão na mira”, afirma Steve Winterfeld, CISO consultivo da Akamai. “Além disso, os dados mostram que as APIs são cada vez mais visadas, pois a IA não reduz os riscos de segurança tradicionais, ela os amplifica. Felizmente, as organizações de serviços financeiros podem aproveitar as estratégias de segurança e as práticas recomendadas detalhadas neste relatório.”

O relatório também mostra tendências baseadas em dados sobre atividades criminosas, a participação do CISO da FS-ISAC, um destaque de segurança sobre recursos MITRE, um destaque de nuvem sobre as diferenças entre arquiteturas de IA e estratégias práticas de mitigação de ataques de DNS e DDoS.

Já em seu 12º ano, os relatórios SOTI Security da Akamai continuam oferecendo insights críticos sobre tendências de cibersegurança e desempenho na web, extraídos de ataques observados na infraestrutura protetiva de cibersegurança da Akamai, que lida com uma parcela significativa do tráfego global da web.

Sobre a Akamai

A Akamai é a empresa de cibersegurança e computação em nuvem que potencializa e protege negócios online. Nossas soluções de segurança líderes de mercado, inteligência avançada contra ameaças e equipe de operações globais oferecem defesa em profundidade para garantir a segurança de dados e aplicações empresariais em todos os lugares. As abrangentes soluções de computação em nuvem da Akamai oferecem desempenho e acessibilidade na plataforma mais distribuída do mundo. Empresas globais confiam na Akamai para obter a confiabilidade, a escala e a experiência necessárias para expandir seus negócios com confiança. Saiba mais em akamai.com e akamai.com/blog, ou siga a Akamai Technologies no X e no LinkedIn.

Neste ano, o Brasil sofreu mais de 315 bilhões de tentativas de ataque cibernético apenas no primeiro semestre — número que representa cerca de 84% de todo o tráfego malicioso registrado na América Latina no período, de acordo com um levantamento da Fortinet divulgado em agosto passado. Com adversários fazendo uso crescente de IA para conduzir campanhas de phishing, ataques DDoS e exploração de vulnerabilidades em ambientes híbridos e multicloud, líderes de segurança corporativa se veem diante de uma encruzilhada: manter o SOC (Security Operations Center) da forma como está ou apostar em novas tecnologias e formas de trabalho que respondam à nova realidade.

Grupos criminosos adotam táticas avançadas e combinam técnicas de Advanced Persistent Threat (APT) com ferramentas de IA para driblar as defesas tradicionais. Golpes que envolvem deepfakes ou phishing automatizado por IA tornam cada vez mais difícil distinguir o legítimo do malicioso. Ao mesmo tempo, a superfície de ataque das organizações se expandiu dramaticamente. Com ambientes de TI híbridos e multicloud, centenas de novos serviços e integrações são adicionados constantemente aos ecossistemas corporativos, abrindo brechas que muitas vezes são difíceis de monitorar.

O problema é que grande parte dos SOCs atuais foi concebida para um contexto em que as ameaças eram baseadas em assinatura e o volume de eventos era controlável. Hoje, porém, a multiplicação de fontes de telemetria, tais como endpoints, nuvens, APIs, identidades, dispositivos IoT e aplicações SaaS, faz com que o volume de logs cresça de forma exponencial.

Não se trata apenas de mais dados, mas de dados de naturezas distintas, com diferentes formatos, níveis de granularidade e relevância operacional. Ferramentas modernas de detecção e monitoramento, como EDRs, XDRs e soluções de observabilidade, coletam informações em tempo real e geram fluxos contínuos de telemetria que precisam ser correlacionados com ameaças conhecidas e comportamentos anômalos. Sem uma arquitetura de dados e automação adequadas, esse ecossistema torna-se difícil de orquestrar – e o SOC passa a lidar menos com ruído e mais com complexidade analítica. O desafio, portanto, deixou de ser filtrar falsos positivos e passou a ser transformar grandes volumes de logs em inteligência acionável com velocidade e contexto.

E, quando os adversários passam a empregar IA para criar malwares praticamente indetectáveis, um SOC calcado apenas em esforço humano não consegue escalar na mesma proporção do risco. O resultado é um descompasso perigoso entre a capacidade defensiva e a velocidade com que as ameaças modernas atuam, evidenciando que manter o status quo não é mais sustentável.

Uma das principais transformações em curso é a adoção do modelo de SOC as a Service, que redefine a forma como as empresas estruturam sua defesa cibernética. Diferente do modelo híbrido ou totalmente interno, o SOCaaS oferece monitoramento, detecção e resposta a incidentes 24×7 por meio de uma plataforma escalável e baseada em nuvem, administrada por especialistas em cibersegurança.

Esse formato elimina a necessidade de manter infraestrutura local pesada e reduz o tempo de implantação, ao mesmo tempo em que garante acesso contínuo a tecnologias e analistas altamente especializados.

Ao integrar telemetria proveniente de múltiplas camadas, o SOC as a Service consolida os eventos em um único datalake de análise, aplicando correlação e contextualização automatizadas com apoio de SOAR e machine learning. Assim, os alertas deixam de ser tratados de forma isolada e passam a compor narrativas completas de ataque, permitindo uma visão tática e antecipada das ameaças.

Essa automação nativa reduz drasticamente o tempo médio de detecção (MTTD) e o tempo médio de resposta (MTTR), pontos críticos para conter ataques modernos que podem se propagar em minutos.

Outro benefício do modelo é a atualização contínua da inteligência de ameaças. Fornecedores de SOCaaS normalmente operam com bases globais de threat intelligence, alimentadas por fontes de ciberinteligência regionais e internacionais.

Essa atualização constante amplia a visibilidade sobre novas campanhas maliciosas, técnicas de exploração e indicadores de comprometimento (IoCs), garantindo que o ambiente corporativo permaneça protegido mesmo diante de vetores inéditos. Ao mesmo tempo, as plataformas de SOCaaS modernas integram recursos de análise comportamental (UEBA) e aprendizado contínuo, permitindo identificar padrões anômalos e prevenir movimentos laterais antes que evoluam para incidentes graves.

Mais do que uma modernização tecnológica, a adoção de modelos de SOC as a Service representa um novo paradigma de defesa cibernética. O CISO que ainda vê o SOC apenas como um centro de monitoramento precisa agora encará-lo como um núcleo de inteligência e antecipação, sustentado por automação, correlação de dados e aprendizado de máquina.