AccessKey pair leak detection, AccessKey leak, credential leak, Security Center-Security Center(Security Center)-阿里云帮助中心

How it works

Scope

Detection platform: Only supports detecting AccessKey pair leaks in public source code on GitHub. Other code hosting platforms are not supported.
Detection targets: AccessKey pairs of Alibaba Cloud accounts (primary accounts) and RAM users, including both the AccessKey ID and AccessKey Secret.

Notification methods

Security Center uses different notification methods depending on whether the leaked AccessKey Secret (hereinafter referred to as SK) is still valid:

Important

A third party can exploit the AccessKey pair to gain control over all resources under your account only when both the AccessKey ID and AccessKey Secret are leaked.

Notification condition	Notification method
AccessKey ID is leaked, regardless of whether the AccessKey Secret is valid.	Alert on the AccessKey Leak Detection page
AccessKey Secret is leaked and still valid.	Voice call: Sent in real time to the configured recipients. Console pop-up: A pop-up message appears when you visit the Alibaba Cloud console homepage or most product consoles. Alert notification: Sent through the configured channels (internal message, email, or SMS).

Configure AccessKey leak alert notifications

Security Center enables AccessKey leak alert notifications by default. Alerts can be sent through SMS, voice calls, email, and internal messages.

Modify notification methods

Access the Security Center console - System Settings - Notifications. At the top of the left side of the page, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.
On the Email/Internal Message tab, find AccessKey Leak Detection and select the required Notification Method.

Note

AccessKey leaks pose high risks. To ensure timely notifications, we recommend selecting all notification methods. For more information, see Configure alert notifications.

Add notification recipients

By default, only account contacts receive notifications. To add other recipients, use one of the following methods:

SMS, email, and internal message:

On the Basic Receiving Management page, modify message recipients in the Security Message > Cloud Shield Security Information Notification section.

Note
After you modify message recipients here, the changes also apply to other notification items in Security Center, as well as to notification items for products such as Anti-DDoS and Web Application Firewall.

For more information, see Configure event alerts.
Voice call:

On the Voice Receiving Management page, modify message recipients in the Security Message > Account Security Alert section.

Handle AccessKey pair leak events

After you receive an AccessKey pair leak alert, it means the AK and SK information of your Alibaba Cloud account or RAM user has been exposed. Handle it by following these steps:

Step 1: Manually handle the leak

Security Center does not support automatic handling of AccessKey pair leak events. You must first complete the following operations externally:

Delete or hide the leaked content on GitHub: Contact the relevant personnel to delete or hide the files, repositories, or code that contain the AccessKey pair information.
Handle the leaked AccessKey in the RAM console: Delete or disable the leaked AccessKey and create a new one, ensuring that core business operations are not affected. For more information, see Delete an AccessKey pair for a RAM user and Disable an AccessKey pair for a RAM user.

Note the following when you handle a leaked AccessKey:
- The change takes effect immediately after you disable the AccessKey: After you disable an AccessKey pair in the RAM console, the change takes effect immediately. The AccessKey can no longer be used for API calls, which immediately blocks any operations performed with it.
- You may still receive alerts after you disable the AccessKey: After an AccessKey is disabled, calls made with it fail, but because the key record still exists, Security Center may continue to detect the leak risk and send alerts. If you confirm that the AccessKey is no longer in use, we recommend that you delete the AccessKey after disabling it to fully eliminate the alerts.
- Assess business impact and plan a rotation strategy: Before you disable or delete an AccessKey, check whether the key is still relied on by your business, for example, as credentials configured for a Kubernetes (K8s) cluster or other services. If the AccessKey is still in use, we recommend that you first create a new RAM user AccessKey, replace it in the relevant business configuration, and verify that the new key works as expected before you disable and delete the old AccessKey. This helps avoid impact on online services.
- Temporary control when rotation is not possible: If you cannot complete the AccessKey rotation for a specific reason, you can configure an access control policy (IP address whitelist) based on your business requirements to allow access only from specified business IP addresses, as a temporary mitigation measure.
  
  Note
  The IP address whitelist mentioned here refers to a network-side access control policy. It is different from the alert whitelist (the Add to whitelist handling method described in "Handle AccessKey pair leak events" in this topic), which is used to mark false positive events in the console. Do not confuse the two.

Step 2: Mark the handling status in the console

After you complete the manual handling, mark the status of the AccessKey alert event in the Security Center console:

Access the Security Center console - Risk Governance - AK Leak Detection.
Click Handle in the Actions column of the target event, select one of the following handling methods, and then click Handle Now.

Handling method	Applicable scenario
Manually Deleted	The leaked AccessKey is no longer in use and has been deleted.
Manually Disabled AccessKey Pair	The leaked AccessKey still needs to be used but must be temporarily disabled. After you select this method, you can re-enable the AccessKey in the RAM console. Note If the AccessKey has already been disabled in the RAM console, Security Center automatically syncs the disabled state, and the AccessKey leak event status changes to Manually Disabled.
Add to Whitelist	The event is a false positive or can be safely ignored. After you select this option, the status changes to Added to Whitelist and the event moves to the handled list. When you need to resume detection, go to the AccessKey pair leak details page from the handled list and remove the whitelist.

View AccessKey call records

By reviewing AccessKey call records, you can determine whether the leaked AccessKey was exploited by attackers and understand the scope of the impact. The following steps describe how to view AccessKey call events in chronological order through ActionTrail.

Note

To view the call records of an AccessKey accessing a specific cloud service, you can use the AccessKey audit feature in ActionTrail. For more information, see Query the logs of an AccessKey pair.

