Learn · Telemetry
Networking for Investigators
Network records are only useful if you know what they can and can't say. This unit covers the networking an investigator needs, and how a name lookup, a connection and a web request fit together.
About 10 min
- In this unit
- Just enough networking to read network evidence: addresses, ports, TCP and UDP, DNS, and web requests.
- Before you start
- How Our Ranges Work
Why it matters
Almost every intrusion crosses the network: a host looks up a name, connects somewhere, and sends or fetches something. Those steps leave records even when nothing on the host was logged.
Network records are easy to misread. A connection says two hosts talked, not what they said, and an address names a host, not a person. Knowing what each record can prove keeps your conclusions honest.
What analysts see
Network evidence reaches you as three kinds of record.
- Connection records: which host talked to which, and on which port.
- Name lookups: which name a host asked for, and when.
- Application records, such as web requests: what was asked for, and how the server answered.
Most questions need at least two of them before you can say what happened.
Core concept
Every host has an IP address. Inside an organization these are usually private ranges, such as addresses starting with 10. or 192.168.; most other addresses are on the internet. An address tells you which host, not which person: you get to the account through that host's own logs.
A connection has two ends. The client starts it from a temporary port, and the server listens on a fixed port that names its service, such as 53 for DNS and 443 for encrypted web traffic. The destination port usually tells you the service; the source port rarely tells you anything.
TCP sets up a connection before any data moves and confirms delivery. UDP just sends, and most DNS lookups use it. A completed TCP connection means the two hosts talked; it doesn't say what they said.
Hosts find each other by name. Before connecting to a name, a host asks a DNS server for its address. A lookup record ties a host to a name at a point in time, and it is often the only place a domain appears when the traffic itself is encrypted.
A web request has a method (GET to fetch, POST to send) and a path, and the server records the request in its own log. With HTTPS the request is encrypted on the wire, so a network sensor sees the connection but not the request; the full request appears only in logs from the web server or a proxy.
A connection record and an application record describe the same activity at different levels of detail. Line them up on time and addresses. Neither tells the whole story alone.
Field names depend on where a record came from. The same idea can have different names in different data: the host that asked a DNS question is id.orig_h in most of our cases' DNS records, while connection records use source.ip. Some cases also store DNS names differently. Check the field list in your data view before you search.
Annotated examples
The name lookup comes first
All values are invented. A workstation asks the internal DNS server for an address. These are the field names most of our cases' DNS data uses.
- @timestamp:
- 2026-03-10T14:02:10.981Z
- id.orig_h:
- 10.200.4.37 (note 1)
- id.resp_h:
- 10.200.1.2 (note 2)
- query:
- wiki.corp.example (note 3)
- qtype_name:
- A (note 4)
- Note 1: The workstation that asked.
- Note 2: The DNS server it asked.
- Note 3: The name it wanted.
- Note 4: "A" means it asked for an address.
A lookup ties this host to this name at this moment. It doesn't prove the host connected afterward: look for its next connection in the seconds that follow.
The connection, as the network saw it
Less than a second later, a connection record for the same workstation.
- @timestamp:
- 2026-03-10T14:02:11.204Z
- source.ip:
- 10.200.4.37 (note 1)
- source.port:
- 52814 (note 2)
- destination.ip:
- 10.200.1.15 (note 3)
- destination.port:
- 443 (note 4)
- Note 1: The same workstation: it started the connection. In this record it is
source.ip, notid.orig_h. - Note 2: A temporary port the client chose. It rarely means anything.
- Note 3: The wiki server. A connection to it right after the lookup links the two.
- Note 4: Port 443: encrypted web traffic.
The network shows who talked to whom and on which service. Because the traffic is encrypted, it can't show which page was asked for.
The request, as the web server logged it
The wiki's own web server records the same visit.
- @timestamp:
- 2026-03-10T14:02:11.338Z
- source.ip:
- 10.200.4.37 (note 1)
- http.request.method:
- GET (note 2)
- url.path:
- /pages/onboarding (note 3)
- Note 1: The same workstation, matched on address and time.
- Note 2: GET: the client fetched something.
- Note 3: The page it asked for. Only the server or a proxy sees this.
Three records, one visit. The lookup gives the name, the connection proves the hosts talked, and the server log says what was asked for.
How to investigate
- 1.
Read the field list first.
Network, DNS and web data name the same idea differently, and cases differ. Check which fields your data view carries, so an empty result means no matching events rather than a missing field.
- 2.
Start from the host.
Find its connections in the time window you care about.
source.ip: "10.200.4.37" - 3.
Name the service from the destination port.
Read the destination port, not the source port.
- 4.
Find the lookup before the connection.
Search that host's DNS lookups in the seconds before it. In most cases the asking host is
id.orig_hand the name isquery.id.orig_h: "10.200.4.37" - 5.
Look for the application record.
Search the web server's records for the same host at the same time.
source.ip: "10.200.4.37" and http.request.method: "GET" - 6.
Note what the network can't see.
Encrypted content and traffic that never passed a sensor leave no record. Check Monitoring Coverage before you treat a missing record as evidence.
Common mistakes
Mistake: Reading meaning into the source port.
InsteadIt's a temporary port the client chose. Read the destination port.
Mistake: Treating a completed connection as proof of what was sent.
InsteadOnly an application record shows the request. Find it, or say you couldn't.
Mistake: Treating an address as a person.
InsteadFind the host first, then the account through that host's own logs.
Mistake: Assuming a private address is safe.
InsteadInternal hosts connect to each other in attacks too. Judge the behavior, not the range.
Mistake: Searching a field the data view doesn't have.
InsteadRead the field list first. An empty result from a missing field looks the same as no activity.
Mistake: Assuming no lookup record means no lookup.
InsteadHosts reuse earlier answers and may ask other servers. Check what is collected.
Field references
| Field | What it tells you | Seen in |
|---|---|---|
| source.ip | The address that started the connection or sent the request | Network, web server and proxy records |
| source.port | The temporary port the client used | Network records |
| destination.ip | The address it connected to | Network records |
| destination.port | The port the server listened on, which names the service | Network records |
| id.orig_h | The host that asked a DNS question | DNS records in most cases |
| id.resp_h | The DNS server that was asked | DNS records in most cases |
| query | The name that was looked up | DNS records in most cases |
| qtype_name | What kind of answer was asked for, such as A for an address | DNS records in most cases |
| http.request.method | What the client asked to do, such as GET or POST | Web server records |
| url.path | The page or resource requested | Web server and proxy records |
| http.response.status_code | The status code the server answered with | Web server and proxy records |
| url.domain | The site requested | Proxy records |
Check yourself
- 1.
- 2.
- 3.
Apply it in a Case
On your next case, take one connection that matters and find the lookup before it and the application record for it. Write down what each one adds.
- DragnetSkills: Investigation scopingTelemetry: Network
- TrailheadSkills: Log analysisTelemetry: Network · Web logs
- TollgateSkills: Log analysis · Investigation scopingTelemetry: Proxy
References
- Elastic Common Schema, network fields · Elastic
- Elastic Common Schema, DNS fields · Elastic
- Elastic Common Schema, HTTP fields · Elastic
- RFC 1918, Address Allocation for Private Internets · IETF
- HTTP response status codes · MDN
Related in Learn
- How Our Ranges WorkA look under the hood of one of our ranges: the live, breached network you drop into, the telemetry it generates, and how a session goes from launch to auto-graded result.
- Reading the TelemetryHow to read the logs and events a range actually produces: what normal looks like, what an attack does to it, and the fields worth learning to trust.
- Searching with KQLSearch the SIEM every range runs on the way an investigation does: set the time range, ask one precise question in KQL, pin what matters and pivot on what you find.