Help Desks to Host Shells Across Brazil's Public Sector

Campaign Identifier: OpenDirectory-38.180.16.98-BrazilPublicSectorToolkit-20261015
Last Updated: October 15, 2026
Threat Level: CRITICAL

1. Executive Summary

The operator’s own files show it running commands inside two Brazilian federal bodies, a federal social-security agency and a federal development bank, and working authenticated staff sessions at a state finance secretariat in the North region. Saved administrator pages from a state traffic department in the Northeast region and from a cloud services supplier sit in the same directory, though I cannot show the operator captured those itself. Beyond those five, the files name 87 more organisation rows across federal, state and municipal government, and every one of those stops at a probe reply, a refusal or a name on a list. Whether any of the access still works today is unknown. The latest dated host-side evidence at the bank is 2026-09-15, and the latest dated console replies at the agency are from 2026-10-02.

All of this came out of an open directory on 38.180.16[.]98, a hosted server the operator used as its working area, file store and listener. Nothing public names this operator. One press report from September 2026 describes an intrusion at the same agency and its federal IT provider that may or may not be the same actor, and it shares no hard indicator with what I hold. What I hold is the other side of the story: the operator’s tooling, its output, and the data it took.

This is an operator early in its attack chain, not early in its life. Everything I can see is reconnaissance, footholds, exploration and collection, sustained since at least mid-September, and over that span the same behaviour also fits espionage. Its targets are Brazilian public-sector bodies broadly, with the agency at the centre. Once it got into a few it kept reaching outward, toward the agency’s federal IT provider, the managed security provider that serves the agency and that provider’s cloud supplier. Of those three, only the cloud supplier shows authenticated access, and only on saved pages.

The help desk was its richest reconnaissance source, and that is the finding I would put in front of any defender reading this. At the agency the operator’s scripts searched the GLPI ticket database for SentinelOne, Intune, Entra, GlobalProtect and remote-shell terms, pulled deployment tickets naming internal hosts and repositories, and took a live SentinelOne console API token out of the settings of the help desk’s own remote-support application. Tickets gave it hostnames, software, users, procedures and the security stack without a single noisy scan.

Where it built its own tools, it chose reliability over stealth. Its reverse relay talks plain ASCII to the operator’s server on TCP port 53, announcing itself with the line READY2 and taking orders of the form DIAL host port, with no encryption and no framing. The operator’s own log records 1,051 relay check-ins out of a victim network’s egress address. Where it could use the victim’s own tools instead, it did. With one stolen staff account it turned an internal Zabbix monitoring server into a command plane, creating temporary scripts that ran on a monitoring proxy and sent root identity back to its own listener, then deleting them.

How far the operator got differs sharply from one organisation to the next.

• At the agency, graded ACCESS SHOWN, the operator ran unauthenticated commands through a renamed copy of GLPI’s htmLawed test page (CVE-2022-35914). Fourteen pieces of command output, fetched from an internal file server, reassemble byte for byte into one of the agency’s own 905,374-byte deployment packages. The operator also queued 4,675 distinct help-desk document paths for download, held the SentinelOne token and used it, and held temporary AWS credentials for an agency cloud account.
• At the bank, also ACCESS SHOWN, a process table captured inside the bank’s WSO2 API Manager container shows a reverse-SOCKS client running as the WSO2 service account, aimed at the operator’s 209.99.185[.]148 through the bank’s own forward proxy. The operator held the unencrypted WSO2 private key and 608 OAuth client key and secret pairs.
• At the finance secretariat, graded COMPROMISED, authenticated staff pages echo the operator’s own address, application edits were accepted, and a 49,131-row export of the state’s main user account table sits in the directory beside a password-cracking input built from it.
• The traffic department and the cloud supplier are COMPROMISED at MODERATE, on saved authenticated administrator pages that carry no address, timestamp or capture route tying the capture to the operator.

I rate the campaign CRITICAL. Little about it is exotic. The entry points are public exploits from 2022 and the expansion runs on management tools the victims already own.

But the parts that matter worked: commands run on a help-desk host, a tunnel client running inside an API gateway, staff sessions and a full account-table export at a state secretariat, and a live EDR console token. They worked inside national institutions that hold benefit, tax and development-finance data. Inside or authenticated access is shown at five of the 92 organisation rows, and the other 87 stop at probes and names. Section 2 explains the score and why the campaign level sits above it.

No publicly named threat actor can be attached to this activity, and the evidence does not support a tracking designation of my own either, so I describe it as an unknown operator. I am confident it is not an authorised red team. A tester would not keep a victim’s data in a publicly reachable directory, would prove access and stop rather than collect in bulk, and would not work inside several unrelated organisations while probing dozens more. It also looks too long-running and too evasive for a smash-and-grab access broker, though it could sit somewhere between a broker and something else. What it ultimately wants is still undetermined.

