Last reviewed:
T1685.002 covers the disablement or modification of cloud native logging services to impair defense through audit log gaps: stopping CloudTrail, deleting Azure activity sinks, or modifying GCP audit sinks. It is a critical post compromise move for attackers seeking to hide their operational trail across IaaS and SaaS platforms. DCV addresses this technique by mapping the prerequisite permissions and the specific service state changes that precede a total quiet period. Detection instrumentation must be established before the first sign of evasion appears.
An adversary may disable or modify cloud logging capabilities and integrations to limit what data is collected on their activities and avoid detection. Cloud environments allow for collection and analysis of audit and application logs that provide insight into what activities a user does within the environment. If an adversary has sufficient permissions, they can disable or modify logging to avoid detection of their activities.
For example, in AWS an adversary may disable CloudWatch/CloudTrail integrations prior to conducting further malicious activity. They may alternatively tamper with logging functionality, for example, by removing any associated SNS topics, disabling multi-region logging, or disabling settings that validate and/or encrypt log files. In Office 365, an adversary may disable logging on mail collection activities for specific users by using the Set-MailboxAuditBypassAssociation cmdlet, by disabling M365 Advanced Auditing for the user, or by downgrading the user’s license from an Enterprise E5 to an Enterprise E3 license.
Platforms: IaaS, SaaS, Identity Provider, Office Suite.
DCV does not currently ship a cloud-audit-log finding mapped directly to T1685.002. The technique earns a library page because a13e research cites it. Detection sits downstream, on the exploitation step the technique enables.
CloudSigma does not currently ship a stand-alone rule that fires on T1685.002 in isolation. Generate a starting-point rule from the CVE, vulnerability disclosure, or threat-research blog post that exercises this technique, then pair it with SIEM-side correlation before enabling in production.
High-fidelity detection of T1685.002 requires correlation
across multiple events. For example, a credential-validation call
followed by a reconnaissance chain (List* /
Describe*) within a short window from an unfamiliar
source. A single-event Sigma rule on
GetCallerIdentity alone fires constantly on
legitimate CLI, SDK and CI/CD activity.
Where you have a specific advisory, vulnerability disclosure or blog post that exercises T1685.002-style abuse, CloudSigma can generate a starting-point rule from that input. You then deploy it in your SIEM and combine it with the SIEM's native correlation features (timeframe joins across users, source-IP anomalies, impossible-travel checks). For T1685.002 specifically the generated rule is rarely sufficient on its own; pair it with the SIEM-side correlation logic before enabling in production.
T1685.002 covers the disablement or modification of cloud native logging services to impair defense through audit log gaps: stopping CloudTrail, deleting Azure activity sinks, or modifying GCP audit sinks. It is a critical post compromise move for attackers seeking to hide their operational trail across IaaS and SaaS platforms. DCV addresses this technique by mapping the prerequisite permissions and the specific service state changes that precede a total quiet period. Detection instrumentation must be established before the first sign of evasion appears.
T1685.002 has no cloud-audit-log signal of its own; DCV does not currently ship a finding mapped directly to it. The technique earns a library page because a13e research cites it. Detection sits downstream, on the exploitation step the technique enables (see Related techniques).
T1685.002 is part of MITRE ATT&CK TA0005 Defense Evasion: How adversaries avoid being detected by security controls.
T1685.002 requires multi-event correlation that exceeds a single Sigma rule's structure. CloudSigma can generate a starting-point rule from a CVE, vulnerability disclosure, or threat-research blog post that exercises T1685.002-style abuse; pair it with SIEM-side correlation logic before enabling in production.