Preserve it before you rebuild

There is a window, usually about an hour wide, between finding out and the first irreversible act. Almost nobody spends it deliberately.

What happens instead is that four things get done, in some order, by people trying to help. The machine is powered off. A backup is restored. Something is re-imaged. Somebody deletes the obviously malicious file. Every one of those is a reasonable instinct, and every one of them destroys evidence — in the first three cases, a whole category of it that no technique recovers afterwards at any price.

This page is about what each one takes with it, and about a preservation sequence you can work through with what you already have — no kit, no specialist, no waiting.

The four acts, and what each one costs

1. Powering the machine off

Of the four, this is the one whose cost is invisible: the machine looks fine afterwards, and what it lost is gone without leaving a gap where it used to be.

A running system holds a large amount of state that exists nowhere else: the list of processes actually executing, the network connections actually open and what they are connected to, code that was injected into a legitimate process and never written to disk, credentials cached in cleartext by software that needed them, and — in a ransomware event — sometimes an encryption key still held by a process that has not finished.

None of that is on the disk. Powering off does not "freeze" it; it deletes it. A machine that has been shut down and restarted cannot be asked what was running on it, because nothing that was running on it still exists.

The instinct behind it is right: stop it talking to the attacker. The action that achieves the same thing without the cost is isolation — pull the cable, disable the interface, move the port to a quarantine VLAN, revoke the security group. The attacker loses access. You keep the state.

2. Restoring from backup

Restoring overwrites the compromised system, which at that moment is the only complete record of the compromise.

It also does something less obvious. A backup taken after the intrusion began contains the intrusion. Restoring it puts the same way in, the same web shell and the same account back into production, and the second incident that follows is usually attributed to a new attack rather than to the restore.

The useful version of the instinct is: identify a restore point that predates the earliest evidence of intrusion. That requires knowing when the intrusion started, which requires the logs, which is the next section. Until then, freeze the backup schedule and change nothing — a suspended job can be resumed, an overwritten retention cannot be un-overwritten.

3. Re-imaging

Re-imaging is powering off plus deleting the disk. It ends the investigation completely for that host, and it is typically done by somebody who was asked to "get it back up" and who did not know anyone would want the machine afterwards.

This is a communication failure more than a technical one. It is worth saying out loud, in the first ten minutes, to everyone with the access to do it: nothing is re-imaged, rebuilt or wiped until one named person says so. Name the person in the same sentence.

4. "Just cleaning it"

Deleting the web shell, removing the unknown administrator account, killing the suspicious scheduled task.

What is lost here is the timeline. A file's creation time is what dates the intrusion; an account's creation event is what places it; a scheduled task's registration is what links it to the session that created it. Delete the artefact and you delete the timestamp, and the question "when did this start" loses its answer — which is the question a regulator, an insurer, a customer or your own board will ask.

Record it instead. Screenshot it, note the full path, note the timestamps as displayed, note who found it and when. Then leave it exactly where it is until the system is going to be rebuilt anyway.

What you can preserve without a specialist

In order. None of this needs a forensics background, and all of it can be done with what a normal estate already has.

Isolate at the network, not at the power. Covered above, and it is first because everything else depends on the machine still existing in the state you found it.

Freeze backup rotation and mark the current retention as hold. Backup schedules run on timers. A rotation that fires during the incident meeting can overwrite the pre-incident copy while nobody is watching, and a suspended job can always be resumed.

Stop deleting anything. Including the obviously malicious. Including temporary files. Including the attacker's own tooling, which is evidence in its own right.

Capture memory if anyone on hand can, before anything else technical. If you have someone who can run a memory acquisition tool, this is the highest-value thing available in the first hour, and its value decays to zero the moment the host reboots. If you have nobody who can, that is fine — isolate and leave it running. A live machine can still be captured later. A powered-off one cannot.

Write down the volatile basics even if you cannot capture memory. The running process list, the open network connections, the logged-on users, the current time on the host and how it compares to a known-good clock. A screenshot of each is worth far more than nothing, and takes two minutes.

Collect the logs before they roll. This one has its own clock, set by your retention settings rather than by anything you can extend afterwards. The window that matters is the one covering the start of the intrusion, which may be months before you found out.

Investigate with credentials the attacker has not seen. Reusing the administrator account that was already logged in tells them you are looking, and mixes your own activity into the record you are trying to read.

Log everything you do, as you do it. Time, person, action. Started at hour one this is a timeline. Assembled at hour six from memory it is a reconstruction, and the difference shows.

The logs are a legal obligation before they are an investigative one

Direction (iv) of the CERT-In Directions of 28 April 2022:

"All service providers, intermediaries, data centres, body corporate and Government organisations shall mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction. These should be provided to CERT-In along with reporting of any incident or when ordered / directed by CERT-In."

