Introduction

The Threat Intelligence (TI) principle has grown by a lot, over the past 15 years. It is still a developing field, cultivating a mentality of building threat-informed defenses.

Threat Intelligence is the Threat information that has been aggregated, transformed, analyzed, interpreted, or enriched to provide the necessary context for decision-making processes.

NIST

In order to materialize the principle of TI, the Threat Intelligence Lifecycle framework comes handy.

The steps presented above, require not only human effort and relevant to field expertise, but also tools to support the associated operations. While each organization is unique, and hence the lifecycle can be materialized in many different ways, so are the tools that can be used accordingly.

It’s been some time since Microsoft has introduced Microsoft Defender Threat Intelligence (MDTI) to help organizations, support their TI lifecycle. Here are 5 reasons you should consider start using and operationalizing MDTI.

1. Curated feed with IoCs

First thing to consider, is taking into advantage MDTI connector in Microsoft Sentinel, as it provides a curated feed of indicators of compromise (IoCs) that you can ingest in your SIEM. Apart from the IoCs, connector comes along with Analytics rules templates that you may use to build detections using the ThreatIntelligenceIndicator table.

You may use the following KQL query, to identify the number of IoCs present in your Sentinel, by ThreatType.

ThreatIntelligenceIndicator
| summarize Count=count() by ThreatType

The MDTI feed is being updated automatically, so you won’t need to do anything further and don’t forget, ThreatIntelligenceIndicator is at your disposal for custom KQL queries of your own.

2. Threat Analytics

If you have found yourself asking, “Where should I begin with to lower my exposure?” or “How am I protected based on specific TTPs or TAs?” then you should familiarize yourself with Threat Analytics. This blade brings a library of Latest threats, High impact threats and Highest exposure threats and how these categories affect your infrastructure.

In the main blade you can filter through threats, whether an alert is associated, which assets are impacted the relevant exposure level, whether there are any misconfigured or vulnerable devices and lastly, the report type of the threat.

Threat types, are also presented in the initial blade:

Now the juicy part is within the Threats where you have access to an assessment of your environment based on the filtering presented above, including the threat’s report which unfolds what the threat is all about. Last tab reflects to Recommended actions, if you are vulnerable to the specific threat then you will get instructions on how to remediate your assets, eliminating the exposure to the threat.

Another handy feature of threat analytics, is the Email notification settings. When new Threats emerge you can set up a built-in automation to receive notifications. You may choose to get everything, you can also receive tailored emails, based on Tags (Tool or technique, Vulnerability etc) and Report types (Ransomware, Extortion, Phishing etc).

Threat analytics is a great tool if you want to lower your exposure risks and keep up to date with current TTPs which are automatically being assessed to your environment.

3. Tracked Threat Actors (with tools & vulnerabilities)

This part will get you acquainted with most prominent Threat Actors (TAs) accompanied with a fruitful set of contextualized information including:

• Source/Region of Origin
• Targets (Industries)

Independently, you may also retrieve information about:

• Tools
• Vulnerabilities

While Basic MDTI does not connect all the dots between these three elements (TAs, Tools & Vulnerabilities), you can still take into consideration which TAs are highly likely to target your organization and build better defenses against them. Don’t forget, utilizing Groups and Software by MITRE ATT&CK will significantly enhance your intelligence capacity as well.

4. Intel Explorer, your contextualized daily news feed

You will probably already have a list of news sites to enjoy day’s first coffee. Keeping up with news and developments, is not easy given the huge amount of information circulating. If you happen to have a curated bookmark folder of intelligence news sites, MDTI offers a daily advanced feed which will help:

• Keep track of latest cybersecurity developments and TTPs.
• Advanced and high confident analysis of TTPs.
• Search articles based on MITRE ATT&CK context.
• If available and provided by Microsoft, download related indicators of compromise (IoCs) and
• Easily share articles through email or URL.

Within the article content, Microsoft will provide -wherever available- Detections and Hunting Queries, it will relate MDE Antivirus signatures associated with the TTPs described in the article, include Recommendations and will also append the related References.

If you want to keep up with current news, you also get the option to distinguish which articles have been published since your last visit. Don’t worry about that, you get this information automatically by the relevant notification provided.

5. Intel projects

Imagine working on an investigation, collecting IoCs and other information. Wouldn’t you want to collect per investigation the set of findings that you are looking into? This is where Intel Projects comes in. You can use the Intel Projects as a cyber threat intelligence workbench where you can save IoCs while you pivot through your investigation.

Following you can go to your Intel Project and have an overview of all Artifacts collected and associated with your investigation. You can also Download Artifacts from the Intel Project and also, contextualize your investigation by using Tags.

Keep in mind that in Basic MDTI, you may create a total of 5 Intel Projects which unfortunately, can’t share with other team members.

A bonus reason to consider

Intel explorer comes with the capacity of Search. Unfortunately, in the Basic license of MDTI the results are quite limited, but, if you are working on a case with recent malicious infrastructure configuration, you will most probably get fruitful results for your investigation as you get 14 days of history for some of the intelligence provided such as Components for IP addresses or…

… DNS resolutions for domains.

Also, you may include results from search, into your Intel projects as mentioned before simply by selecting Add to project.

Closing remarks

While MDTI Basic license comes with limited capacity, it is undeniably a valuable resource to consider operationalizing in your daily tasks and incorporating it in your TI processes.

RiskIQ’s acquisition by Microsoft back in 2021 seems to be paying off by providing a highly competitive product of threat intelligence giving the tools for both beginners and intermediate users to be aware, to identify and address emerging and highly-impact threats.

Have you been using MDTI Basic? If yes, what do you think?

Introduction

The days that Microsoft considered Linux a cancer, have been long gone. Microsoft’s strategy has not only embraced Linux, but developed groundwork to provide the necessary means for open source projects to flourish, leaving behind the early 2000’s rivalries. With that said, Microsoft introduced Windows Subsystem for Linux (WSL) in 2016, allowing Windows users to run a Linux environment without the need of a separate system, or VM.

As we already know, with new features like this, new attack paths come along. There are some stories already of exploited WSL by threat actors. It’s no secret that the WSL operates as a semi-independent environment given for example that Windows users are not associated with the users of WSL. Microsoft recently added a Defender for Endpoint plug-in to monitor and protect WSL environments and this is what this blog is all about.

Identify endpoints that run WSL and/or MDE plug-in

First things first, let’s identify endpoints that users run WSL with the following KQL:

