Studying Data Exfiltration for SCOR: Netcat, DNS Tunneling, ICMP, and Defensive Controls

Why I Wrote This

I passed the CCNA in February 2026, and I am now studying for Cisco’s 350-701 SCOR v2.0 exam, Implementing and Operating Cisco Security Core Technologies [1][2]. The current SCOR blueprint includes an objective to explain exfiltration techniques such as DNS tunneling and ICMP [1]. I had seen both terms before, but I had not stopped to map what is in the request, what comes back, and which data sources could show the activity.

I wrote this post as a study note and a technical-writing exercise. I checked protocol behavior against the relevant RFCs and used MITRE ATT&CK and Cisco documentation for attack and product claims. I left out commands because I am interested in the defensive view: what the traffic looks like, what remains visible, and where controls fit.

A Working Model for Data Exfiltration

In this post, data exfiltration means the unauthorized movement of information out of an environment. MITRE ATT&CK documents exfiltration over alternative protocols when data leaves through a protocol other than an existing command-and-control channel [10]. The model I used has five steps: access the data, prepare it, choose a channel, cross the network boundary, and reach a receiving system. Each step can leave different evidence.

Figure 1. A practical view of the data-exfiltration path.

Netcat and Cryptcat

Ncat, Nmap’s modern netcat implementation, is a command-line utility that reads and writes data across networks [3]. Netcat-style tools can place one side in a listening role and let another system connect to it, creating a direct TCP or UDP path. That behavior is useful for administration and testing, but a compromised endpoint could use the same kind of socket to send information to an external listener.

Cryptcat adds encryption to data sent over TCP or UDP [4]. From a defender’s perspective, that changes the evidence rather than removing it. Content inspection may become less useful, but the process, destination, connection direction, port, timing, and volume still exist. That is why endpoint telemetry and egress policy matter even when the payload is encrypted.

Figure 2. Netcat and Cryptcat: what a defender observes.

DNS Exfiltration: What Happens to the Query

Normal DNS resolution starts when an endpoint sends a query to a recursive resolver. RFC 1035 defines the queried domain name, or QNAME, as a sequence of labels [5]. The resolver checks its cache and, when needed, follows the DNS hierarchy until it reaches an authoritative server that can answer the query.

In a DNS-exfiltration path, a local process splits or encodes data into one or more labels beneath a domain controlled by the remote operator. The endpoint sends the query to its resolver, and normal DNS resolution eventually delivers the full queried name to the authoritative server for that domain [6][7]. The authoritative server can read the encoded labels and reconstruct the chunks. Outbound queries can carry data away from the endpoint, while DNS responses can return acknowledgements or commands, which can make the channel bidirectional [6].

One long query is not enough to prove tunneling. I would look for a pattern: many unique subdomains, long random-looking labels, low cache reuse, repeated queries to an uncommon domain, unusual query volume, or endpoints bypassing approved resolvers. Resolver logs are more useful when they can be tied back to the process that generated the request.

Figure 3. DNS exfiltration query-and-response path.

ICMP Exfiltration: What Happens to the Request and Reply

ICMP is carried inside IP and is normally used for control and diagnostic messages. For IPv4 echo traffic, RFC 792 defines Echo Request as Type 8 and Echo Reply as Type 0 [8]. Both messages contain an identifier, a sequence number, and a data field. The identifier and sequence number help match requests to replies, and a normal Echo Reply returns the data it received in the Echo Request [8].

That answers a point I had been unsure about while studying: ordinary ping includes both a request and a response, but the response normally mirrors the request data. It is not independently sending a new file back to the source. In an exfiltration scenario, a custom process can place encoded chunks in the data field of outbound Echo Requests, and a remote system can extract those chunks. Some custom ICMP tunnels use crafted requests and replies as a two-way carrier, but that behavior is tool-specific rather than ordinary ping behavior [8][9].

