Threat hunting is usually framed around adversaries: actors, techniques, behaviors, and signs of compromise. In an ideal world, they come back dry and you walk away with a validated assumption with a solid detection. But if every hunt needs an adversary on the other end to produce value, you are leaving opportunities on the table to strengthen your defenses.
There is another useful class of hunting target: environmental conditions that make an attacker’s job easier. Like house maintenance tasks, companies can accumulate issues that grow over time. Identifying them in your environment doesn't necessarily mean you are compromised, but are easy paths an attacker gets to use for free once they arrive.
Our Hunt Mode focuses on network hygiene to help you hunt and identify fixable issues, deny attackers lateral moves, and use telemetry you may already have, without requiring a P0 sprint to resolve.
Don't let attackers live off your environment
“Living off the land” usually refers to attackers abusing legitimate binaries, built-in utilities, and other tools already present in an environment.
But there is another way to think about it. Once an attacker gets a foothold, they inherit whatever weaknesses the environment gives them. This can apply in a number of different scenarios:
- If an application sends credentials over an unencrypted protocol, the attacker does not have to defeat the authentication mechanism.
- If a legacy service still relies on weak encryption, they do not have to create that weakness.
- If an unmanaged device can freely communicate with workstations, an attacker does not have to build that path themselves. Worse, that path may sit in a blind spot.
Because these conditions are often forgotten tasks and tend to stick around until they're identified and fixed, they make good targets for hunters.
Use network telemetry you may already have
If you use Microsoft Defender for Endpoint, you may already have more network-layer visibility than you realize.
Microsoft uses Zeek-based network inspection to surface additional protocol information through DeviceNetworkEvents. A useful place to start is:
DeviceNetworkEvents
| where ActionType contains "ConnectionInspected"
| summarize count() by ActionType
| order by count_ desc
That gives you a quick inventory of the inspected connection types actually present in your environment.
Depending on the event, additional protocol details are exposed in AdditionalFields. This can give you application-layer context that goes beyond a normal source IP, destination IP, and port—for example, details about HTTP, DNS, TLS, FTP, authentication, and other inspected traffic where supported.
Microsoft documents more on using these network-layer signals in Advanced Hunting, along with guidance for enabling Network Protection.
The idea is not specific to Defender. If you collect sufficiently-rich protocol metadata through standalone Zeek, Corelight, ExtraHop, or another passive network or NDR platform, the same hunting approach applies.
Hunt 1: Credentials and secrets crossing in cleartext
Start with one of the simplest questions you can ask of network telemetry:
Are credentials or secrets crossing the network without protected transport?
What to observe
Depending on what your sensor exposes, look for things like:
- FTP authentication occurring without encrypted transport
- HTTP requests containing credentials or secrets in URLs and query strings
- HTTP authentication over cleartext connections
- LDAP simple binds occurring without TLS
- Jobs or integrations repeatedly attempting the same cleartext authentication
Useful strings and fields may include things like:
Authorization: Basic
token=
api_key=
password=
secret=
The exact fields depend on the telemetry source. The point is not to build one giant regex for every possible secret. Start with the protocols and applications your network sensor can actually describe.
Why it stands out
Base64 is encoding, not encryption. If a working credential travels over a cleartext connection, anything with the right network vantage point may be able to recover it. That could be a compromised host, an insider, or another system positioned along the path.
Secrets placed in URLs have an additional problem: the URL may persist in browser history, proxies, web server logs, monitoring systems, and other places long after the original request is gone. Broken integrations can make this worse.
A job stuck in a retry loop may send the same credential hundreds of times. The application is failing, but from a credential-exposure perspective it is doing an excellent job of repeatedly broadcasting the secret.
What to do
The remediation depends on what you find:
- Move HTTP authentication behind HTTPS or a stronger authentication mechanism.
- Replace FTP with SFTP or FTPS.
- Protect LDAP authentication with TLS and appropriate signing requirements.
- Remove credentials and secrets from URLs.
- Rotate credentials confirmed to have been exposed.
- Check whether the integration actually needs the privileges the account has.
Fixing the transport is important. Fixing an unnecessarily privileged account at the same time is even better.
Hunt 2: Kerberos still using RC4
The next hunt is not whether Kerberos exists in your environment, but to ask whether something is still forcing Kerberos to use encryption you intended to leave behind.
Where your network telemetry exposes Kerberos encryption information, look for RC4 service-ticket activity.
What to observe
Useful shapes include:
- Service tickets using RC4 where AES should be available
- RC4 activity concentrated around a particular service or service identity
- Multiple systems falling back to RC4 when accessing the same service
- A legacy application, appliance, or device class consistently associated with RC4
If dozens of endpoints show the same weak encryption only when they communicate with one service, the probable solution is to fix the common dependency.
Why it stands out
RC4 is legacy Kerberos encryption that Microsoft is actively working to eliminate from normal Active Directory environments. Its continued use can also increase exposure to offline password-cracking techniques associated with Kerberoasting.
Since this is a hygiene hunt, it doesn't mean finding RC4 means you found Kerberoasting. You found a condition that could make that technique more useful to an attacker.
What to do
Identify the service, identity, device, or application associated with the RC4 traffic.
Next, determine why that dependency cannot negotiate AES and remediate it according to the environment it lives in. A traditional service account, an appliance with an old keytab, and a legacy application may all require different fixes.
The useful part of hunting from network telemetry is that verification is straightforward: run the same hunt again and confirm that subsequent exchanges no longer use RC4.
Hunt 3: Forgotten devices with too much access
Every environment accumulates devices that do not behave like normal managed endpoints. From security cameras and medical equipment to printers and IOT devices, even an SMB can have a sizable collection for normal business usage.
What to observe
Look for:
- Network peers communicating with managed endpoints but missing from your managed asset inventory
- Vendor or device information that helps classify unknown systems
- Unexpected device-to-workstation communication
- Device management servers communicating broadly with domain infrastructure
- Device networks that appear effectively flat with user workstation segments
- Hard-to-patch systems with broad access to the rest of the environment
Depending on your telemetry source, you may be able to enrich an unknown peer with its MAC address, vendor, protocol, hostname, or other information that helps establish what it actually is.
The goal is to move from:
10.20.4.17 talks to 36 workstations
to:
10.20.4.17 is part of the camera-management environment and probably should not be talking directly to 36 workstations.
That is a much more useful finding.
Why it stands out
These devices are often harder to patch, may not support an endpoint agent, and can provide very little host telemetry if they are compromised.
The important finding is not the asset or device itself, but that an unmanaged or semi-managed device class has more network reach than it needs.
Attackers see flat networks and can turn the compromise of one system into opportunities against many others.
What to do
Start by matching what you discovered against the asset inventory. From there:
- Patch or replace unsupported devices where possible.
- Deploy an endpoint agent where one is supported.
- Document systems that deliberately remain agentless.
- Segment device classes from general workstation networks.
- Restrict communication between device-management systems and domain infrastructure to what is actually required.
By taking these steps, the goal is to make sure compromise of one does not automatically provide a path to everything else.
More hygiene hunts hiding in the same telemetry
Once you start looking at network data as a posture signal instead of only an intrusion signal, other hunts fall out quickly.
- Dead-service authentication loops
- Look for systems repeatedly authenticating toward services that no longer exist or should no longer be used: a forgotten scheduled task or stale integration can generate thousands of failed requests.
- These requests are probably not an attack. But removing it reduces noise and makes the genuinely-unusual authentication activity easier to see.
- Unexpected inbound exposure
- Use network visibility to identify services that are externally reachable when nobody intended them to be.
- Ask, Does this need to be exposed to the internet? If the answer is no, remove or restrict the exposure.
- Legacy protocol inventory
- Your network can tell you which deprecated protocols are not merely enabled, but actually still in use. Depending on your telemetry, that might include SMBv1, NTLM, old TLS versions, legacy cleartext protocols, or outdated clients and implementations.
- Usage gives you something configuration inventories often cannot: the dependency you need to remove before you can safely turn the old thing off.
Make hygiene hunting part of the cadence
A hygiene finding usually does not need an incident bridge and an emergency containment plan. It becomes planned remediation prioritized against the risk and business need. But it should not disappear into a ticket queue either.
Once you fix a condition, turn what you learned into a lightweight detection or visibility signal. If cleartext authentication returns, RC4 comes back, or a supposedly segmented device class starts reaching workstations again, you should know.
And remember that a dry result only means something where you actually have visibility. If the relevant network telemetry covers only part of the environment, “we did not find it” is not the same as “it is not there.”
You may already have enough network telemetry to run these hunts and simply are not using it this way. Spend a hunt cycle looking for what your environment gives an attacker for free. Fix what turns up, build enough visibility to know if it comes back, and then go hunting again.
Happy hunting.
Quick Reference
| Hunt |
Network signal |
Remediation |
| Cleartext credentials |
Unprotected authentication or secrets visible in protocol metadata |
Encrypt transport, remove exposed secrets, rotate credentials |
| Kerberos RC4 |
RC4 service-ticket use |
Find the legacy dependency and move it to AES |
| Forgotten devices |
Unmanaged peers with unnecessary network reach |
Inventory, patch, and segment |
| Dead-service loops |
Repeated authentication toward obsolete services |
Remove stale configuration |
| Inbound exposure |
Unexpected externally reachable services |
Restrict or remove exposure |
| Legacy protocols |
Deprecated protocols still in active use |
Migrate dependencies and disable legacy protocols |
