A cyberattack starts earlier than you think: the first signs nobody notices

At 7:15 a.m. on Monday, employees cannot open files, some systems stop responding and ransom demands appear on screens. For the organization, the cyberattack has just begun. For the attacker, this may be the final stage of activity that has continued for days.

The first signs of a cyberattack may have been visible much earlier: an unusual sign-in, a new device, increased activity on one account, access to additional resources or a change in permissions. Each signal alone might have looked harmless. Only linking them into a sequence would have revealed the developing incident.

Useful insights

• Ransomware, data exfiltration or loss of control over systems often represent the culmination of an attack, rather than its beginning.
• A single anomaly does not necessarily mean a breach. Risk increases when several events involve the same account, device or asset and form a logical sequence.
• Companies often have the data needed to detect a threat, but lack complete telemetry, correlation, round-the-clock analysis and a clear escalation path.
• SIEM, EDR/XDR and UEBA support detection but do not replace an analyst, business context or an incident response process.
• The primary purpose of a 24/7 SOC is to shorten the time an attacker remains undetected, before the incident affects the business.

A cyberattack does not begin on the day of the outage

What management and users see is often the final stage of a longer process. Before that, an attacker may gain initial access, explore the environment, find valuable assets, expand access and move to other systems. MITRE ATT&CK organizes these objectives into tactics including Initial Access, Discovery, Lateral Movement and Impact. However, not every incident includes every stage or follows the same sequence.

The detection window is not merely theoretical. According to M-Trends 2026 the global median time between initial access and detection of an attacker’s presence was 14 days in investigations analyzed for 2025. This does not mean every cyberattack lasts exactly two weeks. It shows that there may be a real opportunity between initial access and detection to observe signals and contain a threat.

From a business perspective, the question is not simply whether the organization has a firewall, EDR or SIEM. More importantly: can it notice changes in account behavior, connect data from multiple sources, assess asset significance and begin responding before an anomaly becomes downtime?

„The most dangerous alert does not always look dangerous when it first appears. Its significance often depends on context: what happened earlier, which account is involved and which assets the next step leads to.”

An illustrative timeline: 14 days before the incident

The following scenario illustrates how risk can build up. It does not describe a specific client or a guaranteed cyberattack timeline.

Point in time	What may be visible	How it may appear in isolation	What correlation reveals
Day -14	Sign-in from a new location, another device or at an unusual time	Employee travel, VPN use or a hardware change	Comparison with account history, sign-in risk and subsequent activity
Day -10	Access to many resources and an unusual increase in queries	Intensive work, an administrative script or changed responsibilities	Deviation from the user’s profile and interest in resources outside their role
Day -7	New sign-ins to additional systems, use of other accounts and permission changes	Routine IT tasks or technical support	A sequence suggesting possible lateral movement or access escalation
Day -2	Security changes, attempted access to backups and repeated access testing	Maintenance work or a configuration error	Earlier events raise the priority and justify escalation
Day 0	Encryption, data exfiltration, system takeover or service disruption	An unmistakable crisis	Retrospective analysis shows that the incident began developing much earlier

The greatest opportunity to limit consequences usually comes before day 0. The attacker’s actions may be less visible then, but their potential business impact is still lower than after multiple systems have been compromised.

Day -14: the first unusual sign-in

The first trace may be a successful sign-in to a legitimate account. There is no malicious file, antivirus warning or password error. However, the system sees a change: a different IP address, new location, unfamiliar device, different browser or activity at an unusual time for the user.

Sign-in risk assessment mechanisms use these attributes, among others. Documentation for Microsoft Entra ID Protection states that unfamiliar sign-in properties detection can consider IP address, ASN, location, device, browser and the organization’s subnet.

A new location or device is not proof of an attack. An employee may be traveling, using a new laptop or connecting through the company VPN. Automatically blocking every deviation would therefore cause disruption. Assessment is needed to determine:

• whether the activity matches the user’s history;
• whether the device is managed and compliant with policy;
• whether authentication passed the required checks;
• whether other unusual activity followed immediately after sign-in;
• whether the account can access critical assets.

The first signal rarely provides a complete answer. It does provide a starting point for tracking subsequent events.

Day -10: environment reconnaissance

Once access is gained, account activity may change. A user who normally works in two applications starts reading information from many resources. Queries appear to systems they have not previously contacted, or the number of operations rises sharply over a short period.

