What Facebook Takeout contains and why it matters

This document is auxiliary in nature — prepared for officers as a template for requests and for the scope of analyses. It contains no sensitive data.

What Facebook Takeout contains and why it matters

Typical files used in analysis:

• account_activity.html — a list of events (login, session update, password change, name change) with the time, IP and user-agent marked;
• ip_address_activity.html — activity grouped by IP address;
• record_details.html — administrative entries (password changes, 2FA, checkpoints) with reference to the IP and device fingerprint;
• where_you're_logged_in.html / recognized_devices.html — trusted devices and active sessions;
• messages (e2ee_cutover) — the content of sent messages (important for demonstrating the harm and the phishing mechanism).

From Facebook Takeout one can reconstruct: the sequence of events (timeline), the assignment of events to IP addresses and user-agents, the approximate IP geolocation, and the type of client used (e.g. Messenger Lite, the Chrome browser, a mobile app).

What you cannot establish from Takeout without the telecoms operator

• the specific person (identity) using the IP address — this requires operator data;
• with CGNAT: without source ports it is impossible to unambiguously assign a session to a subscriber;
• without radio logs it is impossible to link IMSI ↔ IMEI ↔ BTS with time precision.

A sample chronology — an illustration of interpreting Facebook Takeout data

Table 1

The list of events shows the typical course of a Facebook account takeover. At around 20:50 the first activity appears from a new device not previously present in the account history — a Pixel 6 running Android — using an IPv6 address outside the owner's usual login range. Over the next few minutes there is a successful login, and then, from another IPv4 address and a computer with the Chrome/Windows browser, there is an administrative password change and a change of the profile name — behaviour typical of a full account takeover.

Indications pointing to the action of a third party: the use of IP addresses and user-agents that were never previously assigned to this user's activity in the Takeout archive; a sudden change of platform (from iPhone/Safari → Pixel/Android → Chrome/Windows) within a short time window; and the sequence of events: password reset → password change → name change → mass sending of messages.

At around 07:13 the next day, recovery actions are visible from the owner's device (an iPhone), including enabling 2FA and changing the password again, which confirms the moment control over the account was regained. All of this correlates with an attack carried out from an external device and various network points, rather than with the owner's normal activity.

A precise data request to the telecoms operator — technically essential fields
The request to the operator (the telecoms undertaking) should require (for the indicated IP and a strict time interval — preferably to the minute):

1. Subscriber / end-user data: first name, surname, installation address, and possibly the PESEL number (if legally available).
2. SIM cards / mobile identifiers: MSISDN, IMSI, ICCID.
3. The IMEI number(s) linked to the sessions (and — if available — the manufacturer and model from the IMEI database).
4. The exact start and end times of each session (in UTC and local CEST) and information on how time is synchronised in the logs.
5. Full NAT/CGNAT mappings: external_IP:source_port ↔ internal_IP:internal_port ↔ session identifier (with timestamps).
   • Practical note: if CGNAT translations are used, the operator must include the source port number — without it, identifying the subscriber is impossible.
6. Radio-network identifiers (for mobile traffic): BTS / eNodeB / CellID, eNodeB sector, APN, and possibly GTP TEID.
7. DHCP / PPPoE / CPE MAC logs (for fixed connections) — the MAC of the CPE device, the assigned internal IP.
8. Metadata and format: files in CSV/TSV format with a description of the columns, copies of the original logs and checksums (SHA-256).
9. An indication of all translations within the requested window — not just a single record.

How to formulate the time range and ports (practice)

• Law-enforcement bodies should indicate a very narrow time interval (e.g. ±2 minutes around the event from the Facebook logs) — this reduces the number of records and speeds up identification.
• If the Facebook log shows only an approximate time (e.g. to the second), use that time as a reference point.
• Request from the operator all NAT mappings for that external IP within the given window (it is the operator that has the ports in its records).

Additional evidence to consider

