Inside an Attacker's Toolkit Targeting Vietnam's Government Networks

Hunt.io Attack Capture™↗ (opens in a new tab) flagged an open directory at IP address 212.232.23[.]75 on port 8877, first logged on September 21, 2026.

A full inventory of the directory reveals a single operator running one core intrusion against Vietnam's Ministry of Foreign Affairs through a compromised Keycloak single sign-on server, a second confirmed compromise of an insurance management platform at 113.160.10[.]154 reached through credential reuse, password-spraying and reconnaissance against Vietnam's Ministry of Public Security and Ministry of Construction, and general-purpose attack infrastructure, a rogue LDAP/JNDI/OIDC catcher, a full ysoserial payload set, and Windows privilege-escalation tooling, kept on hand well beyond this one campaign.

Let's walk through what was recovered.

Key Findings

• Exposed attack infrastructure: An open directory at 212.232.23[.]75:8877 exposed 484 files containing exploit scripts, logs, configuration exports, and staged payloads.

• Keycloak compromise: Artifacts indicate administrative-level access to the Vietnam Ministry of Foreign Affairs Keycloak SSO environment.

• Check Point exploitation attempts: Recovered scripts target CVE-2026-50751 and CVE-2026-91843.

• Insurance platform access: Logs show activity involving a separate insurance management platform at 113.160.10[.]154, including MinIO artifact retrieval and inbound SMB/JRMP traffic.

• Additional government targets: Recovered scripts target systems associated with Vietnam's Ministry of Public Security and Ministry of Construction.

• Broader attack toolkit: The directory contains LDAP/JNDI/OIDC infrastructure, Java deserialization payloads, credential-attack tools, and Windows privilege-escalation utilities.

Infrastructure Details

The host at 212.232.23[.]75↗ (opens in a new tab) is associated with ROCKHOSTER PRIVATE LIMITED (AS215381) and is geolocated to Singapore. Hunt.io↗ (opens in a new tab) recorded four warnings for potential malicious open directories on ports 8765, 8877, 8888, and 8899.

One of the exposed services was an open directory at 212.232.23[.]75:8877↗ (opens in a new tab) captured on September 21, 2026. The directory contained 484 files across eight subdirectories, with a total size of approximately 587 MB. The service was running Python's SimpleHTTP/0.6, and Hunt.io identified the root as a directory listing.

Ministry of Foreign Affairs: Keycloak Compromise and Internal Pivoting

The mofa_ scripts work through a target list of more than thirty subdomains under mofa.gov[.]vn: visa, passport, dichvucong, qlvb, intranet, owa, sharepoint, teams, and others.

The mofa_recon.py script scans eleven mofa.gov.vn subdomains, checking common ports, HTTP/HTTPS services, SSL details, cookies, and sensitive paths. It also groups hosts by IP address to map the Ministry of Foreign Affairs' infrastructure and identify exposed services.

Early scripts fingerprint and probe specific platforms:

• mofa_sp2010.py and mofa_sp_exploit.py target a SharePoint 2010 instance at visa.mofa.gov[.]vn.
• mofa_dnn.py and its variants (_final, _l2, _lf, _login) go after a DotNetNuke deployment, consistent with CVE-2017-9822, a DNN personalization deserialization bug from 2017.
• mofa_telerik.py targets Telerik UI's file-upload handler, consistent with CVE-2019-18935↗ (opens in a new tab).
• mofa_gql.py and mofa_gql2.py walk a GraphQL endpoint at web.mofa.gov[.]vn using introspection, a reconnaissance technique for mapping an API's entire schema from the outside.

Keycloak Abuse: Tokens, Realm Configuration, and Execution Attempts

mofa_deep2.py, mofa_rce3.py, and auto_shell.py target https://sso-ingo.mofa.gov[.]vn/auth, the Ministry’s single sign-on server.

