You Typed a URL. Now What? A SOC Analyst's Journey Through DNS, IPs & HTTPS

You type google.com. You press Enter. Two seconds later, the website appears.

Simple, right?

Not really.

Behind that innocent little Enter key, your computer just performed a small networking adventure involving DNS, IP addresses, TCP, TLS, HTTPS, and multiple servers.

You do not see any of it. You just see Google.

As a normal user, that is fine. As a SOC Analyst, you probably want to know what happened — because the same process occurs when someone clicks a phishing link. The only difference is where the conversation takes you.

So let’s follow the journey.

---

Step 1: Your Computer Asks DNS

You typed google.com, but your computer cannot simply shout: “Hey Internet, give me Google.” It needs an IP address.

That is where DNS — Domain Name System — comes in.

Think of DNS as the internet’s contact list. You know your friend’s name, but not necessarily their phone number. You search for Rahul, and your phone finds +91-XXXXXXXXXX.

DNS does something similar:

google.com
     ↓
    DNS
     ↓
142.xxx.xxx.xxx

Now your computer knows where it needs to go.

This is also the first point where a SOC analyst may become interested. DNS is not used only for normal websites:

• Malware may contact a command-and-control domain.
• Phishing campaigns use malicious domains.
• Attackers can abuse DNS to hide communication.

A DNS query is not automatically suspicious. But what was queried, who queried it, and what happened afterward can become very important.

Step 2: Your Computer Gets an IP Address

DNS gives your computer an IP address, for example: 142.xxx.xxx.xxx.

Think of it like a delivery address. You do not tell the driver, “Bring the food somewhere in Hyderabad.” You give an actual address. The IP address serves a similar purpose.

Now your computer knows where to send traffic — but it still needs to know which service it is talking to. That is where ports come in.

Step 3: Hello, Port 443

When you visit a normal HTTPS website, you will commonly see port 443.

Device → 185.xxx.xxx.xxx:443

Does that mean it is safe? No.

Port 443 does not know whether you are talking to Microsoft or to a criminal pretending to be Microsoft. Google uses 443. Microsoft uses 443. Your company portal uses 443. Attackers can use 443 too.

The port tells you where the service is listening. It does not tell you whether the conversation is legitimate. That is why SOC analysts need context.

Step 4: TCP — Let’s Talk

Before the application starts exchanging data, a TCP connection may be established through the familiar three-way handshake:

Client                  Server

 SYN  ----------------->

      <----------------- SYN-ACK

 ACK  ----------------->

Basically:

• Client: Can we talk?
• Server: Yes.
• Client: Cool.

Connection established. Very polite — unlike most IT support tickets.

Step 5: TLS — The Conversation Gets Encrypted

You typed https://google.com. The S in HTTPS matters.

HTTPS uses TLS (Transport Layer Security) to protect the communication between your browser and the website. The connection is encrypted, so someone sitting in the middle cannot simply read everything you are sending.

Good for privacy. Good for security. And slightly annoying for SOC analysts.

Attackers can use HTTPS too. Malware does not need to announce that it is stealing data; it can communicate over encrypted HTTPS just like legitimate applications.

The SOC may not be able to see the full content of communication from network traffic alone. But the connection is not invisible. We may still have visibility into:

• Source IP and destination IP
• Domain and port
• DNS query
• User and device
• Process
• Connection timing
• Endpoint activity

That is where things get interesting.

Step 6: Your Browser Sends an HTTP Request

The secure connection is established, and your browser can request the webpage:

GET / HTTP/1.1
Host: google.com

You are essentially telling the server: “Hey, can I have the webpage?”

The server responds with something like:

HTTP/1.1 200 OK

Translation: “Sure. Here you go.” Your browser then starts loading the page.

You Didn’t Just Visit One Website

One webpage may contain images, JavaScript, CSS, fonts, APIs, analytics, and third-party content. So your browser may make dozens of additional connections.

You typed one URL, but your computer may end up talking to many domains. Welcome to the modern internet.

