🔄 Topic

Practicing how to interpret packet-level evidence and explain a DNS-related network incident.

🎯 Goal

Use protocol evidence to separate user symptoms from likely technical root cause.

🛠 What I Did

Today I worked on the packet-analysis side of Course 3.

The key activity involved network-layer communication, DNS, UDP port 53, and ICMP error messages.

The important pattern was:

client sends DNS query
    ↓
query uses UDP destination port 53
    ↓
no normal DNS answer returns
    ↓
ICMP error appears
    ↓
likely DNS service or path problem

This is a good example of why analysts should not stop at the user symptom.

🔗 Key Cybersecurity Connections

A user may report:

The website is down.

But the evidence may show:

DNS resolution failed before HTTP or HTTPS even started.

That distinction matters. If DNS fails, the browser may never learn the server IP address. The web server might be fine. The failure could be DNS service, firewall, routing, or port availability.

🔍 Investigation Questions

  • What time did the issue occur?
  • Which client sent the DNS query?
  • Which DNS server was queried?
  • Was UDP port 53 used?
  • Was there a valid DNS response?
  • Was there an ICMP unreachable error?
  • Was the DNS server listening on port 53?
  • Did the firewall block DNS traffic?
  • Did the issue affect one host or many hosts?

🚨 Detection Opportunities

Detection and monitoring ideas:

  • repeated DNS queries without responses
  • ICMP destination or port unreachable after DNS requests
  • multiple clients failing resolution at the same time
  • DNS server reachable by ping but not responding on port 53
  • firewall denies involving UDP/53

Example evidence note:

protocol=UDP
dst_port=53
response=ICMP_port_unreachable
interpretation=DNS_service_or_path_unavailable

🧭 MITRE ATT&CK Techniques

Do not force a MITRE mapping if the evidence only shows an outage.

If later evidence confirms malicious activity, possible mappings may include:

  • T1498 — Network Denial of Service
  • T1499 — Endpoint Denial of Service
  • T1071 — Application Layer Protocol

🗺 Visual Investigation Diagram

User symptom
    ↓
DNS query observed
    ↓
UDP/53 identified
    ↓
ICMP error returned
    ↓
DNS failure suspected
    ↓
Root-cause checks

⚠ Challenges

The challenge is not jumping from symptom to conclusion.

‘Website down’ is a symptom. It is not root cause. The analyst must follow the protocol evidence.

📚 What I Learned

I learned that packet-level evidence can quickly narrow an incident. Protocol, port, and response type can tell me where in the chain the failure likely happened.

➡ Next Steps

  • Practice reading tcpdump-style lines
  • Create a DNS failure incident summary
  • Separate known facts from likely causes
  • Avoid calling outages attacks without supporting evidence

🧠 Reflection

This was very useful for SOC reporting. A clear incident summary should explain the observed traffic, the interpretation, and what should be checked next.

🧩 Lessons Learned

What worked

Using protocol evidence instead of guessing.

What broke

User symptoms can mislead the investigation.

Why it broke

The visible symptom may happen far away from the actual failure point.

Fix / takeaway

Trace the communication path layer by layer.

📈 Skill Progression Context

This supports my SOC analyst and detection engineering progression because it turns course material into investigation habits: identifying assets, reading evidence, asking better questions, and explaining security risk clearly.

Instead of treating the certificate as passive study, I am using each topic to build practical analyst thinking that can later become lab notes, detections, diagrams, or portfolio writeups.

😄 TL;DR

The website may not be down. DNS may have failed before the browser got there.