From POC to Real Attack: Caught at Recon, Breach Prevented

The attacker spent 114 seconds working out where they had landed.

They never got further.

This is an account from our incident response desk.

A customer still in a proof of concept with us got an alert from CrowdStrike OverWatch: likely hostile activity inside the network.

A small alert.

A short burst.

Easy to file as noise.

We ran it down as a full incident anyway.

By the end we knew what happened, how the attacker got in, what they touched and what they did not, and which gaps a better prepared attempt would have used.

The customer has since closed every one of them.

*The customer and every identifier are generalized.

Hostnames, addresses, dates and some details are deliberately left out.

The sequence, the evidence and the lessons are real.*

The short version

What happened.

An unmanaged Windows machine appeared on the customer's remote access address range and spent 114 seconds probing three production servers.

It enumerated their services, then tried 27 network logons against two of them, using throwaway names like guest.

Every attempt failed.

Two days earlier, a port scan had come from the same range.

How it got in.

The customer's own firewall records later confirmed the session was unauthorized.

The way in was a vulnerability in the edge firewall.

The remote access range it landed on routed straight into production, with remote desktop and remote management ports answering.

Who caught it.

CrowdStrike OverWatch's human threat hunters spotted the burst and raised it within a few hours.

Our incident response team started a full remote investigation the same day.

What we found.

No logon succeeded, nothing executed and nothing persisted.

The attacker was caught at reconnaissance, before any foothold.

The servers' own Security logs had already overwritten the evidence, one of them in as little as 12 minutes, so the endpoint telemetry in Falcon was the only record left.

How it ended.

The customer fixed the firewall flaw, cut the route from the remote access range into production, and closed the rest of the list we handed over.

Gap popped.

Gap investigated.

Gap closed.

Gap popped: 114 seconds

The burst opened with a single connection to a terminal server.

Within about a minute the same source had reached three servers, a terminal server, a file server and an analytics server, probing file sharing, RPC, multicast DNS and SNMP.

Along the way it tried one anonymous logon, which the server refused.

A minute later came a run of network logons, now carrying the machine's own name, a Windows default of the DESKTOP-XXXXXXX kind.

Then nothing.

The whole burst lasted 114 seconds.

Each failure tells you which control held.

The account named 1 did not exist.

Guest was disabled.

The anonymous session was refused because null session restrictions were set correctly.

None of that is luck.

It is configuration somebody got right.

The machine itself appeared in no inventory.

It was not domain joined: on most attempts it offered its own name as the logon domain, which is what a workgroup machine does.

It was absent from the managed estate and unknown to the identity platform.

Two days earlier, three addresses from the same range had run a port scan against four servers, probing web, remote desktop, remote management and file sharing ports.

That scan left an unusual fingerprint, which we come back to in the hunting section.

The evidence links the two episodes by address range only, so we treat them as related, not proven to be the same actor.

Who raised it

OverWatch's hunters raised the activity within a few hours.

That matters more than it sounds.

The burst was short, every attempt failed, and the sensor had nothing to block, so no automated prevention fired.

A human hunter looked at the telemetry, decided it did not belong, and raised it.

That is the division of labor we want.

OverWatch's job is to see the 114 seconds.

Ours is to find out what they meant.

Gap investigated: everything, read only

The customer was in a proof of concept, not under contract for incident response.

We started anyway, the same day.

An alert does not check your contract status, and neither do we.

Everything ran remotely through Falcon Real Time Response.

Apart from staging collected evidence in a dedicated case folder on each host, we changed nothing.

Containment and remediation decisions stayed with the customer throughout.

• We searched the full 30 day telemetry window, about 169 million events, to place both indicators and build per host and per port baselines.
• We adjudicated every high and critical alert in the tenant individually, to rule related activity in or out.
• We collected 19 read only triage artifacts from each of the three servers, then full forensic triage packages totaling 2,804 files and 3.86 GB.
• We captured memory from the three processes the source touched or that were most exposed, and checked every executable memory region for injected code.
• We hashed every artifact into a chain of custody, 112 items, all verified at close.

One memory finding shows why that depth matters.

In the whole incident, exactly one packet went back toward the attacker: a single SNMP reply from an analytics service on one server.

We recovered that exchange from the process memory 21 hours later, as a structured record that included the attacker's own source port.

The service could have disclosed at most eleven read only system values.

Small, bounded, and now known rather than guessed.

We also declined one collection.

A memory capture of the credential store was proposed and turned down on safety grounds, because the risk to a production server outweighed what it could add.

And we tested our own story.

We put the findings through 36 independent review agents in three passes, each tasked with disproving them rather than confirming them.

Several working assumptions did not survive.

• A server described to us as a finance file server held operational records and no finance data at all.
• A legacy file sharing protocol that looked enabled was disabled, and the logs that suggested otherwise were recording refused attempts.
• A domain controller first pulled into scope as a victim had only made outbound connections weeks earlier, to an address since reassigned.

Every correction went into the report rather than the bin.

It is the same discipline behind our agentic SOC work: a finding has to survive someone trying to break it before anyone acts on it.

