Skip to content

Social Media Evidence Collection: API, Direct, Indirect and OSINT

Sources of social media evidence, the four collection methods (direct without login, direct with login, API-based and indirect), the OSINT toolset from Maltego to Sherlock, EXIF and document metadata extraction, geolocation pivots, recovery of deleted content via Wayback and provider subpoena, and authentication at trial under BSA Section 63.

Last updated:

Share

Social media evidence collection uses four methods matched to four visibility tiers: direct without login (public OSINT), direct with login (account-access under warrant or consent), API-based (structured platform data under developer terms), and indirect (graph traversal through mutual contacts and tagged content). Platform metadata of greatest investigative value, including IP login logs, device IDs, and account creation records, sits exclusively in the provider tier and requires a BNSS Section 91 production order or MLAT request to obtain. Because stories vanish in 24 hours and deleted content is retained by providers for as little as a few days, the correct acquisition sequence is to preserve perishable public content first, then persistent account content, then serve the formal production order. Admissibility in Indian courts runs through BSA 2023 Section 63 certification, as confirmed in Anvar P V v P K Basheer (2014) and Arjun Pandit Rao Khotkar v Kailash Kushanrao Gorantyal (2020).

Social media evidence degrades fast. Stories vanish in 24 hours, edited tweets retain only a 60-minute edit window on X Premium, Snapchat content disappears from view almost immediately, and platform metadata of investigative value, including IP logs, login fingerprints, and device IDs, sits behind a subpoena. The forensic discipline is therefore one of staging: capture perishable content first, then persistent content, then serve the formal production order for provider records.

Key takeaways

  • Stories vanish in 24 hours and Snapchat content disappears almost immediately, so the correct acquisition sequence is to capture perishable content first, then persistent content, then chase provider records via subpoena.
  • A social media account holds eleven artefact classes across four visibility tiers: public, friends-only, private DMs, and provider-only, with a different legal access route required for each tier.
  • OSINT tools including Maltego, Sherlock, SpiderFoot, and Hunchly form the standard toolkit for aggregating open-source data across platforms before any formal legal process is needed.
  • Image metadata extraction and geolocation pivots from EXIF GPS coordinates to Snap Map can establish physical location evidence directly from user-posted content without touching provider records.
  • Indian trial admissibility for social media evidence runs through BNSS Section 91 production orders, BSA Section 63 certification, and the Anvar and Arjun Khotkar case line that governs electronic record proof.

This topic walks the social media acquisition stack end to end. It covers the eleven sources of evidence visible on a typical platform account, the four data-visibility tiers from public to provider-only, the four collection methods (direct without login, direct with login, API-based and indirect), the OSINT toolset led by Maltego, Sherlock, SpiderFoot and Hunchly, the metadata extraction routine for images and documents, the geolocation pivots from EXIF GPS to Snap Map, the deleted-content recovery options via Wayback, archive.today and provider subpoena, and the Indian authentication route at trial through BNSS Section 91, BSA Section 63 and the Anvar / Arjun Khotkar line of cases. The companion topic on social media crime taxonomy covers the offence side.

By the end of this topic you will be able to:

  • Classify a social media account's artefacts across the four visibility tiers and identify the correct legal access route for each tier.
  • Select and apply the appropriate collection method (direct without login, direct with login, API-based, or indirect) given the target account's privacy posture and the case's legal instruments.
  • Construct an OSINT pipeline using Maltego, SpiderFoot, Sherlock, Hunchly, and ExifTool to aggregate cross-platform identity evidence and preserve chain of custody.
  • Extract and interpret EXIF, document, and video metadata for geolocation, device attribution, and timeline reconstruction, accounting for platform-side metadata stripping.
  • Produce a BSA Section 63 certificate for social media evidence that satisfies the Anvar / Arjun Khotkar admissibility standard at trial.
Key terms
OSINT
Open Source Intelligence. Information collection from publicly available sources, without authentication. Includes public social media profiles, search engines, archives, leaked data corpora and registered-business records.
Direct collection (without login)
Acquisition of a target's public profile content using no credentials. The page is served to anyone. Limited to whatever the privacy settings expose to the public tier.
Direct collection (with login)
Acquisition using the subject's account credentials or a session cookie lifted from a seized device. Requires legal authorisation under BNSS Section 91 or a warrant; the chain of custody must explain how the credentials were obtained.
API-based collection
Acquisition via the platform's official API: X v2 API, Meta Graph API, LinkedIn API. Requires a developer account, often paid tiers, and platform-side terms of service that constrain forensic use.
Indirect collection
Deriving evidence from interconnected accounts (mutual friends, tagged content, common groups) rather than the target's own profile. Powerful when the target's account is private or deleted.
Hunchly
Browser-based case-management tool for OSINT. Captures every page visited as a hashed snapshot, builds the case dossier and produces a court-ready report. The standard tool for OSINT chain of custody.

