Respond to a Suspected Compromise

Pause and identify the exposed authority

A suspected compromise is stressful, and the wrong hurried action can add to the loss. Begin by identifying what may have been exposed: a signing secret, a permission or a custodial account. These cases can overlap, but they do not have identical remedies. This lesson is a response framework and explains when a generic instruction such as change your password is insufficient.

Education only. Crypto assets can lose substantial value or become worthless. No lesson requires buying an asset, depositing money or sharing real passwords, private keys or recovery words.

Stop interacting with the suspicious site or requester. Preserve useful non-secret evidence, including the message, time, network, transaction IDs and the action you remember approving. Do not post recovery words or full private account information in a public help request. Use a clean trusted route to verified documentation and support.

Ask three diagnostic questions. Was signing material revealed or entered into an untrusted place? Was an unwanted contract permission or signature granted? Was a provider login, email or authentication route compromised? If uncertain, state that uncertainty and consider whether broader authority may be exposed. An unexpected transfer can be caused by different mechanisms; a transaction ID alone does not always reveal the original cause. Diagnosis helps avoid applying a narrow remedy to a wider problem.

Write a short incident timeline before changing unrelated settings. Record what was clicked or signed, what device was used, which account and network were involved, and what remains uncertain. Do not wait for perfect certainty before ending contact with the suspicious requester. The timeline helps genuine support understand the situation without receiving secrets.

Open diagram at original size ↗

Read diagram as text

Pause and diagnose first.

Leaked signing secret: fresh independent authority and a clean environment. Unwanted permission: verified scope review and cancellation. Provider account breach: official containment and recovery-chain security.

The diagram is a response map, not a recovery guarantee. Suspected sweepers make blindly adding fee funds unsafe.

Copied keys require fresh independent authority

If a private key or recovery phrase is compromised, treat the old authority as unsafe. Changing the wallet application's password does not remove the attacker's ability to recreate it. A new account derived from the same exposed recovery material may also remain within the attacker's reach. An independent secure wallet requires fresh authority created through a trusted process in a clean environment.

Whether remaining assets can be moved safely depends on the network, the available funds, active attacker behaviour and the device's condition. A malware-infected device can compromise new material too. Do not present a universal rescue sequence as guaranteed. Follow verified wallet guidance and seek qualified assistance through independently checked channels where the situation is complex. Some losses cannot be reversed, even when a new wallet is secured correctly.

A fresh address is not always fresh authority. Many addresses derive from one recovery root. If that root is exposed, moving into another account generated from it can leave the attacker able to sign again. A new provider password also does not change an independent on-chain key.

A clean environment matters because creating new secrets on a compromised device can expose them immediately. Follow the genuine wallet's incident guidance and preserve the only remaining access while assessing the problem. A rescue transaction can be complex, especially where an automated attacker races it. This course teaches diagnosis and boundaries rather than a universal click-by-click recovery recipe.

Permissions logins and service breaches

If the known issue is an unwanted allowance and signing secrets remain secure, a verified revocation may reduce that spender's future authority. Inspect the correct token, spender, network and account. Some signed orders or permissions have different cancellation mechanisms, so a generic token allowance change may be incomplete. Check for additional unauthorised activity rather than assuming one visible approval is the only issue.

For a custodial account breach, contact the provider through its official route, secure associated email and authentication methods, revoke unfamiliar sessions and review withdrawals under the service's procedures. Freezing a compromised service account may be useful if the provider offers it, but no procedure guarantees recovery. Preserve relevant records for the provider and appropriate authorities. A service-password reset addresses a different layer from a self-custody key leak.

Match diagnosis to response

For a provider breach, reach the genuine service through a saved route and report the suspected unauthorised activity. Review active sessions, API keys if used, email access, authentication and withdrawal settings through the provider's documented process. A compromised email can undo a password change by enabling another reset.

Do not feed an automated sweeper

An automated sweeper can watch a compromised address and rapidly transfer newly arriving assets, including funds added to pay network fees. A well-intended instruction to add a little gas can therefore feed the attacker. Moving assets from a compromised address may require specialised transaction handling and careful assessment rather than ordinary wallet clicks.

Do not deposit more money into a suspected compromised address to test it or pay an unknown rescuer. Verified wallet incident guidance specifically warns about this pattern. If a rescue depends on advanced tools you do not understand, stop and obtain trustworthy technical guidance without disclosing signing secrets to unsolicited contacts. An apparent emergency does not make an unknown helper safe.

Review the device, downloads, email recovery, active sessions and related accounts. A new wallet does not repair a compromised computer or a weak service recovery chain. Record what happened, what action was taken, what remains uncertain and which evidence was preserved. Reports to local authorities or regulators depend on the jurisdiction and incident; use official channels rather than numbers supplied by the attacker.

Be wary of anyone guaranteeing retrieval of funds for an advance fee. Blockchain visibility can help document a transfer without making it reversible. Recovery agents may invent authority they do not possess. A good incident record can support legitimate investigation and prevent repeated mistakes even when recovery is unavailable. After immediate containment, review the original failure mechanism and update the safety routine without publishing sensitive information.

Maintain a simple record with four fields: observed event, verified source, action taken and unresolved question. Separate confirmed facts from suspicions. For example, a transaction receipt can show that a spender moved a token, while the original way the attacker obtained that permission may still be unknown.

Keep personal records securely and redact them before sharing. Reporting can support an investigation without guaranteeing recovery. After immediate containment, change the specific process that failed: a saved download source, a verification pause, a permission record or an account recovery dependency. This turns the incident review into a useful safety habit.

Everyday example

What to remember

Lesson completion check

References and further reading