Can hackers be traced? The short answer
Hackers and online scammers can sometimes be traced, but no single tool, IP address, or database proves who performed an act. Investigators build a timeline and correlate independent records: service and network logs, provider assignments, account activity, devices, communications, telephone records, payments, witnesses, and other case evidence. The result can identify infrastructure or an account before it identifies a person.
A public IP address is one lead. It may point to a household connection, company gateway, mobile carrier, cloud server, VPN, proxy, Tor exit, public hotspot, or compromised device. A precise timestamp, time zone, source port, protocol, and service context are often necessary to find the next relevant record. Even when a provider identifies a subscriber, that is not automatic proof of the human actor.
This guide is for victims, network operators, and incident responders who need to understand the evidence path and report an incident safely. It is not legal advice, a promise that a case will be investigated, or a guide to surveillance, retaliation, or unauthorised access. Legal authority, reporting routes, disclosure rules, and retention periods vary by country and case.
If a cyber incident is happening now
- Protect people first. If anyone is in immediate physical danger, contact local emergency services. Do not confront or threaten a suspected actor.
- Interrupt financial loss. Contact the bank, card issuer, payment service, or exchange through a verified channel as quickly as possible. Ask about its fraud process and record the case number. A payment may not be recoverable, but delay can remove options.
- Contain continuing access. Use a known-clean device to secure affected accounts, revoke active sessions, enable strong multifactor authentication, and involve the organisation's incident-response owner. For a business intrusion, containment and evidence preservation should be coordinated because powering off, wiping, scanning, or reimaging systems can destroy volatile evidence.
- Preserve originals. Keep full messages, email headers, call records, URLs, usernames, transaction identifiers, files, logs, and screenshots with visible dates. Do not edit the only copy, run a suspicious attachment, or send malware to people who are not authorised to receive it.
- Report through an official channel. Contact local or national police or the applicable national cybercrime portal. A platform, host, ISP, registrar, or abuse desk can address its own service, but an abuse ticket is not a police report.
Do not pay a stranger who claims they can “hack back,” secretly locate a person, recover cryptocurrency, or guarantee arrest. Such offers can be illegal, can destroy evidence, and are themselves a common follow-on scam.
What investigators can connect
| Record | What it may establish | What it does not prove alone |
|---|---|---|
| Website, app, or cloud log | A request, login, account, session, source IP and port, device token, or action observed by that service at a recorded time | The origin subscriber or person when the connection used shared or intermediary infrastructure |
| ISP, mobile, DHCP, or CGN record | An address or translated port assigned to a subscriber, circuit, device identifier, or internal endpoint at a compatible time | Which household member, employee, guest, application, or compromised device performed the act |
| Platform and identity record | Account creation, login, recovery, sessions, messages, linked identifiers, and retained subscriber details | That the named account holder controlled every session or supplied truthful registration details |
| Endpoint and network evidence | Files, malware, browser or application state, authentication artefacts, packet or flow records, persistence, and event timing | A complete history when data was not logged, has expired, was altered, or came from another device |
| Telephone and carrier record | Call routing, account, SIM or device identifiers, provider handling, and timing retained in a particular network | That displayed caller ID was authentic or that the subscriber was the caller |
| Payment, communication, and witness evidence | Control, benefit, intent, relationships, repeated behaviour, and continuity across events | The technical source of a connection unless it aligns with reliable network and device records |
Preserve facts, not conclusions. Record what a system observed, which clock and time zone produced it, how the record was acquired, and which identifiers connect it to another event. Labels such as “attacker,” “owner,” or “exact location” can overstate an early lead and bias later analysis.
How investigators trace a hacker or scammer
- Receive and triage the report. The report establishes what happened, when, where the evidence is held, the loss or safety impact, and whether activity is continuing. Agencies decide jurisdiction and priority; filing a report does not guarantee direct contact or an investigation.
- Preserve time-sensitive records. Victims and service providers retain relevant records through their approved process. Law enforcement may use preservation or disclosure mechanisms available under the applicable law. A request cannot recreate data that was never collected or was already deleted.
- Build an event timeline. Analysts normalize time zones, check clock drift, distinguish observation time from report time, and connect messages, logins, transfers, calls, and network events using stable identifiers.
- Identify the infrastructure layer. RDAP, routing, DNS, hosting, certificate, platform, and provider records can show who administers an address, domain, account, or service. They do not by themselves name the actor.
- Follow provider and account records lawfully. A service record may lead to an access provider, VPN, cloud tenant, email account, telephone account, or payment instrument. Each hop needs its own compatible timestamp and identifier and may be held in another jurisdiction.
- Examine devices and controlled systems. Qualified analysts may acquire and analyse endpoints, servers, accounts, or infrastructure under proper authority. They look for malware, credentials, files, sessions, communications, tools, and other artefacts that corroborate or contradict the network path.
- Test competing explanations. Shared access, account takeover, spoofed caller ID, remote access, compromised hosts, false registration data, clock errors, and missing logs can change the conclusion. A sound investigation keeps those alternatives visible instead of forcing every clue to one suspect.
Tools such as packet analysers, forensic suites, log platforms, RDAP clients, and OSINT systems help acquire or organise records. They do not confer legal authority, make an unreliable source accurate, or automatically identify a person. Chain of custody, reproducibility, proportional collection, and expert interpretation matter as much as the product name.
A public IP address is a lead, not a person
Registration and routing records can usually identify the organisation responsible for an IP range and the network announcing it. GeoIP databases can estimate a country, region, city, or service area. Neither source is a subscriber directory, GPS record, or proof of a home address. Mobile networks, anycast, hosting, VPNs, transfers, and stale databases can make location estimates especially misleading.
For a direct dynamic connection, the access provider may need the address and precise time to find an assignment record. With local NAT, that record may identify a household or organisation while internal router, DHCP, Wi-Fi, authentication, or endpoint evidence is still needed to distinguish devices. With carrier-grade NAT, many subscribers can share one public address at the same time.
Under CGNAT, the useful network tuple normally includes the source IP address, source port, protocol, and timestamp, with clocks precise enough to compare both ends. RFC 6888 describes the mapping information a carrier may need to identify a subscriber behind a shared address. Missing ports, broad time windows, clock skew, or absent mappings can leave several possible subscribers rather than one answer.
The separate IP tracing evidence guide explains dynamic assignments, NAT, CGNAT, VPNs, Tor, spoofing, and subscriber attribution in more technical depth. This page focuses on the wider cybercrime evidence chain and what a victim should preserve and report.
VPNs, proxies, Tor, cloud systems, and compromised devices
A destination normally sees the address of the last network intermediary that connects to it. That may be a VPN or proxy exit, a Tor exit relay, a cloud workload, remote desktop, corporate gateway, or infected device. The visible IP therefore identifies infrastructure at that observation point, not necessarily the access connection or person behind it.
A further link depends on records that actually exist, compatible timestamps, account or payment evidence, provider location, lawful access, and corroboration. A provider's “no logs” statement is a policy claim, not proof about every operational, billing, fraud, security, or historical record. Conversely, the existence of a provider record does not prove who controlled the account or device.
Investigators may also connect activity through reused accounts, recovery addresses, device identifiers, browser sessions, domain registrations, cryptocurrency or bank transfers, communications, language patterns, infrastructure configuration, or evidence obtained from a seized system. None of these guarantees identification. The defensible conclusion is the one supported by multiple independent records and explicit limitations.
Telephone and telco scam evidence
Displayed caller ID can be spoofed or can show a legitimate number used without the subscriber's involvement. The FCC explains that STIR/SHAKEN can help a voice provider authenticate or verify caller-ID information, but a verified number does not make a call legitimate. Victims should preserve the displayed number while treating it as one field, not the caller's proven identity.
| Preserve | Why it may help | Boundary |
|---|---|---|
| Call or message time | Lets providers compare routing, account, and device records; include time zone and whether the device clock was correct | A screenshot may omit seconds, time zone, routing, or account metadata |
| Number, account, and platform | Identifies the displayed number, messaging account, service, or conversation to preserve | Caller ID, a username, and a profile photo can all be spoofed or taken over |
| Voicemail, messages, and full exports | Preserves wording, links, attachments, headers, and continuity | Local law may restrict recording; do not secretly record or publish personal data without checking the applicable rules |
| Payment instructions and transaction IDs | Connects the approach to a bank, card, wallet, merchant, exchange, or recipient account | A mule or compromised account may sit between the payment and organiser |
| Carrier and device records | May connect call routing, account, SIM, handset, or network events under the appropriate authority | Availability, retention, and disclosure differ by carrier, jurisdiction, and record type |
Do not call a suspicious number using contact details supplied in the message. Verify the bank, government body, employer, or service through its official website, statement, or known app. Never disclose a password, recovery code, one-time code, or remote-control access because a caller creates urgency.
How to preserve evidence before you report cybercrime
- Create a factual timeline: record the earliest known event, exact date and time, time zone, device, account, service, and what you observed. Keep later actions—password changes, calls, transfers, containment, and reports—as separate events.
- Retain complete communications: save original emails with full headers, native message exports where available, voicemail, account identifiers, usernames, URLs, domains, telephone numbers, and unshortened links. Screenshots are useful context but should not replace the underlying record.
- Record financial details: preserve amounts, currencies, destination accounts or wallets, transaction IDs, merchant or exchange details, receipts, and the verified fraud contact used. Do not publish this information.
- Export relevant logs: preserve raw service, identity, endpoint, DNS, proxy, firewall, NAT, cloud, and application logs through the approved process. Include source and destination details, ports, protocol, result, account or session ID, correlation ID, and clock information when available.
- Protect integrity: keep originals read-only where practical, work from documented copies, record who collected each item and how, and use qualified forensic help for device or memory acquisition. NIST SP 800-86 describes identification, collection, examination, analysis, and reporting considerations for organisational incident response.
- Avoid contaminating the scene: do not wipe, reimage, “clean,” open suspicious files, log into a compromised system from an untrusted device, or run an improvised scan solely to create evidence. Containment may still be urgent; let the incident owner balance safety, recovery, and preservation.
- Minimise unnecessary disclosure: give sensitive material only to verified recipients with a legitimate need. Redact public posts, do not crowdsource identification, and do not accuse a person based only on an IP address, username, or phone number.
The FBI's Internet Crime Complaint Center says complainants should retain originals because law enforcement may later request relevant documents or evidence. Its form accepts technical details such as email headers, cryptocurrency transaction metadata, and ransomware hashes, but victims should follow the instructions for the official form rather than sending evidence to unofficial contacts.
How to report a hacker or online scam
- Use the reporting channel for your country. Europol tells members of the public to contact their local or national police; authorities coordinate with Europol when required. Its report-a-crime page links to national police routes in Europe.
- In the United States, use the FBI's official IC3 site. IC3 is the central intake for cyber-enabled crime complaints. A report can be shared with appropriate law-enforcement partners, but contact or investigation remains at the receiving agency's discretion.
- Report the service-specific abuse separately. Notify the affected platform, email provider, registrar, host, ISP, telephone carrier, or exchange through a verified security, fraud, or abuse channel. Include the case or ticket ID in your timeline. Service action can preserve an account or stop abuse, but it does not replace a crime report.
- Escalate organisational incidents. Activate the incident-response, legal, privacy, insurance, and communications owners required by your plan and jurisdiction. CISA's StopRansomware Guide emphasizes preserving volatile evidence and coordinating response for ransomware and data-extortion incidents.
- Keep the report current. Preserve the confirmation and case number. If the official channel accepts updates, add new losses, transactions, accounts, threats, or technical records without rewriting the original timeline.
A strong report states what happened, who or which account was affected, when each event occurred, the loss or risk, the identifiers observed, where original evidence is retained, and what containment or financial steps were taken. It should distinguish facts from assumptions and avoid exaggerating what an IP lookup or caller ID proves.
How do I report a hacker to the FBI?
For a US internet-enabled crime, start at ic3.gov and follow the official complaint route. The form asks about the complainant, financial transactions, subject identifiers, a description of the incident, and technical details. Include only accurate information; retain originals and the report confirmation. Immediate danger belongs with 911 or local police, and other FBI reporting categories may use different official routes.
Do not assume a direct reply means a report succeeded or that silence means it was ignored. IC3 states that complaints are analysed and may be referred, while any contact or investigation is discretionary. Be alert to impostors who claim they can accelerate an FBI case for a fee or ask for payment, credentials, or remote device access.
Can Wireshark or another tool identify a hacker?
Wireshark displays packets captured at a specific network interface or loaded from a capture file. It can help an authorised analyst understand protocols, endpoints, timing, retransmissions, and application behaviour visible at that point. It cannot retroactively capture traffic, decrypt protected content without the necessary keys, see records held by another provider, or convert an IP address into a person's identity.
Capture and monitoring must be authorised and lawful. For an incident on a network you manage, packet data is most useful when synchronized with application, identity, endpoint, firewall, DNS, proxy, and provider records. A commercial “trace IP” page, GeoIP lookup, breach search, or OSINT tool should be treated as a lead with source and date—not as a verdict.
Is it legal to hire a hacker?
Authorised security testing can be legitimate when a qualified professional has written permission, a precise scope, test windows, data-handling rules, safety limits, contacts, and reporting obligations from the systems' authorised owner. “Hack back,” account intrusion, interception, stalking, credential theft, or accessing someone else's device or service without authority is different and can be unlawful.
If someone offers to trace an attacker, recover funds, or access an account, verify their legal authority, identity, company, contract, insurance, methodology, and references. Do not supply credentials or pay a recovery fee based on a social-media message. Use law enforcement, a regulated financial institution, a trusted incident-response provider, and legal counsel appropriate to the case.
What network and IPv4 operators should do
Operators need a monitored abuse path, synchronized clocks, durable assignment and translation records, access controls, documented retention, preservation procedures, and a way to distinguish observations from attribution. An abuse report should contain enough data to locate the event without demanding unrelated subscriber information.
The network abuse handling guide is for operators that receive reports about their own address space; it covers intake, validation, containment, communication, and closure rather than acting as a public reporting form. If a report concerns i.lease-managed resources, use the registered abuse contact for the exact prefix or your existing authenticated customer support channel. Include the prefix, source IP and port, destination, protocol, timestamp with time zone, evidence source, and contact details. i.lease can investigate only its resource and customer boundary; it is not a police agency or a service for identifying private individuals.
Frequently asked questions
Can hackers really be traced?
Sometimes. Investigators correlate service logs, provider records, accounts, devices, payments, communications, and other evidence. Missing records, shared infrastructure, compromised systems, false account data, and cross-border access can prevent a conclusive identification.
Can a hacker be traced by an IP address?
An IP address can identify infrastructure or lead to a subscriber assignment at a specific time. It does not identify a person by itself. Dynamic addresses, NAT, CGNAT, VPNs, cloud servers, public Wi-Fi, and compromised devices require additional records and corroboration.
Can police trace a hacker using a VPN or Tor?
The destination usually sees the exit address. A further link depends on records that exist, lawful access, compatible timing, account or payment evidence, devices, and other case facts. Neither guaranteed anonymity nor automatic deanonymisation is a credible promise.
How do I report a hacker to the FBI?
For US internet-enabled crime, use the official FBI Internet Crime Complaint Center at ic3.gov. Describe the events and losses accurately, include available identifiers and technical details, retain originals, and keep the complaint confirmation. Use emergency services for immediate danger.
What evidence should I save after a hack or scam?
Keep a time-zoned timeline, full email headers or message exports, accounts and URLs, call records, transaction IDs, original files, logs, source IP addresses and ports, device details, screenshots, and every official report or ticket number. Protect originals and avoid unnecessary public disclosure.
Can Wireshark tell me who hacked me?
No. It can analyse packets visible at the capture point and help establish endpoints, protocols, and timing. It cannot identify a person, retrieve provider records, or reconstruct traffic that was not captured.
Can police trace a telephone scammer from caller ID?
Caller ID is one lead and can be spoofed. Investigators may need carrier routing, account, SIM or device, message, payment, and platform records. STIR/SHAKEN information can improve caller-ID verification but does not prove a call is legitimate or identify the human caller.
Should I hire someone to hack back or recover stolen money?
No one can guarantee attribution, arrest, or recovery. Unauthorised access or retaliation may be unlawful and can destroy evidence. Contact the financial provider, official reporting channel, qualified incident responders, and legal counsel, and treat unsolicited recovery offers as a possible follow-on scam.
Primary technical and official sources
- FBI Internet Crime Complaint Center (IC3)
- FBI IC3 official complaint form and evidence instructions
- Europol: report a crime through national police
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
- CISA StopRansomware Guide
- RFC 6888: Common Requirements for Carrier-Grade NATs
- US Department of Justice CCIPS electronic-evidence resources
- FCC consumer guidance on STIR/SHAKEN and caller-ID limits


