AN1961: Analytic 1961
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
AN1961 matters because adversaries may use serverless functions as part of their infrastructure, such as command-and-control infrastructure, in ways that often sit outside a victim organization’s direct visibility. For leaders, the practical issue is not that this analytic guarantees detection, but that cloud-hosted, ephemeral infrastructure can reduce the value of traditional perimeter-focused monitoring and requires stronger threat intelligence, lifecycle-based detection, and incident response assumptions.
Executive priority
Treat this as a visibility and preparedness issue. Security leaders should ask whether the organization can recognize suspicious use of external serverless infrastructure through threat intelligence, DNS/proxy/network observations, and related adversary lifecycle signals. Because the ATT&CK description notes that much of the activity may occur outside the target organization’s visibility, investment decisions should prioritize evidence collection and response playbooks around observable interactions rather than assuming direct insight into the adversary-controlled serverless environment.
Technical view
This analytic is scoped to PRE and has no supplied tactic or formal detection logic. SOC and detection engineering teams should validate whether they can correlate known or suspected adversary infrastructure characteristics with locally visible events, especially outbound connections, DNS lookups, proxy records, and threat intelligence matches. IR teams should avoid over-relying on direct telemetry from the adversary’s serverless functions and instead focus on related lifecycle evidence that may be visible inside the environment.
Likely telemetry
- Threat intelligence indicators and infrastructure characteristics from vetted sources
- DNS query and resolution logs
- Proxy, secure web gateway, or egress web request logs
- Firewall or network egress metadata
- Endpoint or workload network connection records where available
Detection direction
- Validate whether detections can use known unique characteristics of adversary software or infrastructure without assuming direct access to serverless provider-side telemetry.
- Tune correlation around outbound communication patterns and infrastructure intelligence rather than single indicators alone, since serverless infrastructure can be transient or shared.
- Account for false positives from legitimate cloud and serverless services used by business applications.
- Use related lifecycle detections to compensate for the stated visibility gap; this object provides no standalone detection logic.
- Document which telemetry sources are actually retained and searchable during incident response.
Mitigation priorities
- Improve egress visibility and logging for DNS, web, proxy, and network connections.
- Maintain a vetted threat intelligence process for infrastructure characteristics relevant to investigations.
- Define IR playbooks for suspicious external cloud or serverless infrastructure communications, including evidence preservation and scoping steps.
- Review allowlisting, egress policy, and cloud access governance where business operations permit.
- Use this analytic to identify monitoring gaps rather than to claim prevention or complete detection coverage.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique, and includes no relationships, no tactic mapping, and no official detection implementation. The key decision value is the visibility limitation: defenders may need to detect interactions with adversary infrastructure indirectly through local telemetry and related lifecycle activity.
Assessment is limited to the supplied ATT&CK fields and one external reference. No active exploitation, attribution, affected vendor, guaranteed detection method, or customer exposure can be inferred. Local environment architecture, logging coverage, and threat intelligence quality are required to determine practical coverage.
Analytic 1961
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 | 060e6236b904… |
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 AN1961Open 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.