Threat Hunting for Small Security Teams — How Australian SMBs Can Hunt Without a Full SOC

Why Hypothesis-Driven Hunting Beats Waiting for Alerts

Most SMB security teams operate in alert-driven mode: your SIEM fires, you triage, you respond. The problem is that alert-driven monitoring is inherently reactive — you only find what your rules already know to look for. Hypothesis-driven threat hunting flips that model. You start with an informed question based on threat intelligence, then go look for evidence in your existing logs.

With Australian organisations currently facing active campaigns — including ClickFix distributing Vidar Stealer via compromised WordPress sites targeting Australian infrastructure, and China-nexus actors building covert networks of compromised devices — waiting for an alert is a bet you may lose. The Australian Signals Directorate's ACSC has been clear: adversaries are living inside networks for weeks before detection. Hunting shrinks that window.

The key mindset shift: hunting is not incident response. You are not confirming a breach. You are testing a hypothesis — "if an attacker were using living-off-the-land binaries in my environment, what would that look like in my EDR telemetry?" — and either finding evidence or gaining confidence that the technique is not present.

What You Need Before You Start: Log Sources You Probably Already Have

You don't need an enterprise-grade SIEM to begin hunting. Most Australian SMBs running even basic IT infrastructure already collect these four log sources:

SIEM / Central Log Aggregation. Whether you're running a cloud SIEM, a self-hosted Elastic stack, or even just forwarding Windows Event Logs to a central store, this is your hunting ground. Ensure you're collecting Security Event logs (especially IDs 4624, 4625, 4688, 4697, 7045) and enabling PowerShell script block logging (Event ID 4104).

EDR Telemetry. If you have any endpoint detection and response tool — even Microsoft Defender for Endpoint, which is included in many Microsoft 363 business plans — you have process creation data, command-line arguments, network connections, and file modification events. This is your richest hunting data source.

DNS Logs. DNS query logs reveal C2 communication, data exfiltration, and phishing infrastructure. If you run your own DNS resolvers or use a cloud DNS provider like Cloudflare or Quad9 with logging enabled, you have this data. Forward it to your SIEM.

Proxy / Web Gateway Logs. Web proxy logs (Sophos, Cisco Umbrella, Squid) show you what your users and systems are connecting to. Cross-reference with threat intelligence feeds to spot connections to known malicious infrastructure.

Quick win: if you're missing any of these, enabling DNS logging and PowerShell script block logging costs nothing and gives you immediate hunting capability on Windows environments.

Five Beginner-Friendly Hunt Scenarios

Here are five hunt scenarios ordered by difficulty. Each includes the hypothesis, the log source, and what to look for.

Hunt 1: After-Hours RDP Activity (Easy)

Hypothesis: If an attacker has compromised credentials, they may use RDP for lateral movement during non-business hours when detection is less likely.

Log source: Windows Security Event Logs (4624 Logon Type 10), EDR telemetry.

What to look for: RDP logins (Logon Type 10) outside business hours (say, 7 PM to 6 AM AEST) or on weekends. Filter for source IPs that are internal but unusual — lateral movement, not external entry. Pivot on the target machine: what processes ran after the RDP session? Any unusual file downloads or scheduled tasks created?

Given the current Russian GRU campaigns targeting Western logistics and technology companies, monitoring for anomalous RDP patterns is particularly relevant for Australian organisations in those sectors.

Hunt 2: Living-Off-the-Land Binaries (Medium)

Hypothesis: Attackers will use legitimate system tools — certutil.exe to download files, mshta.exe to execute scripts, rundll32.exe to load malicious DLLs — to avoid triggering signature-based detection.

Log source: EDR process creation logs with full command-line arguments.

What to look for: Unusual parent-child process relationships. Certutil.exe with -urlcache or -split arguments. Mshta.exe executing inline VBScript or JavaScript. Rundll32.exe loading DLLs from user-writable directories like AppData or Temp. The LOLBAS project (lolbas-project.github.io) maintains the definitive list.

Hunt 3: Unusual PowerShell Execution (Medium)

Hypothesis: Attackers use encoded PowerShell commands, downloads from the internet, or reflection-based assembly loading to execute malicious code.

Log source: Windows PowerShell Event Log 4104 (Script Block Logging), EDR command-line telemetry.

What to look for: -EncodedCommand or -enc flags. Invoke-Expression combined with New-Object Net.WebClient or Invoke-WebRequest. Base64-encoded strings decoded to reveal suspicious payloads. System.Reflection.Assembly::Load() calls. The ClickFix technique currently targeting Australian WordPress sites relies heavily on clipboard-based PowerShell execution — users are tricked into pasting malicious PowerShell commands, making this hunt scenario directly relevant.

Hunt 4: DNS Tunneling Indicators (Harder)

Hypothesis: If an attacker has established a C2 channel using DNS tunneling, you'll see unusually long subdomain queries, high-frequency queries to a single domain, or entropy anomalies in DNS query names.

Log source: DNS resolver logs.

What to look for: Queries where the subdomain label exceeds 30 characters. High query volume to a single base domain over a short window. Subdomain strings with unusually high Shannon entropy — legitimate CDNs and cloud services generate some noise, but truly random-looking subdomains are suspicious. Tools like dnscat2 and iodine leave distinctive patterns.