On the Security Center console AccessKey Leak Detection page, obtain the AccessKey ID that you want to query.
Log on to the ActionTrail console.
In the left-side navigation pane, choose Events > Event Query.
In the top navigation bar, select the region where you want to query events.
Set the query type to AccessKey ID, enter the AccessKey ID to query, and specify a time range.
View the list of events called by the AccessKey ID. Click View Details in the Actions column of the target event to view the detailed event records.

For more information about the parameters of management events, see Management event structure.

When you review the call records, use the following approach to investigate potential attacks and trace their source:
- Check whether the source is an internal IP address: If the source IP address of an AccessKey call is an Alibaba Cloud internal IP address, a cloud host may have been compromised and turned into a zombie. We recommend that you immediately check the security status of the related cloud host and strengthen host protection.
- Trace the creation of a malicious RAM user: If you suspect that an attacker used the leaked AccessKey to create a malicious RAM user, you can use the details in ActionTrail or the alert email (the abnormal AccessKey, IP address, and time) to confirm which AccessKey was used to create the RAM user through an API call, and determine whether the RAM user was created by console logon or by an API call.
- The alerted interface type may differ from the product you expect: The interface type shown in an abnormal AccessKey call alert (for example, Ecs:DescribeInstances) may differ from the product you expect (for example, OSS). Use the interface actually shown in the alert, and query the call records of the corresponding product in ActionTrail. Otherwise, you may check the logs of the wrong product and miss potential risks.
- Risk assessment boundary: If the call records show that the attacker only used API calls to query resource information (for example, only called Describe operations), this usually does not directly lead to further intrusion. You can use this to reasonably assess the impact of the leak.

Monitor for abnormal AccessKey calls

After you handle an AccessKey pair leak event, we recommend that you continuously monitor for abnormal AccessKey calls to prevent similar incidents, respond quickly when leaks occur, and minimize the impact.

Called interface field description

The called interface is the specific cloud service operation accessed through an API call using the AccessKey. The interface name uses the format {Product prefix}:{API name}, where:

Product prefix: Corresponds to an Alibaba Cloud product name. For example, Ecs maps to ECS, Oss maps to OSS, and Rds maps to RDS.
API name: Corresponds to a specific API operation. For example, DescribeRegions maps to querying available regions.

The following table lists common interface names and their corresponding products.

Interface name	Product	Operation description
Ecs:DescribeRegions	ECS	Query available regions
Oss:GetBucket	OSS	Obtain bucket information
Rds:DescribeDBInstances	RDS	Query the list of database instances

Detect abnormal AccessKey calls from an attacker's perspective

Based on security attack-and-defense experience and large models, Security Center can detect common abnormal AccessKey calls. For example, the IP address that calls the AccessKey has launched attacks recently, the IP address calls AccessKey pairs of multiple users in batches on the cloud, the called API is sensitive and the AccessKey has been leaked before. If an AccessKey pair is called from an IP address in an uncommon region to access a sensitive API, the system identifies the call as abnormal behavior and triggers an alert. If you confirm that an alert is triggered by normal business behavior, use the ActionTrail console to check the call records of the AccessKey pair. After you verify the call, set the alert status to False positive on the alert details page. You cannot configure trusted IP addresses for this feature.

Log on to Security Center console.
In the left-side navigation pane, choose Detection and Response > Alerts. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

Note
If you have activated Agentic SOC, select Agentic SOC > Manage > Alerts.
Set Alert Type to Malicious Process (Cloud Threat Detection) and check for any abnormal AccessKey call alerts.

Note
If an abnormal AccessKey call alert exists, view its details and promptly confirm whether the AccessKey call is a normal behavior.
(Optional) Configure alert notifications: go to System Configuration > Notification Settings, find Alert in the Notification Item column, and select your preferred methods.

Note
The Basic Edition supports only the internal message notification method.

Monitor for abnormal AccessKey calls by your Alibaba Cloud account

ActionTrail provides built-in alerts to monitor AccessKey calls by your Alibaba Cloud account and abnormal AccessKey calls. Enable the built-in alerts Abnormal Frequency of AccessKey Usage Alert and Root Account AccessKey Usage Detection in the ActionTrail console to receive notifications when abnormal AccessKey calls occur. For more information, see Query Insights events.

Detect abnormal AccessKey calls based on historical behavior

The Insights feature provided by ActionTrail analyzes AccessKey pairs with abnormal call rates based on historical behavior, helping you detect abnormal activities in a timely manner. For more information about how to enable and view Insights events, see Query Insights events in the ActionTrail console.

Recommendations

Do not use the AccessKey pair of your Alibaba Cloud account (primary account). For more information, see Remediate potentially compromised AccessKey pairs.
Avoid hard-coding AccessKey information in your code. You can manage AccessKey pairs by configuring environment variables. For more information, see Best practices to prevent AccessKey pair leaks.
Use private GitHub repositories to manage code, or set up an internal code hosting system within your enterprise to prevent source code and sensitive information leaks.

FAQ

Does testing file uploads locally with a third-party SDK cause AccessKey leaks?

Using a third-party SDK to test file uploads locally does not directly cause an AccessKey leak. AccessKey leaks are usually caused by hard-coding the AccessKey in plaintext in application code or a public code repository, where it is later obtained by others.

We recommend that you take the following measures:

Delete the leaked AccessKey and the corresponding RAM user.
Rotate your AccessKey pairs on a regular basis.
Manage credentials such as AccessKey pairs by using environment variables instead of storing them in plaintext in your code.