How they got in — and why your logs decide whether you can answer

The site is back up, or nearly. The board has asked the only question it was ever going to ask, and it is not how bad was it. It is how did they get in.

There is a version of this question that is answerable in a few days and a version that is never answerable at all, and which one you have was decided before the incident, by log retention settings — and where your estate sits on shared hosting or a managed platform, those settings belong to somebody else.

This page is about the entry classes worth working through, the record that confirms each, and the dependency underneath all of them.

The dependency, first, because it is the one that runs out

Every finding below is confirmed from a log. Logs have retention windows. The window that matters is not the one covering the day you found out — it is the one covering the day they got in, which is frequently weeks or months earlier.

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

"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."

A hundred and eighty rolling days is a long window, and it is set at that length for exactly this reason. What decides your investigation is not the obligation but what your estate actually holds — and on shared hosting that is set by the host, not by you, so the first call on the morning after is often to a support queue rather than to an engineer.

Ask, today, in writing, and record the answer with the time you asked: for each system, how many days of logs exist, where are they, in what format, and how fast can they be produced?

CERT-In's own answer at FAQ Q 37 is a useful checklist to ask against: "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".

And the sentence a root-cause investigation usually turns on:

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

A successful login tells you somebody got in. The failures before it tell you when they started trying, from where, and against which accounts — which is what dates the intrusion. Where only successes are recorded, that a compromise happened can usually be established and when it began often cannot — and "when it began" is what determines the scope of everything else.

Without synchronised clocks there is no order of events

The second dependency, and the one that is invisible until you need it.

An entry-point finding is built by putting records from several systems into one sequence — the web server, the application, the firewall, the directory service, the endpoint. If those systems disagree about what time it is, they cannot be put in order, and the disagreement is discovered at the exact moment somebody asks what happened first.

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".

CERT-In's reason, at FAQ Q 39: "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 entry classes, and what confirms each

Work these in parallel, not in order — several of them leave traces in the same places, and the point is to find the earliest confirmed foothold rather than the first one you notice.

An out-of-date component

Content management systems, plugins, themes, libraries, and the application framework underneath them. Publicly known vulnerabilities in widely deployed components are found by automated scanning at scale, so the interval between a disclosure and opportunistic exploitation of unpatched instances is short.

Confirmed by: web server access logs showing requests to the vulnerable path, usually clustered and usually preceded by probing that failed; the component's own version at the time, from the deployment record rather than from what is installed now; file modification times on the component's directory.

What makes it hard later: the first thing done during recovery is often an update, which changes the version, the file dates, and sometimes the log path.

A credential that worked

Reused, phished, guessed, or lifted from somewhere else entirely — a developer's machine, a repository, a config file, a third party.

Confirmed by: authentication logs, and specifically the failures around the success. A single successful admin login from an unfamiliar network with no failures before it looks very different from one at the end of two thousand attempts, and the two mean different things about how the credential was obtained.

What makes it hard later: password resets during recovery, which are necessary and which also close the window on testing whether the credential worked elsewhere.

An exposed administrative interface

Admin panels, database managers, file managers, remote desktop, SSH, or a staging environment reachable from the internet — often deployed deliberately, temporarily, some time ago, by somebody who has left.

Confirmed by: the firewall or security group configuration as it was, access logs on the interface itself, and — frequently the most informative record — the change history showing when it was opened and by whom.

What makes it hard later: it gets closed during containment, correctly, and often without anyone recording what the rule was beforehand.

A file upload that executed

Anywhere the application accepts a file and stores it somewhere that can run code. The result is a web shell: a small script giving command execution through an ordinary-looking web request.

Confirmed by: the file itself, its creation time, and the access log entries that reach it — a script that receives POST requests from one or two addresses and nothing else is not part of your application. The upload request that placed it is usually in the same log, earlier.

What makes it hard later: deleting the shell. It is the most obviously malicious thing on the host and therefore the first thing removed, and its creation time is what dates the whole intrusion.

A third party with access

A plugin's update channel, an integration's API key, a managed service provider's remote access, an agency that still holds credentials from a project two years ago.

Confirmed by: logs of the integration's activity, API key usage records, and the access list itself. This class is hard to see because the activity is authorised and looks like normal operation.

What makes it hard later: nothing in particular — it is hard from the start, which is why it is worth checking explicitly rather than by elimination.

The infrastructure underneath

The host, the container platform, the cloud account, the CI/CD pipeline. Annexure I item (xviii) names attacks affecting cloud computing systems as a reportable type in its own right.

Confirmed by: control-plane logs — cloud audit trails, orchestration logs, pipeline run history. These are the records most often not collected at all, and they are the ones that answer whether the compromise was of your application or of the account that deploys it.

The classes are what you file under, too

The entry class is not only an engineering finding. Annexure I names the reportable types, and several of these map onto it directly: item (iii) unauthorised access of IT systems/data, item (iv) "Defacement of website or intrusion into a website and unauthorised changes such as inserting malicious code, links to external websites etc.", item (x) attacks on application such as E-Governance and E-Commerce, and item (xviii) cloud.

More than one can describe a single incident, and where they do, all of them are ticked. The six-hour filing is not delayed for this analysis — it is made from what is known at the time, and the entry-point finding follows.

Who can ask for the logs

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". FAQ Q 38 applies the same rank to logs by name.

A requisition therefore arrives with its own deadline and its own format. Whether it can be met is decided by the retention question at the top of this page, months earlier.

When the honest answer is "undetermined"

Sometimes the logs are gone, or were never kept, and no amount of work will produce an entry point.

Say so, and say what was excluded. "Root cause undetermined; the following were tested and ruled out, on this evidence; the following could not be tested because logs for that period were not retained" is a finding. It states what is known, what was ruled out and on what evidence, and it identifies exactly what to fix so the next one is answerable.

A plausible-sounding guess is not defensible, and it has a specific cost: it directs the remediation at the wrong thing.

Two things not to do at this point. Do not adopt somebody else's numbers about how compromises usually begin — a national or global base rate is not evidence about your estate, and using one to fill a gap in your own investigation is guessing with a citation attached. And do not attribute the intrusion to a named group or campaign because the tooling looked familiar. Where the evidence supports attribution it is worth having; where it does not, the attribution is decoration, and it survives into the board pack long after the caveat has been dropped.

Our own published language is deliberately conditional on this point: timeline reconstruction, malware analysis, log correlation and attack path mapping, with "threat actor attribution where possible".

What to do with the answer

The entry-point finding is what makes the rest of the recovery specific rather than generic.

• It names what to close, as opposed to patching everything and hoping.
• It bounds what was reachable, which is what determines the scope of what was accessed.
• It dates the intrusion, which is what makes a restore point safe or unsafe to use.
• It tells you which logs you needed and did not have — the single most valuable output, because it is the one that makes the next incident answerable.

If the answer is that the logs were not there, the remediation is not only the vulnerability. It is the retention.