CrowdStrike LogScale Queries Every SOC Analyst Should Know

Most CrowdStrike documentation covers the platform interface. Very little of it tells you what to actually search for when an alert fires and you have three minutes to decide whether to escalate or close.

These five LogScale queries come directly from production environments at major Canadian financial institutions. They have been used on real incidents involving LOLBin abuse, credential attacks, Active Directory reconnaissance, and ransomware precursors. Each one includes the detection logic, what to look for in the results, and the most common false positive sources.

Query 1: LOLBin Abuse Detection

Living-off-the-land binaries are signed Windows executables attackers use to execute payloads without dropping their own files. They are one of the most common techniques used after initial access because they bypass most AV tools and blend into normal system activity.

This query hunts for commonly abused LOLBins spawned by unexpected parent processes — the key indicator that something legitimate is being misused.

#event_simpleName=ProcessRollup2
ImageFileName=/\/(certutil|mshta|wscript|cscript|regsvr32|rundll32|msiexec)\.exe$/i
| where CommandLine!="" AND ParentBaseFileName!=/explorer|services|svchost|msiexec/i
| table @timestamp ComputerName UserName ImageFileName CommandLine ParentBaseFileName
| "sort" @timestamp desc

What to flag immediately

• certutil with -urlcache -f http:// — Certutil doing certificate tasks is normal. Certutil downloading from external URLs is not.
• mshta calling a remote URL — Live payload execution. Isolate before you investigate.
• regsvr32 with /i:http:// scrobj.dll — Squiblydoo bypass. Sophisticated attacker.
• wscript or cscript running from a user's Downloads folder — Script dropped via phishing.

Common false positives

• taniumclient.exe — Management tool, safe to exclude
• ccmexec.exe — SCCM client, safe to exclude
• devenv.exe — Visual Studio, exclude for developer machines

Query 2: Suspicious PowerShell Execution

PowerShell is the most abused tool in the attacker's post-exploitation toolkit. The key is not to alert on every PowerShell execution — that generates thousands of false positives in any enterprise. The key is to alert on PowerShell spawned from Office applications, browsers, or email clients, which almost never happens in legitimate operations.

#event_simpleName=ProcessRollup2
ImageFileName=/\/powershell\.exe$/i
ParentBaseFileName IN ("WINWORD.EXE","EXCEL.EXE","OUTLOOK.EXE",
  "chrome.exe","msedge.exe","firefox.exe","wmiprvse.exe")
| table @timestamp ComputerName UserName CommandLine ParentBaseFileName
| "sort" @timestamp desc

What to look for in the results

• -EncodedCommand in the command line — Base64 encoded payload, almost always malicious in this context
• IEX or Invoke-Expression — In-memory execution, no file dropped
• DownloadString or WebClient — Pulling a second stage payload from the internet
• Bypass -ExecutionPolicy — Attacker explicitly bypassing PowerShell restrictions

Query 3: New Admin Account Creation Outside Business Hours

Attackers who have compromised a service account or stolen credentials frequently create new admin accounts as a persistence mechanism. They do this at night or on weekends when nobody is watching. This query surfaces new accounts added to privileged groups during off-hours.

#event_simpleName=UserAccountCreated OR #event_simpleName=UserAccountAddedToGroup
| eval hour=formatTime("%H", @timestamp/1000)
| where toNumber(hour) < 7 OR toNumber(hour) > 19
| table @timestamp ComputerName SubjectUserName TargetUserName GroupName
| "sort" @timestamp desc

Investigation steps when this fires

• Check the SubjectUserName — who created the account. Was it a human or a service account?
• Check the naming convention. Does it match your organization's standard format? Attackers rarely know internal naming patterns.
• Check what groups the new account was immediately added to. Domain Admins or Enterprise Admins added within minutes of creation is a confirmed attacker action.
• Pull the past 24 hours of activity for the account that performed the creation.

Query 4: Mass File Deletion Event

Mass file deletion appears in two scenarios — ransomware operators covering tracks before exfiltration, and insider threats removing evidence. Both require immediate investigation. The volume threshold of 200 files per 10 minutes filters out normal user activity while catching the bulk deletion pattern.

#event_simpleName=FileDeleteInfo
| bin @timestamp span=10m
| groupBy([@timestamp, ComputerName, UserName], function=count(as=deletions))
| where deletions > 200
| table @timestamp ComputerName UserName deletions
| "sort" deletions desc

Context to pull immediately

• What file types were deleted? Documents and spreadsheets only suggest data staging. System files suggest destructive attack.
• What was the parent process performing the deletions? A backup tool is different from cmd.exe.
• Did this account authenticate to other systems in the 20 minutes before the deletions started? Lateral movement precedes destructive actions.

Query 5: LDAP Reconnaissance (BloodHound Detection)

BloodHound and SharpHound are used by attackers to map the entire Active Directory environment — every user, every group, every path to Domain Admin. The collection process generates a massive volume of LDAP queries from a single workstation in a short period. Normal workstations make perhaps 20 LDAP queries per day. BloodHound makes 10,000 in 3 minutes.

#event_simpleName=NetworkConnectIP4
RemotePort=389 OR RemotePort=636 OR RemotePort=3268
| bin @timestamp span=3m
| groupBy([@timestamp, ComputerName, UserName], function=count(as=ldap_queries))
| where ldap_queries > 500
| table @timestamp ComputerName UserName ldap_queries
| "sort" ldap_queries desc

Confirming BloodHound activity

• Check the process making the LDAP connections. SharpHound.exe or any renamed version is an immediate escalation.
• Check the account — is it a regular user account? Domain enumeration does not require admin rights which is why attackers use standard user credentials for collection.
• Pull what was actually collected by checking DNS requests from the same host during the same window. BloodHound queries all domain controllers.