mofa_deep2.py requests with client_id=admin-cli against /realms/master/protocol/openid-connect/token, and if it doesn't return a token, the script prints [-] No token and exits immediately. After obtaining a token, it moves through a series of Keycloak reconnaissance and exploitation steps, including server information collection, internal service probing, Docker-related SSRF attempts, realm enumeration, and authentication-flow manipulation. The full sequence is shown in the flowchart below.

I have found a full export of the /admin/serverinfo endpoint (mofa_serverinfo.json, 420KB) confirming a Keycloak 26.4.6 instance running on Java 21 with eight CPUs and 512MB of heap, plus exports of the realm configuration for cucngoaivu (the Bureau/Department of Foreign Affairs tenant) and the master realm itself.

The directory contains JSON definitions for three suspicious Keycloak components:

• Rogue LDAP federation provider: Connects the realm to the attacker-controlled server ldap://212.232.23[.]75:53.
• Script-based authenticator: Uses Keycloak’s legacy JavaScript scripting feature to execute Runtime.getRuntime().exec("id"), indicating potential command execution.
• Custom theme provider: Points to a writable path, potentially enabling a follow-on template-injection attack.

A captured JWT contains a realm-admin token for cucngoaivu, with impersonation and manage-users permissions. Its client scope includes reportmgt, sohoa (digitization system), storagemgt, and flexdata.

mofa_rce3.py creates a confidential client with authorization services enabled, attaches three JS-based policies containing literal java.lang.Runtime.getRuntime().exec(...) and ProcessBuilder calls, one of which opens a reverse shell back to 212.232.23[.]75:4444 and another that curls a callback to 212.232.23[.]75:8888/rce. It also probes an internal host for a Spring Cloud Gateway actuator endpoint and waits for a callback.

The auto_shell.py script reuses the Keycloak token flow to test CRLF injection against an assumed internal Redis service, then attempts command execution and persistence through Redis, SSH, webshells, and callbacks. It also includes an LDAP deserialization fallback using ysoserial. The separate Redis target suggests an attempt to extend access beyond the Keycloak host.

Liferay and IdentityServer: Authentication and Account-Manipulation Attempts

Three scripts mofa_oidc.py, mofa_token.py, and mofa_reg.py target my.mofa.gov[.]vn, which runs a Liferay and IdentityServer stack, while mofa_rp.py targets an unrelated cPanel server at 103.1.209[.]115.

• mofa_oidc.py pulls OIDC metadata from my.mofa.gov[.]vn, tests the iworkspace_redacted_ client and several credentials, creates accounts through Liferay GraphQL, and attempts logins against its JSONWS/GraphQL APIs.

• mofa_token.py uses the same client to probe my.mofa.gov[.]vn and web.mofa.gov[.]vn, including Liferay admin APIs, script execution, rogue-account creation, and JSP upload paths.

• mofa_reg.py targets the IdentityServer endpoints at my.mofa.gov[.]vn/auth/Account/Register and /auth/Account/Login, testing credentials and registration flows.

Internal Reconnaissance Through Keycloak SSRF

The cp_ssrf_exploit.py script focuses on internal network discovery through Keycloak, using four techniques to probe Check Point management services.

It first attempts to authenticate to Keycloak using a short list of credential pairs across two realms. It tests both the legacy /auth/realms/... and newer /realms/... path formats used by different Keycloak versions, then verifies administrative access through /admin/serverinfo.

Once authenticated, the script maps the internal network through four techniques that abuse Keycloak administrative features to trigger server-side HTTP requests.

• The first registers a temporary OIDC identity provider with a discovery URL pointing to each candidate internal host and port.
• The second creates a temporary OAuth client with a user-controlled back-channel logout URL, then triggers a login and logout cycle to make Keycloak send a server-side POST request.
• The third repeats the port-mapping process through SAML identity-provider metadata import.
• The fourth directly uses Keycloak's identity-provider configuration import endpoint to probe Check Point management services, including the SOAP path /cpmws/LoginSvcRemote.

The script stops at the port-mapping stage. The actual exploitation of CVE-2026-91843 is handled by the separate cp_91843.py script series discussed below.

