Protect

Antivirus exclusions and ASR

From working with customers we commonly get questions about exclusions for ASR and the impact of the exclusions or when it will work or not.

Indicators in MDE does work for ASR, but not all Indicator types. Defender Antimalware exclusions does work for ASR, but not all rules honor the exclusions. Here are a few tables from learn which can help you with this:

Rules which does not honor Defender Antivirus exclusions

  • Block Adobe Reader from creating child processes
  • Block process creations originating from PSExec and WMI commands
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block Office applications from creating executable content
  • Block Office applications from injecting code into other processes
  • Block Office communication application from creating child processes

Rules which does not honor Defender for Endpoint (MDE) Indicators of type Certificate

  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block Office applications from injecting code into other processes
  • Block Win32 API calls from Office macros

For further information about attack surface reduction, please visit https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction

Happy Hunting!

New ASR Rules available

There 2 new ASR (Attack Surface Reduction Rules) available.

Attack Surface Reduction Rules is a Defender feature which, as it sounds, reduces attack surface on endpoints. This is done by blocking certain attack surfaces like “Block all Office applications from creating child processes”, “Block untrusted and unsigned processes that run from USB” and more, there are 19 rules available today. Two of which are in preview.

The great thing about ASR is that it closes some attack paths, instead of relying on Antivirus or EDR to detect on the malicious code or behavior since these changes all the time.

The new rules:

Block rebooting machine in Safe Mode (preview)

GUID: 33ddedf1-c6e0-47cb-833e-de6133960387

This rule prevents the execution of commands to restart machines in Safe Mode.

Safe Mode is a diagnostic mode that only loads the essential files and drivers needed for Windows to run. However, in Safe Mode, many security products are either disabled or operate in a limited capacity, which allows attackers to further launch tampering commands, or simply execute and encrypt all files on the machine. This rule blocks such attacks by preventing processes from restarting machines in Safe Mode.

Block use of copied or impersonated system tools (preview)

GUID: c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb

his rule blocks the use of executable files that are identified as copies of Windows system tools. These files are either duplicates or impostors of the original system tools.

Some malicious programs may try to copy or impersonate Windows system tools to avoid detection or gain privileges. Allowing such executable files can lead to potential attacks. This rule prevents propagation and execution of such duplicates and imposters of the system tools on Windows machines.

Please note that since these 2 new rules are in preview, additional upgrades to improve efficacy are under development

Happy Hunting!

Attack Simulation Training to be resilient against QR code phishing

QR code has been a hassle in the cyber world since a while back. There are multiple reasons for threat actors to use this method to phish uses and compromise accounts.

One reason is that it is difficult to detect (the MDO research team has done a great job in detecting these, huge kudos to you!) the other reason is that we force the user to move to another device. If they read the email on their monitored laptop, and then scan the QR with the phone it is more difficult to detect, and not all organizations have onboarded their phone to Defender.

Microsoft announced last month about partnership with Fortra’s Terranova Security and have launched two new QR code phishing training modules available in Attack Simulation Training. THis will provide a training email for the end-user which explains the QR code technique

How to launch a simulation with QR code

Go to Defender XDR portal and in the Email & Collaboration you select Attack simulation training

Select Launch a simulation and follow the wizard

Select the How-to Guide

Select payload Teching Guide: How to recognize and report QR phishing messages

Choose your targets

If required, exclude users

Configure your launch details

Monitor

Don’t forget to follow up your simulations with user awareness training to establish a cyber security culture

Happy Hunting!

3 common Defender for Endpoint configuration errors

Both Stefan and Mattias from the Sec-Labs team, have conducted numerous Defender for Endpoint health checks. Apart from other configuration errors, three settings are frequently misconfigured, affecting overall security.

When we discussed this, we realized we should probably write a full configuration recommendation. But let’s start with these 3 settings that are related to each other

Number one – Cloud Protection turned off or not correct cloud block protection

Cloud protection extends the threat detection capabilities in the antimalware engine and is used to enhance real-time protection with the strength of cloud. It’s a common observation in the health checks that this is turned off or not configured to block at the correct level.

The following table contains information about the components in cloud protection and comes from an older blog from Microsoft https://www.microsoft.com/en-us/security/blog/2019/06/24/inside-out-get-to-know-the-advanced-technologies-at-the-core-of-microsoft-defender-atp-next-generation-protection/

