Report Says Huntress Observed a 155-Fold Password-Spraying Spike

Report Says Huntress Observed a 155-Fold Password-Spraying Spike

BleepingComputer reported that Huntress observed a 155-fold increase in password-spraying activity during a period described as the first half of 2026. The report also associated more than 81 million login attempts over two weeks with a campaign.

NewsForge could not verify those figures against primary Huntress material, so they should be treated as claims attributed to Huntress through BleepingComputer—not as evidence that password spraying increased 155-fold across the internet.

The immediate defensive takeaway does not depend on that multiplier: MFA cannot protect accounts uniformly when legacy protocols, excluded users, service accounts, or alternative authentication flows remain outside its enforcement. Organizations should verify which login paths actually require MFA rather than assume that deploying it provides complete coverage.

The distinction between activity and impact is equally important. Login attempts are not confirmed account compromises. A large volume of authentication traffic may indicate persistent targeting, but it does not reveal how many attempts succeeded or what happened after any successful login. No verified compromise count was available for this draft.

What NewsForge could not verify

The available material does not identify where Huntress published the underlying findings or whether a complete technical analysis is publicly available. The unresolved questions fall into four broad categories:

How Password Spraying Targets Accounts

Password spraying is the practice of testing one password, or a small set of passwords, across many accounts. It differs from an attack that tries many candidate passwords against a single account.

Spreading attempts across multiple usernames can make the activity less obvious when monitoring focuses on repeated failures against each individual account. Defenders investigating a suspected spray should consider patterns across the identity environment rather than looking only at one user’s failure count.

Useful questions include whether one source targeted many accounts, whether many sources targeted the same account set, whether attempts followed a recurring schedule, and whether a successful login followed related failures. The available fields and their meaning depend on the identity platform, application, and logging configuration.

Where MFA Coverage Can Break Down

Multi-factor authentication (MFA) adds another verification requirement to a covered login. It does not provide uniform protection if some accounts, applications, protocols, or authentication flows fall outside the policy that requires it.

That distinction separates two materially different scenarios. In an MFA bypass, an attacker defeats, circumvents, or abuses an enforced MFA process. In an uncovered authentication flow, the login never requires MFA. The Huntress-attributed claims do not establish a technical bypass of an MFA challenge.

Legacy authentication and alternative paths

“Legacy authentication” can refer to older methods or clients that do not participate in the same controls as a platform’s modern sign-in process. Its precise meaning and behavior vary by identity provider and application.

Organizations may also operate administrative interfaces, remote-access services, applications with local accounts, automated processes, or other endpoints governed by separate authentication rules. A centrally deployed MFA policy should not be assumed to cover those paths without testing.

BleepingComputer’s report connects the reported activity with legacy authentication and gaps in MFA coverage. Because the affected methods and platforms were not identified, defenders should treat that as a prompt to inspect their own environments rather than assume a particular protocol was involved.

Exclusions, service accounts, and enrollment gaps

An exposure review should examine possible gaps such as:

• Users excluded from an MFA or access policy
• Accounts that have not completed MFA enrollment
• Service accounts permitted to sign in interactively with only a password
• Emergency access accounts without documented restrictions and monitoring
• Dormant accounts that remain enabled
• Applications that maintain separate authentication rules
• Policies scoped to only some users, groups, applications, devices, or locations

These are NewsForge’s risk-based review categories, not confirmed descriptions of the Huntress cases. Authentication logs and platform-specific policy records are necessary to determine whether any apply to a particular environment.

What the 155x Figure Does—and Does Not—Prove

A multiplier cannot be interpreted reliably without knowing its baseline, measured unit, comparison period, and dataset. Depending on those definitions, it could describe authentication attempts, detected incidents, affected customers, campaigns, or another measurement.

A higher observed count could reflect changes in attacker activity, attempt volume, customer visibility, detection, or some combination of factors. Vendor telemetry can provide an early signal, but it represents the systems visible to that vendor and the way the vendor classifies activity. It cannot, by itself, establish the scale or rate of password spraying across the broader internet.