Three things sit in that mandatory limb: the logs are enabled across all ICT systems, they are held securely for a rolling 180 days, and they are maintained within the Indian jurisdiction. Asked specifically about foreign service providers and the foreign part of financial transactions, CERT-In answered at FAQ Q 36 that "Any service provider offering services to the users in the country needs to enable and maintain logs and records of financial transactions in Indian jurisdiction."

Which logs? CERT-In answers that itself, at FAQ Q 37: "The logs that should be maintained depend on the sector that the organisation is in, such as Firewall logs, Intrusion Prevention Systems logs, SIEM logs, web / database/ mail / FTP / Proxy server logs, Event logs of critical systems, Application logs, ATM switch logs, SSH logs, VPN logs etc." The same answer adds that "this list of logs is not exhaustive but has been mentioned to provide flavour of logs to be maintained by the relevant teams" — so a system class missing from the list settles nothing, and the sector you are in is part of the answer.

And one sentence in Q 37 that does more work than the rest of it put together:

"From the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded."

Direction (iv) requires logs of all ICT systems, and CERT-In’s answer says to record the unsuccessful events too. They are frequently the only evidence that dates the beginning of an intrusion — a successful login tells you the attacker got in, and the failures before it tell you when they started trying, from where, and against which accounts. Where only successes are recorded, a compromise can usually be established and its starting point often cannot.

Who can ask for them, and on what terms. Rule 14(1) of the CERT-In Rules, 2013 provides that any officer of CERT-In not below the rank of Deputy Secretary to the Government of India may seek information from service providers, intermediaries, data centres, body corporate and any other person for carrying out the functions provided in sub-section (4) of section 70B of the Act. Rule 14(3) adds that the information sought is to be submitted "within the duration and in the format provided alongwith the communication sent for seeking the information" — a requisition arrives with its own deadline and its own format, both set in the communication that seeks the information. FAQ Q 38 applies the same rank to logs by name.

The question to ask today, not during an incident: for each system class in Q 37's list, how many days do you actually hold, where is it stored, and who can produce it, in what format, how fast? On shared hosting or a managed platform the honest answer is often a number set by somebody else and shorter than you would like. That is a fact worth knowing before it becomes the reason a question has no answer.

Without synchronised clocks there is no sequence

Two jobs here, and they are different. During an incident: record the time zone against every entry in your log, and for each affected system note how its clock compares to a known-good source — a recorded offset is workable evidence. Afterwards, and it takes minutes: put the estate on the servers named below, so the next timeline assembles itself.

Direction (i) requires all service providers, intermediaries, data centres, body corporate and Government organisations to "connect to the Network Time Protocol (NTP) Server of National Informatics Centre (NIC) or National Physical Laboratory (NPL) or with NTP servers traceable to these NTP servers, for synchronisation of all their ICT systems clocks". Where an estate spans multiple geographies it "may also use accurate and standard time source other than NPL and NIC, however it is to be ensured that their time source shall not deviate from NPL and NIC".

CERT-In gives the reason in its own words, at FAQ Q 39:

"A typical cyber incident involves multiple computer systems within as well as across entities. Without an accurate time stamp it is extremely challenging to re-create accurate sequence of events thus causing serious hindrance while handling cyber incidents."

The same answer notes that security technologies "rely heavily on specific patterns and correlation rules that are often based on time parameter", so drifting clocks degrade detection as well as investigation.

What this means in practice is simple and unforgiving. An investigation is the assembly of records from a firewall, a web server, an application, a directory service and an endpoint into one ordered story. If those five sources disagree about what time it was, the story cannot be ordered, and the disagreement is discovered at the point when somebody tries to answer "what happened first".

FAQ Q 43 gives the current server names: samay1.nic.in, samay2.nic.in and time.nplindia.org. CERT-In adds a practical point at FAQ Q 40: "The time zone information shall also be recorded along-with time to facilitate accurate conversion at the time of need."

It is a configuration change measured in minutes, and where it is already in place the records line up on their own.

What chain of custody actually is

A discipline about handling: what was collected, when, by whom, how it was stored, and who has touched it since — recorded contemporaneously, so that the record can be examined later by somebody who was not there. Security Brigade captures forensic images following chain-of-custody protocols, and builds timelines from log correlation and attack path mapping.

The discipline operates on what exists. It is the reason this page is about the first hour rather than about the investigation: a protocol applied to a re-imaged host documents an absence very rigorously.

The short version

If you are reading this mid-incident and have one minute:

• Do not power it off. Disconnect it from the network and leave it running.
• Do not restore. Freeze the backup schedule and touch nothing.
• Do not re-image. Say so out loud, and name who can authorise it.
• Do not delete. Screenshot, record the path and the timestamps, leave it in place.
• Pull the logs now, before the retention window rolls past the start of the intrusion.
• Write down what you do, as you do it, with times.

The six-hour CERT-In filing runs on its own clock, in parallel with all of this. Direction (ii) puts it at six hours from noticing, or from being brought to notice — give it to somebody who is not doing the preservation work.