Latest Posts

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!

Automated attack disruption of Ransomware and BEC – public preview

Automated attack disruption of Ransomware and BEC (Business email compromise uses high-confidence Extended Detection and Response (XDR) signals across all workloads; endpoints, identities, email, and SaaS apps, to contain the threat quickly and effectively, to stop further impact.

These 2 scenarios are common attacks and it’s really great that they are supported by the feature in Microsoft 365 Defender.

Business Email Compromise, BEC

Threat actors are impersonating executives to trick, for example, Economic department to transfer money by impersonating the CFO or the CEO.

Automatic attack disruption can help to detect these attacks and remove the access to the accounts by disabling the compromised account, limiting their ability to send fraudulent email

Human-operated ransomware, HumOR

This attack, commonly used today, is devastating for an organization. The threat actors has full control of the environment and have usually controlled the environment for some time.

The challenge from a SecOps perspective is to be fast enough to respond to the incidents and mitigate accounts and the devices fast enough.

When the threat actors has gained privileged access, things move very quick and automatic attack disruption will contain the spreader device and disable the compromised user account

Automatic attack disruption operates in 3 key stages

  • Detect malicious activity and establish high confidence
  • Classification of scenarios and identification of assets controlled by the attacker
  • Trigger automatic response actions using the Microsoft 365 Defender protection stack to contain the active attack

First the detection will happen, which is achieved by AI, research-information etc.., to establish a high level of confidence in accurately detecting ransomware spread and encryption activity. The XDR-level capability correlates insights across endpoints, identities, email and SaaS apps to establish high-fidelity alerts.

A second stage will aggregate automatic analyze the activities like tampering, backup deletion, credential theft, mass lateral movement and many more to flag the assets included in the chain and trace the activities back to the remote execution TTP

Distrupting the attack

Response actions against the entities which are identified as compromised and in the public preview these two are the main actions:

When this happens, it will be visible in the:

Incident queue

  • A tag titled “Attack Disruption” next to affected incidents

If you really must exclude some user from the automatic attack disruption, then you can do it in the MDI settings

Incident page

  • A tag titled “Attack Disruption”.
  • A yellow banner at the top of the page that highlights the automatic action taken.
  • The current asset status is shown in the incident graph if an action is done on an asset, e.g., account disabled or device contained.

Some thoughts

It’s important that prerequisites are fixed, like MDI Action Account (if not using built-in system account) and

For further reading, please visit
Automatic attack disruption in Microsoft 365 Defender | Microsoft Learn

Stay safe, Protect the world and Happy Hunting!

Near Real Time Rules in Defender

If you want to find threats earlier it is now possible to use NRT rules in Defender.

Before this, we had the options to use 24h, 12h, 3h, and 1h as the schedule. This gives Defenders the possibility to detect and respond to threat much earlier.


Tables that support Continuous (NRT) frequency

  • AlertEvidence
  • DeviceEvents
  • DeviceFileCertificateInfo
  • DeviceFileEvents
  • DeviceImageLoadEvents
  • DeviceLogonEvents
  • DeviceNetworkEvents
  • DeviceNetworkInfo
  • DeviceInfo
  • DeviceProcessEvents
  • DeviceRegistryEvents
  • EmailAttachmentInfo
  • EmailEvents
  • EmailPostDeliveryEvents
  • EmailUrlInfo
  • UrlClickEvents

The NRT rules does not support externaldata operator and you can only query one table

Configuring NRT (Continuous) Rule

From the Advanced Hunting, develop your query and click and configure the Alert Details

Click Next and select impacted entities (in this case we are using an email table and therefore the impacted entities will be mailbox)
Click Next and configure the actions.
It’s important to think about what the actions means and make sure your query will detect exactly what you want.

Be cautious with the Isolate device when querying Device tables. If you have an error in your detection you may isolate all machines by mistake

It’s now completed!

Don’t forget that you can use the hunting if you want to take response actions on multiple entities very quickly.

From the Result of your hunting query, select the rows where you want to take action and click Take Actions

This brings your the Actions pane and you can choose which actions you need.

Depending on your query (which tables and output) you get different options for your actions. ‘

Stay safe, and 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

Containing unmanaged Devices in Defender

For a long time we have been able to isolate onboarded devices in Microsoft Defender for Endpoint. But if a device is not onboarded we could not take any response actions to an eventual threat.

Microsoft has released a feature called Contain device which basically makes the opposite, instead of isolating the compromised device, we can tell all managed devices that they cannot communicate with the specific unmanaged device.

If a contained device changes IP address, the blocking will be updated and changed to the new IP address and the old will be “released” from block.

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!