A real-world case study in passive threat intelligence and open-source investigation.

Disclaimer: This research was conducted exclusively for educational purposes and passive threat intelligence. No systems were breached, no credentials were used without authorization, and no sensitive identifying data is reported in this article. All information collected comes from publicly accessible sources: Shodan, public paste sites, blockchain explorers, and OSINT forums. Sensitive details such as IPs, domains, wallets, emails, and specific nationalities have been redacted. This activity falls within the legal scope of passive cybersecurity research, with no active interaction with the identified systems. Some parts of the article are redacted for safety.

Introduction

While working on threat intelligence research, I came across one of the most underestimated phenomena in the landscape of cryptocurrency fraud: the pig butchering scam. The name comes from the Chinese 杀猪盘 (shā zhū pán), literally “pig slaughter plate,” and the concept is as brutal as it is effective. The victim is “raised” for weeks or months through daily conversations on messaging apps, with relationships carefully engineered and patiently built, until the person is convinced to invest on fake crypto exchanges.

When the funds reach a critical threshold, they disappear.

What struck me while working on this was not only the level of social engineering involved, which is sophisticated in itself. It was the technical infrastructure underneath it: scalable systems, well organized, with a criminal supply chain that runs from scam-kit production to resale to local “franchisees.” Structured criminal organizations sell the kit to other groups or to individual operators, who then target ordinary people interested in investing in crypto but not sufficiently familiar with how blockchains and exchanges work.

It is a business model, complete with R&D, a B2B market, and post-sale support for the “operators.” I decided to understand how it works from the technical side.

Starting Point: Shodan

Shodan is a search engine for internet-connected devices. It is not an offensive tool by itself; in fact, it is widely used in blue team and threat intelligence for passive fingerprinting of exposed infrastructure. I started by refining a query to find servers hosting fake crypto exchanges, focusing on a set of recurring indicators: weak SSL certificates, characteristic HTTP banners, exposed ports, and geographic attributes consistent with the known origin of these kits.

Base query:

"crypto" "exchange" port:443 ssl.cert.subject.cn:*exchange*

From there, I iterated by adding progressive filters. In HTTP banners I looked for keywords such as “deposit,” “withdraw,” and “VIP tier,” which are almost invariably present in fake exchange interfaces to simulate the structure of a legitimate platform. I searched for servers with certificate CNs that cloned well-known exchanges through typosquatting, for example by substituting visually similar characters. I checked for the absence of rate limiting on critical endpoints such as /api/login and /api/transfer, a sign of poor implementation. I observed a recurring technology stack made up of Nginx with default configurations, PHP 7.x, and outdated crypto-related libraries.

The results returned hundreds of hosts, many with very low uptime, which is consistent with disposable infrastructure designed to be replaced quickly after each campaign. What stood out, however, was the strong homogeneity in architectural patterns across seemingly independent hosts. Same stack, same endpoint structures, same naming conventions. A clear signal: these were not separate actors who happened to have the same idea, but operators using the same kit, distributed and resold.

OSINT Correlation and Certificate Analysis

At that point, I selected a sample of IPs and conducted manual correlation, cross-checking Shodan data with other publicly available sources.

On the SSL certificate side, many hosts shared the same issuer, a little-known CA with certificates valid for 30 to 90 days. The absence of Let’s Encrypt or enterprise CAs is a meaningful indicator: whoever runs this infrastructure minimizes costs and rotates certificates frequently to avoid revocation and make long-term tracking harder.

On the ASN side, the IPs belonged to providers with neutral commercial names, often registered in jurisdictions with low KYC verification for hosting. A significant portion was already present in public blocklists such as AbuseIPDB and Spamhaus, which suggested reuse of infrastructure already known to reputation systems, probably because rotation times are still faster than blocklist cycles.

The most interesting part emerged while analyzing API endpoints. Several servers exposed /api/admin, /api/users, and /api/wallet completely open, or protected with default credentials such as admin:admin. These endpoints revealed data structures that confirmed the nature of the platform: internal wallets, transaction IDs, and VIP tiers artificially built to simulate the progression typical of a legitimate exchange and convince the victim that they were on a trustworthy platform.

Through OSINT queries on public repositories and paste sites, using keyword patterns tied to the exchange names I had identified, I found victim emails that had attempted to regain access after the funds vanished. Some of these emails were associated with traceable Ethereum wallets on-chain, which made it possible to partially follow the flow of stolen funds.

