When Skype Leaked Your IP: Anatomy of a Legacy P2P Privacy Vulnerability

Hook

In 2014, knowing someone's Skype username was enough to find their physical location. The platform's peer-to-peer architecture inadvertently turned every user into a node broadcasting their IP address to anyone who asked.

Context

Before Microsoft's 2011 acquisition and subsequent infrastructure overhaul, Skype operated on a fundamentally different architecture than today's cloud-based messaging platforms. Built on a hybrid peer-to-peer model inspired by Kazaa, Skype routed calls directly between users to reduce server costs and improve voice quality. This design decision, while technically impressive for its time, created an unintended consequence: any Skype user could query another user's node and receive their IP address as part of the connection handshake—no friendship or prior contact required.

For OSINT practitioners and security researchers between 2010-2015, this represented a goldmine. A Skype username (easily discoverable through email-to-username API endpoints) could be converted into an IP address, which could then be geolocated to approximate physical location. PaulSec's skype-osint tool automated this reconnaissance pipeline, demonstrating just how trivial it was to surveil Skype users at scale. The tool emerged during the peak of Skype privacy concerns, when journalists, activists, and researchers were actively documenting how the platform's architecture fundamentally conflicted with user privacy expectations.

Technical Insight

The skype-osint architecture is deceptively simple, but its implementation reveals interesting choices about how to interact with obfuscated web APIs. At its core, the tool wraps the deprecated python-spidermonkey library—Python bindings for Mozilla's JavaScript engine—to execute JavaScript payloads against Skype's web endpoints. Why JavaScript execution instead of direct HTTP calls? Skype's web APIs in this era employed client-side JavaScript obfuscation and dynamic token generation that made simple curl requests insufficient.

The tool's primary class, SkypeOSINTAPI, provides two key methods. The first, get_skypeid_from_email(), hits an undocumented Skype API endpoint that resolved email addresses to Skype usernames—a feature intended for helping users find contacts, but trivially abusable for enumeration:

class SkypeOSINTAPI:
    def __init__(self):
        self.runtime = spidermonkey.Runtime()
        self.context = self.runtime.new_context()
        
    def get_skypeid_from_email(self, email):
        # Load JavaScript payload for Skype API interaction
        js_code = self._load_api_payload('email_resolver.js')
        
        # Execute JavaScript in SpiderMonkey context
        self.context.execute(js_code)
        result = self.context.execute(
            f"resolveEmail('{email}')"
        )
        return result if result else None

The second method, get_ip_from_skypeid(), is where the real privacy violation occurred. This function exploited Skype's P2P architecture by initiating a connection request to the target user. Even without the target accepting, Skype's protocol would return routing information including the user's IP address. The tool captured this network-layer information before the application-layer connection was established.

What's particularly noteworthy is the reliance on SpiderMonkey rather than Node.js or other modern JavaScript runtimes. In 2014-2015, embedding a full JavaScript engine into Python tools was uncommon. The author likely chose SpiderMonkey because it offered low-level control over JavaScript execution contexts and could run in a sandboxed environment—important when executing potentially untrusted or reverse-engineered JavaScript from Skype's web clients. The tradeoff was maintenance complexity; python-spidermonkey required compiling C extensions and has been effectively unmaintained since 2016.

The tool's data flow follows a classic reconnaissance pattern: email → Skype ID → IP address → geolocation. Each step required different API endpoints and exploitation techniques. The email-to-ID conversion used Skype's search functionality, while the ID-to-IP extraction required actually triggering Skype's P2P connection logic—likely by crafting specific XML-RPC or proprietary protocol messages that mimicked legitimate call initiation.

From a design pattern perspective, this represents the "API wrapper with runtime execution" pattern common in OSINT tooling. Rather than reverse-engineering Skype's protocols completely, the tool piggybacks on existing client-side JavaScript code, effectively using the official implementation against itself. This approach is brittle—any API changes break functionality—but rapid to develop and maintain during the tool's active period.

Gotcha

The fundamental limitation is temporal: this tool is a historical artifact, not a functional reconnaissance instrument. Microsoft's infrastructure migration eliminated the P2P architecture vulnerabilities between 2015-2017, rendering both the IP extraction and email enumeration functions inoperative. Modern Skype operates on Azure-hosted relay servers that deliberately obscure user IP addresses, and the email-to-username APIs now require OAuth authentication with strict rate limiting. Attempting to run this tool against current Skype infrastructure will yield nothing but timeout errors and API rejections.

Beyond obsolescence, the tool suffered from environmental brittleness even during its functional period. The python-spidermonkey dependency required compiling C extensions that frequently broke across Python version upgrades and operating systems. Developers attempting to replicate the tool today will find spidermonkey bindings incompatible with Python 3.x, and the underlying Mozilla library versions it expected are no longer available in modern package repositories. The tool also provided zero error handling for rate limits or captchas—Skype's API would temporarily block IPs after 10-15 rapid queries, and the tool had no backoff or rotation logic. For batch reconnaissance operations, this made it impractical without significant modification.

Verdict

Use if: You're studying the history of VoIP security, documenting legacy OSINT techniques for academic purposes, or teaching a course on privacy evolution in messaging platforms. The code provides excellent examples of how P2P architecture creates privacy vulnerabilities and demonstrates early-2010s API scraping patterns. It's valuable as a reference for understanding what modern platforms explicitly defend against.

Skip if: You need any functional OSINT capability against current Skype or messaging platforms. The tool is completely non-functional against modern infrastructure and serves no operational security research purpose. For contemporary username enumeration, use Sherlock or Maigret; for Microsoft ecosystem reconnaissance, work directly with the authenticated Microsoft Graph API. Even for historical Skype data, you're better off studying the documented CVEs and Microsoft's architecture migration whitepapers than attempting to resurrect a tool dependent on unmaintained libraries from the Python 2 era. This is a museum piece, not a toolkit.