KQL

will be always updated

KQL (Kusto Query Language) is a query language used for reading and analyzing large volumes of data in Azure Data Explorer, Azure Monitor, Azure Sentinel, and similar platforms. It's designed to be simple and efficient for querying structured and unstructured data from logs and telemetry systems.

https://learn.microsoft.com/en-us/kusto/query/kql-learning-resources?view=azure-data-explorer

KQL Syntax Basics:

Retrieving Data: KQL is primarily used to run queries against a data source (like logs or metrics). Queries are structured in a pipeline, where data is retrieved and filtered, and then operations (like aggregation) are applied.

Example:

SecurityEvent
| where EventID == 4625
| project TimeGenerated, Computer, AccountName, LogonType

Key Operators:

  • where: Filters rows by a condition (similar to SQL’s WHERE).

  • project: Selects specific columns to display.

  • summarize: Aggregates data based on a specified function.

  • count(): Counts the number of occurrences.

Example:

SecurityEvent
| where TimeGenerated > ago(7d) and EventID == 4625
| summarize count() by AccountName

  1. Filtering and Time Constraints: KQL allows you to filter based on time ranges, using functions like ago() or exact timestamps.

Example:

AzureDiagnostics
| where TimeGenerated > ago(1h)

Pattern Matching: You can use operators like contains, startswith, and endswith for matching text patterns.

Example:

SecurityEvent
| where AccountName contains "admin"

Example

Queries for Security and Event Logs:

Failed Logon Attempts (Event ID 4625):

codeSecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by AccountName, IpAddress, Computer
| order by FailedAttempts desc

Scheduled Task Creation (Event ID 4698):

SecurityEvent
| where EventID == 4698
| project TimeGenerated, AccountName, TaskName, Computer

Task Scheduler Events Over the Last 24 Hours:

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID in (4698, 4699) // Task Created and Deleted
| project TimeGenerated, AccountName, TaskName, Computer

Using KQL for Task Scheduler Investigation:

For the log entry you provided about the creation of a scheduled task, you can use KQL to investigate more details in systems like Azure Sentinel or Log Analytics.

Example for Investigating Task Creation:

SecurityEvent
| where EventID == 4698
| where AccountName == "mdht.hh"
| where TaskName == "\\jhjhjhj"
| project TimeGenerated, Computer, AccountName, TaskName, LogonID

This query retrieves the event for task creation by mdht.hh, showing when and where the task was created.

gooo

1- Persistence via TelemetryController Scheduled Task Hijack

is a technique often used by attackers to maintain persistence on a Windows system. It involves modifying or hijacking a legitimate scheduled task to execute malicious payloads repeatedly. The TelemetryController scheduled task, typically used for collecting system telemetry data, becomes a target in this hijacking technique due to its legitimate appearance and regular execution.

Here’s a breakdown of the process:

TelemetryController Overview:

  • TelemetryController is a scheduled task that’s part of the Windows telemetry infrastructure, responsible for collecting diagnostic data and sending it to Microsoft.

  • This scheduled task is typically found in the Task Scheduler Library under Microsoft\Windows\Application Experience.

Hijacking Steps:

  1. Discover the TelemetryController Task:

    • Attackers look for the TelemetryController task, as it is a standard system task that won’t raise immediate suspicion.

    • It usually runs under the NT AUTHORITY\SYSTEM account, granting high privileges.

  2. Modify the Task:

    • The attacker modifies the action or triggers associated with the task.

    • Instead of running the legitimate telemetry-gathering process, the task is modified to execute a malicious payload (e.g., a PowerShell script or executable) at regular intervals.

  3. Persistence:

    • Once the scheduled task is hijacked, it ensures that the malicious code is executed regularly without the need for further manual intervention.

    • Since the task is system-scheduled and might not look suspicious, it often bypasses detection.

  4. Cleanup and Evasion:

    • Attackers may obfuscate or encrypt the payload to avoid detection by security software.

    • The original task name and settings might remain unchanged to avoid raising suspicion.

Mitigation:

  • Monitor Scheduled Tasks: Regularly monitor scheduled tasks for modifications or suspicious activity, especially those running under SYSTEM or other high-privilege accounts.

  • Task Auditing: Enable auditing of scheduled task creation and modification to detect unauthorized changes.

  • Use Security Software: Employ endpoint detection and response (EDR) solutions that can flag suspicious task hijacking attempts.

KQL ATP query

DeviceEvents
| where ActionType == "ScheduledTaskModified" or ActionType == "ScheduledTaskCreated"
| where AdditionalFields contains "Microsoft\\Windows\\Application Experience\\Microsoft Compatibility Appraiser"
| extend InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
| project Timestamp, DeviceName, AdditionalFields, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName
| order by Timestamp desc

2- Detecting High Number of File Rename Events

A high number of file rename events can be an indicator of suspicious activity, such as ransomware, which often renames files as part of its encryption process. Monitoring the volume of file rename operations across endpoints allows security teams to detect potential mass renaming or encryption, which could be malicious.

KQL Query to Detect High Number of File Renames:

DeviceFileEvents
| where ActionType == "FileRenamed"
| summarize RenamedFilesCount = count() by DeviceName, bin(Timestamp, 1h)
| where RenamedFilesCount > 100  // Adjust this threshold based on your environment
| project Timestamp, DeviceName, RenamedFilesCount
| order by RenamedFilesCount desc

3- 8220 Gang's Crypto Mining Indicators

The 8220 Gang is a threat actor group known for exploiting vulnerabilities in Linux and Windows systems to deploy cryptojacking malware. They primarily target cloud servers and other unpatched systems, leveraging weaknesses to gain access and install cryptocurrency miners. The group is named after the port 8220, which they frequently use for command-and-control (C2) communications.