The docker_raw.py attempts to exploit the LDAP CRLF-injection primitive to reach Docker’s unauthenticated API at 127.0.0.1:2375. It uses HTTP request smuggling to submit a container-creation request that mounts the host filesystem and runs with privileged access, potentially enabling host-level access. The script tests three payload variations across the bindDn and bindCredential fields. No evidence in the directory confirms that a container was successfully created or started.

scg_exploit.py reuses the admin token and LDAP CRLF-injection technique to target a Spring Cloud Gateway instance. It attempts to exploit CVE-2022-22947 by injecting a route configuration containing a SpEL expression that executes the id command. The script tests five variants, including route creation, a baseline connection check, route enumeration, a gateway refresh request, and attempts against four alternative ports. No evidence in the directory confirms that the payload executed successfully.

The SSRF logs confirm that Keycloak can make outbound requests to attacker-controlled URLs. ssrf_proxy.log, captured on the operator's listener at 212.232.23[.]75:53, records HTTP requests from 202.6.2[.]2 with the user agent Apache-HttpClient/4.5.14 (Java/21.0.9). The requests include a POST _redacted_ containing a structurally valid Keycloak logout JWT for the cucngoaivu realm. This confirms that the first stage of the SSRF chain worked.

redirect_ssrf.log, generated by ssrf_redir.py, records 13 redirects to internal host on ports 8017and 8083. The host mentioned in the logs corresponds to the Jolokia and Spring Boot Actuator target discussed in The Rest of the Toolbox.

Similarly, docker_ssrf.log documents redirect attempts involving Elasticsearch, Grafana, RabbitMQ, Prometheus, and Kubernetes kubelet endpoints, but provides no evidence of access to the Check Point subnet.

The logs show that the Keycloak instance made outbound requests to attacker-controlled infrastructure, consistent with successful SSRF at that stage.

Check Point: VPN Authentication Bypass and Management-Server Exploitation Attempts

Separate scripts target the gateway directly through its external address.

cve_50751.py

The script closely adapts research published by WatchTowr in 2026. WatchTowr's technical analysis↗ (opens in a new tab) describes the vulnerability and its exploitation. It targets CVE-2026-50751↗ (opens in a new tab), a certificate-authentication bypass affecting Check Point's IKEv1 remote-access VPN. The vulnerability allows authentication as a valid VPN user with a self-signed certificate by exploiting a flaw in how the iked process handles the IKE VPNExtFeatures vendor ID. The vulnerable implementation can skip certificate signature and trust-chain validation. Check Point addressed the issue in hotfix sk185033.

cp_91843.py through cp_91843_p8.py

These eight script versions target CVE-2026-91843↗ (opens in a new tab), described in the accompanying research as an unauthenticated stack-based buffer overflow in the Check Point Security Management and Log Server login handler. The reported impact is root-level code execution, with a CVSS score of 9.8. The vulnerability is triggered by a login request containing an oversized username.

The scripts target 202.6.2.3 across multiple Check Point management ports, including 18190, 19009, 18264, 18209, 18210, and 18211.

Check Point issued a LivePatch under advisory sk1000155↗ (opens in a new tab). The eight iterations indicate continued development of the exploit, although the files alone do not establish whether it achieved code execution.

The directory also contains cp_userenum.py, which attempts to enumerate valid VPN usernames, alongside cp_cookies.txt and cp_headers.txt, which appear to contain session-related artifacts.

The available evidence does not establish whether the Check Point exploitation attempts succeeded.

Insurance Platform: Database, MinIO, and Windows Access

The host at 113.160.10[.]154 appears to run an insurance management backend, based on the qlbh-be-api Docker image and Oracle SID QLBHPDB. The recovered toolkit shows database access attempts, SSH-based operations, MinIO object-storage activity, and a planned lateral-movement path.

Database Access Attempts

The file mssql_hashes.txt contains nine password hashes associated with accounts including sa, webapp, and qlvb. The toolkit also contains an MSSQL command-execution technique using sp_OACreate and WMI.

