PLease Correct the XQL query I have Created for the objective

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PLease Correct the XQL query I have Created for the objective

L1 Bithead

Hi Community,

 

I want to implement this objective so developed two queries with regex and non regex but it is giving tons of logs, can anyone help me on fine tuning or change the queries or correct them. Thank you

 Destructive Wipe / Anti‑Recovery Utilities 

Objective 

To detect destructive actions where adversaries attempt to wipe data or remove recovery options by invoking tools and commands associated with file wiping, shadow copy deletion, log clearing, and backup removal. By correlating processes that exhibit destructive intent with command‑line patterns linked to anti‑recovery behavior, the hunt surfaces early indicators of system‑wipe preparation and evidence‑removal tactics. This aligns with T1561.002 (Disk Structure Wipe) and T1070 (Indicator Removal). 

 

Query 

dataset = xdr_data  

  

| filter event_type = ENUM.PROCESS  

  

| filter action_process_image_name in ("cipher.exe","robocopy.exe","wevtutil.exe","vssadmin.exe","fsutil.exe","sdelete.exe","wbadmin.exe")  

  

| filter lowercase(action_process_image_command_line) ~= "(?i)(cipher\\s+/w:|sdelete|robocopy.+/mir|wevtutil\\s+cl\\s+|vssadmin\\s+delete\\s+shadows|wbadmin\\s+delete)"  

  

| fields _time, agent_hostname, actor_process_image_name, action_process_image_name,  

  

         action_process_image_command_line, action_username  

  

| sort desc _time 

 

Without regex: 

dataset = xdr_data 

| filter event_type = ENUM.PROCESS 

| filter action_process_image_name in ("cipher.exe","robocopy.exe","wevtutil.exe","vssadmin.exe","fsutil.exe","sdelete.exe","wbadmin.exe") 

| filter ( 

      lowercase(action_process_image_command_line) contains "cipher /w:" 

   or lowercase(action_process_image_command_line) contains "sdelete" 

   or lowercase(action_process_image_command_line) contains "/mir" 

   or lowercase(action_process_image_command_line) contains "wevtutil cl " 

   or lowercase(action_process_image_command_line) contains "vssadmin delete shadows" 

   or lowercase(action_process_image_command_line) contains "wbadmin delete" 

) 

| fields _time, agent_hostname, actor_process_image_name, action_process_image_name, 

         action_process_image_command_line, action_username 

| sort desc _time 

 

 

1 accepted solution

Accepted Solutions

L5 Sessionator

Hello @N.B238890 ,

 

Greetings for the day.

 

How can signer information (actionprocesssignaturevendor, actionprocesssignatureproduct) and integrity levels be used in XQL to differentiate between authorized system processes and suspicious activity?

In Cortex XDR, signer information and integrity levels can be combined in XQL to distinguish between legitimate system activity and potentially malicious behavior. These fields help establish both the trustworthiness of a binary and the privilege level at which it operates.

Using Signer Information to Establish Trust:

Signer-related fields help determine whether a process originates from a trusted source.

Key fields:

  • action_process_signature_vendor: The name of the vendor that signed the binary (for example, "Microsoft Corporation")

  • action_process_signature_product: The product family associated with the signature

How this helps:

  • Reduce noise: You can exclude known trusted vendors (such as Microsoft or approved enterprise tools) to focus on unusual activity.

  • Detect masquerading: A process using a legitimate system name (like svchost.exe) but marked as unsigned (action_process_signature_status = 3) is suspicious.

  • Ensure accuracy: Vendor name matching in XQL must be exact. Even small differences in punctuation or formatting can cause filters to fail.

  • Handle edge cases: On some systems (like macOS), vendor names may appear truncated, requiring broader matching logic.

Using Integrity Levels to Identify Elevation

Integrity levels indicate the privilege context of a process and are represented as integers in XQL.

Common values:

  • 0: Low / Untrusted

  • 4096: Medium (standard user)

  • 8192: High (elevated / administrator)

  • 16384: System (highest privilege)

