STATUS: INCIDENT RESOLVED - REMEDIATION PLAN READY

SECURITY INCIDENT REPORT

WASH Institute Server Compromise & Remediation

Report Generated: October 14, 2025

Classification: INTERNAL USE ONLY

1. IMMEDIATE ACTIONS TAKEN

✓ Emergency Response

  • • Redirected washinstitute.org and www.washinstitute.org to beta.washinstitute.org
  • • Taken offline affected subdomains: mtu.washinstitute.org, sanitationsystems.washinstitute.org
  • • Taken offline affected subdirectory: /urban
  • • Quarantined WordPress/PHP site infrastructure
  • • Server admins initiated full disk restoration from clean backup snapshot
  • • Identified attack vector through forensic analysis

✓ Damage Control

  • • Prevented continued visitor exposure to malicious content
  • • Maintained main online presence via beta subdomain
  • • Isolated compromised subdomains and subdirectories
  • • Preserved evidence for forensic analysis

2. REMEDIATION PLAN

⚠️ CRITICAL NOTICE

The server restoration will address immediate symptoms, but the vulnerability remains. Without addressing the root cause, the sites are subject to identical attacks.

Our Approach: Static HTML Conversion

Rationale:

  • • Eliminates PHP execution entirely, removing all code injection/execution vulnerabilities
  • • Provides permanent security solution
  • • Low complexity and risk
  • • Minimal ongoing maintenance
  • • Zero hosting costs

Implementation Steps:

  1. Conduct full content audit to determine scope
  2. Export all WordPress and custom PHP pages to static HTML
  3. Generate static pages for all public-facing content
  4. Preserve all PDFs, media, and document libraries as-is
  5. Create simple static navigation structure
  6. Set up Cloudflare R2 for media and document storage
  7. Configure proper security headers
  8. Implement HTTPS with automatic certificate renewal
  9. Set up 301 redirects for existing URLs (SEO preservation)
  10. Deploy to Cloudflare Pages staging environment
  11. Comprehensive testing of all links and resources
  12. Content audit and verification
  13. DNS cutover to Cloudflare Pages production
  14. Monitor for issues post-migration

Timeline: To be determined based on full content audit and scope assessment

Future Content Management:

If self-service content editing is required in the future, the existing Payload CMS + Astro/Next.js platform can be extended to manage this static content. This would be evaluated as a separate project after the immediate security concerns are addressed.

3. WHY THIS APPROACH

Static HTML Benefits:

  • • Provides immediate and permanent security by eliminating all PHP execution vulnerabilities
  • • Zero attack surface for code injection
  • • Zero ongoing security maintenance costs compared to WordPress ($0/year vs $1,100-2,500/year)
  • • Excellent performance (static pages load instantly via global CDN)
  • • Minimal ongoing maintenance required
  • • Free hosting on Cloudflare Pages

Why Not Return to WordPress/PHP:

  • • WordPress/PHP will always be a high-value target for attackers
  • • Complex attack surface (plugins, themes, core, custom PHP code)
  • • Requires ongoing vigilant maintenance (weekly scans, monthly audits, quarterly penetration testing)
  • • High long-term cost and risk ($1,100-2,500/year + significant time investment)
  • • System (especially the old custom PHP implementation) is already severely outdated
  • • Exact location of current vulnerability is unknown—likely more exist
  • • Even with hardening, WordPress/PHP remains vulnerable to zero-day exploits and plugin/theme vulnerabilities

Security Comparison

Aspect Old WordPress/PHP Static HTML
Code Injection Risk High Zero
Attack Surface Very Large Minimal
Maintenance Required Constant Minimal
Update Frequency Weekly/Monthly Rarely

4. REQUIRED STAKEHOLDER DECISIONS

Immediate Decisions Needed:

  1. Approve static HTML approach: Confirm this is the path forward
  2. Content priority: Which pages/content are most critical?
  3. Functionality requirements: Which features must be preserved?
  4. Subdomain/subdirectory decisions: Should mtu.washinstitute.org, sanitationsystems.washinstitute.org, and /urban be restored or retired?
  5. Budget approval: Confirm hosting costs ($0/year on Cloudflare free tier)

Questions to Answer:

  • □ Are there critical dynamic features needed (user accounts, forums, e-commerce, etc.)?
  • □ What is the acceptable timeline for deployment?
  • □ Who will handle future content updates? (developer-assisted is expected for static sites)

