[Part 1/2] Prometei Goes Both Ways: Same C2, Both Operating Systems, Three Months Apart

Same C2 IP, same Tor onion, same UPlugPlay disguise - three months apart, two operating systems.

Observation window: sample landed 2026-04-25 on one of our SSH honeypots

Primary signal: an unindexed Prometei v3/v4 ELF, delivered with a sibling already labelled trojan.prometei on VirusTotal, beaconing to a clearnet C2 in the ASEAN region plus Tor and I2P fallbacks

Actor confidence: behaviorally and infrastructurally consistent with the Prometei lineage documented by Unit 42 (Palo Alto Networks, 2025) and eSentire (February 2026). Attribution by family + shared infrastructure, not by operator identity. The geographic and linguistic markers in this toolkit point in three different directions and are read here as noise, not signal (see attribution note below).

New contribution: confirms cross-platform deployment of the same Prometei C2 cluster - eSentire saw the Windows variant pivoting through 103.176.111.176; we now see the Linux side of that same campaign three months later.

Defensive value: YARA rule on the JSON-trailer schema; hunt patterns for the UPlugPlay disguise on Linux; explicit C2 IOCs (clearnet, Tor, I2P).

📑 Companion piece, published the same day: Part 2 - Two-Way Prometei: When the Linux Botnet Pivots Back to Windows . Part 1 (this one) covers the Linux ELF (zsvc), the JSON-trailer schema, and the C2 endpoint we observed. Part 2 covers the 17 Windows modules dropped in the same campaign, the cross-platform pivot back from Linux to Windows (WinRM SOAP, Redis SLAVEOF, SMBv1/MS17-010-era dialect set), and a server-side fingerprint (Apache/2.4.41 (Win64) + Cyrillic charset) of the C2.

A fresh Prometei sample landed on one of our SSH honeypots on 2026-04-25. Its hash is unindexed on VirusTotal as of this writing, but the sample is not novel - it belongs to a Linux variant that has been documented since 2020, and that Unit 42 analysed in detail in 2025 for v3/v4 , including the JSON-trailer schema we recover here. eSentire then described the Windows side again in February 2026 . What is novel in this writeup is not the family, not the Linux variant, and not the schema - it is (a) the April 2026 confirmation that the Linux side of the operator’s mesh shares the C2 cluster eSentire reported on the Windows side, three months later, and (b) the binary-churn analysis (four parallel cadences in the same toolkit) we publish in the postscript.

What’s interesting is the infrastructure overlap. The clearnet C2 we extracted from this Linux sample - 103.176.111.176/cgi-bin/p.cgi, hosted in the ASEAN region - is the exact same IP eSentire reported on February 5, 2026 as the primary C2 for a Windows-server intrusion they investigated. The Tor v2 onion in our sample (gb7ni5rgeexdcncj.onion/cgi-bin/prometei.cgi) matches eSentire’s TOR endpoint character-for-character. And our Linux disguise path /usr/sbin/uplugplay matches eSentire’s Windows service name UPlugPlay.

Three months separate the two observations. Two operating systems. Same operator infrastructure. The implication is straightforward: the Prometei cluster eSentire saw in Windows is also actively pushing Linux payloads, and at least one of those Linux payloads landed on our honeypot.

The other thing worth flagging is what the Linux sample carries in plaintext. A JSON configuration trailer at the end of the binary exposes a per-bot identifier, a key blob, and - most usefully for defenders - a triple of fields naming the bot’s parent in the Prometei mesh. The implant tells us who its parent is, within the limits of the schema’s six named fields plus the leading config:1 marker.

Context: Prometei is well-documented; what’s new is the platform-bridge

Unit 42’s 2025 writeup describes Prometei v3/v4 as a Linux ELF, UPX-packed, with a per-bot JSON configuration trailer that confuses stock UPX unpacking. The schema is config / id / enckey / ParentId / ParentHostname / ParentIp / ip - five new fields beyond the v2 baseline. Unit 42 also describes the documented unpacking recipe: strip the JSON trailer first, run upx -d on the resulting binary, then re-attach the config if you want to preserve it.

eSentire’s February 5, 2026 writeup describes the Windows side of a Prometei intrusion in a construction-industry victim. They identify 103.176.111.176 (AS 63737) as the primary C2, plus a Tor onion gb7ni5rgeexdcncj.onion, and call out UPlugPlay as the disguised Windows service name. Their analysis covers the Windows Defender evasion, RDP-credential entry vector, and the modular component download chain.

