A private medical college in Cebu City

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 post's screenshots include the specific subdomain path, an internal database name, and table/column names, and the post links to an archive.md snapshot of site pages. None of these identifiers are reproduced on this site, in line with the methodology of describing operational material at a category level rather than redistributing it.

What Happened

On July 23, 2026, a Facebook post attributed to the page "Nullsec Philippines" addressed a private medical college in Cebu City, opening with a taunting "HELLO THERE" before claiming the poster had "deleted some files on your system" and framing the act as trivial — "its not that hard to fix its my dirty hand against my keyboard." The post referenced an accompanying video the poster said they had made an effort to produce, and linked to an archive.md snapshot described as preserving pages of the institution's site "before the disaster."

The post included two embedded screenshots documenting the claimed access, discussed below. The text was signed "~0x.Z & F," followed by a "SPECIAL GREETZ" line naming ten additional handles. As reviewed for this entry, the post had drawn 90 reactions, 22 comments, and 21 shares, including at least one follow-up comment posted by the page itself roughly two hours after the original post.

A Second Documented Incident at This Institution

This is not the first entry on this site involving this institution. A May 31, 2026 defacement claim by Quantum Security Group (QSG), signed by the persona ZeuS, documented the simultaneous defacement of 27 subdomains on the same institution's primary domain — including, most significantly, a publicly-reachable phpMyAdmin database-administration subdomain, three public development environments, and a payment subsystem. A June 2026 follow-up post under the same QSG banner escalated that claim to bulk data exfiltration backed by a multi-volume archive listing. That entry remains status 'investigating' (elevated from the usual single-source 'unconfirmed' baseline because the original 27-subdomain defacement was independently, publicly verifiable) and anonymized under the same descriptor used here.

The present incident, roughly seven to eight weeks later, again centers on a publicly-reachable database-administration interface — this time Adminer rather than phpMyAdmin — alongside a webshell providing command execution. Whether this reflects the same exposure never having been fully closed, a different exposure on a different host or subdomain reopening the same class of misconfiguration, or an entirely unrelated access path cannot be determined from the screenshots reviewed. What can be said is that the specific recommendation made in the prior entry — to take the publicly-reachable database-administration subdomain offline immediately and permanently — evidently did not extend to closing off this class of exposure institution-wide, if this incident's evidence is accurate.

The two incidents are attributed to different signing personas — ZeuS under the Quantum Security Group banner in May-June, and the pairing signed "~0x.Z & F" with tooling branded for Lei$ under Nullsec Philippines here — but QSG and Nullsec Philippines are documented elsewhere on this site as affiliated channels within the same broader collective, so the actor overlap between the two incidents cannot be treated as independent corroboration of either claim. Each incident is assessed on its own evidentiary merits under this site's methodology.

What the Screenshots Show

• A webshell-style file-manager interface. The first screenshot shows a browser window on a mail-related subdomain of the institution's domain, displaying a tool banner reading "LEI - NULLSEC PH [WAF BYPASS]" above a path field, a command-execution box, and file/directory upload and creation controls — consistent with a webshell providing arbitrary command execution rather than a simple file-upload flaw.
• An attempted mass-deletion command. The command box shows a recursive delete issued against the hosting account's home directory. The visible output is dominated by "Permission denied" results against files within what appears to be a backup or trash-archive path tied to the institution's site — indicating that, for the portion of the attempt visible in the screenshot, deletion was substantially blocked by filesystem permissions rather than fully successful. The referenced backup path's contents (page-import, custom-post-type, and icon-picker plugin files) indicate the archived site copy runs on WordPress.
• A database-administration interface (Adminer). The second screenshot shows Adminer, a web-based database client, open against a database identified in its own interface as the institution's production Student Information System, with the schema/structure view open for a student-fee-related table — showing column names covering fee schedules, payment status, and financing-agent references, but no row-level student data. A sidebar in the same screenshot lists dozens of additional tables in the same database, spanning admissions, financial/banking transactions, dormitory management, and academic and clinical-curriculum records. No data export or row sample was shown for any table in the material reviewed.

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 screenshots themselves cannot be independently authenticated — a webshell banner and a database client's schema view are both straightforward to stage, and the visible permission-denied output for the deletion attempt is, if anything, more consistent with a partially blocked action than a fully successful one