SSH Access and Ministry Targeting

A hardcoded administrator credential appears across multiple scripts, indicating reuse within the recovered toolkit. One script, wq_file.py, stages and launches spray.ps1 toward the Ministry of Public Security. The evidence links this activity to the existing SSH foothold, but does not independently establish the full outcome of the operation.

MinIO Access and Deployment Activity

The MinIO logs confirm downloads of two production artifacts from the deploy-images bucket: qlbh-be-api.tar (324 MB) and qlbh-fe-web.tar (96 MB).

Webhook logs also record callbacks containing s3:ObjectCreated:Put events for uploaded objects, including deploy-images/deploy.sh and deploy-images/test_redis.txt. This confirms that the storage workflow generated notifications for those uploads.

The toolkit includes deploy_trigger.py, which attempts to upload a JSP web shell and a redeployment script. However, the available logs do not establish that either file triggered a redeployment.

A separate modified MinIO startup wrapper, minio_backdoor.sh, contains reverse-shell, SSH-key, and cron-based persistence mechanisms.

Windows Access and Internal Pivoting

The Windows host WIN-0VKLM8DCCRM provides additional evidence of activity against the insurance environment. The capture logs record authentication attempts and Java RMI traffic involving the operator's infrastructure.

• The file impacket_smb.log records the host authenticating to the operator's SMB server. This is consistent with a forced-authentication technique in which a target system is induced to authenticate to an external server.

• The file jrmp.log records Java RMI/JRMP traffic from 113.160.10[.]154 reaching a deserialization listener on port 9999. This confirms that the listener received traffic from the host.

• The directory contains Windows privilege escalation tools such as GodPotato.exe, GodPotato2.exe, JuicyPotato.exe, and PrintSpoofer64.exe.

• The collection also includes ncat.exe, which can provide network relay functionality.

The remaining artifacts are summarized below, with their apparent purpose:

Supporting Infrastructure and Other Targets

Beyond the primary targets, the recovered files reveal supporting infrastructure and tools configured for broader exploitation and access attempts.

Rogue LDAP, JNDI, and OIDC Infrastructure

The collection includes a rogue LDAP server, a separate JNDI responder, and a fake identity provider configuration.

The script rogue_ldap.py listens for LDAP connections on port 53. When it receives a search request, it returns a crafted entry containing JNDI reference attributes. The reference names an Exploit class and points to http://212.232.23[.]75:53/ as its codebase.

The script attempts to serve Java class files over HTTP on the same port. The associated Exploit.java source contains a static initializer designed to execute a base64-encoded reverse shell targeting 212.232.23[.]75:5555.

The related script rogue_jndi.py implements a separate approach involving ELProcessor and RMI referrals. It does not rely on the Exploit.java class used by the LDAP responder.

The directory also contains rogue_idp.py and several fabricated OIDC discovery documents that imitate the ministry's identity provider. Their jwks_uri fields point to internal endpoints, including the Docker API and a MinIO health check, instead of the expected key-set location.

The script meta_srv.py provides a configurable responder for several internal service endpoints. It serves predefined responses for Consul, Eureka, Spring Cloud Config, Docker, and Redis information requests from the meta_responses/ directory. It also records requests containing exfil or xxe in their paths. This allows the operator to inspect how applications respond to requests directed at internal services.

Additional Vietnamese Government Targets

The recovered scripts also target systems associated with Vietnam's Ministry of Construction and Ministry of Public Security.

The script attack_baocao.py targets baocao.moc.gov[.]vn, a reporting portal associated with the Ministry of Construction. It contains a reverse-shell callback configured for port 5555. A second script, scan_kc.py, performs a general port scan against 119.15.167[.]216. This address falls within the same /24 network as baocao.moc.gov[.]vn, which resolves to 119.15.167[.]139.

The PowerShell script spray.ps1 targets Exchange infrastructure under MPS.GOV[.]VN, associated with the Ministry of Public Security. It performs password spraying against a list of candidate usernames based on personal names.

