An online fraud has been linked to an IP address. What happens next?¶

Preserve the complete event and its context, not a copied IP address on its own.

The retailer says that its system recorded a successful checkout on account 884219 at 14:36:42 UTC. It has linked request 7F3A91 to source IP address 198.51.100.27.

The record is useful because it identifies an event, time, account, request and address together. An IP address copied into an email or statement would lose much of that context.

Before relying on the record, work through the immediate checks:

• Event meaning: confirm what checkout_complete and status=success mean in this system.
• Record linkage: establish how request 7F3A91 connects the checkout, account and source-IP entries.
• Time: retain the full timestamp and time zone, including seconds and the UTC basis.
• Available context: ask whether ports, session identifiers and surrounding events exist.
• Record form: establish whether this is an original export, a generated report or somebody's summary.

An online service records what its systems can see. A content-delivery network, reverse proxy or other intermediary can affect the source field. Establish where the address came from and what the recording system could see before treating it as the customer's connection.

Go deeper: Do you have the original record? · What event did the system actually record? · What information should come with an IP address?

The record contains enough context to progress, while the limits remain clear.

An IP address becomes useful when it can be tied to a defined event and time. Before deciding where to go next, check the value against the retailer's record:

• Complete value: 198.51.100.27 contains all four parts of an IPv4 address.
• Relevant event: it is linked to the completed checkout through request 7F3A91.
• Precise time: the record includes the date, seconds and UTC time basis.
• Public or private: it is not within a private range normally used only inside a home or organisation.
• Recording point: Step 01 established what the retailer's source-IP field represented.

The address from the retailer's record is:

Four decimal values separated by dots: the familiar written form of an IPv4 address.

This is IPv4. The format explains what kind of address has been recorded; it does not identify who used it.

The lead is usable. Use an IP registration or network lookup to identify the organisation responsible for the address range and obtain clues about the kind of network involved. A reverse-DNS lookup may add a hostname. Neither result identifies the customer or user.

The result might point to a home or business ISP, mobile network, workplace, public Wi-Fi operator, VPN, proxy or hosting service. That classification shapes the next enquiry.

Go deeper: Is this a valid and complete IP address? · Can an IP address identify a location?

The lookup points to NorthNet Broadband Ltd and an ordinary fixed-broadband range.

The lookup produces the following return:

NorthNet is now the likely holder of allocation records for this connection. That makes a provider enquiry a reasoned next step - not an automatic reaction to seeing an IP address.

Use the appropriate legal and organisational process. Frame the enquiry around the connection seen by the retailer at the recorded time, and ask the provider to explain any qualification affecting the match.

Large providers may operate different ranges for different services, and public registration data can be broad, stale or administrative. A provider name does not by itself reveal the service or user.

Compare other routes: Home or business ISP · Mobile network · Workplace or organisation · Hotel or public Wi-Fi

The provider needs the exact address and event time; other record holders may need prompt preservation.

Before the enquiry leaves, verify the request:

• Preserves the recorded time: retain the date, seconds and UTC basis exactly as supplied.
• Explains the event: state that the address was recorded as the source at completed checkout.
• Includes matching fields: supply any source port, protocol or session identifier held with the same event.
• Tests the clock: record any known offset, uncertainty or reason to question whether the timestamp can be trusted.
• Invites qualification: ask whether dynamic allocation or shared addressing affected the match.

If the network uses CGNAT, a source port and sometimes the protocol may be needed to distinguish one customer's session from others sharing the public address.

The retailer, NorthNet and collection service may hold different records for different periods. Where justified, make a defined preservation request using the relevant identifiers and time window. Record the holder, scope, reason, reference and any expiry or renewal date.

Preservation protects material that still exists within the stated scope. It does not disclose that material or replace the authority required to obtain it.

Go deeper: What should be preserved before relevant records disappear?

The event matches a household broadband service, but the named subscriber does not appear in the retailer records.

NorthNet returns the following result:

This is a significant but qualified lead. The investigation now has a household internet connection and installation address associated with the event. Jordan Morgan is the account holder, but that name does not appear in the retailer's transaction or collection records.

• Address and time: confirm that both exactly match the values supplied.
• Allocation logic: record whether the address was dynamic, shared and whether a source port was required.
• Subscriber meaning: establish whether Jordan is the account holder, bill payer or another type of customer contact.
• Service location: distinguish the installation address from an assertion about where any device or user was located.
• Qualifications: retain any caveat, ambiguity or limitation in NorthNet's wording.

A household service can be held in one person's name and used by several residents, visitors and devices. The subscriber's name is an account fact, not an identification. The subscriber result does not identify a particular device or prove that it was physically inside the property.

Go deeper: What can local DHCP, router and Wi-Fi records show?

Address enquiries, account history, telephone data, CCTV and witness evidence begin to develop Alex Morgan.

The retailer's account history first identifies another person: Alex Morgan. Further proportionate enquiries move the investigation beyond the IP evidence:

NorthNet did not name Alex. It supplied a connection and household address; familiar investigative evidence now tests who had access and develops Alex as a suspect.

Treat each identifier and observation as a separate line of enquiry. Establish the provenance and reliability of the email address, telephone number, retailer account, collection record, CCTV and witness evidence. Build a timeline showing which source connects which event, account, address or person.

An account or number may be shared, transferred, spoofed or used by somebody else. A resemblance on CCTV is not necessarily an identification. Repeated use of the same IP address across events may support an association but does not prove a common user.

The next step should answer defined evidential questions about accounts, devices, access and responsibility.

Several records now converge on Alex, but identity and responsibility still need to be tested. Further provider enquiries, interview, search, seizure and digital examination should flow from the facts and the questions still open.

• Which device accessed the retailer account and completed the transaction?
• Are the retailer or email accounts present on a device associated with Alex?
• Are the stolen payment details, collection message or purchase records present?
• Is there evidence of linked transactions or further victims?
• Could another resident, device user or account user explain the activity?
• Could relevant material be held in an online account rather than on the device?

A live, locked, encrypted or remotely managed device may require immediate decisions. Relevant email, application or cloud material may not be stored locally. Finding a device at the subscriber address would still not prove that it completed the transaction; the examination and wider evidence must test that proposition.

This walkthrough only signposts those on-scene and examination issues. Continue into the mobile and device examination guidance, including what to ask a digital-forensics unit before relying on its report.