If the institution issues a statement, if reputable Philippine technology media independently reports the incident, 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's text is signed "~0x.Z & F." The first element is consistent with 0x.Zh3n, a recurring persona already tracked on this site as co-signer of the private Catholic university in Mindanao PeopleSoft credential-extraction claim and, under the "Zhen" stylization, the private computer college in Rizal province database-leak claim two days before this post. The second element, "F," does not resolve to a specific persona from the material reviewed; Fawkes Pilipinas is separately named later in the same post's greetz line, and it is not established whether the sign-off's "F" refers to that page, a different handle, or is unrelated.

Separately, the embedded webshell interface carries its own banner reading "LEI - NULLSEC PH [WAF BYPASS]," explicitly invoking Lei$. Lei$ has appeared in the greetz line of multiple entries already tracked on this site, including the private university in Cebu City subdomain defacement and, two days before this post, the private computer college in Rizal province database-leak claim — but always as one of several names in a greetz list, not as a tool's named operator. Branding a specific access tool with an individual handle is a more concrete, individually attributable signal than a greetz credit, and marks a visible escalation in how directly this persona's operational role can be documented on this site.

The greetz line also names Nostra, previously tracked in the technical institute in Laguna defacement and IBA College of Mindanao entries; 0xTerror, signer of the private university in Cebu City subdomain defacement and co-signer of the private Catholic university in Mindanao PeopleSoft claim and, by cross-reference there, the state university in Mindanao credential-exposure claim; Ch4nc3ll0rx1337, primary signer of the DepEd Tayo Roxas City and DepEd Tayo Lucena City defacements; and Fawkes Pilipinas, the sister page credited across a large share of the entries on this site, including the same University of San Carlos Publishing House defacement where Lei$, 0xTerror, and Ch4nc3ll0rx1337 were all listed together as group members. 0xseve and Bin0x are recurring greetz names on this site; Bin0x is consistent with the "Ph.Bin0x" handle noted elsewhere. Inv4der is consistent with the recurring greetz stylization "1nv4d3r." Nuclie, tr414l3r0, and G0Ju.VBS do not appear in any prior entry on this site and are logged here as newly observed handles associated with the collective.

The density and overlap of this roster — a two-element signature plus a nine-name greetz line, several of whom have signed or co-signed prior entries individually — places this claim within the same continuing campaign documented elsewhere on this site, rather than as an isolated or unaffiliated incident.

Why This Claim Warrants Attention

• Two distinct access classes demonstrated, not one. The screenshots show both host-level command-execution access (the webshell) and application/data-layer access (a live database-administration panel against the production Student Information System) — a broader compromise footprint than a single-vector defacement claim.
• The exposed database is a core operational system, not an ancillary one. The visible table list spans admissions, financial/fee transactions, dormitory management, and academic records — functions central to daily institutional operations.
• A destructive action was attempted regardless of its actual success. Whatever the permission-denied output means for the outcome, both the intent and the capability to run a recursive delete against the hosting account's home directory were demonstrated.
• Public exposure of a database-administration interface is independently significant, apart from anything else the actor did with it — this class of misconfiguration is detectable and preventable before an incident occurs, not just after one.
• Multi-persona attribution ties this to an active, ongoing campaign, per the cross-references above, rather than to an isolated incident.
• This is the second documented incident at this institution within roughly two months, both involving an exposed database-administration interface. Whether that reflects incomplete remediation or a recurring architectural pattern, it is independently significant context for evaluating the institution's response to this claim and the credibility of any remediation to date. See the May-June 2026 incident.

What Is Not Known

