Exposing Salt Typhoon on the network using the PEAK Threat Hunting Framework

How do you find an adversary who lives where you can't easily look? A recent CISA advisory on the state-sponsored actor "Salt Typhoon" highlights this exact challenge. These actors aren't just breaking in; they're moving in. They persist on network edge devices like routers and firewalls—critical infrastructure that often sits outside the view of traditional endpoint security. From this vantage point, they capture traffic, steal credentials, and plan their next move.

This "living off the network edge" strategy creates a significant blind spot. But it also reveals a powerful truth: the network itself is the best source of evidence to find them.

While a strong set of automated detections is the first line of defense, sophisticated threats like this demand a proactive approach. The CISA advisory makes it clear that threat hunting is essential. So, how do you turn a dense intelligence report into a practical, repeatable hunt?

A robust set of detections is the first line of defense, and Corelight’s capabilities can be leveraged to address specific attacks used by Salt Typhoon, from Suricata rules to AI-driven anomaly detection, including coverage for all exploited CVEs. (In fact, our detection for CVE-2018-0171 has been protecting customers for more than 4 years.) The platform’s flexibility can also be used to identify the tools these actors are known to abuse, including software like SoftetherVPN, and leverage Corelight’s integrated YARA file scanning to detect the actors' custom tools as they're transferred across your network.

That's where a structured methodology comes in. We’re going to use the PEAK Threat Hunting Framework to create a playbook for finding this threat. This post will walk through how to apply its core principles using rich network data. First, we'll cover how to perform a baseline hunt to define "normal" for your network devices, making it easier to spot subtle anomalies. Then, we'll dive into targeted, hypothesis-driven hunts aimed directly at the TTPs Salt Typhoon is known to use. The goal is simple: to give you a practical guide for finding this threat where it lives—on the network.

The anatomy of a PEAK threat hunt

This post walks through how to apply each of these hunting elements. Our goal is to create a practical playbook that you can use to find this threat where it lives, on the network.

The framework organizes a hunt into a simple lifecycle. You Prepare by researching the threat and forming a hypothesis, Execute the hunt by analyzing data for evidence, and then Act on your findings to create new, automated detections. This process is continuously supported by Knowledge—everything from the initial threat intelligence to the new insights you gain during the hunt itself.

Note: Baselining shouldn't be confused with Corelight's built-in anomaly detection, which uses a lot of the same principles but operates in an automated fashion. It uses unsupervised machine learning to automatically establish baselines and alert on deviations, which is a great complement to the manual deep-dive investigations you'll learn about here.

Let's walk through a practical example of a manual baseline hunt, structured with the PEAK framework, to find this kind of threat.

An example hunt: Baselining router management traffic

A particularly valuable target for baselining is the network traffic from the management interfaces of your network devices. This traffic is especially important because it isolates activity originating from the network device itself—such as administrative sessions, telemetry, or updates—from the data-plane traffic that the device is simply routing or switching for other hosts by default.

However, a crucial note on visibility before we begin: To see management plane traffic, you must be able to tap the traffic on the dedicated management networks where these interfaces live. While doing so may require a visibility expansion for some organizations, the payoff is significant because this traffic often exhibits quite consistent, predictable patterns. When that traffic deviates, it's a high-quality signal that something is likely wrong.

Prepare

The Prepare phase is about planning and making sure you have what you need for a successful hunt.

Select and research data sources: We'll start with the Zeek conn.log for its comprehensive, high-level view of all connections, and then pivot to protocol-specific logs like ssh.log for deeper context. We need to know what "normal" looks like. Legitimate traffic from a management interface should be very limited: SSH sessions from approved administrator jump boxes, SNMP polling from monitoring servers, and syslog or telemetry data going to designated collectors.

Scope & plan: Our scope will be all network device management interfaces on the network. To establish our baseline, we will analyze the last 30 days of traffic, a timeframe that should give us a solid understanding of normal activity. Our plan is to query this data to identify every unique destination IP and destination port that our management interfaces have communicated with.

Execute

With a solid plan, the Execute phase is where we analyze the data.

Gather and review distributions: We start by gathering the scoped data from our conn.log files to build our baseline. A simple query in our SIEM can show us the statistical distribution of all destination IPs and ports from our management interfaces over the last 30 days.

It's crucial to remember that this initial baseline reflects all activity—including any potentially malicious traffic that may already be present. Therefore, our goal is to treat this as a raw statistical profile, not an immediately "known-good" profile. The hunt itself is the process of validating this activity. Creating this baseline now, and routinely updating it, is a key practice for improving the fidelity of future threat hunts.

We expect to see a small number of unique destinations and ports. It’s common to find outliers specific to your organization during this process. The next step is to investigate these outliers to determine if they are legitimate traffic or signs of a threat.