DeviceProcessEvents
| where ActionType has "ProcessCreated"
| where ProcessVersionInfoOriginalFileName has "wsl.exe"
| where ProcessVersionInfoFileDescription has "Windows Subsystem for Linux"
| summarize by DeviceName

You can also identify which of your endpoints already have the MDE plug-in:

DeviceTvmSoftwareInventory
| where SoftwareName has "microsoft_defender_for_endpoint_plug-in_for_wsl"
| summarize by DeviceName

Joining forces from the queries above, you can identify endpoints running WSL but don’t have the plug-in installed:

let WSLDevices = DeviceProcessEvents
| where ActionType has "ProcessCreated"
| where ProcessVersionInfoOriginalFileName has "wsl.exe"
| where ProcessVersionInfoFileDescription has "Windows Subsystem for Linux"
| project DeviceName;
WSLDevices
    | join kind=leftanti (DeviceTvmSoftwareInventory
    | where SoftwareName has "microsoft_defender_for_endpoint_plug-in_for_wsl"
    | project DeviceName
) on DeviceName

MDE plug-in deployment

MDE plug-in deployment is straightforward, and includes 3 steps:

• Download the Windows Subsystem for Linux 2 (plug-in).
• Deploy it at the endpoint.
• Check your Assets, you will find a WSL2 tagged device same Device Name as your WSL host.

Let’s go hunt!

After experimenting with WSL and pivoting using KQL, the following tables (at my lab) are being fed with data:

• DeviceNetworkInfo
• DeviceInfo
• DeviceNetworkEvents
• DeviceFileEvents
• DeviceProcessEvents
• DeviceEvents
• DeviceTvmSoftwareEvidenceBeta
• DeviceTvmInfoGathering
• DeviceTvmSecureConfigurationAssessment
• DeviceTvmSoftwareInventory
• ExposureGraphNodes

DeviceNetworkEvents, DeviceFileEvents and DeviceProcessEvents can provide fruitful data for threat hunting and detection opportunities. Rest of the tables, are useful too to build cases.

Commencing with the Advanced Hunting, it is preferable to hunt within the tables only for endpoints that are WSL2 tagged. This will be more precise and will reduce the noise from the command lines of your environment.

A simple hunt to begin with could be the following, looking for reconnaissance  activity:

let WSLSuspicousList = dynamic(["whoami", "uname", "find", "grep", "cron -l", "/etc/shadow", "/etc/passwd", "/etc/sudoers", "w"]); 
let TimeFrame = 30d; // Choose the best timeframe for your investigation
DeviceInfo
    | where RegistryDeviceTag has "WSL2"
    | project DeviceId
| join ( DeviceProcessEvents
    | where Timestamp > ago(TimeFrame)
    | where ActionType == "ProcessCreated"
    | where ProcessCommandLine has_any (WSLSuspicousList)
    | project TimeGenerated, WSLDeviceID = DeviceId, DeviceName, FileName, FolderPath, ProcessId, ProcessCommandLine, AccountDomain, AccountName
    )
on $left.DeviceId == $right.WSLDeviceID
| sort by TimeGenerated desc

Within the dynamic data declared, you may choose to hunt for further options based on your requirements. For example, a keywords list looking for privilege escalation commands would look like:

let WSLSuspicousList = dynamic(["chmod", "sudo", "-su", "acl", "chown", "adduser", "addgroup", "usermod", "passwd"]);

DeviceFileEvents is fruitful as well, as it allows detection of suspicious file creation. The following KQL query for example, would help identify suspicious creation of files in /etc for persistence:

let LinuxPerSuspicousCommands = dynamic(["/etc/ld.so.conf.d/", "/etc/cron.d/", "/etc/sudoers.d/", "/etc/rc.d/init.d/", "/etc/systemd/system/","/usr/lib/systemd/system/"]);
let TimeFrame = 30d; // Choose the best timeframe for your investigation
DeviceInfo
    | where RegistryDeviceTag has "WSL2"
    | project DeviceId
| join ( DeviceFileEvents
    | where Timestamp > ago(TimeFrame)
    | where ActionType == "FileCreated"
    | where FolderPath has_any (LinuxPerSuspicousCommands)
    | project TimeGenerated, WSLDeviceID = DeviceId, DeviceName, FileName, FolderPath
    )
on $left.DeviceId == $right.WSLDeviceID
| sort by TimeGenerated desc

Query inspired by this hunting rule.

DeviceNetworkEvents can also help hunting. However, during the tests performed, I noticed a shift in ActionType results. While in regular results you would expect ConnectionSuccess, ConnectionAcknowledged or DnsConnectionInspected etc, DeviceNetworkEvents for WSL at least for the time tested, does not provide that fruitful results. Hence, I would be wary on pivoting through the ActionType column and stay focused on more common schema data such as RemoteIP, RemotePort etc.

Considerations

Host threat hunting

Given that it is common for users with elevated privileges to be working with WSL, it won’t be a surprise if threat actors might try to take this into advantage. The following query, will assist in hunting for suspicious WSL invoking. Apart from what can be detected within the instance of WSL, keep an eye on the host as well.

let WSLHostSuspicousList = dynamic(["curl", "/etc/shadow", "/etc/passwd", "cat", "--system", "root", "-e", "--exec", "bash", "/mnt/c/"]); 
let TimeFrame = 30d; // Choose the best timeframe for your investigation
DeviceProcessEvents
    | where Timestamp > ago(TimeFrame)
    | where InitiatingProcessFileName has "wsl.exe"
    | where ProcessCommandLine has_any (WSLHostSuspicousList)
    | project TimeGenerated, DeviceId, DeviceName, FileName, FolderPath, ProcessId, ProcessCommandLine, AccountDomain, AccountName
    | sort by TimeGenerated desc 

Query inspired by this hunting rule.

Isolation

Don’t try to isolate the WSL, you can’t! If any of your hunts turn into detection, you will have to make sure to isolate the endpoint that reflects the host, and not the WSL-tagged endpoint.

Device table searches and automations

As you probably have figured out from the blog, having two devices with the same DeviceName, but different DeviceId could be troublesome. It requires some extra effort to differentiate those devices and build queries for the devices you actually want. Taking this one step further, this requires some extra effort when it comes to automations also.

Visible asset

If you don’t see your WSL device immediately, don’t worry, it will eventually come up. This might be the case when you are using the WSL occasionally and not in a daily basis.

Closing remarks

