# Post-Incident Website Validation: What to Check After Credentials or Code May Have Been Compromised

Canonical: https://vulnify.app/blog/post-incident-website-validation-compromised-credentials-code

Use this post-incident website validation workflow after credentials, repositories, code, or administration access may have been compromised, with focused public checks and broader recovery guidance.

After a developer account, administrator credential, repository, CI system, or web server may have been compromised, restoring access is only part of the recovery process. The organization also needs to understand what changed on the public website. An attacker with legitimate credentials can make changes that look like normal administration: add a route, weaken a header, upload a file, create a redirect, replace a script, change DNS, or deploy a modified build. Post-incident website validation does not replace endpoint forensics, log analysis, repository review, credential rotation, or incident response. It provides a complementary external view: what is now observable from the internet, and does that public state differ from the expected baseline? Contain the incident before treating validation as recovery If compromise is active or strongly suspected, prioritize containment. Isolate affected endpoints where appropriate, revoke compromised sessions, rotate relevant credentials, restrict attacker access, preserve evidence, and involve the incident-response owner. Running a website scan while the attacker still controls deployment credentials does not solve the underlying problem. Once immediate containment is underway, public-surface validation can help identify changes that need investigation. Build a timeline of potentially exposed access Determine when the credential or system may first have been compromised and when access was revoked. The time window helps investigators review deployments, DNS changes, repository activity, cloud events, CMS modifications, and administrative actions. Which accounts were exposed? Which environments could those accounts reach? Could they deploy code or only edit content? Could they change DNS, CDN, WAF, or certificate configuration? Could they upload files or install plugins? Could they create new credentials or service accounts? Could they modify CI/CD secrets? The answers determine which public checks deserve the most attention. Compare the public site with a known-good baseline If you have earlier scan reports, monitoring data, deployment records, or configuration exports, use them. Post-incident review is much stronger when it can answer "what changed?" instead of only "what exists now?" A useful baseline includes certificates, redirects, security headers, common exposed paths, technology fingerprints, cookies, expected hostnames, and important public routes. Vulnify's Website Watch can be useful for ongoing change detection when it was in place before the incident, while previous scan reports can provide broader point-in-time comparisons. 1. Check DNS and hostname changes Review authoritative DNS records, recently added subdomains, mail-related records, CDN destinations, and any changes to the primary origin. Attackers with registrar or DNS access can redirect traffic without modifying application code. Confirm that production hostnames still resolve to expected infrastructure and that old or temporary records have not appeared. If domain control may have been exposed, rotate registrar and DNS-provider credentials, review MFA and recovery settings, and inspect audit logs directly with the provider. 2. Check TLS and certificates Confirm the certificate presented publicly is expected, valid for the correct hostnames, and chained to the expected trust path. Unexpected certificate issuance can be an indicator that domain or hosting control changed. Use the SSL Checker for a focused external view, but also inspect certificate-transparency and provider records if certificate abuse is part of the incident hypothesis. 3. Check redirect behavior Compromised sites are sometimes modified to redirect selected visitors to phishing, malware, affiliate, or spam destinations. Redirects can be conditional and may only affect certain paths, devices, or referrers. Use the Redirect Chain Checker on the homepage and representative deep links. Investigate unexpected hostname changes, new intermediate hops, loops, or HTTP downgrades. Compare results from different relevant routes rather than assuming the homepage represents the entire application. 4. Check security headers and browser controls An attacker or emergency configuration change can weaken CSP, HSTS, framing controls, or other response headers. Compare current public headers with the baseline and review changes in the application, reverse proxy, CDN, and WAF. The Security Headers Analyzer and CSP Checker can provide focused verification of the final public response. 5. Check exposed files, backups, and administrative paths Attackers and responders alike can leave artifacts behind. Compromised credentials may be used to upload web shells, archives, diagnostic files, or alternate administration endpoints. Incident responders may also create temporary backups that accidentally remain under the web root. Use the Exposed Paths Checker for common public exposures, then supplement it with direct server and filesystem review. A public checker cannot enumerate every attacker-chosen filename or prove that the filesystem is clean. 6. Check technologies and public JavaScript Compare visible technology fingerprints and major JavaScript resources with the known application. Unexpected frameworks, version changes, third-party hosts, or script files can be useful investigation leads. Vulnify's Website Technology Fingerprint can help review visible stack information. The JavaScript Library Vulnerability Checker can review supported publicly exposed library information. Neither replaces repository integrity checks or software composition analysis inside the build environment. 7. Check cookies and session behavior If authentication code or proxy configuration changed, session cookies may lose Secure, HttpOnly, or SameSite attributes, change domain scope, or be issued unexpectedly on insecure paths. Review both the cookie attributes and the session architecture. The Cookie Security Checker can support public inspection. If administrator or user sessions may have been stolen, revoke them at the application or identity-provider layer rather than relying on cookie flags alone. 8. Check mixed content and external resource changes A compromised template or injected script can add resources from unexpected origins. Mixed content may also appear after emergency restoration if old HTTP asset URLs are reintroduced. Use the Mixed Content Checker and review page source, browser network activity, and CSP reports where available. Unexpected third-party resources deserve investigation even when they use HTTPS. 9. Run a broader public-surface scan After focused checks, run the Website Security Scanner against the authorized production origin. A broader assessment can identify supported public-facing weaknesses that may have appeared during compromise or recovery. A clean result is not proof that the attacker left no persistence. Server-side malware, hidden accounts, repository backdoors, cloud persistence, compromised CI/CD runners, and secrets exposure require direct incident-response work. Hypothetical scenario: compromised developer token A developer's Git hosting token is stolen from an infected workstation. The attacker creates a small change in a frontend dependency, and a normal CI pipeline deploys it. The build passes because the code is syntactically valid and the attacker uses legitimate access. The organization revokes the developer token and resets the laptop, but that alone does not remove the deployed change. Repository review identifies the unauthorized commit, the build is rebuilt from a known-good revision, and the public site is compared with the earlier baseline. Public JavaScript resources, CSP, technology fingerprints, and redirects are checked again after redeployment. The lesson is that credential recovery and application recovery are related but separate workstreams. Hypothetical scenario: compromised CMS administrator A phishing incident exposes a CMS administrator account. The attacker installs an unfamiliar plugin and inserts a redirect into a template. After the account is reset, some mobile visitors still report unexpected destinations. The response should include CMS plugin and theme review, file-integrity checks, credential rotation, audit-log analysis, and a clean redeployment where possible. External redirect and technology checks can confirm whether the suspicious public behavior remains after recovery. Restore from something you can trust When integrity is uncertain, editing individual suspicious files in place may leave hidden persistence. Recovery should use a known-good source where practical: verified repository revision, trusted package sources, clean infrastructure definitions, and controlled secrets. Rebuild rather than merely deleting the artifact you happened to notice. Document what evidence makes the restored state trustworthy. A backup created after compromise may contain the same malicious change. Preserve evidence before cleanup Do not let public validation become destructive cleanup. If a suspicious file, redirect, or script is discovered, capture the relevant URL, timestamps, response data, hashes, and server-side evidence before removing it when incident procedures permit. Preserved evidence can help determine how the change arrived, whether it was accessed, and which other systems need investigation. Coordinate this with the incident-response owner. The fastest visible cleanup is not always the best forensic decision, especially when legal, insurance, customer-notification, or law-enforcement requirements may apply. Monitor after the immediate recovery After the site is restored, watch for recurring changes. Reappearing files, headers, redirects, certificates, or technologies may indicate an incomplete remediation or a deployment process that is restoring compromised configuration. Ongoing monitoring is not proof of attacker eviction, but it can give early warning when the public state drifts again. Post-incident website validation checklist Contain compromised accounts and systems first. Define the likely exposure window. Review DNS and registrar changes. Verify public TLS certificates. Inspect redirects on representative routes. Compare security headers and CSP with the baseline. Check common exposed paths and uploaded artifacts. Review public technologies and JavaScript resources. Inspect cookies and session configuration. Check mixed content and unexpected external resources. Run a broader authorized website scan. Review repositories, servers, CI/CD, cloud logs, and endpoints separately. Restore from a known-good state where integrity is uncertain. Monitor for regression or reappearance after recovery. Conclusion Post-incident validation should answer a concrete question: after containment and remediation, does the public website look and behave like the trusted system you intended to run? Compare DNS, TLS, redirects, headers, paths, technologies, scripts, cookies, and broader scanner findings against a known baseline. Use Vulnify for the external validation layer, but keep endpoint forensics, source integrity, credential response, and incident investigation in the hands of the systems that can inspect them directly.