Support

The email you got indicates that the attacker manually logged into the wp-admin of your site using a valid username and password. Most critically, it tells you WHICH username the attacker used. This is meant to be your last clue to troubleshooting a compromised site. I am a bit unclear as to what you mean with "my credentials" in this context.

Was it your secured-down account with 2FA and everything? That would mean that someone has access to all of that information. Either they've compromised your password manager, or they have compromised your own device. If that's the case, I'd recommend going full nuclear annihilation; wipe all electronic devices, and use a "virgin" device to log into the password manager and change its password to a random 24 to 32 character password generated using https://www.random.org/passwords/ which is noted down on a physical piece of paper until you can memorise it. Change all email passwords, making sure the attacker isn't doing a targeted attack being able to read your email. Only then proceed with the site clean-up.

Was it a forgotten Administrator account with a weak password and no 2FA? The attacker brute forced the password. As I told you, if someone gets your username and password they cannot be stopped by a security extension/plugin. From the site's point of view their accessing the site is indistinguishable from an authorised user accessing the site; the username and password are the proof.

Was it a new Administrator account? What happened depends on how you configured Admin Tools.

Admin Tools can block SQL injection attacks which could among other things create new users when you have SQLiShield enabled. If you disabled it, the attackers may have found a vulnerable plugin on your site and exploit it.

You can tell Admin Tools not to block requests from specific IP ranges. Is it possible you added IP ranges which are too wide, or your site needed you to enable "Enable IP workarounds" but you didn't? These would essentially remove all protection.

Did you use the Optimize WAF feature? Many WP plugins which need to do AJAX and things like that are written by scripters, not software developers. They do not know how to use WordPress features such as wp-ajax.php to handle non-HTML requests. As a result, they create their own directly accessible .php files with usually shoddy security. These files is what is usually attacked and exploited to compromise a site. The only way to have Admin Tools offer some basic protection for those files is using the Optimize WAF feature which tells your web server to run a basic version of Admin Tools' WAF on all requests made to .php files. If you didn't enable this protection, you had a huge attack surface area.

Moreover, The .htaccess Maker will prevent direct access to arbitrary .php files which protects you from a lot of attacks, including direct file write attacks which can't be otherwise stopped. It is an optional feature, though our quick setup wizard does remind you to use it. Conversely, you might have had to add exceptions to that protection i.e. allow specific .php files or entire folders to be accessed directly. This would leave you with the problem I described in the previous paragraph.

Furthermore, it is possible that your site, hosting account, or FTP credentials had already been compromised – this can be especially problematic if you share your credentials with third party developers (all of us expect temporary credentials which will be revoked after we're done working; if you reuse the same credentials, one person's security mishap leads to your site getting compromised from the inside). Remember, last time I told you to change all of these passwords to randomly generated ones with a length of at least 32 characters, and store them in a password manager. If an attacker has direct access to your hosting account or at least FTP/SFTP you're thoroughly screwed. They can just bypass all other protections in place.

Finally, it is possible that you are using a theme or plugin which is compromised. Many plugins in the WordPress Plugins Directory are sold or their accounts are compromised after being effectively abandoned for a while. The attacker will then publish an update with some minor bugfix and an exploit included in the code. Remember, installing a theme or plugin puts code into your site which CAN bypass your security; once the attacker has code executed on your site, especially code you installed yourself as a trusted Administrator who has already gone past all security measures, your site is pwned. You can't block malicious code already running on your site. It's game over.

I would very strongly advise you to contact your host so they can change your hosting control panel and FTP passwords for you, and disable any other FTP/SFTP accounts.

After you do that, it's time to completely empty your site, restore a backup, turn on Admin Tools' Emergency Off-Line Mode to limit access to your site just to your IP, and get to securing your site:

• Check your hosting account for any SSH keys. If you find any, remove them. A clever attacker may have installed their own SSH keys in your hosting account to get direct console access to your site. If they do that, they can bypass all security measures.
• Change your hosting account password.
• Remove any FTP users you do not use. Any FTP users you keep, change their password.
• Change your database user's password in your hosting control panel. Remember to update wp-config.php with the new password.
• Clean up any leftover files lying around on your site. Junk increases your security exposure.
• Change your own WordPress password.
• Revoke all Application Passwords (these are WordPress API keys) from your user account, if any are set up.
• Review all your plugins. Just because something is relatively popular doesn't mean it's not compromised. Check the WordPress Plugins Directory.
• Update all your plugins and themes.
• Make sure Admin Tools' WAF is enabled and check its configuration.
• Go to Admin Tools, Web Application Firewall, Administrator IP Whitelist, and click on Add New. You will see your current IP as detected by your server. Look it up in https://whatismyipaddress.com/. If it comes with something that is NOT your ISP go to Admin Tools, Web Application Firewall, Configure WAF, Basic Features and set Enable IP workarounds to Yes. Otherwise, set this option to No. 
• Run a PHP File Change Scanner and check the suspicious files against the original file sources, as described in the documentation.
• Turn off Emergency Off-Line mode at this point, as you will need to work on your .htaccess file.
• Turn on Optimize WAF.
• Apply the .htaccess Maker. Make sure you do NOT have too broad exceptions. If you have exceptions to allow some files, do remember that they are potential weak points in your security. Allowing Akeeba Backup's restore.php is safe (the file is inert except right after you press Restore in the interface) but if you do not plan on using the integrated restoration it's a good idea to remove that exception as well.

All password changes should be made with a password manager generating long, random alphanumeric passwords which are at least 32 characters long and include lowercase and uppercase letter, numbers, and symbols. DO NOT use dictionary word or other "memorable" passwords; if you can remember a password it's not really secure. DO NOT use password derivation algorithms e.g. the stupid things which use a (typically weak) password of your choosing and the site's domain and username to derive a password; they are functionally equivalent to using the same password everywhere, and the attackers are fully aware of them and do crack them easily.

That's why I mentioned the email in my previous message. The most common targeted attack involves getting access to the victim's email. Ideally, you want 2FA / MFA which doesn't use email. An authenticator code is usually okay, but it strongly depends on whether there's any kind of rate limiting (which really hard to do in PHP if your only persistence layer is an RDBMS like MySQL, MariaDB, or even PostgreSQL). The best method is using WebAuthn with a key stored either in a hardware dongle, or your smartphone protected by biometrics. It raises the bar for attacks substantially. Joomla has that out of the box –I contributed LoginGuard to Joomla back in 4.2– but I have not seen anything like that in WordPress that's not a fairly expensive third party service.

Have a good day!