WSL by itself is a blind spot within your endpoints and can be used to elevate access, build persistence even -as seen in the wild- be used straight from CnC mechanisms and threat actors. The WSL plug-in sheds light on this blind spot and allows building a monitoring capacity which combined with the rest of Defender XDR and Sentinel ecosystem can further fortify this attack vector.

Table of contents

• Analytics
• Hunting
• The MITRE ATT&CK blade
• Workbooks
• KQL queries
• Closing remarks

Part 2: Microsoft Sentinel

Analytics

The first, and probably most fundamental place to begin with MITRE ATT&CK in Microsoft Sentinel is the Analytics blade. Eventually, all incidents’ mapping will be based on the contextualization of the Tactics and Techniques configured per rule here. Below, is the look and feel for the out-of-the-box templates, provided by Microsoft where Tactics and Techniques are present.

Choosing a template will also provide you with details about the mapping.

Of course, before creating your Active analytics rule, by clicking Create rule, you can review the Tactics and Techniques in order to map your Tactics and Techniques of preference.

Triggering a simple Analytics rule, will provide the following Alert and relevant Security Incident that for the built-in “TI map File Hash to DeviceFileEvents Event” as an example has Impact as a pre-configured Tactic.

Hunting

Next place to look into, is the Hunting blade. Hunting also incorporates MITRE ATT&CK to contextualize queries that you build and use for threat hunting.

Apart from the general categorization, which you may notice on top, each query is also contextualized based on Tactics and Techniques. Queries here can be used to build Hunts, a complete hunting capacity that can be used along known frameworks such as TaHiTI or PEAK.

Each Hunt then builds its own queries’ MITRE ATT&CK map, bringing together individualized capacity for your intelligence.

The MITRE ATT&CK blade

Having built your queries in Analytics and the Hunting blade, is the way to ingest your relevant framework capacity at the MITRE ATT&CK blade and the heatmap provided by Microsoft Sentinel.

There are some things to consider here, as the heatmap can be built by incorporating various information. You may choose between Active and Simulated coverage. By default, you may use the Active detections, this will build a heatmap of the active and currently deployed query rules you use either they fall under the Scheduled, Near-real-time (NRT) or Anomaly category. On the other hand, you can enrich the heatmap by Simulated rules which include Analytics rule templates, Hunting queries and Anomaly rules. You may also find used the Legend, a gradual coloring for each Tactic and Technique based on the rules engaged.

It’s important to remember that Active queries, are actually running at the moment and any Security Alert and Security incident raised provided that the query has been associated with the relevant Tactics and Techniques, contributes to the MITRE ATT&CK heatmap. Simulated queries reflects the same idea deriving from templates and the Hunting blade but they contribute to the heatmap as a capacity you my have over the MITRE ATT&CK framework, rather than actual coverage. Thus, for each Tactic and Technique, you can distinguish each category.

Another tool that can be used here is the the ExtractMITRE, in case you want the heatmap information exported and used from your Cyber Threat Intelligence team for various purposes including reporting etc.

Workbooks

Last, but not least, Microsoft Sentinel comes with an out-of-the-box Workbook template that maps detections coverage across the MITRE ATT&CK framework. It also comes with a set of heatmaps based on cloud platforms including Azure, Microsoft Entra ID and more.

KQL Queries

As with Part 1, a relevant KQL query for Microsoft Sentinel providing information about Techniques associated with Security Alerts, can be found below.

SecurityAlert
// Define timerange
| where TimeGenerated > ago(30d)
| where isnotempty(Techniques)
| mvexpand todynamic(Techniques) to typeof(string)
| summarize AlertCount = dcount(SystemAlertId) by Techniques
| sort by AlertCount desc
// Define graphic
| render piechart 

Closing remarks

The capacity of operationalizing MITRE ATT&CK in Microsoft Defender XDR but especially in Microsoft Sentinel, has grown significantly providing lots of capabilities for Threat Hunters and Cyber Threat Intelligence Analysts. By understanding the approach in Microsoft Sentinel along with Active and Simulated coverage, a Hunter or an Analyst could take advantage of a well disciplined path to build threat-informed defenses. Deriving from the above though, the journey of operationalizing MITRE ATT&CK begins in the queries, where Tactics and Techniques must be claimed.

On the other hand, if you are part of a team, and most importantly if you are working remotely, you might want to have direct access to which of your endpoints are isolated. In this case, a tag which can also be used for filtering, could do the job.

Following, we will deploy a Logic App, which runs a KQL query identifying which endpoints have been isolated, and will automatically add a tag and send a notification email to your help desk.

Before building the Logic App, first step is to define the KQL query, which will identify which endpoints have been isolated. Following thorough investigation, once you isolate an endpoint the registry changes below take place and hence, provide us with a detection opportunity.

DeviceRegistryEvents
| where ActionType == "RegistryValueSet"
| where RegistryKey == @"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection"
| where RegistryValueType == "Dword"
| where RegistryValueName == "DisableEnterpriseAuthProxyValueToRestoreAfterIsolation"
| where RegistryValueData == "1"
| where PreviousRegistryValueName == "DisableEnterpriseAuthProxyValueToRestoreAfterIsolation"
| project Timestamp, DeviceId, DeviceName

Now that we know the KQL query, we can build the Logic App.

Once the Deployment is complete, click at Go to resource and from the Logic App page, choose the Logic app designer from the left pane. Click on Add a trigger, search for Recurrence, click on it and select how often you would like to check for isolated endpoints and also, choose your Time zone.

Then, under Recurrence step, click on the + sign and then click Add an action.

Then search for “run query” and from the results below, choose Run query and list results. Insert Subscription, Resource Group, Resource Type (Log Analytics Workspace) and Resource Name, just as your Sentinel. Then insert the query mentioned above.

Now add a new action, search for “tag machine” and under Microsoft Defender ATP, choose Machines – Tag machine. Follow the steps below and choose the proper tag for your environment.

Add a new action, search for “send an email” and choose Send an email (V2). Now here, based on your operations, choose the Recipients, a suitable Subject, any Advanced parameters and also the Importance.

Since I have already build Logic Apps, I already have a connection with my mailbox to send notifications. You can choose Change connection to select any mailbox from your environment you want to send notifications from.

Click at Save and your Logic App, is ready.

Now, let’s test our Logic App. Isolate an endpoint and wait a few minutes, KQL query will take a few minutes to return results. Then trigger the Logic App by clicking at Run at the Logic App options ribbon.

