Threat Hunting Without a SOC: A Practical Guide for Australian SMBs

---

Why Threat Hunting Matters for SMBs

Australian small and medium businesses face the same adversaries as large enterprises — ransomware operators, credential thieves, and initial access brokers — but with a fraction of the defensive resources. The Australian Cyber Security Centre (ACSC) continues to report that SMBs remain disproportionately targeted because attackers know smaller organisations often lack dedicated monitoring.

Threat hunting flips the traditional alert-driven model on its head. Instead of waiting for a tool to tell you something is wrong, you actively look for evidence that an attacker is already inside. This matters because the median dwell time for intrusions in the Asia-Pacific region still exceeds 200 days — that's over six months an attacker operates before a conventional alert fires.

Hypothesis-Driven vs. Alert-Driven: What's the Difference?

Alert-driven monitoring is reactive: your EDR generates an alert, an analyst triages it. This is essential but insufficient on its own. Attackers routinely evade automated detections by using legitimate tools already on the system — what's called "living off the land."

Hypothesis-driven threat hunting is proactive. You formulate a question — for example, "Are any of our endpoints executing PowerShell with encoded commands?" — and then query your logs to find out. You don't need an alert to trigger; you need curiosity and access to data. The hypothesis comes from threat intelligence, MITRE ATT&CK techniques, or simply asking "what would this attack look like in our environment?"

The key shift for SMBs: you don't need to monitor everything. You need to monitor the things that matter — authentication, process execution, DNS, and network egress. Four data sources will carry you further than you think.

Log Sources You Probably Already Have

Most SMBs generate more security-relevant log data than they realise. Here are the sources worth hunting in:

1. Endpoint logs — Windows Event Logs (Security, Sysmon, PowerShell/4104), macOS unified logs, or Linux auditd. If you run Microsoft Defender for Business or any EDR with telemetry export, you already have process execution data.
2. DNS logs — If you run a Pi-hole, AdGuard Home, or forward DNS through a cloud resolver with logging (Cloudflare, AWS Route 53), you have a goldmine for detecting C2 callbacks and DNS tunneling.
3. Proxy and firewall logs — Most SMB firewalls (FortiGate, Unifi, pfSense, Sophos) log outbound connections. Web proxies log URLs and categories. This is your network detection surface.
4. Identity logs — Azure AD sign-in logs (free tier includes basic logs), Windows Security event 4624/4625, VPN authentication logs. Lateral movement and credential abuse leave traces here.

If you don't have a SIEM yet, start with a lightweight aggregator — Wazuh (free, open-source), Graylog Community Edition, or even Logstash piping into Elasticsearch. Forward your existing logs there. You don't need Splunk Enterprise to start hunting.

---

Five Beginner-Friendly Hunt Scenarios

These scenarios require no advanced tooling — just the ability to query your logs. Each includes the hypothesis, the data source, and what to look for.

1. Lateral Movement Detection

Hypothesis: An attacker who has compromised one endpoint is attempting to move to others via SMB or RDP.

Log sources: Windows Security logs (4624 Type 3 — network logons), EDR process logs.

What to look for: One workstation authenticating to multiple other workstations in a short window. A single user account logging into five different machines within an hour is abnormal in most SMB environments. Look for Event ID 4624 with Logon Type 3 sourced from internal IPs. Also watch for net use, wmic, and PsExec process executions — legitimate admin tools that attackers weaponise.

Quick win: Query the last 30 days of 4624 Type 3 events. Pivot by source IP and target host. Any machine authenticating to more than 10 unique hosts in a day warrants investigation.

2. Living-Off-the-Land Binaries (LOLBins)

Hypothesis: An attacker is using built-in Windows binaries (certutil, bitsadmin, mshta, rundll32) to download payloads or execute code, bypassing application whitelisting.

Log sources: Sysmon Event ID 1 (Process Create), PowerShell logging (4104).

What to look for: certutil.exe -urlcache -split -f http://..., bitsadmin /transfer, mshta http://..., rundll32.exe with a URL argument. These binaries have legitimate uses, but the command-line arguments reveal intent.

Quick win: Install Sysmon (free, from Microsoft Sysinternals) with SwiftOnSecurity's open-source configuration. It logs every process creation with full command line. Then search your logs for any LOLBin with a URL or network indicator in its command line.