Sources and visibility tiers: what lives where on a social media account

A social media account holds far more than the public timeline. The examiner's first job is to map the artefact surface against the visibility tiers, because the collection method that applies to each is different.

Artefact classExamplesVisibility tierStandard access
Profile contentBio, display name, profile photo, cover photo, linksPublicDirect without login; archive via Wayback
Timeline posts and storiesFeed posts, Reels, IG/FB stories, X tweetsPublic or friends-onlyDirect or indirect; story preservation in 24 hours
Direct messagesInstagram DMs, X DMs, WhatsApp chatsPrivateDevice acquisition or provider subpoena
Story / status archiveUser's own archive of past storiesAccount-onlyDirect with login or provider subpoena
Search historyRecent searches within the appAccount-onlyDevice or account download
Friend / follower listConnections, mutuals, blocked listFriends-only to publicDirect or indirect via OSINT
Location check-ins and tagged placesPublic check-ins, place tagsPublic or friends-onlyDirect or OSINT (Snap Map, IG location pages)
Photos with EXIF / geotagUser-uploaded imagesTier of containing postEXIF extracted post-acquisition (often stripped by platform)
Saved contentBookmarks, saved Reels, saved postsAccount-onlyDirect with login or account download
Ad preferencesCategorised interests, advertiser audiencesAccount-onlyAccount download (Meta 'Download your information')
Connected apps via OAuthThird-party apps with scope-granted accessAccount-onlyAccount settings or account download
Provider-side recordsLogin IP logs, device IDs, hashed passwords, sign-up emailProvider-onlySubpoena under BNSS Section 91 / MLAT

The visibility tier determines the legal pathway. Public content is acquired without authorisation (OSINT). Friends-only or mutual-follow content is acquired with the subject's consent or via an indirect path (a mutual contact's account viewing the content within the scope of the warrant). Private content (DMs) sits on the device or requires a production order to the provider. Provider-only content (login IPs, account creation metadata, security event logs) requires a BNSS Section 91 production order, an IT Act Section 69 direction for interception, or for foreign platforms an MLAT request in parallel with the platform's Law Enforcement Request System (LERS).

A practical note about story-class content. Instagram and Facebook stories disappear from the public surface after 24 hours but persist in the user's own archive and on Meta's servers under the data retention policy. WhatsApp status follows a similar window. The acquisition discipline is to preserve immediately on victim notification, because the provider-side retention for non-account-holders is shorter than the user-archive window.

The four collection methods: direct without login, direct with login, API, indirect

The four standard collection methods cover the field. Each has a typical use case, a tool family and a legal posture under Indian procedure.

Evidence-collection decision tree for social-media artifacts. Start with the artifact type, branch by its visibility tier, an
Evidence-collection decision tree for social-media artifacts. Start with the artifact type, branch by its visibility tier, and arrive at the collection method with its admissibility note. Admissibility depends on matching the correct legal instrument to the access tier.
MethodUse caseTool familyLegal posture
Direct without loginPublic profile, public posts, OSINT cluster mappingHunchly, Wayback, archive.today, browser DevTools, wgetNo authorisation required for public content
Direct with loginSubject's own account; recovered session cookie from seized deviceBrowser, account download tools, X-Ways Forensics for cookie extractionBNSS Section 91 production order or consent of account holder; warrant where credentials forced
API-basedBulk collection, structured fields, repeat queriesX v2 API, Meta Graph API, LinkedIn API, Tweepy, snscrape (where permitted)Platform terms of service apply; developer access keys required; some APIs paid-only
IndirectTarget account is private, deleted or unreachableMaltego, Sherlock, theHarvester, friend-of-friend graph traversalOSINT for public-tier visible-via-others; production order for provider-side