Investigate outliers: Now, we hunt. During our baselining, we find an outlier: a connection from a router's management interface (10.0.1.1) to an unknown external IP (8.8.8.8) on port 22.

The initial finding in the conn.log looks like this:

This tells us that a connection happened, but it doesn't give us much context. A valuable feature of Zeek data is the uid field. We can use this unique connection identifier to pivot and find all other logs associated with this event. Searching for the uid: CsD23k4E20lJYejSg reveals the following ssh.log entry:

This log provides far more context. We can see that not only did the connection happen, but the authentication was successful ("auth_success": true). We also see the explicit direction field, which is marked as OUTBOUND, confirming that our router initiated the session.

This is a highly suspicious finding and a perfect example of an outlier that warrants immediate investigation.

While the example uses an external IP address, in reality it will likely be a small number of internal IP addresses that the source of the connection will originate from the management interface to an internal system in your network, if any. Don’t limit yourself to only external addresses.

The log gives us an even more powerful clue: the hassh and hasshServer fields.

HASSH is a method of fingerprinting an SSH connection to identify the specific client and server software being used. It works because every SSH client and server advertises a list of the cryptographic algorithms they support during the initial handshake; not only that, but they do so in a particular order that will vary from implementation to implementation.

HASSH creates a unique hash of these lists, which serves as a consistent fingerprint for that software. The hassh field identifies the client, while hasshServer identifies the server.

These hashes are quite useful for baseline hunts. For network management access, your environment likely has a small, predictable set of approved SSH clients used by administrators and automated systems. By baselining the hassh values from this known-good traffic, you can readily spot outliers. Adversaries using custom-coded tools, like the tailor-made SFTP clients mentioned in the CISA advisory (referred to as cmd1 and cmd3), or penetration testing frameworks, will produce unique hassh hashes that stand out as clear anomalies against your baseline. It's likely that these will be unique, particularly for tailor-made SSH clients, like the values we see here:

These fingerprints give you a way to identify the specific tool used in the attack, even if the IP address changes. This is a highly suspicious finding and a great example of an outlier that warrants immediate investigation.

Act

Finding an anomaly is only the first step. The Act phase is what creates lasting value by documenting our findings and improving our defenses against actors like Salt Typhoon.

• Document baseline: The primary output of this hunt is a documented baseline of normal traffic for our management interfaces. This document, which includes any benign outliers we investigated and cleared, is an invaluable resource for the security operations center (SOC) and the network team.
• Expand the hunt and refine your approach: A confirmed finding is a starting point, not an endpoint. This is the natural “peeling the onion” phase of the hunt. Use the indicators from your initial discovery, like the external IP and unique hassh values, to pivot and scour your logs for any other related activity. This helps you understand the full scope of the potential compromise.
• Equally important: Ask yourself what other baselines could have found this? Would a baseline of hassh values have worked? What about looking at data transfer volumes from management interfaces? Answering these questions helps you develop new, overlapping detection strategies, creating a robust defense-in-depth.
• Iterate: A confirmed finding is a starting point, not an endpoint. Use each piece of evidence to pivot to new searches. For example, if a compromised system resolved an unusual DNS name, the next question is clear: "What other systems looked up that same name?" This process builds a chain of evidence, turning one indicator into a map of the adversary's activity. A suspicious DNS response can lead to an IP address, that IP reveals connections to other hosts, and those connections might expose file transfers with unique hashes. Follow these threads until the trail runs cold to uncover the full scope of the compromise.
• Create detections: Alerting on any deviation from the baseline creates a powerful, high-fidelity detection. These types of organization-specific detectors are difficult for adversaries to evade.

The Act phase transforms a single hunt into a lasting security improvement. By documenting the baseline, expanding the investigation, and creating new automated detections, you do more than just close a case. This process is the heart of an intelligence-driven model: the findings from your response become the refined intelligence that fuels your next hunt, creating a continuous cycle of improvement that makes your defenses stronger over time.

The hypothesis-driven threat hunt: Targeting known TTPs

After establishing a baseline for what’s normal, we can move to a more focused, hypothesis-driven hunt. This is the classic approach where we take a specific piece of threat intelligence, form a testable statement about a potential threat in our network, and then use our data to prove or disprove it.

Prepare

The Prepare phase for a hypothesis hunt is all about translating threat intelligence into a clear, actionable plan. A raw idea isn't enough; to be effective, a hypothesis needs to be specific and testable. The PEAK framework provides a simple method for this called

ABLE. ABLE helps structure your thinking by breaking a hypothesis down into four key components:

• Actor: Who are you looking for?
• Behavior: What specific activity or TTP are you trying to find?
• Location: Where in your network would you expect to find this behavior?
• Evidence: What data sources do you need, and what would the activity look like in those sources?

By defining these elements, you create a concrete hunt plan. Here are a few examples:

• Hypothesis 1: Covert SSH Persistence. The advisory recommends hunting for SSH on high, non-default ports using patterns like 22x22 or xxx22. This leads to our first hypothesis:

  "Threat actors have established persistence on a network device by enabling SSH on a non-standard high port, such as 22022."

  Using this, we can apply the ABLE framework:

  Actor: Salt Typhoon. This actor focuses on network edge devices for persistence, using them as a gateway into the broader network.

  Behavior: Establishing persistent, covert remote access by enabling an SSH service on a network device using a non-standard, high-numbered TCP port (e.g., 22022).

  Location: The management interfaces of network edge devices, such as routers and firewalls. This is a critical chokepoint for monitoring device-initiated activity.

  Evidence: An outbound connection recorded in Zeek's ssh.log originating from a network device's management IP to an external destination on a suspicious high port (e.g., 22022, 4422, etc.). The log should show a successful authentication (auth_success: true) and an outbound direction (direction: "OUTBOUND").

  With this structured hypothesis, we have a clear roadmap for the Execute phase. For brevity, we'll continue with this single, well-defined hypothesis, but a similar ABLE-driven process can be applied to other TTPs from the advisory, such as TACACS+ redirection, data staging via FTP, unauthorized tunneling, or SNMP abuse.

• Hypothesis 2: Terminal Access Controller Access-Control System Plus (TACACS+) Redirection. The advisory recommends hunting for TACACS+ flows to unapproved IP addresses. TACACS+ is an authentication protocol commonly used to manage administrator access to network devices like routers and switches. We can reliably hunt for it on TCP port 49 because this is the well-known, standard port for the service, and referenced multiple times in the CISA advisory.

  This gives us our second hypothesis

  "Threat actors are capturing credentials by redirecting TACACS+ traffic from our network devices to an actor-controlled IP address."

  The primary Zeek log for this would be conn.log.

• Hypothesis 3: Data Staging via FTP. The advisory suggests hunting for FTP/TFTP flows from network devices to unapproved destinations, especially after on-box packet captures. This forms our third hypothesis:

  "Threat actors are staging collected data, such as packet captures, by using FTP to transfer files from a compromised router to an internal staging server."

  The best Zeek logs for this hunt are ftp.log and files.log.

• Hypothesis 4: Unauthorized Tunneling. The advisory recommends auditing for unexplained tunnels. This leads to our next hypothesis:

  "Threat actors are exfiltrating data and maintaining C2 communications through an unauthorized GRE tunnel originating from a compromised router."

  The ideal Zeek log for this is tunnel.log.

• Hypothesis 5: Unauthorized Configuration Changes via SNMP. The advisory notes that actors use SNMP to enumerate and alter device configurations, often using well-known community strings like "public" and "private." This gives us our fifth hypothesis:

  "Threat actors are using SNMP with weak community strings to issue SET commands and make unauthorized configuration changes on network devices."

  The primary Zeek log for this hunt is snmp.log.

Execute

With our hypotheses defined, we move to the Execute phase. Let's look at what the evidence for each of these would look like in our Zeek logs.

Evidence for Hypothesis 1: Covert SSH Persistence

Our hunt for this TTP would involve looking for any connections from our routers on non-standard ports that Zeek identifies as SSH. A positive finding in the ssh.log would look like this:

This log confirms a successful, outbound SSH session from our router to an unknown external host on port 22022, directly validating our hypothesis.

Evidence for Hypothesis 2: TACACS+ Redirection

To find redirected authentication traffic, we search our conn.log for any traffic on TCP port 49 (the service tacacs) that is not going to one of our approved, internal AAA servers.

This log, while simple, is a high-fidelity indicator that a device has been reconfigured to send sensitive authentication traffic to an unauthorized external destination.

Evidence for Hypothesis 3: Data Staging via Network File Transfers

The advisory details actors exfiltrating captured traffic. A powerful way to hunt for this is to look for the transfer of packet capture files themselves, regardless of the protocol. This approach allows you to cast a wider net and is a great opportunity to show the power of Zeek's file analysis.

Instead of focusing on a specific protocol like File Transfer Protocol (FTP), we can search directly for the file type. Zeek inspects the content of files transferred over the network and identifies them by their MIME type. For this hunt, we can query the files.log for any transfer where the mime_type is application/vnd.tcpdump.pcap.

This broader hunt gives us the following files.log entry:

This log provides rich metadata about the file itself, including the calculated MD5 and SHA1 hashes from the network transfer. This is valuable for incident response, as you can use these hashes to hunt for the file on other systems, submit them to threat intelligence platforms, or create blocklists.

