A cyber incident rarely begins with a message saying, “You’ve been hacked.” Usually, the first sign is a suspicious login to a corporate account, an unexpected email forwarding rule, a disabled EDR agent, an inaccessible server, or an employee’s complaint about an unusual multi-factor authentication request.

At this point, the organization does not yet know the scale of the attack. But it is precisely the initial decisions that determine whether the incident will remain a localized problem or escalate into a crisis lasting several weeks, resulting in business disruption, data loss, and reputational damage.

The time available for these decisions is shrinking. In the fastest cases investigated by Unit 42, attackers took 72 minutes to progress from initial access to a confirmed data exfiltration. This is roughly four times faster than a year earlier. This figure does not represent the average time for all attacks, but rather the fastest cases; however, it clearly demonstrates just how much the window of opportunity for defenders has narrowed. In our own investigations, we’ve seen attacks on AWS infrastructure take less than 10 minutes. As soon as the attacker obtained the key, they immediately began exfiltrating data. It took them just 6 minutes to start exfiltrating data from the company’s bucket.

The correct response in 2026 will not be a heroic scramble by the on-duty team. It is a pre-planned and managed process that allows you to quickly limit the attacker’s actions, preserve evidence, maintain critical operations, and restore systems to service without further compromise.

What Has Changed by 2026

Attacks no longer reside within a single system

A modern attacker can simultaneously exploit local infrastructure, a cloud account, corporate email, SaaS applications, and a contractor’s access credentials.

Even after an infected laptop is isolated, the attacker may still retain:

  • an active cloud session;
  • a refresh token;
  • an OAuth authorization;
  • an API key;
  • a compromised service account;
  • delegated administrative access;
  • a backup management channel via a legitimate cloud service.

According to Unit 42, in 87% of the incidents studied, determining what had happened required cross-referencing evidence from at least two different sources, and in the most complex cases, from ten. This means that investigations can no longer be limited to a single computer or a single event log: it is necessary to simultaneously analyze identity, endpoint, network, cloud, and SaaS data. (Unit 42)

The “find the malicious file, delete it, and reinstall the computer” model no longer provides adequate containment.

Identities and vulnerabilities are equally important

Modern incidents do not have a single, universal attack vector.

According to Unit 42, 65% of initial intrusions in its investigations were linked to identity-based techniques: stolen credentials, MFA manipulation, session hijacking, impersonating a support representative, or abusing legitimate remote access. (Unit 42)

At the same time, the Verizon DBIR 2026 identifies the exploitation of software vulnerabilities as the leading initial vector in its sample: it accounted for 31% of breaches and, for the first time, surpassed stolen credentials.

Practical takeaway: You cannot choose between identity protection and vulnerability management. A mature response program must address both areas. The team must be able to simultaneously revoke tokens and sessions, analyze privileged access, shut down vulnerable external services, and determine exactly which path the attacker used.

Vendors Have Become Part of the Attack Surface

According to the Verizon DBIR 2026, third parties were involved in 48% of data breaches—60% more often than the previous year. A software vendor, MSP, integrator, cloud service, or contractor with legitimate access can serve as an entry point.

An organization must understand in advance:

  • who can provide the vendor’s logs;
  • how quickly their access can be revoked;
  • how long telemetry is retained;
  • what actions are permitted under the contract;
  • who is responsible for communication;
  • how to preserve evidence on a third-party infrastructure.

If these questions arise for the first time during an attack, the team is already losing critical time.

Ransomware no longer requires encryption

Infrastructure encryption remains a serious threat, but it is no longer a mandatory part of ransomware attacks. Attackers can steal data and immediately move on to threats of publication or sale without triggering the large-scale encryption events that security measures are traditionally designed to detect.

Ransomware was present in nearly half of the data breaches examined in the Verizon DBIR 2026. However, the absence of encrypted servers does not mean the incident is insignificant: unauthorized access to email, CRM, file storage, or cloud environments can lead to comparable financial and reputational consequences.

AI Accelerates Both Sides

AI helps attackers analyze the attack surface more quickly, adapt social engineering tactics, search for vulnerabilities, and create malicious code. The Verizon DBIR 2026 highlights 15 attack techniques that are already being amplified by generative AI.

Defenders, in turn, use models to correlate events, build timelines, group alerts, and prepare queries for threat hunting.

But automation does not replace a verifiable process. A hasty, erroneous conclusion during a crisis can be just as dangerous as a slow response.

A New Framework: Response Begins Before an Incident

In April 2025, NIST released SP 800-61 Revision 3, which replaced the 2012 guidance.

