In this blog post, we’ll talk about protecting your VM admin credentials. The admin credentials are clearly the keys to the kingdom on your VMs and you want to protect them as good as possible. However, that can turn out to be fairly hard, for example if you need to publish the VM for RDP access directly to the internet, for maintenance or remote access scenarios. Of course, Site-to-Site VPN or ExpressRoute would be the recommended approach, but still many VM’s are directly exposed to the internet for various scenario.
Attackers are trying to find and take over VMs on the internet and use them for their purposes – mining for cryptocurrencies is only one of the purposes attackers use these stolen VMs. When attackers try to steal these VMs, they’ll usually try to log on using RDP for Windows or SSH for Linux machines and try to find brute-force their way into the VM, both using well known…
- … usernames with all potential password combinations
- … passwords and they try them with various user names
The latter is especially interesting and seen more often recently, since these attacks focusing on the usernames not necessarily trigger account lockouts – easy passwords are tried over the account estate and by the time the next password is used on any single account, the observation window for the lockout policy is usually long past.
Protect your assets
Protecting your credentials from attackers is the business of making it harder and more complicated to capture the credentials and misuse the VM. You don’t usually have to make it impossible to use the VM, but apply some common sense protections to it:
- don’t publish VMs on the standard ports, such as TCP 3389 for RDP or TCP 22 for SSH, so “stupid” scanning scripts won’t figure out there’s an endpoint available to test accounts on.
- avoid to publish all VMs that you need access to. You could limit this to one VM and use that as a jump host, which is not joined to a/the domain that you’re hosting.
- Use creative usernames on the published VM that don’t resemble “usual” user names that can be found on the box.
- Limit IPs from which you can connect via the published ports to the boxes – that’s more advanced configuration on the endpoints available on the VMs (Network Security Group config).
Something more complex:
- implement Multi-Factor authentication (Microsoft’s MFA Server can do that)
- don’t publish RDP/SSH at all – and access your VMs via ExpressRoute/VPN or other “from internal network” connectivity solutions or
- enable remote access ports for public use only when you need them.
- rotate the username+password combinations regularly and keep both username and password complex.
A good username?
Let’s spend a minute on the discussion of what a “good” username may be. You’d be surprised what automated attacks try as usernames to test well-knows passwords on. The list of tried usernames goes far beyond “Administrator” or simple translations like “Administrador” or “Administrateur” – there’s a whole list of names that we’ve found used when attacking VMs and probing for credentials.
You can easily generate such a list yourself: create a VM, expose the VM over the standard TCP 3389 RDP port and audit the logon events on the machine. Later, export the logon events, EventID 4625 is a good starting point, into a consolidated list of user names and the number of tries. Or for some more reporting– use the Azure Security Center to export the list over a fair estate of your machines. This precludes that you have VM Extensions installed on the VMs and Azure Security Center collects the data properly.
Among the usernames we’ve found on our honeypot VMs (real world examples):
- Console
- CRMADMIN
- SCANNER
- SPADMIN
- RECEPTION
- USER
- TESTUSER
- DELL
- FRONTDESK
- DEMO
- XEROX
- RICOH
But also – some “normal” user names, such as:
- Martin
- John
- Peter
- ALEX
- LISA
- Kevin
Before you walk away…
How can you protect from this? If you still want to use your common usernames, try to append or preface additional information, such as the year and month when you created the VM or the user name, such as:
- FlorianAdmin1804
- RDPRoot201804
- LorenzRookie2018
If you can, try to avoid the name “Admin” or “root” altogether in the administrative user’s name entirely. And don’t forget, using complex password is still required. Manage your keys to your kingdom with something like LastPass. Microsoft published an eBook on Password Guidance, even the book has been written back in 2014 it’s still an interesting read.