If everything has worked as expected, you should be able to filter at your Devices in Defender XDR by “Isolated” as tag and also, you should have received a relevant email notification.

You can also automate reversing tag adding, and sending a relevant notification that an endpoint has been removed from isolation by building a similar Logic App and choosing Remove instead of Add in the Machine – Tag machine step, and changing the wording at the notification email. Most importantly, you will need to replace the KQL query as well, with the following.

DeviceRegistryEvents
| where ActionType == "RegistryValueDeleted"
| where PreviousRegistryKey == @"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection"
| where RegistryValueType == "None"
| where PreviousRegistryValueData == "1"
| where PreviousRegistryValueName == "DisableEnterpriseAuthProxyValueToRestoreAfterIsolation"
| project Timestamp, DeviceId, DeviceName

I hope you enjoyed this blog!

EDIT 29/2/2024: Big shout out to Alex Verboon for his constructive feedback.

Table of Contents

• What are threat intelligence (TI) feeds and why should I consider using them?
• How can the externaldata operator help harness threat feeds?
• What kind of files are supported?
• How can I use the externaldata operator?
• Actual examples of externaldata operator, harnessing threat feeds
  • Domains
  • IPs
  • File hashes
  • Keywords
• Further resources to consider
• Closing remarks

What are threat intelligence (TI) feeds and why should I consider using them?

Threat Intelligence (TI) feeds are streams of information and data often curated in some form of context (i.e. IPs, hashes or categories such specific malware, etc.) and they provide actionable insights about potential attacks cybersecurity threats and risks.

More and more organizations decide to use TI feeds in order to keep defenses up to date and also, be prepared for emerging threats.

How can the externaldata operator help harness threat feeds?

According to Microsoft documentation:

The externaldata operator returns a table whose schema is defined in the query itself, and whose data is read from an external storage artifact, such as a blob in Azure Blob Storage or a file in Azure Data Lake Storage.

externaldata operator

In simple words, you may have a file of data that interests you, and based on the structure and the data itself, you can build a new table with curated aggregation based on your needs.

For example, the following query will build a table by taking into account a json file, the ip_address and url_status fields but leaving outside any entries where url_status is offline.

What kind of files are supported?

Most common files that can be used include TXT, CSV and JSON files, however Microsoft documentation indicates that over a dozen of filetypes can be leveraged through externaldata operator including ORC, Parquet, PSV, RAW and others. Also, compressed files are supported through the formats of gzip and zip.

In order to test data before ingestion, the following validators can be used, per format whether it’s CSV or JSON.

• CSV: http://csvlint.io/
• JSON: https://jsonlint.com/

How can I use the externaldata operator?

Before you start, there are three parameters that need to be defined.

The above, can be depicted in the query below with actually defined parameters. ColumnName refers to which data will be aggregated from the data source, storageConnection depicts the data source and propertyName and propertyValue define specific intrepretation options for the data.

Actual examples of externaldata operator, harnessing threat feeds

You may find many categories of threat feed data available, some might be the most obvious such as IPs, file hashes, domains etc. and some other might include less popular data type but equally valuable for your organization, in case you want to go threat hunting such as keywords, CVEs and more. You may also want to maintain your own threat feeds, probably by using your own hosting provider or a GitHub repo. Just remember to follow a file type supported by externaldata operator.

Domains

The following query, will detect inbound emails in Defender XDR which match the domains provided from a threat feed.

let domainList = externaldata(domain: string) [@"https://raw.githubusercontent.com/tsirolnik/spam-domains-list/master/spamdomains.txt"] with (format="txt"); // Change the text file to whatever you want
let excludedDomains = datatable(excludeddomain :string)  // Add as many domains you would like to exclude
 ["domain1.tld",
  "domain2.tld",
  "domain3.tld"];   
let Timeframe = 1d; // Choose the best timeframe for your investigation
let SuspiciousEmails = EmailEvents
    | where Timestamp > ago(Timeframe)
    | where EmailDirection == "Inbound"
    | extend EmailDomain = tostring(split(SenderMailFromAddress, '@')[1])
    | join kind=inner (domainList) on $left.EmailDomain == $right.domain
    | where not(EmailDomain in (['excludedDomains']))
    | project Timestamp, NetworkMessageId, SenderMailFromAddress, SenderFromAddress, SenderDisplayName, RecipientEmailAddress, EmailDomain, domain, Subject, LatestDeliveryAction;
SuspiciousEmails
    | join (EmailEvents
    | project NetworkMessageId
)on NetworkMessageId
    | sort by Timestamp desc

Source: github/cyb3rmik3

IPs

The following query will check in Sentinel whether any successful sign ins have taken place from any of the IPs provided in the threat feeds.

let BlockList = (externaldata(ip:string)
[@"https://rules.emergingthreats.net/blockrules/compromised-ips.txt",
@"https://raw.githubusercontent.com/stamparm/ipsum/master/levels/5.txt",
@"https://cinsscore.com/list/ci-badguys.txt",
@"https://infosec.cert-pa.it/analyze/listip.txt",
@"https://feodotracker.abuse.ch/downloads/ipblocklist_recommended.txt"
]
with(format="csv")
| where ip matches regex "(^(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$)"
| distinct ip
);
SigninLogs
| where IPAddress in (BlockList)
| where ResultType == "0"

Source: KustoKing

File hashes

The following query will detect if any SHA256 hashes are present from a threat feed providing file hashes for Emotet malware.

let Emotetsha256 = externaldata(sha256: string)[@"https://githubraw.com/Cisco-Talos/IOCs/main/2022/11/Emotet_parents.txt"] with (format="txt", ignoreFirstRecord=True);
DeviceFileEvents
| where SHA256 in (Emotetsha256)
| project Timestamp, FileName, SHA256, DeviceName, InitiatingProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountDomain, InitiatingProcessAccountName

Source: Bert-JanP

Keywords

The following query has been crafted to utilize the ProcessVersionInfoCompanyName table with a threat feed created by installing and testing corresponding tools.

let RMMSoftware = externaldata(RMMSoftware: string)[@"https://raw.githubusercontent.com/cyb3rmik3/Hunting-Lists/main/rmm-software.csv"] with (format="csv", ignoreFirstRecord=True);
let ExclDevices = datatable(excludeddev :string)  // Add as many devices you would like to exclude
 ["DeviceName1",
  "DeviceName2",
  "DeviceName3"];
