Automating Forensic Log Analysis: How LEAP detects Aadhaar & UPI exposure

Your Nginx logs know things your compliance team doesn't.

Every time a user submits a form, calls an API endpoint, or triggers a payment flow, fragments of that interaction land in your access logs. Query strings. Request bodies. Error traces. And in those fragments, more often than you'd expect, you'll find Aadhaar numbers, UPI Virtual Payment Addresses, and mobile numbers sitting in plaintext.

Not because engineers were careless. Because nobody told the logging config to scrub them.

The Pattern Recognition Problem

The naive approach to PII detection in logs is regex. Write a pattern, run it against your log file, flag everything that matches.

The problem: false positives. A 12-digit number isn't automatically an Aadhaar number. A string that looks like a UPI VPA might be a transaction reference ID. If your forensic tool flags everything, investigators waste time chasing noise instead of breach trails.

LEAP's approach is different. For every candidate match, it runs structural validation before flagging.

For Aadhaar specifically, LEAP checks the Verhoeff checksum, a mathematical verification algorithm built into every valid Aadhaar number. A 12-digit string that fails the Verhoeff check isn't an Aadhaar number, regardless of what it looks like. This single layer drops false positives dramatically.

For UPI Virtual Payment Addresses, the structure is localpart@psp where the PSP suffix must match a registered provider handle. LEAP validates against the known PSP list, PhonePe, GPAY, paytm, okaxis, ibl, and others, rather than just matching anything with an @ symbol.

For mobile numbers, LEAP applies the Luhn-adjacent prefix validation: Indian mobile numbers must begin with 6, 7, 8, or 9. Ten-digit strings starting with anything else are filtered out before they reach the results.

Why Browser-Side Execution Matters for Forensics

Here's the tension in digital forensics: the most sensitive files in any investigation are the evidence files themselves.

A log archive from a suspected breach contains not just the breach trail you're looking for, it contains every other user interaction that happened alongside it. Medical records. Financial transactions. Authentication flows. Uploading that file to an external analysis platform to scan it for PII is, by definition, a secondary data exposure.

LEAP runs entirely in the browser using WebAssembly. The log file you drop into LEAP never leaves your machine. The parsing engine, the regex engine, the validation logic, all of it executes locally. What leaves is the structured results report, which contains flagged patterns and their context, not raw log content.

This is why LEAP was built this way: not the fastest tool, but the one where the investigation itself doesn't create a new exposure risk. That design choice comes straight from our founder's background in log-based forensic investigation.

What a Real LEAP Scan Looks Like

Drop a 500MB Nginx access log into LEAP. Within seconds, you get a structured output organised by pattern type:

Aadhaar hits are presented with the line number, the surrounding request context (endpoint, timestamp, HTTP method), and a Verhoeff validation status. Hits with failed checksums are separated, they're still worth investigating as partial matches but shouldn't be treated as confirmed Aadhaar exposure.

UPI VPA hits are grouped by PSP suffix, which immediately tells you which payment provider's infrastructure was involved in the leak trail. A cluster of @paytm hits on a single endpoint at 2am is a very different pattern from scattered VPAs across normal business hours.

Mobile number hits are deduplicated, the same number appearing 47 times in one session is one incident, not 47. LEAP's deduplication collapses repeated appearances of the same identifier and reports the count, giving investigators an activity density view rather than raw counts.

Temporal Clustering: Where the Real Forensic Value Is

Individual PII hits tell you what leaked. Temporal clustering tells you when, how frequently, and from which access patterns.

LEAP groups hits within configurable time windows (default 5 minutes) to surface burst patterns. A legitimate user flow might produce 2-3 PII touches per session across normal business hours. An automated credential stuffing attack or a data scraping run produces hundreds of touches in a compressed window from the same source IP or session token.

This clustering output is what investigators actually use to build timeline evidence. Not "we found 847 Aadhaar numbers in the log", but "these 847 numbers were accessed in 14 minutes from three rotating IPs between 02:17 and 02:31 on March 4th, with each request following a pattern consistent with automated enumeration."

That's the difference between a log scan and a forensic finding.

What LEAP Doesn't Do

LEAP is a forensic detection tool, not a remediation platform. It tells you what's in your logs. It doesn't fix your logging configuration, it doesn't patch the endpoint that leaked the data, and it doesn't file the breach notification for you.

What it does do is give your forensics team, or your law enforcement liaison, a defensible, locally-processed evidence package that can be cited in an investigation without requiring them to send your logs to a third-party service to get the answer.

If your log analysis tool requires an internet connection to tell you what's in your own logs, you don't have a forensic tool, you have a liability.