What this article adds: the Linux side of that same campaign, three months later, beaconing to the same IP, the same onion, and using the same disguise naming convention adapted to Linux paths.

What we observed

A fresh Prometei v3/v4 ELF was uploaded via SSH to one of our honeypots on 2026-04-25T10:47Z. Two binaries were dropped in the same SSH session:

The co-delivery of a sample already labelled trojan.prometei in the same SSH session as our subject zsvc is itself the strongest corroborating signal for the family attribution. The two are siblings.

The source IP that delivered both binaries - IP value redacted, traces to AS11664 Techtel LMDS Comunicaciones Interactivas S.A. in Argentina, with the inetnum block owner registered as a regional medical-sector entity. The owner profile (a medical-sector network, not a hosting provider) suggests the source IP is itself a compromised peer relay propagating the toolkit, not directly operator-controlled infrastructure; we redact the specific IP because the underlying organisation is almost certainly itself a victim, and republishing the value would help the operator and expose a third party to opportunistic targeting from the wider attacker ecosystem. This is consistent with Prometei’s documented peer-to-peer propagation model.

The post-upload command sequence is short and deterministic:

chmod 777 zsvc
chmod 777 upnpsetup
sudo ./upnpsetup        # privilege escalation attempt — fails
su                      # second escalation attempt — fails
./upnpsetup             # falls back to user-mode
sudo ./zsvc             # fails again
./zsvc                  # falls back to user-mode
[ retries + session end after ~110 seconds ]

No interactive exploration. No reconnaissance. Just dispatch, attempt-elevate, run, leave.

Inside the packed sample (before unpack)

zsvc arrives as a stripped 64-bit ELF, statically linked, no section headers, with UPX! magic at offset 0xe7. Stock upx 4.2.2 -d refuses with NotPackedException, both with and without --force. This is the documented Prometei behavior: the binary appends a JSON configuration trailer that perturbs UPX’s PackHeader and overlay_offset metadata, breaking stock unpack while remaining loadable by the Linux kernel.

Per-4KB Shannon entropy across the entire 449 KB ranges between 7.72 and 7.91 bits/byte - uniformly high, no low-entropy code-section boundary visible.

The binary’s last 332 bytes contain the JSON configuration:

{
  "config": 1,
  "id": "<REDACTED-DROP-ID>",
  "enckey": "<128-byte base64-encoded key blob>",
  "ParentId": "<REDACTED-PARENT-ID>",
  "ip": "<REDACTED-VICTIM-EDGE-IP>",
  "ParentIp": "10.1.44.49",
  "ParentHostname": "<REDACTED-PARENT-HOSTNAME>"
}

We redact ParentId, ParentHostname, and the ip field for two distinct reasons. The ip is the public IPv4 that this bot was configured to live on - i.e., the honeypot edge that received it; we do not publish it while our sensors are in service. The ParentId and ParentHostname are coordinates of another peer in the mesh, very likely a victim, and republishing them would help the operator identify which of their nodes was observed and would expose a third party to opportunistic targeting from threat actors who scrape public threat-intel.

The schema is the substance. Whoever wrote Prometei v3/v4 chose to embed a back-pointer to the parent peer in every per-bot config. That choice is the durable IOC.

The enckey decodes from base64 (172 chars) into 128 bytes of binary. The first byte is 0x11, not 0x30 SEQUENCE, so it is not an ASN.1 SubjectPublicKeyInfo. The 128-byte length is consistent with an RSA-1024 modulus carried as a raw integer, but the format remains unconfirmed without parsing the unpacked image’s crypto routines.

After unpack - the C2 picture

