AN1973: Analytic 1973
Monitor for suspicious network traffic that could be indicative of probing for user information, 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.
Analyst context for executives and security teams
This analytic matters because repeated or high-volume authentication requests from one source can be an early warning that someone is probing for valid user information before a larger intrusion attempt. For leaders, the value is not just blocking bad traffic; it is confirming whether identity-facing services, web logs, and SOC workflows can recognize suspicious enumeration-like behavior before it becomes an incident.
Executive priority
Prioritize this as an identity and resilience validation item for externally reachable authentication paths. Security leaders should ask whether the organization can prove it collects enough network and web metadata to investigate large or iterative authentication activity, whether known hostile or botnet-associated sources are handled consistently, and whether SOC teams can escalate suspicious probing without overwhelming responders with normal login noise.
Technical view
The supplied ATT&CK analytic is for the PRE platform and focuses on suspicious network traffic that may indicate probing for user information. SOC and detection teams should validate monitoring for large or iterative quantities of authentication requests from a single source and review HTTP/S metadata such as referer and user-agent fields for suspicious artifacts. Because no official detection logic or relationships were supplied, implementation should be environment-specific and tuned around normal authentication volumes, source reputation context, and expected web client behavior.
Likely telemetry
- Authentication request logs from identity-facing applications or services
- Network traffic metadata showing source, destination, volume, and request patterns
- Web server or reverse proxy logs containing HTTP/S referer fields
- Web server or reverse proxy logs containing user-agent strings
- Source reputation or threat intelligence context when available for adversary- or botnet-associated infrastructure
Detection direction
- Baseline normal authentication request rates by source to identify unusually large or iterative activity.
- Correlate repeated authentication requests from a single source with web metadata such as referer and user-agent values.
- Tune carefully for legitimate high-volume sources such as corporate proxies, monitoring systems, load testing, or shared egress infrastructure.
- Validate whether logs preserve the fields needed for investigation, especially source information and HTTP/S metadata.
- Use source reputation only as supporting context; do not rely on it as the sole detection condition.
Mitigation priorities
- Ensure identity-facing and web authentication services produce sufficient logs for request volume, source, and HTTP/S metadata review.
- Define triage procedures for suspected user-information probing, including when to block, rate-limit, or escalate for incident response review.
- Review authentication endpoint exposure and apply appropriate abuse controls such as rate limiting or request throttling where operationally suitable.
- Maintain SOC playbooks that distinguish suspicious probing from benign automation or shared-source traffic.
- Use this analytic as evidence in readiness discussions around identity monitoring, incident response, and compliance logging expectations.
Analyst notes and limits
This object is a detection analytic, not a technique description. Its strongest decision value is in validating whether the organization can observe and investigate suspicious authentication probing behavior using network and web metadata. No tactic, relationships, aliases, or official detection implementation were supplied, so the take should be treated as guidance for control and telemetry validation rather than a complete detection rule.
The supplied ATT&CK fields do not include official detection logic, related techniques, adversary relationships, impact claims, or active exploitation context. Local baselines and architecture are required to determine thresholds, expected traffic patterns, false positives, and response actions.
Analytic 1973
Monitor for suspicious network traffic that could be indicative of probing for user information, 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.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 74dff37fa659… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1973Open source URL
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.