If you defend a Brazilian public body or a supplier to one, three checks are worth more than the rest of this report. Look for POST requests to GLPI’s htmLawed test page under any name, including renamed copies. Look in your Zabbix audit log for global scripts or items created and deleted by one account in a short burst, especially names beginning z-, wv3_ or poc. And look for any internal host holding a TCP connection to port 53 that carries no parseable DNS, which is how the relay looks to Zeek and Suricata.

2. Risk Assessment

I score the toolkit 7.8 out of 10, HIGH, on what it can do, and I rate the campaign one level higher, at CRITICAL, on what it has already done. The gap between those two numbers is the point of this section. As software, almost nothing here is advanced. As an operation, it has shown command execution inside two federal institutions and holds key material that could still open doors if nobody has rotated it.

The weighting is the standard one used across these reports, with data exfiltration and system compromise at 20 percent each, and persistence, evasion, lateral movement and detection difficulty at 15 percent each.

Risk vs. Campaign Threat Level: The toolkit analysed in this report scores 7.8/10 (HIGH) on capability, because it is assembled from public exploits, a small relay and the victims’ own management tools. The overall campaign threat level is rated CRITICAL because host-side command execution is demonstrated inside two federal institutions (the agency and the bank), the operator holds secrets and records whose validity nobody outside those institutions can check (a WSO2 private key, 608 OAuth client credentials, an EDR console token, a state account table), and the operator was reaching outward toward suppliers when the directory was captured. If the affected institutions confirm that the access is closed and the held credentials are rotated, the campaign level should be reassessed to HIGH.

The bank’s OAuth material is the exposure I would worry about longest. Those client credentials belong to institutions that consume the bank’s APIs, and if they are still valid they let someone act as those subscribers against the bank’s gateway. I have no evidence that anyone did, and I am not claiming subscriber systems were touched. The point is that the exposure outlives the intrusion until the credentials are reissued.

The finance secretariat’s account table carries a similar tail. Its passwords are stored as unsalted MD5, and one hash value is shared by 5,001 accounts, which looks like a default password. Whether that value is a default, and whether any account was cracked or used, is not shown. The cracking input exists; the cracking output does not appear anywhere I can see.

3. Who Was Hit, and How Far the Operator Got

Five organisations show inside or authenticated access, and the long list behind them is mostly probes. I grade every organisation on what the operator’s own files prove, using four levels, and the levels matter because a name in a script is not a compromise.

LISTED means named only, in a target list or script. REACHED means an outside attempt or reply without working access, and a failed or blocked attempt counts. COMPROMISED means working external access, such as an authenticated session, or server material whose owner is established. ACCESS SHOWN means an identified network plus host-side execution or inside-position evidence. A separate CURRENT field records the last datable access, which is not the same as access today.

The assessment carries 92 organisation or group rows: 2 ACCESS SHOWN, 3 COMPROMISED, 66 REACHED and 21 LISTED. A group counts once, so 92 is not a count of distinct legal entities. I hold that tally at MODERATE, because 175 hostname candidates in the files have not all been reconciled into organisations, and a full reconciliation could move a row.

The organisations with inside or authenticated access

The two COMPROMISED rows at the bottom deserve their caveat in the same breath as their grade. Neither page set carries the operator’s address, a timestamp or a capture route, so another collection method (a stealer log, a shared export, someone else’s saved browser page) cannot be ruled out. The finance secretariat is on firmer ground, because its own pages print the operator’s address as the client.

The suppliers and the rest of the named parties

The agency’s federal IT provider, the company that builds and runs its systems, stays at REACHED even though the operator holds a non-public export of part of its directory (2,538 entries in the portion read). Nothing places the operator inside the IT provider: the server that export came from, the route and the date are all unknown, and the export could be an old snapshot. The operator also cloned the 12 code repositories of the IT provider’s public GitHub organisation in 21 seconds and scripted logins against its VPN and identity service, with no reply held for any of them.

The managed security provider that serves the agency is also REACHED. A request-forwarding flaw in a cloud portal built by the cloud supplier (whether the cloud supplier or the security provider owns the application is unestablished) exposed a backend API token in anonymous debug pages, and at least 29 operator scripts present that token onward. Holding a token is not using it, and across 534 file hashes I found no accepted login at the security provider. The help desk of a second state finance secretariat was the target of relay tooling that assumes a foothold already exists, but the only response held is a 285-byte 403 page, so it is REACHED. A state government and a federal health IT department are REACHED on saved public login pages only.

