Team Axon threat hunting expert Yonatan Khanashvili recently appeared on Steve King's Cybersecurity Unplugged podcast to speak about the "Golden SAML" attack technique.
In this fascinating conversation, Steve and Yonatan discussed:
- What Golden SAML attacks are and how they are conducted
- Why this type of attack is so difficult to detect by traditional security tools
- How Hunters detects Golden SAML attacks via our cross-correlation engine
- What organizations can do to detect these attacks and prevent remote access to the network by attackers
Listen to the full podcast below:
The following transcript has been lightly edited for clarity.
Steve King (00:13):
Good day, everyone. I’m Steve King, the director of Cybersecurity Advisory Services here at CyberTheory. Today’s episode will explore the Golden SAML internal attacks and the importance of cross data correlation. SAML is the acronym used to describe the Security Assertion Markup Language standard, used in online security that enables folks to access multiple web applications using a single set of login credentials. This is a fantastic opportunity to demonstrate the power of detecting malicious threats, not only on a specific single vector, but also it raises research questions around the difficulties of traditional single service solutions to detect them. Joining me today is Yonatan Khanashvili, a senior research lead at Hunters and one of the few people on the planet who spends every waking moment hunting bad actors in cyberspace. Hunters is a VC-backed Israeli company with a SOC Platform that empowers security teams to automatically identify and respond to security incidents across the entire attack surface. They mitigate real threats faster and more reliably than SIEMs and ultimately reduce the customer’s overall security risk. Welcome, Yonatan. I’m glad you could join us today.
Yonatan Khanashvili (01:47):
Hi, Steve. Thanks for having me and thanks for the lovely intro.
Steve King (01:51):
Sure. Let’s dive in here. If I’m not mistaken, you guys raised a $68-million Series C round in January of this year. What are your plans for that investment and what is your differentiator compared to your top legacy SIEM competitors, for example?
Yonatan Khanashvili (02:10):
Yeah. Hunters indeed raised $68 million in Series C earlier this year, which is very exciting obviously. The plans are to keep improving the product, developing any new features, while we keep feeding the Hunters platform with more cybersecurity knowledge and content, which will make the Hunters platform better and better as the time goes. I think that the main differentiator between us and legacy SIEM competitors is our ability to provide the product as a SaaS, which simply puts us in a different view of the old SIEM market, that’s simply based on on-premises old solutions that do not provide ingesting, engineering, and detection as a service, which is kind of a key point in a fast-changing attack surface.
Steve King (03:08):
Just roughly… I’m not going to hold you to this, but how many customers do you have today?
Yonatan Khanashvili (03:14):
I think it’s kind of a question that we are not able to answer, but there are dozens of customers that are using the product today and we’re rapidly growing on every quadrant.
Steve King (03:24):
How many employees and do you have offices outside of Israel?
Yonatan Khanashvili (03:30):
We have 150 employees worldwide. In Israel, in the R&D main location, they’re around 80.
Steve King (03:39):
Okay. That’s helpful. Thank you. Talk to me about the big Golden SAML attack and the Golden SAML attackers get access to any application that support SAML authentication that could be cloud-based, Azure, AWS with any privileges they desire and can be any user on the targeted application. Even one that’s nonexistent in the application, in some cases. How did Hunters deal with this?
Yonatan Khanashvili (04:08):
We started to research the Golden SAML attack earlier this year. With a few research questions that we had in our mind, that we wanted to see if we can answer and maybe solve with a better way. I guess the first one is, “What is the awareness of this attack at all in security operations worldwide?” It’s kind of a unique attack and technique that mostly security experts, even sometimes red teamers are not aware of. And the second one is actually if security products today, single surface security products, can detect it and if they can detect it reliably. What we try to do to deal with it is to develop a cross-correlation detection that, I guess, we will discuss more in this talk and to be able to reliably detect the attack and provide more context to the security operations that use the product.
Steve King (05:02):
Okay. Can you explain to our audience, sort of in detail, how that attack works?
Yonatan Khanashvili (05:09):
Yeah. I think that we should start with a few terms to give a bit of background to the audience that maybe they’re not familiar with it. The first thing is IDP. So, IDP is simply an identity provider that provides an authentication layer to various applications that you configured in your enterprise organization. For example, it can be Okta or Azure AD, which are kind of common managed IDP solutions. Another one, which is the one that we’ll discuss today, is ADFS. ADFS is simply a software developed by Microsoft that gives you the ability to have an unmanaged IDP, which means that it’s simply an IDP. But compared to others, like the examples that we gave such as Okta, for example, it’s an unmanaged solution. So you manage the server inside your on-premises environment.
The second term is actually service provider. The service provider is actually the applications that are configured to the IDP and give the user the ability to log in and use them. For example, it can be AWS, G Suite, O365, all the SaaS and cloud applications that organizations use on a daily basis. The ADFS simply gives the ability to have trust between the service provider and the on-premises environment. So, how the tech simply works is with the ability to create a forged SAML that will allow an actor to authenticate and impersonate any user in the federated service. Let’s try to examine a legitimate authentication that will happen when you use ADFS’s IDP. So you as a user will simply log into the service provider that you want to use, for example, G Suite. The G Suite will identify that you used the IDP that's configured to it and will send the packet to the ADFS server that's located in the on-premises environment.
Yonatan Khanashvili (07:14):
The ADFS server will sign the SAML with a certificate that is stored on the ADFS server and will send it back to the service provider, in our case, G Suite, which will simply see that he knows the encryption, he has the key to decrypt it, and will let the user to authenticate. Where that text start to be a danger is when an actor can put his hands on the certificate, which is located on the ADFS server as we say, and simply create a forged SAML that’s signed with the certificate that he stole and just give him the ability to impersonate to any user in the domain, in the federation, and log into the service providers that are configured to the ADFS.
Steve King (07:59):
I see. Okay. These things are multiple steps, right? For example, assuming that AWS trusts the domain, which you’ve compromised, you can then take advantage of the attack and kind of gain any permissions you want in a cloud environment. But you need a private key that signs the SAML objects. So, for the private key, you don’t need domain admin access, you only need Active Directory FS user account. How hard is that to get for an attacker?
Yonatan Khanashvili (08:32):
Yes Steve, so as you said, in order to obviously forge the SAML, as you said… to sign the SAMLs, you will need to stall the certificate that’s stored on the ADFS. The only user that can export the certificate is the ADFS service account, which has a named pipe open to the database where the certificate is stored. I guess, to answer the question, how hard it is to get the certificate, we can mention briefly about an attack that involved the Golden SAML, which is known as SUNBURST attack that happened two years ago. They’re known as SolarWinds incidents that we all remember as security experts. We saw a Golden SAML attack in the wild. It happened. To answer the question about how hard it’s to get a certificate, we can simply, I guess, compare it to having a foothold on-premises, Active Directory environment, having domain admin credentials that can simply help you to gain any user object in the Active Directory. ADFS user account is simply an object in Active Directory. And we see those attacks happens on a daily basis, right? In one SAML activity and incident that we see, so it’s of course possible. And it’s that not that hard if you have THE access to the on-premises environment, indeed.
Steve King (09:56):
Yeah. It sounds like it’s not hard at all.
Yonatan Khanashvili (09:58):
Definitely. And I will mention that there is a lot of research papers talking about the Golden SAML attack, including a great piece of research that Mandiant published and other security firms. This knowledge exists online and it’s not something that’s exclusive to specific actors. It's really something that can be executed without a problem.
Steve King (10:25):
Yeah. The thing that bothers me about all of this, and not specifically SAML attacks, but everything that we do when we discover an attack vector that’s been successful, for example. We kind of scurry around and we kind of have a solution for it and then we talk about it. And then we sort of go away. I mean, we may be a couple of startups put together a company that focuses on solution, but we’ve just said here that we don’t really have a solution for this. Is that correct? I mean, you guys can detect these things, assuming you’re hunting for them. I guess part of my question is, what sort of detection and hunting techniques do you guys use to find and identify the bad guys doing this stuff?
Steve King (11:19):
And if a company like, let’s say, ABC Company, my company. Let’s say I don’t hire Hunters or I don’t buy your product. Does that mean I’m just ignoring this threat? And what does that mean for the industry? Does that mean I’m pretending that SAML attacks aren’t going to happen or they’re not going to happen to me? It’s bothersome to me anyway, and it’s not just, I mean, there’s hundreds of these where we say, “Yeah. Well, third party open source is a problem,” but then we never say how to deal with it because there is no way to deal with it. Is that true in your mind, as a researcher, as a guy that’s been around this space for a long time?
Yonatan Khanashvili (12:07):
Yeah. I think it makes sense. And I think that we as an industry always try to come with new solutions and also increase the awareness of these attacks. It’s not really that this attack can't be detected. It's just more challenging than other simple detection logics that everyone knows. We as an industry always need to keep educating each other with those new findings and give them the ability to actually detect it. And if we discuss specifically about the Golden SAML attack, we came up with interesting detection logics that we obviously conduct in the product, which includes, for example, the ability to correlate between multiple data sources. For example, the ability to correlate between their Windows ADFS event logs and the login to the service provider logs, can provide a reliable coverage for it. And I will explain.
Yonatan Khanashvili (13:21):
We just spoke briefly about how the attacks work. And we know that in order to create the forked SAML to authenticate with a service provider, we don’t need to log into the ADFS server itself, right? Because if we have the certificate, we can simply create a forked SAML without authenticating with the ADFS server. What this means is that we can assume that if we will see a login to the service provider, to the O365 login, to the O365 component without seeing the white Windows event logs in the ADFS server, after we chatted, we can assume that someone has a certificate and just created a forked SAML. This is exactly the detection logic that we're implementing at Hunters and we’re kind of sharing it with the community, and suggesting to security operations to actually implement it.
Yonatan Khanashvili (14:25):
Another one, which is actually an easier one, if you ask me, and also not only based on cross-correlation capabilities, like what I just mentioned, is monitoring for suspicious logins to the ADFS service account itself. Which configured in a default, when you install ADFS server, you create a service account and it should only be with event login type of 7, which is the service login type. Any different login type should be examined and investigated. I will say that if you see an RDP connection with event type of 10 to service accounts, to ADFS service account, it’s definitely a red flag that you should investigate. And if it’s something that you found to be legitimate, you need to do some homework about your hygiene, culture, scope in your corporation and actually fix it. Those kind of things are the small tasks that will stop the next attack.
Steve King (15:36):
Yeah. And how big a role is cross-correlation in the process here?
Yonatan Khanashvili (15:43):
I think it actually plays a key role here because, in the end, there are a lot of really good single-serve products that are doing their job really well. If we take, for example, an EDR solution, it should monitor about stuff that happens on the operating system. The problem is that it does not know anything that happens outside the endpoint. It does not know what happens when you authenticate with a service provider. It does not know what happens on the ADFS event logs itself. And the ability to take the piece of information that each good product provides and correlate between them can give you reliable detection logic that detects complex attacks such as the Golden SAML. As we said, taking the event logs 1200, that examine authentication to the ADFS correlating with the authentication with the service provider with O365 can give a reliable detection logic. And it’s really important to understand those concepts. And we actually suggest it to any audience that hears this talk and understands the importance of SAML attacks, and specifically the Golden SAML attack, which security operations sometimes are not aware of.
Steve King (17:17):
Yeah. Right. I mean, SIEMs can’t do this today, right? I mean, there’s no SIEM that I’m aware of that can detect this kind of an attack. Is that correct?
Yonatan Khanashvili (17:33):
I won’t say that. I think that it’s possible. It will just requires a lot of team effort and people in order to do so, like ingesting the relevant logs to the SIEM storing and know how to correlate between the specific telemetry logs that required in order to detect it. I will say that it’s possible, definitely possible, but it will simply be time consuming and will require a lot of team of experts in order to do so.
Steve King (18:08):
Yeah. And I mean the typical… I guess I’m referring to the typical SIEM customer, which is not an expert. It’s CISO who is running a SIEM and they don’t have a technology background in many cases, but they know that they need some sort of monitoring and logging function and log collection function. And so they’ve installed whoever, pick your SIEM vendor. But without that kind of expertise, manipulating the SIEM, if there’s a way to even do that, I don’t think on a cross correlation basis, there is. Still, maybe you can do it single surface, but manipulating that takes a lot of work on behalf of the SIEM owner, doesn’t it?
Yonatan Khanashvili (19:05):
Yeah. Yeah, absolutely. And it’s not only about time, it’s about getting the right people in order to do so, which will require obviously a lot of security experience and knowledge about… first of all, from a security perspective, about how to conduct it; and also from engineering perspective, as you say, how to correlate between the different components.
Steve King (19:32):
Right. So does that mean that everybody that’s not a deep technical cybersecurity expert is at risk here for SAML attacks?
Yonatan Khanashvili (19:47):
Absolutely. I think that if you, as organization, are using ADFS specifically, you should take actions about examining the relevant logs and really see how you can have a better eye and visibility on those types of text. It definitely happens. We saw how it happened in the SolarWinds attack, and I’m sure there are a lot of other incidents that obviously didn’t publish, and we should be aware of it, as an industry - always share research knowledge as we’re obviously doing here, and have the awareness in security operations to conduct those visibility and detection logics.
Steve King (20:36):
Yeah. I think we have fewer people today that understand this at that level than we did a couple of years ago. Yeah. I think we’re in the opposite direction. In a way, I mean, it’s terrific for you guys. You’ve focused on this area and you should sell lots of these to folks that are concerned about this, but it also seems like Microsoft’s Active Directory is one of the worst things that ever happened to the space. And I don’t mean that in a critical way, Microsoft, but there’s so many problems that tie directly to AD that it’s almost a joke.
Yonatan Khanashvili (21:19):
Oh, yeah. Definitely.
Steve King (21:19):
My final question… Because I see by the clock that we’re kind of running out of time here. Can you sort of tell us some of the difficulties when implementing these detections that you guys encounter, and how important is the fact that this is an out of the box detection solution?
Yonatan Khanashvili (21:40):
I think it’s a really important question, Steve. We just briefly discussed about the difficulties of implementing those detections, the amount of time and the amount of people that will require us to do so. And we discussed briefly about Golden SAML here, I think, for 20, 30 minutes. But in order to do the practical work of implementing those things, it’s really a difficult and challenging task. If we will briefly reverse back the detection logic and what we said, it will start with scoping the ADFS servers and ingesting the relevant event logs, then parsing the relevant event logs that have different properties than other event logs, then storing and aggregating them in the relevant SIEM that you’re using. Then start to research the relevant service provider, authentication logs, and see how you can correlate between them, and that will be only for the service provider that you’re researching.
Yonatan Khanashvili (22:44):
You need to do it for all the service providers that obviously you’re using in the federation. And it’s really challenging and takes a lot of time. And I think this is kind of the importance of out of the box detections and the detection engineering as-a-service that we are trying to do at Hunters. Simply giving our customers the ability to ingest the relevant data, and then know that Hunters know how to parse and how to detect and how to correlate between different things. And we really are believing in the message that we’re trying to give, and this is kind of the power of providing security as a SaaS and not as an old on-premises solution.
Steve King (23:35):
Yeah. Well, you’ve convinced me. I’m ready to sign up for Hunters tomorrow. Thank you, Yonatan. Thanks for spending some time with us today. I appreciate you carving out the time. And then thanks to our listeners as well. We hope you learn something about one of the growing number of threat vectors in our complicated cybersecurity universe. Until next time. I’m Steve King, signing off.