Threat Hunting for Small Security Teams: Practical Hunts Australian SMBs Can Run Without a SOC

Start small: choose one realistic attacker behaviour, collect the minimum useful evidence, search for abnormal patterns, then turn what you learn into tuned alerts or repeatable checks. The goal is not to “find hackers every Friday”; it is to reduce blind spots before an incident forces you to learn under pressure.

Threat Hunting Without a SOC: What It Actually Means

Threat hunting is a proactive search for suspicious behaviour that existing alerts may have missed. Alert-driven monitoring starts with a rule firing: “PowerShell downloaded a file” or “EDR blocked malware.” Hypothesis-driven hunting starts with a question: “If an attacker stole an admin password, how would they move from one workstation to another in our environment?”

For small security teams, that difference matters. You may not have analysts watching dashboards all day, but you can still spend two focused hours each fortnight testing one attacker hypothesis against your existing data. A useful SMB hunt is narrow, evidence-based, and repeatable: one question, a few log sources, a clear time window, and a decision at the end.

A practical threat hunting hypothesis looks like this:

“An attacker who compromised a staff laptop may use built-in Windows tools such as PowerShell, PsExec, WMI, RDP, or scheduled tasks to move laterally without dropping obvious malware.”

That hypothesis tells you what to inspect: Windows event logs, EDR process events, authentication logs, remote desktop events, administrative share access, and endpoint-to-endpoint connections. You do not need perfect telemetry to begin. You need enough telemetry to compare normal business behaviour against activity that is rare, risky, or poorly explained.

Start With the Logs You Already Have

Most SMBs already own enough data for basic threat hunting, even if it is scattered across products. The first budget win is inventorying what you can search today before buying another platform.

Common starting sources include:

• SIEM or log platform: Microsoft Sentinel, Elastic, Splunk, Wazuh, Graylog, or a managed provider portal. Use this to correlate identity, endpoint, firewall, and cloud events.
• EDR telemetry: Microsoft Defender for Endpoint, CrowdStrike, SentinelOne, Sophos, Huntress, or similar. Focus on process creation, command-line arguments, parent-child process relationships, file writes, and network connections.
• Microsoft 365 and Entra ID logs: sign-ins, impossible travel, MFA changes, mailbox rules, OAuth app consent, admin role changes, and audit events.
• DNS logs: internal resolver logs, firewall DNS logs, Cisco Umbrella, Cloudflare Gateway, or Windows DNS Server logs. DNS is excellent for finding malware callbacks, tunnelling, and newly observed domains.
• Proxy, firewall, and VPN logs: outbound destinations, blocked categories, unusual ports, remote access sessions, and after-hours authentication.
• Windows event logs: Security, PowerShell Operational, Sysmon if deployed, Remote Desktop Services, Task Scheduler, and Windows Defender logs.

Do not try to ingest everything on day one. Pick a 30-day retention target for the highest-value sources: identity, endpoint process execution, DNS, VPN, and remote access. If storage is expensive, keep high-fidelity logs for critical systems first: domain controllers, servers, finance endpoints, administrator workstations, and remote access gateways.

Five Beginner-Friendly Hunt Scenarios

1. Lateral movement detection

Hypothesis: “A compromised account is being used to access multiple internal systems outside normal admin patterns.”

Look for one user account authenticating to many endpoints in a short period, especially using admin shares, RDP, WMI, WinRM, PsExec-like service creation, or remote scheduled tasks. On Windows, useful events include logon events, service creation, explicit credential use, and remote desktop events. In EDR, look for remote execution tools, unusual parent processes, and workstation-to-workstation connections.

Quick win: create a baseline of which accounts normally log in to servers. Alert when a standard user logs into multiple servers or when an admin account logs into a workstation unexpectedly.

2. Living-off-the-land binaries

Hypothesis: “An attacker is using legitimate Windows tools to avoid malware detection.”

Search for suspicious use of built-in binaries such as rundll32.exe, regsvr32.exe, mshta.exe, certutil.exe, bitsadmin.exe, wmic.exe, powershell.exe, cmd.exe, and schtasks.exe. These tools are not malicious by themselves, so context matters. Investigate command lines that download files, execute scripts from temporary directories, contact external URLs, decode base64, or spawn from Office applications.

Quick win: alert when Office, browsers, PDF readers, or email clients spawn scripting engines or administrative tools. That parent-child relationship is often more useful than blocking a binary outright.

3. Unusual PowerShell

Hypothesis: “An attacker is using PowerShell for discovery, credential access, or payload execution.”

Search for encoded commands, hidden windows, execution policy bypasses, remote script downloads, suspicious modules, and commands that query users, groups, domain trusts, antivirus status, or credential stores. Useful strings include -EncodedCommand, -ExecutionPolicy Bypass, IEX, Invoke-WebRequest, DownloadString, FromBase64String, Get-ADUser, and Get-ADGroupMember.

Quick win: enable PowerShell logging where practical, including Script Block Logging for higher-value systems. Tune alerts to ignore known administration scripts but retain visibility into first-seen commands and unusual hosts.

4. DNS tunnelling indicators

Hypothesis: “Malware or an attacker is using DNS to move data or maintain command-and-control.”