The remaining 55 REACHED rows split into 27 public or login-page replies, 21 denials or errors and 7 attempts with no reply. They span municipal governments, state secretariats, courts, federal regulators and state IT companies. None shows an objective result and none carries a dated access. The 21 LISTED rows (14 individual bodies and 7 groups, including ministries and federal agencies) are names on lists, with no access shown.

I do not read that long tail as proof of targeting. A sweep across a whole product class on .gov.br (GLPI, WSO2, JBoss, Tomcat, WebLogic) explains probe-level contact just as well as a hand-picked target list does. What I can say is that the core of the operation is directed. The agency-centred collection, the labelled probe sets, the extension to the IT provider, the security provider and the cloud supplier, and a 245,707-row extraction from an integration database whose owner I could not establish are not the output of an opportunist who stumbled in.

Seven further assessment blocks cover systems whose owner I could not establish. Two of them are COMPROMISED at MODERATE: the Zabbix monitoring proxy that returned root identity to the operator, and the Zabbix server behind it. Their estate association with the agency is conditional, so they are not added to the agency’s row.

4. Technical Classification

This is an intrusion toolkit, not a malware family. There is no implant, no loader and no packed binary in the operator’s own work. It is Python, PHP, shell and a little Java, wrapped around public exploits and legitimate management interfaces, and run from a hosted Linux server the operator used. I put family identification at INSUFFICIENT, because nothing in it matches a named family and nothing in it is distinctive enough to found one.

On sophistication I will not assign a grade. The tooling is iterative and practical rather than clever: numbered batch scripts, per-person cookie jars, certificate checks switched off, ISO-8859-1 decoding for Portuguese pages. Where it is good, it is good at using what the victim already runs. Turning a help desk into a reconnaissance source and a monitoring server into a command plane takes knowledge of how institutions actually operate, and no exploit development at all.

The toolkit is in a constant state of revision. Files appeared and disappeared from the live directory between captures, the served tree grew to 9,917 files by its last listing on 2026-10-08, and several helpers exist in numbered generations. The operator also downloaded clean copies of public tools to study them, including an unmodified clone of the public glpwnme GLPI exploitation tool and the stock GLPI 10.0.7 release, which is byte-identical to upstream across all 6,500 files. Neither is trojanised, and neither says anything about which GLPI version the agency runs.

Two Windows executables on the operator’s second host, 209.99.185[.]148, sit apart from all of this. The two bpupdate.exe builds fetch from that host on port 8146 and launch Chrome Canary headlessly under a “BluePeak AppUpdater 2.4” identity. They share the operator’s address and time window, so I rate a common controller at MODERATE. Against that, nothing in either build names the operator’s canary, a Brazilian target or its tunnel listener, the BluePeak naming does not match the operator’s Portuguese working style, and a co-tenant or later tenant is not excluded. Campaign authorship stays NOT CHECKED, and I map no campaign behaviour from them.

5. The Attack Chain at a Glance

The operation runs in a recognisable order: study the target’s public code and products, get in through a public-facing application, mine the inside for access material, then use the victim’s own management tools to spread. Collection runs alongside most stages rather than waiting for the end, and nothing in what I hold goes past collection into fraud, extortion, sale or destruction.

Three things in this chain are worth more to a defender than the rest. The help desk is where the operator learned the environment, so it is where the earliest signal sits. The EDR console token turned a security product into a reconnaissance feed, and the uninstall-password request is exactly the kind of call a console audit can alert on. And the relay is easy to catch on the wire precisely because the operator chose not to hide it. Sections 8 to 12 take each in turn.

6. Infrastructure

Three hosted servers carry the operation, and they are joined by the operator’s own documents rather than by any shared technical fingerprint. Its scripts call one of them “our IP”, label another “nosso canary” (“our canary”), and point the bank’s tunnel client at the third. No operator-owned domain exists anywhere in the evidence. Whether the operator rented these servers, compromised them or bought them second-hand is not established; only a provider’s customer record would settle it.

The first address is tied to the operator most directly: the agency’s own help desk echoed it back as the visitor address, the secretariat’s pages print it as the client, and the operator’s tooling names its listeners. The address is recycled, though. Its port 443 certificate, its JARM and its SSH host key all belong to earlier tenants from 2024 and 2025, so none of them is an indicator for this operator. The operator’s surface on it dates from 2026-09-26.

The second address is weaker for a specific reason. Ten third-party parked domains also resolve to it, and that co-tenancy is not resolved, so the host-level entry in the feed is MONITOR and only the operator’s service ports are BLOCK. The cadsus-panel realm was visible from 2026-09-04 to 2026-09-14. CADSUS is the name of Brazil’s national health-user register, but the word appears in none of the 973 files of the operator’s archived directory, and I cannot say what the panel was for. Phishing is one possibility among several; without context I will not speculate further.