The most significant discovery from a supply-chain perspective was finding, on public forums, the sale of complete packages: registered domain, preconfigured exchange script, message templates for the social engineering phase, instructions on how to handle the victim during the “raising” period, and guidance on how to stall in response to withdrawal requests. The buyers of these kits were located in geographic regions different from Asia, confirming that the supply chain is genuinely transnational: production happens in one place, distribution and operational use elsewhere.

Exposed Elasticsearch: A Window into the Infrastructure

During the investigation I found something unexpected. Several servers belonging to the same criminal infrastructure exposed Elasticsearch instances without authentication, reachable directly over HTTP on port 9200.

I identified them by starting from the IPs already known from the Shodan phase and running a second targeted query:

product:elastic port:9200

Shodan was already indexing these nodes with complete metadata: cluster name, shard count, active indices, and Elasticsearch version in use. No active access was needed; everything was already passively leaked by the search engine, which by design indexes what is publicly exposed on the internet.

The index structure visible through Shodan spoke for itself. The field names were explicit: user_email, deposit_amount, vip_tier, withdrawal_blocked, wallet_address. The naming confirmed the identity of the kit used by the fake exchanges already identified, and the consistency across hosts further strengthened the hypothesis of a single origin.

To manage the volume of collected data more efficiently, I imported everything into a local Elasticsearch instance, building a repeatable and documentable analysis environment. I used ES|QL queries to isolate hosts with high-risk banner patterns, aggregate indicators by ASN, and correlate certificates, wallets, and IOCs in a single structured index. This turned a raw collection of heterogeneous data into actionable threat intelligence, searchable and updateable over time.

To automate the collection and parsing of Shodan data, I built a Python script, shared here in anonymized form without real credentials, purely to illustrate the method:

import requests
import json

API_KEY = "YOUR_SHODAN_API_KEY"
QUERY = "crypto exchange port:443 ssl.cert.subject.cn:*exchange*"

def fetch_shodan_results(query, api_key):
    url = "https://api.shodan.io/shodan/host/search"
    params = {"key": api_key, "query": query}
    response = requests.get(url, params=params)
    return response.json()

def parse_host(host):
    return {
        "ip": host.get("ip_str"),
        "country": host.get("location", {}).get("country_name"),
        "org": host.get("org"),
        "banner": host.get("data", "")[:200],
        "ports": host.get("port"),
        "ssl_cn": host.get("ssl", {}).get("cert", {}).get("subject", {}).get("CN", "N/A")
    }

results = fetch_shodan_results(QUERY, API_KEY)

for match in results.get("matches", []):
    parsed = parse_host(match)
    if any(kw in parsed["banner"].lower() for kw in ["deposit", "withdraw", "vip", "exchange"]):
        print(json.dumps(parsed, indent=2))

The banner filter reduces noise significantly, focusing the analysis on hosts with strong indicators rather than on the full perimeter returned by the raw query.

The Pig Butchering Kill Chain

Reconstructing the full chain, the operational structure of a pig butchering scam breaks into six distinct phases, each with clearly defined roles and technical tools.

In the first phase, kit deployment, the operator buys or develops an exchange clone. The stack is standardized, hosting is offshore, the domain is registered with privacy protection, and it typically has less than 90 days of age. The technical investment is minimal and the infrastructure is designed to be abandoned quickly.

In the second phase, the supporting infrastructure is assembled: servers in ASN ranges with low KYC verification, SSL certificates with short validity, and CDNs to mask the real traffic origin. The goal is to maximize short-term operational resilience, not longevity.

The third phase is social engineering, and here the technical kit gives way to the human component. Contact with the victim typically happens via WhatsApp, Telegram, or dating apps, with a profile carefully constructed in advance. The relationship is cultivated over weeks, with daily conversations, the sharing of believable personal details, and progressive mentions of crypto investments with extraordinary returns.

In the fourth phase, the victim is onboarded onto the platform. The first withdrawals work normally: this is the most important part for building trust. The victim experiences a real gain, becomes convinced of the platform’s legitimacy, and starts increasing the investment.

The fifth phase is the harvest. At some point withdrawals are blocked, with changing explanations: taxes that must be paid before unlocking, incomplete KYC procedures, unmet minimum thresholds, or unexpected technical fees. Each explanation is a pretext to extract more money from the victim before exit.

