A state university in Ilocos Region

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.

What Happened

On December 24, 2025, a Facebook page operating under the name "Philippine CyberMafia" published a post targeting a state university in Ilocos Region. The post was signed "~/.toothless", a handle consistent with the actor's pentester-style presentation (browser bookmarks visible in the screenshots include OffSec, Kali Tools, Kali Docs, Exploit-DB, and Google Hacking).

The post's Taglish caption mocked the institution's administrators and referenced the string `1=1` — the canonical SQL-injection payload used to bypass login forms by making the password-check clause tautologically true. This strongly implies the actor gained access through an SQL-injection authentication bypass on an internal administrative application.

What the Screenshots Appear to Show

Two screenshots accompany the post. If authentic, they depict:

• An authenticated administrator view of a web application hosted on a subdomain of the institution's `.edu.ph` domain (the specific subdomain is obscured in the post). The application is branded with the institution's official seal and name.
• A "Transactions" view filtered by an internal campus ICT management office. Columns shown include Queue Number, Office, Service, Counter, ID Number, Created At, and Transaction Date. The actual rows are redacted in the screenshots (overlaid in red), which is consistent with the actor having access to real data but choosing not to leak it publicly.
• A "Users" view with columns for Name, ID Number, Email, Phone, Program, and Course — a direct list of student personally identifiable information tied to academic records.
• A left-hand navigation indicating modules for Staffs, Users, Transactions, Request, and Reports, suggesting the application is a campus-services queueing or ticketing system rather than the main student-information system.

What Is Not Known

• The authenticity of the screenshots is not independently verified. Internal admin UIs can be screenshotted, mocked, or captured by authorized users; screenshots alone do not prove an external compromise.
• The scope of data accessed or exfiltrated is unknown. The actor redacted the actual records in the screenshots, so the volume, recency, and completeness of the data are not established.
• Whether the SQL-injection inference is correct — the `1=1` reference is suggestive but not conclusive; the actor may have gained access by another means and cited the payload rhetorically.
• Whether other institutional systems are affected — the screenshots show one subdomain application, not the main SIS, LMS, or email systems.
• The institution has not issued a public statement as of the date of this entry, and no news outlet has reported on the claim.

Why This Claim Warrants Attention

• Specific institutional branding — the screenshots are not generic; they show a real-looking internal campus-services portal with the institution's seal and terminology
• Plausible technical vector — SQL-injection authentication bypass remains one of the most common attack patterns against web applications that hand-roll authentication against string-concatenated SQL queries, especially older LAMP-stack apps maintained by campus IT offices
• Student PII surface — the Users view directly exposes identifiers (ID number, email, phone) that can be used for targeted phishing or account-takeover attacks against students
• Authenticated admin context — administrator-level access to a campus queueing system may be a lateral step toward higher-value targets if the app shares credentials, infrastructure, or network reach with other institutional systems
• Pre-existing attacker tradecraft — the browser bookmarks visible in the screenshots (Kali, OffSec, Exploit-DB) suggest the actor has pentester tooling, which raises the plausibility that additional discovery has been or will be performed

Recommended Actions for the Institution

1. 1.Treat the claim as a live incident until disproven — convene an IR team, identify the subdomain application depicted, and preserve server-side logs before retention expires
2. 2.Audit authentication and input-handling code for the application depicted — specifically look for string-concatenated SQL, absent parameterization, and missing input validation on login and search endpoints
3. 3.Review database and application logs for SQL-injection signatures (tautological boolean clauses, UNION SELECT patterns, out-of-band error messages) for the period leading up to the December 24 post
4. 4.Rotate all administrator and service-account credentials associated with the application and any systems it connects to
5. 5.Verify session and token invalidation — force re-authentication for any active sessions on the affected application
6. 6.Assess lateral exposure — map what other systems (SIS, LMS, email, VPN) share authentication, database servers, or network segments with the compromised application
7. 7.Notify the National Privacy Commission (NPC) within 72 hours if any personal data exposure is confirmed, as required by the Data Privacy Act of 2012 (RA 10173)
8. 8.Prepare student communications — if the Users-view data is confirmed accessed, students whose ID numbers, emails, and phone numbers were exposed should be notified so they can be alert to phishing
9. 9.Preserve evidence — archive the Facebook post, screenshots, and all referenced artifacts before the actor or platform removes them

How to Prevent This Pattern

1. 1.Use parameterized queries and prepared statements everywhere — never concatenate user input into SQL; eliminate the `1=1` class of bypass at the code level
2. 2.Adopt a well-tested ORM or query builder rather than hand-rolled SQL for internal tools
3. 3.Deploy a Web Application Firewall (WAF) in front of campus admin applications to block common SQLi patterns as defense-in-depth
4. 4.Remove administrator panels from the public internet — place them behind VPN, IP allowlisting, or SSO-gated access
5. 5.Enforce multi-factor authentication on all administrator accounts, especially for tools that expose student PII
6. 6.Conduct regular code review and penetration testing of in-house web applications, especially long-lived campus utilities maintained by student developers or rotating staff
7. 7.Subscribe admin endpoints to centralized logging and anomaly detection to catch unusual query patterns or authentication activity
8. 8.Inventory and retire orphan subdomain applications — unused or lightly maintained apps on `.edu.ph` subdomains are a frequent entry point
9. 9.Publish a security contact and responsible-disclosure policy so that findings are reported to the institution before they appear on Facebook