The 8220 Gang’s attacks usually involve the following key tactics:

  • Exploitation of Vulnerabilities: They exploit known vulnerabilities in unpatched systems, especially in cloud environments.

  • Use of SSH Brute-Force Attacks: The group often uses SSH brute-forcing to gain access to servers with weak credentials.

  • Cryptojacking Malware: They deploy malicious cryptocurrency miners (usually XMRig) to utilize the system’s processing power to mine Monero (XMR).

  • Persistence Mechanisms: The attackers create persistence mechanisms such as cron jobs or scheduled tasks to ensure that their mining operations continue after system restarts.

  • Command and Control (C2): They use C2 servers for communication, often over ports like 8220.

Indicators of Compromise (IoCs):

  • Unusual Network Activity: High outbound traffic, especially to known crypto mining pools or C2 servers on port 8220.

  • High CPU Usage: Unexpected spikes in CPU usage, often caused by the XMRig miner.

  • Suspicious Scheduled Tasks or Cron Jobs: Creation of tasks or jobs that continuously run mining operations.

  • Files Related to XMRig: Files with names like xmrig, minerd, or similar crypto-mining software.

  • SSH Brute-Force Attempts: Large numbers of failed SSH login attempts followed by successful access.

KQL Query for Detecting 8220 Gang’s Crypto Mining Indicators:

1. Detect High CPU Usage from Crypto Mining (XMRig):

DevicePerformanceEvents
| where CounterName == "Processor" and InstanceName == "_Total"
| summarize AverageCpuUsage = avg(CounterValue) by DeviceName, bin(Timestamp, 5m)
| where AverageCpuUsage > 80  // Set CPU usage threshold (adjust if necessary)
| project Timestamp, DeviceName, AverageCpuUsage
| order by AverageCpuUsage desc

2. Detect Suspicious Scheduled Tasks/Cron Jobs Related to Crypto Mining:

DeviceEvents
| where ActionType == "ScheduledTaskCreated" or ActionType == "ScheduledTaskModified"
| where FileName contains "xmrig" or FileName contains "minerd" or FileName contains "cron"
| project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessCommandLine
| order by Timestamp desc

3. Detect Network Connections to Known Mining Pools or C2 Servers:

DeviceNetworkEvents
| where RemotePort == 8220 or RemoteIP  in ("Known IP addresses for mining pools or C2 servers")
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessCommandLine
| order by Timestamp desc

This query looks for connections to the C2 servers commonly used by 8220 Gang (such as port 8220) or known IP addresses of mining pools.

4. Detect SSH Brute-Force Attempts:

DeviceEvents
| where ActionType == "LogonFailed"
| summarize FailedAttempts = count() by AccountName, DeviceName, bin(Timestamp, 5m)
| where FailedAttempts > 20  // Adjust threshold based on your environment
| project Timestamp, DeviceName, AccountName, FailedAttempts
| order by FailedAttempts desc

5- Unusual Path of mpsvc

The technique T1059.003 (Windows Command and Scripting Interpreter) refers to the execution of scripts or binaries through uncommon or suspicious paths. In this case, mpsvc.exe, the Microsoft Protection Service (Windows Defender), might be used in an unusual path as part of an attack.

Attackers may attempt to use a legitimate executable like mpsvc.exe from an unusual path to bypass security controls. Windows systems trust binaries in certain directories (such as C:\Program Files\), so moving mpsvc.exe or creating a similar executable in an untrusted or unusual path may allow malicious execution without triggering alerts.

Key Indicators:

  • mpsvc.exe running from unusual paths: The legitimate path for mpsvc.exe is typically C:\Program Files\Windows Defender. Running it from other directories (e.g., C:\Temp\, C:\Users\<username>\AppData\Local\) is unusual and could be a sign of malicious activity.

  • Renaming of mpsvc.exe: Attackers may rename or relocate mpsvc.exe to execute a malicious binary under a trusted name.

KQL Query to Detect Unusual Execution of mpsvc:

DeviceFileEvents
| where FileName contains "MpSvc"
| where not(FolderPath has_any ("\\Program Files\\Windows Defender", "\\Windows\\System32"))
| where ActionType == "FileCreated"
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

Steps for Investigation:

  1. Validate the path: Verify whether the mpsvc.exe process is running from an expected location. If it's in an unusual directory, it warrants further investigation.

  2. Check the command line: Review the InitiatingProcessCommandLine to see how the process was started. Look for any suspicious arguments or behavior.

  3. Correlate with other events: Check for other suspicious activities such as modifications to system files, creation of persistence mechanisms (scheduled tasks, services), or network connections initiated by the process.

  4. Review file integrity: Check the integrity of mpsvc.exe to ensure it hasn’t been tampered with or replaced by a malicious binary

Additional Considerations:

Since MpSvc.dll is normally located in system-protected folders like C:\Program Files\Windows Defender, execution or presence of this DLL in any other directory should be considered suspicio

  • DLL Hijacking: Attackers might replace or load a fake MpSvc.dll to get executed by trusted system processes. This is a known method for bypassing application whitelisting and other defenses.

  • Code Injection: Ensure that the process loading MpSvc.dll isn’t being manipulated to execute injected code.

  • System Integrity: Use integrity checks to validate that core Windows Defender components like MpSvc.dll haven’t been tampered with.

6- Potential Tunneled Communication via WebSocket

WebSocket is a protocol designed to enable two-way communication between a client (such as a web browser) and a server. It's often used in real-time web applications like chats, live updates, etc. However, attackers can misuse WebSocket connections to tunnel other communication protocols or data, making it difficult for traditional network security tools to detect the content or malicious activity.

  • Tunneling via WebSocket: By encapsulating malicious or unauthorized traffic inside WebSocket frames, attackers can effectively bypass traditional network monitoring, which may not inspect WebSocket payloads.

  • Risk: WebSocket tunneling can be used for:

    • Command and Control (C2) communications.

    • Data exfiltration.

    • Exploiting services or web applications over legitimate WebSocket connections.

