A Tencent Cloud API key pair lets whoever holds it call the Tencent Cloud APIs as the user it belongs to. The pair is a SecretId and a SecretKey, and together they sign requests. The user might be your root account, a sub-user with broad rights or a service account that manages virtual machines, databases, object storage and DNS. Calls are billed to your account, and an attacker can start resources, read data or remove protection in any region the user can reach. Disable the exposed pair first, then find out what it was used for.
Check your GitHub account for leaked secrets — free
- Provider
- Tencent Cloud
- Severity
- Critical
- Impact
- Cloud infrastructure access
- Checked live by LeakWatch
- No
What a Tencent Cloud Secret ID looks like
A Tencent Cloud SecretId is a fixed prefix followed by a random body. The whole value is 36 characters long, and the SecretKey that goes with it is a separate, longer string:
AKID…XXXX SecretId (masked)
The AKID prefix is specific to Tencent Cloud, so a hit is rarely a false alarm. The SecretId does not sign requests by itself, which is why a leak of only the ID is less dangerous than a leak of both. Still, the two almost always sit in the same file, so search for the SecretKey before you decide how serious the incident is.
How Tencent Cloud Secret IDs get leaked
- Keys in configuration files. A
.envfile, a deployment config or a credentials file for a Tencent Cloud SDK, committed with the rest of the project. - Hard-coded clients. A script or a Serverless function that creates an API client with the keys written in the source, then pushed to a public repository.
- Infrastructure as code. Terraform or Ansible variables that set the keys directly instead of reading them from a secret store.
- Build logs. A pipeline step that prints its environment, or a failing request that echoes the signed parameters.
- Tickets and screenshots. A console or code sample pasted into a support request or a forum post with the values visible.
What to do in the first hour
- Identify the owner. In the Cloud Access Management console, find the user that owns the SecretId. Note whether it is the root account, a sub-user or a collaborator, because that decides how much access is at stake.
- Create a replacement key. Create a new key for the same user and deploy it to your secret store or environment. Confirm your services work with it before you remove the old one.
- Disable the exposed key. Disabling stops the key from working straight away and can be reversed, so use it while you check dependencies. Delete it once you are sure nothing still needs it.
- Review the audit log. Open CloudAudit, Tencent Cloud’s audit product, and search for requests made with the exposed SecretId since the exposure. Look for requests from unknown IP addresses, new instances, new users, new keys and changes to firewall rules or buckets.
- Look for new access. An attacker often adds a sub-user, a second key or a new policy. Review the users, their policies and their keys, and remove anything you cannot account for.
- Rotate the SecretKey too. If the file held the SecretKey, the pair is compromised. Replace both values as one step.
- Clean the repository. Remove the values and rewrite history if you need to. See I accidentally pushed an API key to GitHub and Deep scan your whole git history.
Not sure what else leaked? Run a free scan.
Revoke it at Tencent Cloud
API keys are managed in the Cloud Access Management console. Open the access key page, sign in with a user that can manage the owner of the key, and find the key by its SecretId. Disable it first, then delete it when nothing depends on it. Keys belong to one user, so check the right account before you act. Tencent Cloud also lets you manage keys for sub-users, and the same screen shows the state of each one. If the page or its labels differ from this description, look for the API key section of the user, and follow Tencent Cloud’s documentation for the current steps.
How LeakWatch detects it
The rule is called Tencent Cloud Secret ID. It looks for the literal AKID prefix, which is case sensitive, followed by exactly 32 letters and digits, with a word boundary on each side. The match needs no nearby context, and a value one character shorter or longer is not reported. The severity is critical. This type is not checked live: LeakWatch does not send any request to Tencent Cloud with the value it found. A separate rule looks for the SecretKey near the SecretId, so a file that holds both is reported with the more serious finding.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Is the SecretId secret on its own?
It does not sign requests, so it is less dangerous than the SecretKey. Still, treat it as exposed, because it identifies your account and it is rarely found without its partner.
If I disable the key, is the incident over?
No. Disabling stops new requests, but you still need to check the audit log for what happened while the key was live, and to look for any new users or keys that were created in that time.
Can I use a sub-user key instead of the root account key?
Yes, and you should. Give each service its own user with only the permissions it needs, so that a leak limits the damage to that service.