PG - Enemy at the Gate, and Beyond: Detecting and Stopping Account Takeover

hello everyone good morning yeah welcome to bsid Las Vegas pretty stoked today um this is The Proving Ground area we got some awesome information lined up for today I'll be your spiritual guide information Highway uh Jester so uh before we get going I want to get to a couple housekeeping items first we need to thank all of our sponsors of course our Diamond sponsor Adobe and then our gold sponsors Toyota prism cloud and Plex track of course without their support none of this would really be possible the other thing to remember please silence your cell phones nobody likes the loud buzzing going off in the middle of presentation also since this is being recorded and streamed in some cases um we don't want to interrupt the the folks at home that are watching um during the Q&A please make sure you pop up to the microphone here to use it otherwise we can't hear you and the folks at home can't hear yet so please make sure you do that and use it um and then without further Ado I would like to introduce you to yall sakaria to talk about the Enemy at the Gate detecting and stopping account takeover please thank you hi everyone thank you for coming here today um my name is IAL I live in Israel T Aviv and my background is mostly from A200 intelligence unit in the Israeli Defense Force over the past two years I've been working for hunters an Israeli startup that builds a sock platform in this talk I'm going to introduce uh the count takeover research that we did in the team uh talk talk a bit about our team's unique approach provide some real life examples and here some Hands-On experiences so what's the problem and why is everyone talking about account takeover the three primary ways in which a attacker is access in organizations are stolen credentials fishing and exploitation of vulnerabilities according to DB reports more than 50% of the attacks this year have used stolen credentials for initial access which makes it the number one attack Vector when talking about web application attacks the number are even higher 86% let's dive into some real world examples I'm sure you all heard about lsos not so long ago lapsos had access to T-Mobile's Network by compromising employee accounts either by buying link credentials or through social engineering this gave lapsos access to T-Mobile internal tools including Atlas a tool used for managing customer accounts through this employee account access the hackers were in a position to carry out Sims SW atts where hackers reassign a Target cell phone number to a device under their control this allows for the interception of phone calls and text messages that can be used to further break into a victim's account and also obtain two Factor authentication codes the H the hackers were able to steal source code from a range of companies project just as the group has done with Samsung Microsoft and globant and this is not the end Google F bre resulted from the hack on T-Mobile which impacted 37 million customers by exposing their phone numbers the attack was essentially an API scraping exploit allowing the attacker access to records of basic customer contact and profile information well that's not a big surprise um in mitor attack framework there are more than 50 references of different attack groups leveraging credal credential dep and as you can see the list of reaches is just getting longer and longer so what's the problem and why is it so challenging to detect we are well aware that the companies that we just order logos all utilize some form of identity provider while multiactor authentication is highly recommended and useful it is not Bulletproof detecting a count takeover during the initial access phase is indeed possible but it's not so easy whether it involves credential death from the dark web social engineering or supply chain attack the attacker enters in the king's Rush the red carbet is laid out before them living Defenders with limited options however there are steps that can still be taken it can't take over is more than just getting authenticated we divide it to two different stages access acquisition and access leverage access acquisition is often considered a singular event by reiting credentials and invalidating all sessions the attacker access can be blocked however incident like lapsos have taught us that insiders can hand delivered credentials to attackers Ena access without triggering failed login alerts requiring enumeration or generating failed MFA challenge alerts this allows attackers to bypass the traditional steps associated with account takeover even without reaching any accounts within the organization access leverage has become increasingly dangerous with the rise of single sign on SSO and identity Services is the become single point of failure gaining access to an SSO or identity service authenticated account essentially grants the keys to the kingdom in this talk we will explore one of the most interesting attacks witnessed this year within one of our customers environment we will cover both the access leverage and access acquisition aspects explaining how every step within the kill chain can be detected let's see that in action it begins with when the attacker somehow gets Jon's credentials whether they have been licked or purchased then they bypass thema and gained access to a to Jones Azure account afterward they sent a fishing email from Jon's compromised email account to Sarah Sarah CLE on Dem malicious link and M is installed on her computer this m steals our oaka session cookie enabling the attacker to hijack the session and gain a temporary access key to the company's AWS account in order to remain persistent in the network the attacker creates a persistent AWS access keeme allowing them to exfiltrate and manipulate data we're going to cover some detection opportunities for the techniques involved of in this attack chain our Focus extends Beyond simply identify these techniques we will also talk about noise reduction methodologies for very well-known detection rules and avoid the issue of alert fatigue lastly we will discuss the workflow for security responders during investigations let's begin exploring these detection techniques and strategies in detail the first step the the attacker perform is to log in using Jones credentials since the attacker and Jones are not located in the same place and probably not even in the same country we are supposed to be able to detect this using impossible travel rule also known as superhuman activity impossible travel is about detecting two consecutive logins from two different IP addresses by the same user user with the required traveling speed between them being impossible in the specific time frame impossible travel May indicate the logins were not made by the same person therefore Rising the suspect the user was compromised by malicious actor sounds easy right well apparently it's not so easy simply running this schol on one of our big bigger customers login logs a unified schema contain login logs from different data sources including identity providers homegrown application clown providers and basically any SAS up that you can think about raise more than 9 Millions per one week that's of course not a number that any analyst talented and experienced as he is will be able to deal with in order to reduce noise and find a needle in the astray we need to understand the root causes for false positives and and identify common patterns so we can develop noise reduction methodologies without making significant compromise the first problem that comes to our mind When developing impossible trouble detection is how not dealing with vpns nod and proxies these tools are used legitimately in organizations to remotely log into different Services as I mentioned earlier impossible trouble is all about Sal application login logs but what if we leverage gdr logs to identify IP addresses that are being used by a large number of users if more than let's say 10 endpoints with sensor is installed are being are seen behind an IP address on a regular basis we can assume this IP address is the office not or the company's VPN and therefore not generating an alert for it this noise reduction methodology reduces like 35% of the alerts continuing this line and another common false positive pattern that we identified is IPS that are being used on a regular basis maybe it is not a company's VPN but hey what if I'm logging in from an IP address that is that has an EDR agent agent that is seening the data every single day and what if I'm logging in from a phone from the office Wi-Fi if the IP logged in is seen behind a computer that has an EDR agent installed or used to log in for uh to various SAS applications for a long period of time we consider it trustworthy and TG it as an organizational IP and if both IPS in the alert are trustworthy it is less likely to be a malicious actor okay we progressed a little but we still have too many alerts than we can handle super human activity as you can guess from its name ends to catch a human attacker understanding that this status is not aimed to C to catch compromised service accounts we decided to eliminate logins from nonuser accounts but how can we identify these for example Office 365 provides user type in their login logs and therefore service accounts can be ignored with a simple SQL filter in Octa for example we can TG usern names prior the detection phase we use specific events that are only sent by services and tag these usernames as services for future usage then in the detection phase we can use this asset tagging to filter out nonhuman assets finally for the last no reduction methodology one of the key questions we ask is does this traveler consistently travels between two specific coordinates we a to establish a baseline of statistically significant troubles involving two coordinates SPS of locations for the same users with a baseline in place we can then detect any deviations from the established patterns when a user's trouble Behavior significantly deviates from its usual pattern it rises suspicion and triggers an alert through the combined implementation of noise reduction methodologies including identifying non-human accounts creating an organizational IP Baseline and filtering out rerouting tools we achieved a remarkable decrease in the number of alerts this reduction from ions to just a few dozens allows security teams to efficiently handle and investigate the remaining alerts okay so what's next the attacker login to Jon's account without having to meet the MFA requirement but how is that even possible os2 and other mod authentication methods use identity provider like aour active directory to enhance the Authentication security using MFA when the user authenticates successfully he's granted an access token but what about devices that cannot utilize to a f think about the old printer located down the hall in your office for legacy devices and applications always to includes a flow called resource owner password credentials RS this flow allows the allow the device to receive a token using only the user's credentials without the requirement of toofa for example if your all printer needs to send you an email indicating it's out of Inc it must connect to the Office 365 mail server via its authentication methods as your active directory Microsoft enables the ropes mechanism for the SMTP protocols on The Office 365 mail server by by default to provide a way for legacy application to adopt mod authentication without requiring developers to update the application itself exploiting this mechanism the attacker used Jon's credential to send and receive an email to send an email on his behalf bypassing the need for MFA authentication so how can we detect this Microsoft utilizes a user agent called B to RS which stands for basic authentication version two resource owner password credentials it is used to identify basic authentication from Legacy protocols while it is barely documented buff robs is a mechanism developed by Microsoft that enables all applications relying on Legacy authentication to seamlessly switch to os2 using flow in real time simply looking for this special user agent will provide a really decent and high fedility alert but this is only a user agent how can we investigate this kind of alert first we can correlate The Source IP with the EDR agent to determine if it is associated with known end points within our organization next we can anal the previous aure login activity if this device always uses a legacy protocol to authenticate it is most likely to be a bad practice than an attacker additionally we investigate the compromised email account for any indic for any indicators of business email compromise such as creation of forwarding rules or sending emails around the loging time as a mitigation staff consider applying the block Legacy of policy in in conditional access policies this policy can help prevent further exploitation through Legacy authentication protocols okay let's recap what we had so far the attacker obtains stolen credentials and gains access to Jon's account they used an MFA bypass technique granting access to send and receive emails taking advantage of this access the attacker sends a fishing email to Sarah when Sarah clicks Mal is installed on her computer this becomes the pivotal moment from access acquisition to access leverage once the attacker has control over Sarah's account his objective is to gain access to valuable assets and maintain persistent if possible and what provides access to everything the identity provider now let's dive into the technique of OA session hijacking which is a serious threat in this situation let's briefly go go over uh of how sessions are managed in Octa when a user starts a session in Octa a unique session identifier is generated and relevant information is stored both in the client side and the server side the session cookies contain s information required for authentication during the SSO process the user's web browser sends a request to OCTA since the attacker has M installed on Sarah's computer he can steal the session cookie from the web browser and use it to hijack the session so what does it look like OCTA session contains two main events in the initialization phase OCTA session starts and OCTA Sol login we're basically looking for something that looks unusual in the session for example the user agent the first step in our OCTA session hijacking detection is to aggregate events based on the OCTA session ID by doing so we can identify unique sessions and focus on the first session initialization event within our defined sech window this allows us to pinpoint the start of each user's session next we examine whether there are multiple IP addresses Os or browser variations associated with each OCTA session ID to reduce noise and improve the accuracy of our detection we utilize the Leon distance algorithm we don't want to alert every time someone just updates their Chrome version but we do want to alert if there are significant differences in the user agent such as different OS versions this lein distance algorithm um measures the similarity between different Os or browser Variations by calculating the minimum numbers of operations required to transform one string into another by applying this algorithm we can better identify similar variations and distinguish them from significant differences that may indicate session hijacking attempts well if in any OCTA hijacking successful attack the attacker is sub subject to the constraints of the stolen sessions both itation and the resources accessible during the session if the legitimate user logs out or is log out logged out by an administrator the session cookie is invalidated with that in mind following the successful hyding of the OCTA session the attacker establishes a persistent AWS access key that will later on allow him to exfiltrate and manipulate data the detection we are going to cover is to discuss covers both creation of new persistent aess Kei and leaked credential usage the thing is that creation and usage of AWS persistent aess key is very normal happens all the time so how does this detection work firstly we rrive AWS clout logs and filter out IIM users this ensure that we focus on non-temporary users who have the ability to perform API actions we also exclude AWS internal IP address set since these internal IPS are typically associated with AWS services that are not indicative of external access additionally we filter out requests are sent from within a VPC by checking for n VPC endpoints this helps us identify requests or orating from outside of APC environment next we look for instances where an access key is used for the first time from a specific IP address although it is generally not considered a security best practice to use the same axis keid from multiple new IP addresses they're all legitimate situation where this can occur within an organization factors such as third party Integrations or Services as well as a distributed Workforce may lead to access from various locations to distinguish abnormal usage from legitimate usage involving multiple APS we create a baseline using time serious calculation this Baseline helps establish a normal pattern of Ip usage for each access scheme and to alert only when it deviates from the standard okay back to our attack scenario throughout this talk we have explored several critical detection opportunities and investigation workflows to detect both steps of a account takeover we began by discussing the detection of impossible travel focusing on noise reduction methodologies and avoiding alert fatigue next we talked about Asal MFA bypass techniques emphasi emphasizing the importance of Investigation worklow analyzing as login activity and investigating business s compromise we moved on to the access leverage phase where we explored the threat of ocation hijack hijacking and its detection mechanisms lastly we examine abnormal usage of AWS AIS Keys establishing Baseline to identify potential kixs and unauthorized key usage as we wrap up this talk I want to leave you with three important points to remember first MF alone is not sufficient to guarantee security it is crucial to implement effective detection mechanisms to identify both access acquisition and access leverage even with MFA in place second data source correlation correlating data from multiple sources helps us reduce noise and provides a better contextual understanding of potential threats and lastly detection is just a first step an effective security responder workflow is essential to mitigate and respond to security incidents thank you very much for your time I will be happy