Credential abuse surpasses malware as the top silent threat

Attackers no longer need to make noise to compromise a company. Often, they don’t enter by deploying malware, exploiting a critical vulnerability, or launching a visible ransomware campaign from the very first moment. They gain entry with a valid account, a stolen password, forgotten VPN access, a cloud session without MFA, or a convincing helpdesk call. When that happens, much of the traditional security becomes too late.

The latest global report from Kaspersky Security Services highlights this trend once again: credential- and identity-based techniques are among the most effective observed in 2025. Their analysis shows that password guessing has a 34.8% conversion rate to confirmed incidents, closely followed by local account creation at 34.7%, and abuse of valid accounts at 34.5%. Account manipulation reaches 32%, and network service discovery 31.2%.

The problem: a legitimate account looks like a legitimate account

Credential abuse works because it resembles normal activity too closely. An EDR might detect a suspicious binary, an antivirus could block a known sample, and a firewall might cut off an unusual connection. But when the attacker logs in with a real user, from a corporate service, using legitimate admin tools, the signals are much weaker.

This technique isn’t new, but its effectiveness remains high because many companies share the same weaknesses: reused passwords, old active accounts, incomplete MFA, exposed services, users with more privileges than necessary, and low visibility over identity changes. Kaspersky interprets this pattern as a strategic shift: fewer noisy malware instances, and more legitimate access reused to avoid detection.

MITRE ATT&CK describes this technique as using valid accounts to gain initial access, persistence, privilege escalation, or evasion. Its danger lies precisely in the fact that the attacker doesn’t always need to break anything. They can authenticate, move laterally, query resources, and expand control with credentials the system accepts as valid.

Creating local accounts is a clear example of persistence. Once inside, an attacker can create a new user to avoid dependence on the initial access. If the compromised account is disabled, the intruder still has another backdoor. Account manipulation follows the same logic: reactivating disabled users, adding members to privileged groups, or modifying permissions without deploying external tools.

Four real-world examples illustrating the risks

The Colonial Pipeline case remains a fundamental lesson for any security team. In 2021, its CEO explained before the US Senate that attackers gained access using a stolen password linked to an outdated VPN system without multifactor authentication. It wasn’t a sophisticated exploit against unknown technology; it was a single-factor account on critical infrastructure.

Microsoft experienced another relevant example in 2024 with Midnight Blizzard, also known as Nobelium or APT29. According to the company, attackers used password spray attacks against a legacy account from a non-production tenant lacking MFA. From there, the incident escalated to access corporate emails. The lesson is uncomfortable: “non-production” environments are also part of the attack surface.

The Snowflake incident in 2024 revealed another aspect of the same problem. Mandiant identified a data theft and extortion campaign against Snowflake customer instances, attributed to UNC5537, involving stolen credentials—many obtained via info-stealer malware. Mandiant noted that compromised accounts often lacked MFA and there was no evidence that the breach was due to Snowflake platform vulnerabilities. The key lesson: in SaaS, provider security cannot compensate for poorly protected customer identities.

Social engineering attacks against helpdesk personnel add another layer. Okta warned in 2023 about a campaign where attackers called support staff to persuade them to reset MFA factors for high-privilege users. Once inside the admin accounts, they exploited legitimate federation functions to impersonate users within the organization. No need to hack Okta directly: manipulating the support process was enough.

These examples share a common feature. An attacker does not always enter through the expected point. They can exploit an old account, a forgotten tenant, leaked credentials, a compromised laptop with info-stealer malware, or a helpdesk operator under pressure from an urgent call. That’s why defenses can no longer focus solely on endpoints or perimeter security.

Signals a SOC should not ignore

Credential abuse rarely appears as a single spectacular event. It usually builds a chain: first failed login attempts, then successful authentication from an unusual location, followed by internal service exploration. Later, group changes, user creation, MFA device registration, or abnormal activity with admin tools.

A SOC should treat these signals as pieces of the same story. An off-hours local account creation might be benign if done by a known administrator during maintenance. But if it appears after multiple failed attempts, from an unusual IP, and followed by internal resource queries, the context changes drastically.

It’s also crucial to monitor identity changes more closely: MFA resets, new device enrollments, reactivation of disabled accounts, privilege role modifications, OAuth app creations, API token generation, email rule changes, new SSH keys, secrets in repositories, and cloud console access from unusual locations.

In hybrid environments, the challenge grows. A company might have on-prem Active Directory, Entra ID, Okta, Google Workspace, AWS IAM, critical SaaS accounts, VPNs, and remote management tools. If each logs events separately and no one correlates them, attackers can slip through gaps in visibility.

Which controls truly help

The first step is to accept that identity is a primary attack surface. MFA should be mandatory, especially for remote access, privileged accounts, cloud dashboards, critical SaaS, and admin tools. But MFA alone doesn’t suffice—attacks against helpdesks show that protection of reset processes, device registration, and account recovery are equally vital.

The second measure is to reduce privileges. Permanent admin accounts should be rare. Privileged access must be time-limited, justified, logged, and periodically reviewed. Local accounts need to be inventoried and monitored. Inactive accounts must be properly disabled and checked regularly.

Third, control behavior, not just authentication. A valid login can still be malicious. Detection rules based on risk are essential: unusual location, unknown ASN, impossible travel, device change, out-of-hours access, suspicious activity after MFA reset, or admin tool usage by users who never usually perform such actions.

Fourth, protect user credentials at endpoints. Campaigns like Snowflake show how info-stealers impact security. A compromised device can exfiltrate session tokens, stored keys in browsers, cloud credentials, or access to corporate platforms. Endpoint hygiene remains necessary but must integrate with identity protection.

Fifth, test human procedures. Helpdesk processes should not be shortcuts over technical controls. Recovery procedures must include strong identity verification, additional approval for privileged users, temporary blocking upon suspicious signs, and alerts when MFA factors are reset on sensitive accounts.

For administrators, SOC teams, and security leaders, the takeaway is clear: if an attacker can log in with a valid account, create new ones, escalate privileges, and move laterally unnoticed, the issue is not just passwords. It’s about identity architecture, telemetry, and response capabilities.

Modern defense must start from an uncomfortable truth: a valid credential doesn’t prove user legitimacy. It only shows someone has passed a gate. What matters next is understanding who’s acting, from where, with what pattern, on which resources, and with what intent.

Frequently Asked Questions

What is credential abuse in cybersecurity?
It is the use of legitimate, stolen, or compromised accounts to access corporate systems and operate as if the attacker were an authorized user.

Why is credential abuse difficult to detect?
Because many actions seem normal: login, application access, permission changes, or admin tool use. Detection depends on context and correlation.

Does MFA completely prevent these attacks?
No. MFA greatly reduces risk but must be complemented by helpdesk protection, device control, anomaly detection, least privilege, and regular account reviews.

What real-world examples demonstrate this problem?
Cases like Colonial Pipeline, Microsoft Midnight Blizzard, Snowflake fraud campaigns, and social engineering attacks on Okta tenants show how credentials, old accounts, or weak support processes can open doors to serious breaches.

via: Open Security