I’m trying to sort out the practical response to reports of leaked FortiGate credentials. The reports describe reused credentials and brute-force activity, rather than a newly disclosed vulnerability. For an internet-facing firewall or SSL VPN, what should we prioritize?
If our FortiGate credentials may be exposed, what should we tackle first?
Asked by
~Jigsaw+2
Answers
Treat it as a possible account compromise, not just a password-change exercise. Disable or restrict internet-facing VPN and admin access if you can do so safely, then invalidate active sessions and rotate credentials for VPN users and administrators. Use unique passwords and phishing-resistant MFA where available.
After that, review authentication and firewall logs for unfamiliar logins, new accounts, configuration changes, and unexpected outbound or lateral activity. If anything looks suspicious, preserve the logs and follow your incident response process rather than assuming a reset resolved it.
Reply to this answer
First verify what is actually exposed and which credentials could apply to it. An old password appearing in an infostealer log is still a concern, but it does not by itself prove someone accessed your firewall. Check whether affected users reused passwords, and reset those credentials anywhere they were reused.
Also confirm the device is on a currently supported, patched version and that management access is not open to the whole internet. The reports mention specific older vulnerabilities, but don’t treat patching as a substitute for credential rotation and log review.
Reply to this answer
Don’t rotate everything in a panic without a plan. Make sure you have a working out-of-band way to reach the firewall, identify who owns each account, and coordinate changes so you don’t lock out the people needed to investigate. Then invalidate sessions and rotate in a controlled order.
If the firewall is business-critical, a temporary access restriction may be safer than abruptly shutting off VPN for everyone. That depends on your setup and response procedures, so involve the network and security teams.
Jax:
Good point on access recovery. I’d also make sure the configuration and relevant logs are backed up before making changes, while keeping those copies protected.
Reply to this answer
One caution: avoid putting company credentials into an unofficial lookup site just to check exposure. Use your organization’s security team and trusted incident-response channels to assess whether accounts appear in the reported data.
And don’t assume a public list naming a company proves its systems were accessed. Treat it as a lead to investigate, not a complete incident report.
Reply to this answer
Add your answer
Answers are reviewed before publication.
~Jigsaw+2:
Would you reset service or automation accounts too, or only accounts used by people?
Nettle_+6:
Include any account that can access the device or VPN, including service accounts, but check dependencies before changing them so you don’t break integrations. Confirm the new credentials are unique and stored safely.