G
Greg Wiselka
The use of SaaS applications has become widespread in businesses of all sizes. With more SaaS apps in use, there are more potential targets for attackers. They frequently exploit centralized user authentication systems targeting unaware users with phishing attacks. Attackers can take advantage of this lack of awareness to trick users into authorizing malicious apps, steal credentials and gain access to multiple services. Attack techniques are getting more sophisticated and frequent exploits of poorly designed of SaaS applications are on the rise.
In this blog, we'll demonstrate how SOC teams can benefit from App governance and its integration with Advanced Hunting to better secure SaaS apps.
Why use advanced hunting?
Advanced hunting uses a powerful query language called Kusto Query Language (KQL). KQL allows security analysts to create complex queries that can filter, aggregate, and analyze large volumes of data collected from endpoints, such as security events, process data, network activity, and more. However, this can be challenging for new security analysts who may not be familiar with writing queries in KQL. By using the pre-defined KQL queries and app signals collected in Microsoft 365 Defender, security analysts can immediately benefit from hunting capabilities to investigate app alert insights without having to use any KQL.
A real-life example of threat investigation
Let’s investigate a real-life incident triggered by a built-in threat detection policy in App governance. In our case, the “App impersonating a Microsoft logo” alert was triggered. Using our unified XDR platform, Microsoft 365 Defender, a SOC analyst can access all defender alerts in one place via the incidents view. The SOC analyst can filter on status, severity, incident assignment, service sources and other categories. In Figure 1, the Filter Service source = App Governance, Status = New, Severity= High, was applied to help with incident detection and prioritization.
Note: To learn more about App governance built in policies, check out our documentation.
The incident (Figure 1) consists of four alerts that the SOC analyst can review to verify if they are true positives (TP) or false positives (FP) and act accordingly. The SOC analyst can click on the incident and access the attack story (Figure 2), where the alerts can be reviewed in chronological order. They can also view additional information in “What happened” and “Recommended actions” sections which gives the analyst a much better understanding as to why the alert was triggered in the first place with a path forward to remediate.
Let’s learn more about the application, by selecting view app details (Figure 3).
Usually, malicious apps will not have any certification or publisher verification because of the app nature community verification would be rare. The combination of all those attributes (highlighted at Figure 4) raise red flags.
Because the app is registered in Azure AD, the SOC team can easily access additional information available in the Azure portal which may help with providing additional context that may help with the incident resolution.
In Figure 5, we can see why the machine learning algorithm highlighted the app as malicious, the logo impersonates the original Outlook logo, but the publisher domain does not match the Microsoft domain. The SOC analyst can now follow their company guidelines to disable the app (this can be completed directly in AAD or in App governance app details window – Figure 4)
Use of Advanced Hunting as part of incident investigation.
After disabling the malicious app, the SOC analyst should investigate further the app activity by selecting, “View app activities” (option highlighted in Figure 4), which will generate the Query 1 also visible in Figure 6. The results visible in Figure 7&8 will include all graph API activities the app preformed on SharePoint Online, Exchange Online, One Drive for Business and Teams workloads.
Query 1:
// Find all the activities involving the cloud app in last 30 days
let appid = (i : dynamic )
{
case
(
i.Workload == "SharePoint", i.ApplicationId,
i.Workload == "Exchange", iff(isempty(i.ClientAppId), i.AppId, i.ClientAppId),
i.Workload == "OneDrive", i.ApplicationId,
i.Workload == "MicrosoftTeams", i.AppAccessContext.ClientAppId,
"Unknown"
)
};
CloudAppEvents
| where ((RawEventData.Workload == "SharePoint" or RawEventData.Workload == "OneDrive") and (ActionType == "FileUploaded" or ActionType == "FileDownloaded")) or (RawEventData.Workload == "Exchange" and (ActionType == "Send" or ActionType == "MailItemsAccessed")) or (RawEventData.Workload == "MicrosoftTeams" and (ActionType == "MessagesListed" or ActionType == "MessageRead" or ActionType == "MessagesExported" or ActionType == "MessageSent"))
| extend AppId = appid(RawEventData)
| where AppId == "Paste your app Id"
| where Timestamp between (datetime("2023-08-08 00:00:00Z")..30d)
| extend tostring(RawEventData.Id)
| summarize arg_max(Timestamp, *) by RawEventData_Id
| sort by Timestamp desc
| project Timestamp, OAuthApplicationId = AppId, ReportId, AccountId, AccountObjectId, AccountDisplayName, IPAddress, UserAgent, Workload = tostring(RawEventData.Workload), ActionType, SensitivityLabel = tostring(RawEventData.SensitivityLabelId), tostring(RawEventData)
| limit 1000
In the query results, the analyst can see the IP address which could be an indicator of malicious activity, attackers frequently use IP of bad reputation, blacklisted, Tor exit nodes. Analyzing historical data can reveal patterns of malicious behavior associated with specific IP addresses. This can be useful for threat intelligence and proactive threat hunting. The analyst can also see impacted workloads and action types which are crucial for them to understand hacker actions.
By analyzing these actions, security analysts can trace the steps of the attacker to determine the scope of the breach, how the attacker gained access, and what data or systems may have been compromised. MailItemsAccessed action suggests that an unauthorized user or hacker has accessed the contents of one or more email messages within an email account and UpdateInboxRules can be a sign of an attacker attempting to manipulate email traffic by diverting, filtering, or forwarding messages to their advantage.
The analyst may want to create a detection rule (option visible on Figure 6) to proactively identify and alert on similar suspicious activities in the future, which is essential for enhancing an organization's ability to detect and respond to security threats effectively, automate alerts, reduce false positives, and stay ahead of evolving cyber threats. Learn more about custom detections rules and how to create them here.
By selecting one of the records (Figure 8), the SOC analyst can get more information about the impacted user to act accordingly and “stop the bleeding.” They can take immediate action to halt or mitigate the security breach, prevent further access (changing passwords, revoking access privileges or even disabling the compromised account), all result in minimizing the damage. After the bleeding has stopped, the data helps security teams conduct a thorough investigation to determine the root cause of the incident. Understanding how the breach occurred is essential for preventing similar incidents in the future.
The app impersonation security incident shows the benefits of app governance machine learning in detecting malicious applications which offers additional layer of protection for your users and organization. The integration of app governance with advanced hunting capabilities provides SOC teams with the tools and insights needed to proactively detect, respond to, and mitigate security threats in SaaS OAuth applications. It allows for a more comprehensive and data-driven approach to SaaS app security, helping organizations protect their critical data and assets.
Continue reading...
In this blog, we'll demonstrate how SOC teams can benefit from App governance and its integration with Advanced Hunting to better secure SaaS apps.
Why use advanced hunting?
Advanced hunting uses a powerful query language called Kusto Query Language (KQL). KQL allows security analysts to create complex queries that can filter, aggregate, and analyze large volumes of data collected from endpoints, such as security events, process data, network activity, and more. However, this can be challenging for new security analysts who may not be familiar with writing queries in KQL. By using the pre-defined KQL queries and app signals collected in Microsoft 365 Defender, security analysts can immediately benefit from hunting capabilities to investigate app alert insights without having to use any KQL.
A real-life example of threat investigation
Let’s investigate a real-life incident triggered by a built-in threat detection policy in App governance. In our case, the “App impersonating a Microsoft logo” alert was triggered. Using our unified XDR platform, Microsoft 365 Defender, a SOC analyst can access all defender alerts in one place via the incidents view. The SOC analyst can filter on status, severity, incident assignment, service sources and other categories. In Figure 1, the Filter Service source = App Governance, Status = New, Severity= High, was applied to help with incident detection and prioritization.
Note: To learn more about App governance built in policies, check out our documentation.
Figure 1. Selecting incidents.
The incident (Figure 1) consists of four alerts that the SOC analyst can review to verify if they are true positives (TP) or false positives (FP) and act accordingly. The SOC analyst can click on the incident and access the attack story (Figure 2), where the alerts can be reviewed in chronological order. They can also view additional information in “What happened” and “Recommended actions” sections which gives the analyst a much better understanding as to why the alert was triggered in the first place with a path forward to remediate.
Figure 2. Reviewing the attack story.
Let’s learn more about the application, by selecting view app details (Figure 3).
Figure 3. Selecting View app details.
Usually, malicious apps will not have any certification or publisher verification because of the app nature community verification would be rare. The combination of all those attributes (highlighted at Figure 4) raise red flags.
Because the app is registered in Azure AD, the SOC team can easily access additional information available in the Azure portal which may help with providing additional context that may help with the incident resolution.
Figure 4. The malicious O365 Outlook Application card, Highlighted red flags and links to Azure AD and App activities in hunting.
In Figure 5, we can see why the machine learning algorithm highlighted the app as malicious, the logo impersonates the original Outlook logo, but the publisher domain does not match the Microsoft domain. The SOC analyst can now follow their company guidelines to disable the app (this can be completed directly in AAD or in App governance app details window – Figure 4)
Figure 5. View of app details in Azure Portal.
Use of Advanced Hunting as part of incident investigation.
After disabling the malicious app, the SOC analyst should investigate further the app activity by selecting, “View app activities” (option highlighted in Figure 4), which will generate the Query 1 also visible in Figure 6. The results visible in Figure 7&8 will include all graph API activities the app preformed on SharePoint Online, Exchange Online, One Drive for Business and Teams workloads.
Figure 6. Advanced hunting query.
Query 1:
// Find all the activities involving the cloud app in last 30 days
let appid = (i : dynamic )
{
case
(
i.Workload == "SharePoint", i.ApplicationId,
i.Workload == "Exchange", iff(isempty(i.ClientAppId), i.AppId, i.ClientAppId),
i.Workload == "OneDrive", i.ApplicationId,
i.Workload == "MicrosoftTeams", i.AppAccessContext.ClientAppId,
"Unknown"
)
};
CloudAppEvents
| where ((RawEventData.Workload == "SharePoint" or RawEventData.Workload == "OneDrive") and (ActionType == "FileUploaded" or ActionType == "FileDownloaded")) or (RawEventData.Workload == "Exchange" and (ActionType == "Send" or ActionType == "MailItemsAccessed")) or (RawEventData.Workload == "MicrosoftTeams" and (ActionType == "MessagesListed" or ActionType == "MessageRead" or ActionType == "MessagesExported" or ActionType == "MessageSent"))
| extend AppId = appid(RawEventData)
| where AppId == "Paste your app Id"
| where Timestamp between (datetime("2023-08-08 00:00:00Z")..30d)
| extend tostring(RawEventData.Id)
| summarize arg_max(Timestamp, *) by RawEventData_Id
| sort by Timestamp desc
| project Timestamp, OAuthApplicationId = AppId, ReportId, AccountId, AccountObjectId, AccountDisplayName, IPAddress, UserAgent, Workload = tostring(RawEventData.Workload), ActionType, SensitivityLabel = tostring(RawEventData.SensitivityLabelId), tostring(RawEventData)
| limit 1000
In the query results, the analyst can see the IP address which could be an indicator of malicious activity, attackers frequently use IP of bad reputation, blacklisted, Tor exit nodes. Analyzing historical data can reveal patterns of malicious behavior associated with specific IP addresses. This can be useful for threat intelligence and proactive threat hunting. The analyst can also see impacted workloads and action types which are crucial for them to understand hacker actions.
By analyzing these actions, security analysts can trace the steps of the attacker to determine the scope of the breach, how the attacker gained access, and what data or systems may have been compromised. MailItemsAccessed action suggests that an unauthorized user or hacker has accessed the contents of one or more email messages within an email account and UpdateInboxRules can be a sign of an attacker attempting to manipulate email traffic by diverting, filtering, or forwarding messages to their advantage.
Figure 7. Advanced hunting query results.
The analyst may want to create a detection rule (option visible on Figure 6) to proactively identify and alert on similar suspicious activities in the future, which is essential for enhancing an organization's ability to detect and respond to security threats effectively, automate alerts, reduce false positives, and stay ahead of evolving cyber threats. Learn more about custom detections rules and how to create them here.
By selecting one of the records (Figure 8), the SOC analyst can get more information about the impacted user to act accordingly and “stop the bleeding.” They can take immediate action to halt or mitigate the security breach, prevent further access (changing passwords, revoking access privileges or even disabling the compromised account), all result in minimizing the damage. After the bleeding has stopped, the data helps security teams conduct a thorough investigation to determine the root cause of the incident. Understanding how the breach occurred is essential for preventing similar incidents in the future.
Figure 8. Advanced hunting inspected record details.
The app impersonation security incident shows the benefits of app governance machine learning in detecting malicious applications which offers additional layer of protection for your users and organization. The integration of app governance with advanced hunting capabilities provides SOC teams with the tools and insights needed to proactively detect, respond to, and mitigate security threats in SaaS OAuth applications. It allows for a more comprehensive and data-driven approach to SaaS app security, helping organizations protect their critical data and assets.
Continue reading...