Now Add the SOC Perspective

Instead of google.com, imagine the user clicks micros0ft-login-example.com. Because apparently attackers believe adding a zero makes them invisible.

The same networking process happens:

User clicks link
      ↓
DNS query
      ↓
Domain resolves to IP
      ↓
Connection to port 443
      ↓
TLS encryption
      ↓
HTTPS request
      ↓
Fake login page

From the user’s perspective: “Microsoft login page.”

From the SOC’s perspective: “Why did this device resolve that domain?”

Now we investigate.

What Does the SOC Analyst Ask?

The first question is not “Is this malicious?” It is: “What happened?”

We start building the story:

Who?

Which user accessed it?

What?

Which domain and IP were contacted?

When?

When did the activity happen?

Where?

Which device made the connection?

How?

Which process created the connection?

What Happened Next?

Did the user download something? Did PowerShell execute? Did another process start? Did the machine make more suspicious connections?

That final question matters greatly because one event rarely tells the whole story.

One Connection vs. an Attack Story

Imagine you see:

LAPTOP-102
      ↓
suspicious-domain.com
      ↓
185.xxx.xxx.xxx:443

Suspicious? Maybe.

Now imagine you see:

Phishing Email
      ↓
User clicks link
      ↓
DNS Query
      ↓
Suspicious Domain
      ↓
HTTPS Connection
      ↓
PowerShell
      ↓
File Download

Now we are talking. Individual events are not necessarily the answer — the sequence is the story. That is how a SOC analyst thinks.

Why DNS Is So Valuable

DNS can give you one of the earliest clues about where a device is trying to communicate.

10:31:02  User clicks phishing link
10:31:03  DNS query for suspicious-domain.com
10:31:03  Domain resolves to suspicious IP
10:31:04  HTTPS connection established
10:31:10  PowerShell executes
10:31:15  File downloaded

DNS is not just “the thing that converts names to IP addresses.” It is part of the investigation.

Where Does the SIEM Come In?

Platforms such as Microsoft Sentinel bring together different parts of the story:

DNS logs
     +
Firewall logs
     +
EDR telemetry
     +
Identity logs
     +
Email logs
     ↓
   SIEM
     ↓
Correlation & Detection

You might see:

User: john.doe
Device: LAPTOP-102
Domain: suspicious-domain.com
IP: 185.xxx.xxx.xxx
Port: 443
Process: chrome.exe

Then another event shows:

chrome.exe
      ↓
powershell.exe
      ↓
185.xxx.xxx.xxx:443

You are no longer looking at random logs. You are connecting events — and that is the real job of a SOC analyst.

The Big Picture

When you visit a website, the journey looks roughly like this:

You type the URL
       ↓
DNS resolves the domain
       ↓
You get an IP address
       ↓
TCP connection
       ↓
TLS handshake
       ↓
HTTPS request
       ↓
Server responds
       ↓
Browser loads the page

From a SOC perspective:

DNS
 ↓
IP
 ↓
Connection
 ↓
Process
 ↓
User
 ↓
Endpoint activity
 ↓
SIEM correlation
 ↓
Investigation

Same internet. Different perspective.

Final Thoughts

The next time you type a URL and a website loads, remember that your computer had a conversation with several systems before you even saw the page.

DNS found the destination. The IP told your computer where to go. TCP helped establish communication. TLS protected the conversation. HTTPS carried the request. Your browser loaded the result.

For a normal user: “The website opened.”

For a SOC Analyst: “Where did this machine go, why did it go there, which process initiated it, and what happened afterward?”

You do not need to memorize every networking protocol to become a good SOC analyst. You need to understand the story behind the traffic.

Eventually, you will look at a simple connection:

192.168.1.25 → 185.xxx.xxx.xxx:443

Instead of thinking, “It is just port 443,” you will think: “Wait. Why is this machine talking to that IP?”

That is when networking starts becoming security.

YouTube: The Security Insider