• Whether the deletion attempt succeeded elsewhere on the system. The visible output shows permission-denied results only for the sampled backup/trash-path files; the post does not show the outcome for the site's live, active directories.
• The authenticity and completeness of the database access shown. Only one table's column structure was shown; there is no row-level data, and no way to confirm from the screenshot alone whether the credentials used still work.
• The initial access vector. Neither screenshot shows how the webshell was placed or how the database-administration tool became reachable — whether through a vulnerable plugin, exposed default credentials, a leaked password, or another route.
• Whether this incident reuses the access path from the May-June 2026 incident at this institution, reflects incomplete remediation of it, or is an entirely separate exposure.
• The content of the page's own follow-up comment on the post, visible beginning roughly two hours after the original post, whose full text was not available for this entry.
• Whether the institution is aware. No public statement has been observed, and it is not known whether the post has been reported to the institution privately.

Recommended Actions for the Institution

1. 1.Treat the claim as credible until independently disproved, and begin incident response immediately. Screenshots showing live command-execution and database-administration capability are sufficient basis to act without waiting for further proof from the poster.
2. 2.Immediately audit for and remove any webshell or unauthorized file-manager script, across the full hosting account and not just the single path visible in the screenshot.
3. 3.Restrict or remove public access to any database-administration interface (Adminer or equivalent) reachable from the open internet; where one must remain available, gate it behind VPN access, IP allowlisting, and its own independent authentication layer.
4. 4.Rotate every credential category tied to the production Student Information System — database service accounts, the web application's own database user, hosting/control-panel logins, and any credentials cached in configuration files reachable from the affected host.
5. 5.Reduce the database user's privileges to least-privilege, so that a future exposure of the application's own credentials cannot again open a full schema-browsing session of the kind shown here.
6. 6.Audit authentication, file-system, and database-access logs with at least a 90-day retention floor, to establish dwell time and determine whether data was queried or exported beyond what the screenshots show.
7. 7.Restore affected directories from a verified clean backup, and confirm the integrity of the backup/trash path referenced in the screenshot before relying on it for restoration.
8. 8.Notify the National Privacy Commission within 72 hours under Republic Act No. 10173. The legal trigger is risk to personal data, not certainty of exfiltration; live administrative access to a database covering admissions, financial, and academic records meets that threshold regardless of whether row-level data was shown.
9. 9.Issue a same-day public advisory. Silence leaves the threat actor's framing as the only public narrative. The contrast example on this site is the Assumption College of Davao ICTC advisory.
10. 10.Engage a forensic firm to determine the initial access vector for both footholds — the webshell and the database-administration exposure may not share a single entry point, and confirming each independently matters for closing them fully.
11. 11.Commission an independent, comprehensive security audit rather than relying on any remediation claimed after the May-June 2026 incident at this institution. The recurrence of a publicly-reachable database-administration interface — now Adminer, previously phpMyAdmin — is independently significant regardless of whether the two incidents share a root cause, and warrants verifying that the earlier incident's recommended remediations were actually completed institution-wide rather than applied only to the specific subdomain named at the time.

How to Prevent This Pattern

1. 1.Never expose database-administration tools (Adminer, phpMyAdmin, or equivalent) on a public-facing hostname. These are administrative tools by design and belong behind VPN or IP-restricted access at minimum.
2. 2.Run routine file-integrity monitoring on all web-facing hosts to catch webshells and unauthorized file-manager scripts shortly after upload, rather than discovering them from a threat actor's own screenshot.
3. 3.Use least-privilege database accounts for application connections, distinct from any administrative account, so a leaked application credential cannot open a full schema-browsing session.
4. 4.Keep CMS plugins and import/export tooling current, and minimize their footprint. The backup path referenced in the screenshot shows several third-party plugins that should be audited for known vulnerabilities and removed if unused.
5. 5.Segregate backup and trash directories from the live web root with restrictive permissions, and verify they cannot be enumerated or written to by the same account a public-facing application uses.
6. 6.Run external attack-surface scans against all .edu.ph subdomains, not just the primary site, to catch exposed admin panels and management interfaces before an opportunistic actor does.
7. 7.Publish a security contact and responsible-disclosure policy, so that anyone who finds an exposed administrative interface has a channel other than a public Facebook post.
8. 8.Treat any post-incident remediation as unverified until independently re-tested. A recommendation to take an exposed interface offline after one incident does not guarantee it was applied system-wide; a follow-up scan or audit should confirm the fix before considering the incident closed.