Protect – SEC-LABS R&D

Automated attack disruption of Ransomware and BEC – public preview

SEC-LABS R&D 2023-03-20 0 Comments

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:

Disable user – If MDI is in place, it will trigger a Suspend Account which will suspend the user in AD and AAD
Remediation actions – Microsoft Defender for Identity | Microsoft Learn
Device containment, MDE onboarded devices will automatically be prevented from communicating with the compromised device

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!

Detect, Protect, Respond

automated attack disruption, Automation, BEC, Human-operated ransomware, Microsoft 365 Defender

Tamper Protection for Exclusions in Defender

SEC-LABS R&D 2023-02-04 0 Comments

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:

Devices are running Windows Defender platform 4.18.2211.5 or later
- Use Advanced Hunting or the following report to see the status of version
  https://security.microsoft.com/devicehealth?viewid=oldavhealthreport
DisableLocalAdminMerge is enabled
- https://learn.microsoft.com/en-us/windows/client-management/mdm/defender-csp
Tamper protection is deployed through Intune, and devices are managed by Intune only
Microsoft Defender Antivirus exclusions are managed in Microsoft Intune
Functionality to protect Microsoft Defender Antivirus exclusions is enabled on devices
- https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/manage-tamper-protection-intune?view=o365-worldwide#how-to-determine-whether-antivirus-exclusions-are-tamper-protected-on-a-windows-device

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!

Detect, Protect, Security

Defender, Exclusions, MDE, Tamper protection

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

SEC-LABS R&D 2023-01-11 0 Comments

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

Detect, Identify, Protect, Security

gMSA, MDI, Microsoft 365 Defender, Troubleshooting

Containing unmanaged Devices in Defender

SEC-LABS R&D 2022-06-20 0 Comments

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.

Detect, Protect, Respond

Contain device, Defender for Endpoint, Isolate device, MDE, Microsoft 365 Defender, Network Discovery

Defender troubleshooting mode

SEC-LABS R&D 2022-05-28 0 Comments

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!

Detect, Protect, Respond, Security

MDE, Tamper protection, troubleshooting mode

New features in Advanced Hunting – Microsoft 365 Defender

SEC-LABS R&D 2021-11-04 0 Comments

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 least… Link 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

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!

Detect, Protect, Respond, Security

M365D, MDE, Microsoft365Defender, ThreatHunting, XDR

Application Consent – Protect Detect and Respond

SEC-LABS R&D 2020-07-09 0 Comments

As companies raise their bars and protect more and more accounts with Multi-factor Authentication the attacks are twisting with new angles. The method of using Application Consent is nothing new but attackers haven’t had a need to use it as a stolen password is normally less friction.

So what is Application Consent, Application consent is a way to grant permissions to Applications to access your data that they need to perform their specific Task. An example could be a be a Travel App that needs to read your Travel itinerary so that it can automatically update your Calendar with Flight Data or other information.

I am sure everyone has seen a App Consent Screen

Kevin Mitnick did a malicious Ransomware PoC roughly with Application Consent two years ago around this, feel free to watch the demo on the youtube link.

Application Control Protect

The first thing you should ask your selves, do you allow your users to Grant Permissions themselves of their data or have you as an organization centrally taken this control?

The settings can be configured under your Azure Active Directory

First off can your users Register Applications themselves or is this under central control?

AAD > User Settings > Enterprise Applications

So if you do not allow this the users would never be able to allow an App consent either, but if you do you can control how much data they can share and under what circumstances, you will find a few options in the detailed settings below.

AAD > Enterprise Applications > User Settings

AAD > Enterprise Applications > Consent and Permissions > User Consent Settings (Preview at the time of writing)

Do not allow user consent
Allow user consent for apps from verified publishers
Allow user consent for Apps

Allowing users to allow Apps will put you at risk as they can be lured into accepting an Application Consent. This is not only sensitive from a Security Threat perspective, but also from a privacy / secrecy perspective where third party apps malicious or not are for an example being granted access to PII or Customer Data.

Here you need to find the balance between control and risk on how much you can detect. With the “Allow user consent for apps from verified publishers” you also have the option to control what data and methods are being granted as well. Not that the offline_access is something you need to review thoroughly as that opens up your exposure.

Another possibility that exists is also to user a Admin Consent Requests, in this case a User can request a consent that an Admin will have to review and approve or deny.

AAD > Enterprise Applications > User Settings

Application Control Detection

There are a few ways to see and detect Application Consent, either you create a manual process to review this on a schedule or you use the tools you have at hand. Some examples on what you can use below depending on how you are licensed and how you have integrated Logs.

Manually in Azure AD Portal
Powershell to extract data
Microsoft Cloud App Security
Azure Sentinel
Alerts in Office 365 Audit Log
3rd Party SIEM

If you have integrated Office 365 Logs to Azure Sentinel this is an example query to find application consent activity.

AuditLogs 
| where OperationName == "Consent to application"
| extend displayName_ = tostring(TargetResources[0].displayName)
| extend userPrincipalName_ = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| project displayName_, userPrincipalName_, ActivityDateTime

Application Control Respond

So what can you do if you find Applications that you suspect are doing malicious activities or is putting your data at risk.

You have a few options, start with documenting and putting a timeline with all the activities you are taking, its easy to forget when you need to go back in time.

