Mind the Gap: How to Secure Active Directory Service Accounts

Welcome everyone. I am Allison Parrott and I am thrilled to welcome you to today’s event titled “Mind the Gap: How to Secure Active Directory Service Accounts” and sponsored by Semperis. Before we begin, I want to cover a few housekeeping details. If you have any questions throughout the presentation, please make sure to type those into the Q&A box and we will make sure to get those answered for you. Semperis has provided some resources which correspond with today’s event, so please take a moment to check those out. They are located to the right of your audience console. Today’s webcast is also being recorded, so keep an eye out for a link in your email to rewatch the presentation or share with a colleague. And now I am thrilled to announce our speaker for today. We have the pleasure of hearing from a member of the Semperis team. With us today we have Sean Dube, Principal Technologist, Americas at Semperis. So we are in for a great event. And with that, I will pass the time over to Sean to get us started. Thank you, Alison and thanks everybody for attending today and taking time out of your day, either now or when you see it for a later review, to hear about service accounts and some of the ins and outs of service accounts. What I’m planning to talk about today is first, what are Active Directory Service Accounts? And I should note at the beginning, the scope of this is that I’m going to talk about Active Directory Service Accounts. I’m not talking about Entra ID Service Accounts or Service Principles, rather we’re just focusing on on-prem Active Directory. The situation about the attacks on service accounts that are going on and why they’re attacked. How Microsoft has evolved service accounts over time and the pros and cons of each of those. And then finally at the end, recommendations for you. What takeaways can you get from this to get a handle on your service accounts? For myself, I’d like to say—and I apologize if you’ve heard this before—I like to say I’ve been doing Microsoft Identity as long as Microsoft has been doing identity. I was actually involved with Microsoft stuff before Windows NT Server, something called LAN Manager. That is long gone into the annals of history. But I spent a while with Texas Instruments where I helped design and deploy their Windows NT network around the world. Then I went to Intel where I was one of the architects of Intel’s Active Directory and helped deploy that around the world and ran it for ten years. I also, back in the day, wrote a book about Windows Server 2000 and Active Directory. And in that book, I actually drew an analogy of how Kerberos works to going to a company party at a hotel. I was quite proud of that analogy at the time and it still holds up fairly well. Then I detoured and went off to be a technology journalist. I’d been writing since 1997, but I spent five years as a full time technology journalist, which was terrific. And I started writing about the rise of cloud identity, which was quite a new thing. And if you remember back to that time, if you were around at that time in the business, we were all remarking about who in their right mind would outsource their identity to some random provider on some other set of computer hardware entirely. And yet here we are. And most organizations are in a hybrid environment where they have a cloud identity provider like Entra ID. But guess what, 25 years later, Active Directory is still here and it’s not going anywhere. Anyway, long story short, after working some time as a consultant, I then came back around full circle to Active Directory with Semperis. And you can say “SEMperis” or “SemPERis”…either is fine because we really focus on identity security and the attacks on the identity system that are so prevalent everywhere with every attack. I was an MVP for15 years for identity and I have a podcast. This is my shameless plug for my podcast called the Hybrid Identity Protection Podcast and it focuses on, guess what? Identity security. And I did a bunch of interviews a couple of weeks ago at our annual conference, the HIP conference—the Hybrid Identity Protection Conference in Charleston, South Carolina. And I got to interview a number of really interesting people, significantly, one of which was Doctor Mary Aiken. She is a cyber psychologist that deals on the psychology of cyber attacks and how attackers think. And she is actually the model for the TV series NCIS Cyber, the lead character in there was designed after her. So shameless plug for my podcast. But let’s talk about service accounts. So to begin with, why do we have service accounts? Who cares? What’s the whole point behind a service account? The way I look at it is basically people can’t be standing around using their credentials and their privileges every time you want to run an application. I mean, I’m an identity guy and when you’re a hammer, everything’s a nail. So I think identity is the most important thing around, but the reality is applications are the most important thing around. That’s what businesses run on. And to run applications, it’s just not practical to type in credentials every time an application needs to run. Number two, it’s also impractical to use people’s credentials for inter-application communications, for one application to talk to another. It’s just not remotely practical at all on how to do that. So that’s what service accounts are for. The word nonhuman identities—NHI—is the buzzword of the moment, and I’m frankly not a fan of NHIs, it’s yet another three-letter acronym to throw around. But they are accounts that are not logged on interactively (used by humans) to facilitate machine to machine communications with AD or to have applications run stuff and get things done, get business done—and done with the same privileges as the service account. So in a nutshell, that’s what it’s all about. And there are lots of service accounts, lots and lots of service accounts. Everybody has tons of service accounts. But before I dive into that a little more, a little more 101 on service accounts and these aspects of it. So to talk about service accounts in Active Directory, we also have to talk about service principal names or SPNs. And I liken SPNs to DNS for Active Directory integrated applications. Now in DNS, what does it do? It translates host names that we’re familiar with and humans can remember and it translates them to IP addresses, which we don’t wanna remember and they keep changing anyway. So DNS does takes care of all of that. Just ask AWS a couple weeks ago. There’s a haiku about DNS and many of you on this are probably familiar with it. It goes along the line of: It isn’t DNS | It can’t be DNS | It was DNS. That’s was AWS in nutshell. But the point is, as I digress, the point is DNS translates host names to IP addresses. Service principal names create a unique string that maps a service to a service account. So if somebody wants to find a SQL Server service for example, and this is an application wants to use SQL Server service and it’s not mapped, you don’t have to type in a specific computer name to find the service. What you do is you query for the SPN of for example, MS SQL And it’s a set SPN command and it will tell you where the server is and the service account that is using it. So when you have this and this is anybody that is logged on to an Active Directory network can do a setspn -Q to see a list of all of the SPNs on network. Now that’s a problem and that’s gonna be a problem as I’m going to describe in a second. But remember when Active Directory was designed, the corporate network was a secure location. So if you are on the corporate network, Active Directory is there to help you. Sure, I’ll tell you a list of all the applications that are available so that you can get to whatever you need to do. So you don’t need to know the service account and you don’t need to know the computer either, you just need to know the SPN. So service accounts: hard to secure because they’re low visibility, they have static passwords, they have excessive privileges and of course they’re very important to the business but I’ll get much more into it here. So with the basics of service accounts, let’s look at them. Let’s look at the security risks around service accounts. So in 2023, CrowdStrike made this significant finding, which was they saw a 583 percent increase in Kerberoasting. So Kerberoasting—besides having an attack with a really cool name, I’ll dive into Kerberoasting more in just a second—but that is one of the most popular attacks to compromise Active Directory and it uses and it leverages service accounts to do that attack. There has also been a great increase in what is called the DCSync attack or a DCSync abuse. This is something that was actually done by SolarWinds. And essentially, if you get DC sync attack, the attacker can gain what’s called domain replication rights. This is typically held by domain admins or enterprise admins. If a threat actor can get in, get privileged account in the environment and then gain these rights, what they can simply do is to say, give me synchronize all the accounts in domain admins, which the threat actor can then compromise or even exfiltrate the entire Active Directory database, which they can then use tools like Mimikatz or Power Sploit to gain further control of the environment. This is something that happened to SolarWinds. Password spray attacks. A password spray attack is an attack where the common password is guessed. You have there’s a well known list of the first hundred or the first thousand most common password that everybody uses. And if a service account has a common password, a password spray attack can easily get it. And because by the nature of the beast, service accounts can’t have multi factor authentication on them, they can be easily compromised by a password spray attack. An example for this was a service account causing a breach is the notorious Change Healthcare breach last year, which cost several billion dollars eventually it was determined to be. Initial access was gotten into the network by a Citrix remote access portal and that portal didn’t have MFA on it. And they used valid credentials from a service account, again, no MFA. And with that service account, they’re able to spread through the network because it was a privileged account and it was an unmonitored account. And that was the rest that happened was not pretty and we all understand the result of what had happened with that. So I talked about Kerberoasting, and so I thought I would give you a quick overview of what a Kerberoast is. So a Kerberoast is pretty simple its execution remarkably when you think about the execution of it and the way AD was designed. The first thing that happens is a threat actor that gets in the environment and one of my colleagues that had extensive experience with Microsoft’s Incident Response Team, DART, says nowadays you just pretty much assume initial access. They could have bought credentials off the dark web, they could have phished credentials, they could have social engineered the help desk, just assume the threat actor is able to log in. So at that point, they’re on the network, Active Directory designed for a trusted network goes, hey. Okay. Hi. How are doing? What can I, you know, what can I do for you? The threat actor says, okay. Let’s look for interesting accounts that have service principal names and privileges so they can you can query the membership of any group in Active Directory. So let’s query the membership of the default privileged groups, account operators, backup operators, domain admins, enterprise admins. Okay, we have those users. Now let’s do an spn -Q and find all the interesting SPNs out there and let’s correlate the two and what we can find are service accounts that have privileges in. So with that knowledge of service accounts with privileges, the next step is to do which is called a TGS request in Kerberos. And so to make this work in Kerberos, if you want to access a resource, a SQL Server or a file server, you basically send a TGS request to a domain controller and the domain controller will return this ticket. And the key thing about a TGS ticket is that it is encrypted with the password hash of the service account associated with that service. And that comes back to you the client, okay? So the threat actor now has data, he has the password hash of the service account. Well, guess what? The default hashing algorithm in Active Directory is RC4. RC4 if you haven’t upgraded it to AES, many, many organizations have not done it because you have to do it carefully and it just doesn’t get done. So you have this RC4 hash that has been cracked since about 2001 when it was first cracked. So you take this data and you take it to offline and you crack it with a tool for example called Hashcat. And in this particular example, this service account that had the password of “this is cool” was cracked in two seconds. And they now have the password hash of the service account which means they have all they can authenticate to Active Directory as the service account. If the service account is privileged, they can then do a DC sync attack and say, give me the credentials, give me the password hash and all the attributes for an account called the KRBTGT. And that allows you to create just about any TGT you want to and it’s game over. They own the network. And this can be done a former colleague did this in as few as ten minutes to gain control of Active Directory with a Kerberos. So I mentioned the KRBTGT account. So KRBTGT comes by default in an Active Directory domain and what it is, it basically is designed to sign and encrypt the ticket granting ticket, the TGT, per view account and the domain. When you authenticate to Active Directory successfully, what you get back from Active Directory is a TGT—a ticket granting ticket—that you then present anytime you need to access a resource. And it’s encrypted by the KRBTGT account. If you gain control of the KRBTGT account, it means you can create your own TGT with any privileges in it you want. So as you can see, that’s why it’s called the Golden Ticket because you can be anybody in the forest. You can create any TGT in the forest to own it. It is recommended and don’t go off and change the password willy nilly because you’ll put yourself in a world of hurt. It is recommended that you change it every six months, something like that, but you have to do it very carefully. And one of our principal incident response people at Semperis has a script. His name is Jorge de Almeida Pinto and the blog is called Jorge’s Quest for Knowledge—easy to find. And he has a KRBTGT reset script. So it is recommended that you do reset the KRBTGT on a regular if infrequent basis. And this is one of the places that’s a resource that pretty much everybody recommends to use is Jorge’s script. As I said, the cons are that it makes you vulnerable to a Golden Ticket attack. So what is the evolution of service accounts of Active Directory over time? It’s been quite a while and what I’m gonna do is go from the oldest to the newest. So virtual accounts, something called LocalSystem NTAUTHORITY, user account-based service accounts (by far the most common), Standalone Managed Service Accounts, Group Managed Service Accounts, and the new one, Delegated Managed Service Accounts. And you can see from that link below, that’s the Microsoft documentation on all of the service accounts. You wanna dive more deeply into service accounts, that’s where you can go. So let’s start with the simplest one, virtual accounts. So virtual accounts are entirely local to the Windows machine, be it server or be it client, and it’s managed, but it’s like I said, it’s entirely local and it makes it easier for service administration. It’s automatically managed, the service name is established, you can see it on your own computer, all you need to do is use the query below, the [SC] Query, to see a list of all the services running on your computer. And if you find any that say NT service, that’s a virtual local account. The classic account name for that and you can see it listed here is MS SQL Server. If you have a SQL Server, you’re going to see it as a local account called MS SQL Server. The system account—again, this is NT Authority\SYSTEM—this is used by the operating system for running high level privileged system services. Security software uses it also. Semperis software has agents that run in the system context, which allows you to do things at a privileged level that you couldn’t otherwise access. User based service accounts, as I said, they are by far the most common type. I’ve talked to many organizations that have large organizations that have service accounts literally in the tens of thousands of service accounts. Just an unmanageable, huge amount of accounts. What is the difference between a regular account and a service account? Nothing. Essentially, historically it means somebody checked the checkbox that says the password never expires, they put, historically, a simple password on it or they put the password on a post it note on the AD admin’s wall, and there it sits for the next ten years because everybody’s afraid to change it. They’re everywhere. What are the requirements for this? Pretty simple, none. What are the pros of it? Well, historically this was the first service accounts that are used in the domain. They’re simple to create, but the cons are many. It has a static password. And once that password is set and once an application uses it, it’s difficult to change without impacting your applications. It’s usually a very simple or very weak password because historically, if this was created ten years ago or fifteen years ago, it wasn’t going to be that hard. And I like to say that, hey, either everybody knows the password because everybody has had to access it over the years and the people will move around the company or nobody knows the password because whoever created it left the company or retired or they forgot it themselves. But as I’ve shown with Kerberoasting, it’s easily cracked once it’s obtained. And as I have also shown you, it’s an easy and attractive path to get the domain admins via Kerberoasting. And as I said, if you change if you go in and say, oh, this is I need more secure. I need to secure this user account and running a line of business application or some important application. And you then create some gnarly password and then you change the password in Active Directory. About ten hours later, more or less, when the Kerberos ticket for that account expires, your application will crash. And people will be wondering why did my application crash? Nothing changed. Well, six or seven or eight hours ago, someone changed the password to that service account. So you have to be very careful about how you change service accounts. So after getting beat up for quite a while on service accounts, Microsoft came up with Standalone Managed Service Accounts. They just called them MSAs at the time. They didn’t call them standalone MSAs. And actually I’m friends with the guy that was the PM for this back in the day. But the purpose was to get rid of the static password requirement, have the password generated by a domain controller, have the password rotated by a domain controller. And it got stored in the Unicode password attribute of this object, the sMSA Active Directory object, but it was locked down with access control list, so only the computer that it was intended for can read it. So this is a really this is a much better solution. The pros like I said, well the requirements, you had to have Windows Server 2008 R2 and also the forest functional level and the domain functional level. Pretty much everybody has that right now. If you don’t have those, you really need to get going on a lot of computer security because a lot has happened since that day. The pro is that it can’t be used for interactive log on. That’s a great thing. The password is not stored locally, which means if you have Mimikatz, the threat actor has Mimikatz, they can’t extract it from LSASS out of memory to get the password. It is a 240 character password which is great and it’s rotated every 30 days. So you can also, when we talk about password cracking, if you could get that password, the amount of time it would take you, the amount of time it would take a threat actor to crack a 240 character password is probably greater than 30 days. And unless you’re a nation state actor, the opportunity is too much trouble for a cybercrime. It’s too much trouble, let’s go on to next victim. So that’s great. The cons are really two. Number one, it’s bound to a single computer. So if you have a multi-tier app or you have a clustered application, you can’t use standalone MSAs because they have to be bound to a single computer. And the other—and this is as significant as anything else—it had very limited third party support, which means you could have an application but they didn’t support MSAs, they wouldn’t work with an MSA. And so as a result, we have pretty limited adoption of standalone MSAs. The next iteration that Microsoft did was group managed service accounts, gMSAs, and the whole point behind a gMSA is that it’s usable across multiple servers. And then the way it derives the password is also different because it has to be the password has to be available across multiple servers. It derives the password from the KDS root key, stores it in Active Directory, and again it’s accessible only by authorized hosts and these hosts are in the particular security group for that individual gMSA. To do this, you had to have Windows Server 2012 Forest Functional Level and Domain Functional Level. Pros obviously is that the gMSA can be used across multiple servers, a web farm or a load balancing cluster being the great examples for that. Great degree of scalability to it. The cons are that it’s limited to a single forest. I don’t see that as a huge problem. All gMSA passwords are derived from the forest-wide KDS root key. But if you gain the root key, you can get the password for the gMSA. And there are many ways as we sort of show have already shown, maybe you don’t attack the gMSA, you go to some other service account that has a weak password, you Kerberoast it, and then hey, guess what, you can get it anyway. It has limited delegation so that if you grant the right to manage gMSAs, they grant you the right to manage all gMSAs. So from an operational viewpoint, that’s something you have to be very careful to keep locked down. It still doesn’t have native Kerberoasting mitigation. It’s just a long password. Admittedly, it’s a very long password. This is the same kind of length and complexity as a standalone MSA. It’s a very long password and so it’s the likelihood of Kerberoasting it has gone down is much lower, but it’s still there. And guess what, at the bottom still the same problem and this is more of a business problem and a marketing problem than anything else is that it had limited application support. Applications just simply didn’t pick it up and they don’t work with it very, very well. So this also found a limited adoption to this day. Managed service accounts and group managed service accounts are still not widely adopted. Now what we have brand shiny new is the dMSA—the delegated managed service account. This came out in Windows Server 2025, and the purpose behind the delegated managed service account is to reduce privilege exposure by binding the service identity to a specific device, a specific secure machine account. Now that gives you a number of security advantages, but it also has a couple of disadvantages. First off, the requirements—and this always seems to be the case with Active Directory. Hey, we got this great new feature, guess what? You’ve got to upgrade all your domain controllers. So the requirement is that you have Windows Server 2025 Forest and Domain functional levels. Now you don’t have to upgrade all of your member servers, but you do have to upgrade all of your domain controllers to Windows Server 2025. My guess is that most of the people on this call have not upgraded all of their domain controllers to Windows Server 2025 yet. So that’s one thing. And then for the member servers that are going to be using delegated managed service accounts, they also have to be running Windows Server 2025. And also very importantly, a patch for CVE-2025-53779, known as BadSuccessor, which is a security vulnerability in the delegated managed service accounts. If you wanna know what that is, you can look up bad successor and you can get lots of information about it, but it has been largely remediated and it should be rolled out, you’ll get it as part of regular service updates. So the pros of a delegated managed service account is that it can replace a standard service account. So this is the pathway to take your standard user service account and make it more secure. It has fully managed and randomized keys, it has Kerberoasting mitigation. Finally, Kerberoasting is mitigated because for this account, password based authentication is disabled. That means there is no TGS ticket to be harvested. It’s linked to a single machine’s identity. Again, it’s designed to replace the standard prevalent service account that’s out there right now. The cons are you can’t use it in a cluster. It’s used for a single machine. And then as you’ve seen, there’s a big upgrade required to make this work. And finally, it’s also not supported for scheduled tasks. So what we have is a hodgepodge of types of service accounts, the things that they can do and the things that they can’t do. Well, so I used—this is the only time you’re gonna hear it in this presentation—I used AI to create a mapping of these accounts and what their pros and what their cons are. And it looks like, and I’m just now seeing this unfortunately, is they are not showing in color as displayed. That’s disappointing. So what I’m going to have to do is I’m gonna have to tell you what we’re looking at. And really the takeaway for this particular table is it trends. And from the left to the right we have legacy service accounts up to dMSAs, and of course the pain points that they addressed. And the general trend is from very red towards very green, where all of these rows, Multi Service Support, Password Management, Delegation—everything except for Multi Service Support—is green for a dMSA. Again, as we had said, it does not support multiple servers that one particular entry is incorrect, but the rest of it is accurate and it shows the different things that they can do. And I’ll make sure that you get the PDF that does have this marked in color. The next slide is a slide of the threats associated with it. And of course, that one doesn’t show either unfortunately. But what I’ll try to describe this to you as best as possible. Under the legacy service accounts, this is pretty much all red. And you can see Kerberoasting attack is high. And let’s maybe just walk Kerberoasting across here. So we can see legacy service accounts are easily Kerberoasted. SMSAs and gMSAs have long and random passwords, but they are still ticket based and they could still be theoretically cracked. Maybe if you had a sufficiently determined adversary, they could crack it. Pass-the-hash and it is a common attack and it is a regular user account is very vulnerable to pass-the-hash. But from SMSA on, they’re not vulnerable because the password is never exposed to administrators. So those are things trending in the right direction. So in general, what happens all the way across is things go from red to green, I would note with the exception of the Golden Ticket. So the Golden Ticket attack, the problem is it’s still Active Directory. It still depends on KRBTGT to encrypt TGT. So you don’t really have a choice on that. And it’s all about protecting KRBTGT as best as possible and in attempting to monitor for a compromised or forged TGTs that have perhaps abnormal lifetimes. So with all this about service account, how do you identify service accounts? How do you figure out what’s out there? So the short answer is you can’t do it just one way. You have to do it a bunch of different ways and then do a lot of correlation to see what you come up with. Semperis with our DSP offering, we have a service account module to help discover service accounts, but it’s complicated. So the first you can do is the simplest is just query Active Directory and find out what all accounts that have passwords never expire. Now of course, you’re probably going to find a number of regular users that have passwords that don’t expire, that really are interactive users. Appalling though it is, I know what the world is like in Active Directory after 25 years. But some of those, hopefully most of those will actually be service accounts. I know you try to have naming conventions, but there’s and that’s what I have on the bottom here, accounts with specific descriptions. Maybe you have—in the description it says service or maybe the account name starts with SVC underscore, but of course, this is just entirely by manual human unless you’ve built it into your provisioning tool. So it’s less than 100 percent sure that that’s gonna be all of them. You don’t know that that’s gonna be all of them. A really great way to get a lot of them, if not most of them, is to look for the accounts with SPNs, with service principal names as I described because that’s the nature of what service accounts were originally designed for. It was for SPNs. Maybe they’re in a specific OU, maybe you or your predecessors were highly organized and they created a process that was followed by your account operators and they put them all in a particular OU. So you could use Get AD User and look for…maybe it’s an OU called Service Accounts. Not real likely, but who knows, maybe you’re lucky that way. You could also look for accounts trusted for delegation because unless you have something really unusual, accounts trusted for delegation are used by service accounts. And there is the other one that I mentioned, accounts with specific naming conventions. So what you have is you have a collection of accounts and then you have to go through and figure out which ones really are service accounts and which aren’t and it’s tedious. And of course, it’s not like you don’t have a lot to do anyway, but from a security viewpoint, it has become essential to try to secure your service accounts. So given that, what are the recommendations? What are the steps that you take going forward to get a handle on your service accounts? Well, we sort of addressed the first one already, discovery. You can’t secure what you don’t know, what you don’t know is out there. And hundreds or thousands of accounts that have been created for this. As I said, run the discovery, look for what’s out there. Once you know that, look at your SPNs, look at your attack surface and reduce your attack surface. So that means if you have unnecessary SPNs, because let’s face it, after something’s in production for ten, fifteen, twenty years, there are going to be applications that were out there and then maybe have been end of life. You know, the application owner shut the server down and it’s not there anymore, but guess what? I will bet you a dollar the service account and the SPN is still out there. That’s low hanging fruit for a threat actor. So look for unnecessary SPNs that are tied to unnecessary service accounts. Look into dMSAs. I recognize Windows Server 2025 upgrade not insignificant to do, but the way to phrase it to the business people of your organization is, what you have is a very large and, since we’re talking about Active Directory, potentially an existential risk for the organization in the host of service accounts that are out there. You have a mitigation for it in delegated MSAs. To do that, you have to upgrade to Windows Server 2025. It’s not just because it’s the latest support, it’s not just because it’s got whatever bells and whistles are or you like it or the logo has changed or whatever. It is the pathway to being able to mitigate your service account problems. Run services under machine accounts wherever possible. Strengthen account security, so by the account security this is password based. If you know the passwords on a service account, update it. Update it to passwords that are difficult enough to crack that it’s not worth the trouble. It takes too long to crack it. That’s one of the simplest things that you can do with the proviso of course, that you have to work with the application owners when you change the password provided of course you even know what application the service account is being used for. Disable RC4 encryption in favor of AES 256—you can upgrade that. There are effects you need to be aware of. If you look in Microsoft documentation, you don’t just go in and change—hopefully, nobody just goes in and just changes things in Active Directory because it seemed like a good idea at the time—because bad things happen when you do that. But look into upgrading to AES 256 for your default encryption. And look at using the setting account is sensitive and cannot be delegated to privileged accounts. This will help limit lateral movement around privileged accounts if you have threat actors in the environment. Basic operational hardening, again, is what sort of what I call eat your vegetables recommendation. Oh, we’ve heard it before, you’re always telling us do these things. Well, guess what? It’s because these are the things that you need to do. I’d like to tell an anecdote. I heard a speech by Rachel Wilson, who is the director… one of these days, I’ll look it up exactly, but I’d say she’s the director of risk management for Morgan Stanley. And before she had that role, she was the director of offensive security at NSA, the outbound hackers. And her motto is in terms of cybercrime is, don’t be the slowest gazelle in the herd. In other words, if you make it difficult enough—and as my colleague said, assume initial access—but if you make the environment difficult enough that it takes the threat actor more time than they’re willing to spend to get to their goals, they’ll throw their hands up in the air and spend a few hundred dollars and go on to the next victim that they can more easily compromise, which means they get paid sooner. So eat your vegetables, never use domain admin creds for service accounts. By now that should be an obvious statement, that’s the express route to domain dominance. Apply least privileges—and this is part of the problem historically as this audience knows of service accounts is because everybody’s always in a hurry. Everybody always needs this done yesterday and you have a million things on your plate and it takes too long to figure out for application What is the least privileges that will cause it to run successfully. And often as not, you’ll just give up and over-privilege them because it makes it work. I actually had a story talking to the CISO that had just come into an organization. I won’t say what the organization is or even what it did. And to his horror, he found out that as part of onboarding, new users were added to the domain admins group because it just made everything work. But yeah, you’re not gonna do that. You’re gonna apply least privilege wherever possible to your service accounts And again, rotate the passwords regularly. Now, that can be a challenge because as I said, you have to find out what the application is being used for. And if it breaks it and you didn’t know what the old password is, then you’ve painted yourself into a corner. One of the nice things about Semperis’ Directory Services Protector is that we have all of that information in DSP and we can roll back any changes to Active Directory. So if you have a service account modernization program or a security program and you upgrade the password of a service account for an application that you think it is and you give it a long gnarly password and it’s great. And then it turns out there’s some other application someplace else that’s using that same service account and you just broke it and they need to get things back as quickly as possible. With DSP, all you have to do is check a checkbox and say undo and it will restore the previous account password. Not to forget governance. Governance or lack of governance is pretty much what got everyone into this problem to begin with and made it worse and worse and worse. So by that, what do I mean? It isn’t not necessarily the technology, it is the process, it is the policy. So you got to figure out these service accounts. Who owns the service account? Every service account should have an owner. This says must have an owner. That’s a great goal to get to, but it’s essential that somebody is responsible for it. Somebody that you can contact when you have to change a password or upgrade it. And that the owner is responsible for actions taken by the account. So if manager goes away, account validation triggers and a new manager is assigned so that there remains an owner for the account each time. If there isn’t a manager, don’t use the account. I know that’s easier said than done, but that’s a goal to work towards. And with that account being managed by somebody, let’s make them responsible for annual account verification and organizing the project, hopefully a minor project, the downtime to do a password reset or a password change. And again, in a perfect world, if they can’t do it, the account is disabled. Strong words, but it’s something to strive for. But the point is the reason that you have eighteen thousand service accounts in an organization is because they were created and there was no life cycle associated with them. And you could go through an account cleanup, a service account cleanup like we’re talking about here, but the problem is if you don’t put the governance in place, it’s just going to start all over again. So you need to do both at the same time. So in conclusion, I think it’s pretty clear that legacy service accounts are the weakest link. You can’t see it, but what you’ll see in the PDF is that they score red on most threat vectors. Their only strength is that they’re easy to use, but that doesn’t help us in the modern security world we’re in today. Standalone managed service accounts fixed password hygiene, but they broke scalability. So these work, but the applications, most applications don’t support them very well and you can’t use them on multiple machines. GMSA has got better, but they introduced new risks of the forest wide KDS root key as a single point of failure. Delegated Managed Service Accounts are the most capable and the most flexible. They’re not perfect, but they are head and shoulders, chest, waist above the traditional basic user Kerberos account. There are a couple of risks, like I said, associated with Golden Ticket and KRBTGT, but that’s because that’s the way Active Directory is put together and that’s not changing anytime soon. So the takeaway that we have is that layered defense is essential. None of the models eliminate all of the attack surfaces, but you if you apply least privilege, you look for abnormal ticket activity, you do audits of your SPNs to make sure that you have just the minimum SPNs that are actually need to be out there and you protect your root keys and your KRBTGT account—those are critical regardless of which kind of account type you choose to have for your service accounts. I have a bunch of references here for you to learn everything you ever wanted to know about service accounts. From Microsoft, there’s the link about BadSuccessor, there’s the KRBTGT rotation script from my colleague Jorge’s blog. And by the way, he has a great and widely read blog. And also my other colleague, Kriss Stephen in Scotland, has a great post about service account fundamentals. And I think we are into Q&A. I ran a little bit long, but not huge. And so let’s take a look and see what we have for some Q&A questions. Wonderful. Thank you so much, Sean. That was a great presentation. We do have some questions in from the audience at this time. But I do want to take the time to remind the audience that if you do have any questions, please feel free to type them in now and we’ll get them answered for you by Sean. With our questions, our first one that I’m seeing is why can’t I simply change a user account based service account’s password for something more secure? Yeah. That is a little complicated a way of explaining it. But essentially, when an application is running with a service account, it has the Kerberos ticket of that service account. And the Kerberos ticket lifetime is by default ten hours. And at the end of that, that ticket is renewed. If you go in and change the password on a service account to something stronger or anything, you change the password, The password that is being run in the application is stored on the server, like the SQL Server that is running. It attempts to reuse the password. Well, that password is no longer valid. It will not get the Kerberos ticket and the application will fail because it can no longer access anything. So when you change the password on a regular user service account, you have to coordinate with the application owner, again assuming you even know where the application owner is, to change that and without causing an application downtime. Now, if you have a product such as Directory Services Protector that you know you can easily roll it back and you’re feeling really daring, you could do the scream test—not screen test, the scream test—and change the password on the service account and see who screams and then you’ll find out who’s using it—but that could be a career limiting move—and then roll it back once you find out who’s using it. But that still may be viable for old accounts that you think are not being used very often when you have that ability to roll it back. Thank you so much. We have a question in from Paul that says, What’s the first step I should take to get control of my service accounts? The first step is understanding the scope of your problem. Do lots of queries, do these queries and there are other service accounts are getting a lot of visibility right now and there are a lot of blog posts showing up and providing a fair number of scripts as well to help you discover your service account. So I have the simple queries in here, but if you do a little bit of searching around on the web or have your favorite AI do it, you will come up with a number of different scripts to help you find those service accounts. But unfortunately, once you have that, it’s still a hard slog. You still have to go through and you have to try to figure out what they do. You have to figure out who owns them and hope that everything doesn’t turn into the screen test. Thank you. We have a question in from Carlos. It looks like Carlos is saying, is there a good way to change those passwords or move them to sMSA? Well, I think, Carlos, I sort of just addressed that, you know, the good way to do it is you have a project and you identify where the application if associated with an SPN, you have a it’s pretty straightforward to figure out where the application is. And from there, hopefully, it’s not too difficult to figure out who owns the application. And then you plan for downtime, and you go in and you change the password in Active Directory, and then you go into the application and you log in and you change the password you change the password on the application. SMSAs, you need to look ahead of time and look to the application owner or in the application vendor to find out if they support sMSAs. That’s probably the biggest hurdle is what applications support sMSAs. Microsoft applications, I’m a bit rusty on it to be perfectly honest. I know, for example, the canonical example for an sMSA is ADFS—Active Directory Federation Services—supports sMSAs and in fact encourages the use of sMSAs. But it really is a question of whether the application can support it. Thank you. We have two more questions. I’m going to try to squeeze them in for you. We have one question in from Timothy. They’re saying, Any thoughts for programmatically validating SPNs? We see a lot of service account reuse and our pentesters are frequently exploiting accounts. We have around 19,000+ service accounts. Timothy, I feel for you, buddy. Yeah. Yeah. And for programmatically validating SPNs, I don’t have a good answer for you on that. That’s a good approach and I would do some searches on that because you probably have a whole lot of SPNs and I doubt you have 19,000 SPNs in your environment, but I’m sure you have several thousand. And, yeah, you have to tackle it programmatically. I know, like I said, our service accounts module can has abilities to assist in finding all of them. I don’t know if we do, by chasing down SPNs or not, but that’s a that’s a that’s a good tactic. Our last question is MFAs for interactive service accounts? Don’t know if you know and then we have and source destination ACLs for non-interactive service accounts. Do you maybe know what they’re referring to? Michael, if you want, you can always reach out and we can get your information to Sean if you’d like to give us a little bit more. That be helpful because I’m not quite sure. So I mean, service accounts, if by interactive he means like human login, I’m not sure if he means that for interactive service accounts, and source destination ACLs, access control lists for non-interactive service accounts. Yeah. Send me an email, Michael, or send it through Allison, and we’ll get it. I’m sean@semperis.com and let’s get your question answered so I understand it better. Awesome. Thank you so much. Sean, it looks like we’re just about out of time, but before we wrap, I just wanna say thank you so much for being on here with us today. If we didn’t get your questions, please feel free to put them into the console now and we will send them over to Semperis and their team to answer after the webcast. Thank you so much, Sean. Thank you to the audience for attending today’s webcast and of course, a special thank you to Semperis for sponsoring today’s event presented by Redmond Mag. Thank you again for attending and have a wonderful rest of your day, everyone. Thanks, everybody.