How do I know if an IP is malicious?

Look for recent observed attack behavior, repetition, threat classification, supporting network context, and confidence. No single country, VPN, hosting, or ASN label proves malicious intent.

Can I check an IP without creating an account?

Yes. FraudGuard IP Lookup provides a public investigation view without registration or payment.

What does a high-risk IP score mean?

It means the provider found signals associated with elevated risk. Review the evidence and request context before deciding whether to challenge or block.

Is one bad IP enough to block a whole network?

Usually not. Investigate repetition across the prefix or ASN, measure legitimate traffic, and prefer the narrowest effective control.

How to Check if an IP Address Is Malicious

When a suspicious IP appears in a login log, WAF alert, payment review, or incident timeline, the goal is not to collect another score. The goal is to make a decision that is fast, proportionate, and explainable.

Use the process below for one address. For larger datasets, follow How to Investigate Suspicious IPs at Scale.

Step 1: verify the source

Confirm that the value is a valid public IPv4 or IPv6 address and that your application extracted it from a trusted source. If traffic passes through a CDN, reverse proxy, or load balancer, use only the client-IP header that your infrastructure controls.

Record the UTC timestamp, route, account or tenant, request outcome, and why the event became suspicious. Those fields will matter when external evidence is ambiguous.

Step 2: run a reputation lookup

Open FraudGuard IP Lookup and review the full result, not only the risk label.

Prioritize:

observed attack behavior and threat family;
first- and last-seen times;
recent event volume and repetition;
confidence factors and recommendation reasons;
targeted services, protocols, or ports;
network, ASN, provider, prefix, and infrastructure context;
geography and customer-specific list context.

Direct, current behavior is more useful than a generic infrastructure label.

Step 3: ask whether the evidence matches your event

An IP can be malicious in one context and irrelevant in another. Compare the lookup with what happened in your system:

Does the observed attack family resemble the request?
Is the activity recent enough to influence a live decision?
Did the source target one account or many?
Are there impossible request rates or repeated failures?
Is the IP a known partner, office, monitor, or customer integration?
Would a block interrupt a low-risk page view or a high-value transaction?

Matching independent evidence increases confidence. A mismatch may still justify monitoring, but it weakens the case for a hard block.

Step 4: investigate the surrounding network carefully

Review the prefix and ASN when the address appears to be part of a wider campaign. Use Advanced Threat Lookup to find related FraudGuard observations.

Do not assume every address on a provider is connected. Large cloud and consumer networks host many unrelated users. Look for common timing, target, payload, account, threat family, or request pattern.

Step 5: choose an action

Evidence	Action
No relevant malicious evidence; normal request	Allow and log
Unknown or stale result	Monitor or use application-level controls
Ambiguous evidence on a sensitive action	Challenge or step up authentication
Excessive automation without strong attack evidence	Rate-limit
Recent repeated attack observations with high confidence	Block temporarily and alert

The safest production systems support several outcomes. Binary allow/block rules create unnecessary false positives when uncertainty is real.

Step 6: record and revisit the decision

Log the evidence timestamp, action, reasons, policy version, cache duration, and any analyst override. Set expiry times on blocks and allowlist entries. If a legitimate user is affected, provide a reviewed dispute path instead of asking support to reverse-engineer an anonymous firewall rule.

Red flags in an IP lookup process

the tool returns a score but no evidence;
the result has no observation date;
country, VPN, or hosting status is treated as proof;
a single IP automatically triggers an ASN-wide rule;
an outage silently becomes “block everyone”;
the team cannot explain the decision to a customer.

FraudGuard ACE v2 is designed to avoid the black-box pattern by returning explainable allow, challenge, or block guidance with observed activity, recency, confidence, and network context. Review the ACE v2 API when you are ready to automate the workflow.