The source field tells us this specific transfer happened over FTP, and the conn_uids field contains the unique connection identifier (uid) for the session. This uid is a powerful pivot point that links all Zeek logs related to a single connection. By searching for this uid (CdefGH345ijkLM678), we can retrieve the corresponding ftp.log entry to get more context:

This protocol-specific log confirms the finding and adds crucial details. We can now see the compromised router (10.0.0.1) used the

STOR command to upload a file named tac.pcap—matching the CISA case study—to an internal server. By starting with a broad, file-type hunt and then pivoting to protocol-specific logs, we get a complete picture of the actor's activity.

This level of file inspection was possible because the transfer used an unencrypted protocol. It's important to note, however, that the advisory indicates these same actors also use a custom SFTP client for encrypted transfers. Therefore, gaining visibility into the particulars of those files would require network traffic decryption.

Evidence for Hypothesis 4: Unauthorized Tunneling

To find covert C2 channels, we can hunt for unexpected tunnels. Zeek's tunnel.log is purpose-built for this and provides a much clearer signal than raw connection logs.

This log clearly shows the router establishing a Generic Routing Encapsulation (GRE) tunnel, a TTP explicitly mentioned in the advisory for C2 and exfiltration activities.

Evidence for Hypothesis 5: Unauthorized Configuration Changes via SNMP

To validate this hypothesis, we hunt for SNMP activity involving weak community strings combined with configuration-changing commands. The Zeek snmp.log provides direct visibility into this. A suspicious entry would show a set_requests value greater than zero, indicating a write operation, along with a common community string like "private."

This log is a strong indicator of compromise. It shows an external, unauthorized host (198.51.100.22) successfully authenticating to a router (10.0.1.1) using the default writable community string "private" and issuing a set_requests command, directly confirming our hypothesis.

Act

The Act phase is about taking our validated findings and creating lasting value.

Escalate findings: A positive finding for any of these high-fidelity hypotheses should be immediately escalated to the incident response team for containment and eradication.

Create detections: The true value of a hunt is turning its logic into automated detections. Each of these hunts provides clear logic for a high-fidelity alert:

• A rule that triggers when a network device initiates an ssh.log entry with a destination port matching a suspicious pattern (xxx22).
• A rule that triggers on any conn.log entry with a destination port of 49 where the destination IP is not in an approved list of AAA servers.
• A rule to detect when a network device generates an ftp.log entry with the STOR command and an arg ending in .pcap.
• A rule that triggers when a network device generates a tunnel.log entry of type GRE to an external destination. These are all examples of Signatures, the highest level in the PEAK Hierarchy of Detection Outputs, and they ensure we automatically catch these TTPs in the future.
• A rule that triggers when an snmp.log entry from an external source IP contains a weak community string (e.g., "private") and a set_requests value greater than 0.

From hunt to detection: Making your findings have a lasting Impact

The true purpose of a threat hunt isn't just to find a single incident; it's to create lasting improvements to the organization's overall security posture. The Act phase of the PEAK framework is where this value is created. It’s about more than just finding malicious activity or resolving an incident; it's about systematically documenting what you did, communicating what you learned, and turning your manual effort into automated defenses. Every hunt, whether it uncovers malicious activity or not, should be preserved in a way that allows another hunter to repeat it later, which is critical for training and future reference. The knowledge gained—about a new adversary technique, a gap in your visibility, or even just a benign anomaly—is most powerful when it's shared with all relevant stakeholders, including the SOC, IR teams, and the owners of the systems involved.

A crucial part of making a hunt's findings having a lasting impact is creating durable, automated detections. However, not every discovery warrants a high-severity alert. The PEAK Hierarchy of Detection Outputs provides a strategic model for choosing the right type of detection for the quality of the signal. For a high-confidence finding from a hypothesis-driven hunt, the goal is to create a Signature that can be used to detect activity matching this hypothesis in the future. This is the top of the hierarchy and the ideal outcome for a clear, validated threat.

Conclusion: Turning intelligence into lasting defense

Threat intelligence from reports like a CISA advisory is critical, but its value is only realized when it's put into action. The PEAK framework provides a practical, layered methodology to do just that. By combining broad baseline hunts, focused hypothesis-driven hunts, and creating signatures, defenders can build a proactive strategy against sophisticated actors like Salt Typhoon. A structured hunting program turns a one-time report into a continuous defense that strengthens your security posture over time. For an in-depth view of how to hunt and expose these adversary techniques, check out this report from Intel 471, which details a Typhoon hunt using Corelight data with examples in Splunk, Elastic, and CrowdStrike Falcon® LogScale.