Again, this does not necessarily mean an attack. A new system deployment, inventory exercise, audit or administrator activity may look similar. Security log analysis should therefore ask not only „What happened?” but also:

• whether the activity matches the user’s role;
• whether it occurred within an approved change window;
• whether it involves the user’s usual devices and systems;
• whether it was preceded by an event that raised the account’s risk;
• whether a similar pattern appeared on other devices.

This is the difference between collecting logs and detecting threats. A log records that an event occurred. Detection tries to establish whether the event matters in a wider context.

Day -7: the first signs of lateral movement

The next stage may involve new sign-ins to additional systems, access to network resources, use of an account with greater privileges or changes in group membership. The environment sees separate operations. The organization needs to know whether they represent routine administration or a single attack path.

Lateral Movement changes the nature of the incident. The problem no longer concerns only one account or workstation. The attacker may gain access to further resources, expanding the scope of analysis and response required.

At this point, correlation should combine at least three perspectives:

• identity—who authenticated and how;
• endpoint—which device the activity came from and what happened on it earlier;
• asset—which system was accessed and its business significance.

Without this correlation, each team may see only part of the picture: the cloud administrator sees an unusual sign-in, the endpoint team a single EDR alert, and the application owner an access change. Nobody sees the full story.

Does your security data form a unified picture?

Most organizations already have some of the information needed for early detection. The gap appears when data stays in separate consoles, alerts have no owner and nobody assesses their significance after hours. Reviewing the current monitoring model and 24/7 SOC offering helps identify exactly where the path from signal to decision breaks down.

Contact us

Day -2: preparing for the final stage

Risk rises sharply in the last phase before a visible incident. There may be attempts to weaken security controls, configuration changes, access to backup systems, increased privileged-account activity or repeated tests of access to key resources.

A single change may still have a legitimate explanation. But if it follows an unusual sign-in, environment reconnaissance and activity across multiple systems, it means something very different. A SOC should assess it as a possible part of a developing incident, rather than an isolated configuration alert.

This is when previously agreed response permissions matter. Even accurate detection will not contain a threat if the team does not know:

• who can block an account;
• who decides whether to isolate a device;
• which systems may be disconnected temporarily;
• when to activate incident response;
• who assesses the business impact of technical action.

Day 0: the visible incident

The problem only becomes obvious on day 0. Files are encrypted, data has been copied, privileged accounts are compromised or a key service stops working. The organization focuses on limiting consequences, communication, business continuity and system recovery.

This is the most expensive point at which to begin responding. The incident is broader, decisions are made under pressure and every isolation action may affect operations. Retrospective analysis often reveals that the necessary signals were present in logs much earlier.

That is why „How do you detect a cyberattack?” cannot be answered by ransomware detection alone. Organizations must look for earlier behavioral changes and measure the time from the first significant anomaly to its confirmation. This is the practical meaning of MTTD.

Why the organization noticed nothing

Usually, the problem is not a complete absence of data. It is how that data is used.

Individual alerts look harmless

An unusual location may reflect travel, a permission change an approved request, and increased activity intensive work. Without history and business context, there is no basis for a reliable decision.

Events are scattered

Identity logs are in the cloud, endpoint telemetry in EDR, network traffic in another tool and administrative changes in the ticketing system. When nobody connects them, a developing attack looks like a series of unrelated exceptions.

The alert has no owner

A system may correctly generate a notification that reaches a shared mailbox or a queue reviewed only the following day. Recording an event is not the same as handling it.

Monitoring stops after business hours

An attack does not have to follow the company’s calendar. If nobody is responsible for assessment and escalation at night, on weekends or holidays, the attacker’s operating window grows regardless of tool quality.

Rules do not reflect the environment

Default configuration knows nothing about asset criticality, user roles, maintenance windows or approved exceptions. Without rule tuning, the organization receives too much noise or misses significant deviations.

Detection is not connected to response

Even a confirmed incident may wait if playbooks, contacts, escalation levels and decision-making authority are missing. SIEM without a complete process may record traces correctly, but does not guarantee timely analysis or containment.

Illustrative scenario: five signals nobody connected

The following is an illustrative scenario. It does not describe a specific organization or VigilHorizon client.

A medium-sized company uses Microsoft 365, cloud services, on-premises Active Directory, EDR on workstations and a central log repository. Monitoring operates, but alerts are analyzed mainly during business hours.

On Friday evening, an employee account signs in from a new device. The event is assigned medium priority and is not picked up before Monday. A few days later, the same account accesses resources it has never used before. The system records increased activity, but no individual rule threshold is exceeded.

