A private Catholic university in Mindanao

Single-source notice: This incident is based on a single public post by a self-identified threat actor. No mainstream news outlet has reported on it, no independent researcher has corroborated it, and the institution has not issued a public statement. The claim remains unverified and the institution's name has been redacted pending verification.

The threat-actor post contains the specific AES-encrypted credential blobs, the seven SHA-512 password hashes, the RSA public key, the affected internal hostname, the internal database IP, the user-account names, and the SSL-certificate alias name. None of these values are reproduced on this site. The post is described here at the category level only — the values themselves remain in the actor's post and are intentionally not republished by this tracker.

What Happened

On June 2, 2026, the Facebook account using the name Nullsec Philippines publicly posted a long, technically detailed claim addressing a private Catholic university in Mindanao. The post was signed "0x.Zh3n and 0xTerror" with greetings to a long list of affiliated handles, including Fawkes Pilipinas, CrimsonSec Philippines, 4HmD0S4, Quantum Security Group, Lei$, B3RT1337, Nostra, 0xseve, X10N, crypt0nymz, Yasuo, C1pherus, Ph.Bin0x, and Ph.Blake — a constellation overlapping with prior Nullsec-attributed claims documented on this site.

The actors claim that the exploitation vector was an unauthenticated file-read vulnerability in the PeopleSoft WSRP Consumer ResourceProxy servlet on a student-records subsystem. If authentic, this is materially distinct from the database-leak and defacement claims dominant in the 2026 Philippine education-sector dataset: it is a credentialed compromise of the application server itself, providing the operator with the keys to every downstream system rather than a single application's row data.

The post enumerates four categories of extracted material, each with concrete values that are not reproduced here:

What the Actors Claim to Have Extracted

1. WebLogic domain and boot configuration credentials (AES-encrypted)

Eleven AES-encrypted credential strings were extracted from WebLogic domain configuration files and the boot configuration file. The categories enumerated in the post are:

• A domain credential (the WebLogic domain identity itself)
• The node manager username and password — control-plane credentials for the WebLogic server lifecycle
• The SSL private key passphrase — the secret protecting the institution's TLS/SSL identity
• The Java keystore and truststore passwords — the secrets protecting the application's certificate store and its accepted-CA store, respectively
• The embedded LDAP password — the authentication credential for the WebLogic-embedded directory service
• The boot administrator username and password — credentials used by the WebLogic server to start without manual authentication

These blobs are in WebLogic's standard `{AES}`-prefixed format. They are not directly usable as cleartext, but the same post claims that the WebLogic domain AES master encryption key file itself was also retrieved (see below). Once the master key is recovered via Java deserialization of the key file, every `{AES}`-encrypted credential in the post becomes plaintext on a single workstation, in seconds.

2. PeopleSoft application database connection credentials

The PeopleSoft WebLogic output properties file is enumerated as containing the encrypted Oracle database connection credentials (username and password), and the post identifies the internal database address and Oracle listener port. The internal IP, the port, and the cleartext form of the database credentials — once the AES master key is recovered — would together constitute a turnkey ingress for any actor with internal-network access.

A separate PeopleSoft Internet Architecture installation log is enumerated as containing the WebLogic administrator username in plaintext and the administrator password encrypted with the PeopleSoft-specific PIA V1.1 algorithm rather than the standard WebLogic AES. This is a different encryption family that requires the PIA-specific decryption key, but its presence in an installation log file alongside the username in plaintext means a defender cannot assume credential safety simply because the encryption format differs.

3. Operating-system password hashes (SHA-512 crypt)

The post publishes seven password hashes that the actors claim were extracted from the operating-system shadow file. The hashes are `$6$`-prefixed (Linux SHA-512 crypt format), which is offline-crackable using hashcat mode 1800 on a single consumer GPU against the rockyou wordlist and standard mutators.

The seven accounts include an admin account and six accounts with named-individual usernames consistent with employee identifiers. The post explicitly names the accounts. The seven account names and the seven hash values are not reproduced on this site. Defenders should assume offline cracking is already underway; any of these accounts that reuse passwords on email, cloud, or remote-access services elsewhere is at compounding risk.

The post claims the root account hash was withheld voluntarily. The remaining seven are sufficient for full system compromise via known privilege-escalation patterns on most legacy Linux installations.

4. RSA public key and historical Java keystore backups

One RSA public key from an SSH `authorized_keys` file is enumerated, and the actors note that the key appears in the `authorized_keys` of multiple user accounts on the affected host — implying lateral-movement infrastructure already in place across those accounts. The post asserts that the corresponding private key was not on the server itself, suggesting the private key resides on a workstation outside the host they breached.

