How a Developer Traced a Suspicious IP Using IPDekho

My phone went off at exactly 2:14 AM. It wasn't the usual slack notification or email ping; it was the high-priority PagerDuty siren that makes your stomach sink. I pulled myself out of bed, grabbed some cold water, and looked at the alert: "Critical egress traffic anomaly on database node db-replica-02." This replica server has one job: stay in sync with our primary database inside our private VPC. It should never push significant traffic to the public internet, let alone the 85 Mbps stream that was currently pegging our network graphs. We were looking at an active database dump in progress, and I had to stop it before the entire customer schema was gone.

Debugging the Server in Real-Time

I SSH'd into the replica node via our jump box to see what was running. Running top showed our CPU usage was normal, which meant the database wasn't struggling with complex calculations. But when I ran socket diagnostics using the socket statistics command: "ss -tanp | grep ESTAB", the culprit was right there. The ss output printed out: "tcp ESTAB 0 1280640 10.0.4.15:5432 185.190.140.35:49152 users:((\"postgres\",pid=14802,fd=9))" This socket line showed a connection from our PostgreSQL port 5432 established to the external IP address: 185.190.140.35. The send-queue column showed exactly 1,280,640 bytes (over 1.2 megabytes) of active data waiting to be pushed out over the network interface, which is a clear signature of an active, heavy data exfiltration event.

I ran a quick process lookup: "ps -fp 14802". The terminal printed "postgres: admin customer_db [local] COPY". Someone was running a raw SQL copy command, streaming our customer tables straight to that Romanian IP. I killed the process immediately with "kill -9 14802" and dropped the connection. I then modified our AWS security groups to block all outbound and inbound traffic to 185.190.140.35. The egress graph fell off a cliff. The leak was plugged, but we had to find out who owned this IP and how they got past our network perimeter.

Investigating the Target IP

I opened IPDekho and plugged 185.190.140.35 into the lookup search box. The geolocation lookup pointed to a datacenter in Bucharest, Romania. To get more context, I ran the ASN Lookup. The IP belonged to AS44901, owned by Voxility S.R.L. Voxility is a legitimate hosting provider, but their servers are frequently rented by malicious groups who use fake credit cards or crypto to spin up VPS instances for staging attacks or routing stolen data. This confirmed we weren't dealing with a home computer or an employee working remotely; it was a cloud-based server used for automation.

Next, I checked the reverse DNS records. The pointer (PTR record) resolved to "c-185-190-140-35.routed-by.voxility.net". A traceroute showed the network packets routing out of our AWS VPC, through transit networks in Virginia and Frankfurt, and terminating directly inside the Voxility infrastructure in Bucharest. The WHOIS records listed "abuse@voxility.com" as the contact point. I copied our logs, the socket connection timestamps, and the process details, and emailed a formal abuse report. The Voxility security desk responded within a few hours, confirming the tenant was running unauthorized scanning and proxy scripts, and they shut down the instance.

The Root Cause: A Dev Mistake

The external server was offline, but we still had to answer the most important question: how did they connect to our database port in the first place? Private databases should be completely isolated from the internet. I opened the PostgreSQL client authentication configuration file, "pg_hba.conf". When I scrolled to the bottom, I found the mistake. A junior developer had added "host all all 0.0.0.0/0 md5" earlier that afternoon. The config entry looked like this: # TYPE DATABASE USER ADDRESS METHOD host all all 0.0.0.0/0 md5 They were trying to test a replication script from their home connection and got tired of hitting firewall timeouts. They opened the database to the entire internet and whitelisted port 5432 in our AWS Security Groups, intending to revert it before they logged off for the evening. They simply forgot.

Automated scanners on the public internet find open database ports within minutes. The attacker's script discovered the open port, brute-forced the default admin credentials, and initiated the dump. We immediately removed the wildcard host rule from pg_hba.conf, rotated all database passwords, and restricted port 5432 access strictly to our internal network range (10.0.0.0/16). We also added automated checks to our deployment pipeline to reject any changes that open database ports to the public internet. This incident showed how quickly a simple human mistake can expose critical databases, but having fast network tools allowed us to trace and contain the leak before our customer records were lost.