Identity is the New Perimeter

by Charlie Smith, Microsoft Solutions Principal, Critical Start

Identity based attacks are on the rise and so is the level of exposure.  If you pause for a moment to think about everything your account (aka Identity) has access to — Salesforce, Email, OneDrive, Teams, Slack, VPN, Dropbox to name a few – it’s only natural to start thinking about:     

• The sensitive data you have access to
•  The emails, contact information and shared mailboxes you have access to
• The internal and customer data you have access to
• What you would find if you downloaded everything in your OneDrive or Dropbox

Chances are you can access these resources from the public internet without being behind the corporate firewall or VPN connection, hence why Identity is now considered the new perimeter!

Threat Actors and Identity:

Threat actors are resourceful and use a variety of techniques to compromise their victim’s accounts.   When a threat actor compromises an Identity, they essentially have the same access, SaaS apps, files, contacts, email, etc., as their victim. And while most organizations have implemented additional security measures such as multi-factor authentication (MFA), it doesn’t always stop threat actors from gaining access to their victim’s account.

The attack kill chain illustrated below highlights a few of the more preferred techniques threat actors use to compromise their victims.

• Phishing email
• Payload on the endpoint (exploitation and installation)
• Brute-force attack

Unfortunately, most organizations regardless of size (small business to large enterprise) and level of security maturity experience these types of attack. That’s why providers, such as Microsoft Azure AD (AAD), offer an “Identity Protection” solution that will alert on suspicious and malicious sign-in behaviors.

Resolve Every Alert:

If you look at several of the largest breaches, the security tools did their job.  They detected the threat and raised an alert, but since the alert was labeled “low severity”, it went uninvestigated. Now, this doesn’t mean the security teams involved in these breaches were lax in doing their jobs — the exact circumstances behind why low severity alerts went uninvestigated may never be known to the public.  Was it a staff shortage?  A lack of knowledge or the incorrect mix of resources?  Was it an “alert” prioritization policy being observed by the Security Operations Center (SOC) analysts?  

All alerts need to be investigated to uncover if the behavior is trusted or malicious. At CRITICALSTART™ EVERY alert, including AAD Identity alerts are fully investigated for their trusted behavior, or lack thereof, and resolved regardless of alert severity (critical, high, medium, low, informational).  This means critical severity alerts are given the same attention, level of detail, and priority as a low and informational alert because threat actors operate in EVERY severity alert level.  

Microsoft AAD Sign-in Attributes:

When investigating an ADD Identity alert, the following attributes should be part of every investigation.

• Anonymous IP Address
• Multifactor authentication – pass/fail?
• Client app + User Agent
• Device Information
• Location
• Office365 Activity + AAD Audit logs

Let’s take an example of “Anonymous IP Address”. Essentially this means AAD Identity Protection has detected a sign-in from an IP address that has been flagged as anonymous. While the practice of using a TOR browser, private VPN, etc., to appear anonymous is not always malicious, it is certainly suspicious when accessing corporate resources.  

By following the steps below, the answer to “should this behavior be trusted or is it malicious” may be a little easier to make.

Multi-Factor Authentication (MFA):

When looking at an identity alert, the AAD sign-in responsible for the alert needs to be reviewed. By obtaining the Request ID from the alert, the AAD can be searched for the Request ID. Not only does this zero in on the actual sign-in, but other sign-ins that came before and after (more on that later) can be reviewed to uncover if this behavior is malicious or not.

One of the first attributes to focus on is if MFA was applied.  If yes, did it pass or fail? In the screen shot below, the MFA was applied, and it was successful.  Remember, just because the MFA was successful, doesn’t mean this behavior is trusted.

Client App + User Agent:

Reviewing the Client App and User Agent attributes provides some great context on what methods were used to sign-in. For example, was “IMAP” seen as the Client App, while the User Agent was “BAV2ROPC”? In the screen shot below a browser was used as the Client App, and Firefox as the User Agent. While this activity is not malicious it does rule out other suspicious behavior.

Device Information:

Reviewing the device information identifies the operating system, browser, managed (Intune enrolled), join type (AAD join, hybrid join, AD registered) and more. In this context, empty fields are equally important as populated fields. In the screen shot below, it’s clear that the sign-in came from a Windows 10 device using Firefox.  However, what makes this sign in suspicious is what’s missing. 

• This device did not come from a join type of Azure AD Registered (BYOD), AAD Join, or Hybrid join
• This device is not managed with Microsoft Intune, therefore it would not be in a compliant state
• The Device ID field is blank, which further validates AAD doesn’t have a computer object in its directory

Location, Location, Location:

Out of all the attributes, location can be subjective and tricky during an identity investigation. However, it does serve as a great data point.

Reviewing AAD sign-ins before and after a sign-in shows the user consistently logged in from the same location (Plano, TX), then there was a successful sign-in from Germany. Could the user be on vacation in Germany? Sure.  Is it possible the user is in Germany, but used a VPN connection to Headquarters in Plano, TX? Sure.

However, what makes this suspicious is the fact that this IP address has been flagged as anonymous, it’s a location not seen before for this user and the device is anonymous so it shouldn’t be trusted because AAD doesn’t have any records of it.

Office365 Activity + Audit Logs:

Reviewing a user’s Office365 (O365) activity and audit logs helps identify other suspicious activity at the time (or around the time) when the sign-in occurred. By reviewing the O365 Activity (especially from Microsoft Cloud App Security – MCAS), any mail forwarding rules, mass download, sensitive file sharing to external user, MFA setup on another device, etc. can be observed.

Also, by reviewing a user’s audit logs, evidence of a new device being registered, and an existing device being removed around the time of the anonymous IP address alert are seen. While seeing a user register a device on their account is not suspicious, the timing of the two events is too close. At this point, remediation steps are recommended.

Remediation Steps:

When it comes to remediation, there is typically three suggested steps to take:

1. Revoke session tokens:  Immediately revoke all user sessions to kick off all current signed-in sessions (this includes the user and threat actor)
2. Disable account: to prevent the threat actor logging back into the account (this means the user too)
3. Reset user password: after making the user aware of this

Luckily all these actions can be taken from the user’s account within Azure Active Directory (see below).

In Summary

Identity based attacks are now the new perimeter.  Preventing these types of attacks is more important than ever due to the global nature of business, and the required speed of user access to cloud-based networks and productivity tools anytime, from anywhere, and on any device. 

Microsoft AAD Identity Protection can help to identify suspicious and malicious sign-in behaviors while managed detection and response services provided by CRITICALSTART can investigate and resolve every alert, regardless of the severity, to ensure that businesses, user identity, and the data accessed are fully protected.