Steps to Detect Suspicious WebSocket Activity:

  1. Identify unusual WebSocket activity: WebSocket traffic is typically predictable in volume and type (e.g., small real-time messages). Large amounts of data being transferred via WebSocket could be a sign of tunneling.

  2. Look for anomalies in WebSocket communication: Abnormal destination IP addresses or domains, odd port usage, and sudden bursts of WebSocket connections are red flags.

  3. Examine WebSocket payloads: If the content of WebSocket messages does not match expected application behavior, it could indicate misuse for tunneling.

  4. Monitor WebSocket connection persistence: WebSockets are usually short-lived. Long-lived connections could indicate attempts to maintain persistence for malicious purposes.

Example Splunk Query:

index="network_logs" 
sourcetype="http"
method="CONNECT" 
uri="ws://*"
OR uri="wss://*"
| stats count by src_ip, dest_ip, uri, bytes_in, bytes_out
| where bytes_out > 1000000 OR bytes_in > 1000000

To detect potential tunneled communication via WebSocket in Microsoft Defender for Endpoint (ATP), you can use the Advanced Hunting feature with a Kusto Query Language (KQL) query.

DeviceNetworkEvents
| where RemoteUrl startswith "ws://" or RemoteUrl startswith "wss://"
| summarize ConnectionCount = count() by DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP, LocalPort
| where ConnectionCount > 10  // Threshold for multiple connections; adjust as needed
| project DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP, LocalPort, ConnectionCount
| order by ConnectionCount desc

