AWS
Cloud Infrastructure
Security
Tutorials
Integrate AbuseIPDB Threat Intelligence with CloudQuery
TL;DR:
AbuseIPDB is a crowdsourced threat intelligence database that assigns abuse confidence scores (0-100) to IP addresses based on submitted reports. Sync your cloud inventory with CloudQuery, query AbuseIPDB for each public IP, and join the results in SQL to identify which cloud resources have flagged IPs - catching compromised infrastructure before it becomes a customer-impact event.
AbuseIPDB is a crowdsourced database of IP addresses that have been reported for malicious or abusive behavior - port scanning, brute force attacks, spam, DDoS participation, and similar activity. Security teams and system administrators submit reports when they observe abuse from an IP, and AbuseIPDB aggregates those reports into a confidence score that reflects how likely an IP is to be malicious.
For cloud security teams, AbuseIPDB answers a critical question: are any of your public cloud IPs associated with known abuse activity?
That question matters in two directions. Your cloud resources could be targets of abuse, or they could themselves be sources — appearing in AbuseIPDB because they've been compromised and are now sending spam, participating in botnets, or scanning other networks. Both scenarios warrant investigation, and both are easy to miss without automated checks.
Why Check Your Cloud IPs Against AbuseIPDB? #
Load balancers, public EC2 instances, RDS endpoints, and Kubernetes API servers attract automated scanning around the clock. Cross-referencing source IPs hitting your infrastructure against AbuseIPDB helps separate background internet noise from targeted activity — useful when deciding whether to tighten a security group rule or escalate to incident response.
The less obvious direction is outbound. When a cloud resource gets compromised through a vulnerable application, a leaked credential, or a misconfigured service, it often starts generating abuse: sending spam, joining botnets, scanning other networks. These compromised resources end up in AbuseIPDB. If any of your public IPs appear there with high confidence scores, something in your environment is worth finding.
There's also a practical business risk that has nothing to do with security posture. IPs on AbuseIPDB with high scores land on commercial blocklists. Your application server's IP ends up on one of those lists, and suddenly legitimate users can't reach your service, outbound email gets flagged as spam, and partner integrations start rejecting connections. Finding this during a routine check beats finding it through support tickets.
Finally, compliance teams are increasingly asking for documented evidence of IP intelligence monitoring — particularly for SOC 2 and security frameworks that require continuous monitoring of internet-exposed infrastructure. It maps cleanly and is easy to demonstrate.
Querying AbuseIPDB with CloudQuery #
The integration has three moving parts: a CloudQuery sync that builds your current IP inventory, a script that queries AbuseIPDB for each public IP, and SQL queries that join the results to identify which resources are flagged.
AbuseIPDB's Check endpoint accepts a single IP and returns a JSON object with the abuse confidence score (0–100), total reports, last reported date, usage type, ISP, and country. The Check Block endpoint can check an entire CIDR range at once, which is useful for checking your VPC CIDR allocations.
Store the API responses in an
abuseipdb_scores table in the same destination database as your CloudQuery data. A minimal schema looks like this:CREATE TABLE abuseipdb_scores (
ip_address TEXT PRIMARY KEY,
abuse_confidence INTEGER,
total_reports INTEGER,
last_reported_at TIMESTAMPTZ,
isp TEXT,
usage_type TEXT,
country_code TEXT,
checked_at TIMESTAMPTZ DEFAULT NOW()
);
Once both tables are populated, cross-referencing your inventory against AbuseIPDB data is a standard SQL join.
Example: Find Public IPs with High Abuse Confidence Scores #
The core query joins your CloudQuery cloud inventory against AbuseIPDB scores and filters for IPs above a confidence threshold. A score above 25 is generally worth reviewing; above 50 warrants immediate investigation.
-- Find cloud resources with public IPs flagged in AbuseIPDB
SELECT
'ec2_instance' AS resource_type,
i.instance_id AS resource_id,
i.region,
i.public_ip_address AS ip_address,
a.abuse_confidence,
a.total_reports,
a.last_reported_at,
a.isp,
a.usage_type,
i.tags->>'Owner' AS owner,
i.tags->>'Environment' AS environment
FROM aws_ec2_instances i
JOIN abuseipdb_scores a
ON i.public_ip_address = a.ip_address
WHERE
i.public_ip_address IS NOT NULL
AND a.abuse_confidence > 25
ORDER BY a.abuse_confidence DESC, a.total_reports DESC;
To check across multiple resource types in one query, use a UNION:
-- Check all public IPs across EC2 instances and Elastic IPs
WITH public_ips AS (
SELECT instance_id AS resource_id, 'ec2_instance' AS resource_type,
public_ip_address AS ip, region, tags
FROM aws_ec2_instances
WHERE public_ip_address IS NOT NULL
UNION ALL
SELECT allocation_id AS resource_id, 'elastic_ip' AS resource_type,
public_ip AS ip, region, tags
FROM aws_ec2_eips
WHERE public_ip IS NOT NULL
)
SELECT
p.resource_type,
p.resource_id,
p.ip,
p.region,
a.abuse_confidence,
a.total_reports,
a.last_reported_at,
p.tags->>'Owner' AS owner
FROM public_ips p
JOIN abuseipdb_scores a ON p.ip = a.ip_address
WHERE a.abuse_confidence > 25
ORDER BY a.abuse_confidence DESC;
The output gives you a prioritized list: the highest-confidence compromised IPs at the top, with the resource IDs and owner tags you need to route the finding to the right team.
Setting Up the Integration #
Step 1: Sync your cloud inventory with CloudQuery.
Configure the relevant source plugins (AWS, GCP, Azure) and run a sync to populate your destination database. Public IP addresses are captured automatically for supported resource types. See the CloudQuery documentation for provider-specific setup.
Step 2: Extract your public IPs.
Query your destination database for all distinct public IPs across relevant resource tables:
SELECT DISTINCT public_ip_address AS ip
FROM aws_ec2_instances
WHERE public_ip_address IS NOT NULL
UNION
SELECT DISTINCT public_ip
FROM aws_ec2_eips
WHERE public_ip IS NOT NULL;
Step 3: Query AbuseIPDB.
Send each IP to the AbuseIPDB Check endpoint using your API key. A basic curl call looks like:
curl -G https://api.abuseipdb.com/api/v2/check \
--data-urlencode "ipAddress=1.2.3.4" \
-d maxAgeInDays=90 \
-H "Key: $ABUSEIPDB_API_KEY" \
-H "Accept: application/json"
The response includes
abuseConfidenceScore, totalReports, lastReportedAt, isp, usageType, and countryCode. Write those fields into the abuseipdb_scores table.The free tier allows 1,000 checks per day. A typical AWS environment with 200-500 public IPs fits easily within that limit with daily checks. If your environment is larger, check IPs in batches across multiple days, prioritize production workloads first, or upgrade to a paid tier. The bulk report endpoint supports batch submissions for organizations generating their own abuse reports.
Step 4: Run the enrichment queries.
Use the SQL examples above to identify flagged IPs and trace them back to specific resources. Anything above 50 confidence score in a production environment should go to incident response immediately — don't queue it.
Step 5: Schedule regular refreshes.
AbuseIPDB scores aren't static. New reports come in, old ones age out. Set up a daily job that re-checks all current public IPs and triggers a re-check for any new IPs discovered during the CloudQuery sync. Existing IPs can accumulate new reports between checks; an IP that was clean last week might not be clean today.
It's one of the cheaper security controls you can add to a cloud environment. The data already exists in your CloudQuery destination; the only new piece is the AbuseIPDB API calls and a scheduled job to keep scores current.
Monitor Your Cloud Attack Surface with CloudQuery
Get StartedFAQ #
What is AbuseIPDB? #
AbuseIPDB is a crowdsourced database of IP addresses reported for abusive behavior including brute force attacks, port scanning, spam, and DDoS participation. It assigns each IP a confidence score (0–100) based on the volume and recency of reports.
How do I use AbuseIPDB with CloudQuery? #
Sync your cloud infrastructure with CloudQuery to capture all public IP addresses, then query those IPs against the AbuseIPDB API, store the results in your destination database, and join the datasets in SQL to identify cloud resources with high abuse confidence scores.
Can CloudQuery check IPs against AbuseIPDB? #
CloudQuery doesn't natively integrate with AbuseIPDB, but it captures all public IP addresses from your cloud resources as part of its standard sync. You can then query AbuseIPDB for those IPs separately and store the enrichment data in the same database for SQL-based cross-referencing.
What is a good AbuseIPDB confidence score threshold? #
A score above 25 is generally worth reviewing - it indicates a non-trivial number of reports. Scores above 50 warrant prompt investigation, particularly if the flagged IP belongs to a resource in your production environment. A score of 100 means the IP has been consistently reported by multiple sources and should be treated as actively malicious.
How often should I refresh AbuseIPDB scores for my cloud IPs? #
For production environments, daily refreshes are a reasonable baseline. AbuseIPDB report data changes as new abuse incidents are reported and older reports age out. New CloudQuery syncs should trigger a re-check of any newly discovered IPs. Pair this with your existing CloudQuery sync schedule so both datasets stay current.
Does AbuseIPDB have API rate limits? #
The free tier allows 1,000 checks per day. If your environment has more public IPs than that, batch your requests across multiple days or upgrade to a paid tier. Use the AbuseIPDB bulk check endpoint to check entire CIDR blocks at once, which can reduce API calls significantly for environments with contiguous IP allocations.
Can I use AbuseIPDB alongside other IP intelligence sources? #
Yes, and it's worth doing. AbuseIPDB covers abuse reports; it doesn't provide geolocation or ASN context. Combining it with ipinfo.io enrichment gives you both threat signals and network context for each public IP. The join pattern is identical - both datasets land in your destination database and join on IP address.
What cloud resource types have public IPs that I should check? #
EC2 instances with public IP addresses, Elastic IPs, NAT gateway allocations, and RDS instances with public endpoints are the most common. Application Load Balancers don't have static IPs but do have public DNS, so they're checked differently. Your CloudQuery asset inventory contains all of these resource types with their IP information.
