DEV Community: Cyberlords Security

Was your Instagram actually accessed? The evidence checklist before you pay anyone

Cyberlords Security — Fri, 30 Oct 2026 17:53:23 +0000

A "someone has been in my account" report is usually a mix of real artefacts and anxiety. The useful work is separating them: what the account actually records, what it doesn't, and what a forensic examiner can still recover.

This is the checklist we run before anyone spends money on recovery — written for account owners, not for intruders.

1. Start with the record the platform keeps for you

Instagram and Facebook both keep a login history. In the app: Settings → Accounts Centre → Password and security → Where you're logged in. On the web: Settings → Login activity.

You are looking for a device, city or time you don't recognise. Two warnings:

VPN users get false positives. If you or your household use a VPN, a foreign city is expected.
The list is pruned. Logins fall off after a while, so absence of a strange entry proves nothing.

Screenshot it with a timestamp before you change anything. If the case later goes to a lawyer or the police, that screenshot is evidence and the account state is not.

2. Pull the data export, not just the activity page

Accounts Centre → Your information and permissions → Download your information. Choose JSON, and ask for the full date range.

The export includes things the UI hides: IP addresses attached to sessions, message metadata, and the security emails the platform says it sent you. Those emails are the useful part — if the platform claims it sent a "new login" alert and you never received it, that tells you something about the intruder's access to your mailbox.

The export takes hours to days. Request it first, then keep working.

3. Read your own mailbox for the handover trail

An account takeover almost always leaves mail:

password reset requests you didn't make (the "we sent you a code" mails),
a "your email was changed" notice,
security alerts marked read that you never opened.

Check the read/unread state. An attacker with mailbox access marks their own alerts as read so the phone never buzzes. Unread alerts you don't remember seeing are normal; read alerts from a night you were asleep are not.

Also check for filters and forwarding rules — a rule that silently forwards password resets to another address is the single most-missed artefact in these cases.

4. Check the devices that are still attached

Two-factor method. If it changed from SMS to an authenticator you didn't set up, that's a strong indicator. So is a new backup code set.
Linked apps. Settings → Website permissions / Apps and websites. Anything you don't recognise had an access token; revoking it is reversible, deleting the account is not.
Trusted devices. On Android, check for device admin apps you didn't install.

5. Separate "accessed" from "still has access"

These need different responses.

Accessed means: logins from new places, changed recovery details, messages read. Still has access means: an active session, a linked app token, a forwarding rule, or a cloned session cookie on a device you no longer control.

Removing the intruder is the easy half. The half people skip is checking every route they left open — which is why "I changed my password and it happened again" is such a common story.

6. When it is worth paying an examiner

DIY is enough if you only need your account back. It is not enough if you need to know who, or need evidence that survives scrutiny:

harassment, stalking, or a partner or ex with physical access to your devices;
a business account where messages were used to defraud clients;
a dispute where "I was hacked" is your defence;
a device you suspect was compromised at the operating-system level, not just the app.

An examiner works from the device image and the platform records, not from screenshots, and produces something a court can be shown.

What we do, and what we won't

We take Instagram and WhatsApp account-compromise cases only with the account owner's written authorization, proof you control the account, and a lawful purpose. We don't break into other people's accounts, and we turn down requests to read a partner's, employee's or ex's messages — that's not a grey area, it's a crime in most jurisdictions.

If your case fits, the intake is at cyberlords.io/hire-a-hacker/instagram, and messaging-app cases are handled at cyberlords.io/hire-a-hacker/whatsapp. You'll be asked for authorization before anything is touched.

If it doesn't fit, the six steps above are most of what we'd do in the first hour anyway. Do them, and screenshot everything as you go.

Authenticated is not authorized: a practical IDOR test you can run on your own app

Cyberlords Security — Fri, 30 Oct 2026 17:41:42 +0000

Most "we got hacked" stories in web apps don't start with malware. They start with an endpoint that checks who you are but never checks what you are allowed to touch. The industry name is broken object-level authorization, or IDOR.

This is a short, practical guide to testing whether your app has that flaw — the way we do it on an authorized engagement, with written permission, on systems we are paid to test.

Why it happens so often

Frameworks make authentication easy: drop in a session, gate the route, done. Authorization is the part with no shortcut, because it depends on your own data model. It's the difference between:

// authenticated, not authorized
router.get('/api/invoices/:id', requireLogin, (req, res) =>
  db.invoices.findById(req.params.id).then(res.json))

and:

// authenticated and authorized
router.get('/api/invoices/:id', requireLogin, async (req, res) => {
  const invoice = await db.invoices.findById(req.params.id);
  if (invoice.ownerId !== req.user.id) return res.status(404).end();
  res.json(invoice);
})

Ten lines of code separate a fine app from a breach notification.

The test, in order

1. Map every object identifier. Query parameters, path segments, JSON body fields, hidden form inputs, GraphQL node IDs, S3 keys, signed-URL tokens. If a value selects a record, it's a target.

2. Create two accounts you own. Account A owns the data, account B tries to reach it. Never test with real user data — that's the difference between a test and an incident.

3. Replay with B's session. Capture A's request in your proxy, drop the session cookie and token, and send it again as B. Look at the status code and the body: a 200 with {"error":"forbidden"} is not a fix, and a 403 that still leaks the record name in the message is still a leak.

4. Try identifier shapes. Sequential IDs (1001 to 1002), UUIDs harvested from list endpoints (they are never as secret as people think), slug variations, and nested resources (/users/7/invoices/99 where the check is on 7 only).

5. Test state changes, not just reads. PUT, PATCH, DELETE, role fields, isAdmin, price, quantity, and the email or phone on an account. Reads leak data; writes destroy it.

6. Check the edges. Export endpoints, PDF generators, CSV downloads, share links, webhooks, image proxies, and anything that takes a URL. These are where object checks go missing.

The evidence that makes a finding useful

A screenshot of Postman is not a report. Record, for each issue:

the exact request and response pair, with both accounts' identities redacted consistently;
the impact in business terms ("any authenticated user can read any other tenant's invoices" beats "IDOR on /api/invoices");
a reproduction path a developer can follow in under five minutes;
the fix, at the level of the check that was missing, not "add authorization".

If you cannot demonstrate the impact with your own two accounts, you have a hypothesis, not a finding.

The legal line, because this matters

Testing someone else's system without permission is a crime in most jurisdictions, whatever the intent. Before a single request goes out you want: written scope (domains, IPs, accounts), the testing window, prohibited techniques, an emergency contact, and a definition of what happens if you find something critical.

If you are testing your own product, write the same document anyway. It forces the team to agree on scope, and it is the thing that protects you when a test knocks over production.

If you would rather not do it yourself

This is the work we do for a living under signed authorization: scoping, testing, evidence, and a report your developers can act on. You can see how we structure an engagement at cyberlords.io/hire-a-hacker, and if you only want to read up first there is a longer piece on staying lawful while doing this.

One closing note for developers: the fix is almost never a WAF rule. Centralize the ownership check next to the query, test it in CI with two seeded accounts, and treat a missing check as a failing test rather than a code review comment.