Look for clients making unusually high DNS query volumes, repeated lookups to rare domains, long subdomains, high-entropy labels, many failed lookups, or frequent TXT record queries. DNS tunnelling often creates patterns that stand out even when the payload is encrypted elsewhere.

Quick win: review the top internal hosts by DNS request count and the top domains with long query names. A single workstation generating thousands of unusual DNS requests deserves investigation, especially if the destination is newly registered or appears in Abuse.ch or other threat feeds.

5. After-hours RDP and remote access

Hypothesis: “A stolen credential is being used for interactive access outside normal business hours.”

Search VPN, RDP, Entra ID, and firewall logs for successful logins outside expected working hours, from unusual geographies, or from unmanaged devices. For Australian SMBs, after-hours access may be normal for owners, IT providers, or shift workers, so build a simple exception list rather than ignoring the pattern.

Quick win: alert on successful RDP or VPN sessions after hours for accounts that have not used remote access in the previous 30 days. Prioritise accounts with admin privileges or access to finance, payroll, legal, or customer data.

Detection Engineering Basics for SMBs

Detection engineering is the process of turning a useful hunt into a reliable detection. After a hunt, ask: “Would we want to know if this happened again?” If yes, convert the logic into a SIEM rule, EDR detection, scheduled query, or ticketing workflow.

Sigma is a practical starting point because it provides a vendor-neutral rule format for describing suspicious log patterns. A simple Sigma-style rule might detect PowerShell with encoded commands, then your SIEM can translate or implement equivalent logic. The key fields are the log source, detection conditions, false-positive notes, severity, and references to attacker techniques such as MITRE ATT&CK.

Tuning is where SMBs win or lose. A noisy rule that fires 200 times a day will be ignored. Start with a narrow condition, run it in audit mode, review false positives, then add filters for known IT tools, approved scripts, service accounts, and maintenance windows. Keep a short comment beside every suppression: who approved it, why it exists, and when to review it.

Use threat intelligence as enrichment, not truth. Open-source sources such as MISP communities, Abuse.ch, CISA advisories, and MITRE ATT&CK can help identify malicious infrastructure, malware behaviours, and common attacker techniques. But indicators expire quickly. A domain or IP match should increase priority; it should not replace investigation.

First Hunt Playbook: A Two-Hour SMB Threat Hunt

1. Choose one hypothesis. Start with after-hours RDP, unusual PowerShell, or lateral movement. Avoid broad goals like “find malware.”
2. Set the time window. Use the last 7 or 30 days depending on log retention.
3. Identify required data. For after-hours RDP, use VPN logs, Windows logon events, RDP gateway logs, Entra ID sign-ins, and EDR authentication telemetry.
4. Define normal. List expected admin accounts, IT provider accounts, remote workers, maintenance windows, and approved remote access tools.
5. Run the first query. Search for successful remote logins outside business hours, grouped by user, source IP, device, and destination.
6. Sort by risk. Prioritise admin accounts, first-time remote access, overseas logins, unmanaged devices, repeated failures followed by success, and access to servers.
7. Investigate the top five results. Check whether the user was working, whether MFA was satisfied, whether the source IP is expected, and what processes ran after login.
8. Record findings. Use a simple table: hypothesis, data sources, query used, suspicious results, confirmed benign results, gaps, and follow-up actions.
9. Create one improvement. This may be a tuned SIEM alert, an EDR watchlist, a firewall rule, an MFA policy change, or a better logging configuration.
10. Schedule the next hunt. Repeat fortnightly or monthly. Rotate through identity, endpoint, DNS, cloud, and remote access themes.

A successful first hunt may find no compromise. That is still valuable if it improves visibility, documents normal behaviour, and produces one better detection.

Building a Budget Threat Hunting Program

A small program needs rhythm more than expensive tooling. Assign one owner, one recurring calendar slot, and one shared place to store hunt notes. Keep the scope realistic: one hunt per fortnight, one detection improvement per hunt, and one monthly review of unresolved gaps.

Prioritise controls that make hunts easier: centralised logs, MFA everywhere, EDR on all endpoints, DNS visibility, admin account separation, and consistent asset naming. If you use an MSP or MDR provider, ask them what hunts they run for you, what data they can show, and how they tune detections for your environment.

Map hunts to MITRE ATT&CK techniques so you can see coverage over time. For example, PowerShell maps to command and scripting interpreter behaviour, after-hours RDP maps to remote services, and DNS tunnelling maps to application layer protocol misuse. This helps non-technical owners understand whether the business is improving coverage against real attacker methods.

FAQ

Conclusion

Threat hunting for SMBs is not about building a miniature enterprise SOC. It is about asking better questions of the data you already have, finding gaps before attackers exploit them, and turning each hunt into a stronger detection or control.

Start with one hypothesis, one log source, and one repeatable playbook. Then build momentum: tune alerts, improve retention, document normal behaviour, and use open-source intelligence to enrich investigations. Visit consult.lil.business for a free cybersecurity assessment.

References

1. Australian Cyber Security Centre — Essential Eight
2. NIST Special Publication 800-92 — Guide to Computer Security Log Management
3. MITRE ATT&CK Enterprise Matrix
4. CISA — Cybersecurity Advisories
5. Abuse.ch Threat Intelligence Projects
6. SigmaHQ — Generic Signature Format for SIEM Systems

---

Verifier warning: verifier could not run (PluginLlmTrustError).