Detect

Assigning severity to incidents and other features are now GA

The speed of how new useful functionalities in Microsoft Defender XDR, previously Microsoft 365 Defender, are being developed is very high. From this perspective it is super important to send feedback, not only things that may not work as you expected or if there is an error, but also new feature requests.

Some new features which was released in GA in February is within the incident management space.

Change incident severity

When a incident is being generated, the severity is based on the alert with highest severity. If the severity is wrong, you can change it by opening the manage incident which will open the incident pane.

Assign incident to a group

Instead of only assign the incident to a specific individual (who might be on a leave), it is now possible to assign the incident to a group by opening the manage incident which will open the incident pane.

Go hunt directly from attack story

When selecting an item in the attack story, you will get an option for “Go Hunt” which will give you the options to choose between All activities, Related alerts and See all available queries

When selecting a query, you will have the response in the same window. The positive thing with this is that you don’t have to move away from the incident view. If you want to continue the hunting you have the option to “Open in advanced hunting”

Happy Hunting!

Microsoft Defender XDR Deceptions Feature

Last year Microsoft announced a deception capability in Microsoft Defender for Endpoint. The idea with the deception is that adversaries access a Decoys or Lure which will trigger an incident for the response team to act on.

In Settings > Endpoints > Advanced features

Enable Deception

To create Deception rules

In Settings > Endpoints > Deception rules

It is possible to scope this specific deception rule to Devices with a specific tag

The system will automatically generate Alias or Hostnames which can be edited to better fit your organization

Lures can be autogenerated or use custom lures (file size up to 10MB)

A Lure can be of any filetype except PE files (exe and dll)
It is recommended that the lure contains information of decoys.

Happy Hunting!

Quick tip – Country Codes

All countries has an ISO code, described in ISO 3166 is an international standard.
These codes are used throughout the IT industry by computer systems and software to make it easier to identify a country.

It has multiple formats and they country codes are presented in the following formats: Alpha-2 (2 characters), Alpha-3 (3 characters) and Numeric (3 digits).

In the data from some logs like SigninLogs and IdentityLogonEvents the country is presented as Alpha-2. We realized pretty quick is that some 2-characters country codes are difficult to remember. As in below, picture it could be difficult to know all these countries.

We have been using this for a long time and thought it might be something others can use as well.

So to solve this I created a csv file and placed on github:

https://raw.githubusercontent.com/mattiasborg82/Hunting/main/General/cc.txt

To be able to join our data with this file we can use the external data operator in Kusto

Since it’s a CSV file, we can make it more usable by split the rows on comma

To to build the full use-case for this, we join it with our SigninLogs (or other logs that uses the country code)

Copy friendly code

let CountryCodes = externaldata (CountryCode:string)
[
 @"https://raw.githubusercontent.com/mattiasborg82/Hunting/main/General/cc.txt"
]
with(ignoreFirstRecord=true);
SigninLogs
| where isnotempty(Location)
| join kind=leftouter (
    CountryCodes
    | extend Country = tostring(split(CountryCode, ",")[0]),
              Location = tostring(split(CountryCode, ",")[1])
    | project-away CountryCode)
on Location
| summarize count() by Country,UserDisplayName

This can be used further to combine with conditional access blocks showing potential credential leak

Happy Hunting!

ADCS Auditing for MDI

Copy Friendly

certutil –setreg CA\AuditFilter 127 

net stop certsvc && net start certsvc

Configure auditing on the configuration container

Open ADSI Editor

Right click on the configuration Node (CN=…) and select Properties > Security Tab > Advanced

MAKE SURE YOU SELECT THE AUDIT TAB!!

Click Add (VERY IMPORTANT THAT YOU ARE IN AUDIT TAB)

Select principal Everyone, Type: All And Applies to: This object and all descendant objects

Scroll to the bottom and click “Clear” and back up and check the Write all properties

Defender for Identity no longer requires logging 1644 events. If you have this registry setting enabled, you can remove it.

Happy Hunting!

Graph semantics in Kusto

Earlier this month, the Kusto team announced graph semantics feature in Kusto.

This Kusto extension makes it possible to contextualize data in graphs which consists of Nodes and Edges that can be connected. These connections can visualize the relationships between the Nodes.

To describe graph semantics in a none-tech scenario, the best way is to look at social connections where people have connections, one to many, many to many and many to one

let Users = datatable (UserId:string , name:string)[
"1","Mattias",
"2","XboxController",
"3","Stefan",
"4","XBOX"
]; // nodes
let Knows = datatable (FirstUser:string , SecondUser:string)[
"1","2",//Mattias knows xbox controller
"2","4",//Xbox controller knows xbox
"1","3"//Mattias knows Stefan
]; // edges
Knows
| make-graph FirstUser --> SecondUser with Users on UserId
| graph-match (user)-->(middle_man)-->(friendOfAFriend)
    project SecLabs_person = user.name, middle_man = middle_man.name, kusto_friend_of_friend = friendOfAFriend.name