The proxylogon2.py script, configured to target mail.mps.gov.vn (42.1.75[.]63), demonstrates a more advanced Exchange exploitation effort. It begins by probing /ews/exchange.asmx, /rpc/rpcproxy.dll, and /autodiscover/autodiscover.xml using unauthenticated NTLM negotiation to identify internal NetBIOS and DNS domain names from server challenge responses.

The script then attempts to exploit two known Microsoft Exchange vulnerabilities:

• CVE-2021-26855 (ProxyLogon), using an X-BEResource cookie-based server-side request forgery (SSRF) technique against /ecp/y.js and related front-end paths.
• CVE-2022-41080 (OWASSRF), using a crafted X-OWA-ExplicitLogonUser header in requests to /owa/.

Pre-generated Java Deserialization Payloads

The directory contains seven pre-generated ysoserial payloads covering several common Java gadget chains.

The directory combines reusable exploitation tools with scripts configured for specific government systems.

Assessment of Confirmed Activity

Three findings in this directory are supported by captured evidence of real network activity.

1. The first concerns the Ministry of Foreign Affairs Keycloak single sign-on server at sso-ingo.mofa.gov.vn. The collected artifacts indicate administrative-level access, including a 426 KB export of the /admin/serverinfo endpoint and a realm-admin JWT containing impersonation and manage-users permissions. A separate inbound request captured on the operator's listener bears Keycloak's Apache-HttpClient/4.5.14 (Java/21.0.9) signature and contains a structurally valid logout JWT.

2. The second finding involves a Windows host identified as WIN-0VKLM8DCCRM, associated with a separate victim network behind an insurance management platform at 113.160.10.154. The impacket_smb.log file records the host authenticating to the operator's SMB server, consistent with forced authentication. Meanwhile, jrmp.log records Java RMI/JRMP callback traffic from the same IP address reaching the operator's deserialization listener.

3. The third finding concerns the insurance platform's MinIO object store. The api_dl.log and mc_dl.log files record the retrieval of build artifacts using similar credentials. The http_cb.log file also records a callback from the host to a webhook registered by the operator when new objects were written to the bucket.

Defensive Recommendations

Organizations running similar environments should prioritize the following controls.

• Restrict administrative access to identity providers such as Keycloak to trusted management networks or approved remote-access paths. Enforce MFA for administrators wherever supported.

• Keep VPN gateways, identity servers, firewalls, hypervisors, databases, and application-management interfaces on supported versions with current security updates.

• Restrict administrative interfaces to approved source networks.

• Enforce outbound network controls on application and identity servers. Allow only required destinations, protocols, and ports.

• Validate URLs, redirects, and imported identity-provider metadata against strict destination allowlists.

• Require authentication and appropriate authorization for Docker, Kubernetes, Redis, Elasticsearch, monitoring interfaces, and other internal management services.

• Eliminate default and shared credentials.

• Monitor password spraying, repeated authentication failures, unusual successful logins, unexpected SMB authentication, and new SSH sessions between internal hosts.

• Monitor for unauthorized identity-provider configuration changes, new privileged accounts, web shells, scheduled tasks, cron jobs, unexpected SSH keys, and modified service binaries.

Conclusion

The recovered directory documents a broad toolkit configured for identity infrastructure abuse, internal service discovery, remote code execution attempts, credential attacks, and lateral movement. Captured artifacts support administrative-level access to the Ministry of Foreign Affairs Keycloak environment and network activity involving a separate insurance platform, including SMB authentication, JRMP callbacks, and MinIO artifact retrieval.

However, the evidence does not establish that every staged payload executed or that every targeted system was compromised.

Defenders should validate the affected systems against the reported indicators, audit identity-provider and management-plane configurations, rotate potentially exposed credentials, restrict internal service access, and investigate suspicious deployment and persistence mechanisms.

The central lesson is that identity infrastructure and internal management services must be treated as critical security boundaries, not trusted paths through the network.

MITRE ATT&CK Mapping

Indicators of Compromise