The sixth phase is the exit. Funds are moved through mixing services or cross-chain bridges into untraceable wallets, and the operator disappears. The fake exchange stops responding, the domain is abandoned, and the kit is reconfigured for the next campaign.

Generic Indicators of Compromise

Without revealing sensitive research data, the following is a set of generic indicators that anyone working in threat intelligence or blue team can use as a baseline for detection and monitoring.

On the domain and certificate side, it is worth monitoring domains registered less than 90 days ago with SSL from unknown or uncommon CAs, clones of known exchanges with typosquatting in the certificate CN, and domains whose URL structure imitates typical legitimate exchange paths.

On the API side, exposed /api/wallet or /api/transfer endpoints without authentication, as well as /api/admin endpoints accessible with default credentials, are strong indicators of criminal infrastructure.

On the network reputation side, an ASN with a high rate of reports on AbuseIPDB or present in Spamhaus blocklists is a signal worth taking seriously, especially when combined with the other indicators.

On the data infrastructure side, Elasticsearch instances exposed on port 9200 without authentication, with indices named users, deposits, wallets, or similar structures, are almost diagnostic for the kit in question.

On-chain, wallets showing rapid consolidation patterns toward exchanges known for weak KYC compliance deserve attention in the context of a broader analysis.

Tools and Methodology

For anyone who wants to replicate this methodology in authorized environments, the tools used and their purposes are listed below.

• Shodan was the starting point for passive fingerprinting of exposed infrastructure, with iterative queries to progressively narrow the area of interest.
• Local Elasticsearch made it possible to normalize, correlate, and analyze the collected data in a structured way, building a repeatable threat hunting environment.
• Python with the requests and json libraries automated the collection and parsing of data from the Shodan API, reducing analysis time.
• AbuseIPDB and Spamhaus enabled correlation of IPs with consolidated public blocklists.
• Blockchain explorers such as Etherscan supported partial tracing of suspicious on-chain transactions.
• Public paste sites were used for OSINT on credential leaks and to identify email patterns associated with the identified exchanges.
• Whois and ASN lookups completed the picture on registrant and hosting provider identity.
• Public OSINT forums provided context on the criminal supply chain and the market for kits.

The skills applied in this research cover passive threat intelligence, OSINT, SSL certificate analysis, reverse DNS, correlation of data from heterogeneous sources, Python scripting for automation, basic on-chain analysis, and ES|QL queries for structured threat hunting.

Final Reflections

This research confirmed something that is already understood at a theoretical level but is useful to see concretely: cybercriminals operating in this space behave like companies. They have operational divisions, standardized processes, a supplier market, and a capillary distribution system. The technical infrastructure they build is often mediocre from a security standpoint, with default configurations left unchanged, trivial credentials, and unauthenticated exposed instances. But that is not their real strength, and it would be a mistake to focus only on that.

Their real strength is social engineering, which has no patch and does not respond to firewalls. The victims of these scams are not naïve or uneducated people: they are people who were given attention, time, and systematic care to build trust. The technical component exists to give operational credibility to something that is, at its core, a relational scam.

From a defensive perspective, the two most effective fronts remain user education, especially around the mechanics of this type of fraud, and proactive monitoring of domains and certificates to identify suspicious infrastructure before it is actively used. From a threat hunting perspective, Shodan remains a significantly underused tool in Italian SOCs. With the right queries and a structured correlation method, it is possible to identify criminal infrastructure during the setup phase, before campaigns are launched.

If you work in blue team or threat intelligence and want to compare methodology or queries, the comments are open.

-

© 2026 Marco Altomare. All rights reserved.

The contents of this article, including but not limited to: texts and analysis, the kill chain reconstructions, OSINT analyses and correlation methodologies; technical contributions, the Python scripts, the Elasticsearch (ES|QL) queries and the Shodan search strategies; graphic elaborations, comparison tables of tools and structural diagrams; are the exclusive intellectual property of the author, Marco Altomare, except where otherwise specified or where trademarks belong to their respective owners (e.g., Shodan, Elasticsearch).

Any reproduction, distribution, modification, publication, or commercial use of the material, even in part or in summary form, without the prior written consent of the author, is strictly prohibited.

Citation or sharing for research or informational purposes is permitted only on the condition that the original attribution is maintained and a direct link to the source is included. Any abuse or unauthorized use that violates copyright will be prosecuted under the law.