The main change is that incident response is no longer viewed as a separate, linear process that is triggered after an alert. It is integrated into the overall NIST CSF 2.0 cyber risk management model and linked to all six of its functions:

Govern, Identify, Protect, Detect, Respond, and Recover.

Role management, asset inventory, segmentation, backup, vendor contracts, and logging are not merely supporting measures but integral parts of incident preparedness. (NIST Computer Security Resource Center)

On June 11, 2026, NIST also published IR 8374 Revision 1—an updated ransomware risk management profile based on CSF 2.0. The document integrates preparation, protection, response, and recovery into a single risk management cycle. (NIST Computer Security Resource Center)

The main takeaway is simple:

An effective response begins long before the first alert.

Before an incident occurs, an organization must define roles and responsibilities, establish an off-network communication channel, ensure adequate log retention, protect backups, and test recovery procedures. Separate playbooks are also necessary for ransomware, corporate email compromise, cloud account takeover, data theft, and attacks via contractors.

Drills are particularly important. A plan that exists only on paper and has never been tested under time pressure remains a mere assumption rather than a defense tool.

The First 60 Minutes: Don’t Treat the System Blindly

At the onset of an incident, the team almost always has incomplete information.

At this point, it’s not just the attacker’s actions that are dangerous, but also the defenders’ impulsive decisions: mass shutdowns of servers, premature system wipes, chaotic password changes, or immediate restoration from an untested backup.

1. Appoint an incident leader

A serious investigation cannot be conducted through chaotic phone calls, private messages, and dozens of parallel chat threads.

A unified response bridge and a designated Incident Commander are essential.

They are not required to personally perform forensic operations. Their task is to manage the process:

  • maintain a unified plan;
  • assign task owners;
  • resolve priority conflicts;
  • document decisions;
  • synchronize technical and managerial workflows;
  • regularly update the confirmed status;
  • monitor the coordination of critical actions.

The most technically skilled specialist does not necessarily have to lead the entire incident response. Analysts investigate the attack, while the Incident Commander ensures the investigation does not devolve into a series of uncoordinated actions.

2. Switch to a trusted communication channel

If corporate email, the authentication system, or a messaging app could be compromised, do not discuss the investigation within those platforms.

Use a pre-established out-of-band communication channel. Do not transmit the following via potentially compromised systems:

  • isolation plans;
  • investigation hypotheses;
  • new passwords;
  • keys and tokens;
  • evidence collected;
  • information about communication with the attacker;
  • internal management decisions.

An attacker who observes the team’s actions gains the ability to change tactics, cover their tracks, and prepare alternative access channels in advance.

3. Confirm the incident and determine its initial scope

You don’t need to wait for the full picture to begin your response.

The initial assessment should answer at least five questions:

  1. What exactly was detected?
  2. Which users, devices, and services may be affected?
  3. Is the attacker still active?
  4. Is there a risk of a critical process being disrupted?
  5. Are there signs of data theft, destruction of backups, or compromise of privileged access?

The classification may change as the investigation progresses. The key is to formulate a working hypothesis and set priorities as early as possible.

It is helpful to immediately distinguish between confirmed facts, probable conclusions, unverified hypotheses, and unknown circumstances. This reduces the risk that one analyst’s assumption will form the basis for a disastrous management decision.

4. Isolate, but do not destroy evidence

Isolation and shutdown are not the same thing.

An affected host should typically be disconnected from the network using EDR, NAC, VLAN, a switch, or a cloud policy. But unless absolutely necessary, you should not immediately:

  • shut it down or reboot it;
  • delete files;
  • run an antivirus scan;
  • reinstall the operating system;
  • put the device back into service after a superficial check.

Random-access memory may contain encryption keys, active network connections, embedded processes, access tokens, unrecorded commands, and traces of an attacker’s tools.

Exceptions may be made when continuing to operate the system poses an unacceptable threat to people, critical infrastructure, or the business. However, such a decision must be made deliberately and documented in the incident log.

5. Establish a Consistent Timeline

Record every significant event:

  • the time of the first alert;
  • the source of detection;
  • changes in system status;
  • administrator commands;
  • device isolation;
  • account lockouts;
  • log export;
  • creating snapshots;
  • decisions made;
  • persons responsible and those who approved the actions.

Use a single time zone, preferably UTC. Store the original logs separately from working copies, calculate checksums for the collected files, and record who worked with the evidence and when.

Without a timeline, an investigation quickly turns into a collection of conflicting recollections.

6. Protect Your Backups

In a ransomware incident, backup systems are often among the attacker’s first targets.