The 3NT and M247 allocation is commodity hosting, so the shared provider between the first two addresses is not a link on its own. I found no evidence either way on whether any of these providers runs a permissive hosting policy, and I make no bulletproof-hosting claim. An Amazon address that sent the operator 1,051 relay check-ins is the victim estate’s egress rather than a fourth operator host, and it is deliberately absent from the indicator feed.

The build-up ran over about five weeks. The second server’s configuration changed on 2026-08-20, its panel appeared in early September, the bank’s tunnel started on Sep 14, the canary’s certificate is dated 2026-09-21, and the first server’s operator window opens on 2026-09-26. My read is planning and the need for scale: the operator laid out the infrastructure it expected to need and stood it up as the operation grew. Configuration dates are not tenancy records, so that is my read of a sequence and no more.

When the directory went silent, and why, is undated. A server that still answers on other ports says nothing about whether any of the victim access still works, and a quiet directory is not evidence of a takedown.

7. What the Public Record Holds

Nothing public that I found names this operator or describes its combined activity, and I hold that at MODERATE. That is bounded by what was searched. Searches for the bare addresses and file hashes did not return a known positive control, so those negatives are not reliable, and the relay’s protocol strings were never searched at all. I make no claim to be first to publish any of it.

Others could see the raw material before I did. A commercial capture service archived the operator’s directory on 2026-09-27, before this investigation began, and its automated summaries described the bank’s WSO2 activity and the agency’s GLPI exploitation from that capture. That is machine-written description behind a login rather than published analysis, but it means the raw material was visible to that service’s customers.

Most of the techniques are known. GLPI’s htmLawed flaw (CVE-2022-35914) has been mass-exploited since 2022, as VulnCheck’s write-up describes. WSO2’s file-upload flaw (CVE-2022-29464) was under wide exploitation by April 2022, according to a Deepwatch advisory that itself relies on Rapid7’s reporting. Another operator taking a Brazilian government GLPI compromise through to the directory service has been described by CyberCyber Labs in Inside an Exposed C2 Server (CCL-2026-07-EXC2, sections 1 to 4).

That makes the vector and target combination partially covered, with no shared infrastructure in a controlled comparison. Abuse of Zabbix global scripts and API-driven remote commands is documented prior art, as Section 11 explains. I found no prior report of a SentinelOne console API token being used this way against a Brazilian agency, or of this relay protocol, at the depth I searched.

A September press report is the one piece of context I have to address directly. Cybernews published on 2026-09-09 an account of an actor it found on 2026-07-06 inside the same social-security agency and its federal IT provider: an AI agent on cloud infrastructure, remote management access into an agency Windows machine, credential collection against the IT provider’s VPN, reverse tunnels, and a claimed bypass of SentinelOne. It shares victims, interest in the IT provider’s VPN and SentinelOne as the obstacle with what I hold. It shares no hard indicator, and a byte search of the files I hold for the article’s named tool strings found none.

So the link stays NOT CHECKED and a same-operator assessment stays INSUFFICIENT.

I can see two readings. It could be the same actor, never fully removed after that July discovery. Or it could be a different actor using the published story as a playbook. The infrastructure dates do not settle it either. The second server and its panel predate the article, so I will not claim that everything began after publication. A matching command server, SSH key or file hash from the article’s unredacted material would settle it, and I do not have that material.

8. The Social-Security Agency: From a Help-Desk Test Page to the Internal Package Store

The agency is the centre of this operation, and the finding that moved it from “targeted” to “inside” is a single shell script. The operator sent commands through a vulnerable test page that ships with GLPI, had each command fetch one 64 KiB slice of a file from an internal file server and print it as base64, and saved the fourteen answers. Those fourteen answers decode, slice by slice, into 905,374 bytes that are byte-identical to an agency deployment package and match the MD5 in the agency’s own package manifest. Nobody can hold those slices without running commands on a host that can reach that file server, and that is what makes this an intrusion rather than a target list.

Around that proof sits everything else: a bulk pull of the help desk’s document store, the help desk mined for the security stack, a live EDR console token, cloud credentials and two internal application databases. What is not shown is just as important. I cannot date the GLPI commands, I cannot say how many documents actually left, and I cannot say whether a credential-capture hook the operator wrote was ever installed.

9. The Development Bank: An API Gateway and a Tunnel Out Through the Bank’s Own Proxy

