An AccessKey pair is a credential used to authenticate your identity when you call Alibaba Cloud APIs. A leaked AccessKey pair can compromise every resource under your account, leading to unexpected charges, ransom demands, and—in severe cases—harm to Alibaba Cloud or other users. Follow these steps to respond to a suspected leak and reduce the risk of credential misuse.
Alibaba Cloud security measures
Alibaba Cloud continuously works to strengthen cloud service security and help you protect your account. If Alibaba Cloud detects that your AccessKey pair has been publicly exposed—based on external intelligence—it promptly notifies you through your registered contact channels. To safeguard your business and data, Alibaba Cloud also applies restrictive protection to the compromised AccessKey pair, blocking it from calling high-risk APIs for certain cloud services. For details, see Restrictive protection for AccessKeys.
Monitor notifications sent via text message, email, and in-console messages. Respond promptly based on your business needs and watch for unusual activity involving your cloud resources to avoid service disruption.
Alibaba Cloud cannot monitor the security status of all your AccessKey pairs. Under the shared responsibility model, AccessKey pairs are part of your account’s identity credentials, and you are fully responsible for their security. Stay vigilant.
What should I do if an AccessKey leak causes a RAM user to be unable to log on or the account is frozen?
When Alibaba Cloud detects that an AccessKey is at risk of leakage, the security system automatically triggers protective mechanisms that may restrict the associated RAM user from logging on to the console. You may encounter error messages such as Authentication.Block.AccountFrozen or "The current account is not allowed to log on."
To resolve this issue:
Log on to the RAM console with the Alibaba Cloud account (root account). Immediately disable or delete the leaked AccessKey, then create a new AccessKey to complete the rotation. Merely disabling the AccessKey may not be sufficient to lift the restriction — you must delete or rotate it.
After completing AccessKey handling, if the RAM user still cannot log on, submit a ticket to request removal of the security risk control restrictions.
Manual response steps for suspected leaks of an Alibaba Cloud account (root account) AccessKey
If the AccessKey is no longer in use, go to the AccessKey management page and disable or delete it immediately.
If the AccessKey is still in use, go to the AccessKey management page and rotate it.
Create a new AccessKey and securely store the AccessKey secret. Replace the old AccessKey with the new one in your applications. After confirming everything works correctly, disable and delete the old AccessKey.
Manual response steps for suspected leaks of a RAM user AccessKey
If the AccessKey is no longer in use, go to the Resource Access Management (RAM) console and disable or delete the RAM user’s AccessKey. For instructions, see Disable a RAM user's AccessKey and Delete a RAM user's AccessKey.
If the AccessKey is in use and can be rotated immediately, rotate it as soon as possible.
Create a new AccessKey and securely store the AccessKey secret. Replace the old AccessKey with the new one in your applications. After confirming normal operation, disable and delete the old AccessKey. For instructions, see Rotate a RAM user's AccessKey.
If the AccessKey is in use but cannot be rotated immediately, follow the steps below to limit potential damage. Complete rotation as soon as possible afterward.
Step 1: Reduce AccessKey permissions
Identify your business requirements and, without disrupting current operations, quickly reduce permissions for the suspected AccessKey pair. Restrict high-risk permissions to minimize potential damage to your business and billing. Keep this restrictive policy in place until you have disabled and deleted the AccessKey pair.
Recommended high-risk permissions to restrict: preventing the RAM user from creating RAM users or granting permissions in RAM, blocking release of ECS, RDS, OSS, or SLS resources, and disabling SMS sending.
The following example shows a custom policy that denies high-risk actions. Evaluate its impact and adjust based on your business needs.
{ "Version": "1", "Statement": [ { "Effect": "Deny", "Action": [ "ram:AddUserToGroup", "ram:AttachPolicyToGroup", "ram:AttachPolicyToRole", "ram:AttachPolicyToUser", "ram:ChangePassword", "ram:CreateAccessKey", "ram:CreateLoginProfile", "ram:CreatePolicyVersion", "ram:CreateRole", "ram:CreateUser", "ram:DetachPolicyFromUser", "ram:PassRole", "ram:SetDefaultPolicyVersion", "ram:UpdateAccessKey", "ram:SetPasswordPolicy", "ram:UpdateRole", "ram:UpdateLoginProfile", "ram:UpdateUser" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "ecs:DeleteInstance", "ecs:DeleteInstances", "ecs:DeregisterManagedInstance", "ecs:ReleaseDedicatedHost" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "rds:DeleteAccount", "rds:DeleteDatabase", "rds:DeleteDBInstance", "rds:DestroyDBInstance" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "oss:DeleteBucket", "oss:DeleteObject", "oss:PutBucketAcl", "oss:PutBucketPolicy" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "log:DeleteLogStore", "log:DeleteProject", "log:PutProjectPolicy", "log:DeleteProjectPolicy" ], "Resource": "*" }, { "Effect": "Deny", "Action": [ "dysms:CreateProductNew", "dysms:CreateSmsTemplateNew", "dysms:AddSmsTemplate", "dysms:SendSms", "dysms:SendBatchSms" ], "Resource": "*" } ] }For instructions, see Create a custom policy and Manage permissions for RAM users.
Clearly define the minimum permissions required for the AccessKey and remove all unnecessary ones.
Step 2: Enable MFA for the RAM user
As a best practice, enable multi-factor authentication (MFA) for all RAM users under your Alibaba Cloud account (root account) who access the console.
Require MFA for RAM users logging on to the console under the root account.
For instructions, see Manage RAM user logon settings.
Bind an MFA device to the user.
For instructions, see Bind an MFA device to a RAM user.
Step 3: Check for abnormal AccessKey operations
Review the AccessKey pair for unusual activity and investigate whether other identities may also be compromised. Focus on abnormal source IP addresses and resource creation or deletion actions outside normal business operations.
Dangerous operations to investigate during the suspected leak period:
Identity and permission changes: creating RAM users (
CreateUser), creating AccessKeys (CreateAccessKey), attaching policies (AttachPolicyToUser), creating roles (CreateRole), and enabling console logon (CreateLoginProfile). Events such asCreateLoginProfile,AttachPolicyToUser, andCreateUsertypically indicate that an attacker is creating backdoor accounts or escalating privileges. Pay close attention to the source IP address and UserAgent of these API calls.Resource deletion or release: deleting ECS instances (
DeleteInstance), deleting RDS instances (DeleteDBInstance), and deleting OSS buckets (DeleteBucket).Data exfiltration actions: modifying OSS bucket ACLs (
PutBucketAcl) or bucket policies (PutBucketPolicy).Abnormal API behavior: large volumes of API calls in a short time, operations from unfamiliar IP addresses or regions, or batch operations outside normal working hours.
To check: In the Resource Access Management (RAM) console, find the RAM user’s AccessKey list and review operation records. Alternatively, go to the AccessKey audit page in the ActionTrail console and enter the AccessKey ID to query its operation history.
In addition to ActionTrail, you can log on to the Security Center console to view AccessKey leak alert details, including the names of RAM users that were maliciously created, abnormal calling IP addresses, and other relevant information.
ActionTrail's AccessKey audit feature shows all API calls made by a specific AccessKey pair over the past 90 days, including call time, action name, source IP address, and accessed cloud service. For instructions, see Monitor AccessKey usage with ActionTrail.
NoteFor data-related operations not covered by ActionTrail—such as those in OSS or SLS—use the respective cloud service’s logging features to investigate.
To confirm the scope of the leak: check the notifications sent via security email, text message, or in-console message to identify the specific leaked AccessKey ID. If the notification mentions only one AccessKey and no other alerts have been raised, typically only that specific AccessKey has been leaked.
Also check whether other RAM users or AccessKey pairs show signs of abnormal activity beyond the known compromised key. If you find suspicious behavior, confirm with relevant personnel whether the actions were authorized. If a leak is suspected, take the following actions:
If the RAM user must remain active, immediately change its password and enable multi-factor authentication (MFA).
If the RAM user was not legitimately created or is no longer needed, delete it. Deleted RAM users go to the recycle bin. Monitor your business for impact, and restore the user quickly if needed.
For abnormal AccessKey activity, restrict permissions as described above, then rotate the key.
Step 4: Check for abnormal charges
In Expenses and Costs , review your billing for unexpected charges. Based on findings from the previous step, apply targeted protective measures for affected services.
Simply deleting maliciously created RAM users is not sufficient to eliminate the leak risk. The core risk is that the AccessKey of the Alibaba Cloud account (root account) or a high-privilege RAM user has already been leaked. An attacker can use the leaked AccessKey to continuously create new users or escalate privileges. You must rotate the AccessKey — create a new one, replace the old one in all your applications, then disable and delete the old AccessKey. You must also investigate the leak path, such as source code, configuration files, and server security vulnerabilities. Otherwise, the risk persists.
Why is my AccessKey detected as leaked even though it is stored in a private repository, Nacos, or offline database?
Even when you believe your AccessKey is stored securely, it can still be exposed through the following common paths:
Code repositories: If a private repository was previously public, has been forked, or a collaborator uploaded the code to another location, the AccessKey may still be detected by scanning services.
Configuration centers (such as Nacos): If the configuration center lacks proper access control, has known vulnerabilities, or the server has been compromised, AccessKeys stored in plain text may be stolen.
Offline storage: If the application or script that reads the AccessKey connects to the internet to call APIs, the key may be intercepted during transmission or recorded in logs.
Application vulnerabilities: Remote code execution (RCE) or arbitrary file read vulnerabilities can allow attackers to steal AccessKeys from configuration files on the server.
To prevent future leaks:
Use the Credentials tool to manage credentials instead of hard-coding AccessKeys.
Configure network access restrictions (IP allowlists) for AccessKeys.
Avoid embedding AccessKeys directly in source code or configuration files.
Long-term AccessKey leak prevention strategy
See Best practices for using access credentials to call Alibaba Cloud OpenAPI.
Can I request emergency disabling of an AccessKey that belongs to a different account?
Due to privacy protection and permission isolation policies, Alibaba Cloud cannot directly disable an AccessKey that does not belong to your currently logged-on account based on a leak report. Recommended actions:
If you know which account the AccessKey belongs to, contact the account holder and ask them to handle it.
If you have access to the account associated with the AccessKey, use the
DeleteAccessKeyAPI or the RAM console to delete the key yourself.For AccessKeys belonging to other accounts that you cannot access, coordinate handling through legal or security compliance channels.