The Uninvited Guest:
What Happens Before the Attack Becomes Visible

Your front door is locked, the cameras are working and the people inside are going about their day. A ransomware intrusion can create the same deceptive calm: systems respond, staff can log in and the morning report shows no disruption, even though an attacker has already gained access.

Before files are encrypted or a service stops, the intruder may be identifying privileged accounts, exploring server connections, collecting sensitive information or locating the systems your organisation would need for recovery. The visible crisis can arrive after some of the damage has already been done.

For a board, CIO or CISO, the question is whether security teams can recognise that preparation while the business still appears to be operating normally. Waiting for an outage means waiting for a later stage of the incident.

Imagine an uninvited guest staying in your house for 45 days while you continue your normal routine. They do not damage the furniture or announce their presence. They learn which doors you use, where you keep the keys, which rooms contain valuables and how you would leave in an emergency.

The picture makes a hidden intrusion easier to understand, but the guest does not need a long stay to become dangerous. An attacker using a stolen password or session may begin exploring your environment immediately. A working account can open doors without producing the obvious signs of a forced entry.

The important interval is the time between gaining access and being identified and interrupted. During that interval, normal business activity may continue alongside reconnaissance, theft or preparations for encryption. The incident has begun even if the people responsible for essential services have not yet seen an operational consequence.

Active Directory manages identities and access in many organisations. An attacker trying to reach those servers is therefore approaching infrastructure that can influence access to much of the environment. The practical implication is that the response window may already be narrowing while ordinary services remain available.

Shorter dwell time also reflects faster detection by defenders. It should not be read simply as evidence that every attacker has become faster, or that artificial intelligence caused the change. Your response planning needs to account for rapid progression without treating one report’s median as a guaranteed deadline.

A valid login confirms that a credential or session has been accepted. It does not establish that the person using it is the employee, administrator or supplier to whom the access was granted.

An intruder may use the same remote-access tool, server connection or cloud workflow as an authorised colleague. The distinction lies in what the account does: connecting to unfamiliar servers, seeking higher privileges, changing security settings or collecting information outside its normal role.

Firewall, endpoint and identity protections remain essential, and they may detect or block that activity. The question for your organisation is what happens when access has nevertheless been compromised: which signals reveal the misuse, and who investigates them before the account reaches additional systems?

An attacker preparing ransomware has a reason to examine how your organisation would recover. Backup repositories, recovery accounts and management consoles can reveal where copies are held and which permissions could be used to alter or delete them.

A successful backup job does not tell your security team whether an intruder is exploring the account or console that administers it. The question on this page is whether that preparation would be recognised in time. Whether the copies themselves can survive an attack and support restoration is the separate recovery question.

For your incident team, the immediate questions are concrete: which account or server is implicated, what access should be restricted, which services depend on it and who can authorise the action? A reviewed alert and a terminated session are different outcomes. The wider design of that response belongs to the detection-to-interruption question; here, the concern is how much preparation can continue before the warning changes anything.

Executive oversight does not require the reconstruction of every technical step. It requires evidence that the teams responsible for monitoring, investigation, and response can recognise an intrusion before service failure becomes the alarm.

• If a valid account starts accessing unfamiliar servers or sensitive repositories, which team receives the signal and how quickly is it reviewed?
• If an intruder attempts to access identity infrastructure, which responder can restrict the account or session while the investigation continues?
• Would attempts to access backup consoles or recovery accounts be visible before copies or settings were altered?
• Outside business hours, who owns an alert from first review through to a confirmed containment action?
• Which targeted action could your team take before an outage, and how would it establish the effect on essential services?

Answers should identify systems, people, coverage and actions. A list of installed tools or a general assurance that the incident plan exists cannot demonstrate how those responsibilities work together during the hidden phase.

The uninvited guest challenges one assumption: that an apparently normal working day means there is still time before the incident becomes serious. A stolen account can be used to explore systems, collect data or approach recovery infrastructure while essential services continue to run.

If someone gained access tonight, which activity would reveal the intrusion before files were encrypted or a service stopped, and who could act on that evidence?