We applied Unit 42’s documented Prometei unpack procedure: locate the JSON trailer (it begins at the literal substring {"config":1,"id":"), dd to keep only the bytes before the trailer, and run stock upx -d on the trailer-stripped image. The unpacker accepted the input on first try. Unpacked size: 1 288 624 bytes.

The unpacked binary is a standard ELF with 30 sections and 905 functions discovered by radare2’s auto-analysis (aaa). main() lives at 0x00425fcb. Symbol table is stripped, but function boundaries are intact. Strings count climbs from 286 in the packed image to 2 893 in the unpacked one.

What unpack reveals:

Three C2 channels in plaintext

The beacon URL template is also visible:

http://%s/cgi-bin/p.cgi?r=0&auth=hash&i=%s&enckey=%s

This three-channel design (HTTP + Tor + I2P, with HTTP as primary and Tor/I2P as anonymized fallbacks) is meaningfully more sophisticated than the single-URL clearnet model many commodity miners use. It gives the operator failover when any one channel is taken down by an abuse process or a node operator.

The Tor onion is a v2 16-character .onion address. Tor Project deprecated v2 onions in 2021. We treat this endpoint as dead code in the sample (a probe below confirms non-resolution against modern Tor relays).

103.176.111.176 is the same IP eSentire flagged for Windows in February

103.176.111.176 sits in AS63737 - as-name: VIETSERVER-AS-VN, descr: VIETSERVER SERVICES TECHNOLOGY COMPANY LIMITED per the APNIC aut-num record, last modified 2021. The /23 inetnum that contains the IP (103.176.110.0/23) is sub-allocated downstream to netname: MAXCLOUD-VN, descr: MAXCLOUD DATA TRANSMISSION AND TECHNOLOGY COMPANY LIMITED. Both names are correct simultaneously: VIETSERVER operates the ASN, MAXCLOUD-VN is a downstream sub-allocation customer. eSentire’s February 2026 writeup names the ASN-level owner (VIETSERVER); we cite the inetnum-level allocation (MAXCLOUD-VN) because it more narrowly localizes the C2’s hosting boundary. Same allocation, two coexisting levels of the registry hierarchy - no rotation, no source disagreement. The geographic origin of the hosting is one of three contradictory markers in this toolkit and we discuss its (limited) attribution value below - see “On attribution”.

The Tor onion gb7ni5rgeexdcncj.onion is the same address eSentire published.

The Windows service name eSentire identified - UPlugPlay - matches our observed Linux disguise path /usr/sbin/uplugplay. Same disguise, adapted to the platform’s binary-naming conventions.

These three converging anchor points (clearnet IP, Tor onion, disguise name) make the cross-platform overlap concrete rather than circumstantial.

The C2 endpoint is still active as of 2026-05-02

We performed a brief external reachability check from a clean ephemeral test host - no OHIIHO infrastructure attached - to confirm whether the documented C2 is still live three months after eSentire’s writeup.

Three things matter from this probe:

• The clearnet C2 was alive three months after eSentire’s report (Feb 5 → May 2). The server was reachable, BGP was stable, and the controller correctly handled probe requests (HTTP 200 with zero-byte body for invalid parameters is exactly what a working CGI gate looks like when it accepts the connection but rejects the auth).
• The server stack - Apache 2.4.41 (Win64) + OpenSSL 1.1.1c + PHP 7.3.10 - is from late 2019. The operator runs old software but has kept it operational for the campaign’s lifetime. The Win64 build identifies the C2 host as Windows, and the windows-1251 Cyrillic charset is observed on the response. Both are facts about the C2 stack; we do not read either as an attribution signal - see §“On attribution” above.
• The Tor onion in the sample is dead code. Tor v2 was sunsetted in 2021; any Tor 0.4.6+ relay refuses v2 descriptors. Defenders blocking only Tor v3 onions are not missing anything from this Prometei lineage’s Tor channel - although a future variant could ship a v3 onion equivalent.

We did not test the I2P endpoint because the cost-benefit was not worth it for this writeup; an I2P resolution would have required a full I2P daemon up. We treat the I2P endpoint as a behavioral IOC (its presence in the binary), not as an actively probed channel.

Filesystem persistence and reconnaissance

The unpacked strings expose Prometei’s full Linux footprint:

Reconnaissance paths align with Unit 42’s documented flow: /proc/cpuinfo, /proc/meminfo, /etc/os-release, /etc/redhat-release, /etc/debian_version, /etc/host.conf, /etc/nsswitch.conf, /etc/resolv.conf.

Mining-related functions

Direct evidence in the function-name strings: start_mining and stop_mining. Self-eviction signature: pkill updatecheckerd - the bot kills any prior instance of itself (running under that disguise name) before launching the new one.

We did not extract mining-pool URLs or wallet addresses from the static strings. Those almost certainly sit in encoded tables that require deeper static work or runtime instrumentation. Out of scope for this writeup.

Hardcoded DNS fallbacks

Hardcoding 114.114.114.114 is mildly suggestive of operator awareness of Chinese-network conditions (the resolver is widely chosen as a censorship-resistant fallback in mainland China and is also used outside it). Not diagnostic of operator nationality.

On attribution: three stacked contradictions, read as noise

Three geographic and linguistic markers appear in this toolkit, each pointing in a different direction:

• A Cyrillic windows-1251 charset on the C2 server’s HTTP response headers
• A Vietnamese-language string (xinchao123 - “xin chào”, “hello”) hardcoded as the archive password in the Windows orchestrator
• A clearnet C2 hosted on AS63737 (MAXCLOUD-VN), an ASN registered to a Vietnamese hosting entity

A skilled operator who wanted to hide their identity would not stack three contradictory markers in the same toolkit; they would pick one cover story and stay disciplined. Two non-exclusive readings fit the data, neither provable from static evidence alone:

• Sloppy assembly. The operator reused leftover assets - a borrowed Mimikatz build frozen since 2023, an off-the-shelf VPS in a cheap hosting market, a placeholder string copied from somewhere - without OPSEC discipline. Many commodity-malware operators do exactly this: the cost of cleaning up is real, the marginal evasion gain is small, and the customer base does not pay extra for hygiene.
• Inconsistently-executed false flag. The mismatch between markers is the signature of an attempt to dilute attribution that did not commit to a single decoy identity. A careful false flag would stack consistent markers (e.g., all three pointing to the same regional or linguistic origin), not contradictory ones. A lazy false flag looks exactly like sloppy assembly from the outside.

We do not claim attribution. The markers in this toolkit characterize the assembly process, not the operator identity. Earlier writeups (Unit 42 in 2025, eSentire in February 2026) characterize the Prometei lineage as long-running and Russian-leaning at the family level - but lineage and operator identity are not the same thing, and a single sample’s surface markers cannot pin either further than that. The hosting jurisdiction is in particular a near-zero-information signal: cheap VPS providers in any region of the world serve attackers from any other region.

What follows in this article is therefore deliberately scoped to the technical content of the sample (binary, schema, infrastructure topology, defensive IOCs). Geographic markers are mentioned where they appear in the data, not used as attribution signal.

What “the implant tells us who its parent is” actually buys us

The leaked Parent* triple is a CTI pivot, not a smoking gun. What it actually buys defenders and analysts:

• Inter-sample correlation: if two different Prometei samples carry the same ParentId, they were dispatched by (or descend from) the same parent peer. That builds the propagation tree from the leaves up.
• Containment scoping: a defender who finds a Prometei zsvc on one of their hosts and reads the trailer learns whether the parent peer is on their internal network (ParentIp in RFC1918 → potentially yes) or external. RFC1918 ParentIp strongly suggests an internal compromise predates the on-host symptom.
• Bot-mesh shape: across many Prometei samples, the (ParentId → child IDs) graph reconstructs the cluster’s propagation topology. Public-domain samples + per-bot identifiers = a defender-side mesh map.

What the leak does not prove:

• It does not identify the operator. The parent is another peer in the mesh, not the C2 controller.
• It does not validate that the parent host is hostile by intent - it is most likely another victim that has been used as a relay.
• It does not unlock the C2 channel; the enckey is per-bot and tied to the operator’s controller-side material.

Postscript: a second sample-set, same loadout, different per-victim SHAs

After the analysis above was complete, we retrieved a second Prometei sample-set from the same honeypot path. Same eight files (7z.dll, 7z.exe, rdpcIip.exe, sqhost.exe, updates1.7z, updates2.7z, upnpsetup, zsvc), same archive password (xinchao123), same C2 schema. Different per-victim hashes for the mutating files. This second set lets us draw conclusions about how the operator manages binary churn that one sample-set alone could not support.

Four levels of binary churn in the same toolkit

Comparing the two sample-sets file-by-file produces four distinct churn behaviors:

The fourth level is the interesting one. For zsvc, the operator does not recompile at all. The C2 backend keeps a single statically-linked Linux ELF and appends a freshly-generated 332-byte JSON trailer (with a fresh id, fresh enckey, fresh Parent* triple) at delivery time, then ships the result. No build pipeline involved per drop. This is consistent with the UPX-trailer schema we documented above: it is the most lightweight per-victim customization a malware operator can offer, and it produces a fresh SHA256 for every victim while spending zero CPU on rebuilding.

The defensive consequence is the headline. A SHA256 IOC for zsvc is per-victim, not per-campaign: every victim sees a different hash. A YARA rule on the JSON-trailer schema is durable; an IOC list of zsvc hashes is not.

Two C2 chains observed across the two drops

The two sample-sets carry different Parent* values in their zsvc trailers (which is by design - every drop gets a fresh trailer). What we observe across the two drops is that the parents are different too:

We redact the second drop’s Parent* values for the same reason we redacted the first drop’s: the parent is a third-party peer, almost certainly itself a victim, and republishing the values would help the operator and expose the third party. What matters analytically is that the two drops transited through different upstream peers. The C2 mesh has more than one active relay path into our sensors. That is structural - pull samples from N drops on a single victim, and you are pulling routes through N different parent peers, which lets you reconstruct a fragment of the propagation graph.

What this changes for defenders

• Hash-based blocklists for zsvc are functionally useless. The JSON-trailer-only churn means every Prometei v3/v4 victim observed will produce a unique zsvc SHA256. Schema-anchored YARA is the only durable approach. (The same holds for the unpacked SHA, since that is currently constant - but we cannot assume the operator will not bump it; if you fingerprint on BuildID 4a23814d2f15bc7ed5be580c0fae30b02cc3c764, expect that to rotate eventually.)
• The Mimikatz components are 3-year-frozen IOCs. miWalk32.exe and miWalk64.exe carry PE compile timestamps from 2026, but their SHA256 has not changed since they first appeared. If you see those hashes, you are seeing this lineage with high confidence.
• The xinchao123 archive password is a behavioral signal: any process that invokes 7z x updates*.7z -pxinchao123 is unpacking Prometei’s component archives. Non-trivial to detect in clean form, but worth a string-match on process command lines if you are hunting in EDR data.

What this does not let us conclude

• The two drops do not, on their own, tell us whether the operator’s “stash” of pre-built variants is large or small. We see two; there could be five, or fifty.
• The clearnet ParentIp in the second drop’s trailer was not reachable on TCP/80 from a clean test host at the time of this writing. That is consistent with a parent peer either offline, firewalled outbound-only, or repurposed since the drop. Without a live channel, we cannot pivot from Parent* to operator-controlled infrastructure.

Defensive notes

YARA - schema-anchored, not value-anchored

A YARA rule that matches the JSON-trailer layout (the six named fields plus the literal config:1 marker, anchored on ELF magic) detects this class of Prometei sample without depending on any per-bot value. The rule is durable across the campaign because the schema does not rotate; the values do.

Hunt patterns for Linux fleets

• /usr/sbin/uplugplay on disk - exotic enough to flag, given the matching name with eSentire’s Windows UPlugPlay service.
• /etc/CommId, /etc/pcc0, /etc/pcc1, /etc/uplugplay - Prometei config files; their existence on a server is high-signal.
• A process named updatecheckerd that does not correspond to a package-manager-known binary.
• Outbound HTTPS to gb7ni5rgeexdcncj.onion if you have visibility into Tor traffic at the edge.
• Outbound HTTP to 103.176.111.176/cgi-bin/p.cgi with a query string of the shape ?r=0&auth=hash&i=…&enckey=….

Network-layer

Block the three known endpoints at the perimeter for any Linux server fleet without legitimate ASEAN / Tor / I2P egress requirements:

103.176.111.176              # clearnet C2
gb7ni5rgeexdcncj.onion       # Tor v2 onion
mkhkjxgchtfgu7uhofxzgoawntfzrkdccymveektqgpxrpjb72oq.b32.i2p   # I2P

The clearnet IP is perishable and will rotate; treat the Tor onion and I2P endpoints as more durable but expect rotation on a multi-month cadence as well.

Public threat-intel propagation: family known, IP not yet propagated

Credit for first-publishing 103.176.111.176 as a Prometei C2 belongs to eSentire’s Threat Response Unit, in their February 5, 2026 writeup of a Windows-server intrusion . Our contribution here is the Linux side of that same campaign three months later, plus the postscript on per-victim binary churn - not the C2 IP itself.

That said, at the time of this article’s publication the IP’s propagation across commodity threat-intel surfaces is uneven. VirusTotal returns 15 vendor engines flagging 103.176.111.176 as malicious (out of 91 reporting), with sparse community context (2 malicious votes, 0 harmless) and a -2 reputation score. The family-level attribution is well-documented (Unit 42 2025, eSentire February 2026), and a meaningful subset of VT engines have already lit up - but commodity reputation feeds and aggregated blocklists have not uniformly propagated the indicator. Defenders relying on a single feed may or may not catch beacons to it today; defenders cross-checking VT engines have a reasonable chance.

Submission to public threat-intel sources

The hash 2746f158… is not on VirusTotal as of this article’s publication. We are holding submission until our sensor network has rotated - to avoid signaling to the operator that this specific drop landed in our sensors, not because the trailer’s redacted coordinates are themselves the gating factor (the SHA256 is already public in this article, and anyone who recovers a matching binary from another source will see the same trailer schema). A future VT submission, with a comment linking back to this article, will follow once that rotation is complete.

Confidence-rated IOCs

Observed

Inferred (strongly suggested, not observed at runtime)

• Self-eviction via pkill updatecheckerd then re-launch of the new binary
• Three-channel C2 failover (HTTP → Tor → I2P) is operator-side rather than defensive accident
• Cross-platform deployment by the same operator cluster (based on shared C2 IP, shared Tor onion, shared disguise name across our Linux observation and eSentire’s February 2026 Windows observation)
• zsvc is not recompiled per-victim. Inferred from the second sample-set (see Postscript): bit-identical unpacked code, identical BuildID, same SHA256 of unpacked. Per-victim customization happens entirely through the JSON trailer.
• The operator runs at least four distinct binary-churn cadences in parallel within the same toolkit - frozen for stable utilities (Mimikatz, Tor binaries, support DLLs), slow recompile for the Linux ELF (upnpsetup), faster recompile for the Windows trinity (windrlver + sqhost + rdpcIip) and msdtc.exe, and append-only-trailer for zsvc. This separation of cadences is the engineering signal: the toolkit has lived long enough that the operator has tuned per-component overhead.

Speculative

• 114.114.114.114 hardcoded suggests operator awareness of Chinese-network conditions; not diagnostic of operator nationality
• 103.176.111.176 will rotate (any clearnet C2 does) - the rotation cadence in this lineage appears to be multi-month
• The windows-1251 Cyrillic charset on the C2 response is one of the three contradictory markers discussed in §“On attribution”; we do not read it as a directional signal here. Earlier reporting (eSentire February 2026) describes the Prometei lineage as long-running with a Russian-leaning family-level characterization - that is a property of the lineage as documented historically, not a claim about this specific operator instance

Scope of this analysis

We deliberately did not cover:

• Operator identity beyond family attribution. Both Unit 42 and eSentire characterize Prometei as a long-running cryptojacking campaign (eSentire calls out a suspected Russian-origin lineage; we have no independent evidence to corroborate or refute). Static analysis of one sample does not pin attribution.
• Mining pool URL and Monero wallet address. These almost certainly sit in encoded tables in the unpacked binary; extracting them requires either deeper static work (capa, Ghidra) or runtime instrumentation. Both are out of scope for this writeup.
• Runtime behavior. We did not execute the binary. The behavioral inferences in the “Defensive notes” section come from string analysis and from the Unit 42 / eSentire reference work, not from sandbox observation.
• The 128-byte enckey blob format. The length matches RSA-1024 raw modulus, but the blob is not ASN.1-wrapped. We do not claim a specific cryptographic structure.
• Coordinate of the parent peer (ParentId, ParentHostname). We hold this in our internal records but do not publish - the data identifies a third-party peer that is itself almost certainly a victim, and republishing the values would help the operator and expose the victim. The schema is what defenders need; the values are the operator’s problem.

References

• Unit 42 / Palo Alto Networks. Resurgence of the Prometei Botnet. 2025 - https://unit42.paloaltonetworks.com/prometei-botnet-2025-activity/
• eSentire Threat Response Unit (TRU). Tenant from Hell: Prometei’s Unauthorized Stay in Your Windows Server. eSentire, February 5, 2026 - https://www.esentire.com/blog/tenant-from-hell-prometeis-unauthorized-stay-in-your-windows-server
• MITRE ATT&CK T1059.004: Unix Shell - https://attack.mitre.org/techniques/T1059/004/
• MITRE ATT&CK T1496: Resource Hijacking - https://attack.mitre.org/techniques/T1496/
• MITRE ATT&CK T1071.001: Application Layer Protocol - https://attack.mitre.org/techniques/T1071/001/

OHIIHO Research - sensors powered by HIIH.