```

7- Suspicious Processes with No Command Line (WerFault, gpupdate, Regsvr32, SearchProtocolHost)

The processes WerFault, gpupdate, Regsvr32, and SearchProtocolHost are legitimate Windows processes but can be abused by attackers for malicious purposes, often as part of Living Off the Land Binaries (LoLBins) attacks. These processes are used to execute system tasks, troubleshoot, or load libraries, making them useful tools for attackers who want to evade detection.

  • WerFault.exe: Windows Error Reporting service. Attackers may abuse it for process injection or to disguise malicious activity.

  • gpupdate.exe: Group Policy Update tool. Abnormal use could signal an attacker is trying to change group policies without administrative oversight.

  • Regsvr32.exe: Tool used to register DLLs. Attackers often use it to execute scripts or load malicious DLLs, particularly via proxy execution.

  • SearchProtocolHost.exe: Used by Windows Search Indexer. Abnormal usage could indicate data exfiltration or misuse by attackers.

Suspicious Activity: These processes running without a command line (i.e., no associated arguments or parameters) may suggest that they are being leveraged in a stealthy way to avoid detection.

Microsoft Defender ATP (KQL) query to detect these processes running without command line arguments.

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("WerFault.exe", "gpupdate.exe", "Regsvr32.exe", "SearchProtocolHost.exe")
| where isnull(ProcessCommandLine) or ProcessCommandLine == ""
| summarize ProcessCount = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by DeviceName, FileName, InitiatingProcessAccountName, InitiatingProcessFileName, ProcessId
| project DeviceName, FileName, ProcessId, InitiatingProcessAccountName, InitiatingProcessFileName, ProcessCount, FirstSeen, LastSeen
| order by ProcessCount desc

8- Non-Baselined Child Process of Winlogon

Winlogon.exe is a critical system process in Windows responsible for handling user logins, managing user sessions, and handling certain aspects of the Windows logon process. It is an important target for attackers because it's a highly trusted process, and running malicious processes as children of Winlogon can allow attackers to hide their activities and evade detection.

  • Legitimate Role: Winlogon handles tasks such as loading the user's profile and launching system-critical processes like userinit.exe.

  • Abuse by Attackers: If an attacker can spawn a non-baselined (unexpected) child process under Winlogon.exe, it might be indicative of process injection, privilege escalation, or persistence mechanisms.

The term "non-baselined" refers to processes that are not typically spawned by Winlogon.exe, meaning their appearance could signal an anomalous or malicious activity.

Suspicious Behavior:

  • Malicious processes spawned by Winlogon are rare and often indicate that an attacker is trying to exploit its privileged position to execute unauthorized or malicious code.

  • Process injection or spawning unexpected child processes from Winlogon can allow attackers to bypass security controls.

Microsoft Defender ATP (KQL) query that detects child processes spawned by Winlogon.exe that are not part of the normal baseline:

DeviceProcessEvents
| where InitiatingProcessFileName == "winlogon.exe"
| summarize ChildProcessCount = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by DeviceName, FileName, ProcessCommandLine, InitiatingProcessAccountName, InitiatingProcessFileName, ProcessId
| where FileName !in ("userinit.exe", "explorer.exe", "taskhost.exe") // Common child processes of winlogon.exe
| project DeviceName, FileName, ProcessCommandLine, InitiatingProcessAccountName, InitiatingProcessFileName, ProcessId, ChildProcessCount, FirstSeen, LastSeen
| order by ChildProcessCount desc

9- Reconnaissance

Reconnaissance is the first phase of a cyberattack, where attackers gather information about a target's environment to find weaknesses they can exploit. In the context of network security, reconnaissance often includes:

  1. Port Scanning: Scanning for open ports to identify services running on target systems.

  2. Network Scanning: Discovering hosts, devices, and systems on the network.

  3. Service and Version Enumeration: Identifying services and their versions to look for vulnerabilities.

  4. Credential Scanning: Attempting to enumerate user accounts or services to gain information about valid credentials.

  5. Directory or File Enumeration: Gaining access to shared files or directories by probing services like SMB.

Reconnaissance is often performed using tools like Nmap, Netcat, or through scripted methods to probe targets in a stealthy manner. Early detection of reconnaissance activities can prevent attackers from progressing to more damaging phases of their attack, like exploitation or privilege escalation.

Here is a Microsoft Defender ATP (KQL) query that can detect typical reconnaissance patterns such as port scanning, network scanning, and suspicious enumeration activity.

DeviceNetworkEvents
| where RemotePort in (21, 22, 23, 53, 80, 443, 3389, 445, 1433, 3306, 5900, 8080) // Commonly scanned ports
| summarize ConnectionAttempts = count(), DistinctIPs = dcount(RemoteIP) by DeviceName, InitiatingProcessFileName, RemoteIP, LocalPort
| where ConnectionAttempts > 100 or DistinctIPs > 10
| project DeviceName, InitiatingProcessFileName, RemoteIP, LocalPort, ConnectionAttempts, DistinctIPs
| order by ConnectionAttempts desc

---------

Query for Port Scanning Detection:

DeviceNetworkEvents
| summarize PortCount = dcount(LocalPort) by DeviceName, InitiatingProcessFileName, RemoteIP
| where PortCount > 10
| project DeviceName, InitiatingProcessFileName, RemoteIP, PortCount
| order by PortCount desc

This query detects cases where a remote IP or process is attempting to scan multiple ports on a target device, which is indicative of port scanning.

Query for Network Scanning:

DeviceNetworkEvents
| where ActionType == "ConnectionSuccess" and InitiatingProcessFileName != ""
| summarize HostCount = dcount(RemoteIP) by DeviceName, InitiatingProcessFileName
| where HostCount > 10
| project DeviceName, InitiatingProcessFileName, HostCount
| order by HostCount desc

This query detects attempts to scan multiple hosts on the network by identifying large numbers of successful connections from a single process or device.

common reconnaissance tools or commands like ping, net, and dir are used to:

  • ping: Determine if hosts are alive and reachable on the network.

  • net user/net group/net view: Enumerate user accounts, groups, and shared resources.

  • dir: List files and directories, often used to discover sensitive information or misconfigured directories.

Attackers typically use these tools as part of the reconnaissance or discovery phase to map out the environment and understand the layout, services, and user accounts on the target system.

Microsoft Defender ATP (KQL) query designed to detect suspicious usage of commands like ping, net, dir, and other common reconnaissance tools:

DeviceProcessEvents
| where ProcessCommandLine has_any ("ping", "net user", "net group", "net view", "net localgroup", "net session", "net share", "dir", "ipconfig", "whoami")
| summarize Count = count() by DeviceName, InitiatingProcessAccountName, ProcessCommandLine, InitiatingProcessFileName, ProcessCreationTime
| project DeviceName, InitiatingProcessAccountName, ProcessCommandLine, InitiatingProcessFileName, ProcessCreationTime, Count
| order by ProcessCreationTime desc

Detecting arp, route, and other Network Discovery Commands:

DeviceProcessEvents
| where ProcessCommandLine has_any ("arp", "route", "tracert", "nslookup", "netstat", "ipconfig")
| summarize Count = count() by DeviceName, InitiatingProcessAccountName, ProcessCommandLine, ProcessCreationTime
| project DeviceName, InitiatingProcessAccountName, ProcessCommandLine, ProcessCreationTime, Count
| order by ProcessCreationTime desc

This query will detect the use of network discovery commands such as arp, route, tracert, nslookup, and netstat, which are often used to probe and discover network details.

What to Investigate:

  • Abnormal Usage of Reconnaissance Commands: Investigate instances where these commands are run by unexpected users or processes, particularly on sensitive systems.

  • Unexpected Accounts: Check for the use of system or administrative accounts running these commands, as they may indicate privilege escalation or lateral movement attempts.

  • Frequent Execution: Multiple occurrences of these commands in a short period of time could indicate active probing or enumeration activities.

10- Detecting Multiple TXT/ZIP File Creations by the Same Process

Creating multiple TXT or ZIP files in a short period by the same process can be an indicator of suspicious activity, such as:

  • Data exfiltration: Attackers often compress data into ZIP files before exfiltrating it.

  • Script-based automation: Malicious scripts could create multiple text files as part of reconnaissance, logging, or preparing data for further attack stages.

  • Ransomware: Some types of ransomware create large numbers of files (including .txt or .zip) to either lock or log data for further exploitation.

By monitoring file creation events for patterns of multiple .txt or .zip files being created by the same process, we can potentially detect malicious activity.

Detection Strategy:

We will track processes that create multiple .txt or .zip files in a short time, which could signal suspicious file generation. The detection will focus on:

  • Counting the number of .txt or .zip files created by a single process.

  • Flagging processes that exceed a threshold of file creation activity within a defined period.

KQL Query for Detecting Multiple TXT/ZIP File Creations by the Same Process

DeviceFileEvents
| where FileName endswith ".txt" or FileName endswith ".zip"
| summarize FileCount = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) 
  by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, InitiatingProcessId
| where FileCount > 5  // Threshold: More than 5 files created
| project DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, InitiatingProcessId, FileCount, FirstSeen, LastSeen
| order by FileCount desc

summarize FileCount = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp):

  • Counts how many .txt or .zip files were created by each process (FileCount).

  • Captures the first and last timestamps when files were created by the same process.

Customization Options:

  • Threshold: You can adjust the threshold in where FileCount > 5 to fit your environment’s normal file creation patterns.

  • File Types: Modify the query to include or exclude different file types based on what you consider suspicious (e.g., .log, .csv, etc.).

Additional Query for Monitoring File Creation in a Specific Time Window:

To focus on processes that created multiple .txt or .zip files within a short period (e.g., within 10 minutes), you can add a condition to the time window:

DeviceFileEvents
| where FileName endswith ".txt" or FileName endswith ".zip"
| summarize FileCount = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp), DurationMinutes = (max(Timestamp) - min(Timestamp)) / 1min 
  by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, InitiatingProcessId
| where FileCount > 5 and DurationMinutes < 10  // Threshold: More than 5 files created within 10 minutes
| project DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, InitiatingProcessId, FileCount, FirstSeen, LastSeen, DurationMinutes
| order by FileCount desc

  • DurationMinutes: Calculates the time difference in minutes between the first and last file creation event.

  • where DurationMinutes < 10: Filters to only include processes that created files within a 10-minute window, potentially signaling abnormal behavior.

What to Investigate:

  • High File Creation Rate: Investigate processes that create multiple .txt or .zip files in a short amount of time, as this could indicate automated processes or data exfiltration attempts.

  • Suspicious Processes: Look for processes that normally wouldn’t create large numbers of files, such as browsers, email clients, or scripts that don’t typically generate such files.

  • Unusual Users: If the initiating process account is an unexpected or non-administrative user, it could indicate unauthorized activity.

---------

11 - Conhost Spawning Non-Baselined Processes

The Console Window Host process (conhost.exe) is a legitimate Windows process responsible for handling command-line operations in conjunction with cmd.exe and other console-based applications. Normally, conhost.exe is associated with legitimate tasks like running command prompts, PowerShell, or other console-based scripts.

However, attackers can exploit conhost.exe to spawn malicious or non-baselined processes, allowing them to run scripts or malware in a less obvious way. A non-baselined process means that the process spawned by conhost.exe is unexpected, unusual, or not part of the system's normal operations, indicating potential malicious activity.

Detection Strategy:

The goal is to detect when conhost.exe spawns processes that deviate from the normal baseline of expected processes. These non-baselined processes could be indicative of malware, command execution, or malicious scripts that attackers are trying to run using conhost.exe as a parent.

KQL Query to Detect Conhost Spawning Non-Baselined Processes:

DeviceProcessEvents
| where InitiatingProcessFileName == "conhost.exe"
| summarize NonBaselineProcessCount = dcount(FileName), DistinctCommandLines = dcount(ProcessCommandLine)
  by DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| where NonBaselineProcessCount > 1 and DistinctCommandLines > 1
| project DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, FileName, ProcessCommandLine, NonBaselineProcessCount, DistinctCommandLines
| order by NonBaselineProcessCount desc

gsummarize NonBaselineProcessCount = dcount(FileName), DistinctCommandLines = dcount(ProcessCommandLine):

  • Counts the number of distinct processes spawned by conhost.exe (NonBaselineProcessCount).

  • Counts the distinct command lines used by these processes (DistinctCommandLines), indicating variation in execution.

where NonBaselineProcessCount > 1 and DistinctCommandLines > 1: Filters for cases where conhost.exe is spawning more than one distinct process or executing different command lines, which could indicate non-baselined or unusual activity.

What to Investigate:

  • Non-Baselined Processes: Investigate any processes launched by conhost.exe that aren't typically expected, such as unknown executables or scripts.

  • Command Lines: Pay attention to processes spawned with unusual or unexpected command lines, as this could indicate malicious script execution.

  • Initiating Accounts: Check which user accounts or services are responsible for running conhost.exe, especially if non-administrative accounts are spawning unusual processes.

Additional Query to Identify All Non-Baselined Child Processes of conhost.exe:

To detect all non-baselined child processes launched by conhost.exe that may deviate from normal behavior, we can also focus on whether the parent process of conhost.exe is legitimate or unusual.

DeviceProcessEvents
| where InitiatingProcessFileName == "conhost.exe"
| summarize ChildProcessCount = count(), DistinctCommandLines = dcount(ProcessCommandLine)
  by DeviceName, FileName, InitiatingProcessParentFileName, InitiatingProcessAccountName
| where ChildProcessCount > 1 and InitiatingProcessParentFileName != "explorer.exe"  // Exclude normal parents like explorer.exe
| project DeviceName, InitiatingProcessAccountName, FileName, InitiatingProcessParentFileName, ChildProcessCount, DistinctCommandLines
| order by ChildProcessCount desc

where ChildProcessCount > 1 and InitiatingProcessParentFileName != "explorer.exe": Filters for processes where conhost.exe is spawning more than one process, excluding those initiated by normal parents like explorer.exe.

What to Investigate:

  • Abnormal Parent Processes: Check if conhost.exe was initiated by unexpected processes, especially scripts or malware (e.g., powershell.exe or suspicious scripts).

  • Multiple Child Processes: If conhost.exe spawns many child processes in a short time, this could indicate malicious activity, such as command-line script execution or malware launching multiple instances.

----

12- Browser Extensions and Security

Browser extensions are add-ons that enhance the functionality of web browsers by providing additional features such as ad-blocking, password management, and productivity tools. However, browser extensions can pose significant security risks if they are malicious or compromised. Attackers may use malicious browser extensions to:

  • Spy on browsing activity: Extensions can read and modify web content, track browsing behavior, or steal sensitive information such as login credentials or credit card details.

  • Inject malicious scripts: Some extensions can modify web pages or inject JavaScript to execute malicious code in the context of legitimate websites.

  • Communicate with remote servers: Extensions may establish hidden communication channels with command-and-control (C2) servers for data exfiltration or other malicious activities.

  • Act as persistence mechanisms: Extensions can be used to maintain persistence on a compromised system since they are not always subject to traditional security controls.

Detection Strategy:

The goal is to monitor and identify suspicious or malicious browser extensions installed on endpoints by analyzing extension activity, usage patterns, and communication behavior.

Query to Detect Browser Extensions Using ATP (KQL)

To monitor for suspicious browser extensions on endpoints, you can use Microsoft Defender ATP (KQL) to detect extensions and their activity. This query will check for the execution of popular browsers along with known extension directories (e.g., Chrome, Firefox) and focus on browser-related activity.

DeviceProcessEvents
| where FileName in~ ("chrome.exe", "firefox.exe", "msedge.exe", "opera.exe")
| extend BrowserPath = FolderPath
| summarize ExtensionCount = count() by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, BrowserPath
| project DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, BrowserPath, ExtensionCount
| order by ExtensionCount desc
```

