# What Happens Before the SOC Can Respond?

The PaperCut campaign is a reason to examine exposure, privileged access, and rehearsed containment. Detection cannot carry the entire burden of defending against faster exploitation.

Published: 2026-09-14

An alert can arrive quickly and still arrive after the first consequential action.

That is the question I want an incident-response exercise to answer: what can an attacker reach while the alert is being collected, routed, read, and acted on?

## Read the campaign clock carefully

GreyNoise's September 9 investigation reports at least 440 compromised PaperCut instances across 395 identified organizations in 48 countries. The campaign used a DeepSeek model with the Codex harness; that does not mean it used OpenAI's models.

The reported milestones were under four hours from an empty workspace to the first real-victim remote code execution, then about two more hours to the first domain administrator access. Once the campaign launched at scale, at least eleven organizations were compromised within 26 seconds. GreyNoise observed domain administrator access at twelve organizations, not all 395. The actor's eventual objective remained unresolved. [Read GreyNoise's investigation](https://www.greynoise.io/blog/ai-orchestrated-campaign-against-papercut-ng-mf).

Those measurements describe different stages. A 26-second campaign window is not an end-to-end intrusion time for every victim. It also cannot tell us how much faster the same operator would have been than a comparable campaign without AI.

The underlying vulnerabilities, CVE-2026-81578 and CVE-2026-82078, are covered in [PaperCut's urgent advisory](https://www.papercut.com/kb/Main/security-bulletin-27-aug-2026-urgent-security-advisory/). Use the vendor's current affected-version and remediation guidance rather than treating a blog post as a patch reference.

## Response time is only one part of the design

My reading is that this campaign makes an existing operational weakness harder to tolerate: services can remain exposed while remediation waits for ownership, approval, or a maintenance window.

A SOC cannot compensate for every one of those delays. It also should not be expected to decide whether an unfamiliar print server is safe to disconnect for the first time during an intrusion.

I would separate the work into three questions:

1. Why can an untrusted client reach this service?
2. If the service is compromised, what authority does it expose?
3. Which containment actions can responders execute without discovering the dependencies from scratch?

The model used by an attacker does not change who owns those answers.

## Find the exposed service and its owner

For an internet-facing management application, I want an inventory record that connects the externally reachable endpoint to a host, installed version, accountable owner, and business dependency.

An internal asset record is not proof that the service is unreachable from outside. Conversely, an external scanner result may not identify the team responsible for the underlying application. Both views need reconciliation.

When an urgent advisory applies, the owner needs a documented choice: remediate, restrict access using an appropriate supported control, or take the service out of exposure while work proceeds. Any temporary exception needs an expiry and a named approver.

I would measure the time from an actionable advisory to confirmed exposure reduction. A closed patch ticket is useful, but the acceptance test should establish that the affected instance was actually updated or made unreachable through the vulnerable path.

This is not a demand to predict a CVE before disclosure. It is a demand to know which service you operate and how to change its exposure when a relevant warning arrives.

## Examine what a service compromise buys

For each management server, review its service identity, administrative sessions, stored credentials, and permitted network connections. The name of the application is a poor proxy for its importance. A modest business function can sit behind an unnecessarily powerful identity.

My review would ask:

- Does the service require its current privilege level under the vendor's supported deployment model?
- Do privileged administrators sign into the host in ways that expose reusable credentials?
- Can it reach identity infrastructure or management interfaces unrelated to its job?
- Are application credentials shared with other services?
- Can its identity create accounts, change groups, or access backups?

Do not blindly change service privileges and break a supported installation. Where permissions cannot safely be reduced, record the reason and strengthen the surrounding isolation and administrative access controls.

The desired result is specific: compromising one application should not automatically provide a practical path to administer the rest of the environment.

## Build detections around evidence you own

In [Seventeen Thousand Actions, Five Days, One Detection Contract](/blog/seventeen-thousand-actions-one-detection-contract/), I focused on reconstructing activity across several evidence sources. The operational extension is to decide which of those joins can support a timely response.

For this class of exposed-service incident, I would start with host execution, application access, identity changes, and outbound network activity. The following are candidate detection requirements to validate locally, not ready-made campaign signatures.

| Candidate signal | Evidence required | Response question |
| --- | --- | --- |
| Unexpected execution beneath the application service | Process ancestry, command details, service baseline | Can the host be isolated without losing the evidence needed for investigation? |
| Sensitive credential-store access by an unexpected process | Relevant endpoint telemetry and approved-access baseline | Which identities and secrets require immediate review? |
| New privileged membership associated with the affected host or identity | Directory auditing joined to host and authentication records | Can the change be reversed and the initiating access contained? |
| Unusual outbound transfer following suspicious execution | Egress records joined to host activity | Can the destination or route be blocked while scope is established? |

Test these with approved, harmless simulations. Check collection delay, false positives, missing fields, and the actual responder workflow. A detection that needs process ancestry will not work if the sensor never collected it.

A normal enterprise SOC cannot correlate compromises across unrelated organizations without a service or intelligence partner supplying that visibility. Nor should it depend on finding an attacker's orchestration files on its own hosts. Those may exist entirely on attacker-controlled infrastructure.

## Rehearse containment before it is urgent

I would choose one representative management service and run a tabletop followed by a controlled technical exercise.

Assume the service has been compromised and a credential may have left the host. Ask the team to identify the owner, restrict access, isolate the affected system, preserve appropriate evidence, and contain the relevant identities.

Record separate times for event collection, alert delivery, responder acknowledgment, and effective containment. Also record how long it takes to establish which credentials were accessible. A single mean-time-to-detect number conceals those dependencies.

Pre-authorized actions should have narrow conditions and an understood business impact. Host isolation can be appropriate; automatically disabling a widely shared service account may cause a different outage. That tradeoff belongs in the exercise, with the people who own the dependency.

## Rotation needs a clean place to land

Patching a vulnerable application does not revoke a stolen credential. Changing a password also does not necessarily remove persistence or terminate every existing session.

The response plan should coordinate host containment, investigation, credential replacement, session handling, and recovery. Replacement secrets should be issued from a trusted administrative environment and delivered to recovered systems. Otherwise an attacker with continuing access may obtain the replacements too.

If the investigation indicates broader identity compromise, escalate to the organization's identity-recovery procedures. Do not treat a potentially domain-wide event as a routine application password reset.

The companion post, [Your Evaluation Sandbox Holds Production Authority](/blog/your-evaluation-sandbox-holds-production-authority/), applies the same credential-lifecycle question to agent testing infrastructure. Both environments need a demonstrated answer to “does the old access still work?”

## Start with one service

The useful action this week is small enough to complete: select one externally reachable management application and trace the path from its owner to its privileges, detections, and containment procedure.

Find the step where the team has to stop and ask somebody who is not in the room. Fix that dependency and repeat the exercise.

Faster exploitation gives defenders less room for those unresolved decisions. The work is to make fewer of them for the first time during an incident.