Do not begin a mass restore until you have determined:

  • whether the attacker has access to the backup console;
  • whether operator accounts have been compromised;
  • whether snapshots have been deleted;
  • whether storage policies have been modified;
  • when the initial intrusion is believed to have occurred;
  • Does the selected copy contain a pinning mechanism?
  • whether isolated or immutable copies have been preserved.

A successful status for the last backup job only confirms that a copy was created. It does not confirm that it is clean and suitable for secure recovery.

During an active incident, the PWN-ALL DFIR team can take over technical coordination: initial containment, preservation of evidence, determination of the scope of the compromise, and preparation of a secure recovery plan. The company’s practice deals with ransomware, data theft, BEC, account takeover, and cloud environment compromises.

The response must proceed along parallel tracks

A common mistake is to complete the technical investigation first and only then involve management, legal counsel, the insurer, and business owners.

In a real incident, these streams must proceed simultaneously.

Technical Track

The team must identify the attacker, determine the likely initial entry vector, identify affected assets and identities, locate persistence mechanisms, assess potential data exfiltration, and prepare for a secure recovery.

Management Workflow

Management and process owners must assess the business impact, establish recovery priorities, determine acceptable downtime, and coordinate actions to halt critical processes.

Legal and Communications Workflow

At the same time, it is necessary to identify the owners of the affected data, review contractual obligations, determine applicable notification requirements, contact the insurer, and prepare internal and external communications.

Specific requirements vary depending on the industry, contracts, and jurisdictions. Therefore, the legal assessment should not wait for the final forensic report.

The DFIR team’s task is to provide this workflow with verifiable technical facts: a timeline, a list of affected assets, confirmed indicators, an assessment of the initial point of access, and information about potential data exfiltration. The final legal determination rests with the organization’s specialized legal counsel.

Identity takeback: regaining control over identities

In a hybrid infrastructure, simply restoring a server is not enough. First, the organization must ensure that it has regained control over its own identity management system.

The following should be verified:

  • privileged and emergency accounts;
  • active sessions and refresh tokens;
  • new or modified MFA methods;
  • OAuth applications and granted permissions;
  • service principals and workload identities;
  • federation rules;
  • conditional access policies;
  • delegated administrative access;
  • API keys, certificates, and CI/CD secrets;
  • email forwarding rules;
  • registered devices;
  • contractor access.

Changing a password does not always terminate an active cloud session. Therefore, credential rotation must be accompanied by revoking tokens, terminating sessions, and verifying trusted applications.

It is particularly dangerous to perform a mass rotation from a compromised administrative environment.

First, a clean workspace is created with verified devices, a dedicated communication channel, controlled accounts, and independent logging. Only then does coordinated identity takeback begin.

The cloud and SaaS require a separate playbook

A cloud incident cannot be investigated like a typical workstation infection.

Some evidence exists only in the provider’s logs and may be retained for a limited time. In the first few hours, the following should be preserved:

  • login and audit logs;
  • IAM change history;
  • control plane logs;
  • email and collaboration events;
  • policy and network rule changes;
  • key and token creation details;
  • disk and configuration snapshots;
  • data from SaaS applications connected via SSO or OAuth.

Separately, it is necessary to verify the creation of new administrators, changes to federation settings, the issuance of long-lived tokens, OAuth consent grants, the disabling of security policies, the launch of new cloud resources, and data exports.

The procedure for emergency escalation to the provider, the parties’ authorities, and the procedure for retaining telemetry must be defined in advance.

PWN-ALL uses separate processes to investigate compromises of Microsoft 365, Google Workspace, cloud infrastructure, and corporate accounts. This allows for the analysis of actions that may not have left traces on traditional endpoints.

How to Use AI During an Investigation

AI can accelerate:

  • event normalization;
  • alert grouping;
  • timeline construction;
  • preparing queries for threat hunting;
  • correlating indicators;
  • anomaly detection;
  • analyzing large log files;
  • preparing interim reports.

However, the model should not independently make decisions that carry a high potential for damage.

A secure process involves using a controlled environment, minimizing sensitive data, logging requests and responses, having an analyst verify conclusions, and linking each hypothesis to the source telemetry.

Without additional approval, the model must not be authorized to shut down a critical segment, delete user accounts, perform mass rotation of secrets, destroy artifacts, publish notifications to customers, or make a final determination that no exfiltration has occurred.

AI can suggest a direction for the investigation. The responsibility for the conclusion remains with the human analyst.

Recovery does not mean returning to the previous state

The most dangerous phrase during an incident:

“Let’s just restore everything from the backup.”

If you restore the previous architecture along with its old vulnerabilities, compromised secrets, and configuration errors, an attacker could return.

