How to Report Network Abuse Associated With an IP Address

An IP abuse report asks a network or service operator to investigate a specific event, such as repeated failed logins or harmful traffic. Check how your system recorded the source IP, save the event time and connection details, and find the operator's abuse contact. Record times in Coordinated Universal Time (UTC) so both sides can match their records. Describe what your system observed; an address's reputation or category alone is not evidence of an abusive event.

An IP address can identify a subscriber connection, NAT gateway, proxy, VPN server, Tor exit, shared hosting system, compromised device, or other intermediary. It does not by itself identify a person or prove who performed an action. Registration records identify organizations associated with Internet number resources; the registry, registered organization, and apparent traffic source are not necessarily the same actor.

What should I check before sending an abuse report?

First determine whether a network-abuse report is the right type of report:

For scans, exploit attempts, abusive login traffic, denial-of-service traffic, or other connections received from an address, contact the relevant network or service operator.
For a phishing page, malware download, fraudulent account, or other hosted content, report the exact URL, hostname (the DNS name of the host or service), account, or content to the hosting provider or platform. The IP address may be shared or operated by a content delivery network (CDN), a service that delivers content through distributed servers.
For a vulnerability in a product or service, use the vendor's vulnerability-disclosure process, which may be published through security.txt.
For a credible and imminent threat to a person, contact the appropriate emergency or law-enforcement authority in addition to taking technical measures. An abuse desk is not an emergency service.

Before sending a network-abuse report:

Confirm that the address came through a trusted logging path.
Base the report on an event your system observed, not solely on an IP reputation score, blocklist entry, VPN classification, or scanner tag.
Use accurate UTC timestamps from a synchronized clock. Include the sender's and recipient's IP addresses and ports from the same connection when available. A port is a number distinguishing an application or exchange of data at an IP address. Include the protocol, such as TCP or UDP, which defines how the traffic is exchanged. Record which system captured these details (the observation point).
Describe the observed behavior and outcome without claiming that the address holder, network, or provider was the actor.
Preserve the original evidence and send only the necessary, redacted portion.
Apply appropriate rate limits, blocks, account protections, or other mitigations without waiting for the recipient to respond.
Use the most specific applicable abuse contact rather than sending the report to IANA or a Regional Internet Registry (RIR) merely because its name appears in the allocation chain.

A provider, proxy operator, hosting company, or registered address holder may be in a position to investigate an event without having caused, authorized, or known about it.

How do you verify the address before reporting it?

Identify the system that recorded the event (the observation point) and how it obtained the reported address. For a direct connection, the address of the system that connected directly to the Internet-facing server (its immediate peer) is normally the relevant source address. If the connection passed through a CDN, load balancer, reverse proxy, or service mesh, follow the real-client-IP workflow.

Trust forwarding information only when the immediate peer is an authorized proxy.
Ensure the trusted proxy removes or overwrites client-supplied forwarding values.
Do not report the leftmost value from an untrusted X-Forwarded-For header.
Record whether the address came from the accepted socket, a provider edge log, PROXY protocol, or another trusted field.

Check whether the address could have been globally reachable at the observation point. In a public Internet-facing log, private-use, shared address space, loopback, link-local, and documentation addresses usually indicate a local-network, translation, proxy, parsing, anonymization, or logging issue rather than an external abuse contact.

Do not assume that every special-purpose address has the same properties. IANA separately records whether each special-purpose range is usable as a source, usable as a destination, forwardable, and globally reachable.

Also distinguish event-time evidence from a later lookup. Current RDAP, WHOIS, routing, geolocation, or reverse-DNS information does not establish who was using a dynamic or transferred address at the time of an older event.

What evidence should an IP abuse report contain?

Evidence	Why it matters
Accurate UTC timestamp	Lets the recipient correlate the event with NAT, DHCP, authentication, subscriber, proxy, or service logs. Include the clock source or estimated accuracy when relevant.
Source IP and source port	Helps identify a particular connection behind a shared public address. The port must come from the same connection and observation point as the source IP.
Transport or network protocol	Distinguishes TCP, UDP, ICMP, and other traffic that may have different state and mapping records.
Destination IP, port, and service	Identifies the endpoint that received the activity. Include the destination hostname, service, or virtual host where relevant.
Observation point and address derivation	Explains whether the address was the immediate peer or came from trusted proxy metadata or an edge log.
Observed action and outcome	Describes what happened instead of relying on a generic label such as “malicious IP.”
Event count and time range	Shows the scope and rate of repeated behavior. Include representative events or a per-event list as appropriate.
Redacted logs, packet evidence, or request IDs	Provides evidence the recipient can correlate with its records without exposing unrelated information.
Report ID and reply contact	Allows both parties to refer to the same case and request additional evidence safely.

