Security

The Security Dojo Podcast

Stefan and I have talked about starting a podcast for a long time and now we have, together with Pierre Thoor, released episode 1 of the Security Dojo.

Our first episode is about the podcast itself and we’re also touching previous and upcoming events.

The plan is to invite guests and talk about news and things we find interesting. We appreciate feedback

You can listen to the pod here

Apple podcast:
https://podcasts.apple.com/us/podcast/security-dojo/id1686552862
Spotify:
https://open.spotify.com/show/52EVzPioqoALzeFyou6mM6

Embedded player (Spotify):

Website:
https://securitydojo.ms
LinkedIn profile:
https://www.linkedin.com/company/security-dojo-podcast

Happy Hunting!

Microsoft Sentinel Parsing tips – Whitespace control

This post will be a part of a multiple posts to cover data parsing in Microsoft Sentinel.

Intro

Kusto is a powerfull query language and easy to adopt.

Even if Kusto is very powerfull, working with custom log sources is, sometimes, a mess. Some parsers requires more effort and some are very simple.

In general, when it’s possible to use operators like “parse” (link) function or “parse-kv” (link) it’s very welcome. However, the reality has a different challenge for us.

In this post we want to share a quick pro tip to solve the mystic of hidden whitespaces

The challenge of whitespaces

Whitespaces ” ” exists everywhere, the challenge is how it’s presented in log analytics.

Log analytics does a lot for the user in terms of nicely present data. It actually removes duplicate whitespaces, as well as leading and trailing whitespace.

This could result in problems like failing parsers, regex and string operators like “==”, “startswith”, “endswith” etc will fail. Especially if it’s not consistent.

Marking the string in the output view does not show the extra whitespaces

Copying the text and paste into a text-editor will not show it either like in below example where we copied the output into VS Code (we can only see one dot to show one whitespace between foo and bar)

However, the double whitespaces are interpreted during execution, and it’s only in the presentation view the extra is removed. As in below example, we used split on ” ” to show the existence of the double whitespace.

When working with multiple log sources you don’t want to search and see if they exist (which may change during the log source life cycle), you rather want a way to always make the log to look good in your parser.

Solution

To properly address this (if there aren’t any good ways to change the audit settings of the system sending the logs)

To handle the duplicate white spaces we use the replace_regex function (link here) and use the whitespace “\s” with the quantifier “+” which means one or multiple times and replace it with a space ” “.

This will search for spaces (one or more) and replace it with a single, because we don’t want to remove single spaces. And by using the same column name “SyslogMessage” we will actually reuse the same column for our clean output.

Please note that this will not change the message in the database, only during execution.

Doing this gives us the following output.

The next step is that we want to remove the leading and trailing whitespaces. If we for instance expect the first character to be a value, the leading whitespace could make our parser to fail or an analytic rule.

We have seen occasions where this happens from time to time and not all messages in a log source.

To fix the leading and trailing whitespaces we use another regex to look for start of string and end of string. But this time we want to replace with “nothing/null” which is why we can’t use this regex in the first cleaning.

In the second run we use the same column name again to cleanup the SyslogMessage. There is a best practice to always keep the original message, however, this is to solve an error from the log source and not to alter the SyslogMessage.

The regex starts with an anchor “^” to define the start of the string and followed by a whitespace “\s” since we cleaned all double whitespaces we don’t need to use the quantifier. To handle the trailing whitespace we use the OR operand “|” and check for a whitespace “\s” followed by the anchor “$” to determine the end of the string. If we get any hits it will be replaced with null and we have a clean string.

By adding these 2 lines of code to the parser, we will avoid running into strange issues which could take some time to troubleshoot.

//Sample
CustomLogSource_CL
| extend SyslogMessage = replace_regex(SyslogMessage,@"\s+",@" ") //Remove duplicate whitespaces
| extend SyslogMessage = replace_regex(SyslogMessage,@"^\s|\s$",@"") //Remove leading and trailing whitespaces

Happy Hunting!

Live response is GA for Linux and macOS

Live response is designed to enhance investigations by enabling your security operations team to collect forensic data, run scripts, send suspicious entities for analysis, remediate threats, and proactively hunt for emerging threats.

Capabilities

  • Run basic and advanced commands to do investigative work on a device.
  • Download files such as malware samples and outcomes of PowerShell scripts.
  • Download files in the background (new!).
  • Upload a PowerShell script or executable to the library and run it on a device from a tenant level.
  • Take or undo remediation actions.

Requirements

  • macOS – Minimum required version: 101.43.84. Supported for Intel-based and ARM-based macOS devices.
  • Linux – Minimum required version: 101.45.13

Happy Hunting

Tamper Protection for Exclusions in Defender

One thing that threat actors commonly do when getting a foothold on a device, is to try to disable Defender services and adding exclusions for their tools which they plan to execute.