At the bank the operator got command execution inside the bank’s WSO2 API Manager and left a tunnel client running there, aimed at its own server through the bank’s own forward proxy. A process table captured inside the container shows the client as PID 7519, running as the WSO2 service account, started on “Sep 14” (the table carries no year or zone), with a proxy credential of the bank’s on its command line. I hold at HIGH that the process exists and at MODERATE that the operator started it, because the operator’s own capture commands sit beside it and the destination is the operator’s 209.99.185[.]148.

That is a big finding with a lot of fallout, and it is also not complicated. Nobody needed a zero-day here. The operator’s scripts aim at a public flaw from 2022, and while no response shows that flaw working, I infer it as the way in. That, a service account and a reverse proxy client were enough to put the operator inside a national development bank’s API layer and walk away with its signing key and its subscribers’ credentials. That is how most of this threat landscape actually works, and it is worth saying plainly.

The question I cannot answer yet is whether the API gateway was the goal. It could have been the target from the start, a door the operator happened to find, or a way to reach the OAuth clients and the APIs behind them specifically. The operator’s discovery script scoped its search to the bank’s own domains, which leans toward deliberate interest in the bank, but that is all it shows.

10. The Finance Secretariat, the Saved-Page Victims and the Suppliers

The finance secretariat is the clearest case of the operator working as an ordinary user and leaving with the user table. Its saved staff pages print the operator’s own address, 38.180.16[.]98, as the client in the application banner, so these are sessions the operator ran. Through a database query page reachable from outside, it exported the state’s main user account table, and the export sits in its directory with exactly the row count its own log reports. What I cannot show is any command execution on a host of the secretariat’s, which is why the grade stops at COMPROMISED.

The other saved-page victims and the suppliers are weaker, each for a specific reason, and I give each its reason below rather than letting them borrow the secretariat’s footing.

11. The Monitoring Server as a Command Plane

With one stolen staff account, the operator logged into an internal Zabbix monitoring server and used its own script feature to run commands on the machines it monitors. Its scripts create temporary global scripts and command items, run them on a monitoring proxy, receive the result on the operator’s own listener, and delete the objects afterwards. One of those callbacks returned root identity and a hostname from the proxy to 38.180.16[.]98 on port 9090. I hold the join between that script and that callback at MODERATE, and I cannot name the network that owns the proxy, so it is graded COMPROMISED rather than added to the agency.

The technique is not a mark of special skill. It has been publicly documented since at least 2013, in a Metasploit module (CVE-2013-3628), a published exploit that drives the same thing over the JSON-RPC API, and the vendor’s own documentation of remote commands. Its value is as defender guidance, and it fingerprints nobody. What is less documented is the combination here: execution through a proxy, objects created in bulk and cleaned up, driven by an ordinary stolen account rather than an administrator.

12. The Port 53 Relay, and the WebLogic Scripts That Would Deliver It

The operator’s reverse relay is a 3,219-byte, 83-line Java source file, Relay.java.new, that calls home to 38.180.16[.]98 on TCP port 53 and does exactly what it is told. It announces itself, waits, opens a connection to whatever host and port the controller names, and then copies bytes in both directions until either side closes. There is no encryption, no authentication and no framing. Port 53 is the DNS port, which many networks let out when they block most other ports, but nothing about the traffic is DNS.

That design tells me what the operator cared about. Encryption and stealth layers add errors, truncation and dropped sessions; a bare line protocol does not. This operator wanted relayed traffic to arrive complete, and it accepted being easy to see on the wire in exchange. For defenders that is a gift, and Section 16 turns it into rules.

The operator’s own relay log shows the relay in use, with 1,051 check-ins from a single victim estate’s egress address, split into two labelled lanes. One lane, “pod”, announces READY and logs 648 check-ins with 272 tunnel-up events to 71 destinations. The other, “wls”, announces READY2 and logs 403 check-ins with 143 tunnel-up events to 6 destinations. There are 618 failed dials. The log has clock times but no date or zone, and it proves connection setup, not logins or transferred content.

13. MITRE ATT&CK Mapping

The mapping covers 70 procedure rows across 57 distinct technique IDs (Enterprise ATT&CK v19.2): 51 OBSERVED, 17 INFERRED and 2 NOT SHOWN. OBSERVED includes a retained attempt that failed, where the attempt is the procedure. INFERRED means the operator’s tooling is built to do it but no execution result is held. NOT SHOWN rows mark a boundary and claim no impact. Confidence grades the mapping and its evidence. On an INFERRED row, HIGH means I am confident the tooling does this; whether it ran is a separate question.

The techniques that carry the case are below. The full table follows in the collapse.

Port 53 here does not mean DNS tunnelling, and root identity returned from a monitoring proxy does not mean privilege escalation; I map neither. The help desk as a reconnaissance source sits under T1213, which is where ATT&CK puts it.