RFC 6302 recommends recording the source port and a UTC timestamp accurate to the second or better from a traceable time source. The guidance applies to Internet-facing servers and load balancers. These details are particularly important because NAT implementations can reuse source ports and a public address alone may not identify the relevant subscriber or internal connection.

A timestamp that contains milliseconds is not necessarily accurate to a millisecond. Clock synchronization and estimated error matter more than the number of displayed decimal places.

The source and destination IP addresses, their ports, and the protocol form a connection tuple. Keep them together with the event time and recording location, and check that all describe the same event:

timestamp;
source IP;
source port;
destination IP;
destination port;
protocol; and
observation point.

Do not combine a client IP captured at a CDN edge with a source port captured on the connection between the CDN and your application. RFC 6692 similarly requires an abuse report's source port to correspond to the source IP from the same TCP connection.

If your application is behind a proxy, the application's immediate source port is normally the proxy's port. The original client port may be available only in the edge connection log or trusted connection metadata. Do not infer it, copy it from a different event, or apply one sample source port to every connection.

For protocols without ports, do not invent port values. For ICMP, include the IP version, ICMP type and code, and identifiers or sequence numbers where relevant.

For repeated activity, include at least:

The first and last observed event times.
The total event count and relevant rate.
Representative event records in the message body.
A per-event list of timestamps and connection tuples when subscriber or NAT correlation may be required.

Preserve the original logs or packet evidence. Send a redacted copy and remove passwords, raw cookies, session tokens, API keys, authorization headers, private keys, and unrelated personal data. Do not remove the timestamps and connection fields needed to investigate the report.

How do you find the correct abuse contact?

Look up the address in IP Lens and note the relevant registry, prefix, registered organization, ASN, and any identified hosting, VPN, proxy, or CDN service.
Verify the destination against the current RDAP record, the appropriate RIR lookup, or official operator information.
Prefer an explicit abuse contact associated with the most specific applicable network or customer registration.
If that record has no usable abuse contact, follow its referral, parent registration, or operator information.
If a hosting, VPN, proxy, CDN, cloud, or platform service is clearly identified, check its official abuse form or reporting policy as well.
Record when the lookup was performed and where the report was sent.

RDAP provides structured registration data and can refer a query to the registry responsible for the resource. Terminology differs by registry: ARIN publishes Points of Contact with roles such as Abuse, RIPE uses abuse-c and an associated abuse-mailbox, and APNIC records may direct reporters to an abuse-c, Incident Response Team (IRT), mnt-irt, or National Internet Registry (NIR).

Use the most specific applicable registration, not simply the smallest prefix displayed by a tool. A child assignment may publish its own abuse contact, while another address may intentionally inherit the parent network's contact. In parts of the APNIC region, a referral to an NIR may need to be followed before the relevant provider or customer record is found. An Internet Service Provider (ISP) is the company supplying Internet access.

Registration data describes Internet number-resource registration. The listed organization may be an ISP, customer, reseller, hosting provider, address lessor, infrastructure operator, or historical registrant. It is not proof that the organization or one of its employees generated the traffic.

IANA coordinates Internet number resources, while the RIRs administer their respective registries. They do not operate most registered networks and are not general enforcement desks for traffic associated with those resources. ARIN, for example, states that it does not operate the networks in its registry and cannot investigate or stop unwanted network activity.

If a published abuse contact bounces or is clearly invalid, use the relevant registry's invalid-contact or registration-inaccuracy process. That process reports a registry-data problem; it is not a substitute for sending the abuse report to the network operator.

Read how IANA, RIRs, WHOIS, and RDAP records relate for more detail.

What should an IP abuse report look like?

Subject: Network abuse report: 240 failed login attempts from
         203.0.113.24 — 2026-08-23 UTC

Hello,

Report ID: EXAMPLE-2026-0823-017
Reporter: Security Operations, example.net
Reply contact: security@example.net

We observed repeated failed login attempts from the address below.

Observation point: Internet-facing reverse-proxy edge
Client address source: immediate TCP peer recorded by that edge
Clock: UTC, NTP-synchronized; estimated error below 1 second

First event time: 2026-08-23T09:41:27.318Z
Last event time:  2026-08-23T09:51:16.902Z
Event count: 240

Sample event:
  Event time:       2026-08-23T09:41:27.318Z
  Source IP:        203.0.113.24
  Source port:      53144
  Destination IP:   198.51.100.10
  Destination port: 443
  Transport:        TCP
  Destination:      login.example.com over HTTPS
  Request ID:       req-7fa91d2e
  Result:           authentication rejected

Observed behavior:
  240 failed login attempts against 37 distinct account identifiers
  during the stated interval.

Observed outcome:
  No successful authentication was observed in this event set.

Action taken:
  The source was temporarily rate-limited.

A redacted per-event list is attached. Each record contains its own
UTC timestamp and connection tuple because source ports vary between
connections. The evidence does not contain passwords, cookies,
authorization headers, session tokens, or account identifiers.