Direct collection without login is the default for any FIR that names a public-tier account. The investigator opens the profile in an isolated browser (Hunchly running), captures every page (URL, full DOM, screenshot, hash), archives via Wayback Machine and archive.today, and exports the captured pages to the case dossier. Hunchly is the Indian state cyber-cell standard for OSINT chain of custody because every page capture is automatically SHA-256 hashed, time-stamped and packaged with the case ID.

Direct collection with login is the path when the target account is the subject's own (seized device, voluntary unlock or BNSS Section 105 search warrant) or when the victim's account is being preserved. Cookie acquisition from a seized device lets the examiner authenticate as the user without forcing a password reset that the attacker would notice. The platform's data-export ('Download your information' on Meta, 'Download your data' on X) yields the account-only artefacts in a structured archive. The chain of custody must record how the credentials or session cookie were obtained.

API-based collection is the structured path. The X v2 API yields tweets, replies, follower lists, user lookups and DMs (with the right scopes) under paid tiers. The Meta Graph API requires app review for most non-public scopes; the older Public Feed and Keyword Insights APIs that historically supported research are deprecated. LinkedIn's API is largely closed; investigators rely on direct collection with login. Tweepy is the Python wrapper for the X API; snscrape historically scraped Twitter without API access but is constrained by current X policy.

Indirect collection is the path when the target account is locked. The mutual contact's view (with their cooperation and consent), the tagged-content cluster across other accounts, the common-group membership and the public mentions of the target on other accounts all yield evidence without touching the locked account. Maltego is the link-analysis workhorse: entities (account, email, phone, domain) and transforms (run a query on each entity to find related entities) build a graph that the IO can pivot through. Sherlock takes a username and queries 400+ platforms for matching profiles in seconds.

The OSINT toolset: Maltego, SpiderFoot, Recon-ng, Sherlock, Hunchly

OSINT investigation pipeline. Five sequential stages from target identification to timeline reconstruction, with example tool
OSINT investigation pipeline. Five sequential stages from target identification to timeline reconstruction, with example tools for each stage. The pipeline feeds from left to right; each stage enriches the picture before the next step runs.

OSINT for social media runs on a small set of category leaders. The examiner does not need every tool; one from each category gets the job done.

ToolCategoryWhat it doesForensic use
MaltegoLink analysisGraphs entities and transforms; 100+ community transformsCluster identification, sock-puppet linkage, common-infrastructure mapping
SpiderFootAutomated reconnaissanceRuns 200+ modules against a target (domain, IP, email, name)Bulk recon on a person or organisation; first-pass OSINT sweep
Recon-ngCLI OSINT frameworkModular CLI reconnaissance with workspaces and modulesScripted recon in headless investigation pipelines
SherlockUsername enumerationChecks 200+ platforms for a given usernameCross-platform identity mapping for a single handle
theHarvesterEmail and subdomain enumerationHarvests emails, subdomains, hosts from search enginesCorporate target recon; phishing kit infrastructure mapping
Hunter.ioEmail pattern discoveryFinds emails by domain pattern (first.last@example.in)Witness contact, corporate phishing target list
OSINT FrameworkCatalogueCurated directory of OSINT tools by categoryReference for choosing the right tool per task
CensysInternet asset searchIndexes TLS certificates, banners, services across IPv4 + IPv6Phishing kit hosting, malicious infrastructure
ShodanConnected device searchIndexes banners on internet-facing servicesConnected IoT exposure, exposed databases linked to a target
HunchlyCase managementCaptures every visited page with hash, timestamp and case IDOSINT chain of custody for court
Wayback Machine extensionBrowser pluginArchives the current page or fetches archived versionsQuick preservation of pages that may disappear
ExifToolMetadata extractionReads and writes EXIF, IPTC, XMP across image and document formatsImage attribution, GPS extraction, camera fingerprint

The reference workflow stacks these tools in order. SpiderFoot runs the first-pass sweep against the target identity (name, email, phone, username) to gather every public reference. Sherlock checks the username across 200+ platforms to find cross-platform accounts. theHarvester adds the email-and-subdomain corpus. Maltego ingests the SpiderFoot and Sherlock outputs as entities and runs transforms to expand the graph (related accounts, registered domains, breach corpus matches). Hunchly captures every page touched in the investigation, building the case dossier with hash and timestamp on each capture. ExifTool extracts metadata from any images or documents recovered. Shodan and Censys map the infrastructure side when phishing kits or malicious hosting are part of the case.