14. Threat Actor Assessment

I cannot attribute this activity to any publicly named actor or persona, and I put named-actor attribution at INSUFFICIENT. What I can describe with confidence is the operation: a sustained campaign of collection and access expansion across Brazilian public bodies and their suppliers, whose ultimate purpose is undetermined. The evidence for what the operator did is far stronger than the evidence for who it is. This is the first coverage The Hunters Ledger has published on this operator: no earlier case of mine touches its three addresses or the bpupdate.exe builds.

Nothing in the directory authenticates an identity. The operator’s git clones carry a root account on a provider-style host-local name, v487918523.local, which is a pivot candidate whose owner I have not checked, not a persona. Its working labels and comments are in Portuguese, mixed with English, which says what language it works in and nothing about nationality or location; I have no measured base rate for that and no working-hours analysis. Its self-labels (“red team”, “NOSSO”, test strings like PROVA123) are statements by the operator, and an intruder calling itself a red team is not evidence of permission. None of my other 69 investigations shares a recorded key, address or artifact with this one, though that comparison covered what I recorded for each case, not every byte of their tooling.

In my judgment this is not an authorised test, and I base that on three things I see constantly in my day job running a managed detection and response team. An authorised tester would not keep a victim’s data in a publicly reachable directory. A red team proves access and stops, and does not queue 4,675 documents for download or export a whole account table. And an engagement covers one organisation, perhaps one connected organisation.

This operator shows inside or authenticated access at five organisations, two of them only on saved pages whose capture route is unknown, and some of the five have no connection to each other at all. The other 87 of the 92 rows are probes, refusals and names on lists, so they say nothing about access, and it is the five that carry this point. The formal analysis leaves that hypothesis at LOW rather than excluded, because no owner has yet told me there was no engagement, and I cannot rule one out until they do.

It does not behave like a smash-and-grab access broker either. I would expect a broker holding what this operator held by early October to sell it and move on to the next target. This operator instead mapped the EDR estate for unmonitored machines, asked for agent uninstall passwords, kept a tunnel running and kept widening access. That points to someone who intends to act inside these networks itself. It is too long-running and too evasive to be a bulk collector, though it could sit somewhere between a broker and something else, so I hold access brokering at LOW rather than ruling it out.

On motive, my read is that it cannot be pinned down yet because the operator is early in its attack chain: still doing reconnaissance, setting up footholds, exploring and collecting. Sustained over weeks, from at least mid-September, the same behaviour is also consistent with espionage. The counter-evidence travels with that read. Across the whole directory the operator builds new access and uses access it already holds in similar measure (252 files against 213), and a sale made somewhere else would not appear in this directory. So collection may already be the objective, or a buyer may simply not be visible to me.

The competing-hypotheses analysis agrees with that uncertainty. Intelligence-purpose collection and direct financial use of benefit and tax data tie, with nothing to separate them: the source code and network inventories fit the first, and the account tables and a cracking pipeline fit the second. Nothing in the directory shows a recipient, a demand, a sale, a fraud transaction, a publication or destruction. My first reaction to the bank’s material was that it looked like extortion being prepared; nothing shows a demand, and I no longer rank that read above the others.

15. Indicators of Compromise

The machine-readable indicator set is published separately as a JSON IOC feed, undefanged and ready for ingestion. It carries 41 operator-side indicator entries: 2 full SHA-256 file hashes, 9 address and port entries over the three operator servers, 4 URLs, 12 file paths, 1 mutex, 1 TLS certificate, 3 service fingerprints, 6 relay network signatures, 2 behavioural patterns and 1 operator host-name fingerprint. Every entry carries its own confidence and action, and those govern over the feed-level label. The feed’s validator parsed 30 entries in 4 of its 10 containers; the other containers were not machine-checked.

Read the context fields before blocking. The port 53 entry is a historical operator role, held at HIGH. The READY2 first payload is DEFINITE only for the contained run of the wls-variant file, and which file was actually deployed is not established. The feed carries the same HIGH with the same scope note. A connection that announces only READY is the pod lane, whose source I never read, and it matters just as much.

The first address is recycled: its port 443 certificate, JARM and SSH key belong to earlier tenants, and ports 4000 and 111 were seen on it in the window but no operator file names them, so their role is unestablished. The second address also hosts ten third-party parked domains. The two URLs on port 8146 belong to the bpupdate.exe builds, whose tie to the operator is address-only, and they are carried at MODERATE.