3. Unusual PowerShell Execution

Hypothesis: An attacker or malware is using PowerShell to execute encoded or obfuscated commands.

Log sources: PowerShell Script Block Logging (Event ID 4104), Sysmon Event ID 1.

What to look for: -EncodedCommand (or -e / -enc) followed by a Base64 string. Invoke-Expression (or IEX). DownloadString, DownloadFile, Invoke-WebRequest chained with IEX. PowerShell started by a non-standard parent process (not Explorer, not a known management tool). PowerShell running from a temp directory.

Quick win: Enable PowerShell Script Block Logging via Group Policy (Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging). Query Event ID 4104 for EncodedCommand — any legitimate use is rare enough to investigate each hit.

4. DNS Tunneling Indicators

Hypothesis: An attacker is using DNS as a covert data exfiltration channel or C2 callback mechanism.

Log sources: DNS resolver logs (Pi-hole, BIND, Cloudflare DNS analytics, EDR DNS telemetry).

What to look for: Unusually long subdomain labels (over 50 characters) in DNS queries to domains you don't recognise. A high volume of TXT record queries to a single domain. DNS queries to domains with very recent registration dates. Repeated queries to dynamic DNS providers (duckdns.org, noip.com) from servers that have no business needing them.

Quick win: Export your DNS logs, group by queried domain, sort by query length. Anything with subdomains exceeding 50 characters that isn't a CDN or SaaS provider (Cloudflare, Azure, etc.) is a candidate for investigation.

5. After-Hours RDP Access

Hypothesis: An attacker with stolen credentials is using RDP to access your environment outside normal business hours.

Log sources: Windows Security logs (4624 Type 10 — Terminal Services), VPN logs, firewall logs (port 3389).

What to look for: Successful RDP logons (Event 4624, Logon Type 10) between 8pm and 6am. RDP from IP addresses outside Australia (if your team is domestic). RDP sessions lasting less than 2 minutes — attackers probing but not staying. Multiple RDP failures (4625) followed by a success.

Quick win: Pull 30 days of 4624 Type 10 events. Filter to your off-hours window. Every session should map to a known employee on a known device. Investigate anything that doesn't.

---

Detection Engineering Basics

Hunting finds things once. Detection engineering ensures you find them automatically next time. When you confirm a hunt uncovered malicious activity (or a risky-but-legitimate pattern worth monitoring), turn it into a persistent detection.

Sigma rules are the open standard for this. Sigma is a YAML-based rule format that describes what a log event looks like when something bad happens. You write the rule once, and tools like Sigma's converters translate it to your SIEM's query language — Splunk SPL, Elastic KQL, Microsoft Kusto, Sentinel KQL, or others.

A simple Sigma rule for detecting encoded PowerShell might look like:

title: Suspicious Encoded PowerShell Command
status: experimental
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        CommandLine|contains:
            - '-EncodedCommand'
            - '-enc '
            - '-e '
    condition: selection
level: medium

Write the rule, test it against your existing logs (does it fire on known-bad activity without flooding you with false positives?), then deploy it. The Sigma public repository (github.com/SigmaHQ/sigma) has over 3,000 community-maintained rules you can adapt rather than writing from scratch.

Tuning is critical. Every detection should have a documented expected false-positive rate. If a rule fires 200 times a day, nobody will read alert 201. Start with high-confidence, low-volume detections. Add breadth over time. Review detections quarterly — attacker TTPs evolve, and stale rules provide false comfort.

---

Open-Source Threat Intelligence for SMBs

You don't need a paid threat intel subscription to inform your hunts. These free resources are used by professional SOC teams:

• MITRE ATT&CK (attack.mitre.org) — The framework that maps attacker behaviours to techniques. Every hunt hypothesis should map to an ATT&CK technique ID. This gives you a structured way to think about what you're looking for and whether you've covered your gaps.
• MISP (misp-project.org) — Open-source threat intelligence platform you can self-host. Community feeds share IOCs (indicators of compromise) from active campaigns. You can subscribe to feeds relevant to Australian organisations through AusCERT and the ACSC.
• Abuse.ch — Free malware IOC feeds: URLhaus (malicious URLs), MalwareBazaar (malware samples), ThreatFox (C2 infrastructure). These are updated daily and can be ingested into your SIEM or checked against your logs retroactively.
• CISA Known Exploited Vulnerabilities — The authoritative list of CVEs being actively exploited. Cross-reference against your asset inventory monthly.
• ACSC Alerts and Advisories (cyber.gov.au) — Australian-specific threat intelligence. The ACSC publishes advisories about campaigns targeting Australian organisations, which should directly inform your hunt hypotheses.

