MCAS: How to protect AWS Admins and Developers

by Contributed | Dec 16, 2020 | Technology

This article is contributed. See the original author and article here.

By Richard Diver, Alex Weinert, @Matt Soseman 

In this blog, I am going to tell you about a new deployment guide that will help you to apply several advanced security controls for access to AWS environments, using Microsoft Security solutions – this is one of the simplest implementations that can solve a myriad of problems when trying to provision identities and govern access to systems that may be business critical and hold very sensitive information.

Securing Access to AWS Environments

Management of AWS identities can be complex, especially when there are multiple environments to manage. The risk of compromise to administrators and developers is increasing as attackers attempt to gain access to critical resources. There is also a risk of misconfiguration and potential loss of data if the user credentials are not properly monitored for suspicious activity.

In this blog post for Azure AD (https://aka.ms/AWSIdentity), you can read about the implementation of secure authentication for AWS using Azure AD SSO. When the authentication and single sign-on with Azure AD is setup for AWS, you can implement advanced Conditional Access policies with MCAS to enable Session Control policies: this is the ability to continuously monitor the activities of the AWS user as they interact with resources. The diagram below shows some of the options available today with Microsoft Cloud App Security, when integrate with Azure AD to protect AWS:

For real-time data loss prevention (DLP), MCAS can use both the built-in content inspection or the Data Classification Service (Azure Information Protection) integration to block uploads or downloads.

Note: MCAS session controls apply to browser-based sessions. For thick clients, MCAS can only apply access policies (via Conditional Access App Control).

Implementing Advanced Security Controls

Microsoft Cloud App Security is a key component of securing any cloud application. When used to secure AWS it can also be used to scan the environment and provide recommendations against the CIS Benchmark to ensure the correct configuration and security controls have been implemented. The diagram below explains the layers of security that can be gained by using some of the Microsoft security solutions together:

You can take advantage of this defense in depth approach using integrated solutions you very likely already own! Get the latest version of the deployment guides here and learn more about how to enable this within 30 minutes:

• Implement Azure AD to secure AWS Authentication: https://aka.ms/AWSIdentity


• Implement advanced Microsoft Security solutions for AWS: https://aka.ms/AWSSecurity

You can also read more about how Microsoft Cloud App Security helps to protect your AWS environment here: https://docs.microsoft.com/en-us/cloud-app-security/protect-aws

To learn more about Microsoft Cloud App Security, check out the resources below:

Best Practices: https://docs.microsoft.com/en-us/cloud-app-security/best-practices

MCAS POC: Aka.ms/mcaspoc

MCAS Podcast: Aka.ms/MCASPodcast

MCAS Ninja Training: Aka.ms/MCASNinja

Thank you!

Simplified Ribbon is now available in Excel for the web

by Contributed | Dec 16, 2020 | Technology

This article is contributed. See the original author and article here.

We are excited to announce that the Simplified Ribbon is now Generally Available in Excel for the web.

The Simplified Ribbon has a refreshed modern design which makes it easy to use while retaining all the functionality and power of the classic Excel Ribbon. Going forward both the Simplified and Classic ribbon are available, and you can choose your preferred experience with a single click.

Switching to the Simplified Ribbon

You can use the “Simplified Ribbon” toggle button at the top right corner of the app to switch between the Simplified and Classic ribbon.

Using the Simplified Ribbon

The Simplified Ribbon shows the commands in a single line which not only brings a modern interface to Excel for the web but also frees up space to show more rows of data on the grid. However, this means there is less space available and all the buttons from the Classic ribbon might not be visible.

If you do not see a command on the Simplified Ribbon, please try the following:

• Similar commands are grouped together in the Simplified Ribbon.


• 
  

  For e.g., all the buttons of the Alignment group in the Home Tab are grouped together as shown below. You can click on the downward arrow beside the “Align Text Left” button to access the other alignment options.

  
  


• 
  
   
  
  
   
  
  
   
  
  

  

  
  

There are several such groups of related commands across the Simplified Ribbon.

• Depending on the width of your screen some commands may be collapsed into More Options menu represented by ellipses: . The ellipses will be available at the end of the ribbon on the right of your screen. Click on the ellipses to see the remaining commands which did not fit on your screen. Here is an example:


•  


• 
  

  

  
  


•  


• Type the command you need in the “Tell me what you want to do” box at the top of your screen. Excel will show you the command and help on using it. Here is an example on searching for commands related to indent.

Feedback 

If you have any feedback or suggestions go to Help Tab > Feedback, and then select I like something, I don’t like something or I have a suggestion.

SolarWinds Post-Compromise Hunting with Azure Sentinel

by Contributed | Dec 16, 2020 | Technology

This article is contributed. See the original author and article here.

Microsoft recently blogged about the Recent Nation-State Cyber Attacks that has impacted high value targets both across the government and private sector. This attack is also known as Solorigate or Sunburst. This threat actor is believed to be highly sophisticated and motivated. Relevant security data required for hunting and investigating such a complex attack is produced in multiple locations – cloud, on-premises and across multiple security tools and product logs.  Being able to analyze all the data from a single point makes it easier to spot trends and attacks. Azure Sentinel has made it easy to collect data from multiple data sources across different environments both on-prem and cloud with the goal of connecting that data together more easily. This blog post contains guidance and generic approaches to hunt for attacker activity (TTPs) in data that is available by default in Azure Sentinel or can be onboarded to Azure Sentinel.

The goal of this article is post-compromise investigation strategies and is focused on TTPs and not focused on specific IOCs.  Azure Sentinel customers are encouraged to review advisories and IOC’s shared by Microsoft MSRC and security partners to search on specific IOC’s in their environment using Azure Sentinel.  Links to these IOC’s are listed in the reference section at the end.

To make it easier for security teams to visualize and monitor their environments for this attack the MSTIC team has shared a SolarWinds Post Compromise hunting workbook via Azure Sentinel and Azure Sentinel GitHub. There are many things in this workbook that threat hunters would find useful and the workbook is complimentary to the hunting methods shared below. Importantly, if you have recently rotated ADFS key material this workbook can be useful in identifying attacker logon activity if they logon with old key material. Security teams should leverage this hunting workbook as part of their workflow in investigating this attack.

Thanks to the MSTIC and M365 teams for collaborating to deliver this content in a timely manner.  This document will be updated as needed.

Please note that since Azure Sentinel and the M365 Advanced Hunting portal share the same query language and share similar data types, all of the referenced queries can be used directly or slightly modified to work in both.

Gaining a foothold

As shared in Microsoft’s technical blog – Customer Guidance on Recent Nation-state Cyber Attacks – attackers might have compromised the internal build systems or the update distribution systems of SolarWinds Orion software then modified a DLL component in the legitimate software and embedded backdoor code that would allow these attackers to remotely perform commands or deliver additional payloads. Below is a representation of various attack stages which you can also see in Microsoft Threat Protection (MTP) portal.

To hunt for similar TTPs used in this attack, a good place to start is to build an inventory of the machines that have SolarWinds Orion components. Organizations might already have a software inventory management system to indicate hosts where the SolarWinds application is installed. Alternatively, Azure Sentinel could be leveraged to run a simple query to gather similar details. Azure Sentinel collects data from multiple different logs that could be used to gather this information. For example, through the recently released Microsoft 365 Defender connector, security teams can now easily ingest Microsoft 365 raw data into Azure Sentinel. Using the ingested data, a simple query like below can be written that will pull the hosts with SolarWinds process running in last 30 days based on Process execution either via host on boarded to Sentinel or on boarded via Microsoft Defender for Endpoints (MDE). The query also leverages the Sysmon logs that a lot of customers are collecting from their environment to surface the machines that have SolarWinds running on them. Similar queries that leverage M365 raw data could also be run from the M365’s Advanced hunting portal.

SolarWindows Inventory check query

Privilege Escalation

Once the adversary acquires an initial foothold on a system thru the SolarWinds process they will have System account level access, the attacker will then attempt to elevate to domain admin level access to the environment. The Microsoft Threat Intelligence Center (MSTIC) team has already delivered multiple queries into Azure Sentinel that identify similar TTPs and many are also available in M365. These methodologies are not specific to just this threat actor or this attack but have been seen in various attack campaigns.

Identifying abnormal logon activities or additions to privileged groups is one way to identify privilege escalation.

• Checking for hosts with new logons to identify potential lateral movement by the attacker.


• Look for account being created and added to built-in administrators group.


• Monitor for rare activity by a high-value account carried out on a system or service Along with adding accounts to a domain privileged group such as Enterprise Admins, Cert Publishers or DnsAdmins.


• Additionally, monitor for rare activity by a high-value accounts which has been carried out on a system or service.

Related to this attack, in some environments service account credentials had been granted administrative privileges. The above queries can be modified to remove the condition of focusing “User” accounts by commenting the query to include service accounts in the scope where applicable:

//| where AccountType == “User”

Please see the Azure Sentinel Github for additional queries and hunting ideas related to Accounts under the Detections and Hunting Queries sections for AuditLogs, and SecurityEvents

Microsoft 365 Defender team has also shared quite a few sample queries for use in their  advanced hunting portal that could be leveraged to detect this part of the attack. Additionally, the logic for many of the Azure Sentinel queries can also be transformed to equivalent queries for Microsoft 365 Defender, that could be run in their Advanced Hunting Portal.

Microsoft 365 Defender has an upcoming complimentary blog that will be updated here once available.

Certificate Export

The next step in the attack was stealing the certificate that signs SAML tokens from the federation server (ADFS) called a Token Signing Cert (TSC). SAML Tokens are basically XML representations of claims.  You can read more about ADFS in What is federation with Azure AD? | Microsoft Docs and SAML at Azure Single Sign On SAML Protocol – Microsoft identity platform | Microsoft Docs. The process is as follows:

1. A client requests a SAML token from an ADFS Server by authenticating to that server using Windows credentials.


2. The ADFS server issues a SAML token to the client.


3. The SAML token is signed with a certificate associated with the server.


4. The client then presents the SAML token to the application that it needs access to.


5. The signature over the SAML token tells the application that the security token service issued the token and grants access to the client.

The implication of stealing the TSC is that once the certificate has been acquired, the actor can forge SAML tokens with whatever claims and lifetime they choose, then sign it with the certificate that has been acquired. This enables the actor to forge SAML tokens that impersonate highly privileged accounts. There are many publicly available pen-testing tools like ADFSDump and ADFSpoof that help with extracting required information from ADFS configuration database to generate the forged security tokens.  Microsoft’s M365 Defender team has created several high-fidelity detections related to this. A few of them include:

• Possible attempt to access ADFS key material which detects when a suspicious LDAP query is searching for sensitive key material in AD.


• ADFS private key extraction which detects ADFS private key extraction patterns from tools such as ADFSDump.

Note: These detections can be seen in Azure Sentinel Security Alerts or in the M365 security portal.

Outside of directly looking for tools, this adversary may have used custom tooling so looking for anomalous process executions or anomalous accounts logging on to our ADFS server can give us some clue when such attacks happen. Azure Sentinel provides queries that can help to:

• Find rare anomalous process in your environment.


• Also look for rare processes run by service accounts


• Or uncommon processes that are in the bottom 5% of all the process.


• In some instances, there is a rare command line syntax related to DLL loading, you can adjust these queries to also look at rarity on the command line.

Every environment is different and some of these queries being generic could be noisy. So, in the first step a good approach would be to limit this kind of hunting to our ADFS server.

Azure Active Directory Hunting

Having gained a significant foothold in the on-prem environment, the actor also targeted the Azure AD of the compromised organizations and made modifications to Azure AD settings to facilitate long term access. The MSTIC team at Microsoft has shared many relevant queries through the Azure Sentinel Github to identify these actions.

One such activity is related to modifying domain federation trust settings. In layperson terms, a federation trust signifies an agreement between two organizations so that users located in partner organization can send authentication requests successfully.

• The Azure Sentinel query for domain federation trust settings modification will alert when a user or application modifies the federation settings on the domain particularly when a new Active Directory Federated Service (ADFS) Trusted Realm object, such as a signing certificate, is added to the domain. Modification to domain federation settings should be rare hence this would be a high-fidelity alert that Azure Sentinel users should pay attention to.


• If a threat actor obtains access to an Application Administrator account, they may configure alternate authentication mechanisms for direct access to any of the scopes and services available to the Service Principal. With these privileges, the actor can add alternative authentication material for direct access to resources using this credential. The team has produced queries that look for addition of new key credentials to an Application or Service Principal.


• While OAuth applications in this intrusion campaign are being used for persistent access via attacker-added credentials, while reviewing OAuth applications it may be valuable to look for evidence of previously unknown OAuth permissions, such as those that can read sensitive data and provide offline access:

Suspicious application consent similar to O365 Attack Toolkit

Suspicious application consent similar to PwnAuth

Suspicious application consent for offline access

In addition, consider hunting for new key credentials being added to Service Principals and Azure AD applications. Attackers have been observed adding new key credentials and then using these to access sensitive data within an environment. MSTIC has already published detections to help identify such activity, and this has also been incorporated into the hunting workbook.

Data Access

Accessing confidential data is one of the primary motives of this attack. Data access for the attacker here relied on leveraging minted SAML tokens to access user files/email stored in the cloud via compromised AppIds. One way to detect this is when a user or application signs in using Azure Active Directory PowerShell to access non-Active Directory resources.

Microsoft Graph is one way that the attacker may be seen accessing resources and can help find what the attacker may have accessed using the Service principal Azure Active Directory sign-in logs. If you have data in your Log analytics you could easily plot a chart to see what anomalous activity is happening in your environment that is leveraging the graph. Note that the data type in Azure Sentinel below is only available when XXX is configured.

Security Analysts using Azure Sentinel could also leverage KQL’s built-in anomaly detection algorithms to find anomalous increases in Exchange mail items accessed operations which is another way to identify this attacker activity.

For example, below is a sample query that brings out some of the logons to Azure AD that did not use multi factor authentication. It is possible this could produce many results, so additional tuning is suggested for your environment. This attack also used Virtual Private Servers (VPS) hosts to access victim networks. Combining the query below with data that list VPS server ranges will make this a high-confidence alert.

In relation to the VPS servers section above, the previously mentioned workbook has a section that shows successful user signins from VPS (Virtual Private Server) providers where only tokens were used to authenticate. This uses the new KQL operator ipv4_lookup to evaluate if a login came from a known VPS provider network range. This operator can alternatively be used to look for all logons not coming from known ranges should your environment have a common logon source.

In addition to pre-compromise logon hunting it is also possible to monitor for logons attempting to use invalid key material. This can help identify attempted logons using stolen key material made after key material has been rotated. This can be done by querying SigninLogs in Azure Sentinel where the ResultType is 5000811. Please note that if you roll your token signing certificate, there will be expected activity when searching on the above.

Additionally, as a cloud native SIEM Azure Sentinel can not only collect raw data from various disparate logs but it also gets alerts from various security products. For example, M365 Defender has a range of alerts for various attack components like SolarWinds malicious binaries, network traffic to the compromised domains, DNS queries for known patterns associated with SolarWinds compromise that can flow into Sentinel. Combining these alerts with other raw logs and additional data sources provides the security team with additional insights as well as a complete picture of nature and the scope of attack.

References

Recent Nation-State Cyber Attacks 

Behavior:Win32/Solorigate.C!dha threat description – Microsoft Security Intelligence

Customer guidance on recent nation-state cyberattacks 

FireEye Advisory: Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor

FireEye GitHub page: Sunburst Countermeasures 

DHS Directive

SolarWinds Security Advisory

FalconFriday – Fireeye Red Team Tool Countermeasures KQL Queries  

Microsoft-365-Defender-Hunting-Queries: Sample queries for Advanced hunting in Microsoft 365 Defender (github.com)

Azure Sentinel SolarWinds Post Compromise Hunting Workbook

Enhanced AI for account compromise prevention

by Contributed | Dec 16, 2020 | Technology

This article is contributed. See the original author and article here.

Hello Everyone,

One of the amazing journeys I have been lucky to be a part of is developing our self-tuning algorithms for detecting attacks on accounts in real-time. Back in 2012, we got tired of the treadmill of manually adapting to attackers and committed to adaptive learning systems. Today, I want to share some cool new work the team has delivered.  When I started fighting account compromise at Microsoft, we put a lot of effort into building and maintaining a large set of heuristic rules that ran during authentication.  These rules effectively spotted compromise based on observed behavior, but it was easy for attackers to change their patterns and bypass those rules. This meant that we were always in reactionary mode trying to update the heuristics every time an attack pattern changed, or a new attack evolved.  At that point, we decided that the only scalable and maintainable way to prevent current attacks and adapt to block new attacks was to apply machine learning to the area of account compromise. After much research and many iterations, we built a real-time system that uses supervised machine learning to analyze the current compromise to adapt and block attacks as they happen. 

Fast forward to today, we just released a re-design on the real-time machine learning compromise prevention system for Azure AD. The improved system still leverages supervised machine learning but it expands the features and process used to train the model, which provides significantly improved accuracy in Azure AD real-time risk assessment. The model flags more bad activity as risky while simultaneously reducing false alarms. This risk can be used by Azure AD Identity Protection customers as a condition in their Conditional Access policy engine to block risky sign-ins or ask for multi-factor authentication. Let’s dive into how the real-time compromise prevention system works.

The real-time ML system leverages intelligence from many sources, including:

• User behavior: is the user signing in from a known device, a known location, a known network?


• Threat intelligence: is the sign-in coming from a known bad, suspicious infrastructure?


• Network intelligence: is the IP address part of a mobile network, a proxy, a hosting facility?


• Device intelligence: is the device compliant or managed?
  
  

Known good or bad sign-ins are used to label the data and help “teach” the algorithm what is a good sign-in and what is a malicious sign-in. These known good and bad sign-ins are called labels and are a precious good when it comes to building AI systems for security. Our team has invested a lot in having good quality labels that can be used to train models and to assess the detection performance. One of our most significant assets is a team of highly trained analysts who work on data labelling by manually reviewing cases and making determinations. We also leverage other sources for labelling, such as customer feedback that we get directly from the Identity Protection UX and API, and threat intelligence sources from across Microsoft ecosystem.

All this intelligence is used to automatically train new supervised machine learning models, which are then deployed to the Azure AD authentication service and used to score 30 Billion authentications every day in real-time and taking just a few milliseconds per authentication. The new protection system is ever vigilant, regularly retraining the ML models dynamically adapt to changes in the bad actor ecosystem.

Here’s a look at how the new sign-in risk scoring system works – the classifier scores each login in the core Identity System, and then label data generated in the “Analysis” section is used by the Learner to generate an improved model, then the whole cycle starts again:

We are so excited about the improvement this new system provides and we want to show you the data. You can see Precision-Recall curves for the previous scoring system and the newly improved system in the chart below. Precision indicates the percentage of the sign-ins flagged as risky that are actually bad sign-ins. A recall is a measure of the percentage of all bad sign-ins that are flagged as risky. Each point in each line represents the precision and recall at a specific score. The score is the probability or confidence level that the model has about the sign-in being bad. In summary, the higher the precision and higher the recall, the better the model performs.

This is just one of the exciting new Identity Protection features our team has been working on. Our team continues to work with our customers, partners, and teams across Microsoft to offer customers the best Identity protection systems. If you want to find out more information about how machine learning systems like this works, be sure to check out a recent session from the Ignite conference entitled “The science behind Azure Active Directory Identity Protection”. 

On the behalf of Azure AD team, thank you for all your feedback far. We hope you’ll continue to help us improve and share more about your experience with Azure AD Identity Protection.  And be sure to follow us on Twitter (@AzureAD) to get the latest updates on Identity security.

Maria Puertas Calvo (@Maria_puertas_calvo)

Principal Lead Data Scientist

Microsoft Identity Division