Several things are deliberately not in the feed. The victim estate’s egress address, every victim-internal range, a victim’s external directory server and the unresolved peer of one Zabbix callback are excluded, because blocking a victim’s address harms the victim. Five operator tool hash sets known only by truncated prefixes are excluded by the full-hash rule. JARM values and SSH host keys are excluded because they either belong to earlier tenants or have no measured base rate. No credential, token, key or victim personal data appears anywhere in the feed.

The Zabbix object names (z- and wv3_ prefixes, poc items, diag-04 to diag-06, item identifiers 96795 and 96797 to 96802) live inside a victim’s monitoring server. They are in the feed as behavioural patterns for a Zabbix owner to search for in their audit log, never as blocklist entries.

16. Detection and Hunting Guidance

The full rule set is published separately at Detection Rules, Brazil Public-Sector Toolkit: 13 rules, 5 Sigma (3 detection, 2 hunting) and 8 Suricata (3 detection, 5 hunting), with no YARA. All 13 pass syntax validation. None has been measured for prevalence against real traffic, and the coverage-gaps section of that page is worth reading before deploying any of them.

The relay rules are the only ones I could fire against a real capture of the threat behaving, and the numbers belong to two different rules, so I keep them apart. The published announce rule fired on 22 of 22 relay sessions in the filtered capture (the relay sessions plus the one onward connection, on which it stayed silent), and on none of 2,411 TCP flows from seven unrelated captures. None of that traffic contains real DNS over TCP, so how the three port 53 rules behave against it is NOT CHECKED.

An earlier, scratch version of the announce rule, written from the same contained capture, fired on all 22 relay sessions and on none of the other 37 TCP flows in the unfiltered capture. Those 37 flows were the capture’s own background traffic, so that is a measurement against the scratch rule and not a false-positive rate. The full capture did not survive, so the published rule was never run against those 37 flows.

Everything built from the operator’s scripts (the WebLogic plant, the log scrub, the Zabbix commands) is grounded in what the scripts ask for, and has not been seen firing on victim telemetry.

Where to look first

Start with the help desk. Requests to GLPI’s vendor/htmlawed/htmlawed/ directory, and any POST to a test page there under any filename, are the agency’s entry point. Ticket and knowledge-base searches for security-stack terms (SentinelOne, Intune, Entra, GlobalProtect, remote shell) or for documents titled as database dumps, run in bulk by one session, are the reconnaissance. If you run GLPI 9.5.x, check inc/auth.class.php for code that writes submitted passwords to files/_log/event.log.

In the EDR console, SentinelOne’s management audit trail will show an API user enumerating service users, human users, the agent list and the rogue-device inventory, and asking for agent uninstall passwords. The last of those is the one to alert on. The token in this case came from a help-desk application’s integration settings, so any console token stored in a third-party application’s settings deserves rotation and an owner.

On the monitoring plane, the Zabbix audit log is where to look for global scripts or command items created, executed and deleted by one ordinary account within a short window, and for the object names in Section 15. On monitored hosts, a Zabbix agent or proxy process spawning a shell that reads shell histories, /etc/shadow, SSH keys or the cloud metadata endpoint is covered by one of the hunting rules.

At the egress, any internal host holding a TCP connection to port 53 whose payload does not parse as DNS deserves a look; Zeek and Suricata both flag it without knowing this relay’s strings. An application service account (in this case the WSO2 one) running a client that holds HTTPS to a hard-coded external address through the organisation’s own forward proxy is the bank’s pattern, and the proxy’s CONNECT log is where it shows.

For WebLogic, a shell spawned by the WebLogic Java process that writes a JSP into a _WL_internal or stage directory, or that rewrites log files under the domain tree, is covered by the Sigma rules. These come from scripts with no run evidence, so treat them as a hunt for the intent the scripts describe.

Response orientation

• Hunt first for POSTs to GLPI’s htmLawed test page under any name; SentinelOne console API enumeration and uninstall-password requests; Zabbix script creation and deletion bursts by one account; TCP 53 flows with no DNS.
• Look for and remove /tmp/upd running as an application service account; /tmp/Q.class; unexplained JSPs in WSO2 authenticationendpoint and oauth2 web applications; health.jsp or decrypt*.jsp under WebLogic _WL_internal; a password-logging hook in GLPI’s authentication class; Zabbix objects named z-*, wv3_*, poc* or diag-04 to diag-06.
• Contain by removing or patching GLPI’s htmLawed test page and any renamed copy, rotating the WSO2 keystore and reissuing the exposed OAuth clients, revoking console API tokens held in third-party settings, resetting accounts in the secretariat’s exposed account table (privileged and shared-hash accounts first), and blocking egress as the indicator table bounds it: the first address on its listed ports from 2026-09-26, the third address, and on the co-tenanted second address only port 8899, with the host itself monitored rather than blocked.