Practical integration: Export IOCs from these feeds as CSV or STIX. Query your logs for any matches — "have any of our endpoints contacted any IP on the Abuse.ch ThreatFox list in the last 30 days?" This is a hunt you can run monthly in under an hour.

---

Building a Threat Hunting Program on a Budget

You don't need a team of five analysts. A solo IT manager or a two-person team can run an effective hunting program with discipline and the right cadence.

Start with a monthly hunt. Pick one scenario from the five above. Block out two hours. Query your logs. Document what you found (including "nothing suspicious" — that's a valid and valuable result). Repeat with a different scenario next month.

Build a hunt register. A simple spreadsheet or markdown file tracking: date, hypothesis, ATT&CK technique, data source queried, findings, follow-up actions. Over 12 months, you'll have documented coverage across multiple attack categories.

Create a feedback loop. Every confirmed finding becomes a detection rule. Every detection rule gets tuned. Every quarter, review which detections fired, which were false positives, and what new ATT&CK techniques you should hunt for based on emerging threat intel.

Leverage free tooling:

• Sysmon for endpoint telemetry (free)
• Wazuh or Graylog for log aggregation and alerting (free, self-hosted)
• Sigma for detection rules (free, open standard)
• MISP for threat intelligence (free, self-hosted)
• MITRE ATT&CK Navigator for technique coverage mapping (free, browser-based)

Total software cost: zero. Total investment: 2-4 hours per month plus initial setup.

---

First Hunt Playbook: Step-by-Step

If you've never run a threat hunt before, start here. This is a single hunt you can complete in under two hours using only Windows Event Logs and PowerShell.

Step 1: Enable PowerShell Script Block Logging On your domain controller, open Group Policy Management. Create or edit a GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging → Enabled. Link it to an OU containing your endpoints. Wait 24-48 hours for logs to accumulate.

Step 2: Collect Logs On each endpoint (or via a central log collector), export the last 7 days of PowerShell/Operational logs:

Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" -MaxEvents 10000 | Export-Csv powershell_logs.csv

Step 3: Form Your Hypothesis "An attacker has executed encoded or obfuscated PowerShell on at least one endpoint in the past 7 days."

Step 4: Query Open the CSV in Excel, Google Sheets, or a Python script. Filter the Message column for any of these strings: -EncodedCommand, -enc , IEX, DownloadString, FromBase64String, Invoke-Expression.

Step 5: Triage Hits For each match, check: Was the user an admin? Was the parent process expected (SCCM, Ansible, a known deployment tool)? Does the decoded command make sense in context? Anything you can't explain gets escalated.

Step 6: Document Add the result to your hunt register. If you found something, create a Sigma rule for it. If you didn't, note the coverage gap you've closed (PowerShell obfuscation — ATT&CK T1027/T1059.001).

Step 7: Schedule the Next Hunt Pick a different scenario for next month. Schedule it now — if it's not on the calendar, it won't happen.

---

FAQ

Conclusion

Threat hunting isn't an enterprise luxury — it's a practical capability any Australian SMB can build incrementally. Start with one hypothesis, one log source, and two hours a month. Turn confirmed findings into detections. Expand your coverage over time. The adversary's advantage is that most SMBs don't look. By the time you're running your sixth hunt, you've already closed detection gaps that organisations ten times your size haven't addressed.

Your first hunt is this month. Pick a scenario, block out the time, and query your logs. The only wrong move is waiting until after an incident to start.

Visit consult.lil.business for a free cybersecurity assessment — we'll help you identify which log sources you already have, map your current detection gaps against MITRE ATT&CK, and build your first hunt playbook tailored to your environment.

---

References

1. ACSC — Threat Hunting Guidance (cyber.gov.au)
2. MITRE ATT&CK Framework
3. Sigma Rule Repository — SigmaHQ
4. CISA Known Exploited Vulnerabilities Catalog
5. SANS Institute — Threat Hunting Resources

Verifier warning: verifier could not run (PluginLlmTrustError).