How do most data breaches happen?

Through a small number of paths: stolen or guessed credentials, exploitation of internet-facing software, cloud and access misconfiguration, compromise of a third party with access, and social engineering of staff or the service desk. Novel exploits are far less common than valid logins and unpatched systems.

Why is the IT service desk a target for attackers?

Because it can reset passwords and multi-factor authentication factors, unlock accounts, and grant temporary access, and it is trained to resolve requests quickly. Social engineering of help desks has featured in multiple publicly reported intrusions, usually using detailed employee knowledge plus urgency to bypass verification.

How long do attackers stay in a network before being detected?

Publicly reported incidents frequently describe dwell times of weeks, during which attackers enumerate systems, escalate privilege, and move toward data. That period is also the window in which detection through identity and central log monitoring remains possible. Shorter detection times are the goal of identity monitoring.

What reduces breach risk most?

Phishing-resistant multi-factor authentication and strong identity controls, fast patching of internet-facing systems, continuous detection of misconfigurations, least-privilege time-bounded third-party access, verification procedures at the service desk, and central logging that an attacker on a compromised host cannot edit. No single control covers every path.

How Data Breaches Actually Happen

Most breaches follow a small number of paths: stolen or guessed credentials, exploitation of an internet-facing vulnerability, a cloud or access misconfiguration, compromise through a third party, or social engineering of staff including the service desk. Attackers then escalate privilege, move laterally, and take data, usually over days or weeks rather than minutes.

The common entry paths

Credential compromise. Phishing, credential stuffing using passwords reused from other breaches, information-stealing malware on an employee or contractor device, and tokens or keys committed to repositories. Logins with valid credentials look normal, which is what makes this path effective.

Exploitation of internet-facing software. Unpatched web applications, VPN concentrators, file transfer products, and security appliances. Exploitation often begins within hours or days of a patch, because the patch itself reveals the flaw.

Misconfiguration. Storage buckets open to the internet, databases exposed without authentication, over-permissive identity policies, and test environments holding production data. No exploit is required; the data is simply reachable.

Third parties. Suppliers, contractors, managed service providers, and software vendors with access to your systems or data. Their compromise becomes yours, and their controls are largely outside your view.

Social engineering of people and process. Convincing an employee to approve an authentication prompt, persuading a service desk to reset a password or an MFA factor, or sending a fraudulent legal request for data. The technology works exactly as designed.

Insiders. Deliberate misuse by people with legitimate access, and accidental exposure through mistakes such as sending files to the wrong recipient.

What happens after entry

Access is rarely where the attacker wants to be. They enumerate the environment, escalate privilege, look for identity infrastructure, and move toward data stores or backup systems. Publicly reported incidents frequently describe dwell times measured in weeks, which is time in which detection is still possible.

Why the service desk is a target

The service desk sits at the intersection of identity and urgency. It can reset passwords, reset multi-factor authentication factors, unlock accounts, grant temporary access, and add devices. It is also trained to be helpful and to resolve things quickly.

Social engineering of help desks has featured in several publicly reported intrusions, typically following a familiar pattern: a caller who knows enough employee detail to sound legitimate, a plausible urgent reason, pressure applied to skip verification, and a request that restores authentication rather than one that obviously grants access.

Controls that reduce this specific risk.

Define which requests require verification beyond what the caller can state, and make identity resets the highest tier.
Verify through a channel the caller did not choose, such as calling back a number from the directory or an approval from the requester's manager in a system the caller does not control.
Require a second approver for MFA factor resets and privileged account unlocks.
Record who verified, how, and when, on the ticket, every time.
Remove the pressure: make it explicit policy that agents may refuse urgency, and back them when they do.
Alert on patterns, such as repeated reset requests for privileged accounts or requests outside an employee's normal hours and location.

Where to intervene

Make credentials less useful. Phishing-resistant multi-factor authentication, conditional access based on device and location, short-lived credentials for services, and monitoring for impossible travel and anomalous session behaviour.

Shrink and patch the edge. Inventory everything that is internet facing, patch those systems on the fastest tier, and remove services that do not need to be exposed.

Find misconfigurations continuously. Automated checks for public storage, exposed databases, and excessive permissions, run on a schedule rather than at audit time.

Govern third-party access. Least privilege for suppliers, time-bounded access, separate accounts, and monitoring of what those accounts do.

Instrument identity. Most intrusions touch identity systems. Alerting on privilege grants, MFA resets, new device registrations, and unusual administrative actions catches more than endpoint alerting alone.

Log centrally, off the affected system. Attackers with privilege edit local logs. Central, immutable retention is what makes investigation possible.

Practise the response. A tabletop exercise where credentials are compromised and the service desk was involved reveals whether your process can answer basic questions: who reset what, verified by whom, and when.

Close with a cause, not a symptom. Recording that an incident began with a service desk reset, a third-party account, or an unpatched appliance is what turns individual incidents into a pattern you can act on.

Preparing for disclosure

Notification obligations vary by jurisdiction and data type, and the clock often starts at awareness rather than confirmation. Knowing in advance who decides, what evidence is needed, and which regulators and customers must be told keeps the response from stalling while lawyers and engineers work out the process during the incident.

Frequently asked questions

How do most data breaches happen?: Through a small number of paths: stolen or guessed credentials, exploitation of internet-facing software, cloud and access misconfiguration, compromise of a third party with access, and social engineering of staff or the service desk. Novel exploits are far less common than valid logins and unpatched systems.
Why is the IT service desk a target for attackers?: Because it can reset passwords and multi-factor authentication factors, unlock accounts, and grant temporary access, and it is trained to resolve requests quickly. Social engineering of help desks has featured in multiple publicly reported intrusions, usually using detailed employee knowledge plus urgency to bypass verification.
How long do attackers stay in a network before being detected?: Publicly reported incidents frequently describe dwell times of weeks, during which attackers enumerate systems, escalate privilege, and move toward data. That period is also the window in which detection through identity and central log monitoring remains possible. Shorter detection times are the goal of identity monitoring.
What reduces breach risk most?: Phishing-resistant multi-factor authentication and strong identity controls, fast patching of internet-facing systems, continuous detection of misconfigurations, least-privilege time-bounded third-party access, verification procedures at the service desk, and central logging that an attacker on a compromised host cannot edit. No single control covers every path.