Monitoring Browser Extension Activity:

To track the installation and execution of suspicious extensions, you can monitor browser directories such as:

  • Chrome: Extensions are typically stored in the C:\Users\[USERNAME]\AppData\Local\Google\Chrome\User Data\Default\Extensions directory.

  • Firefox: Extensions are stored in C:\Users\[USERNAME]\AppData\Roaming\Mozilla\Firefox\Profiles\[PROFILE]\extensions.

  • Edge: For Edge, extensions are stored in C:\Users\[USERNAME]\AppData\Local\Microsoft\Edge\User Data\Default\Extensions.

Example Query to Track Extension Installation in Chrome:

DeviceFileEvents
| where FolderPath has "Google\\Chrome\\User Data\\Default\\Extensions"
| summarize ExtensionInstallCount = count() by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, FileName, FolderPath
| project DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, FileName, FolderPath, ExtensionInstallCount
| order by ExtensionInstallCount desc

What to Investigate:

  • New or unknown extensions: Investigate newly installed extensions or those with unknown functionality.

  • Unusual communication patterns: Extensions communicating with unfamiliar external IP addresses or domains could signal data exfiltration or malicious behavior.

  • Abnormal permissions: Check for extensions that request excessive permissions (e.g., reading all website data, access to clipboard or sensitive data).

