In this series of articles, we will explore TTP tactics based on the Mitre ATT&CK framework, focusing on how to develop effective detection rules in different environments (cloud, enterprise, ICS) and scenarios. We will discuss practical attack scenarios, detection, response, and optimization.
This is the first article in the series, primarily focusing on how to write detection rules for “T1555.006 Cloud Secrets Management Stores“, helping security teams enhance their defense capabilities in cloud environments.
Introduction
The Mitre ATT&CK framework divides the attack process into multiple stages, from Initial Access, Information Gathering, Privilege Escalation to Data Exfiltration. Each stage includes multiple tactics and techniques.
Specifically, “In cloud environments, attackers may obtain cloud keys through various methods and use them for unauthorized access, further advancing the attack.”
Category
Tactic Name: Key Access
Applicable Platforms: IaaS, Linux, Windows, macOS
Scenario
Cloud Key Storage (T1555.006): Attackers may obtain keys from cloud-native secret management libraries. Cloud key storage is used to securely manage and access keys, passwords, and other sensitive information in cloud environments.
Detection and Response
Case 1
Taking Azure Key Vault as an example, the following rule can detect whether a vault policy has been erroneously modified to be readable by a certain user group (low-privileged user group).
title: KeyVault Access Policy Changed to Low-Privileged or Open Permissions
id: e54b3f3b-dccd-4ba9-bd8d-7c5f8a42b6f1
description: Detects changes to KeyVault access policies where objectId or applicationId is modified to low-privileged or open access.
references:
- https://docs.microsoft.com/en-us/azure/key-vault/general/overview
logsource:
service: azure
product: azure
detection:
selection:
OperationName: 'Microsoft.KeyVault/vaults/accessPolicies/write'
filter_low_privilege_object:
- RequestBody|contains: '"objectId":"00000000-0000-0000-0000-000000000000"' # replace with any specific low-privileged object ID
- RequestBody|contains: '"applicationId":"*"'
- RequestBody|contains: '"applicationId":"00000000-0000-0000-0000-000000000000"' # replace with any specific low-privileged app ID
condition: selection and filter_low_privilege_object
fields:
- TimeGenerated
- OperationName
- RequestBody
- Caller
- ResultDescription
falsepositives:
- Administrative changes where low-privilege access is expected (verify with security team)
level: high
tags:
- attack.defense_evasion
- attack.privilege_escalation
- attack.t1555.006
Log Source: AKV Activity Log
Alert Level: High
False Positives: Administrative changes where low-privileged access is expected (verify with the security team)
Case 2
Taking AWS Secrets Manager as an example, detecting access to secrets from uncommon IP addresses using CloudTrail logs.
title: Detection of Access Key Usage with AWS Secrets Manager
id: 123e4567-e89b-12d3-a456-426614174006
description: Detects AWS Secrets Manager access events and flags access keys for further analysis if they have not been used in the past 90 days. This rule helps identify potentially suspicious activity by capturing access events with specific keys.
logsource:
category: cloud
service: aws
product: cloudtrail
detection:
selection_secrets_manager_access:
eventSource: "secretsmanager.amazonaws.com"
eventName: "GetSecretValue"
condition: selection_secrets_manager_access
fields:
- sourceIPAddress
- userIdentity.arn
- userIdentity.accessKeyId
- eventTime
- eventName
- eventSource
falsepositives:
- Admins accessing from a new IP.
- Legitimate activity from a newly provisioned service or newly rotated key.
level: high
tags:
- attack.initial_access
- attack.credential_access
- attack.t1552.001
Log Source: AWS CloudTrail
Alert Level: High
False Positives:
- Admins accessing with a new key.
- Legitimate activity from a newly provisioned service or newly rotated key.
Response Steps
Analyze the reason for the key access, check for related ticket records, and determine if it was a mistake or malicious behavior, and assess the impact scope.
Analyze the entity that triggered the policy change. Was it caused by a configuration error, human error, or external attack?
Rule Conversion
We recommend using sigma-convert (https://github.com/marirs/sigma-convert), or the online tool sigconverter (https://sigconverter.io/), to convert Sigma rules into corresponding SIEM search queries. For example:
eventSource="secretsmanager.amazonaws.com" eventName="GetSecretValue"
| table sourceIPAddress,userIdentity.arn,userIdentity.accessKeyId,eventTime,eventName,eventSource
Disclaimer
The detection rules mentioned in this article are for learning and discussion purposes only. The sample rules and guidance provided do not constitute formal advice or solutions. Since each enterprise’s security environment and needs vary, we strongly recommend that companies modify these rules specifically and conduct thorough testing based on their actual circumstances and environments to ensure they meet your organization’s specific needs and security requirements.
We assume no responsibility for any issues or losses that may arise from the use or implementation of these rules.
References
Mitre ATT&CK for Cloud: https://attack.mitre.org/matrices/enterprise/cloud/
AWS Well-Architected Framework: https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html introduces security best practices to help understand how to prevent and detect cloud key leakage.
Azure Security Center: https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoft.azuresecuritycenter?tab=overview provides security advice for Azure environments, which can be used to optimize detection rules.
Google Cloud Security Best Practices: https://cloud.google.com/security/best-practices provides security practices for Google Cloud, offering references for multi-cloud environments.
- Alibaba Cloud AK Leakage Detection: https://help.aliyun.com/zh/security-center/user-guide/detection-of-accesskey-pair-leaks
Follow SecLink Security Space for more exciting content.
