skip to content

An analyst browsed a live C2 panel from the office network and the cluster went dark within the hour - what have you lost?

level: seniorimportance: should knowfreq 44%

answer

  1. who owns that address range
  2. three losses, not one
  3. surprise is spent, not lent
  4. rotation is evidence, not proof
  5. pivot passively: certificates, registrant, hosting

basics

~20 s

You have likely lost quiet observation of that infrastructure and told the operator which company is investigating him, because corporate address space is attributable. Rotation timed to the visit is strong evidence he noticed, not proof.

solid answer

~50 s

Three losses. First, the tracked cluster is dead: the addresses and domains you were pivoting on stop producing anything, and any hunt built on them expires. Second, and worse, the visit is attributable - registry records map the office netblock to your organisation, so a watchful operator now knows *who* is looking, which invites destruction of evidence, use of backup persistence, or a jump straight to his objective. Third, the initiative moved to him; his clock now governs your response. What you do next is passive: preserve everything already collected before it ages out, and re-find the infrastructure through certificate transparency, registrant and nameserver reuse, and hosting patterns rather than by probing harder. Then tell the incident lead plainly that the adversary knows, because that changes their decisions, and stand up a non-attributable research path before anyone touches anything again. Be honest in the writeup: rotation an hour later is compelling, not certain.

code

text · 3 lines
text
203.0.113.77 - - [14/Mar/2026:09:41:22 +0000] "GET / HTTP/1.1" 200 1671 "-" "curl/8.5.0"
203.0.113.77 - - [14/Mar/2026:09:41:26 +0000] "GET /admin HTTP/1.1" 302 199 "-" "curl/8.5.0"
...

go deeper

for a junior

Know that corporate address space identifies your employer and that touching adversary infrastructure from it is a serious mistake. Be ready to say who you would tell immediately.

for a middle

Explain what an access log entry discloses, why registry records make the address attributable, and which pivots stay passive when you need to re-find the infrastructure.

for a senior

Show the whole handling: name the three losses, hedge the rotation claim correctly, brief the incident lead because their planning assumption has changed, and rebuild the picture from certificates, registrant history and your own estate rather than by probing.

for a principal

Own the systemic cause. Decide whether the team gets a funded non-attributable research path, and write the standing rule that governs live adversary infrastructure until it exists.

## What the visit actually disclosed An HTTP request writes a source address, a timestamp, a request path and often a distinctive user agent into a log the operator controls. Internet registry records tie a netblock to an autonomous system and a named organisation, so the source address is not anonymous - it is a business card. If your office egress is a small, well-labelled range, the operator does not learn *that someone* is investigating him; he learns which company, and by inference which of his intrusions is now known. That inference is the expensive part. A curious operator can then look up the organisation, work out which of his implants is deployed there, and act. ```text 203.0.113.77 - - [14/Mar/2026:09:41:22 +0000] "GET / HTTP/1.1" 200 1671 "-" "curl/8.5.0" 203.0.113.77 - - [14/Mar/2026:09:41:26 +0000] "GET /admin HTTP/1.1" 302 199 "-" "curl/8.5.0" ... ``` Two requests, four seconds apart, from one address, one of them straight to an administrative path. Nothing about that looks like a passing crawler. ## The three losses, separated **Observation.** You were watching infrastructure that was producing something - resolutions, certificates, banners, connections from your own estate. Once it rotates, that stream stops. Indicators you extracted stay in the case file but they age into worthlessness within days, and detections written narrowly against those addresses will now be silent for reasons that have nothing to do with the adversary being gone. **Surprise.** Before the visit you knew something he did not know you knew. That asymmetry is the only advantage a defender ever holds during an intrusion, and it is spent, not lent. **Initiative.** He now decides the tempo. An operator who believes he is discovered may destroy artefacts on the hosts he holds, activate persistence you have not found, or - in a theft or extortion operation - stop being patient and finish. Communicating that to the incident lead is not optional: the response plan they built on the assumption of a quiet adversary is no longer the plan they have. ## What you must not conclude The direction of the claim matters. Rotation an hour after the visit is *evidence* he noticed, not proof. Operators rotate infrastructure on schedules, hosting providers suspend accounts, domains lapse, and other victims report the same host on the same day. Write it as a judgement with its reasoning visible - correlation in time, plus a request to an administrative path from an attributable address - rather than as a fact. Overstating it in a report is how a team learns the wrong lesson and how a leader loses confidence in the next report. ## Re-finding the infrastructure without touching anything The pivots that survive a burn are the passive ones, because they read what other parties recorded: - **Certificate transparency.** Adversary infrastructure is frequently provisioned the same way each time. Certificates issued by the same authority, with the same subject shape or naming convention, in a similar cadence, surface siblings and successors. Remember what a CT entry proves: a certificate with that name was issued and logged, not that a host is serving it. - **Registrant and nameserver reuse.** Historic registration records, nameserver sets and registrar choices tie new names back to old ones even when contact details are redacted. - **Hosting and address-space patterns.** Historic scan records held by a scanning service - read, never re-run on demand - show which addresses previously answered with the same characteristics. - **Your own estate.** Everything the intruder's implant did inside your network is yours to search and reveals nothing to him. It is also the only surface where his *behaviour*, rather than his infrastructure, is recorded. What does not work is probing harder. Scanning the provider's range or hammering the old address to see whether it still answers confirms the visit was not a stray crawler and closes the door you were hoping was ajar. ## Preventing the repeat The cause here is capability, not carelessness: an analyst with a legitimate question and only one network path took it. The fix is a research path that is not attributable to the company - a separate egress, a separate tenant, separate devices - plus a written rule that until that path exists, live adversary infrastructure is read passively and never touched. That is a decision with a budget attached, and it belongs to whoever owns the team, not to the analyst at 03:00 with a domain in front of them.

  • How would you word the rotation in the report?
    As a judgement with its basis shown: the cluster stopped resolving within an hour of an attributable request to an administrative path, which makes operator awareness the most likely explanation, while scheduled rotation and provider suspension remain possible. Stating it as proven is the failure - it survives exactly until someone asks how you know.
  • The analyst used a commercial VPN. Does that make the visit unattributable?
    Not reliably. It removes the corporate netblock, but the timing still correlates with your discovery, common VPN exit ranges are widely recognised and often blocked or flagged, and the browser fingerprint and request pattern remain. A VPN is a partial measure, not a research path - and it is billed to someone.
  • What is the first thing you tell the incident lead?
    That the adversary very likely knows he is discovered, so their planning assumption of a quiet intruder no longer holds - artefacts may be destroyed, unfound persistence may be used, and the operation may accelerate. The decision of what to do about that is theirs; your job is to make sure they are not still working from the old assumption.

saying these in an interview costs you the question

  • Says nothing was lost because the indicators are in the case file
  • Treats rotation as proof the operator saw the request
  • Proposes scanning the provider's range to re-find the cluster
  • Assumes a commercial VPN makes the visit unattributable
  • Keeps the burn inside the intel team instead of telling the incident lead

context

resolving links…