Investigating a hostile IP: BGP tracing, anonymous cloud VPS, and phishing triage

I recently spotted suspicious requests hitting my system logs from a specific IP address: 199.91.221.83. Rather than simply dropping the packets at my local firewall and moving on, I decided to trace the origin, map the infrastructure, and take practical steps to neutralize the host.

Here is the step-by-step investigation and how I handled the threat.

1. Uncovering IP origin and BGP routing#

The first step in any traffic analysis is determining which Autonomous System owns the subnet. A standard WHOIS and BGP route lookup in the terminal returned the network profile:

whois 199.91.221.83 | grep -E "OrgName|OriginAS|NetRange|Country"

The lookup revealed:

• Organization: BL Networks
• ASN (Autonomous System Number): AS399629 (verified via whois -h whois.arin.net AS399629, as OriginAS in direct IP whois is often omitted)
• IP Range: 199.91.220.0/23 (NetRange: 199.91.220.0 - 199.91.221.255; target host lives within the 199.91.221.0/24 block)
• Infrastructure Type: Data center / VPS Cloud Hosting (registered via corporate registered agents in Sheridan, Wyoming)
• Registered Country: United States (US)

The address was not a typical residential broadband connection. It belonged to BitLaunch, a cloud hosting provider operating under its own BGP routing entity (BL Networks).

2. The mechanics of anonymous cloud hosting#

Looking closer into how this hosting provider operates explains why privacy-focused clouds attract both legitimate operators and threat actors seeking to evade identification:

1. Minimal account registration: No real name, billing address, or physical verification is required. Accounts are created with just an email and password.
2. Crypto-only transactions: Payments are settled using Bitcoin, Litecoin, or Ethereum, removing conventional banking audit trails.
3. Fast server destruction: When an instance is destroyed, storage volumes are wiped without retained cloud snapshots.

However, commercial registration anonymity is not total operational invisibility. Even when personal names are omitted from account forms, the provider infrastructure still records connection metadata, such as the management IP used to access the control panel. When unlawful conduct is documented, these connection logs can still be subpoenaed through formal legal channels.

3. Identifying phishing and filing an actionable abuse report#

Examining the open web ports on that host revealed a fake login page designed to steal user credentials.

Because anonymous hosting services actively protect their IP reputation to avoid global blocklists (like Spamhaus or SURBL), filing a well-documented abuse complaint directly with their trust and safety team is the fastest way to get malicious instances terminated.

To ensure the report was handled promptly, I included the five essential evidence points:

To: support@bitlaunch.io, legal@bitlaunch.io
Subject: [Abuse Report] Phishing infrastructure on IP 199.91.221.83 (AS399629)

Report details:
1. Malicious URL: https://fraudulent-domain.tld/login.php
2. Target IP: 199.91.221.83
3. Event timestamp: 2026-08-30 22:15:00 UTC
4. Evidence attached: Screenshot of the credential harvesting form and raw HTTP headers
5. Impact summary: The host is actively mimicking a banking authentication portal to harvest credentials.

Conclusion: next steps and takeaways#

Investigating hosts on privacy-centric hosting platforms requires understanding the boundaries of public registration data. Combining BGP routing discovery with an evidence-backed abuse report remains the most reliable method to take fraudulent infrastructure offline.

See also

Cybersecurity Introduction to RDAP on registro.br: the WHOIS successor

Cybersecurity Lintriage: a Bash script for forensic triage and incident response on Linux

Servers From 'no route to host' to virtual host: debugging standalone Nginx and cloud networking

This post is licensed under CC BY-NC.