The following week brings sign-ins to further systems and a permission change. Each event goes to a different console and owner. The permission change looks like administrator activity because it has not been linked to account risk and unusual device activity.

Two days before the incident, EDR records an attempt to change security settings. The alert is closed as inconclusive because the analyst cannot see earlier identity events. On day 0, some data is encrypted and business systems become temporarily unavailable.

All the signals existed, but no single incident captured the complete sequence. If the SOC had correlated sign-ins, account behavior, endpoint telemetry, permission changes and asset criticality, the priority could have risen during reconnaissance or lateral movement. This does not guarantee stopping every attack, but creates an earlier and much less costly decision point.

How a SOC detects a developing attack

A SOC should not treat every deviation as a confirmed incident. Its role is to verify, correlate, prioritize and route confirmed risk for response.

Early signal	Why it may be ignored	How the SOC responds
Unusual sign-in	May result from travel, VPN use or a new device	Compares account history, device, location, MFA result and subsequent activity
New device	May be a legitimate hardware replacement	Checks device management, compliance and identity risk
Increased account activity	Trend changes are difficult to spot manually	Compares operation volumes and types with the user’s profile and role
Access to many resources	May resemble intensive work	Correlates resources, event sequence and system criticality
Permission change	May be a routine IT task	Verifies the ticket, change window, person making the change and earlier alert context
Sign-ins to additional systems	Each may look legitimate	Combines identity, network and endpoint events into a possible lateral movement scenario
Security settings change	May be maintenance work	Checks authorization, impact and links to privileged-account activity
Access to backups	Administrators perform these operations legitimately	Raises priority when behavior deviates from the schedule or coincides with other anomalies

In practice, an effective process includes:

1. receiving telemetry from key sources;
2. assessing data quality and completeness;
3. correlating events in SIEM/XDR;
4. using behavioral analysis where justified;
5. enriching alerts with identity, device and asset context;
6. triage by a SOC analyst;
7. classification and escalation under the playbook;
8. containment actions within the agreed incident response process;
9. documentation, root-cause analysis and post-incident rule improvements.

The distinction between visibility and the ability to act is explored further in What a 24/7 SOC is and why monitoring alone is not enough.

How to shorten detection time

The goal is not to promise complete elimination of risk. A mature model shortens the time from the first meaningful signal to assessment and decision, and reduces the points where an incident can stall.

1. Collect telemetry from critical assets

Events cannot be detected if tools do not record or forward them. Priorities include identities, privileged accounts, endpoints, internet-facing systems, network infrastructure, email and the most important business applications.

2. Measure data quality, not just quantity

Millions of logs offer little help if they arrive late, lack fields, have incorrect timestamps or are retained too briefly. The organization should know which detection scenarios need specific sources and how quickly a telemetry loss will be noticed.

3. Correlate behavior across systems

SIEM connects events from multiple sources, XDR reveals relationships in security telemetry, and UEBA can highlight deviations from typical behavior. None should operate without tuning, testing and contextual assessment.

4. Provide 24/7 analysis

24/7 IT security monitoring means more than an available dashboard. It requires a team that will pick up alerts, verify data, set priorities and initiate escalation at any time.

5. Connect detection to a playbook

Clear analysis and decision steps should exist for compromised accounts, unusual administrative activity, lateral movement and attempts to weaken controls. A playbook must identify the owner, contacts, escalation conditions and permitted containment actions.

6. Measure the entire timeline

MTTD alone does not show whether an alert waited in a queue, how long verification took or when containment began. Measure alert creation, analysis start, incident confirmation, escalation and response initiation separately. Metric interpretation is explored further in MTTD and MTTR—why detection time determines incident scale.

7. Test scenarios from signal to response

A test should not stop at checking whether a rule generated an alert. It must verify that the alert reached the right person, the analyst had enough context, escalation worked and a decision could be made within an acceptable timeframe.

Checklist: will you detect an attack before day 0?

Select an answer to each question:

Question	Answer
Are Microsoft 365, VPN and on-premises sign-ins analyzed together?	YES / NO
Does monitoring cover every privileged account and critical asset?	YES / NO
Is the team notified when telemetry is lost or delayed?	YES / NO
Are new devices and unusual locations assessed against user history?	YES / NO
Are permission changes compared with approved requests?	YES / NO
Are EDR/XDR alerts correlated with identity and network events?	YES / NO
Does someone analyze security alerts around the clock, including weekends and holidays?	YES / NO
Does every high-risk alert have an owner and an acknowledgment deadline?	YES / NO
Does the playbook specify who can block an account or isolate a device?	YES / NO
Has the incident response process been tested in the past 12 months?	YES / NO
Are alert creation, acknowledgment, confirmation, escalation and response times measured?	YES / NO
Do lessons from incidents and tests feed back into detection rules?	YES / NO

If most answers are „no,” the organization may have tools and logs but still lack a coherent early detection capability. A useful next step is a readiness test: Would your company detect ransomware before servers were encrypted?.

Summary

A modern cyberattack rarely begins with a spectacular outage. It more often develops from individual events that reveal a real threat only when connected. An unusual sign-in, a new device, a change in account activity and access to further systems do not necessarily mean an incident. But they should not be left without context.

The greatest value of a 24/7 SOC is its ability to recognize this sequence, shorten MTTD and initiate a response before business impact becomes visible. This requires combining telemetry, SIEM/XDR, analysts, business context, playbooks and the Incident Response.

If you do not know who analyzes alerts outside business hours, which data sources are critical or how long it takes to move from signal to decision, start with a review of your current monitoring model. Its purpose is to identify detection and response gaps and match security monitoring, 24/7 SOC or audit scope to the organization’s actual risk.

Frequently asked questions (FAQ)

What are the first signs of a cyberattack?​

Early signs may include unusual sign-ins, new devices, sudden changes in account activity, access to resources outside the normal role, sign-ins to additional systems, permission changes or attempts to modify security controls. None of these signals alone necessarily confirms an attack.

Does every unusual sign-in mean an account has been compromised?​

No. An unusual sign-in may reflect travel, VPN use, a device change or legitimate work outside normal hours. Assessment must consider user history, device, authentication method, location and activity after sign-in.

How can you detect a security incident in a company at an early stage?​

You need complete data from key systems, effective detection rules, event correlation, behavioral analysis where appropriate, business context and a team capable of round-the-clock triage and escalation. Detection must connect to a response process.

Does a cyberattack always last many days?​

No. Some attacks develop very quickly; others remain undetected for weeks or longer. This article’s 14-day model illustrates a sequence of possible signals, not a universal incident duration.

What does dwell time mean?​

Dwell time is the period an attacker remains in an environment before being detected. The longer it lasts, the more opportunity they have to explore infrastructure, expand access and prepare actions that affect the organization.

What is the difference between an event, an alert and an incident?​

An event is recorded activity in a system. An alert is generated when a rule or analytical mechanism identifies an event or sequence as requiring attention. An incident is a confirmed or sufficiently likely breach requiring coordinated handling under the adopted classification.

Will SIEM detect every threat?​

No. SIEM cannot see data that the organization does not send to it, and rule effectiveness depends on configuration, telemetry quality, updates and testing. The system supports correlation, but alerts still require assessment and an appropriate response.

How does Microsoft 365 monitoring help detect account compromise?​

It enables analysis of sign-in risk, new devices, account configuration changes, email activity, permission grants and resource access, among other things. Its greatest value comes from combining this data with endpoint, network and other system telemetry.

How do you detect lateral movement in a network?​

Correlate sign-ins to additional systems, unusual account use, access to shares and services, permission changes, and endpoint and network telemetry. Assessment must consider the user’s role, authorized administrative work and asset criticality.

Why does 24/7 monitoring shorten detection time?​

Because an alert can be picked up and assessed at night, on weekends or holidays. Tool availability alone is not enough—staffing, accountability, context and an escalation procedure are needed.

Does UEBA replace a SOC analyst?​

No. UEBA can identify deviations from typical behavior, but does not know the full business justification for every activity. Analysts verify context, connect data and assess whether an anomaly requires escalation.

What should a company do after detecting the first suspicious signal?​

It should verify the event, check related accounts, devices and assets, assess the scope and preserve data needed for analysis. If the risk is significant, activate the agreed playbook and incident response process. Specific containment actions should follow permissions, system criticality and business impact.

Learn more

• What a 24/7 SOC is and why monitoring alone is not enough
• MTTD and MTTR—why detection time determines incident scale
• Lateral movement—the attack stage most companies never notice
• Why did SIEM fail to detect ransomware? Common causes and organisational mistakes
• Incident Response — responding to a cyberattack step by step
• Would your company detect ransomware before servers were encrypted?