The logs had already forgotten

Here is the finding that should worry every Windows shop.

By the time anyone looked, the servers' own Security logs no longer held the incident.

Nobody deleted them.

They were full.

On one server the Security log held 12 minutes of history.

The other two held 4 and 8 hours.

Windows Filtering Platform connection auditing was consuming between 88.7 and 100 percent of each log, and the failed logon records an investigation depends on were down to between zero and three per host.

The reconnaissance had rolled off every host before the investigation began.

The only surviving record was Falcon's 30 day endpoint telemetry, held off the host.

Without it there would have been nothing to investigate.

The fix is cheap.

Turn off filtering platform connection auditing unless you genuinely use it, raise the Security log above its 20 MB default, and forward Security events off the host.

On the 12 minute server, the first change alone would have recovered almost the entire log.

Generalized server labels. Filtering platform audit events consumed between 88.7 and 100 percent of each log.

How a firewall flaw became direct access

Endpoint telemetry can tell you what a machine did.

It cannot tell you who was behind it.

So we told the customer exactly which record would decide it: the authentication log on their remote access gateway, which they held and we did not.

They pulled it.

The session was unauthorized.

And the way in was a vulnerability in their own edge firewall.

That is the gap behind the gap.

The firewall flaw put a stranger's machine on the remote access address range.

What made it dangerous was what that range could reach.

It routed straight into production server subnets across two cloud accounts, and remote desktop and remote management ports answered from it.

The attacker did not need to break anything else to stand one hop from production.

The entry was the firewall. The reach came from a remote access range that could talk straight to production. Generalized, illustrative.

The investigation surfaced more gaps of the same shape, the ones a better prepared attempt would have used.

• Two stale generic local accounts sat enabled and untouched for years on an end of support server, and this attempt missed them only because it guessed guest and 1.
• No account lockout was in place, so 27 failures in 114 seconds triggered nothing.
• SMB signing was neither required nor enabled, which leaves relay exposure.
• Network Level Authentication was off for remote desktop on two servers.
• An SNMP responder answered any address that could reach it.

One more finding had nothing to do with this incident, and it was a bigger standing exposure than the incident itself.

A customer facing web portal was reachable from the internet and could not attribute a single request to a source.

Address translation at the gateway stamped every request with the same internal address.

More than ten thousand requests arrived in two weeks, most of them probes for files like /.env and /.git/config, and not one could be traced to its source.

Nobody asked us to look for it.

We found it because we looked at everything the attacker could reach.

Gap closed

We handed over a prioritized list with the firewall log at the top, because everything else depended on it.

The customer worked through it.

The firewall flaw is fixed.

The route from the remote access range into production is cut.

The rest of the list is closed.

The attacker spent 114 seconds finding out where they were.

Whoever comes through that door next will find it shut.

Hunt for this in your own estate

Two hunts from this case travel to any Falcon tenant.

They are starting shapes in CrowdStrike Query Language, not finished detections.

Field names can vary by environment, so confirm them against your own data before you trust a result.

A hunt that has never returned a hit has proven nothing by returning nothing.

1. Source port equals destination port plus 40000.

The earlier port scan set every source port to 40000 plus the destination port: 40080 for 80, 40443 for 443, 40389 for 3389.

Across more than a million inbound connection records in 30 days, only those twelve connections and one unrelated coincidence matched.

That is specific enough to hunt on.

#repo=base_sensor #event_simpleName=NetworkReceiveAcceptIP4
| test(RemotePort - LocalPort == 40000)
| groupBy([RemoteAddressIP4, ComputerName, LocalPort], function=count())

2. A machine that is not on your domain, trying to log on to your servers.

A workgroup machine offers its own name as the logon domain.

On a domain joined estate, failed network logons where the domain equals the client's own computer name deserve a look.

Expect some legitimate noise from appliances and non domain devices, and know every one of them.

#repo=base_sensor #event_simpleName=UserLogonFailed2 LogonType=3
| test(LogonDomain == ClientComputerName)
| groupBy([ClientComputerName, RemoteAddressIP4, ComputerName], function=count())

These are read only hunts.

A hit is the start of an investigation, not a verdict.

Why OverWatch plus an IR team works

This case closed well because three things happened in order, and fast.

OverWatch's hunters saw a short burst that automated prevention had no reason to stop.

Our team turned it, the same day, into evidence: what happened, what did not, how the attacker got in and what else was open.

The customer acted on it and closed the gaps.

Remove any one of those and the story changes.

Without the hunters, 114 seconds of failed logons is easy to miss.

Without the investigation, an alert stays an alert and the firewall flaw stays open.

Without the follow through, the next attempt comes back better prepared.

We are a CrowdStrike Elite Partner, and this is the part of the partnership we value most: OverWatch's eyes, and a team that runs every lead to the ground.

The customer was not even under contract yet.

That did not change how we worked.

If an alert landed in your environment tonight, who would run it down, and how much of the evidence would still be there?

Talk to our incident response team.

Learn more about QMasters and our CrowdStrike partnership.