17. Notification

The bank and the agency were notified through CTIR Gov, Brazil’s federal government incident response centre, starting in early October. The bank received an early notice on 2026-10-04 and a full encrypted evidence package on 2026-10-09. The agency received an early notice on 2026-10-05, with CERT.br copied, and follow-ups after it.

On 2026-10-16 I sent a second round, through CERT.br, CTIR Gov or the organisation’s own response team, to the state traffic department, two state finance secretariats (one message also covering that state’s government), the federal health IT department and the agency’s federal IT provider, and a closing message to the agency. No recipient had asked me to hold publication when this report went live. I do not notify the remaining suppliers and third parties myself, among them the cloud services supplier and the managed security provider. They are the affected organisations’ to alert, and the evidence I sent them lists the suppliers they should notify. The indicator feed and rules go public together with the report.

I do not contact the institutions whose API credentials were exposed at the bank. Those subscribers are the bank’s to notify, and I gave the bank what it needs to do it. Organisations that appear here only at REACHED or LISTED, with nothing I can give them beyond the fact that they were probed, learn of it from this report.

18. Confidence Summary, Gaps, and What Would Change This

My findings sort cleanly by strength, and the table keeps each claim beside the observation that would move it.

The largest open questions are all things only the affected organisations can answer. Whether any access is current, whether the bank’s tunnel ever carried traffic, whether the GLPI credential hook was installed at the agency, whether any held credential or token is still accepted, and who owns the Zabbix servers, the integration database and the hosts the relay ran on are all NOT CHECKED. How many of the agency’s documents actually left is NOT MEASURED, though a join of the operator’s queue and log records could settle it.

Several things limit what I can say from the operator’s side as well. I never read the “pod” lane relay source. The real controller’s behaviour is unknown. The WebLogic plant, log scrub and relay delivery exist only as scripts. Some counts in this report come from a single reader of a large file, including the finance secretariat’s export figures, and the five largest counts (4,675 paths, the 905,374-byte decode, 1,051 check-ins, 245,707 rows, 49,131 lines) rest on their recorded methods rather than an independent recount. The prior-art searches were not refreshed between 2026-10-09 and publication beyond a check on 2026-10-15 that found nothing new naming this operator.

Of the hypotheses I could not kill, three matter most for a reader. The saved-page grades at the traffic department and the cloud supplier may reflect someone else’s collection. The long tail of REACHED and LISTED rows may be a product-class sweep rather than targeting. And collection may already be the objective, or a broker may simply not have listed yet. I would rather leave those open than pick the most satisfying answer for any of them.

19. References

• Cybernews (2026-09-09, updated 2026-09-10), report on an intrusion at a Brazilian federal agency and its IT provider; context only, no shared hard indicator.
• CyberCyber Labs (2026-07-28), “Inside an Exposed C2 Server” (CCL-2026-07-EXC2), sections 1 to 4; a different operator’s GLPI compromise of a Brazilian public body.
• Rapid7 (2013-10-30), Metasploit module zabbix_script_exec (CVE-2013-3628); authenticated Zabbix server-script execution.
• Exploit-DB 39937 (2016-06-06); Zabbix JSON-RPC script update and execution.
• Zabbix documentation, remote commands; vendor description of server, proxy and agent execution.
• CISA Known Exploited Vulnerabilities catalog (catalog version 2026.10.08); two Zabbix vulnerabilities listed, no post-exploitation pattern.
• VulnCheck, GLPI exploitation, CVE-2022-35914 (GLPI htmLawed) background; quoted passages read.
• Deepwatch (April 2022), advisory on exploitation of CVE-2022-29464 (WSO2), itself quoting Rapid7.

Acknowledgements

I thank Adverserial AI for access to its CyberKimi and CyberGLM models during this investigation. A good part of the operator’s tooling and the stolen data in this case is material that general-purpose AI models declined to read. Those two models read it for me, and some of the findings in this report rest in part on those reads.

© 2026 Joseph, The Hunters Ledger. Licensed under CC BY 4.0, free to republish and adapt, including commercially, with attribution to The Hunters Ledger and a link to the original.

@misc{hunters-ledger-opendirectory-38-180-16-98-brazil-public-sector-toolkit-20261015,
  author       = {Harrison, Joseph},
  title        = {Help Desks to Host Shells Across Brazil's Public Sector},
  howpublished = {The Hunter's Ledger},
  year         = {2026},
  month        = {oct},
  url          = {https://the-hunters-ledger.com/reports/opendirectory-38-180-16-98-brazil-public-sector-toolkit-20261015/},
  note         = {Published 15 October 2026. Licensed CC BY 4.0.}
}