Your SysAdmin/Super User/Root User has a lot of access to your critical systems – legitimately. It’s a job that comes with a great deal of trust, but what if one went rogue? It’s a nightmare scenario. How would you know it was happening? How could you recover from it?
Unfortunately, there are many ways a rogue SysAdmin may manipulate their privilege online. One such example involves adding Privileged Accounts to systems. Such new additions are typically given innocuous names that are easily mistaken for legitimate functions: such as ‘back up’.
Only by careful examination can someone tell if these accounts are bogus, and means looking for interactive login rights. Moreover, to identify these details, the person looking needs to be a capable SysAdmin to start with.
A more complex attack will see API keys used to gain access to applications, such as a script that behaves like a recognised client part of an application. As an attack type, creating backdoor access is very difficult to detect. A typical example is the use of extra ports on firewalls, because it is so easy to get locked out whilst defining rules. Deleting log files is another classic cause for concern. Was this done to ‘save the day’ because the system was out of disk space, or does it hide a more nefarious activity?
Using other people’s accounts can also be a sign, particularly while they are away. The SysAdmin changes the password, then the rightful user just assumes they forgot their password or missed a mandatory refresh.
And if the online attacks are difficult to trace, then the offline versions take this to a whole new level. An offline attack refers to breaking in to a copy of an online system. Since the SysAdmin is responsible for backups, they have plenty to choose from. Though the passwords for the system and applications may well be not known to the SysAdmin, they can use a copy of a virtual machine in a separate instance (at home or their corner of the cloud). They can boot the system into single user mode, and then change any password they wish.
A stolen virtual machine can be subjected to many brute force hacks. The system itself may complain, generating warning syslogs, but with nowhere for the warnings to go, your organisation is not aware of the attacks.
Imagine what would be available to the attacker if the virtual machine they copied was an Active Directory domain controller. Senior Staff accounts would have access to sensitive emails which would be accessed in a seemingly legitimate manner.
Mitigate The Risk
It’s essential your organisation takes stock of the data that is really sensitive. The next stage is to work out who you can trust with administrative access to these. You’ll need to understand here however that a zero-trust policy, whilst possible, is expensive and slow to operate.
From the examples we’ve given, you can see that most of the problem relates to Privileged Credentials as those that have them can make copies of critical systems. It’s still possible to make copies without credentials, but physical access is required, and the systems in question would need to be taken offline so that disks could be copied.
When a SysAdmin goes rogue, you have to assume that they know every password of every person and every account, and that they have a copy of your Active Directory Domain Controller. Consider separating people from the passwords. If users do not know the passwords in the first place they can’t share them, and they can’t ‘borrow’ them.
If you suspect an internal (or external) attack, every account needs its password changed. Deal with devices on an infrastructure-first basis; if you don’t fix that level the rogue can continue with the same attack path. With this in mind, you should also consider access to Master Encryption Keys (MEK) – this involves a backup and restore of the previous master to a fresh install (thus regenerating on a new MEK). It’s also increasingly good practice to get the MEK away from any SysAdmins too.
Staff knowing that all system actions are recorded is probably the best deterrent you can get. If you can prove who has access to what, and in which role, you can be sure of when they accessed the system and what they did. Overall, security is improved, and you get a better night’s sleep.