Block Sign-in to Application
Remove Users from the Application
Remove the Application Completely
Ban/Block Application in MCAS
Review Permissions under the App in AAD

I wouldn’t recommend removing the app until your investigations is complete, id rather block the Login. Depending on that tools you have you can start going through your audit logs in relation to this app.

More Reading

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/manage-consent-requests

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide

Detect, Protect, Respond

24/7 protection during Covid-19 – Defender ATP Auto IR

SEC-LABS R&D 2020-05-14 0 Comments

One thing we usually discuss with customers is the workload. Everyone has too much to do and it can, sometimes be difficult to prioritize investigations.

Especially now, where you might be short on staff, and the Covid-19 virus can strike at the SOC organization or reduce the numbers of available people.

Of course, this does not only apply during the world crisis of Covid-19. Automation is also a help in the normal day to day work.

There are benefits of being able to automate responses and we have these discussions with many customers.

MDATP Automatic self-healing is built-in into Defender ATP and is mimicking these ideal steps a human would take to investigate and remediate organizational assets, impacted by a cyber threat.

This is done using 20 built-in investigation playbooks and 10 remediation actions

Increased Capacity

Respond at the speed of automation
Investigate and remediate all alerts automatically
Free up critical resources to work on strategic initiatives

Cost implications

It will drive down the cost per investigation and remediation
Takes away manual, repetitive tasks
Automated remediation eliminates downtime

Get full value of your protection suite and people, quick configuration and you are up and running

SecOps Investigation (Manual)

Sometimes it will take some time from the alert being triggered until someone has the time to start looking at it. Manual work also requires more resources for review and approval for each action

From a SecOPs perspective, an initial response involves information gathering.

Collecting:

Process list
Services
Drivers
Network connections
Files created
1. Where did the file originate from?
1. etc

Based on our results, we will decide the remediation steps (if we do not follow a playbook here, the catch will be different result depending on who makes the response).

Remediation:

The remediation will include connecting remotely or manually collect the device and then launch tools for the remediation process.

Automatic response with Auto IR

Fast time to respond which will avoid additional damage and compromise of additional devices, when attackers will start moving lateral in the environment.

It’s our 24/7 buddy who assists the SOC staff to remediate threats so the human staff can focus on other things

MDATP is sending telemetry data to the cloud
MDATP cloud continuously analyzes the data to detect threats
Once a threat is identitfied an alert is being raised
The alert kicks off a new automated investigation
AIRS component asks Sense client to initiate SenseIR
SenseIR is then orchestrated by AIRS on what action should be executed (Collection/Remediation)
Based on the data collected from the machine (current and historical) AIRS decides what actions should be taken
For every threat identified, AIRS will automatically analyze the best course of action and tailor a dedicated surgical remediation action to be executed using on device components (e.g. Windows Defender Antivirus)

Playbook is executed

“suspicious host” playbook is just an example of “catch all” playbook that is applied after detailed AutoIR investigation for evidences raised by alerts / incident to ensure that nothing is missed.

Data Collection

Volatile data
- All processes list – main image, loaded modules, handles, suspicious memory sections
- All services list
- All drivers list
- All connections
None-Volatile data
- Recently created files – x minutes febore / after alert
- All persistence methods
- Recently executed files
- Download location

Incrimination

Microsoft Security Graph eco system – DaaS, AVaaS, TI, TA, Detection engine, ML infrastructure etc.
Custom TI indicators – for allow / block list

Remediation

How?
- By leveraging OS components (e.g. Defender Antivirus) to perform the remediation (prebuilt into the system, low level actions (driver), tried and tested)
What?
- File actions
- Process actions
- Service actions
- Registry actions
- Driver actions
- Persistency methods (Reg, Link files, etc.) actions
- Scheduled task actions
- More…

Getting started

Go to the MDATP portal (https://securitycenter.windows.com)
Click settings and then Advanced features
Turn on Automated Investigation and Automatically resolve alerts

In machine groups select Add machine group

As you can see in the options, you can select different AutoIR levels

Summary

Go auto approval, save time and protect your business!

Happy Hunting

Detect, Protect, Respond, Security

AutoIR, Automation, DefenderATP, SOAR

Windows Defender Tamper Protection with Intune / MEM

SEC-LABS R&D 2020-03-28 0 Comments

As we have been reading about many of the advanced threats we see today do try to turn off and tamper with protections that are active on our endpoints.

With Windows Defender you have the option to enable Tamper Protection to make your Windows Defender configuration more safe.

With the protection the client is safeguarded from attempts to disable

Virus and Threat Protection and IOAV
Real-time Protection
Cloud-delivered protection
Behavior monitoring
Removal of Security Intelligence Updates

Of course you should not run as local admin as you expose your machine to other risks but this protection helps in some of those scenarios, there are of course other means an attacker can circumvent being detected and that why we strongly recommend adding EDR capabilities to your endpoint security strategy.

To turn this on you simply make sure your machines are managed

You can find the setting under Windows 10 and later > Endpoint Protection and Category > Microsoft Defender Security Center > Tamper Protection

Once you have enabled Tamper Protection assign it to your Endpoints.

On the endpoint you should be able to see that Tamper Protection is turned on in the Windows Security Center

If you are running a early version of Windows 10 you need to have atleast 1709 for this to work and for 1709-1809 you will not see this in the Security Center and need to verify this with powershell and look for the value “isTamperProtected” set to True