Secure recovery is performed in stages:

  1. A clean administrative environment is created.
  2. Regain control over identities.
  3. The initial point of entry is closed.
  4. Persistence mechanisms are removed.
  5. Secrets, keys, tokens, and certificates are rotated.
  6. Backups are verified.
  7. Critical dependencies are restored.
  8. Systems are connected in controlled groups.
  9. Security and operability are verified at each stage.
  10. Enhanced monitoring continues after launch.

The business owner confirms the service is functional, and the security team confirms there are no known signs of ongoing compromise.

System availability does not yet mean the incident is over.

As part of the recovery process, PWN-ALL evaluates clean backups, the feasibility of rebuilding systems, available decryption and key recovery options, and then establishes priorities for restoring the infrastructure to operation. The outcome depends on the ransomware family, the state of the systems, the evidence preserved, and the quality of the backups; therefore, full decryption or the recovery of all data cannot be guaranteed.

If an organization is considering paying the ransom

A professional approach to ransomware should not be based on the assumption that payment is ruled out under any circumstances.

Sometimes management considers it due to threats to human life or safety, the shutdown of critical processes, the lack of usable backups, the risk of irreversible business loss, or the extremely high cost of prolonged downtime.

Official recommendations do not support paying the ransom: it does not guarantee the restoration of access to data, the removal of the malicious presence, or the deletion of stolen information. Furthermore, an organization that pays may become a target again.

That said, paying the ransom is not a technical action but an exceptional management decision made in a crisis situation.

First, alternatives must be explored

Before making a decision, you should assess:

  • the viability of backups;
  • the possibility of partial recovery;
  • the reconstruction of critical services;
  • temporary manual processes;
  • the availability of decryptors;
  • the ability to recover data from other sources;
  • acceptable duration of the emergency mode.

The attacker’s claim that payment is the only way out cannot be accepted without an independent technical review.

PWN-ALL can assess the actual state of the infrastructure and backups, investigate the possibility of decryption or key recovery, and provide management with a comparison of available scenarios. The final decision rests with the authorized representatives of the affected organization.

It is necessary to determine the actual consequences

It is not enough to simply compare the ransom amount and the cost of recovery.

One must consider the impact on people, the duration of downtime, the resilience of temporary processes, the consequences for customers and partners, the likelihood of data being published, the cost of a secure recovery, and reputational damage.

The decision must be based on verified facts, not just on the attacker’s promises and deadlines.

Legal and sanctions-related restrictions are assessed separately

The recipient, an affiliated group, an intermediary, or the payment infrastructure used may be subject to sanctions or other restrictions.

Official sanctions authorities explicitly warn of the risks to companies that facilitate ransomware payments. Therefore, applicable restrictions must be verified by qualified legal and sanctions advisors before any action is taken.

PWN-ALL handles the technical aspects of the process: it collects data on the attacker’s infrastructure, verifies the attacker’s claims, documents communications, and provides materials to the insurer and relevant advisors. The legal assessment and decision regarding the transaction remain the responsibility of the organization and its authorized advisors.

Communication with the attacker must be controlled

Independent correspondence with the extortionist may reveal the criticality of specific systems, the organization’s internal state, or the limits of its capabilities.

With appropriate approval, PWN-ALL can facilitate controlled communication, helping to:

  • verify whether the attacker actually possesses the claimed data;
  • request a test decryption;
  • assess the decryptor’s functionality;
  • determine the technical feasibility of the demands;
  • gain additional time;
  • maintain a complete history of communications and decisions.

This support does not replace a legal review, does not constitute a recommendation to pay, and does not grant the DFIR team the authority to make decisions on behalf of the client.

The attacker’s claims must be verified

Prior to a final decision, the following may be requested: a test decryption of a limited set of files, proof of access to the claimed data, and confirmation of the proposed tool’s functionality.

However, even a successful verification does not guarantee full recovery.

The attacker may provide an unstable decryptor, decrypt only a portion of the data, retain the stolen information, pass it on to other parties, or return via any remaining access.

Any tools received should be analyzed and tested in an isolated environment.

Negotiations do not halt the investigation

Communication with the attacker does not replace incident response.

At the same time, you must continue to:

  • localizing the threat;
  • searching for the initial vector;
  • revoking compromised sessions;
  • rotating secrets;
  • protecting backups;
  • evidence collection;
  • Cloud environment audit;
  • search for hardening mechanisms;
  • preparation for secure recovery.

Once the ransom is paid, the incident is not considered resolved. Systems still need to be cleaned or rebuilt, compromised access credentials need to be replaced, and the attack vectors need to be eliminated.

