Anatomy of a command-and-control IP
What a fraud score of 95 actually means. We walk one real C2 server through every signal ffraud saw, and why the score landed where it did.
A fraud score is only useful if you can see through it. So let's take one real IP that scores 95/100 and pull apart every signal behind that number, the same signals the API returns to you.
curl https://api.ffraud.com/public/ip/80.82.77.33#The verdict
The engine returns fraud_score: 95, risk: "critical", and a plain-English reason: an active command-and-control server confirmed by our honeypot sensors and repeated community reports. That last part is the whole game. One sighting is a rumor; the same IP hammering our honeypots and getting independently reported is evidence.
#The signals underneath
- Threat tags:
c2_server,malware_distribution. This is *what it was caught doing*, not just "abuse: true". - Infrastructure: a datacenter IP, not residential. C2 lives on rented boxes.
- Neighborhood: a chunk of the surrounding /24 is also flagged. Bulletproof hosting clusters.
- Recency: abuse confirmed within the last 30 days, so this is live, not a historical footnote.
- Confidence: high: multiple layers agree and we've watched it for a while.
Notice what is *not* here: we never expose the internal detection mechanics behind the flag. That's deliberate. The verified conclusion is the product; the machinery stays ours so it can't be gamed. The full logic is in how we score.
#What you do with it
At 95 you block, no hesitation. The value of the breakdown is the *edge* cases: an IP at 55 with a VPN flag and a clean neighborhood is a very different decision from a 55 sitting in a 70%-abusive subnet. The score compresses that; the fields let you un-compress it and write your own rule.
Every IP in the open database carries this same reasoning. Pull the whole thing from GitHub, or check one at a time. Both free.