5. NEXT STEPS

Immediate Actions

Static HTML Conversion & Deployment

INCIDENT DETAILS

Technical analysis and forensic findings

6. EXECUTIVE SUMMARY

Incident Overview:

  • • Multiple WordPress/PHP sites compromised through file upload vulnerability
  • • Malicious index.html files injected recursively across all directories
  • • Main WordPress index.php files overwritten with redirect code
  • • Attack vector: Form-based file upload without proper MIME type validation
  • • Result: washinstitute.org and www.washinstitute.org redirected to malicious/spam/porn sites

CRITICAL FINDING

  • • Vulnerability: Insecure file upload form allowing arbitrary PHP file execution
  • • WordPress/PHP system extremely out of date on security updates
  • • PDFs, media, and static assets likely unaffected
  • • Significant malicious code injection across WordPress/PHP files

7. ATTACK TIMELINE

Tue, Oct 7

Redirected https://washinstitute.org to https://beta.washinstitute.org, triggering reindexing and crawler activity

Wed, Oct 8 - Sun, Oct 12

Redirect temporarily removed; malicious crawler exploited vulnerability during this window

Sat, Oct 11

All visitors to https://washinstitute.org redirected to malicious URLs

Mon, Oct 13

Emergency redirect to https://beta.washinstitute.org implemented; WordPress/PHP site quarantined

8. DAMAGE ASSESSMENT

5,492

Files Compromised

100%

Directory Compromise

Affected Systems:

  • • washinstitute.org (main WordPress site)
  • • www.washinstitute.org
  • • mtu.washinstitute.org (subdomain - TAKEN OFFLINE)
  • • sanitationsystems.washinstitute.org (subdomain - TAKEN OFFLINE)
  • • /urban subdirectory (TAKEN OFFLINE)
  • • Multiple custom PHP sites on same server
  • • All directories containing index.html/index.php files

Files Compromised:

  • • index.html files created recursively in all folders (with redirect code to malicious websites)
  • • index.php files overwritten with redirect code
  • • 5,492 files written/compromised (primarily index.html and index.php files)
  • • Static assets (PDFs, images, documents) likely intact

Current Status:

  • • Main sites (washinstitute.org, www.washinstitute.org) redirected to beta.washinstitute.org (safe holding page)
  • • Affected subdomains taken offline: mtu.washinstitute.org, sanitationsystems.washinstitute.org
  • • Affected subdirectory taken offline: /urban
  • • WordPress/PHP infrastructure quarantined
  • • Server admins restoring disk to older snapshot (IN PROGRESS)

9. ROOT CAUSE ANALYSIS

Primary Vulnerability:

Form-based file upload system without proper security controls:

  • • No MIME type validation
  • • No file extension whitelisting
  • • No upload directory restrictions
  • • Allowed arbitrary PHP file execution

Note: The exact location of the vulnerable form is unknown due to the vastness and complexity of the legacy codebase. Given the outdated nature of the system, attempting to locate and patch this specific vulnerability is impractical and insufficient—other unknown vulnerabilities likely exist.

Contributing Factors:

  • • PHP system severely outdated (security patches not applied)
  • • Increased exposure due to site reindexing (attracted malicious crawlers)
  • • No file integrity monitoring

Attack Chain:

  1. Attacker uploaded malicious .php file via vulnerable form
  2. PHP file executed via HTTP requests to upload endpoint
  3. Execution script created index.html files recursively
  4. Script overwrote index.php files with redirect payload
  5. All site visitors redirected to attacker's malicious domains

10. LESSONS LEARNED & PREVENTION

What Went Wrong:

  1. File upload form lacked basic security validation
  2. PHP system critically outdated (Less likely to be WordPress because it's relatively new, but can't be completely ruled out)
  3. No intrusion detection or file integrity monitoring
  4. No automated security scanning
  5. Site exposure increased during reindexing period

How to Prevent Future Incidents:

  1. Never trust user input: Always validate, sanitize, and restrict file uploads
  2. Eliminate server-side execution: Static sites cannot execute malicious code
  3. Defense in depth: Multiple security layers (WAF, monitoring, backups)
  4. Keep systems updated: Automate security patching where possible
  5. Regular security audits: Quarterly reviews and penetration testing
  6. Incident response plan: Documented procedures for rapid response

Security Checklist for Any Future Web Platform