let Timeframe = 7d; // Choose the best timeframe for your investigation
DeviceProcessEvents
    | where Timestamp > ago(Timeframe)
    | where ProcessVersionInfoCompanyName has_any (RMMSoftware)
    | where not(DeviceName in (['ExclDevices']))
    | project Timestamp, DeviceName, ActionType, FileName, FolderPath, ProcessVersionInfoCompanyName, ProcessVersionInfoProductName, ProcessCommandLine, AccountName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
    | sort by Timestamp desc

Source: github/cyb3rmik3

The list could go on, but the idea is that, sky is the limit. You can build queries for almost anything you want or harness threat feeds out there to hunt and detect within your Microsoft ecosystem.

Further resources to consider

• Over the last year I have been experimenting with queries and lists I found useful. You may find them at my GitHub repos, KQL threat hunting queries and Hunting Lists.
• Bert-Jan has crafted a curated list of Threat Intelligence feeds that can be used to empower defenses in Microsoft Defender XDR. Plus, queries included.
• Our community contributed repository of KQL queries at kqlsearch has a ton of relevant queries, I bet some will meet your needs, or at least give you an idea to build your own query.
• As always, Microsoft’s documentation provides great insights and also, a lot of options to pivot further for anything that concerns you.

Closing remarks

Being able to ingest threat intelligence feeds and empower your defenses, is a process that should be thoroughly evaluated, described and contextualized. While this blog has elaborated that with proper query building, you may harness almost any threat feed to hunt, it is important to remember that threat intelligence is meant to be scoped. In simple words, this means that you should only ingest threat intelligence that fits your organization’s requirements.

Happy hunting!

Table of Contents

• Greek national high school exams site DDoS attack
• Papaki.gr cyber attack
• TurkHackTeam DDoS attacks
• APT29 attacks Embassies in Greece
• Zimbra zero-day attack on Greek government agency
• Anonymous Collective DDoS attacks
• Further interesting facts
  • Hellenic Federation of Enterprises (SEV) statistics
  • National Cyber Security Index (NCSI) Score
  • National Cyber Security Agency
  • National Intelligence Service (NIS) Annual Report
• Closing remarks

Greek national high school exams site DDoS attack

Candidates for final exams in high schools in Greece, were welcomed to establishments with an unpleasant surprise as at the first two days of the exams, the exam subjects distribution website was inaccessible due to a cyber attack.

Greece's Education Ministry Faces Unprecedented Cyber Attack Targeting High School Exam Platform https://t.co/NEp3Fefpal#greece #greek #greekcitytimes pic.twitter.com/rEjIJmT7LD

— Greek City Times (@greekcitytimes) May 30, 2023

Given the very recent national elections, the cyber attack has gained a lot of attention and controversy, to the point of discussing that this DDoS attack might haven’t been an actual cyber attack, but just a failure following high demand of resources. In light of this, I have prepared a detailed OSINT analysis of the Greek school exams site DDoS attack, proving that this attack, indeed took place. Another issue raised, and analyzed in my blog, reflects whether the attribution from Greek authorities to Killnet is valid or not, where eventually there aren’t any hard evidence that the notorious group is involved.

Papaki.gr cyber attack

Papaki.gr, a prominent Greek domain registrar of over 350.000 domains and member of team.blue brands, announced on July 27th that an unauthorized access to their systems has been identified. While details of the cyber attack haven’t been released, Papaki informed that most probably two clients were affected but be that as it may, all clients should consider their following information as compromised:

• Credentials and information including phone numbers, addresses and other PII of clients.
• Billing information (Invoices etc).
• Domain information (Administrator’s, owner’s information etc).
• Other options available to domain administrators (Domain settings etc).

No further information has been uncovered about the TTPs or the Threat Actors (TAs) behind this attack, but it gained a place in this blog due to its potential impact.

TurkHackTeam DDoS attacks

On the occasion of Turkey’s Victory Day, in August 30th, TurkHackTeam announced that it will be conducting cyber attacks for several days, hitting critical infrastructure of Greece. The following websites have been announced as targets at their Telegram channel.

Interestingly, in their last day of attacks, their message included “Our attacks will be on the oppressor’s” indicating a political motive for their attacks.

Further attacks took place after September 3rd, however in a far more lower intensity, which ended in September 13th including an e-shop database dump, further disruption attacks and surprisingly, some CCTV cameras exposure.

APT29 attacks Embassies in Greece

On November 14th, the National Cyber Security Coordination Center (NCSCC) of Ukraine released a report, indicating that embassies situated in Greece, have been targeted from APT29. APT29 is affiliated with Russia’s Foreign Intelligence Service (SVR).

NCSCC supports that this attack, had political motives as APT29 might tried to gather intelligence concerning Azerbaijan’s strategic activities. It’s noteworthy that all countries targeted, Italy, Romania and Greece, maintain significant political and economic ties with Azerbaijan.

APT29 leveraged a newly discovered vulnerability in WinRAR, identified as
CVE-2023-38831, to facilitate their intrusion.

Last, but not least, apart from the embassies in Greece, the prominent ISP Cosmote (OTENET) has also been targeted within the same campaign.

APT29 attacks Embassies using CVE-2023-38831

Our latest report unravels meticulously orchestrated cyberattacks of #APT29 targeting embassies across #Europe, including Italy, Greece, Romania, and Azerbaijan.

Read the Full Report Here: https://t.co/J2nvypnv1h

1/4 pic.twitter.com/80P3oSuWrq

— НКЦК (@ncsccUA) November 14, 2023

Zimbra zero-day attack on Greek government agency

In June 2023, Google’s Threat Analysis Group (TAG) discovered an in-the-wild 0-day exploit targeting Zimbra Collaboration, now patched as CVE-2023-37580. The initial in-the-wild discovery of the 0-day vulnerability was a campaign targeting a government organization in Greece.

TAG doesn’t name which government organization has been targeted, also no attribution has taken place with regards to which TA was behind the attack. OSINT information from Shodan, suggests that a lot of organizations use Zimbra in Greece, including government bodies. Hence, it is difficult to narrow down results and guess which organization might have been affected. While there are no, to little information about this attack, it deserves a place here given its complexity and sophistication.

Anonymous Collective DDoS attacks

On December 7th, Anonymous Collective announced they will be targeting Greek Government entities as well as companies, banks and others, following Greece’s supporting of Israel at their war with Palestine.

The politically-driven attacks of Anonymous led to the disruption of prominent companies from public and private sector:

• ose.gr, Hellenic Railway Organization, the Greek national railway company which owns, maintains and operates all railway infrastructure in Greece.
• elta.gr, The Hellenic Post S.A., the state-owned provider of postal services (also, ransomed in 2022 by Vice Society).
• depa.gr, Public Gas Corporation of Greece, the natural gas supply company of Greece.
• coralacademy.gr, SHELL’s retail training platform.
• elin.gr, ELINOIL one of the most dynamic energy groups in Greece, with a nationwide network of 580 petrol stations.

Interestingly, Anonymous Collective have made two false statements that can easily be debunked. First, referring to the Hellenic Railway Organization website, which was stated that it was down for over 14 hours (pic. 3). However, the website was accessible from Greece far more early and as such, there should probably be a geofencing protection present a few hours after the attack.

Anonymous Collective support that their first target, https://t.co/KhnZI7LvYW is still down.

However, there seems to be some sort of Geofencing protection enabled as the website is accessible from .#OpGreece #ThreatIntel #CTI https://t.co/bu7uODfIL4 pic.twitter.com/tgflLMCDue

— Michalis Michalos (@Cyb3rMik3) December 8, 2023

The second, referred to SHELL’s retail training platform.

There is 2 login pages that shell stations use to order gas or petrol.

Anonymous Collective

This statement is also false, both websites that were taken down are being used for training purposes.

Further interesting facts

Hellenic Federation of Enterprises (SEV) statistics

Hellenic Federation of Enterprises (SEV) provided interesting statistics with regards to Greek small and medium businesses (SMBs). They stated that:

• 40% of the SMBs strategically focus on digital transformation.
• 4 out of 10 SMBs that have suffered a data leak, terminated their operations.
• 57% of SMBs that suffered a cyber attack raised their prices to address the restoration costs.
• 6,9% of Greek businesses (vs 25,5% in the EU) reviewed their strategy and digital security policies during the last 12 months.

National Cyber Security Index (NCSI) Score

Greece enjoys the 7th place within the National Cyber Security Index (NCSI). However, there is space for improvement with regards to community as it has 0 points in Operational support of volunteers in cyber crises as well as at Public cyber threat reports are published annually.

National Cyber Security Authority

Following the undeniable rise in cyber attacks in Greece over the past years, the Greek Government will soon proceed and create the National Cyber Security Authority, as part of the Ministry of Digital Governance. The legislative discussion about the Authority, is taking place is this blog is written.

National Intelligence Service (NIS) Annual Report

For the first time, National Intelligence Service (NIS) has published an annual report including information about Cybersecurity and New Technologies.

Closing remarks

ENISA Threat Landscape 2023 report indicates that the most prevailing threats are ransomware and DDoS attacks. The fact that no ransomware attack is mentioned here, doesn’t mean that no relevant prominent attacks haven’t taken place. Amongst 2023 victims were, Byte Computer, a 30-year old ICT integrator which was ransomed by Lockbit, then Neptune Lines, a carrier of 21 vessels ransomed by Vice Society (an acquainted TA to Greece) and the University of Aegean, which was ransomed by Lockbit. Also, Greece’s state property company, ETAD was hit by ransomware but no information has been disclosed.

Greek threat landscape had it all in 2023. Publicly accessible information presented in this blog indicate a shift towards disruption and espionage, demonstrating that Greece has been made a prominent target for politically and ideologically motivated hacktivists and state-sponsored threat groups. Greek state’s decision to develop a National Cyber Security Authority is a significant move, that sheds optimism for the future of our country’s cyber resilience. However, more needs to be done other than this, including nurturing a community to share, discuss and develop intelligence.

Happy new year!

It’s no secret that Remote Monitoring and Management (RMM) software is being used by Threat Actors (TAs) for lateral movement and to establish command and control (C2). The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), and Multi-State Information Sharing and Analysis Center (MS-ISAC), released a joint Cybersecurity Advisory (CSA), highlighting the malicious use of legitimate RMM software.

Red Canary has also shed some light on the malicious use of RMM software in recent blogs, emphasizing on the importance of detecting relevant activity given that:

• RMM software doesn’t require extensive technical knowledge to be used.
• RMM software has been used in supply chain attacks.

Adding to the above:

• It’s possible that companies lack effective monitoring mechanisms to identify questionable activity via remote management technologies. Because of this oversight gap, attackers may be able to go unnoticed.
• The attack surface grows as more remote management technologies are used by enterprises to support distant work or streamline operations. This allows TAs to have greater opportunities identify and take advantage of vulnerabilities.

Detection Considerations

With a ton of RMM software out there, utilizing a dozen of techniques, including different console connection methods, it seems impossible to prepare a common hypothesis for a highly effective analytic.

On the other hand, RMM software is widely used from enterprises for common operation procedures. Given the establishment of work-from-home or work-from-everywhere after Covid19 outbreak, remote support software has been fundamental to streamline operations for IT teams throughout the world.

Be that as it may, by experimenting with RMMs and Microsoft Defender for Endpoint (MDE) a common ground can be identified to build a relatively high precision analytic.

Detection Opportunities

First things first, let’s have a look at the pyramid of pain.

It is needless to say that building analytics, should primarily aim as higher as possible so that it would provide concrete and efficient results. Recently surfaced Trend Micro’s publication “Analysis on legit tools abused in human operated ransomware” is a great resource to deep dive into artifacts from RMM tools that could help build queries looking from file names, to network connections and security event logs.

KQL Queries to keep an eye on

• CJ May has developed a great query that sinkholes domains used by RMM software which you may find here.
• Daniel Card has also collected filenames from RMM software which are used in this query.

What about MDE?

I decided to try and run some of the most prominent RMM tools based on Red Canary’s reports and try and find common ground for good detection analytics. I came across many tables that collect artifacts towards this, including:

• DeviceNetworkEvents (Domains and IPs)
• DeviceNetworkEvents along with SslConnectionInspected ActionType (Certificates used for communication)
• DeviceProcessEvents (Filenames and file hashes)

But one that caught my eye, was the following:

Software running in Windows has hardcoded ProcessVersionInfoCompanyName and ProcessVersionInfoProductName on it. Hence, it seems that we might not be on top of the Pyramid of Pain, but we are very close. After running a dozen of RMM tools locally, I came down to this artifact collection which can be used along with the following query to detect for RMM activity.

