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. Which one you have was decided before the incident, by log retention settings. Where your estate sits on shared hosting or a managed platform, those settings belong to somebody else.

This page covers the entry classes to work through, the record that confirms each, and the dependency underneath all of them.

Start with the dependency that runs out

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

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 what your estate actually holds. On shared hosting the host sets that, not you, so the first call on the morning after is often to a support queue.

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, and that 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. Several of them leave traces in the same places, and the point is to find the earliest confirmed foothold, not 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, taken from the deployment record and not 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. These are 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 the change history showing when it was opened and by whom, which is frequently the most informative record.

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, so check it explicitly and do not leave it to 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

Annexure I names the reportable types, and several of them map onto the entry class 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.

What to do with the answer

The entry-point finding is what turns a generic recovery into a specific one.

• It names what to close.
• 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. That is the single most valuable output, because it is what 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.