​

What to Do If You Get Hacked

Incidents happen even when you follow good security habits. The difference between a contained event and a disaster often comes down to speed, evidence preservation, credential rotation, communication, and recovery. This guide applies to personal accounts, work devices, school platforms, developer environments, and small organizations.

​

The Incident Response Framework

Professional incident response is usually organized around five stages:

​

Step 1: Stay Calm and Preserve Evidence

Before changing everything, capture useful evidence:

• Screenshot ransom notes, suspicious emails, login alerts, and account changes.
• Record dates, times, affected accounts, and what you noticed first.
• Save suspicious email headers if phishing was involved.
• Export login history and active session lists if the service allows it.
• Photograph physical evidence such as unknown USB devices or tampering.
• For organizations, preserve relevant logs before they rotate.

​

Step 2: Disconnect and Isolate

If you suspect malware or active compromise on a device:

• Turn off Wi-Fi and unplug Ethernet.
• Do not plug in external USB drives.
• Keep the device powered on if possible so forensic data in memory is not lost.
• Move the device away from shared networks.
• Use a separate clean device for account recovery.

​

Step 3: Secure Critical Accounts From a Clean Device

Use a different device you trust. Prioritize:

​

Session and Token Cleanup

Changing a password is not always enough. Also:

• Sign out of all devices.
• Revoke unknown OAuth apps.
• Rotate API keys and personal access tokens.
• Rotate SSH keys if your device may be compromised.
• Check mail forwarding rules and inbox filters.
• Review recovery email addresses and phone numbers.

​

Step 4: Remove the Access Path

The attacker got in somehow. Find and close that route. Common access paths:

• Reused or weak password
• Phishing page
• Stolen session cookie
• Malware or infostealer
• Malicious browser or IDE extension
• Vulnerable software
• Over-permissive OAuth app
• Exposed API key or cloud key
• Compromised vendor or SaaS integration

If you cannot identify the access path, assume the device and all credentials on it may be exposed.

​

Step 5: Scan, Rebuild, or Restore

​

For Lower-Confidence Malware Cases

1. Run a full scan with a reputable security tool.
2. Remove suspicious apps, extensions, scheduled tasks, and login items.
3. Update the operating system and browser.
4. Monitor accounts for new suspicious activity.

​

For Serious Compromise

If the device had ransomware, a rootkit, persistent malware, stolen tokens, or unknown admin activity, a rebuild is safer than trying to clean it.

1. Factory reset or reinstall from official media.
2. Restore only clean data from backups.
3. Reinstall applications from official sources.
4. Rotate credentials before reconnecting synced services.
5. Monitor for repeat activity.

​

Step 6: If Ransomware or Extortion Is Involved

Do not respond emotionally to deadlines, threats, countdowns, or public leak pages. Recommended actions:

• Preserve the ransom note and related evidence.
• Disconnect affected systems.
• Contact your security, legal, insurance, and leadership contacts if this is an organization.
• Contact law enforcement or a national cybercrime reporting center when appropriate.
• Check trusted sources such as No More Ransom for decryptors.
• Restore from clean backups when possible.
• Prepare clear communication for affected people.

​

Step 7: If a Vendor or SaaS Platform Is Breached

Sometimes you are not the original victim. A vendor, learning platform, payroll tool, cloud provider, or software supplier may be breached first. Do this:

1. Read the vendor’s official incident updates, but do not rely only on them.
2. Identify what data your organization stored with the vendor.
3. Review your own logs for related suspicious activity.
4. Rotate integration keys, API tokens, SSO secrets, and admin passwords if exposure is possible.
5. Watch for targeted phishing that references real courses, projects, invoices, support tickets, or messages.
6. Notify affected users according to policy and law.
7. Document fallback procedures if the platform is unavailable.

​

Step 8: Warn Contacts and Affected People

Attackers often use compromised accounts to target contacts. Use a different communication channel if possible. Keep the message short:

My account was recently compromised. If you received unusual messages, links, files, payment requests, or login prompts from me, do not click them. I am securing the account now and will confirm when it is safe.

For organizations, coordinate communications through leadership, legal, IT, and communications teams.

​

Step 9: Monitor Financial and Identity Risk

If financial information, identity documents, or personal data may be exposed:

• Review bank and credit card statements.
• Enable transaction alerts.
• Contact banks or card issuers for suspicious transactions.
• Consider fraud alerts or credit freezes where available.
• Watch for targeted phishing using exposed personal details.

​

Step 10: Post-Incident Review

After recovery, document what happened.

​

Questions to Answer

1. How did the attacker get in?
2. What accounts, devices, data, tokens, and vendors were affected?
3. How long did the attacker have access?
4. What evidence supports the timeline?
5. What worked during response?
6. What was missing, slow, unclear, or manual?
7. What changes will prevent or reduce the next incident?

​

Preventive Actions

• Enable MFA on critical accounts
• Move to a password manager
• Remove unused browser and IDE extensions
• Revoke unused OAuth apps
• Rotate exposed tokens and API keys
• Set up backups with versioning
• Test restore procedures
• Patch software and firmware
• Create a contact list for incident response
• Write a short communication template before the next incident

​

Legal and Reporting Considerations

Depending on the data and location, organizations may have notification duties. Examples include:

• LGPD in Brazil: Personal data incidents may need to be reported to the ANPD and affected individuals.
• GDPR in Europe: Certain breaches must be reported to the supervisory authority within 72 hours.
• US state laws: Breach notification requirements vary by state.
• Education data: Student data may trigger institutional, contractual, or regulatory obligations.

For individuals, consider reporting to:

• Brazil: CERT.br or local police cybercrime channels
• US: IC3 at ic3.gov
• EU: Your national data protection authority or cybercrime reporting center

​

Key Takeaways

1. Preserve evidence before changing everything.
2. Use a clean device for recovery.
3. Rotate tokens, not just passwords.
4. Revoke active sessions and OAuth apps.
5. Treat vendor breaches as your risk too.
6. Recover from clean backups and monitor after recovery.
7. Document lessons learned while the timeline is still fresh.