---

13- Spoofed Privileged Parent Process Detection

Parent process spoofing is a technique used by attackers to make malicious processes appear as though they were initiated by a trusted or privileged process. This can be used to bypass security mechanisms that rely on parent-child process relationships to detect anomalies. By spoofing or mimicking a high-privilege parent process like winlogon.exe, explorer.exe, or services.exe, attackers attempt to hide their activity, escalate privileges, or persist on a compromised system.

Common privileged processes that attackers may attempt to spoof include:

  • winlogon.exe: Handles user logins and desktop session initialization.

  • explorer.exe: The Windows desktop and file management process.

  • services.exe: Manages system services that run in the background.

Detecting such spoofing involves identifying unusual child processes spawned by these privileged processes or any behavior inconsistent with the expected activity.

Detection Strategy

We aim to identify child processes spawned by privileged parent processes that do not align with normal baseline activity. This could include unusual command-line parameters, unexpected child processes, or multiple parent processes spawning the same child process inconsistently.

KQL Query for Microsoft Defender ATP (Advanced Hunting)

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("winlogon.exe", "explorer.exe", "services.exe", "lsass.exe") 
| summarize ParentProcessCount = dcount(InitiatingProcessFileName), DistinctCommandLines = dcount(ProcessCommandLine)
  by DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName
| where ParentProcessCount > 1 or DistinctCommandLines > 1
| project DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName, ParentProcessCount, DistinctCommandLines
| order by ParentProcessCount desc

where InitiatingProcessFileName in~ ("winlogon.exe", "explorer.exe", "services.exe", "lsass.exe"): This filters the processes to focus on those initiated by privileged parent processes such as winlogon.exe, explorer.exe, services.exe, or lsass.exe.

summarize ParentProcessCount = dcount(InitiatingProcessFileName), DistinctCommandLines = dcount(ProcessCommandLine):

  • ParentProcessCount counts how many different parent processes have launched the same child process.

  • DistinctCommandLines counts how many distinct command lines have been used to launch the child process, which can indicate anomalous or malicious behavior.

where ParentProcessCount > 1 or DistinctCommandLines > 1: Filters for processes that have either multiple parent processes or have been run with multiple distinct command lines.

What to Investigate:

  • Multiple Parent Processes: Check for processes launched by more than one parent process, particularly if the parent processes are privileged or uncommon.

  • Distinct Command Lines: Investigate any process launched with multiple distinct command lines, which may indicate process spoofing or varying malicious execution.

  • Privileged Parents: Focus on processes initiated by highly trusted system processes like winlogon.exe or services.exe that should not spawn unusual or unexpected child processes.

dditional Query to Detect Suspicious Child Processes of Any Parent Process

If you want to broaden the scope to detect child processes spawned by any parent process exhibiting suspicious behavior, we can adjust the query accordingly.

DeviceProcessEvents
| summarize ParentProcessCount = dcount(InitiatingProcessFileName), DistinctCommandLines = dcount(ProcessCommandLine)
  by DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName
| where ParentProcessCount > 1 or DistinctCommandLines > 1
| project DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName, ParentProcessCount, DistinctCommandLines
| order by ParentProcessCount desc

  1. where ParentProcessCount > 1 or DistinctCommandLines > 1: Filters out processes that were initiated by more than one parent or have been executed with different command lines. This indicates inconsistent or suspicious behavior.

What to Investigate:

  • Multiple Parent Processes: Child processes that have been spawned by more than one parent process, especially privileged processes, should be investigated for potential spoofing.

  • Distinct Command Lines: Examine processes with varying command lines, as this might indicate malicious scripts or attempts to mask behavior.

  • Suspicious Child Processes: Investigate processes that typically aren't associated with privileged parents (e.g., unknown executables being spawned by winlogon.exe or services.exe)