The Indian state cyber cells maintain Maltego Classic or Maltego CE licences for link analysis and Hunchly site licences for case management. The procurement template treats both as core OSINT tools alongside the disk-imaging hardware. SpiderFoot HX is the hosted variant some units use for cloud-side scanning.

  1. Define the target entity set
    Names, usernames, email addresses, phone numbers, known account URLs. Capture the entity set in writing at the start of the case.
  2. First-pass sweep with SpiderFoot or theHarvester
    Run a 200-module sweep on the target identity. Export findings as a CSV ingestible into Maltego.
  3. Username enumeration with Sherlock
    Run Sherlock against each known username. Capture the hit list; visit each hit through Hunchly so the page is preserved.
  4. Link analysis in Maltego
    Import the entity set; run transforms (Have I Been Pwned, breach corpus lookups, WHOIS, social media graph) to expand connections.
  5. Per-account direct capture via Hunchly
    Open each target profile through Hunchly. Every page is hashed, timestamped and added to the dossier with the case ID.
  6. Metadata extraction on recovered images and documents
    Run ExifTool on downloaded images. Note EXIF GPS, camera make/model, timestamp, software, thumbnail. Cross-reference document metadata (Word author, PDF producer) for attribution.
  7. Generate the Hunchly case report and BSA Section 63 certificate
    Hunchly exports the case dossier with hashes and an evidence index. Sign the BSA Section 63 certificate over the dossier file for production at trial.

Metadata and geolocation: EXIF, document metadata, Snap Map, Strava

When a user uploads a photo or document to a social media platform, much of the embedded metadata travels with the file unless the platform strips it on ingest. The examiner's task is to extract whatever the platform retained and, more productively, to locate the off-platform copies that carry the complete metadata set.

Metadata classFields of forensic interestTool
EXIF (image)Camera make/model, lens, ISO, aperture, shutter, GPS coordinates, software, original timestamp, modify timestamp, thumbnailExifTool, Jeffrey's Image Metadata Viewer, ExifPilot
IPTC / XMP (image)Description, author, copyright, keywords, location namesExifTool
Document (Word, Excel, PowerPoint)Author, last-modified-by, company, total editing time, revision number, template pathExifTool, oletools, DocBleach
PDFProducer, creator, title, author, modify-date, document-IDExifTool, pdfinfo, peepdf
Video (MP4, MOV)Container metadata, recorded timestamp, codec, GPS atoms (iOS, Samsung), encoderExifTool, MediaInfo
Audio (M4A, MP3)Encoder, recording timestamp, ID3 tags, device modelExifTool, MediaInfo

Most major social media platforms strip EXIF from uploaded images for privacy reasons. The forensic implication is that an EXIF-rich image found in a victim's WhatsApp media folder, or in an attached email, or in a cloud backup retains the GPS coordinates that the public Instagram upload of the same image does not. The off-platform copy is therefore evidentiarily richer than the on-platform copy.

ExifTool is the unified tool. A single command (exiftool -GPSLatitude -GPSLongitude -DateTimeOriginal -Make -Model file.jpg) yields the relevant fields. ExifPilot is the GUI variant for examiners who prefer a windowed workflow. Jeffrey's Image Metadata Viewer is a quick web-based reader for triage.

Geolocation pivots beyond EXIF.

  1. Geotagged posts
    Instagram location pages, X tweet location (where enabled), Facebook check-ins. Open the platform's location page for the tagged place; the post will appear in the public feed for that place.
  2. Snap Map
    Snapchat's public-tier location feed shows submissions to 'Our Story' on a world map. Useful for events and breaking incidents.
  3. Strava heat map
    Strava's public global heat map exposed the locations of US and allied military bases in 2018 when service members ran routes that lit up otherwise-classified perimeters. The cautionary tale applies broadly: any aggregate fitness data leaks individual location.
  4. Background-derived geolocation
    Landmark recognition in photos. The 2018 Bellingcat investigations into MH17 and Syria established the technique: identify the photo's location from architectural and geographic landmarks visible in the background.
  5. Wi-Fi BSSID lookup
    If a photo's EXIF or metadata captures nearby Wi-Fi BSSIDs (some Android cameras and IoT devices do), services like WiGLE map BSSIDs to physical locations.
  6. IP-derived approximation
    Login IP from the provider subpoena, geo-resolved to city. Approximate, not precise, but corroborative.

