Recreating the ATM Heist Investigation from Pritam & Pedro Using Real OSINT Tools

#cybersecurity #osint #digitalforensics #python

In the opening episode of Pritam and Pedro (JioHotstar's new cybercrime buddy-cop drama), a young hacker cracks an ₹28-lakh ATM theft case in "15 minutes" — mostly off-screen, mostly unexplained, and mostly movie magic.

That got me thinking: what would this investigation actually look like if a real cyber cell or fraud investigation team picked it up?

Not the "typing fast = hacking" version. The real one — the boring, methodical, tool-assisted version that actually catches people.

This post walks through the real-world investigative workflow for a financial cybercrime case like an ATM fraud/skimming incident, and the OSINT (Open-Source Intelligence) tools investigators and threat intel analysts actually reach for. I'll set up a practice environment so you can follow along with your own version of the "case."

⚠️ Scope note: Everything here is about the investigative/defensive side — how fraud gets traced and attributed after the fact. This is not a guide to committing fraud, bypassing ATM security, or accessing any system you don't own or have explicit authorization to test. All tool usage below should be practiced only on your own accounts, lab environments, or data you're authorized to analyze.

The Case File (Our Fictional Scenario)

Let's build a simple, self-contained scenario to investigate — the kind you'd see in a beginner digital forensics module:

An ATM reports 40 unusual withdrawal transactions overnight, all just under the reporting threshold.
The bank's fraud team flags a cluster of transactions tied to a handful of card numbers.
A suspicious IP address shows up repeatedly in the bank's web portal login logs around the same time — someone was checking balances online before each withdrawal.

That's actually a very realistic starting point. Most financial cybercrime investigations don't start with "the hacker's screen typing green code" — they start with transaction logs and login logs, because the paper trail (or in this case, digital trail) is what everything else hangs off of.

Step 1: Start With the Transaction Logs, Not the "Hack"

Before touching any external tool, an investigator's first move is always internal: pull the structured data.

Transaction timestamps — do withdrawals cluster in a tight time window? That suggests automation or a coordinated team rather than one person.
Amount patterns — repeated withdrawals just under a reporting/alert threshold is a classic structuring pattern (similar to "smurfing" in money laundering).
Card BIN (Bank Identification Number) analysis — the first 6-8 digits of a card number tell you the issuing bank and card type, which helps investigators figure out if compromised cards came from one breach source or several.

You can practice this kind of pattern analysis with nothing more than a spreadsheet and a public synthetic fraud dataset. Kaggle hosts several credit-card-fraud datasets built exactly for this kind of exploratory analysis — great for practicing anomaly detection with pandas before you ever touch an OSINT tool.

import pandas as pd

df = pd.read_csv("synthetic_transactions.csv")

# Flag transactions clustered within a short time window
df['timestamp'] = pd.to_datetime(df['timestamp'])
df = df.sort_values('timestamp')
df['gap_seconds'] = df['timestamp'].diff().dt.total_seconds()

suspicious = df[df['gap_seconds'] < 90]  # withdrawals <90s apart
print(suspicious[['timestamp', 'amount', 'card_id', 'atm_id']])

This kind of log-first thinking is what actually opens a case — not a dramatic hacking montage.

Step 2: Pivot From the IP Address

Once the bank's fraud team hands off the suspicious login IP, this is where OSINT tooling starts to matter.

Shodan is a search engine for internet-connected devices and infrastructure — not for finding people, but for understanding infrastructure. If the suspicious IP turns out to belong to a VPS, a compromised IoT device, or an open proxy, Shodan can help characterize what that IP actually is:

Is it a residential IP, a data-center IP, or a known VPN/proxy exit node?
What ports and services are exposed on it? (An open RDP port or unpatched service on that IP might explain how it got compromised in the first place, if it belongs to an innocent third party being used as a relay.)
Has that IP shown up associated with known malicious infrastructure before, per Shodan's tagging?

# Example Shodan CLI query — checking what's exposed on a given host
shodan host <ip_address>

This step usually tells investigators one of two things: either the IP belongs to the actual perpetrator's infrastructure (rare — most aren't that careless), or — far more commonly — it's a compromised machine or proxy being used to obscure the real origin, which becomes its own sub-investigation.