let RMMSoftware = externaldata(RMMSoftware: string)[@"https://raw.githubusercontent.com/cyb3rmik3/Hunting-Lists/main/rmm-software.csv"] with (format="csv", ignoreFirstRecord=True);
let ExclDevices = datatable(excludeddev :string)  // Add as many devices you would like to exclude
 ["DeviceName1",
  "DeviceName2",
  "DeviceName3"];
let Timeframe = 7d; // Choose the best timeframe for your investigation
DeviceProcessEvents
    | where Timestamp > ago(Timeframe)
    | where ProcessVersionInfoCompanyName has_any (RMMSoftware)
    | where not(DeviceName in (['ExclDevices']))
    | project Timestamp, DeviceName, ActionType, FileName, FolderPath, ProcessVersionInfoCompanyName, ProcessVersionInfoProductName, ProcessCommandLine, AccountName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
    | sort by Timestamp desc   

Check out this, and further queries at my Github repo.

The query above reflects the tests with RMM tools I have done so far, this is an ongoing project and I will be updating the hunting list accordingly.

Bonus query

MDE already tracks some RMM tools as suspicious and hence, it raises an alert. Taking into account the MITRE ATT&CK T1229 technique, you can identify whether a relevant alert has been raised in your environment.

AlertInfo
| where Timestamp > ago(30d) // Define timerange
| where AttackTechniques contains "T1219" // Reference: https://attack.mitre.org/techniques/T1219/

Closing remarks

RMM tools have been going under the radar given that its legitimate software and who would have thought that TAs would use it? But hey, why make things complicated when they can be so simple?

While MDE offers detection opportunities for RMM tools, and it’s always good to know what’s moving in your environment, you should also consider hardening this kind of posture in further ways as well. Proxies, UAC, firewall communication, deep packet inspection, just to name a few.

Happy hunting!

Fortra recently released a report indicating that business email compromise (BEC) attacks are at their zenith. Why not? As ENISA mentions in its 2022 Threat Landscape Report, financially motivated threat actors find it far more easier to perform a Man-in-The-Middle (MiTM) through an account take over rather than preparing and conducting sophisticated malware attacks and then going into extortion and negotiations.

Microsoft has been following BEC attacks and reported in its May 2023 Cyber Signals, that they investigate 156.000 BEC attempts daily, while they have taken down 417,678 throughout May 2022 to April 2023.

Having said that, it is crucial to comprehend the importance of being able to detect and respond in these kinds of attacks. A good overview for incident response about BEC attacks, can be found here by PwC.

Within this blog, we will discuss how can someone investigate initial access, given that a mailbox has been compromised through a phishing attack. Some good reads to help understand detections, incident response and mitigations:

Detection opportunities

Microsoft 365 Defender and Microsoft Defender for Office 365 through Advanced Hunting provide some insightful tables that could help detect the initial access especially for phishing emails. Following, four queries are provided to help towards investigating this attack path.

Review recent attachments

The following query will list all emails received on the Timeframe specified that haven’t been blocked and have an attachment. This will help analysts get an overview of the email attachments recently received that might rise suspicions.

let CompromizedEmailAddress = ""; // Insert the email address of the compromised email address
let Timeframe = 2d; // Choose the best timeframe for your investigation
let EmailInformation = EmailEvents
    | where RecipientEmailAddress == CompromizedEmailAddress
    | where Timestamp > ago(Timeframe)
    | where DeliveryAction != "Blocked"
    | where AttachmentCount != "0"
    | project Timestamp, NetworkMessageId, SenderMailFromAddress, SenderFromAddress, SenderDisplayName, ThreatNames;
EmailInformation
    | join (EmailAttachmentInfo
    | project NetworkMessageId, FileName, FileType, FileSize
) on NetworkMessageId
| sort by Timestamp desc

Review recent UrlClickEvents

The following query will help identify emails with URLs inline, where the user took action and clicked any of them and the URL wasn’t blocked.

let CompromizedEmailAddress = ""; // Insert the email address of the compromised email address
let Timeframe = 2d; // Choose the best timeframe for your investigation
let EmailInformation = EmailEvents
    | where RecipientEmailAddress == CompromizedEmailAddress
    | where Timestamp > ago(Timeframe)
    | where UrlCount != "0"
    | project Timestamp, NetworkMessageId, SenderMailFromAddress, SenderFromAddress, SenderDisplayName, ThreatNames;
EmailInformation
    | join (UrlClickEvents
    | where ActionType != "ClickBlocked"
    | where Workload == "Email"
    | project Timestamp, Url, IPAddress, NetworkMessageId
) on NetworkMessageId
| sort by Timestamp desc 

Suspicious email detected after delivery

The following query will present email details that have been identified as suspicious after delivery.

let CompromizedEmailAddress = ""; // Insert the email address of the compromised email address
let Timeframe = 2d; // Choose the best timeframe for your investigation
let EmailInformation = EmailEvents
    | where RecipientEmailAddress == CompromizedEmailAddress
    | where DeliveryAction != "Blocked"
    | project Timestamp, NetworkMessageId, SenderMailFromAddress, SenderFromAddress, SenderDisplayName, ThreatNames;
EmailInformation
    | join (EmailPostDeliveryEvents 
    | where ThreatTypes != ""
    | project Timestamp, NetworkMessageId, Action, ActionType, ActionTrigger, ActionResult, DeliveryLocation, ThreatTypes, DetectionMethods
) on NetworkMessageId
| sort by Timestamp desc 

Suspicious subject keywords

Having gone through PwC BEC incident response playbook, there is a set of keywords included that could be found in email’s subject, that could potentially be correlated to phishing emails. This query will most probably return a lot of false/positives, however it could potentially return results significant enough to go through.

let CompromizedEmailAddress = ""; // Insert the email address of the compromised email address
let Timeframe = 2d; // Choose the best timeframe for your investigation
let SuspiciousKeywords = dynamic([ // as provided by PwC BEC Playbook
    @"Request",
    @"Reconfirm Password",
    @"Account Alert",
    @"Confirmation",
    @"Account Reset",
    @"Payments",
    @"Reminder",
    @"Confidential",
    @"You Recieved",
    @"Voice Messages",
    @"Hello",
    @"Voicemail from",
    @"Immediate Response",
    @"Voic(e)Message",
    @"Urgent",
    @"VM from",
    @"Action Required",
    @"Audio Message",
    @"Account Suspended",
    @"Voice Recording Available",
    @"Password Reset",
    @"Received Fax Document",
    @"Sign-in attempt",
    @"Bill Invoice"]);