The Strava 2018 incident illustrates a broader principle: aggregate, anonymised data still locates individuals when the underlying population is small. The investigator should expect that fitness apps, ride-share apps and food-delivery apps carry the same risk pattern, and that subpoena to those providers (BNSS Section 91) is part of the toolkit when a target's physical location at a given hour is the question.

Deleted and edited content: Wayback, archive.today, provider subpoena, notification cache

When a target realises an investigation is under way, post deletion, tweet editing, and DM clearing are immediate responses. Five complementary recovery paths address this.

PathCoverageLimitationsIndian access route
Wayback Machine (web.archive.org)Public web pages, including many public profilesCoverage depends on whether the crawler visited; private posts not capturedOpen access; cite by archive URL with timestamp
archive.todayManual snapshot service; preserves on demandSnapshot must be triggered before deletionOpen access; investigator can trigger preservation on observation
Google cache (deprecated 2024)Historically retained Google's last crawl of a pageDiscontinued by Google in early 2024; Bing cache still available for some pagesOpen access where available
Provider subpoena for retained server-side copyMany platforms retain deleted content for 30-90 days for abuse reviewWindow is short; preservation request must go in fastBNSS Section 91 production order; MLAT for foreign provider
Push-notification history on phone OSiOS Notification Centre and Android notification log retain DM and post textDevice must be accessible; OS retention variesDevice acquisition under BNSS Section 105 search warrant
Platform edit historyX Premium (60-minute edit window), Reddit edit history, ThreadsOnly where platform exposes the edit chainDirect collection or platform LERS

