April 16 2023 Sunday
Ransomware Prevention Part 11 - Let’s talk about Service Accounts
Part 11 - Let's talk about Service Accounts
See here for the entire series of posts, if you are just stumbling onto these posts.
As I said all the way back in part one, these post are supposed to be helpful in giving you meaningful useful advice to prevent ransomware.
Service Accounts. They exist everywhere. Most have common (and scary) attributes such as passwords that haven't changed in a few years, if not a decade or more. Service Account passwords are rarely, if ever, changed because of of the havoc the can be created when they are. And there are many organizations that have no earthly idea where or how many times these accounts are used. Finally many are local admins on server, or (queue scary music) are domain admin level accounts.
Given any of the above attributes, let alone several of those attributes being present in a single service account, it should come as no surprised that they represent an adversary hitting a gold mine if the can compromise one of them. So how does one protect these God level accounts? Read on.....
In all my years of doing this, I have yet to find an actual reason to have any service account listed as a domain admin. Zero. Nada. Ziltch. If you have a service account in Domain Admins you are simply doing your job wrong.
Managed Service Accounts
The preferred way to create, manage and use service accounts is utilize Managed Service Accounts (MSA). These MSA accounts come in two distinct flavors, stand-alone MSA accounts (sMSA aka MSA), and group MSA accounts (gMSA) and were first introduced in Windows 2008 R2 with gMSA accounts being added with 2012. The only significant difference between the two types is that a sMSA account can only ever be used on a named, single server. it cannot be "assigned for use" on two servers at the same time (note, I said servers, not services!). gMSA accounts on the other hand can get used across several names servers, so a shared account if you will.
For security reasons, sMSA accounts should always be your default choice. gMSA accounts have specific use cases, the one I see the most is using a single gMSA account on several ADFS servers in an ADFS farm.
MSA accounts in general address many, if not all, of the issues with traditional service accounts, namely:
"Darren, this sounds perfect!" Well, yes and no.
That being said, MSA accounts can and should be used anywhere and everywhere you can. For management of MSA accounts, ManageEngine have a helpful free tool available here: https://www.manageengine.com/products/free-windows-active-directory-tools/free-active-directory-service-account-management-reporting-tool.html. Microsoft has detailed MSA documentation and a quick Google will show you how to set them up.
Traditional Service Accounts
As mentioned above, you may locate services that simply won't work with MSA accounts. If you have those then you're left with the traditional service account way, which is simply a user account. These accounts, while nowhere near as secure as MSA accounts are, can have increased security.
Traditional service accounts should be prevented from interactive logins. While MSA accounts have this prevention enabled by default, traditional service accounts need to be set up for this via a GPO
Traditional service accounts need long, complex passwords. I'd look at a minimum of 32 characters.
See here for the entire series of posts, if you are just stumbling onto these posts.
As I said all the way back in part one, these post are supposed to be helpful in giving you meaningful useful advice to prevent ransomware.
Service Accounts. They exist everywhere. Most have common (and scary) attributes such as passwords that haven't changed in a few years, if not a decade or more. Service Account passwords are rarely, if ever, changed because of of the havoc the can be created when they are. And there are many organizations that have no earthly idea where or how many times these accounts are used. Finally many are local admins on server, or (queue scary music) are domain admin level accounts.
Service Account passwords are rarely, if ever, changed
Given any of the above attributes, let alone several of those attributes being present in a single service account, it should come as no surprised that they represent an adversary hitting a gold mine if the can compromise one of them. So how does one protect these God level accounts? Read on.....
In all my years of doing this, I have yet to find an actual reason to have any service account listed as a domain admin. Zero. Nada. Ziltch. If you have a service account in Domain Admins you are simply doing your job wrong.
Service Accounts should never, ever be a Domain Admin
Managed Service Accounts
The preferred way to create, manage and use service accounts is utilize Managed Service Accounts (MSA). These MSA accounts come in two distinct flavors, stand-alone MSA accounts (sMSA aka MSA), and group MSA accounts (gMSA) and were first introduced in Windows 2008 R2 with gMSA accounts being added with 2012. The only significant difference between the two types is that a sMSA account can only ever be used on a named, single server. it cannot be "assigned for use" on two servers at the same time (note, I said servers, not services!). gMSA accounts on the other hand can get used across several names servers, so a shared account if you will.
For security reasons, sMSA accounts should always be your default choice. gMSA accounts have specific use cases, the one I see the most is using a single gMSA account on several ADFS servers in an ADFS farm.
MSA accounts in general address many, if not all, of the issues with traditional service accounts, namely:
- Automatic changing of passwords by AD ever 30 days or whatever your AD machine password expiration is. NO manual intervention is needed.
- Password complexity is high, 240 bytes make brute forcing difficult
- MSA accounts have to be specifically assigned to a server before a server can use it.
- MSA accounts are prevented from interactive user logins.
"Darren, this sounds perfect!" Well, yes and no.
- Not every service you have running can use MSA accounts. It's gotten better over the years, but it's still trial and error.
- They are an absolute pain in the backside to create and manage the first time you try.
- You still need to reduce the MSA account to least privileged access.
That being said, MSA accounts can and should be used anywhere and everywhere you can. For management of MSA accounts, ManageEngine have a helpful free tool available here: https://www.manageengine.com/products/free-windows-active-directory-tools/free-active-directory-service-account-management-reporting-tool.html. Microsoft has detailed MSA documentation and a quick Google will show you how to set them up.
Traditional Service Accounts
As mentioned above, you may locate services that simply won't work with MSA accounts. If you have those then you're left with the traditional service account way, which is simply a user account. These accounts, while nowhere near as secure as MSA accounts are, can have increased security.
Traditional service accounts should be prevented from interactive logins. While MSA accounts have this prevention enabled by default, traditional service accounts need to be set up for this via a GPO
Traditional service accounts need long, complex passwords. I'd look at a minimum of 32 characters.