Hunt 5: Lateral Movement via Service Creation (Medium)

Hypothesis: An attacker who has compromised one machine will create services or scheduled tasks on other machines to move laterally and establish persistence.

Log source: Windows Security Event Logs (4697 — service installed, 7045 — new service creation), EDR telemetry.

What to look for: Services created with unusual binary paths, especially paths pointing to Temp, AppData, or user directories. Services with random-looking names. Scheduled tasks created via schtasks.exe with arguments that execute scripts from unusual locations. Cross-reference with authentication events on the target machine to see which account created the service.

Detection Engineering: Writing Your First Sigma Rule

Once a hunt produces results, harden that finding into a detection rule. Sigma is the open standard for writing vendor-neutral detection logic — think of it as "YARA for logs."

Here's a Sigma rule for Hunt 3 (unusual PowerShell) that you can drop into any Sigma-compatible SIEM:

title: Suspicious Encoded PowerShell Command
status: experimental
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - '-EncodedCommand'
            - '-enc'
            - '-ec'
    condition: selection
level: high
tags:
    - attack.execution
    - attack.t1059.001

Convert this to your SIEM's query language using Sigma's backend tools (sigmac for Elastic, Splunk, Sentinel, and others). Tune the rule by adding legitimate exclusions — your build servers or admin scripts that use encoded commands legitimately. False positives that get ignored become blind spots.

Detection engineering is iterative. Your first rule will be noisy. That's fine. Tune it, document the exceptions, and move on. Each rule makes your alert-driven monitoring smarter, which frees up time for more hunting.

Open-Source Threat Intelligence for Australian SMBs

You don't need a paid threat intelligence platform. These free feeds are directly relevant to Australian organisations:

• ASD ACSC Advisory Feed (cyber.gov.au): Current advisories on campaigns targeting Australian infrastructure, including the active ClickFix/Vidar and cPanel/WHM exploitation campaigns (CVE-2026-4194, CVSS 9.3).
• MITRE ATT&CK (attack.mitre.org): The framework for understanding adversary techniques. Map your hunts to ATT&CK techniques to prioritise what to hunt for based on the threats most relevant to your industry.
• Abuse.ch (abuse.ch): Free feeds including URLhaus (malicious URLs), MalwareBazaar (malware samples), and ThreatFox (IOC sharing). Download and pivot against your proxy and DNS logs.
• CISA Known Exploited Vulnerabilities Catalog (cisa.gov): Required reading for understanding what attackers are actively exploiting. The recent Cisco Firepower malware advisory demonstrates why patching alone isn't enough — you need to hunt for signs of compromise on affected systems.
• MISP Open Threat Intelligence (misp-project.org): Community-driven threat sharing platform with free feeds. The CIRCL OSINT feed is a strong starting point.

Your First Hunt Playbook: Step-by-Step

This playbook takes one person about 2–4 hours. You need access to your SIEM and basic query skills.

Step 1 — Pick one hypothesis. Start with Hunt 1 (after-hours RDP). It's the easiest and most likely to produce clear results.

Step 2 — Scope the time range. Pull the last 30 days of data. Hunting is not real-time — you're looking for what already happened.

Step 3 — Write the query. Filter Windows Security Event Log 4624 for Logon Type 10. Exclude known admin accounts and your own IP ranges if you have remote admin staff. Group results by target machine and hour.

Step 4 — Analyse results. Look for outliers. A machine that received one RDP session at 2 AM on a Sunday from an unusual source IP is interesting. A domain controller that received RDP sessions from a workstation at odd hours is very interesting.

Step 5 — Investigate findings. For each outlier, pull the process creation logs from the target machine during the session window. What ran? Was anything installed? Were any files created in Temp or AppData?

Step 6 — Document and decide. Record what you found. If it's benign, document why — this builds institutional knowledge. If it's suspicious, escalate to incident response. Either outcome is valuable.

Step 7 — Harden into a detection rule. Write a Sigma rule or SIEM alert for the pattern you hunted. Now you'll be alerted automatically next time.

Step 8 — Schedule the next hunt. Pick Hunt 2 for next week. Consistency matters more than sophistication. One hunt per week compounds into real detection coverage over a quarter.

FAQ

Conclusion

Threat hunting is not a luxury reserved for enterprises with 24/7 SOCs. It is a disciplined methodology that any Australian SMB can adopt with the logs they already have. Start with one hypothesis, run the playbook, and build from there. The five hunts in this article map to the most common adversary techniques seen in current campaigns targeting Australian networks — from ClickFix social engineering to living-off-the-land tradecraft used by state-sponsored actors.

Your next step: pick Hunt 1, block out two hours this week, and run the playbook. Then do it again next week with a different scenario. Within a month, you'll have detection coverage that most SMBs lack, and you'll have the confidence that comes from actively searching for threats rather than passively waiting for alerts.

Visit consult.lil.business for a free cybersecurity assessment and let us help you build a threat hunting program tailored to your organisation.

References

1. ASD ACSC — ClickFix Distributing Vidar Stealer via WordPress Targeting Australian Infrastructure
2. ASD ACSC — Defending Against China-Nexus Covert Networks of Compromised Devices
3. CISA — Known Exploited Vulnerabilities Catalog
4. MITRE ATT&CK Framework
5. Sigma Project — Generic Signature Format for SIEM Systems