The Wayback Machine is the default first move for any public-tier deletion. The investigator pastes the profile URL into web.archive.org and checks for snapshots. The archive URL itself (https://web.archive.org/web/YYYYMMDDHHMMSS/https://...) is the citable evidence; the snapshot date is the timestamp at which the page held the content shown. For pages not previously crawled, archive.today lets the investigator trigger a snapshot at the moment of observation, before the target deletes.

Google's cache (previously available at cache:URL or via the search-result cached link) was deprecated by Google in February 2024. Some Bing cached pages remain available. archive.today is the surviving on-demand alternative.

Provider-side retention varies. Meta retains deleted content in a recovery queue for 30 days for the account holder and longer for the provider's abuse-review functions; X has historically retained deleted content for up to 30 days during its deletion process, with server copies potentially persisting for up to 90 days; WhatsApp's content is end-to-end encrypted and provider-side recovery is generally not available (metadata is available). A preservation request to the platform's Nodal Contact Person (for SSMIs under the Intermediary Guidelines 2021) is the immediate action; the formal production order under BNSS Section 91 follows.

The notification cache is an underused source. iOS Notification Centre and Android's notification log retain the preview text of social media DMs and post mentions for a window that depends on the OS version (typically the most recent 48-72 hours of notifications, longer for some message types). When the target has deleted the DM but the recipient's device still has the notification cached, the cache is a primary evidence source. Cellebrite, Oxygen Detective and Magnet AXIOM all parse the notification stores.

Edit history is platform-specific. X Premium allows editing a post for 60 minutes; the platform exposes the edit chain to viewers. Reddit's edit history is accessible to logged-in users. Threads inherits Instagram's edit semantics. Where the edit chain is exposed, capture it via Hunchly before the platform's window closes.

Authentication at trial: BSA Section 63, BNSS Section 91, Anvar, Arjun Khotkar

Social media evidence reaches the trial court through the same admissibility framework as all electronic records: BSA 2023 Section 63, which replaced IEA Section 65B. The certificate format and the case-law line that interprets it define the qualification standard.

ElementStatutory anchorIndian case-law anchorPractical content
Production of records from providerBNSS Section 91 (was CrPC 91)Bishwajit Halder line on procedural proprietyMagistrate's order, served on platform's RGO or LERS portal
Interception or stored-content accessIT Act Section 69PUCL v Union of India (1996) safeguards extended to electronicAuthorised officer, written reasons, time-bound, reviewed
MLAT for foreign providersMutual Legal Assistance Treaties (US, UK and others)Government of India guidelines on MLAT requestsChannelled through MHA Internal Security division
Electronic record admissibilityBSA 2023 Section 63 (was IEA 65B)Anvar P V v P K Basheer (2014); Arjun Pandit Rao Khotkar v Kailash Kushanrao Gorantyal (2020); Shafhi Mohammad v State of Himachal Pradesh (2018) [restricted]Certificate identifying the device, the imaging method, the working condition, signed by responsible official
Expert opinion at trialBSA Section 39 (was IEA 45)State of NCT of Delhi v Navjot Sandhu line, post-AnvarExaminer's deposition admissible as expert evidence

The Indian case-law evolution on electronic-record admissibility runs through three landmark judgements. In Anvar P V v P K Basheer (2014) the Supreme Court held that Section 65B (now BSA Section 63) is a mandatory pre-condition to admissibility of any secondary electronic evidence, and that oral evidence about the contents of an electronic record cannot substitute for the certificate. In Shafhi Mohammad v State of Himachal Pradesh (2018) a two-judge bench appeared to relax the requirement when the certificate could not reasonably be procured; that relaxation was overruled. In Arjun Pandit Rao Khotkar v Kailash Kushanrao Gorantyal (2020) a three-judge bench restored Anvar P V in full: the certificate is mandatory; the party seeking admission must produce it; failure is fatal. BSA 2023 Section 63 codifies the Anvar / Arjun Khotkar position.

The certificate's content (under BSA Section 63(4)) identifies the electronic record, describes the way it was produced (including the device, the software and the imaging method), states the conditions under which the device operated (the device was used regularly and was operating properly during the relevant period; the information stored is regularly fed in the ordinary course of activities), and is signed by a person occupying a responsible official position in relation to the operation of the relevant device. For social media evidence the 'device' includes the imaging workstation and any platform-side records produced under BNSS Section 91.

  1. Capture the page with URL visible
    Browser address bar visible in screenshot. Hunchly does this automatically; manual capture requires a full-page screenshot tool that captures the chrome.
  2. Hash the captured artefact
    SHA-256 over the captured page bundle (HTML, screenshot, MHTML or PDF). Record the hash in the chain of custody.
  3. Cross-reference with provider records
    Where available, match the captured content against the provider's API or production-order response. Note the Message-ID / post-ID / tweet-ID for cross-reference.
  4. Image the device side if applicable
    Where the captured content sits on a seized device (notification cache, app database, browser cache), image the device under BNSS Section 105 search warrant procedure.
  5. Draft the BSA Section 63 certificate
    Certificate identifies the device, describes the imaging method (Hunchly version, browser version, OS, network position), states the working-condition language and the regular-feed language, and is signed by the responsible official (senior FSL analyst or IO with the requisite designation).
  6. Annex to charge sheet under BNSS Section 193
    The FSL report, the captured exhibits with hashes, the platform's production-order response (if any) and the Section 63 certificate together form the annexure to the charge sheet.
  7. Lead expert evidence at trial
    Examiner deposes under BSA Section 39 (expert opinion). Cross-examination typically targets the chain of custody, the imaging method and the certificate's signatory authority.

The Indian context anchor for foreign-platform subpoena is the Sushant Singh Rajput investigation, in which the Mumbai Police and later the CBI sought records from Twitter (now X) and Instagram for posts and DMs of multiple parties. The cooperative request channel ran through Meta's and X's Law Enforcement Request Systems in parallel with formal MLAT requests via the MHA. Bombay High Court orders on Twitter content takedown during the same period set out the procedural template for high-profile takedown applications.

The cross-link for the substantive admissibility doctrine sits with Bharatiya Sakshya Adhiniyam 2023 Section 63; the BNS 2023 cyber and BSA 2023 electronic evidence topic covers the wider statutory frame.

Practice
Question 1 of 5· 0 answered

Which collection method applies when the target's social media account is private and the investigator must derive evidence from mutual friends, tagged content and common groups?

Frequently asked questions

What are the four visibility tiers on a social media account and how do they map to collection methods?
Public (visible to anyone), Friends-only / mutual-follow (graph-restricted), Private DMs (account-only) and Provider-only (subpoena-required). Public content is collected directly without login using OSINT (Hunchly, Wayback, archive.today). Friends-only is collected with the subject's consent, indirectly via a mutual contact's view, or via account download with login. Private DMs are collected from the device or via BNSS Section 91 production order to the provider. Provider-only records (login IP logs, device IDs, hashed passwords) require BNSS Section 91, IT Act Section 69 or for foreign platforms an MLAT request alongside the Law Enforcement Request System.
Which OSINT tools are standard in Indian state cyber-cell procurement?
Maltego (link analysis), SpiderFoot (automated reconnaissance, 200+ modules), Recon-ng (CLI OSINT framework), Sherlock (username enumeration across 200+ platforms), theHarvester (email and subdomain enumeration), Hunter.io (email pattern discovery), Censys and Shodan (internet-asset and connected-device search), Hunchly (case management with hashed page capture), Wayback Machine and archive.today (web archive preservation), ExifTool (metadata extraction). The state cyber cells run Maltego CE or Classic licences alongside Hunchly site licences as core OSINT infrastructure.
How is EXIF metadata extracted from a recovered image, and what is the GPS field of interest?
ExifTool is the unified tool. A single command (exiftool -GPSLatitude -GPSLongitude -DateTimeOriginal -Make -Model file.jpg) yields the relevant fields. The GPS field of forensic interest is the lat/long pair in decimal degrees, with the GPSAltitude and GPSTimeStamp adding precision. Most public social media platforms strip EXIF on upload, so the EXIF-rich copy is the off-platform original (in WhatsApp media folder, email attachment or cloud backup) rather than the public Instagram or X post. Jeffrey's Image Metadata Viewer is the quick web-based reader; ExifPilot is the GUI variant.
What are the standard recovery paths for content the target has deleted from a social media account?
Five complementary paths: Wayback Machine (web.archive.org) for public profiles that the crawler visited before deletion; archive.today for on-demand snapshots triggered before deletion; provider subpoena under BNSS Section 91 for server-side recovery queues (typically 30 days for Meta, shorter for X); the notification cache on the recipient's iOS or Android device, which retains DM and post preview text for a window after delivery; and platform-exposed edit history where available (X Premium 60-minute edit window, Reddit edit history). Google cache was deprecated by Google in February 2024 and is no longer available; some Bing cached pages remain. The preservation request to the platform's Nodal Contact Person must precede the formal production order because retention windows are short.
What does the BSA Section 63 certificate need to contain for social media evidence?
The certificate (BSA Section 63(4)) identifies the electronic record, describes how it was produced (device, software, imaging method, network position), states that the device was used regularly during the relevant period and was operating properly, states that the information stored is regularly fed in the ordinary course of activities, and is signed by a person occupying a responsible official position in relation to the device. For social media evidence the 'device' commonly includes the imaging workstation (Hunchly version, browser version, OS), the seized device for device-side capture, and the platform-side production-order response. The leading authorities are Anvar P V v P K Basheer (2014) and Arjun Pandit Rao Khotkar v Kailash Kushanrao Gorantyal (2020); BSA 2023 codifies their position.
How does the investigator obtain content from Meta, X or Google when no Indian office is incorporated for content access?
Two parallel channels. The cooperative channel runs through the platform's Law Enforcement Request System (Meta LERS, X transparency portal, Google LERS) with the BNSS Section 91 production order attached; platforms respond cooperatively for emergency requests and most regular production orders. The formal channel is an MLAT request via the Ministry of Home Affairs Internal Security division to the platform's home jurisdiction (the United States for Meta, X and Google) under the India-US Mutual Legal Assistance Treaty. MLAT cycles are slow (months to over a year), so the LERS channel carries most operational requests. Under the Intermediary Guidelines 2021 the platforms' Resident Grievance Officer and Nodal Contact Person are the formal contact points for India-resident operations.
Why is the notification cache on a recipient's phone a useful evidence source after a DM is deleted?
iOS Notification Centre and Android's notification log retain the preview text of social media DMs and post mentions for a window that depends on the OS version and notification settings (typically the most recent 48-72 hours of notifications, longer for some message types). When the sender deletes a DM after delivery, the recipient's notification cache often still holds the preview text and a thumbnail. Cellebrite, Oxygen Detective and Magnet AXIOM all parse the notification stores during a full device extraction under BNSS Section 105 search warrant procedure. The notification cache is therefore a primary, often-overlooked recovery source for deleted social media DMs.

Test yourself on Digital Forensics with free, timed mocks.

Practice Digital Forensics questions

Found this useful? Pass it along.

Share

Spotted an error in this page? Report a correction or read our editorial standards.

Your journey to becoming a forensic professional starts here.

Practice with mock tests, learn from structured notes, and get your questions answered by a global forensic community, all in one place.