For detection, I would look for a user process generating ICMP, sustained request-and-reply traffic to an unusual external address, repeated packet sizes, regular timing, abnormal payloads, or volume that does not match diagnostic use. MITRE specifically calls out ICMP generated by non-network service processes and fixed-size ping patterns with unusual delays as useful signals [9].

Where the Controls Fit

No single product covers every part of these techniques. Endpoint telemetry can show which process accessed the data, opened the socket, generated the DNS request, or created the ICMP traffic. Egress filtering can limit which hosts, destinations, and protocols are allowed to leave the network. MITRE recommends filtering unnecessary protocols at the boundary and routing outbound traffic through authorized gateways [9][11].

For DNS, Cisco Umbrella and Secure Access DNS Defense are examples of products designed to detect DNS tunneling and reduce DNS-based exfiltration risk [6][12]. Cisco Secure Firewall can apply Snort-based inspection policies and block traffic in inline deployments [13]. Cisco Secure Network Analytics can look for data-exfiltration behavior and flow anomalies, including activity in encrypted traffic [14]. DLP and proxy controls add policy around the data and destination, while SIEM correlation can connect endpoint, DNS, firewall, and flow evidence [15].

What I Learned

Comparing these techniques side by side changed what I pay attention to. With netcat-style traffic, I focus on the process and socket. With DNS, I focus on the queried labels, resolver path, destination domain, and query pattern. With ICMP, I focus on the message type, identifier, sequence number, payload, timing, and direction.

I can take an exam objective, check the standards and vendor documentation, and turn it into questions I could use during an investigation.

Conclusion

The CCNA gave me a stronger networking foundation, and SCOR is pushing me to connect protocols with telemetry, enforcement, and incident response. This post is one example of how I am trying to study: read the objective, check the source material, map the traffic path, and explain what a defender can see.

I want to keep using technical writing this way. It is a practical test of whether I understand the material well enough to explain it accurately and in a form someone else can use.

The views expressed here are my own and do not represent any employer or organization.

References

[1] Cisco Learning Network — 350-701 SCOR v2.0 Exam Topics. https://learningnetwork.cisco.com/s/scor-v2-exam-topics

[2] Cisco — Implementing and Operating Cisco Security Core Technologies (350-701 SCOR). https://www.cisco.com/site/us/en/learn/training-certifications/exams/scor.html

[3] Nmap — Ncat Reference Guide. https://nmap.org/book/ncat-man.html

[4] Kali Linux Tools — cryptcat. https://www.kali.org/tools/cryptcat/

[5] IETF RFC 1035 — Domain Names: Implementation and Specification. https://datatracker.ietf.org/doc/html/rfc1035

[6] Cisco Umbrella — Improvements to DNS Tunneling and DNS Exfiltration Detection. https://umbrella.cisco.com/blog/improvements-dns-tunneling-dns-exfiltration-detection

[7] MITRE ATT&CK — Application Layer Protocol: DNS (T1071.004). https://attack.mitre.org/techniques/T1071/004/

[8] IETF RFC 792 — Internet Control Message Protocol. https://datatracker.ietf.org/doc/html/rfc792

[9] MITRE ATT&CK — Non-Application Layer Protocol (T1095). https://attack.mitre.org/techniques/T1095/

[10] MITRE ATT&CK — Exfiltration Over Alternative Protocol (T1048). https://attack.mitre.org/techniques/T1048/

[11] MITRE ATT&CK — Protocol Tunneling (T1572). https://attack.mitre.org/techniques/T1572/

[12] Cisco Secure Access — DNS Defense Data Sheet. https://www.cisco.com/c/en/us/products/collateral/security/secure-access/secure-access-dns-defense-ds.html

[13] Cisco Secure Firewall — Intrusion Policy Guidance. https://secure.cisco.com/secure-firewall/v7.6/docs/intrusion-policy-73

[14] Cisco — Secure Network Analytics. https://www.cisco.com/site/us/en/products/security/security-analytics/secure-network-analytics/index.html

[15] Cisco Umbrella — Data Loss Prevention. https://umbrella.cisco.com/products/data-loss-prevention-dlp