Account takeover fraud: warning signs and response

An attacker may use a reused password exposed elsewhere, a deceptive sign-in page, compromised email or a stolen active session. They may never need the current password. Recovery channels and active sessions need protection alongside passwords.

For a business, the affected account might belong to a customer, an employee or the business itself at a payment provider. An attacker may change contact details, spend stored value, redirect payouts or make recovery harder for the owner.

A stolen-card purchase does not necessarily mean an account was taken over. Someone who controls an account might instead change its payout destination without making a card purchase. Identify the affected account and permissions before deciding how to respond.

An unfamiliar device may simply mean the owner replaced a phone. Check whether the sign-in was expected and whether sensitive actions followed it. If the recovery email changes soon afterward, confirm the change through a previously established safe channel.

A new payout destination could reflect a legitimate change of bank account. Use the provider’s independent verification process before relying on it. If purchases or refunds also increase, compare the orders, permissions and timing with the verified owner’s activity.

None of these events proves fraud on its own. Travel, shared connections and accessibility tools can affect account signals. Review the combination and keep relevant timestamps and references without collecting more sensitive information than the investigation needs.

Use distinct credentials and available multifactor authentication (MFA) for business accounts, especially those with financial authority. Limit who may change recovery details, add users, issue refunds or alter payment destinations, and review access when staff responsibilities change.

Sensitive changes need the appropriate fresh verification. An open session is not enough evidence by itself. Prepare a recovery method and known support contact before an incident, and check requests to replace an authentication factor carefully.

MFA adds protection, but weak recovery procedures and stolen sessions can still expose an account. Use the provider’s secure verification process. Never ask a customer to send a password or one-time sign-in code.

1. Contact the account provider through a trusted route. Where your role permits it, restrict risky pending actions while the owner and recent changes are verified. Preserve relevant records rather than deleting suspicious activity.
2. Address credentials, active sessions, recovery channels and MFA changes together. A password reset alone may leave access in the attacker’s hands. Review newly added users, API credentials and financial destinations where those features exist. Use established evidence of ownership, not details the attacker may just have changed.
3. Once control is restored, reconcile affected orders and payments. Document what happened and follow the applicable provider and organizational notification requirements.

Recovery does not guarantee that a transfer can be reversed. That depends on what happened and the systems involved.