Step 3: Build the Relationship Graph With Maltego

This is the part TV shows love to compress into a single dramatic zoom-in on a screen. In reality, it's slower and far more valuable: link analysis.

Maltego is an OSINT and link-analysis platform used to visually map relationships between entities — domains, IPs, email addresses, usernames, organizations, and more — by chaining together "transforms" that pull data from various public sources.

For our case, an investigator might build a graph starting from:

The suspicious IP → what domains resolve to/from it
Any domains → WHOIS registration data (registrant email, registrar, creation date)
Registrant email → any other domains registered with the same email (a common pattern for repeat fraud infrastructure)
Any exposed usernames or handles → associated social media or forum presence

The value of Maltego isn't "finding the hacker's Facebook profile" (that's the Hollywood version). It's finding infrastructure reuse — attackers are humans, and humans are lazy. They reuse email addresses, hosting providers, naming conventions, and payment methods across multiple operations. That reuse is what eventually connects one case to a broader pattern, and that pattern is what makes a case prosecutable.

Step 4: Cross-Reference With Breach & Leak Intelligence

If the fraud team suspects the cards were compromised via a data breach (skimmer, phishing campaign, or a leaked database) rather than physical card cloning, the next step is checking whether the compromised card data or associated emails appear in known breach corpora.

Tools and services investigators commonly use here:

Have I Been Pwned (for checking if an email/domain appears in known breaches)
Threat-intel platforms that index leaked credential dumps (used by professionals under proper authorization, not casually)

This step matters because it tells you whether you're looking at a targeted attack on this specific bank/ATM network, or a downstream consequence of an unrelated breach where stolen card data is simply being cashed out — two very different investigations with very different next steps.

Step 5: Timeline Correlation — Where It All Comes Together

The final step is boring, and it's also the one that actually convicts people: correlating everything onto a single timeline.

Login timestamp (from bank logs) →
IP infrastructure lookup (Shodan) →
Domain/registrant pivot (Maltego) →
Breach association (HIBP or equivalent) →
Physical withdrawal timestamp and ATM location (from the original transaction logs)

When all five line up into a coherent, time-ordered story, that's a case. When they don't, you've likely found a false positive or a much messier multi-actor situation — which, incidentally, is closer to how real fraud rings actually operate than the show's tidy single-genius-hacker narrative.

What the Show Gets Wrong (And Why That's Worth Knowing)

If you're studying for a SOC analyst, fraud investigation, or digital forensics role, it's genuinely useful to notice why the dramatized version is wrong:

Real investigations are cross-team. Bank fraud analysts, law enforcement, and cybercrime cell investigators each hold a different piece — no lone genius has access to all of it.
Attribution takes days to weeks, not minutes. Link analysis across WHOIS records, breach data, and infrastructure reuse is iterative and often hits dead ends.
Most cases are solved through infrastructure reuse and human error, not a dramatic one-shot hack.

That gap between fiction and practice is exactly why walking through a fake case like this is a good learning exercise — it forces you to think in terms of evidence chains rather than hacking scenes.

Try It Yourself

If you want to practice this workflow hands-on:

Grab a public synthetic fraud dataset (Kaggle has several) and practice the pandas anomaly-detection step above.
Set up free-tier accounts for Shodan and Maltego Community Edition, and practice pivoting on infrastructure you own or that's explicitly designated for public lookup practice (e.g., your own test domain/IP).
Try building a simple timeline-correlation spreadsheet that links your synthetic transaction data to fictional "IP lookup" and "domain registration" entries you create yourself.

None of this requires touching a real bank, a real ATM, or anyone else's data — and that's the point. The investigative methodology is the transferable skill, regardless of the dataset.

Have you tried building out OSINT link-analysis workflows for practice? I'd love to hear what datasets or lab setups you've used — drop them in the comments.