Further Customization:

Specific Devices or Users: If you want to focus on specific devices or user accounts, you can filter by DeviceName or InitiatingProcessAccountName:

| where DeviceName == "TargetDevice" or InitiatingProcessAccountName == "TargetUser"

File Hash Information: If available, include file hashes to facilitate threat intelligence lookups:

| project DeviceName, FileName, SHA256, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName

14- Files Added to Windows Defender Exclusion List (Registry)

Windows Defender allows users to add files, folders, file types, and processes to an exclusion list, preventing them from being scanned by antivirus protection. This feature can be manipulated by malware to avoid detection. When files are added to the exclusion list, specific changes occur in the Windows Registry, which can be monitored for suspicious activity.

The relevant Registry keys for Defender exclusions are typically found under:

  • Files: HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths

  • Processes: HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Processes

  • Extensions: HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Extensions

Monitoring these keys for unexpected modifications can help detect malicious activity that is attempting to evade Windows Defender.

KQL (Kusto Query Language) query for Microsoft Defender Advanced Threat Protection (ATP) that detects when items are added to the Windows Defender exclusion list:

DeviceRegistryEvents
| where RegistryKey has @"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions"
| where ActionType == "RegistryValueSet" or ActionType == "RegistryKeyCreated"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RegistryKey, RegistryValueName, RegistryValueData
| sort by Timestamp desc

---------

15 - New DNS over HTTPS Activity

DNS over HTTPS (DoH) encrypts DNS queries using HTTPS, enhancing user privacy by preventing eavesdropping and tampering. However, this feature can be abused by threat actors to hide malicious activities, such as exfiltrating data or bypassing network monitoring. Detecting new or unusual DoH activity is crucial to identify potential misuse by malware, unauthorized applications, or data exfiltration attempts.

KQL query can be used in Microsoft Defender for Endpoint:

DeviceNetworkEvents
| where RemotePort == 443  // Filtering HTTPS traffic
| where (RemoteIP in ("1.1.1.1", "8.8.8.8", "9.9.9.9", "185.228.168.168", "208.67.222.222")) // Known DoH server IPs
    or RemoteUrl has_cs "dns.google" 
    or RemoteUrl has_cs "cloudflare-dns.com" 
    or RemoteUrl has_cs "dns.quad9.net" 
    or RemoteUrl has_cs "dns.opendns.com" 
| project Timestamp, DeviceName, LocalIP , RemoteIP, RemotePort, RemoteUrl, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc

When investigating DoH activity, consider the following aspects to distinguish between legitimate and potentially malicious usage:

  1. Unusual or Unauthorized Applications:

    • What to focus on: Check the InitiatingProcessFileName and InitiatingProcessCommandLine for unfamiliar applications using DoH.

    • Why: Legitimate DoH activity is generally associated with known browsers (e.g., Chrome, Firefox) or network tools. Any unexpected or unknown processes initiating DoH traffic could indicate malicious software attempting to evade detection.

  2. Known Malicious DoH Endpoints:

    • What to focus on: Cross-check the DoH server IPs or domains against threat intelligence databases to identify if they are associated with malicious activities.

    • Why: Cyber attackers may set up custom DoH servers to bypass network defenses. Connections to known malicious servers are strong indicators of compromise.

  3. Frequency and Volume of DoH Requests:

    • What to focus on: Monitor the number of DoH requests from a device and the frequency.

    • Why: High-frequency or large volumes of DNS requests could indicate malicious software attempting to communicate with a command-and-control (C2) server or conducting data exfiltration.

  4. New or Unfamiliar DoH Endpoints:

    • What to focus on: Identify new or unusual DoH servers not previously observed on the network.

    • Why: New or unexpected endpoints may indicate an attempt by malicious software to use custom DoH servers for hiding communication.

  5. Correlation with Other Suspicious Activities:

    • What to focus on: Look for related events, such as:

      • Unusual file executions.

      • Changes in registry settings (e.g., Windows Defender exclusions).

      • Unexpected network traffic patterns.

    • Why: DoH activity often correlates with other suspicious behaviors, indicating a potential compromise or malware infection.

  6. Endpoint Location and User Behavior:

    • What to focus on: Examine the device and user behavior related to the DoH activity.

    • Why: Devices not typically associated with internet browsing (e.g., servers) initiating DoH queries could indicate compromise.

  7. Blocking Unapproved DoH Providers:

    • What to focus on: Maintain an allowlist of approved DoH providers in your environment and block others.

    • Why: Blocking unauthorized DoH providers and monitoring attempts to use them can highlight potential malicious activities trying to evade security controls.

By focusing on these investigation points, you can better analyze DNS over HTTPS activity and identify potential security incidents in your network environment.

16 - New Account Created

The creation of a new account on a system, especially when not authorized, can be a potential security threat. Attackers often use this technique to establish persistence in a compromised environment, gain lateral movement capabilities, or elevate their privileges within a network. The steps involved in this attack typically include:

  1. Compromising an Initial Account: Attackers may initially gain access to a system through various methods such as phishing, exploiting vulnerabilities, or using stolen credentials.

  2. Creating a New Account: After compromising the system, they create a new account. This allows them to maintain access even if the initial point of compromise is detected and blocked.

  3. Privileged Account Creation: Often, the newly created account is assigned elevated privileges to execute more harmful operations like accessing sensitive data, executing administrative tasks, or spreading across the network.

  4. Persistence and Evasion: By using a legitimate-looking account, attackers can persist in the environment while evading detection by traditional security monitoring.

KQL Query for Advanced Hunting in Microsoft Defender ATP