FeatureDescription
Cloud-side
Metadata-based ML engineSpecialized ML models, which include file type-specific models, feature-specific models, and adversary-hardened monotonic models, analyze a featurized description of suspicious files sent by the client. Stacked ensemble classifiers combine results from these models to make a real-time verdict to allow or block files pre-execution.
Behavior-based ML engineSuspicious behavior sequences and advanced attack techniques are monitored on the client as triggers to analyze the process tree behavior using real-time cloud ML models. Monitored attack techniques span the attack chain, from exploits, elevation, and persistence all the way through to lateral movement and exfiltration.
AMSI-paired ML enginePairs of client-side and cloud-side models perform advanced analysis of scripting behavior pre- and post-execution to catch advanced threats like fileless and in-memory attacks. These models include a pair of models for each of the scripting engines covered, including PowerShell, JavaScript, VBScript, and Office VBA macros. Integrations include both dynamic content calls and/or behavior instrumentation on the scripting engines.
File classification ML engineMulti-class, deep neural network classifiers examine full file contents, provides an additional layer of defense against attacks that require additional analysis. Suspicious files are held from running and submitted to the cloud protection service for classification. Within seconds, full-content deep learning models produce a classification and reply to the client to allow or block the file.
Detonation-based ML engineSuspicious files are detonated in a sandbox. Deep learning classifiers analyze the observed behaviors to block attacks.
Reputation ML engineDomain-expert reputation sources and models from across Microsoft are queried to block threats that are linked to malicious or suspicious URLs, domains, emails, and files. Sources include Windows Defender SmartScreen for URL reputation models and Office 365 ATP for email attachment expert knowledge, among other Microsoft services through the Microsoft Intelligent Security Graph.
Smart rules engineExpert-written smart rules identify threats based on researcher expertise and collective knowledge of threats.
Client-side
ML engineA set of light-weight machine learning models make a verdict within milliseconds. These include specialized models and features that are built for specific file types commonly abused by attackers. Examples include models built for portable executable (PE) files, PowerShell, Office macros, JavaScript, PDF files, and more.
Behavior monitoring engineThe behavior monitoring engine monitors for potential attacks post-execution. It observes process behaviors, including behavior sequence at runtime, to identify and block certain types of activities based on predetermined rules.
Memory scanning engineThis engine scans the memory space used by a running process to expose malicious behavior that may be hiding through code obfuscation.
AMSI integration engineDeep in-app integration engine enables detection of fileless and in-memory attacks through Antimalware Scan Interface (AMSI), defeating code obfuscation. This integration blocks malicious behavior of scripts client-side.
Heuristics engineHeuristic rules identify file characteristics that have similarities with known malicious characteristics to catch new threats or modified versions of known threats.
Emulation engineThe emulation engine dynamically unpacks malware and examines how they would behave at runtime. The dynamic emulation of the content and scanning both the behavior during emulation and the memory content at the end of emulation defeat malware packers and expose the behavior of polymorphic malware.
Network engineNetwork activities are inspected to identify and stop malicious activities from threats.

When it’s configured (which is normally default, but should be verified that no policy is actually disabling it) the cloud block level must be configured.

The following blocking levels are available:

SettingDetails
Default blocking levelprovides strong detection without increasing the risk of detecting legitimate files
Moderate blocking levelprovides moderate only for high confidence detections
High blocking levelapplies a strong level of detection while optimizing client performance (but can also give you a greater chance of false positives)
High + blocking levelapplies extra protection measures (might affect client performance and increase your chance of false positives)
Zero toleranceblocking level blocks all unknown executables

It is recommended to at least be on the High blocking level

For more information about cloud block level and how to configure it, please visit https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/specify-cloud-protection-level-microsoft-defender-antivirus

As shown in below picture, the cloud protection feature is really important

More information about Cloud protection is available here: https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/cloud-protection-microsoft-defender-antivirus

Number two – Sample submission

If a suspicious is detected and depending on setting, a sample is sent to the cloud service for analysis while Microsoft Defender Antivirus blocks the file. As soon as a determination is made, the file is either released or blocked by the AV.

How does this process work? Cloud protection and sample submission at Microsoft Defender Antivirus | Microsoft Learn

  1. Client-based machine-learning models, blocking new and unknown malware.
  2. Local behavioral analysis, analyze and stopping file-based and file-less attacks.
  3. Antivirus, detecting common malware through generic and heuristic techniques.
  4. Cloud-based protection is provided for cases when Antivirus running on the endpoint needs more intelligence to verify the intent of a suspicious file
  5. file metadata is sent to the cloud protection service. Often within milliseconds, the cloud protection service can determine based on the metadata as to whether the file is malicious or not a threat.
  6. The cloud query of file metadata can be a result of behavior, mark of the web, or other characteristics where a clear verdict isn’t determined.
  7. A small metadata payload is sent, with the goal of reaching a verdict of malware or not a threat. The metadata doesn’t include personally identifiable information (PII). Information such as filenames, are hashed.
  8. Can be synchronous or asynchronous. For synchronous, the file won’t open until the cloud renders a verdict. For asynchronous, the file opens while cloud protection performs its analysis.
  9. Metadata can include PE attributes, static file attributes, dynamic and contextual attributes, and more

For the settings…

The Sample submission has 4 different settings. In the health checks, a common observation is that it is disabled (do not send) or always prompt.

For cloud protection to work properly, it must be configured to Send all Samples automatically or (at least) Send safe samples automatically.

To stress further, you will not have full protection if this is configured in the wrong way!

