Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1946: Analytic 1946

Monitor for suspicious network traffic that could be indicative of probing for email addresses and/or usernames, such as large/iterative quantities of authentication requests originating from a single source (especially if the source is known to be associated with an adversary/botnet). Analyzing web metadata may also reveal artifacts that can be attributed to potentially malicious activity, such as referer or user-agent string HTTP/S fields.

EnterpriseAN1946AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because username and email probing can be an early warning that an organization is being mapped for later access attempts. For leaders, the value is not in the alert alone, but in confirming whether identity-facing services and web entry points produce enough evidence to distinguish normal authentication volume from large or iterative enumeration-like activity.

Executive priority

Prioritize this as an identity and SOC readiness validation item. Executives should ask whether authentication and web metadata are retained, correlated, and reviewed well enough to support early incident decisions before account compromise is confirmed. It also supports audit and compliance evidence by showing whether the organization can monitor identity-facing access patterns and investigate suspicious source behavior.

Technical view

SOC and detection teams should validate monitoring for large or iterative authentication requests from a single source, especially when the source can be compared against known suspicious infrastructure or botnet-related intelligence. Because the ATT&CK object lists platform PRE and no tactics, treat this as pre-compromise reconnaissance-style detection support rather than proof of compromise. Web metadata such as HTTP/S referer and user-agent fields should be reviewed for artifacts that help cluster activity and separate automation from normal user traffic.

Likely telemetry

  • Authentication request logs for externally reachable services
  • Source IP address and request-rate metadata
  • Web server, reverse proxy, WAF, or application gateway logs
  • HTTP/S metadata including referer and user-agent fields
  • Threat intelligence context for known suspicious sources, where available

Detection direction

  • Baseline normal authentication request volume by source, application, and time window before alerting on high-volume or iterative behavior.
  • Tune detections to identify repeated probing for usernames or email addresses from a single source while accounting for legitimate scanners, monitoring systems, NAT gateways, and business partners.
  • Correlate network and web metadata with authentication outcomes to avoid treating generic web traffic as confirmed identity probing.
  • Use referer and user-agent patterns as supporting evidence, not sole proof of malicious activity.
  • Document blind spots where identity-facing services do not log source, request volume, referer, user-agent, or attempted username/email values.

Mitigation priorities

  • Ensure externally reachable authentication and web entry points generate sufficient logs for investigation.
  • Centralize and retain authentication and web metadata so SOC and incident responders can correlate activity by source and time.
  • Apply rate limiting, bot-management, or abuse-prevention controls where appropriate for high-volume authentication request patterns.
  • Maintain a process for enriching suspicious sources with threat intelligence while avoiding automatic attribution without evidence.
  • Review incident response playbooks for early-stage identity probing so teams know when to escalate, block, monitor, or collect additional evidence.
Analyst notes and limits

The supplied ATT&CK object is a detection analytic, not a technique, and provides no relationship context or explicit tactic mapping. The strongest use is as a coverage check for identity-facing telemetry and detection logic around high-volume or iterative authentication behavior and web metadata analysis.

Official detection content was not provided, platforms are limited to PRE, and no relationships were supplied. Local service architecture, logging depth, identity provider behavior, and normal traffic baselines are required before determining alert thresholds or coverage quality.

Official MITRE ATT&CK definition

Analytic 1946

Monitor for suspicious network traffic that could be indicative of probing for email addresses and/or usernames, such as large/iterative quantities of authentication requests originating from a single source (especially if the source is known to be associated with an adversary/botnet). Analyzing web metadata may also reveal artifacts that can be attributed to potentially malicious activity, such as referer or user-agent string HTTP/S fields.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
2a5bf21d6bd3db3f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 2a5bf21d6bd3…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1946
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.