Payment may resolve one aspect of the crisis, but it does not eliminate the compromise or replace a secure recovery.

What Not to Do During an Active Incident

Shut down the entire infrastructure without a plan

This can destroy volatile evidence, complicate analysis, and halt unaffected processes. Isolation should be targeted or segmented and based on a risk assessment.

Reinstall systems before collecting data

Quick formatting erases traces of the attacker’s initial access, foothold, and movement.

Declaring victory after removing malware

A malicious file may be just one of the tools used. It is necessary to check identities, cloud sessions, tokens, remote access, email policies, SaaS applications, and management infrastructure.

Do not consider a password change to be complete containment

The attacker may still have active sessions, refresh tokens, OAuth permissions, or alternative MFA methods.

Use compromised communication channels

An attacker can read team messages, adapt tactics, and cover their tracks.

Contacting the extortionist directly

Unprepared communication can weaken your negotiating position, reveal the criticality of your systems, or create additional legal and operational risks.

Restore systems before the attack vector is closed

Otherwise, the recovery process risks becoming a repeat incident.

Assuming the absence of encryption means there is no data breach

Data theft can occur through legitimate cloud services and active user sessions without triggering typical ransomware events.

Trusting a backup without verification

A backup must be verified not only for readability but also for integrity, cleanliness, and the absence of any stored encryption mechanisms.

Publishing unconfirmed conclusions

Do not promise that there has been no data breach until it has been confirmed by an investigation.

Declaring the environment clean due to the absence of new alerts

The absence of events may not mean there is no attacker, but rather that visibility is insufficient.

How to measure readiness

The number of closed alerts says almost nothing about an organization’s ability to withstand a serious attack.

More useful metrics:

  • time to incident confirmation;
  • time to appoint an Incident Commander;
  • time to first containment;
  • time to revoke compromised sessions;
  • time to retrieve cloud logs;
  • time to verify a clean backup;
  • percentage of critical systems with sufficient telemetry;
  • completeness of the timeline;
  • time to resolve the initial attack vector;
  • percentage of measures implemented following a post-incident review.

It is important to measure not only speed but also the quality of solutions:

  • how many actions were carried out without an assigned owner;
  • how many changes were not logged;
  • what evidence was lost;
  • how many systems had to be restored repeatedly;
  • which assumptions from the IR plan turned out to be incorrect.

After an incident, what’s needed isn’t a formal “meeting held” document, but a concrete plan for changes that includes responsible parties, deadlines, and verification criteria.

Minimum organizational readiness by 2026

Prior to an incident, the company must have:

  • an approved IR plan;
  • a matrix of roles and responsibilities;
  • an off-network communication channel;
  • separate playbooks for key scenarios;
  • a map of critical systems and dependencies;
  • sufficient log retention period;
  • immutable and verifiable backups;
  • a procedure for preserving evidence;
  • a clean administrative environment;
  • contact information for an external DFIR team;
  • templates for internal and external communications;
  • procedures for addressing the extortionist’s demands;
  • regular tabletop and technical exercises.

It is not only the technical team that should be tested. Management, IT, security, business process owners, legal and communications functions, the insurer, key vendors, and an external DFIR partner should all participate in the exercises.

A plan that has never been tested under time constraints is an assumption, not a means of protection.

Response is about managing uncertainty

During an attack, it’s rarely possible to get all the answers right away.

A strong team does not wait for absolute certainty, nor does it act blindly. It separates facts from hypotheses, makes reversible decisions where possible, coordinates disruptive actions, preserves evidence, maintains a unified timeline, and simultaneously manages technical and business risks.

An incident cannot be made entirely predictable.

But the team’s work can be made predictable.

When an external response team is needed

PWN-ALL steps in for incidents where speed, evidence preservation, and controlled recovery are critical:

  • ransomware and extortion without encryption;
  • data theft and publication;
  • BEC and corporate email compromise;
  • account takeovers;
  • Microsoft 365 and Google Workspace compromises;
  • attacks on cloud infrastructure;
  • web application and server breaches;
  • incidents involving vendors and contractors.

The work may include emergency containment, digital forensics, determining the scope of the compromise, collecting and preserving evidence, investigating decryption options, verifying backups, providing technical support for controlled communications, secure recovery, preparing reports, and implementing follow-up security enhancements. For active incidents, PWN-ALL has a dedicated 24/7 response process in place.

In the event of an active incident:

Do not shut down affected systems, do not delete evidence, do not respond to the attacker on your own, and do not initiate a mass recovery until an initial assessment has been conducted.

The first priority is to limit the attacker’s actions without destroying the information needed for the investigation, decision-making, and the secure restoration of business operations.