AN1996: Analytic 1996
Once adversaries leverage serverless functions as infrastructure (ex: for command and control), it may be possible to look for unique characteristics associated with adversary software, if known.[1] Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle.
Analyst context for executives and security teams
AN1996 highlights a hard-to-see infrastructure problem: adversaries may use serverless functions as part of their infrastructure, such as command-and-control support, and much of that activity can occur outside the target organization’s direct visibility. For leaders, the practical issue is not that this analytic provides a ready-made alert; it signals that some adversary infrastructure detection depends on external intelligence, lifecycle correlation, and evidence from adjacent activity rather than internal endpoint or network logs alone.
Executive priority
Treat this as a visibility and readiness question. Security leaders should ask whether threat intelligence, managed detection, and incident response processes can identify suspicious serverless-backed infrastructure when internal telemetry is limited. This matters for incident decision-making because lack of direct visibility can delay understanding of adversary infrastructure, scope, and related activity. It also affects budget and control prioritization: teams may need external intelligence sources, infrastructure hunting workflows, and clear handoffs between threat intelligence, SOC, and IR rather than relying only on standard internal detections.
Technical view
The supplied ATT&CK object is a detection analytic for PRE-stage visibility and does not include a formal detection rule or related ATT&CK relationships. SOC and detection teams should validate whether they can correlate known or suspected adversary software characteristics with infrastructure indicators, including serverless-function-hosted endpoints when such indicators are available. Because MITRE notes that much of the activity may be outside the target organization’s visibility, detection should focus on related lifecycle stages and correlation with available intelligence rather than expecting a single high-confidence internal signal.
Likely telemetry
- Threat intelligence reporting on adversary infrastructure characteristics
- Infrastructure hunting results, including domains, URLs, hosting patterns, and serverless-backed endpoints when known
- DNS and proxy logs for organizational systems that may contact identified infrastructure
- Network security logs showing connections to suspicious or intelligence-linked infrastructure
- Incident response case evidence tying internal activity to external infrastructure indicators
Detection direction
- Validate whether the SOC has a process to ingest and operationalize external infrastructure intelligence, including the cited class of infrastructure hunting research.
- Do not treat absence of internal alerts as proof of absence; MITRE explicitly notes that much of this behavior may occur outside target visibility.
- Tune detections around correlation: internal DNS, proxy, or network contact with intelligence-linked infrastructure may be more useful than attempting to detect serverless infrastructure creation directly.
- Review false positives carefully because serverless platforms and hosted endpoints are widely used for legitimate purposes; suspiciousness should depend on known adversary software characteristics or related lifecycle evidence.
- Use related-stage detections where available, since the ATT&CK object states detection may need to focus on other parts of the adversary lifecycle.
Mitigation priorities
- Prioritize visibility architecture first: confirm DNS, proxy, network, and threat intelligence data are available for correlation during investigations.
- Establish a threat intelligence workflow for infrastructure indicators, including confidence, expiration, and analyst review before blocking or escalation.
- Prepare IR playbooks for cases where adversary infrastructure is externally hosted and only indirectly visible through endpoint, DNS, proxy, or network evidence.
- Where policy permits, apply controlled blocking or monitoring for validated malicious or suspicious infrastructure indicators, while accounting for legitimate serverless usage.
- Document detection limitations for audit and risk discussions so leadership understands where internal telemetry cannot directly observe external adversary infrastructure.
Analyst notes and limits
This object is best understood as a detection strategy note rather than a complete analytic. The key defensive value is recognizing that adversary use of serverless functions as infrastructure may require external infrastructure research and lifecycle correlation. The only cited source is ThreatConnect’s infrastructure research and hunting article, and no ATT&CK relationships were supplied to connect this analytic to specific techniques, software, groups, or campaigns.
Official detection content is not provided, tactics are not specified, and the only listed platform is PRE. No relationship context was supplied. This take therefore cannot assert active exploitation, attribution, specific cloud providers, customer exposure, or guaranteed detection coverage. Local telemetry, intelligence sources, and investigation evidence are required to determine relevance in a specific environment.
Analytic 1996
Once adversaries leverage serverless functions as infrastructure (ex: for command and control), it may be possible to look for unique characteristics associated with adversary software, if known.[1] Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle.
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 | 45b413bc1e1f… |
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]
ThreatConnect Infrastructure Dec 2020
ThreatConnect. (2020, December 15). Infrastructure Research and Hunting: Boiling the Domain Ocean. Retrieved October 12, 2021.
Open source URL -
[2]
mitre-attack AN1996Open 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.