What can it use it for?

  • Many-to-many relations
  • Hierarchical data
  • Networked relationships
  • Social Networks
  • Recommendation systems
  • Connected assets
  • Knowledge graphs

From a hunting perspective, we can connect systems in a unspecified amounts of times. Since we can’t to recursive join, we can use graph to connect unknown number of systems.

Time-aware

In a scenario where we have lateral movement, we could connect all devices involved and at what time (of course depending on the data source, but if we have data from Microsoft Defender XDR data with network data from the endpoint sensor and know about activities involving certain ports, 3389 for example) we could draw all show how and when the threat actor moved laterally.

For further information, please visit: https://learn.microsoft.com/en-us/azure/data-explorer/graph-overview

For Kusto training, CTF mode, Kusto Detective: https://detective.kusto.io/

Threat Hunting and the New Hunts in Sentinel

Establishing a Proactive Hunting program is something which is useful and necessary today.

From working with proactive threat hunting for a long time, from when data was not available at your fingertips, things has become a lot easier in the era of SIEM and over the last years, EDR and XDR.

The technical part is the easy one. The process of establishing your hunting and connect it with existing processes is usually what’s difficult.

What is proactive Hunting?

First, what is threat hunting?

To dive in to this topic I want to point out activities that are somewhat related

The custom detections or scheduled rules is pretty clear what it is. but Tasks is something which sits in between Proactive Threat Hunting and Custom Detections.
Tasks are things discovered in Hunting, and data of interest but cannot be set as a custom detection as of yet.

The reasons could be many, but for example to noisy data and no good correlation values or near-time events that can be used to reduce False-Positives. Even though we have finalized our hypothesis from threat hunting we might want to follow-up on the events, maybe on a daily basis, but we cant have it scheduled since it will give an incident fatigue.

To summarize tasks, it’s queries that might make it to a detection but for now we run it automatically or manual and do manual review on the result on a daily schedule.

To iterate back to threat hunting before we take a look at the hunts feature in Sentinel

Threat Hunting can be divided into 2 main pillars; Proactive and Reactive hunting

Proactive Threat Hunting is when you don’t know something is going on, like playing hide-n-seek, except for that you don’t know anyone is playing with you

Reactive Threat Hunting is post breach/post incident and you use threat hunting to find the outer boundaries of the incident, which could be other devices communicating with a specific IP, list all process communicating, find the same processes on other devices, and then which IP’s they are communicating with.

In the EDR era or now, the XDR era, threat hunting becomes easier on a technical level. The data collection happens automatically for many workloads and not only collected, it’s streamed.

With the power of Kusto Query Language, you can do advanced aggregations, anomaly calculations and visualizations to truly crunch and bend your data.

In Proactive Threat hunting, you will start your assignment by defining your Hypothesis, which could be something like “I would like to see if any local users have been added outside the process”

Then you check what ever data you need to discover such activities (DeviceEvents/DeviceProcessEvents hint hint) and you continue to develop the query for is and document your result.

Here is what makes Hunts feature so great. It actually allows for process integration, like we have in Microsoft 365 Defender where we can create incidents based on the results and have it handled by the incident process.

Hunts in Sentinel

Common use cases:

  • Proactively hunt based on specific MITRE techniques, potentially malicious activity, recent threats, or your own custom hypothesis.
  • Use security-researcher-generated hunting queries or custom hunting queries to investigate malicious behavior.
  • Conduct your hunts using multiple persisted-query tabs that enable you to keep context over time.
  • Collect evidence, investigate UEBA sources, and annotate your findings using hunt specific bookmarks.
  • Collaborate and document your findings with comments.
  • Act on results by creating new analytic rules, new incidents, new threat indicators, and running playbooks.
  • Keep track of your new, active, and closed hunts in one place.
  • View metrics based on validated hypotheses and tangible results.

In Sentinel go to Hunting and Hunts

Here is the list of previous hunts.

If you select New Hunt we can create a new

You can add the Hypothesis and choose if it’s Validated or not (which can be set later in the process by another Threat hunter)

When we have our new Hunting campaign, we can add queries

Adding Tactics and techniques and map entities

It’s possible to create incidents from the results to map to the incident process, and we can also start automated playbooks (entity-based) from the entity pane.

Summary

There are so many details on this feature and it has some many capabilities. The best part is that it has the process of hunting as its core. Now it’s easier to deliver threat hunting, as a service, as a consultant or if you work internally for an organization.

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!