For the Defender services, we have had Tamper Protection for some time, but that did not cover exclusions.

Tamper Protection configuration via Intune

Requirements

For Tamper Protection to cover exclusions, the following requirements must be met:

Disable Local Admin Merge

Verifying and troubleshooting

The registry value TPExclusions which is in the HKLM\SOFTWARE\Microsoft\Windows Defender\Features key shows a value of 1 if protected and 0 if not protected. Please note that you cannot change the registry value to protect the exclusions, it’s for information and not configuration

While we talk about Antivirus policies…

We would like to share this as well since it’s something we see when we do Defender assessments, it’s unfortunately very common that these settings are wrong

Cloud block level (high is recommended minimum) and Cloud Extended Timeout check must be set to 50 (seconds)
Sample submission is required for Cloud protection

And for

Happy Hunting!

Taking actions on on-prem accounts with MDI Action Account, troubleshooting

Background

The response action of blocking a compromised account is important to have available. Regardless of solution one must be able to quick and easy be able to block an account.  In MDI (part of Microsoft 365 Defender) it is possible since some time ago to configure an MDI Action Account, lately the option to run with the system account of the Domain Controller has been added to this feature and therefor you don’t have to configure the gMSA account.

Using system or a custom gMSA account

The choice is made based on organizational structure, Tiering/RBAC, MSSP partner. Basically, if you are required to delegate the permissions to only allow actions on accounts in certain OU’s, then you must use a custom gMSA accounts.

For example, if you have a MSSP partner monitoring your security and take actions to discovered threats, a so called MDR (Managed Detection and Response), you have an option to control to which accounts the MSSP can take actions.

The available actions are:

  • Disable user in Active Directory: This will temporarily prevent a user from logging in to the on-premises network. This can help prevent compromised users from moving laterally and attempting to exfiltrate data or further compromise the network.
  • Suspend user in Azure Active Directory: This will temporarily prevent a user from logging in to Azure Active Directory. This can help prevent compromised users from attempting to exfiltrate data and minimizes the time between Disable user in Active Directory and the sync of this status to the cloud.
  • Reset user password – This will prompt the user to change their password on the next logon, ensuring that this account can’t be used for further impersonation attempts.

From an MSSP perspective, this feature is very useful since there wouldn’t require customer access (VPN or other kind of access) to respond to threats. Even though this feature is very popular for MSSPs, you will still want to have this option if you have your internal security operations to be able to respond from the portal you are currently working in.

Even though this feature is very popular for MSSPs

To learn how to create and configure the gMSA account you can start with this link
https://learn.microsoft.com/en-us/defender-for-identity/manage-action-accounts

Troubleshooting

(The troubleshooting path will be updated based on troubleshooting session done with customers)

There 2 primary sources for troubleshooting this, sensor logs and event logs. Preferably the logs are sent to SIEM solution (like Microsoft Sentinel).

Using Sentinel (or look in the event viewer, or if you have another SIEM solution in place).

SecurityEvent | where Account has "gMSA-MDIAction$"

Note the $ character in the account name, gMSA account is more like a computer account. It’s the type of msDS-GroupManagedServiceAccount.

If the account doesn’t have logons ending with a $ (like a computer account), then it’s not a gMSA account and start there by creating a one.

https://learn.microsoft.com/en-us/defender-for-identity/manage-action-accounts

This can also be checked on the logon event (this will trigger 4625, logon failed)

Verify that the AccountType is “Machine”

Successful sign-in:

Account is not allowed to logon as a service

If the gMSA Account is setup and configured correctly and there is still event 4625 being logged.

Check the Status property of the login event

0xc000015b indicates that the account is not allowed to login0xC000015B

STATUS_LOGON_TYPE_NOT_GRANTED, A user has requested a type of logon (for example, interactive or network) that has not been granted. An administrator has control over who can logon interactively and through the network.

More information about the Status property can be found here:

https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55

To address this issue you need to create a new or update existing policy to allow that account to logon as service on the target system (the DCs)

https://learn.microsoft.com/en-us/system-center/scsm/enable-service-log-on-sm?view=sc-sm-2022#enable-service-log-on-through-a-local-group-policy

Successful events effecting the user you try to take action on

The following query will find events of enabling and disabling a user

SecurityEvent
| where EventID in(4738,4725,4722)
| where Account contains "gMSA-mdi-action$"
| where TargetAccount contains "test" //the user you want to take action on
You see 4738 “A user account was changed” at the same timestamp as the 4725 and 4722 and the 4738 event show the UAC 0x10: Account Enabled and 0x11: Account Disabled

https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738

Hope this helps!

We will continue to update this post if we run into other related troubleshootings

//Happy Hunting

New alert suppression configuration

New options with more granular control are available when configuring suppressions

With logical operators like grouping, OR, AND it’s possible to be very granular with the suppressions, which is really critical to avoid suppressing to much.

