I85PREP
⌘ K
IBM C1000-162 study materials
IBM C1000-162 study resources

Thirty-Day Lateral-Movement Hunt After an AQL Timeout

IBM C1000-162 · Put your knowledge to work in context.

All case studies

Thirty-Day Lateral-Movement Hunt After an AQL Timeout

You are hunting for lateral movement using PsExec and WMI in a 30-day window. QRadar stores 14 TB of events with 90-day retention and 7-day flow retention; the deployment ingests 45,000 EPS. Your first AQL query selects all events where the process name contains 'psexec' or the event name contains 'WMI' over the last 30 days. It times out after 10 minutes with no results. You want to find rare parent-child process pairs and service creations on servers that do not normally receive them. The network has 9,000 endpoints and 800 servers. You have read-only analyst access, no ability to change retention, and a change freeze on rules for two weeks. The only available identity data is in the events themselves; there is no CMDB feed into QRadar, and asset weights are only partially populated.

1. Why did the query time out, and how would you rewrite it?

Read the worked answer

The query is a full scan of 30 days of events with broad substring conditions and no selective filter. At 45,000 EPS, 30 days is roughly 116 billion events; no Ariel search will scan that in 10 minutes. Additional problems:

  • process name contains 'psexec' and event name contains 'WMI' are not index-friendly. QRadar indexes fields such as source/destination IP, username, QID and some custom properties, not arbitrary substrings.
  • The OR across two unrelated conditions widens the scan.
  • No log-source or event-category filter excludes endpoints that are out of scope.

Rewrite:

  1. Start with the event category/QID for process creation or service installation and the Windows Security log source group; that cuts the data by orders of magnitude.
  2. Use an exact QID or a reference set of process names instead of a leading wildcard.
  3. Split the 30 days into 24-hour or 7-day chunks, or run a narrow 24-hour query first and extend only after confirming selectivity.
  4. For WMI, target specific event IDs (for example, 4688 process creation with WMI provider host, 7045 service installation) rather than the string 'WMI'.
  5. Use LAST 24 HOURS for iteration and START/STOP for the final 30-day run off-peak.

2. How would you identify rare parent-child process pairs without scanning every event?

Read the worked answer

Baseline first, then find the rare pairs:

  • Build a baseline count of parent-to-child process pairs per server over 7 days, grouped by parent process name, child process name, and destination host.
  • Use GROUP BY with COUNT(*) and HAVING COUNT(*) < N (for example, less than 3) to surface pairs that occur rarely in the environment.
  • Restrict to the 800 servers rather than all 9,000 endpoints, and to process-creation events that carry a parent/child field.
  • Compare pairs on servers that normally never see them: anti-join against a 30-day server baseline, or use a reference set of 'expected server process pairs'.
  • Prioritize pairs where the parent is a service (services.exe, wmiprvse.exe) and the child is a known lateral-movement binary or a command shell.
  • Tune N against a known-good sample; too low and you get one-off admin tools, too high and you miss the intrusion.

Because there is no CMDB feed, treat the server list as an asset group built from existing QRadar assets. Do not rely on asset weight for the hunt logic, since it is only partially populated.

3. What would you produce at the end of the hunt, given that you cannot create rules during the change freeze?

Read the worked answer

Produce a hunt package that can be operationalized after the freeze:

  • A written finding with the AQL used, time ranges, counts, and the specific hosts and accounts involved.
  • A CSV/AQL export of the candidate pairs and the 20-50 highest-risk events, with timestamps and observer notes.
  • A proposed rule design (BB for the server list, BB for expected pairs, rule for a rare parent-child pair with a service parent) and a proposed reference set, ready to deploy after the freeze.
  • Detection coverage mapped to MITRE ATT&CK (for example, T1021.002 SMB/Windows Admin Shares, T1047 WMI) so the rule can be tracked.
  • A temporary compensating control: a saved search or dashboard widget the team can run manually each shift, with a clear note that it is not a detection.
  • A list of data gaps (asset weights, CMDB) and retention/flow limitations, so the next hunt does not repeat the timeout.