Tracing a Suspicious IP During a Database Leak: A Walkthrough
Updated Published by Kishan Prajapat, SEO & Content Lead
Drafted with Citeya, an AI writing tool built by KPThink.
This is an illustrative scenario, not a report of a real incident. The people, companies, IP addresses (from the ranges reserved for documentation) and figures are made up to show how the investigation works.
At 2:14 AM an alert fires: a read replica called db-replica-02, which should only ever talk to the primary database inside a private network, is sending around 85 Mbps to the public internet. A replica with that much outbound traffic is almost certainly being dumped.
Stop the leak first
On the replica, ss -tanp | grep ESTAB lists established TCP connections with the process behind each one. One line stands out: PostgreSQL’s port 5432 has an established connection to 203.0.113.35, with a large send queue. ps -fp on that process shows a COPY running against the customer database. Killing the process and adding a deny rule for 203.0.113.35 in the cloud security group stops the transfer, and the outbound graph drops straight away.
Only then is it worth investigating. Containment comes before curiosity.
Find out who the IP belongs to
An IP lookup places 203.0.113.35 in a data centre, and an ASN lookup shows it is announced by AS64500, a VPS hosting provider. That already rules out a colleague on a home connection: this is a rented server, probably one of many an attacker uses and discards.
A reverse DNS lookup returns the provider’s generic hostname for the address, and the WHOIS record for the network block lists an abuse contact. Sending that contact the connection timestamps, the destination port and the process details gives the provider what it needs to act against the customer renting the server.
Find the hole
The real question is how an external server reached a database that should be private. In this scenario the answer is in pg_hba.conf: someone testing replication from home added host all all 0.0.0.0/0 md5 and opened port 5432 in the security group, meaning to revert both later. Automated scanners find open database ports within minutes, and a weak password did the rest.
The fix has three parts: remove the wildcard rule and restrict 5432 to the internal range, rotate every database credential (the attacker may have more than one), and add a deployment check that rejects any change exposing a database port to the internet. The last one matters most, because the mistake itself is easy to make again.
What to take from it
An IP address in your logs is where the investigation starts, not the answer. Stop the traffic, identify the network behind the IP, report abuse to the provider, and then fix the configuration that let it in. Our guide to port scanning explains why an exposed port gets found so quickly.
Check What Your Server Exposes
Scan your server’s public IP to see which common TCP ports are reachable from the internet.
Run a Port ScanSpotted a mistake? Tell usand we'll correct it.
Related Articles
Using IP and ASN Checks to Cut Checkout Fraud: A Worked Example
An illustrative example of how a small online store could use ASN and network-type checks to hold suspicious orders for review, and where those checks fall short.
Investigating an “Impossible Travel” Login Alert: A Walkthrough
An illustrative walkthrough of triaging an impossible-travel alert with WHOIS, reverse DNS and a port scan, and deciding whether it’s an attack or an employee on a VPN.
Diagnosing a Partial Outage After a DNS Change: A Walkthrough
An illustrative walkthrough: after a server move, some users reach the site and others time out. How cached DNS records cause it, how to confirm it, and how to avoid it next time.
WestJet first told Boeing about 737 MAX software g
Explains how WestJet first reported a 737 MAX flight-computer software glitch, why regulators delayed MAX 10 certification, and what airlines and crews must do now.