Please investigate this activity under your applicable policies.
Please refer to the report ID above if additional event information
is required.

Regards,
Security Operations
example.net

The addresses in this example are documentation addresses and must be replaced with the actual verified endpoints. Do not include a field merely because the template contains it. Mark an unavailable value as unknown or omit it with a brief explanation. Never guess a source port, destination, protocol, or client-address origin.

Keep addresses, ports, protocol, and timestamp together only when they describe the same event at the same observation point. If necessary, provide separate fields such as:

Edge client address: 203.0.113.24:53144
Edge observation time: 2026-08-23T09:41:27.318Z

Backend peer address: 192.0.2.15:41872
Backend observation time: 2026-08-23T09:41:27.326Z

Describe facts rather than calling the registered organization, provider, subscriber, or address holder “the attacker.”

What special cases change the report?

Shared or Carrier-Grade NAT address: An accurate timestamp, external source IP and source port, destination endpoint, and protocol are especially valuable. Without the public source IP, its source port, the protocol, and sufficiently accurate time, the provider may not be able to correlate the event with a subscriber or internal mapping. Attach each relevant event's connection details rather than assigning one sample port to the entire incident.
Dynamic or transferred address: The current subscriber, customer, route origin, registration, or reverse-DNS name may differ from the event-time state. Always include the event timestamp and do not present a later lookup as historical assignment evidence.
VPN, forward proxy, or Tor exit: The visible address identifies an intermediary, not necessarily the originating user. Report the specific event to the operator's published contact when available, but do not assume that the operator can identify the originating person. For a suspected Tor exit, check whether the address was listed as an exit at the event time instead of relying only on its current status. The Tor Project points to ExoneraTor for querying past Tor relay lists by address and date.
Spoofed or reflected traffic: An isolated TCP SYN can carry a forged source address. A completed TCP handshake or application-layer exchange is stronger evidence that return traffic reached the apparent source, although the address may still represent a proxy, NAT gateway, compromised host, or other intermediary.; UDP, ICMP, and some reflected attacks can use forged source addresses. In a reflection attack, a reflector may see the victim's address as the source of the triggering request. Do not report the apparent victim as the actor merely because that address appears in the request received by the reflector. If you receive reflected responses, identify the reflectors and exposed services separately and include packet direction and protocol evidence.
CDN, shared hosting, or hosted content: An address may serve many unrelated customers or may belong to a globally distributed CDN edge. For phishing, malware, fraudulent storefronts, or other hosted content, include the exact URL, hostname, virtual host, account, certificate name, and observation time where appropriate. Use the provider's content-abuse or platform-abuse channel rather than relying only on the network-registration contact.
Identified research or measurement scanner: Before reporting a low-volume scan, check whether the source publishes an explanation and contact through reverse DNS, an address-hosted page, the probe payload, or /.well-known/probing.txt.; RFC 9511 defines /.well-known/probing.txt for describing Internet measurement probes. It also warns that probe-attribution information is not authenticated and must not be blindly trusted. Treat it as an investigative lead, verify it independently, and continue to apply your normal security controls.
Broad prefix or ASN pattern: Provide evidence for the individual addresses and events that support the pattern. A prefix or ASN can contain unrelated customers, services, resellers, or workloads and is not automatically evidence of one actor. Avoid requesting that an entire ASN or broad prefix be blocked unless the evidence and operational impact justify that request.
Protocols without ports: For ICMP or other protocols without TCP- or UDP-style ports, include the protocol number and relevant protocol-specific fields. Depending on the event, these may include:; ICMP version, type, and code.

Echo identifier and sequence number.

Quoted packet headers contained in an ICMP error.

Fragment identifiers.

Packet direction, size, flags, and capture interface.; State that source and destination ports are not applicable instead of entering zero or an invented value.

What should you do after sending the report?

Keep a record of:

The recipient and reporting channel.
The sending date and time.
The report ID and email subject.
The evidence version or file hash.
Any delivery failure, automated response, or case reference.
Later correspondence and materially new evidence.

Monitor the behavior and continue applying controls based on what your systems observe. Do not assume that a report will stop the activity, identify the originating person, or produce a reply.

Avoid repeatedly sending identical reports while the recipient's published response window is open. Follow up when you have materially new evidence, the behavior has significantly escalated, or the stated response period has passed.

If the contact bounces or is clearly stale, try the operator's official reporting channel and submit an invalid-contact report to the relevant registry. Both ARIN and APNIC publish processes for reporting inaccurate or invalid registration contacts.

Protect both the original evidence and the report because they may contain personal data or security-sensitive details. Retain them only as long as required by your documented security purpose, retention policy, contractual obligations, and applicable law.

For an immediate danger to people or a serious ongoing crime, use the appropriate emergency, law-enforcement, legal, or incident-response channels rather than relying solely on an abuse mailbox.