Separately, the post enumerates five historical Java keystore backups dating to 2019, 2021, 2022, 2023, and 2025, in addition to the current keystore. The actors note that older backups "may be susceptible to default password attacks" — meaning that even if the institution rotates current credentials, the backup chain extending six years back may itself yield credentials that were valid at any point during that window, and any long-lived secrets (signing keys, internal-CA roots) that survived rotation.

Why the Methodology Treats This as 'Unconfirmed'

This entry is fully anonymized and tagged as `unconfirmed` because:

• The only public source is the threat actor's own Facebook post
• No corroborating media coverage has been observed
• No NPC finding is available
• No public statement has been issued by the institution
• The institution's name, the affected hostname, the internal IP, the user-account names, the SSL-certificate alias, and every credential blob and hash value are present in the threat-actor post but are not reproduced on this site; the inclusion of those values in any independent forensic verification cannot be checked from the public footprint alone

If the institution issues a statement, if reputable Philippine technology media independently reports the breach, or if the NPC publishes a finding, this entry will be updated and de-anonymized in line with the SchoolBreach.org methodology.

Threat-Actor Persona and Cross-References

The post is signed by the handles 0x.Zh3n and 0xTerror. The handle 0xTerror is also a co-signer of the state university in Mindanao credential-exposure claim (May 10, 2026), placing the same persona on two of the most operationally significant credential-extraction claims in the 2026 dataset, twenty-three days apart.

The greetz line on this post includes Quantum Security Group, the page that addressed the private IT-focused university chain (May 27, 2026) six days earlier. This explicitly places Quantum Security Group within the Nullsec extended-collective network rather than as an unaffiliated emerging actor — useful context for institutions assessing the breadth of the campaign.

The greetz line also includes crypt0nymz, the handle on the private school in Rosario, Batangas claim (April 28, 2026), and Yasuo, who co-signed the state university in MIMAROPA defacement (May 2, 2026). The constellation is now broad enough that a single threat-actor handle change is no longer evidence of a different operator; it is reasonable to treat these claims as the output of a single loose collective rather than as independent incidents.

Why This Claim Warrants Attention

• Application-server compromise, not row-level data theft. Most 2026 claims tracked on this site are either defacements (web-content compromise) or database leaks (row-level data theft). This claim is materially different: it is a credentialed compromise of the application server itself, which provides the operator with the secrets used by every other service the server fronts. If authentic, the operator can mint any session, read any database, impersonate any user, and re-establish access after credential rotation if any of the historical keystore backups yields a still-valid secret.
• Stale infrastructure. The WebLogic boot configuration file is timestamped 2018-06-30. The keystore backup chain runs from 2019 through 2025. PeopleSoft has had multiple critical-rated unauthenticated-file-read vulnerabilities disclosed in this window, and an institution still running 2018-era WebLogic boot configuration is likely behind on the underlying CPU patch schedule as well.
• Hashes are offline-crackable. The publication of `$6$` SHA-512 crypt hashes means cracking work is already happening on attacker hardware and is not visible to the institution's defenders. There is no log entry for offline hashcat work. The names of the seven accounts are public, which means credential-stuffing tests against the affected individuals' email, cloud, and remote-access accounts will likely begin within hours of the post's publication.
• Lateral movement pre-staged. The single RSA public key authorized across multiple user accounts is a classic post-compromise persistence pattern. Even if every shell password is rotated and every `{AES}`-encrypted credential is re-issued, that one key remains valid for SSH access to multiple accounts until removed from each `authorized_keys` file individually.
• Backup-chain blast radius. Five historical keystores cover six years of operations. Long-lived signing keys, internal-CA roots, and SAML token-signing certificates frequently outlive their owners' awareness; if any of them is still in use anywhere downstream, rotation of the current keystore alone will not contain the incident.

What Is Not Known

• Whether the values in the post are authentic. The credential blobs, the hashes, and the RSA key are all values an attacker could in principle fabricate to manufacture a more impressive-looking claim. Authenticity can only be confirmed by the institution's defenders matching the published values against their own configuration.
• Whether student data was directly accessed. The actor describes credential extraction, not row-level data retrieval. The published credentials make row-level access trivial if authentic, but no student records or sample rows are published.
• Dwell time. The actors do not disclose when the access was obtained or how long it persisted.
• Whether the institution is aware. No public statement has been observed at the time of this entry; whether the institution's IT or security function has been notified privately is not known.
• Whether the AES master key is already decrypted. The actors describe retrieving the WebLogic domain AES key file but state that Java deserialization is still required to extract the raw key. If the actors have already completed that step, every `{AES}`-encrypted credential in the post is plaintext to them; if not, the post's published `{AES}`-prefixed blobs may not yet be in directly usable form.

Recommended Actions for the Institution

