How Philippine Schools Get Breached
Based on incidents tracked on SchoolBreach.org, here are the most common attack vectors — ranked by frequency and impact.
1. Phishing and Social Engineering
Frequency: Most common
Example: DepEd Regional Email Phishing
How It Works
Attackers send emails impersonating DepEd, school administrators, or IT support. They ask staff to "verify accounts," "update credentials," or "review an important document." The link leads to a fake login page that steals credentials.
Why Schools Are Vulnerable
- Staff receive many official DepEd memoranda and are used to following instructions
- Many schools lack email authentication (SPF/DKIM/DMARC)
- Low cybersecurity awareness among non-IT staff
- Urgency tactics work well in hierarchical organizations
How to Defend
- Enable MFA on all accounts
- Train staff quarterly on phishing recognition
- Implement email authentication protocols
- Try the Phishing Awareness Quiz for staff training
2. Misconfigured Systems and APIs
Frequency: Very common
Example: Private School Enrollment Leak
How It Works
School enrollment portals, student information systems, or cloud storage are set up without proper authentication. Data is accessible to anyone who finds the URL — sometimes even indexed by search engines.
Why Schools Are Vulnerable
- IT staff may be undertrained or overworked
- Many schools use custom-built or low-cost systems without security review
- "It works" is prioritized over "it's secure"
- Cloud services (S3, Firebase) require explicit security configuration
How to Defend
- All APIs must require authentication
- Regular penetration testing of web applications
- Never use default credentials
- See the Site Scanner for guidance
3. Credential Stuffing and Password Reuse
Frequency: Common
Example: Catholic School Google Workspace Compromise
How It Works
Staff reuse their school passwords on personal websites. When those personal sites get breached, attackers try the same credentials on school accounts.
Why Schools Are Vulnerable
- No MFA enforcement on school accounts
- Staff not trained on password hygiene
- No password policy requiring unique passwords
- No monitoring for compromised credentials
How to Defend
- Enforce MFA — this alone blocks 99% of credential stuffing
- Use a password manager
- Monitor for compromised credentials (Google Workspace has built-in alerts)
- Test your password practices with our Password Strength Tester
4. Ransomware
Frequency: Growing
Example: State University Ransomware Attack
How It Works
Ransomware encrypts school files, databases, and systems, then demands payment (usually in cryptocurrency) for the decryption key. Schools are targeted because they often lack security and have time-sensitive data (enrollment, grades).
Why Schools Are Vulnerable
- Limited IT budgets for security tools
- Flat network architectures allow lateral movement
- Insufficient backup practices
- Enrollment and grading deadlines create pressure to pay
How to Defend
- Maintain offline backups (3-2-1 rule)
- Network segmentation
- Email filtering and endpoint protection
- Never pay the ransom
5. Unsecured IoT Devices
Frequency: Moderate but growing
Example: School CCTV System Breach
How It Works
CCTV cameras, biometric attendance systems, smart boards, and network printers are connected to the internet with default credentials. Attackers find them via IoT search engines.
Why Schools Are Vulnerable
- IoT security is an afterthought
- Vendors install devices with default passwords
- IT staff may not manage IoT devices
- Devices often share the network with student data systems
How to Defend
- Change ALL default passwords on every device
- Segment IoT devices on a separate VLAN
- Don't expose IoT devices directly to the internet
- Inventory all connected devices
6. Third-Party Vendor Breaches
Frequency: Moderate
Example: Online Learning Platform Data Exposure
How It Works
A third-party software vendor (LMS, enrollment system, communication tool) suffers a breach, exposing data from all schools using that platform.
Why Schools Are Vulnerable
- Schools don't vet vendor security practices
- No Data Processing Agreements in place
- Data from multiple schools co-mingled in one system
- Schools assume "cloud = secure"
How to Defend
- Vet vendors before signing contracts
- Require Data Processing Agreements
- Ask about data encryption and access controls
- Check if vendors are NPC-registered
7. Keyloggers (Hardware and Software)
Frequency: No reported Philippine school incident yet — but the threat is real and growing
Reference: Multiple US school incidents (University of Kansas, University of Iowa, Corona del Mar High School)
How It Works
A keylogger records every keystroke typed on a computer. Hardware keyloggers are small USB devices (costing as little as P1,000 / $20) plugged between a keyboard and computer — they require no software installation and are nearly invisible. Software keyloggers are programs installed on a computer that silently capture keystrokes and send them to the attacker via email or FTP.
In documented cases abroad, students installed hardware keyloggers on teachers' computers in lecture halls and faculty rooms, captured login credentials, then used those credentials to access grading systems and change their grades.
Why Philippine Schools Are Especially Vulnerable
- Shared computers in faculty rooms, computer labs, and libraries are common
- USB ports on school desktops are rarely inspected or locked down
- Many schools use single-password authentication for grading and SIS access — no MFA
- Faculty may not be trained to recognize a small USB device attached to the back of a desktop
- Hardware keyloggers are readily available on Shopee and Lazada
How to Defend
- Enable MFA on all grading and SIS accounts — even if a keylogger captures a password, MFA blocks unauthorized access. See our MFA Setup Guide for Schools
- Physically inspect USB ports on faculty and lab computers regularly — look for unfamiliar devices between the keyboard cable and the USB port
- Use USB port locks or blockers on machines that handle sensitive data
- Implement grade-change audit logs — alert administrators when grades are modified, by whom, and when
- Restrict physical access to faculty computers — lock rooms when unoccupied
- Train staff to recognize hardware keyloggers and report unfamiliar USB devices
- Use on-screen keyboards for entering credentials on shared machines as an extra precaution
8. Shared Hosting Exploitation and Web Shells
Frequency: Rising sharply in 2025–2026
Example: La Union Colleges Breach
How It Works
Attackers exploit a vulnerable site on shared hosting to upload a web shell — a small PHP file that gives them a browser-based file manager and command terminal on the server. From there, they read database credentials from config files, dump entire databases, and pivot to every other site on the same hosting account. One compromised account can take down multiple schools simultaneously.
Why Schools Are Vulnerable
- Shared hosting is the default choice for budget-conscious schools
- Multiple school sites often share a single hosting account
- Outdated CMS installations and plugins provide easy entry points
- Database credentials stored in plaintext config files are readable by any script on the same account
How to Defend
- Avoid shared hosting for any site that handles student data — use a VPS or managed hosting instead
- Keep CMS, plugins, and PHP updated
- Enable two-factor authentication on hosting control panels
- Monitor for unfamiliar PHP files in your web directories
- See our full guide: Shared Hosting and Web Shells
The Bottom Line
Most school breaches are preventable with basic security hygiene. The attacks aren't sophisticated — they exploit the most basic gaps: weak passwords, unpatched systems, untrained staff, and misconfigured services.
The Security Scorecard self-assessment can help you identify where your school stands.