• Imaging the owner's iPhone/iPad/Mac (if available) — allows confirmation of 2FA settings, trusted devices, locally stored sessions and cookies;
• SIM / IMSI / operator analysis — correlation of IMSI ↔ IMEI ↔ network logs;
• A request for DNS/Proxy/VPN logs — if a VPN/proxy is suspected (addresses not matching the geolocation), information can be requested from VPN services (if identified) or proxy providers;
• Securing the content of messages from the messages folder as evidence of social engineering (the phishing content).

Typical pitfalls and limitations

• CGNAT and large address ranges: without ports or a narrow time interval, the operator will point to many potential subscribers;
• VPN / intermediary servers: IP geolocation may indicate the city of the server, not the user's actual location;
• The User-Agent is not evidence — information about a "Pixel 6" or "iPhone17,3" comes from the UA and can be forged; the real evidence is the IMEI;
• Time differences: services may record events in UTC; normalise all times to CEST in the analysis.

A sample fragment of a request to the operator

"On the basis of the provisions of the Act of 12 July 2024 – Electronic Communications Law (Journal of Laws 2024, item 1221), which on 10 November 2024 replaced the Telecommunications Law, in connection with the pending pre-trial proceedings ref. <case reference>, the Police kindly request the disclosure of telecommunications data and the data of the subscriber or end user associated with the following IP addresses in the specified time intervals:

Scope of the requested data:

1. Subscriber or end-user data
   • first name and surname or company name,
   • PESEL or NIP number (if available),
   • installation address (service address / access-point address),
   • contact details (phone number, e-mail address, if present in the operator's system),
   • contract status (active / terminated, contract type: prepaid, postpaid, fixed, mobile).
2. Technical and operational session data:
   • full NAT / CGNAT translation mappings (external_IP:source_port ↔ internal_IP:port ↔ session identifier) together with precise timestamps (in UTC and CEST);
   • the SIM / device identifiers assigned to those sessions: MSISDN, IMSI, ICCID,
   • the IMEI numbers of the devices (with the manufacturer and model indicated, if available in the operator's IMEI database);
   • the exact start and end time of each session;
   • mobile or fixed network identifiers: BTS / eNodeB / CellID / APN / GTP TEID or, for fixed connections, DHCP / PPPoE logs and the MAC of the end device (CPE);
   • the approximate location resulting from the network logs (access-point address, base station, access node).
3. Form of data transfer:
   • the data should be provided in electronic format (CSV, TSV or JSON) together with a description of the fields and time formats,
   • the files should be accompanied by checksums (e.g. SHA-256) to ensure integrity,
   • please provide the response through official channels to the indicated Police address or via a secure SFTP/FTP channel."

Operational recommendations (step by step)

1. Obtain and secure the Facebook Takeout from the victim — record the checksums.
2. Preliminary analysis and creation of a timeline (indicating key events and IPs).
3. The Police submit requests to the operators with precise time intervals and a demand for NAT mappings and IMEI/IMSI/MSISDN.
4. After receiving the operator's logs — correlation of IMSI ↔ IMEI ↔ external_IP:port ↔ timestamp.
5. If necessary: securing the devices (imaging the phone/computer) and further expert examination.

An invitation to cooperate

The practice of a court expert in IT and telecommunications offers comprehensive support to law enforcement in cases involving unauthorised access to accounts, online fraud and establishing the sources of logins. We help identify and safely download digital data (e.g. Facebook Takeout archives) and analyse it in terms of IP addresses, devices, password changes and user activity. Based on the results of the analysis, we prepare drafts of formal requests to telecoms operators compliant with Article 218 § 1 of the Code of Criminal Procedure and the data-retention provisions of the Electronic Communications Law, indicating the scope of data that will make it possible to unambiguously identify the perpetrator (subscriber, device, location). After receiving the operators' replies, we correlate their logs with data from internet services and prepare an expert opinion together with analytical annexes and final conclusions. We also provide substantive support for further procedural activities and the interpretation of telecommunications data.