FortiBleed question about admin accounts

Yes, creating admin accounts is one of the most common persistence moves after a FortiGate is compromised, so you are not seeing a glitch, you are seeing the attacker's foothold. Thirteen admin accounts is a clear, confirmed compromise. The most important thing I can tell you up front: do not just delete the rogue accounts and carry on. Once an attacker had full admin on the box, you have to assume they planted persistence beyond what you can easily enumerate, so this is a rebuild, not a cleanup.

What else to hunt for, because accounts are rarely the only thing they leave behind:

• API users. config system api-user. These carry tokens that survive admin password changes, so a deleted admin account does not lock them out. Very common backdoor.
• SSH keys on admin accounts. Check every admin for a planted set ssh-public-key, including the legitimate-looking ones.
• Automation stitches and actions. config system automation-stitch and automation-action. Look for anything that runs a CLI script or fires on an event, since attackers use these to recreate accounts after you delete them.
• Management exposure changes. Check each interface allowaccess for HTTPS or SSH added on the WAN, the admin trusthosts on every account, config firewall local-in-policy, and config system global for changed admin-port, admin-sport or admin-ssh-port.
• VPN backdoors. New IPsec tunnels or dialup, new SSL VPN settings, portals or SSL VPN users, and any new local users or user groups.
• New remote auth servers. RADIUS or LDAP entries pointing at infrastructure you do not own.
• New policies, VIPs and port forwards giving inbound access to internal hosts, and any any-to-any allow.
• DNS, static routes, DDNS and FortiGuard override-server changes used to redirect or exfiltrate.
• Logging tampering. You said logging shows little, which is itself a signal. Check whether log settings were reduced or disabled.

On forensics despite the thin logs: use the configuration revision history. In the GUI under System, Config Revisions, or via the revision CLI, you can diff the current config against a revision from before the incident and see exactly what was added and roughly when. That timeline often tells you more than the event log when logging is sparse. Since this box is on FortiGate Cloud, also pull the FortiCloud side, it may retain admin login records and logs the device itself no longer shows, and check the FortiCloud account for unauthorized access and rotate its credentials too.

Remediation, treat it as fully compromised:

• Isolate the device now.
• Rotate every secret that ever lived in that config, not just admin passwords. API keys, local user passwords, VPN pre-shared keys, RADIUS and LDAP bind credentials, SNMP communities, and any private keys or certificates on the box. Assume all of it is exposed.
• Reflash firmware from a clean image and rebuild from a known-good backup taken before the compromise, or rebuild clean. Do not restore the current tainted config.
• Re-issue any certificates the device held.
• Bring it back hardened: management off the internet, trusted hosts and local-in policies, MFA on all admin and VPN logins.
• Investigate laterally. This was a foothold. Look at what that firewall could reach and whether the attacker pivoted, especially anything reachable over its VPN or management network.

It being non-production lowers the business impact but not the investigation effort, because it still sat on your network as an attacker-controlled device. If it touched anything sensitive, treat it as a real incident and consider bringing in IR support rather than self-cleaning.

Besides what I already wrote on Reddit, there is no pattern to look for - “FortiBleed” is a PR stunt unrelated to a specific exploitation. If you look at previous CVEs, you may start at https://www.fortiguard.com/psirt - in each CVE listed there there is an explanation/workaround section, for some CVEs Fortinet also published known Indicators of Compromise you may use for scanning your Fortigate. 

On a personal opinion side - can you reverse engineer embedded, built on Linux kernel but still monolith OS of FortiOS in a controlled lab? If not, then chances of you discovering IOCs not listed in previous PSIRT alerts, sorry, but are close to zero. If it is indeed important to you, namely - you have a regulatory/law/government obligation to investigate the break in, then you can open ticket with Fortinet and ask them to do investigation of your FGT, not sure the procedure as never done it before. But as hobby/past time exercise - beyond checking the Fortinet published IOCs, it is a 99% chance of wasting your time.