Most importantly, the 155x claim and the 81 million-attempt total concern reported activity, not verified outcomes. Neither figure establishes how many accounts were accessed, whether attackers obtained useful privileges, or whether downstream activity occurred.

How Defenders Can Check Their Exposure

The unresolved questions about the reported activity do not prevent organizations from documenting which authentication paths require MFA and which still accept passwords without an additional factor. The following steps are NewsForge’s risk-based priorities. Implementation decisions should be checked against current documentation for each identity platform and application.

1. Inventory every authentication path

List identity providers, remote-access systems, email services, cloud applications, administrative portals, externally reachable appliances, and applications with local user databases.

For each entry, document:

• The authentication protocol or flow
• The account populations allowed to use it
• Whether MFA is required in practice
• The policy owner
• The available log source
• Whether interactive sign-in is necessary
• Any approved exception and its expiration or review date

The objective is to record tested coverage rather than rely on a general statement that MFA has been deployed.

2. Identify legacy and password-only authentication

Determine which older clients, protocols, applications, and automated processes still depend on password-only access. Before changing production systems, identify operational dependencies and consult the relevant provider documentation.

Where a path cannot be removed immediately, document why it remains necessary, who owns the exception, what accounts can use it, and what monitoring covers it. Platform-specific restrictions should be selected only after confirming how that system enforces authentication policies.

3. Audit enrollment, exclusions, and access policies

Compare the account directory with MFA enrollment and enforcement records. Review exclusions individually, including temporary exceptions that may have remained in place after their original purpose ended.

Test policy behavior for relevant applications and login routes. A policy’s intended scope is not, by itself, proof that every authentication attempt passes through it.

4. Review logs for distributed failures

Examine sign-in records for patterns spanning multiple accounts and sources. Review teams can look for:

• One source attempting to access many accounts
• Multiple sources targeting the same set of accounts
• Failures recurring at regular intervals
• Unfamiliar authentication methods or client characteristics
• Successful sign-ins occurring near related distributed failures
• Sign-ins through flows that did not require MFA

Investigators should interpret these observations in the context of their platform’s log fields and retention settings. A pattern can justify further investigation without, by itself, proving malicious activity or account compromise.

5. Prioritize privileged, dormant, emergency, and service accounts

Document whether these accounts can sign in interactively, which authentication requirements apply, and who reviews their activity. Remove unnecessary access only through the organization’s normal change-control process.

If evidence indicates that an account was accessed, the investigation should cover subsequent identity and application activity. Relevant areas may include role changes, authentication-method changes, recovery settings, active sessions, tokens, and application-specific actions, depending on the systems involved.

6. Produce a documented findings package

The completed review should produce more than an informal checklist. Record:

• Every authentication path examined
• MFA coverage and tested policy behavior
• Legacy or password-only flows
• Excluded and unenrolled accounts
• Service-account and emergency-access exposure
• Relevant suspicious sign-in patterns
• Remediation owners and target dates
• Exceptions requiring formal acceptance or further review

This package gives identity and access management teams a defined set of findings to validate, prioritize, and track.

What Organizations Should Watch Next

Primary Huntress material could clarify how the reported multiplier was calculated and what the activity meant operationally. Independent reporting from security vendors, identity providers, or government authorities would help determine whether it reflects a sustained broader trend or conditions specific to Huntress’s visibility. Confirmed compromises and post-authentication activity would provide a clearer measure of impact than login volume alone.

For now, the defensible takeaway is narrower than the reported 155x figure: organizations should verify where MFA is actually enforced rather than assume deployment equals complete coverage. Review legacy authentication, policy exclusions, service accounts, alternative login paths, and suspicious distributed failures. Document the results in a findings package, then share it with the teams responsible for identity and access management, security monitoring, and incident response.