DeviceEvents
| where ActionType == "UserAccountCreated"
| project Timestamp, DeviceName, AccountName, InitiatingProcessAccountName, InitiatingProcessAccountDomain , AdditionalFields
| sort by Timestamp desc

Enhancing Detection

You can enhance this query by:

  • Filtering for accounts created outside of working hours.

  • Flagging accounts created by non-administrative users.

  • Searching for accounts created on critical systems (e.g., domain controllers).

1. Detect Accounts Created Outside Working Hours

This query checks for new user accounts created outside typical working hours (e.g., 8 AM - 6 PM). Adjust the time range as needed for your organization.

DeviceEvents
| where ActionType == "UserAccountCreated"
| where hourofday(Timestamp) < 8 or hourofday(Timestamp) > 18  // Outside 8 AM - 6 PM
| project Timestamp, DeviceName, AccountName, AccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountDomain, AdditionalFields
| sort by Timestamp desc

2. Detect Accounts Created by Non-Administrative Users

This query flags new accounts that were created by accounts not typically involved in administrative tasks. Replace "AdminUser1" and "AdminUser2" with the names of known admin accounts in your environment.

DeviceEvents
| where ActionType == "UserAccountCreated"
| where InitiatingProcessAccountName !in ("AdminUser1", "AdminUser2")  // Replace with known admin accounts
| project Timestamp, DeviceName, AccountName, AccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountDomain, AdditionalFields
| sort by Timestamp desc

3. Detect Accounts Created on Critical Systems (e.g., Domain Controllers)

This query identifies new user creation on critical devices such as domain controllers. Replace "DomainController1", "DomainController2" with the names of your critical systems.

DeviceEvents
| where ActionType == "UserAccountCreated"
| where DeviceName in ("DomainController1", "DomainController2")  // Replace with your critical system names
| project Timestamp, DeviceName, AccountName, AccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountDomain, AdditionalFields
| sort by Timestamp desc

4. Detect High-Privilege Accounts Creation

This query detects new accounts that are assigned to high-privilege groups such as "Administrators". You might need to check AdditionalFields to find group information.

DeviceEvents
| where ActionType == "UserAccountCreated"
| where AdditionalFields contains "Administrators"  // Modify as per the field containing group info
| project Timestamp, DeviceName, AccountName, AccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountDomain, AdditionalFields
| sort by Timestamp desc

17 - Inhibiting System Recovery

Attackers often attempt to inhibit system recovery to ensure their malicious activities (like ransomware) cannot be easily reversed. Common tools like vssadmin, wmic, wbadmin, and bcdedit are often misused to delete system backups, disable Volume Shadow Copy Service (VSS), or modify boot configurations. Here’s a quick rundown of each tool:

  • vssadmin: A command-line utility that manages volume shadow copies (system backups). Attackers may use vssadmin to delete shadow copies and prevent recovery.

  • wmic: Windows Management Instrumentation Command-line (WMIC) allows administrators to perform various management tasks. Attackers might use WMIC commands to disable shadow copies or backups.

  • wbadmin: A command-line utility for managing Windows backups. It can be used to delete backup catalogs and disable backup services.

  • bcdedit: A tool for managing Boot Configuration Data (BCD) stores. Attackers use bcdedit to modify boot configurations, which can hinder recovery efforts.

Detection Strategy

Detecting the misuse of these commands involves monitoring the command line activity for specific keywords or actions associated with disabling or deleting backups, modifying boot configurations, or disabling recovery options. This strategy relies on detecting command execution patterns that align with known malicious activities:

  1. Command Execution: Monitor for the execution of vssadmin, wmic, wbadmin, or bcdedit.

  2. Suspicious Commands: Identify specific command patterns that are often used for malicious purposes, such as:

    • vssadmin delete shadows

    • wbadmin delete catalog

    • bcdedit /set {default} recoveryenabled No

    • wmic shadowcopy delete

  3. Contextual Information: Investigate the user account, process, or originating system involved in executing these commands to differentiate legitimate use from potential malicious activity.

you can use Microsoft Defender ATP's advanced hunting capabilities to detect the use of these tools. Here's a sample query to identify potential misuse:

DeviceProcessEvents
| where ProcessCommandLine contains "vssadmin" 
    or ProcessCommandLine contains "wmic"
    or ProcessCommandLine contains "wbadmin"
    or ProcessCommandLine contains "bcdedit"
| where ProcessCommandLine matches regex @"(?i)(delete|resize|shadow|catalog|disable|reset|restore)"
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName, AccountDomain
| sort by Timestamp desc

  • matches regex: Identifies specific command patterns that indicate potential malicious activity (e.g., delete, disable, reset).

What to Investigate

When this query returns results, investigate the following details:

  1. Process Details: Examine the full command line to understand what action was performed. For example, vssadmin delete shadows /all /quiet indicates the deletion of all volume shadow copies.

  2. Initiating Process: Look into the parent process (InitiatingProcessFileName) to identify if the action was executed by a legitimate process or a suspicious one (e.g., powershell.exe spawned by an unknown script).

  3. User Account: Check the AccountName and AccountDomain to identify the user who executed the command. Determine if this user has legitimate reasons for performing this action.

  4. Device Context: Review the DeviceName and cross-reference it with recent activities on that device. Look for signs of compromise, such as the presence of malware, unusual network connections, or privilege escalations.

  5. Timeline Correlation: Correlate the timestamp of the event with other security alerts, such as suspicious file activity, network anomalies, or endpoint detections, to see if it aligns with broader attack patterns.

  6. Process Ancestry: Check the ancestry of the process to understand if it was executed by another suspicious process, which might indicate script-based attacks (e.g., powershell.exe or cmd.exe spawning vssadmin.exe).

18-

PreviousRandom NotesNextHunting with ATP

Last updated