Always be cautious when adding suppressions

When using the auto-fill rule it will automatically apply all entities from the alert

Resolve or hide an alert

Click Save

Resolving an alert will be handled as a regular resolved alert, meaning ending up in timeline, alerts queue, and APIs

Hiding the alert will cause the alert to be suppressed from the entire system, both on the device’s alerts and from the dashboard and will not be streamed across Defender for Endpoint APIs.

Depending on your scenario it could be important to make the choice to match the scenario you need. Could be related to reporting of total incidents/alerts to customers etc.

Stay safe and Happy Hunting

Defender troubleshooting mode

Troubleshooting mode will make it possible for local admins on the endpoint to override Antivirus policy on the device, including tamper protection. When enabled it give the admin a 3 hour window to do what was intended. After the 3 hour window, the settings will be re-applied again.

Enabling Troubleshooting mode

Go to the Device page in Microsoft 365 Defender and click on the 3 dots menu item and select troubleshooting mode

In the Device action center we can see the following entry

Prerequisites

  • Windows 10 (version 19044.1618 and above)
    Windows 11
    Windows Server 2019
    Windows Server 2022
  • Microsoft Defender for Endpoint must be tenant-enrolled and active on the device. 
  • The device must be actively running Microsoft Defender Antivirus, version 4.18.2203 and above. 

Hunting for events

//Use the following ActionType and the DeviceEvents table
DeviceEvents
| where ActionType == "AntivirusTroubleshootModeEvent"  

Happy Hunting!

Switching tenant in Microsoft 365 Defender

[Updated post]

What’s described in this post is no longer applicable due to TID parameter are added to links in the portal

We developed an extension that does exactly the same thing but this is not needed anymore hence why we won’t release it. Microsoft has updated links in the portal to include the TID-parameter which is awesome and for people working with many customers this is really great news and you don’t need multiple profiles either!

[Old post]

If you work with multiple customers with Microsoft 365 Defender or working in a multi-tenant setup, you have probably noticed that your end up in the first tenant even if changing the tid-parameter in the url.

The reason why this happens is that when for instance, clicking on links in Defender, it will take you to the tenant stored in a cookie, especially if you don’t have the tenant id parameter in the link.

It can be addressed by working with multiple profiles, but if you don’t want that you can just do the following

Open dev tools and go to Application and expand Cookies
Select the security.microsoft.com and right-click on sccauth and select delete

Refresh the page

Happy Hunting!

Tuning insights in Microsoft Sentinel

Fine-tuning the analytic rules to minimizing the number of false-positives can be time-consuming and you still want to keep the high visibility so you don’t want to risk false-negatives. At the same time, the risk of managing a high number of incidents, especially if they are false-positives, would also be time-consuming.

To be able to fine-tune the analytic rules, we need historical data. Same as what was needed when developing the detection in the first place and for fine-tuning we also need decisions made when classifying the incident and if those decisions was related to any specific entities.

Machine Learning to the help

Microsoft Sentinel uses machine learning to analyze signals from the data sources and the responses made to an incident over time to assist and providing data for fine-tuning decisions.

The rules with recommendations for a fine-tune is noted with a light bulb next to the rule name as in below picture.

fine-tuning recommendations
Fine-tuning recommendations available (preview feature)

When editing the analytic rule, in the Rule Logic tab, the Tuning insights is available

There are several panes which can be scrolled through which contains actionable items like exclude accounts, IPs etc. from the analytic rule

The third pane shows the importance of correct mapped entities since this is the only way to get results and shows the four most frequent entities in the alerts generated by the analytic rule.

Hopefully this can share some light on make your work more effective by working with your analytic rules to make your detection better.

Don’t forget to be careful and thing through your exclusions to avoid losing visibility.

For further reading, please visit

https://docs.microsoft.com/en-us/azure/sentinel/detection-tuning

Happy Hunting!

Sec-Labs Team

Take actions from Threat Hunting in M365 Defender

We wrote a blog post earlier about the news in threat hunting

New features in Advanced Hunting – Microsoft 365 Defender – SEC-LABS R&D

Another feature in hunting, which will speed up responses from a threat hunting scenario is Take Action

When selecting a record in the result, the Take Action button will be visible as seen in below picture

take actions, m365 defender

So instead of just creating a new incident or adding events to an existing incident we can take actions from the hunting experience.

In the Take actions experience we have actions grouped by Devices, Files and Users.

actionable items, m365 defender

The action options available is dependent on the data in the result. For instance, file information like checksum is required to being able to quarantine a file.

When clicking Next we can see the target selected and click Next

We can add a Remediation name and Description for our action

This feature enables a rapid response at the fingertips of the threat hunters for immediate actions

For further information, please visit

https://docs.microsoft.com/en-us/microsoft-365/security/defender/advanced-hunting-take-action?view=o365-worldwide

Happy Hunting!

Sec-Labs Team