Se below for details.

  1. After examining the metadata, if Microsoft Defender Antivirus cloud protection can’t reach a conclusive verdict, it can request a sample of the file for further inspection. This request honors the settings configuration for sample submission:
    1. Send safe samples automatically
      • Safe samples are samples considered to not commonly contain PII data like: .bat, .scr, .dll, .exe.
      • If file is likely to contain PII, the user gets a request to allow file sample submission.
      • This option is the default on Windows, macOS, and Linux.
    2. Always Prompt
      • If configured, the user is always prompted for consent before file submission
      • This setting isn’t available in macOS and Linux cloud protection
    3. Send all samples automatically
      • If configured, all samples are sent automatically
      • If you would like sample submission to include macros embedded in Word docs, you must choose “Send all samples automatically”
      • This setting isn’t available on macOS cloud protection
    4. Do not send
      • Prevents “block at first sight” based on file sample analysis
      • “Don’t send” is the equivalent to the “Disabled” setting in macOS policy and “None” setting in Linux policy.
      • Metadata is sent for detections even when sample submission is disabled
  2. After files are submitted to cloud protection, the submitted files can be scanneddetonated, and processed through big data analysis machine-learning models to reach a verdict. Turning off cloud-delivered protection limits analysis to only what the client can provide through local machine-learning models, and similar functions.

Number 3 – Extended cloud block timeout

The last feature in this post, is the extended cloud block timeout.

If you read the whole post, you have probably noticed that all these 3 features should be configured together since they depend on each other to better protect the endpoint.

While the cloud protection is analyzing the file that was found suspicious, antivirus can block the file from running. As default, it will prevent the file from running for 10 seconds but this can be configured to up to 50 seconds (plus the 10 default seconds) to allow cloud protection to do more analysis like detonation before the file is released.

This happens on suspicious files, and should not have impact on end users!

Block at first sight and its prerequisites must be enabled before you can specify an extended timeout period.

https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/configure-cloud-block-timeout-period-microsoft-defender-antivirus

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!

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

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!

New features in Advanced Hunting – Microsoft 365 Defender

During Ignite, Microsoft has announced a new set of features in the Advanced Hunting in Microsoft 365 Defender.

These features will definitely help you in the Threat Hunting process and also reduce the gap between analysts, responders and threat hunters and simplify the life of a threat hunter.

Multi-tab support

When having hunting training classes, I usually recommend to use multiple browser tabs. One for the query development, and one used to go back to previous queries to see how some things were done earlier.

for example, if you are developing a hunting query and need an if statement, external data, regex or other more advanced features it is easier to just open a previous query to see how it was solved last time. At least until you get more fluent in KQL. This is to avoid having to save your new query, go back to the old one, and then back to the new again

With the multi-tab support we can open the query in a new tab

Resource usage

The new Hunting Page will now provide the resource usage for the query both timing and an indicator of the resource usage

This will make it easy to see when query optimization is recommended and needed.
You could for example use equals, has instead of contains, remove columns not used to reduce the dataset etc. Of course, when it’s feasible.

If you would like to learn more about how to optimize queries, please visit:

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

UX

Schema, Functions, Queries and Detection Rules have been separated into tabs for, according to my opinion, easier access and pivoting which will give a better overview in each tab.

Schema Reference

The schema reference will open as a side pane




When looking at one of the *events tables, the ActionType column is very useful to see which events are being logged.
Earlier, I usually selected distinct ActionType in the query to have a look at the events being logged. Now, it’s possible to use the quick access from the portal to expand all action types for a specific table.

Above image shows the action types for DeviceFileEvents. In the DeviceEvents there are around 180 different action types to query.

For the hunting query development and hunting use-cases, the action types is a great go-to resource.

The columns in the schema reference is clickable and can in a simple way be added to the query

Simple query management

Inspect record

The inspect record pane is an easy way to see the data for one single row. When developing new queries I usually take a subset of data (take/limit 20) to see an overview of the results, and also select an event to see all data instead of side scrolling through all columns when needed.

New features in inspect record is that we can do quick filters which will be added to the query.

In this example we would like to know more about process executions from the C:\AttackTools folder

If we would like other pre-defined FolderPath filters, we can select View more filters for FolderPath
We can continue the query development and as in below example, get the count for each file in the folder specified in the query.

Last but definitely not leastLink the query results to an incident

This is my favorite, this will reduce the gap and simplify the process between threat hunters, responders, and analysts.

By selecting the relevant events in the result, they can be added to an existing incident, or create a new incidents.

This feature will help organizations to define the threat hunting both in a proactive hunting scenario, and in a reactive, post breach scenario when the hunters will assist analysts and responder with a simplified process.

How to link the data to an incident

To be able to link the data you need to have the following columns in the output

  • Timestamp
  • DeviceId/AccountObjectID/AccountSid/RecipientEmailAddress (Depending on query table)
  • ReportId

Develop and run the query

Please note, you cannot have multiple queries in the query window when linking to incident

Choose to create a new incident or link to an existing

Add the necessary details and click next
Select the impacted entities
After finishing the wizard, the data will end up in a new alert in the incident

Last tip

Run a quick check in your environment to see if you have remote internet-based logon attempts on your devices by looking for RemoteIPType == “Public”. There are other where RemoteIPType is useful, like processes communicating with Internet.

Happy Hunting!