Ransomware attacks and data breaches are now occurring daily. Ransomware is no longer a tech topic that only techies understand. Data breaches and ransomware attacks have been covered pretty extensively in main stream media. There was even a deep dive into Ransomware on the Jon Oliver show:
Areas of Concern That Demand Your Attention
One interesting resource for learning how best to protect yourself against Ransomware attacks is from the Ransomware Gangs themselves, check out the advice a company called CWT was provided by a Ransomware Gang after paying their ransom. Note these tips specifically:
- Turn off local passwords
- Update passwords every month
- Force end of administrators sessions
Turning off local passwords is easy in theory but it is something which may cause some blowback. Make sure your field techs are able to continue operating as normal. You might be surprised how they have been doing some parts of their jobs. On the plus side, disabling local passwords will highlight this to you and let you correct the workflow and bad practices. You may even have some apps setup to use local accounts which is an even scarier prospect. This corrective action to turn off local passwords may cause an operational pinch but is something CyberArk can help you enforce.
Updating passwords every month may be too much to swallow for your regular users. I’m not sure this is realistic at least not for all organizations and industries. Widespread use of MFA where possible is likely more digestible for end users or perhaps the possibility of even ditching passwords entirely.
Your Domain Admin accounts and accounts with elevated rights are key to your security or lack there of. It is a good idea to use CyberArk or a similar product rotate complex passwords for local admin accounts, domain admin accounts, accounts with elevated rights and even service accounts where possible. Microsoft LAPS is a good solution for rotating passwords or local admin accounts.
For service accounts, at a minimum you should definitely ensure these accounts have only the permissions they require. These should be as least privileged as possible.
In my experience applications that require service accounts don’t work too well when you rotate passwords, so perhaps rotating passwords but less frequently as well as using strong passwords and containing the accounts as much as possible could be best.
You really should limit the number of Domain Admin accounts in your organization to only a handful and let them get accessed only through CyberArk, if possible. For domain admins and accounts with elevated rights often used by Admins, Architects, Engineers etc. you should have passwords that rotate every few hours. You may opt to rotate your Domain Admin passwords every 2 hours or 1 hour and possibly have the other accounts rotated a little less frequently. This is where some of the pain points of using a product like CyberArk comes into play and this is how I reduced our pain also helped us follow the remaining tip: Force end of administrators sessions.
The Pain of CyberArk
Your IT workers work long hours. Their admin account passwords are likely to change while they are working. Even if it doesn’t change while they are working, people pick up some bad habits like remoting into a bunch of machines at once and never logging out of them. They might lock their machine and walk away for hours or work on a single machine they RDP’d too while keeping others logged in but not actively working on them. When the end of the day comes they likely won’t bother logging off of each machine before they go on their merry way. This is risky behavior and when the password changes, those connections on the many machines they RDP onto can result in a lockout. Even if they hit the x to close their RDP session, this does not log them off, it only disconnects them and even in a disconnected state the account attempts to authenticate causing lockouts AND even in a disconnected state the account is left vulnerable to a hacker using it for their own nefarious purposes.
Forget bad habits of just leaving machines logged in and idle or left in a disconnected state, there are also plenty of people who get a prompt telling them their session is going to be logged out so they just move the mouse to keep the session alive. This is also bad behavior. You want to make sure these elevated admin accounts are only logged in on machines when they are actually being used. Leaving them on the machine when idle invites a hacker to leverage the account.
Changing passwords also becomes a pain in the arse for your IT workers. When their accounts are logged in and working suddenly they will find they can’t browse out to file shares, applications stop working properly and they pretty much can’t do their jobs anymore. They need their account unlocked so they can work properly again. What caused the lockout though? Did it occur when they were trying to RDP into a machine and used the wrong password a few times? If so, once the lock lifts they can get to their shares and apps again without issue and can just RDP to the machine successfully by using the updated password. Once people become accustomed to rotating passwords a lockout for this reason isn’t too likely but what is more likely to keep occurring is people using an old password for something like an RDP session or to run an application and when the password is no longer valid the session or app attempts to re-authenticate it multiple times using the wrong cached credentials, causing the lockout. This can be a pain to figure out. If you have something like NETWRIX, you are lucky. If you don’t, you may have to rely on the Microsoft ADLockout tool to find which Domain Controller the lockout occurred on, go through the event logs and find the IP address for the machine or service that generated the failed authentication attempts.
I found a really great way to eliminate the pain of account lockouts for admins was to use ControlUp Automate to force a logoff of any session on our management servers once they go idle for an hour. The simple Logoff session script is available in the ControlUp Script Library. You just have to search for it and select install.
When you have the script installed, within the Security Policy menu ensure the script is allowed to be run by the ControlUp Monitor and it is a good idea to allow it for Automation Admins too, then create a new Advanced Trigger based on Sessions with the state filter set to Idle Time is greater than or equal to 60 minutes. You may want to set it to 2 hours or perhaps start it at 2 hours and if people don’t complain then reduce it down.
Set the Scope to your folder with your Management Servers. Definitely DO NOT set it to your Citrix VDAs or Horizon desktops!
And simply set the Follow-up Action to run the Logoff session script.
What I like about this approach is it will take care of all idle sessions whether they are logged in or in a disconnected state. Unlike with Group Policy, this simple logoff session script will not alert the user that the session will be logged off. You might think not warning them is not a very good user experience but my feeling is this is the best approach. If you warn them that they will be logged off, they will keep the session alive whether they intend to actually use the session or not. This helps reduce the chances of CyberArk password rotation locks too and when you do have a lock, you can be sure it is not a disconnected session on any of the machines covered by the scope of your trigger.
To wrap up this article, I was inspired to setup ControlUp to force the logoffs after an incident in which we had a brief network outage and all of my open RDP sessions dropped. I couldn’t remember everywhere I had logged in so the lockouts when the password changed was inevitable and painful to deal with. It was a god send to have in place going forward. The security benefits was a nice added bonus.
For more really great security tips from an actual security expert, check out Patrick Coble’s excellent work. Also, listen to the 5BytesPodcast every week as I feature a lot of security related news.
Photo by Bermix Studio on Unsplash