1. 1.Treat the claim as credible until independently disproved, and begin a credentialed-compromise incident response immediately. Do not wait for hash-cracking confirmation or independent verification — the public footprint already obligates rotation.
2. 2.Rotate every credential category enumerated in the post. Every WebLogic AES-protected credential, every PIA V1.1-protected credential, every shell account password, every SSH `authorized_keys` entry on the affected host, every Java keystore password, the embedded LDAP password, the database connection credentials, and the boot administrator credentials must be re-issued. Treat the entire credential set as compromised regardless of whether the AES master key is yet decrypted.
3. 3.Re-key the WebLogic domain. Generating a new domain encryption key and re-encrypting every `{AES}`-protected blob is necessary; rotating only the protected values is insufficient if the master key file itself has left the host.
4. 4.Replace TLS certificates and rotate any signing keys. If the SSL private key passphrase was extracted, the private key must be assumed compromised; re-issue certificates and revoke the old ones via CRL/OCSP. If the keystore contained SAML signing keys, internal-CA roots, or token-signing keys, every downstream system that trusts those keys must be re-paired.
5. 5.Audit the PeopleSoft WSRP Consumer ResourceProxy attack surface. Confirm the vulnerable servlet is the version the threat actor exploited, apply the relevant Oracle critical patch update, and consider disabling the servlet entirely if it is not required for current operations.
6. 6.Audit `authorized_keys` across every user account on the affected host. Remove the published RSA public key from every account it appears in; review every other `authorized_keys` entry for currency and necessity; require named-individual SSH keys with hardware-token enforcement going forward.
7. 7.Audit the keystore backup chain. Each of the five historical backups (2019, 2021, 2022, 2023, 2025) must be assumed compromised. Any long-lived secret protected by any of those keystores — internal-CA roots, signing keys, SAML certificates — should be rotated and the rotation propagated to every dependent system.
8. 8.Audit the operating-system shadow file and the named accounts. Force a password reset on the seven accounts identified in the post (assume the hashes are already cracking). Coordinate with each named individual to rotate any reused credentials on personal email, cloud, and remote-access accounts. Consider HR-coordinated communication for the named employees specifically.
9. 9.Notify the National Privacy Commission within 72 hours under RA 10173. Even absent direct row-level student-record exfiltration claims, the credential set published in the post creates a documentable risk to personal data sufficient to meet the materiality threshold. The notification clock starts when the institution becomes aware, which is now.
10. 10.Engage an external incident-response firm. A credentialed compromise of an application server with this much downstream surface is beyond what an in-house team can typically scope under time pressure. The forensic question is not whether to rotate, but where else the operator went after extracting these credentials.
11. 11.Issue a same-day public advisory. The contrast example on this site is the Assumption College of Davao ICTC advisory (April 2, 2026), where a same-day institutional advisory strengthened rather than damaged the institution's reputation. Silence in the face of a publicly-published credential set leaves the threat actor's framing as the only public narrative.

How to Prevent This Pattern

1. 1.Patch PeopleSoft to the current Oracle Critical Patch Update. Unauthenticated file-read vulnerabilities in PeopleSoft components have been disclosed multiple times; the public detail in this claim should not be the first time a defender hears that an unauthenticated WSRP component exists on a public-facing surface.
2. 2.Disable or firewall PeopleSoft components that are not in active use. WSRP, ResourceProxy, and other portlet-era components are often left enabled in installations that no longer use them; the attack surface should match the operational surface.
3. 3.Externalize secret management. WebLogic-domain-encrypted `{AES}` credentials in configuration files on disk are a 2018-era pattern. A modern equivalent is a secret-management service (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) where secrets are retrieved at runtime and never written to a config file the application can be tricked into reading.
4. 4.Treat the shadow file as a single point of catastrophic failure. Restrict shell access on application servers to the minimum set of accounts that require it, prefer ephemeral session credentials (Teleport, Boundary, OIDC-fronted SSH) over long-lived passwords, and audit `authorized_keys` files as part of routine configuration management rather than only after incidents.
5. 5.Retain keystore backups only as long as required by the auditor's specific request. A six-year backup chain on disk in the application's own configuration directory means that an attacker with file-read access against the current keystore has six years of keystore alongside it; off-host, write-once, time-windowed backup storage is a better pattern.
6. 6.Run external attack-surface management against your own `.edu.ph` domain. Free and commercial services that crawl public surface and flag known-vulnerable PeopleSoft / WebLogic versions and exposed admin endpoints can catch the same issues that opportunistic actors are scanning for, before a Facebook post crystallizes the exposure into a permanent public artifact.
7. 7.Publish a security contact and responsible-disclosure policy. Researchers who find a PeopleSoft WSRP vulnerability should have a private channel; absent one, the only available channel is the public-Facebook-post channel that produced this incident.