How this helps:

  • Baseline normal behavior: Core Windows processes typically run at High or System integrity.

  • Detect privilege escalation: A process running at a higher integrity level than expected—especially relative to its parent—may indicate escalation.

  • Hunt for anomalies: Filtering for processes above Medium integrity (> 4096) can highlight elevated activity worth investigating.

Example XQL Logic

To find elevated processes that are not signed by Microsoft:

dataset = xdr_data
| filter event_type = ENUM.PROCESS
| filter action_process_integrity_level > 4096
| filter action_process_signature_vendor != "Microsoft Corporation"
 
Limitations to Consider
  • Self-signed certificates: May result in null or empty signer fields if the certificate is not publicly trusted.

  • Enrichment delays: Signature data may take a short time to populate after process execution.

  • Internal certificates: Binaries signed with private enterprise certificates may still appear as unsigned in some detections.

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

 

Thanks & Regards,
S. Subashkar Sekar

View solution in original post

4 REPLIES 4

L5 Sessionator

Hello @N.B238890 ,

 

Greetings for the day.

 

How can signer information (actionprocesssignaturevendor, actionprocesssignatureproduct) and integrity levels be used in XQL to differentiate between authorized system processes and suspicious activity?

In Cortex XDR, signer information and integrity levels can be combined in XQL to distinguish between legitimate system activity and potentially malicious behavior. These fields help establish both the trustworthiness of a binary and the privilege level at which it operates.

Using Signer Information to Establish Trust:

Signer-related fields help determine whether a process originates from a trusted source.

Key fields:

  • action_process_signature_vendor: The name of the vendor that signed the binary (for example, "Microsoft Corporation")

  • action_process_signature_product: The product family associated with the signature

How this helps:

  • Reduce noise: You can exclude known trusted vendors (such as Microsoft or approved enterprise tools) to focus on unusual activity.

  • Detect masquerading: A process using a legitimate system name (like svchost.exe) but marked as unsigned (action_process_signature_status = 3) is suspicious.

  • Ensure accuracy: Vendor name matching in XQL must be exact. Even small differences in punctuation or formatting can cause filters to fail.

  • Handle edge cases: On some systems (like macOS), vendor names may appear truncated, requiring broader matching logic.

Using Integrity Levels to Identify Elevation

Integrity levels indicate the privilege context of a process and are represented as integers in XQL.

Common values:

  • 0: Low / Untrusted

  • 4096: Medium (standard user)

  • 8192: High (elevated / administrator)

  • 16384: System (highest privilege)

How this helps:

  • Baseline normal behavior: Core Windows processes typically run at High or System integrity.

  • Detect privilege escalation: A process running at a higher integrity level than expected—especially relative to its parent—may indicate escalation.

  • Hunt for anomalies: Filtering for processes above Medium integrity (> 4096) can highlight elevated activity worth investigating.

Example XQL Logic

To find elevated processes that are not signed by Microsoft:

dataset = xdr_data
| filter event_type = ENUM.PROCESS
| filter action_process_integrity_level > 4096
| filter action_process_signature_vendor != "Microsoft Corporation"
 
Limitations to Consider
  • Self-signed certificates: May result in null or empty signer fields if the certificate is not publicly trusted.

  • Enrichment delays: Signature data may take a short time to populate after process execution.

  • Internal certificates: Binaries signed with private enterprise certificates may still appear as unsigned in some detections.

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

 

Thanks & Regards,
S. Subashkar Sekar

Thank you for the solution, but if we use this:

| filter action_process_signature_vendor != "Microsoft Corporation"
| filter action_process_signature_status = 3   // unsigned, it will drop many real attack instances that LOLBAS.

L2 Linker

What is your time range, how many results are you getting, and is the activity expected? 

Time range: 90 days, getting 10 lakh results that is max output. yes, it is grabbing some of the legitimate processes with the key words we are troughing.

  • 1 accepted solution
  • 939 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!