EmailEvents 
| where RecipientEmailAddress == CompromizedEmailAddress
| where Timestamp > ago(Timeframe)
| where Subject has_any (SuspiciousKeywords)
| where DeliveryAction == "Delivered"
| project Timestamp, SenderMailFromAddress, SenderFromAddress, SenderDisplayName, SenderMailFromDomain, SenderFromDomain, SenderIPv4, AttachmentCount, UrlCount, LatestDeliveryAction
| sort by Timestamp desc 

Summary

The queries above could cover a significant effort to investigate initial access for BEC attacks after an account has been compromised. Having said that, the investigation queries focus mainly on phishing attacks as the preliminary attack. Of course -as with all queries- they should be tested and fine tuned upon your environment to meet your needs and expectations.

You can check my GitHub to find further KQL queries that might be of your interest, also, drop me a line on X if you have any comments.

What is live response?

Live response allows security analysts to connect to an endpoint using a remote shell connection. It provides the means to perform in-depth investigations and materialize incident response actions.

Live response includes collecting forensic data, running scripts, sending suspicious entities for analysis, remediating threats, and proactively hunting for emerging threats.

Amongst others, you can:

• 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.
• Upload a PowerShell script or executable to the library and run it on a device from a tenant level.
• Take or undo remediation actions.

Step 1 – Create the PowerShell script

Unless you use any fancy text editor, simply open Notepad, insert the following script and save it as “Restart-Computer.ps1”.

Restart-Computer -Force

This script will skip the default confirmation and will proceed to restart the endpoint.

Step 2 – Commence a live response session

Navigate at the endpoint’s page and choose “Initiate Live Response Session”. Then, click on “Upload file to library”. Choose the script created at Step 1, add a distinctive description and click “Confirm”.

If you type “library” at the command prompt you should be able to see the file you uploaded with the following information:

• Filename
• Description
• Date/Time uploaded

Step 3 – Run the script

Now that you know your library content, you may run your script by using the following command:

run Restart-Computer.ps1

If everything worked as expected, your endpoint should be restarting.

Bonus Step – Verify restart

If you would like to be a step ahead, you may verify the endpoint’s restart action simply by creating and uploading a new PowerShell file with the following script in content:

systeminfo | find "System Boot Time"

Save it as “Restart-Computer-Verify.ps1”, upload it in the library and run it. You should be able to the result as per below.

Key takeaways

• Microsoft Defender for Endpoint live response is a powerful tool and this is a simple exercise to familiarize with the environment and the capability to run PowerShell scripts.
• I wouldn’t recommend adding scripts that are not necessary, in order to keep your library “clean” with the tools you need in case you commence an actual live response action.
• Always make sure you test and verify your scripts before adding them to your regular operations (and in your library of course) as it would be catastrophic to try and response while troubleshooting your scripts at the same time.

References

• Investigate entities on devices using live response
• Live response command examples

Be that as it may, it is important to keep a set of simple queries handy to be used immediately in case threat hunting or detecting is required to take place.

As presented through the query below, it is important to remember that KQL queries are build upon a simple principle: choose data – filter – present.

SigninLogs                              // Choose table
| TimeGenerated >= ago(7d)              // Set timeframe 
| where RiskLevelDuringSignIn == 'none' // Filter
| summarize Count = count() by city     // Summarize
| sort by Count desc                    // Sort
| take 5                                // Select

Reference

Before diving into the queries, please consider visiting my GitHub repo where I store queries built for many purposes including threat hunting and detecting.

Destination IP (with Port) or URL

If you are worried that endpoints might have contacted an IP (probably a CnC server) or a phishing URL, the following queries will do the job, just provide the IP address or the URL accordingly.

DeviceNetworkEvents 
| where RemoteIP == "insert destination IPv4 address here"
// optional filter if you want to define destination port as well
// | where RemotePort == "insert destination port number here"

DeviceNetworkEvents 
| where RemoteUrl has "insert URL here"

Email sender

If you are investigating a possible malware delivery through email, you can choose between SenderFromAddress, SenderIPv4 and SenderMailFromAddress to identify the spread of emails to other mailboxes:

• SenderFromAddress is the email address in the FROM header, which is visible to email recipients on their email clients
• SenderIPv4 is the sending server’s IP address
• SenderMailFromAddress is the email address in the MAIL FROM header, also known as the envelope sender or the Return-Path address

EmailEvents
// Choose one or more of the following options to detect malicious email deliveries
| where SenderFromAddress has "insert sender email here"
| where SenderIPv4 == "insert sending server IP here"
| where SenderMailFromAddress has "insert envelope sender email here"

Email attachment

If you already know the SHA256 hash of a malicious email attachment, the following query will detect relevant email deliveries.

EmailAttachmentInfo
| where SHA256 == "insert SHA256 hash here"

Local user sign in

If you are looking for a sign in activity in a local host based on a user or the host, the following query will do the job.

DeviceLogonEvents
// Choose to see local sign ins by host, or by username
// If you know the exact device name, you may use "has" instead of "contains"
| where DeviceName contains "insert part of device name here" 
| where AccountName == "insert the username here"

Cloud user sign in

There are cases where you might need to look into suspicious sign ins, an IP address or a source country accessing your Microsoft Cloud environment could be an incident precursor.

AADSignInEventsBeta 
| where IPAddress == "insert suspicious IP address here"
// To choose the Country, insert the ISO 3166 country code [https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes]
| where Country == "insert ISO country code"

File hash

If you need to search for a specific file hash, whether you have SHA256, SHA1 or MD5, you can use the following query to hunt.

DeviceFileEvents
// Replace SHA256 with SHA1 or MD5, depending on what you have available
| where SHA256 == "insert hash here"

Process injection

If you have a clue of a malicious activity involving process injection, or if you would like to hunt following a report you might have gone through, the following query could help you in your quest.

DeviceProcessEvents 
| where InitiatingProcessParentFileName contains "insert filename here"
| where InitiatingProcessFileName contains "insert filename here"

Closing remarks

The queries above, are the absolute basics. You can also consider others as well as fundamentals, but that depends on your environment setup. These queries should be on the back of your head for some quick searches, in case you are into some incident analysis and hunting. They could also be saved at your “Saved Queries” tab at Microsoft 365 Defender Advanced Hunting blade.

Hunting is a continuous process which involves a framework for development and consists of elements such as your environment, your risks, your possible attackers etc. You may find more on how to approach a framework like this, at my GitHub repo where I present both Microsoft’s and MITRE ATT&CK methodology.

Good luck hunting!