Would You Notice If Your Machine Was Compromised?

Pause Here for a Second:

Pause here for a second.

Look at this screen.

There is nothing strange here. No warning. No broken window. No app opening by itself. No keyboard typing alone. No clear sign that something is wrong.

And that is exactly the point.

Most people imagine a compromised machine through the Hollywood version of hacking. A glitchy screen, flashing windows, random commands, files moving alone, and a victim who instantly knows they lost control.

But real compromise does not need to look like that.

A machine can look normal while something inside it has already changed.

The desktop is only the surface. It tells us what the user can see, not what the system is doing.

So before we talk about malware, tools, or network traffic, we need to answer a simpler question:

What does "compromised" actually mean?

What Does "Compromised" Mean?

A compromised machine is not defined by how it looks.

It is defined by control.

When we say a machine is compromised, we mean that something inside the system is no longer acting only for the user. Some process, session, script, binary, or access path is giving another side influence over the machine.

That influence can be small at first.

Maybe the attacker can run one command. Maybe they can read a file. Maybe they stole a session token. Maybe they executed a payload once. Maybe they gained a shell inside the machine.

But the important idea is the same:

the machine has started doing something the user did not intend.

Of course, an attacker does not magically "receive" your computer. There has to be a path.

A user opens a malicious file. A fake installer runs. A cracked program is trusted. A password is stolen. A vulnerable service is abused. A script executes where it should not.

That first step is called initial access.

But initial access alone is not enough for real control. If the attacker wants to keep interacting with the machine, they need a way for that machine to communicate back, receive instructions, and stay reachable.

This is where the next question appears:

If the attacker has some access, how does that access become control?

That question leads us to C2.

So, What Is C2?

If compromise means that something inside the machine is no longer acting only for the user, then the next question is simple:

how does that control continue?

An attacker does not want a random one-time moment inside the system. A single command or a single mistake is not enough if there is no way to keep interacting with the machine.

There needs to be a channel.

That channel is what we call C2.

C2 stands for Command and Control. In simple words, it is the communication path between the compromised machine and the side controlling it.

The machine may check in. The operator may send an instruction. The machine may return output. Then it may wait again.

From the outside, this can look very small. Maybe just a process making a network connection. Maybe a repeated request. Maybe DNS traffic. Maybe an HTTPS connection that does not look strange at first glance.

That is why C2 is interesting from a defender's perspective.

It is not only about "a hacker controlling a computer." It is about the traces left by that control.

What process made the connection? Where did it connect? How often did it call back? Did the behavior match the role of the program? Did anything else happen before or after that connection?

This is the part we want to observe in the lab.

For this article, we are going to use Sliver as the C2 framework for our controlled environment.

Not because it is the only C2 framework, and not because this article is about teaching offensive usage.

We use it because it is open source, free to study, clear enough for lab work, actively documented, and reliable for building a defensive learning environment. It gives us a realistic way to observe the kind of behavior we want to investigate: a machine communicating back, receiving tasks, and leaving traces we can inspect with monitoring tools.

There are other C2 frameworks that appear often in red-team and adversary-emulation discussions, such as Cobalt Strike, Metasploit/Meterpreter, Mythic, Havoc, and others. Each one has its own design, ecosystem, and use cases.

But the framework is not the main point here.

The main point is the behavior.

We are not trying to celebrate the tool. We are trying to create a controlled situation where we can ask better defensive questions:

What does the machine do when a C2 channel exists? What can Windows tools show us? What does the network reveal? What does the process tree reveal? What changes if persistence is added? And which small patterns tell us that the machine is no longer acting only for its user?

For reference, the Sliver project can be found on GitHub under:

GitHub - BishopFox/sliver: Adversary Emulation Framework Adversary Emulation Framework. Contribute to BishopFox/sliver development by creating an account on GitHub.

BishopFox/sliver

Its official documentation is available through:

https://sliver.sh/docs/

From here, we can move from definition to observation.

The next step is to build a safe lab where this behavior can be watched without risking a real system.

Same Event, Two Perspectives

At this point, we have cleared the basic idea.

A compromised machine is not defined by how the desktop looks. It is defined by control.

And C2 is the channel that allows that control to continue.

But to really understand what is happening, we need to look at the same moment from two different sides.

The offensive side and the defensive side.

On the offensive side, the event may look simple. A terminal is open. A C2 server is running. A session appears. The operator can see that a machine has connected back.

From that view, the question is usually direct:

Do we have access?

But on the defensive side, the same moment looks different.

Windows does not say, "someone has access now."

It shows traces.

A process started. A connection was opened. A parent process launched something. A path appeared. A privilege context existed. A network pattern began. Maybe later, something tried to stay after reboot.

That is why the defensive side is more interesting for this article.

The attacker sees the result.

The defender has to reconstruct the story.

Offensive View: The Operator Side

This is the shorter side of the story.

Here we are looking from Kali Linux, inside a CLI environment, through the Sliver C2 server used in our controlled lab.

From this view, we can see that a Windows machine has checked in and that an active session exists. The operator side can see information about the target context, and in this case the session also indicates elevated privileges.

That detail matters.

Access as a normal user is one thing. Access with administrative privileges is another.

Higher privileges usually mean the operator has more visibility and more possible actions inside the target environment. It can affect what can be queried, what can be changed, and how realistic persistence becomes later in the investigation.

But we are not staying on this side for long.

The offensive view only tells us that access exists.

It does not explain what Windows had to do for that access to appear. It does not show us which process created the connection, what path it came from, what network traffic was generated, or what traces were left behind.

That is why this view is only the beginning.

The real investigation starts when we turn around and look at the same moment from the Windows side.

Defensive View : Now We Start Looking for Traces

This is the point where the article becomes more important.

Until now, we explained what compromise means, what C2 is, and how the same moment can look different from the operator side and the defender side.

But the real question is not:

"Can someone get access?"

The real question is:

"How would we know that access happened?"

A Windows desktop will not always answer that for us. The screen may stay normal. The user may keep working. Nothing obvious may appear.

So we have to stop looking at the surface and start looking at what changed inside the system.

But before we do that, we need visibility.

We are not going to investigate this only by looking at the desktop, and we are not going to depend on guesswork. The normal Windows interface can show us open apps, notifications, and some running programs, but it does not show the full story of what is happening inside the machine.

If something suspicious is running quietly, we need tools that let us see deeper.

We need to know which processes are active. We need to know who launched them. We need to see where they are running from. We need to watch network connections. We need to inspect file activity, registry changes, startup entries, and timing.

For that, we use tools like Sysinternals and Wireshark.

links:

Sysinternals - Sysinternals Library, learning resources, downloads, support, and community. Evaluate and find out how to install, deploy, and…

Wireshark * Go Deep The homepage for Wireshark, the world's leading network protocol analyzer.

Sysinternals helps us understand what Windows is doing internally. It gives us a better view of processes, parent-child relationships, command lines, file activity, registry activity, startup entries, and persistence points.

Wireshark helps us understand the network side. It lets us see traffic moving in and out of the machine, which is important when we are dealing with C2 behavior.

Because C2 is not only a process problem.

It is also a communication problem.

A machine that is under control usually needs some kind of channel. That channel may create connections, repeated traffic, DNS requests, or patterns that do not match normal user behavior.

So before we ask whether the machine is compromised, we need tools that let us see enough of the machine to ask better questions.

We are not using these tools to get a magic answer.

We are using them to collect pieces of the story.

This is the defensive part of the investigation.

We are not trying to prove compromise from one sign. A single process is not enough. A single connection is not enough. A single file touch is not enough.

What we are looking for is a chain.

A process started. It came from a certain path. It opened a connection. It repeated that connection. It touched something it should not touch. It tried to stay available.

One sign can be noise.

A sequence of signs becomes a story.

That is why we will split the investigation into clear sections.

First, we look at the process side:

Which process appeared?
Where did it run from?
Who launched it?
Does its parent process make sense?
Is it running with normal user rights or elevated privileges?

Which process appeared?
Where did it run from?
Who launched it?
Does its parent process make sense?
Is it running with normal user rights or elevated privileges?

Then we look at the network side:

Did that process open a connection?
Where did it connect?
Was the connection repeated?
Does the timing look like beaconing?
Does the network behavior fit the program's role?

Did that process open a connection?
Where did it connect?
Was the connection repeated?
Does the timing look like beaconing?
Does the network behavior fit the program's role?

Then we look at file and system activity:

What did the process touch?
Did it read user files?
Did it access sensitive paths?
Did it write somewhere unusual?
Did it interact with registry keys or startup locations?

What did the process touch?
Did it read user files?
Did it access sensitive paths?
Did it write somewhere unusual?
Did it interact with registry keys or startup locations?

After that, we look at persistence:

Did anything try to survive reboot?
Was a startup entry created?
Was a scheduled task added?
Was a service changed?
Did the same behavior come back after restart?

Did anything try to survive reboot?
Was a startup entry created?
Was a scheduled task added?
Was a service changed?
Did the same behavior come back after restart?

Finally, we connect everything together.

This is where the offensive and defensive views meet.

From the operator side, the story may look simple: access appeared, a session checked in, and commands could be sent.

From the Windows side, that same story must be reconstructed from traces:

process
path
parent
privilege
connection
timing
file activity
persistence

process
path
parent
privilege
connection
timing
file activity
persistence

That is the structure we will follow.

We will not jump randomly between tools. We will not repeat the same idea under different names. Each section has one job.

Process tells us what ran. Network tells us where it talked. File and registry activity tell us what it touched. Persistence tells us whether it tried to remain. Timeline connects the pieces.

Only after that can we return to the attacker's mechanism and explain, at a high level, how the access path we used in the lab created these traces.

And at the end, we can briefly mention other ways attackers may try to keep access, not as a guide to abuse, but as a defensive map of what investigators should know to look for.

Process View: What Ran?

The first tool I used on the Windows side was Process Explorer from Sysinternals.

The goal was simple:

find the process that deserves to be followed.

Not the process that "looks scary." Not the process with a dramatic name. The process whose context does not fully explain itself.

Full Process List

At first, the process list looks noisy.

There are Windows services, browser processes, security components, Sysinternals tools that I opened myself, and normal background activity.

So I did not start by judging names.

I started by looking at context.

In Process Explorer, the useful fields here were:

Process PID Description Company Name CPU Private Bytes Working Set

From the full view, most Windows processes had a normal description and a clear company name, usually Microsoft Corporation.

That does not make them impossible to abuse, but it gives us a baseline.

Then one process became worth checking:

update.exe

The name is generic. The company information is not clearly trusted like the surrounding Microsoft processes. And it sits in the process tree as something that needs more context.

At this point, update.exe is not proof.

It is only the first lead.

Reducing the View

After spotting it in the full list, the next step was to reduce the view around that process.

In Process Explorer, I searched for:

update.exe

This is important because once a process becomes a lead, I do not want to keep staring at the full process list. The full list creates noise.

Now the question becomes narrower:

What exactly is this process?

For this process, I wanted to check:

PID Parent process Image path Command line User Integrity level Verified signer

The process name alone was not enough.

A fake-looking name can be harmless. A normal-looking name can be suspicious.

So the name only opened the door.

The details decide whether we keep following it.

Process Properties: Image Tab

After isolating update.exe, the next step was to open its properties inside Process Explorer.

This is where the process stopped being just a name in the list.

In the Image tab, three details immediately mattered.

First, the path:

C:\Users\Admin\Desktop\New folder\update.exe

That path does not look like a normal Windows update component. A real Windows updater should not normally live inside a user desktop folder called New folder.

Second, the command line points to the same executable:

"C:\Users\Admin\Desktop\New folder\update.exe"

So this is not just a random label in the process list. This is the actual binary that was executed from that location.

Third, Process Explorer shows an autostart location:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\MediaUpdateTask

This is the most important detail in the screenshot.

Now the process is no longer only "something running now."

It has a persistence clue.

A Run key under HKCU means Windows can start this entry again when that user logs in. The name MediaUpdateTask also tries to look normal, but the target behind it points back to the same suspicious update.exe.

This gives us a much stronger lead:

a generic updater name, running from a user-controlled folder, with no clear trusted identity in the visible metadata, and linked to a registry autostart location.

At this point, the investigation becomes more focused.

We are not asking "is there anything suspicious somewhere in the system?" anymore.

We now have a concrete object to follow:

C:\Users\Admin\Desktop\New folder\update.exe

The next questions become technical:

What does this executable do? Does it open a network connection? Does it communicate with the C2 side? What files or registry keys does it touch? Does the autostart entry really bring it back after login or reboot? Does its behavior match the access we saw from the operator side?

This screenshot does not finish the investigation.

But it tells us we are looking in the right place.

The process view gave us the file. The Image tab gave us the path. The autostart field gave us the persistence clue.

Now we can move from identity to behavior.

Strings Tab: Reading Static Clues

After checking the path and autostart location, I moved to the Strings tab inside Process Explorer.

This tab does not prove the full behavior of the program.

But it gives hints about what the binary may contain, what it may reference, and what we should verify next with dynamic tools.

In this screenshot, a few strings are important.

The first one is a registry-looking path:

Software\Classes\CLSID\{...}\InprocServer32

This is not a random string to ignore.

InprocServer32 is commonly associated with COM registration, where Windows loads a DLL or component through a registry-defined path. Seeing this kind of registry path inside a suspicious process does not prove abuse by itself, but it gives us a very specific direction:

we need to check whether update.exe reads, writes, or depends on registry keys related to CLSID or InprocServer32.

The second interesting part is the compiler/runtime artifacts.

The strings show C++ standard library references and paths such as:

/usr/lib/gcc/x86_64-w64-mingw32/...

This suggests that the binary was likely built with a MinGW-w64 / GCC toolchain, or at least contains artifacts from that toolchain.

That matters because it does not look like a normal Microsoft-signed Windows component.

Again, this is not final proof.

But it adds context.

So now the process has multiple weak signals pointing in the same direction:

generic name: update.exe user-controlled path: Desktop\New folder registry autostart location: CurrentVersion\Run\MediaUpdateTask registry-related string: CLSID\...\InprocServer32 compiler artifacts linked to MinGW/GCC

This is how the pattern becomes stronger.

The Strings tab also helps us avoid guessing.

Instead of saying "this is malicious" too early, we extract questions:

Why does this executable contain a COM-related registry path? Does it actually read that path during runtime? Does it create or modify registry values? Does it load something from that registry location? Does it connect outside after reading those values? Is it only a visible loader for something stored elsewhere?

At this stage, we still do not explain the full mechanism.

We only build the next step of the investigation.

The string gives us a target.

Now we need to verify it with runtime evidence.

That means moving to Process Monitor and filtering on the same process:

Process Name is update.exe

Then we look for registry activity:

RegOpenKey RegQueryValue RegSetValue RegCreateKey

And we pay special attention to paths containing:

CurrentVersion\Run MediaUpdateTask Software\Classes\CLSID InprocServer32

This is where the investigation becomes more precise.

The Strings tab gave us clues.

Process Monitor will tell us whether those clues are actually used while the process is running.

Registry Activity: Did update.exe Use Those Keys?

The Strings tab gave us a registry clue.

It showed a path related to:

Software\Classes\CLSID\...\InprocServer32

But a string inside a binary is only a hint.

To know whether the process actually touched that area of the registry, I moved to Process Monitor.

The filter was kept narrow:

Process Name is update.exe Include

Then I focused on registry operations:

Operation begins with Reg Include

This removed most of the Windows noise and kept the view focused on what update.exe was doing inside the registry.

In the screenshot, the important operation is:

RegEnumValue

This matters.

RegEnumValue does not mean the process is writing to the registry.

It means the process is enumerating values under a registry key. In simpler words, it is asking Windows:

"What values exist here?"

The path shown in Procmon points to:

HKCU\Software\Classes\CLSID\{...}

And the result is repeatedly:

SUCCESS

That tells us the process was not just carrying a registry string inside the binary. It was actively walking through that registry location at runtime.

The Detail column also shows repeated index values, such as:

Index: 318 Index: 319 Index: 320 and so on.

That pattern is important.

It suggests that update.exe is not checking one single value and stopping. It is enumerating through many values under the same registry branch.

So the correct interpretation here is:

update.exe is collecting or reading registry data from the CLSID area.

Not writing yet. Not proving modification by this screenshot alone. But clearly reading through that registry space.

This is why the Process Monitor evidence is useful.

From Process Explorer, we already had:

update.exe running from a user-controlled path an autostart location connected to the process registry-related strings inside the binary

Now Procmon adds runtime behavior:

update.exe is actively enumerating registry values under HKCU\Software\Classes\CLSID\...

That makes the earlier Strings clue stronger.

The string was not random.

The process actually went there.

At this point, the investigation becomes more focused.

The question is no longer:

"Does this binary contain registry-looking text?"

The question becomes:

"Why is this process reading through this registry branch, and what data is it trying to recover from it?"

That is where the next step comes in.

If a process is reading many registry values, especially under a path we already saw in its strings, we need to check whether this registry data is only configuration, a COM-related lookup, or part of a staged execution chain.

The key point is this:

we do not jump directly to the final mechanism.

We follow the evidence.

Strings gave us the target. Procmon confirmed registry enumeration. Now we need to understand what happens after those reads.

Does the process open files? Does it allocate memory? Does it create another process? Does it start network communication? Does the timing match the C2 session seen from the offensive side?

This is how the story becomes technical without guessing.

The registry activity tells us that update.exe is not idle.

It is reading from a specific registry area.

Now we follow what it does next.

Registry Activity: What Did update.exe Read?

After the Strings tab showed a registry-related path, I needed to verify whether this was only a static string inside the binary or something the process actually used while running.

For that, I used Process Monitor.

The filter was kept narrow:

Process Name is update.exe Include

Then I focused only on registry activity:

Operation begins with Reg Include

This removes most of the noise and keeps the view focused on what update.exe is doing inside the registry.

[Image — Procmon showing update.exe enumerating CLSID registry values]

In this capture, the important operation is:

RegEnumValue

The path points to:

HKCU\Software\Classes\CLSID\...

And the result is repeatedly:

SUCCESS

This does not mean update.exe is writing to the registry.

It means the process is enumerating values under that registry key. In other words, it is walking through that registry location and asking Windows what values exist there.

The repeated index numbers in the Detail column make the pattern clearer:

Index: 318 Index: 319 Index: 320 Index: 321 and so on.

That is not a single random lookup.

It is a repeated registry enumeration pattern.

This matters because we already saw a CLSID / InprocServer32-related clue in the Strings tab. Now Procmon shows that update.exe actually touches that registry area during runtime.

So the chain becomes stronger:

update.exe contains registry-related strings → Procmon shows update.exe reading through the same registry area → the registry is not just a static clue → it is part of the process behavior

At this stage, I am still not jumping to the final mechanism.

But now we know something important:

update.exe is not just running from an unusual path.

It is actively collecting or reading data from the registry.

The next question becomes:

what happens after this registry enumeration?

Does it open a file? Does it load something? Does it create another execution event? Does it move into network communication?

That next action is what will tell us what role the registry data plays in the full behavior chain.

Network Activity: Did update.exe Call Back?

After the registry view, we had a stronger lead.

update.exe was not only running.

It was reading through registry values under:

HKCU\Software\Classes\CLSID\...

That matters, but it is still not the full story.

A process can read the registry for many reasons.

So the next question was:

after this registry activity, did the same process communicate outside the machine?

This is where I stayed focused on the same object.

Not all network traffic. Not the whole Windows machine. Only update.exe.

The PID from the Procmon view gave us a useful pivot:

update.exe PID: 4840

So the next step was to check whether this same process had an active connection.

First, I checked the TCP/IP tab inside Process Explorer.

The fields that matter here are:

Local Address Local Port Remote Address Remote Port State

If the same process that reads registry values also opens a connection to a remote address, the chain becomes much stronger.

Then I used TCPView to confirm it from a network-focused Sysinternals view.

The filter was simple:

update.exe

or by PID:

4840

This is important because the goal is not to say:

"Windows has network traffic."

Windows always has network traffic.

The goal is to say:

update.exe, the same process we already marked as suspicious, is the one talking outside.

That gives us a cleaner chain:

process found → unusual path → autostart clue → registry enumeration → network connection

At this point, the investigation is no longer built on one weak indicator.

It is built on behavior that keeps connecting back to the same process.

If TCPView or the TCP/IP tab shows an established remote connection, the next step is to take that remote IP and port into Wireshark.

Not to capture everything.

Only to answer one question:

what does the traffic from update.exe look like?

This is the important part of the network check.

The connection is not being treated as random Windows traffic. It is tied back to the same process we have been following from the beginning:

update.exe

That matters because the investigation is now connected across categories.

The process view gave us the executable. The Image tab gave us the path and autostart clue. Procmon showed registry enumeration. Now the network view shows that the same process is also involved in external communication.

At this point, the question becomes more precise.

Not:

"Does this Windows machine have network traffic?"

But:

"Why is this specific process, running from this specific path, after reading this registry area, opening this specific connection?"

That is the difference between noise and investigation.

Now we have enough to move into Wireshark.

Not to inspect every packet.

Only to look at the traffic shape created around this connection.

Wireshark View: What Does the Traffic Look Like?

At the end of the previous section, we already had the important pivot:

update.exe was tied to a remote connection.

That means we do not open Wireshark blindly.

We already know what we are looking for:

traffic leaving the Windows machine toward the same remote side connected to update.exe.

1. Filtering the Outbound Side

The first filter I used was:

ip.dst == <REMOTE_IP>

I used ip.dst here because I wanted to focus on packets going to the remote side.

This is different from:

ip.addr == <REMOTE_IP>

ip.addr shows both directions. ip.dst shows only traffic where the remote host is the destination.

At this stage, I cared about the outbound side because I wanted to see what the Windows machine was trying to reach.

2. Isolating the TLS Handshake

After seeing the outbound traffic, the next filter was more specific:

tls.handshake.type == 1 && tls.handshake.extensions_server_name

This focuses on TLS Client Hello packets where the SNI value can appear.

If needed, it can be combined with the destination filter:

ip.dst == <REMOTE_IP> && tls.handshake.type == 1 && tls.handshake.extensions_server_name

3. Reading the Traffic Pattern

After getting the destination and SNI, I moved from identity to pattern.

The next question was:

was this one request, or repeated communication?

For that, I looked at the packet list with columns like:

Time Source Destination Protocol Length Info

Here, the useful filter can be broader:

ip.addr == <REMOTE_IP>

This shows both directions between the Windows machine and the remote host.

If I want only outbound packets again, I go back to:

ip.dst == <REMOTE_IP>

4. Summarizing the Conversation

Packet lists can become noisy, so I also checked:

Statistics → Conversations

This view summarizes the communication instead of forcing us to read every packet.

It shows:

which hosts talked, how many packets were exchanged, how many bytes moved, and how long the conversation lasted.

What This Adds

Wireshark does not prove the whole case alone.

Encrypted traffic is normal. SNI is normal. TLS Application Data is normal.

But the context is not normal.

The same process we followed from Process Explorer and Procmon now has a network story around it.

The chain is becoming clearer:

update.exe was found as a process → it ran from a user-controlled path → it had an autostart clue → its strings exposed registry-related clues → Procmon showed registry enumeration → network tools tied it to a remote side → Wireshark exposed the SNI domain → repeated TLS traffic showed ongoing communication

So the Wireshark section answers one question:

what did the connection look like on the wire?

The next step is to connect this network behavior back to Windows event logs.

For that, we move to Sysmon.

What We Have Proven So Far

Before mapping this behavior to any attack technique, it is worth stopping for a moment.

One screenshot alone would not be enough.

A strange process name alone is weak. A registry read alone is weak. Encrypted TLS traffic alone is normal. Even an autostart clue alone does not explain the whole story.

But here, the evidence does not stand alone.

It connects.

Process Explorer showed us update.exe as the process worth following.

The Image tab showed that it was running from an unusual user-controlled path, and that it was linked to an autostart location.

The Strings tab gave us static clues: registry-related references and compiler/toolchain artifacts that did not look like a normal Microsoft Windows component.

Process Monitor then showed runtime behavior: update.exe was using RegEnumValue against the CLSID registry area, meaning it was reading through registry values while running.

Wireshark added the network side: outbound TLS traffic, a remote destination, and an SNI domain visible during the TLS handshake.

So the case is not built on one suspicious detail.

It is built on a chain:

update.exe runs → from an unusual path → with an autostart clue → contains registry-related strings → reads registry values at runtime → communicates with a remote side → exposes a domain through TLS SNI

That is the point where the behavior becomes clearer.

We are not saying "this is suspicious" because of one name.

We are saying the same process left traces in process inspection, registry activity, and network traffic.

That is what makes the investigation stronger.

Now we can move from raw evidence to classification:

which known attack techniques does this behavior resemble?

Mapping the Behavior to MITRE ATT&CK

Now that the evidence chain is clear, we can map what we saw to known attack behavior.

But this part needs to be careful.

MITRE ATT&CK is not a magic verdict.

It does not say "this machine is hacked" by itself. It gives us a language to describe behavior.

So instead of saying:

"this is technique X"

we ask:

"which technique does this behavior resemble, and how strong is our evidence?"

That difference matters.

1. Persistence: Registry Run Key

The first clear behavior is persistence.

In Process Explorer, the Image tab showed an autostart location connected to update.exe:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MediaUpdateTask

This matches the idea of using a Registry Run key to make something execute again when the user logs in.

So this maps strongly to:

T1547.001 — Registry Run Keys / Startup Folder

The important point is not only that a Run key exists.

The important point is what it points to.

In our case, the referenced executable was:

C:\Users\Admin\Desktop\New folder\update.exe

That path does not look like a normal Windows component or a trusted vendor updater path.

So the persistence clue is strong because it connects two things:

autostart location → unusual executable path

This tells us that update.exe was not only executed once.

It had a way to come back.

2. Discovery: Registry Enumeration

The second behavior came from Process Monitor.

Procmon showed update.exe repeatedly using:

RegEnumValue

against:

HKCU\Software\Classes\CLSID\...

This does not mean the process wrote to the registry.

It means it was enumerating registry values.

So the clean mapping here is:

T1012 — Query Registry

This is not persistence by itself.

This is discovery or data collection from the registry.

The important part is that the registry path was not random. We had already seen related registry strings in the Process Explorer Strings tab.

So the chain is:

Strings showed a registry clue → Procmon confirmed runtime registry enumeration → the process was actually reading through that area

This makes the registry behavior real, not just a static artifact inside the binary.

3. Command and Control: Web Protocols

The third behavior came from the network side.

Wireshark showed outbound TLS traffic to a remote side, and the TLS handshake exposed an SNI domain.

That gives us a possible C2 communication pattern.

The mapping here is:

T1071.001 — Application Layer Protocol: Web Protocols

But again, we should be precise.

TLS traffic alone is normal.

A browser uses TLS. Windows services use TLS. Many legitimate applications use TLS.

So the traffic becomes interesting only because it connects back to the same process chain:

update.exe → unusual path → autostart clue → registry enumeration → outbound TLS traffic → SNI domain

That is why we do not say:

"TLS means C2."

We say:

"TLS communication from this process supports the C2 behavior we already observed from the lab side."

The process context makes the network evidence meaningful.

4. COM-Related Clue: Not Confirmed Yet

The Strings tab also showed a path related to:

Software\Classes\CLSID\...\InprocServer32

That is important, but we have to be honest about what it proves.

A CLSID or InprocServer32 reference can be related to COM behavior.

But at this point, we have not proven COM hijacking.

To claim something like:

T1546.015 — Component Object Model Hijacking

we would need stronger evidence.

For example:

a COM registry reference being modified, a legitimate COM object being redirected, a DLL or payload path replacing the original reference, or execution triggered through that COM relationship.

Right now, what we have is weaker:

the binary contains a COM-related string, and Procmon shows registry enumeration under the CLSID area.

That is enough to say:

"this is an area to investigate."

It is not enough to say:

"COM hijacking happened."

This is important because good analysis is not only about finding scary technique names.

Good analysis is knowing what you can prove and what you cannot prove yet.

What We Can Say Confidently

From the evidence we collected, we can say:

update.exe was running from an unusual user-controlled path.

It had an autostart clue under the current user Run key.

It contained registry-related strings.

It enumerated registry values at runtime.

It communicated with a remote side over TLS.

It exposed an SNI domain during the TLS handshake.

So the strongest MITRE mapping is:

T1547.001 for the Run key persistence behavior.

T1012 for the registry enumeration behavior.

T1071.001 for the web-protocol communication pattern.

And the COM-related registry path remains a lead, not a confirmed technique.

That is the cleanest way to classify what we saw.

Not by forcing the evidence into a dramatic attack name.

But by mapping each observed behavior to the closest defensive category.

Why Some Attacks Are Harder to Spot

The case we followed was useful because it gave us visible traces.

update.exe had a generic name. It ran from a strange path. It had an autostart clue. It read from the registry. It opened encrypted traffic to a remote side.

That made the investigation easier to follow.

But real attacks are not always this noisy.

This screenshot shows why looking only at the process list is not enough.

Here, we are not looking at a strange standalone executable like update.exe.

We are looking deeper, inside a normal Windows process, through Process Explorer's DLL / handle search view.

A process like explorer.exe can load many DLLs during normal Windows activity. Most of them may come from expected locations such as:

C:\Windows\System32\...

That is normal.

But this is exactly why cleaner attacks are harder.

If suspicious code appears through a loaded DLL, injected code, or an unexpected module inside a trusted-looking process, the main process name may not look suspicious at all.

From the outside, the process list may look clean.

The suspicious part may be one layer deeper.

So the question changes.

We are no longer asking only:

"Is there a strange process?"

We also ask:

"Is a normal process loading something it should not load?"

That means checking:

module name, DLL path, company name, verified signer, load location, and whether the module comes from a trusted system path or a user-writable folder.

A DLL loaded from C:\Windows\System32 may be normal.

A DLL loaded into a trusted process from AppData, Temp, Downloads, or a strange application folder deserves more attention.

The same idea applies to process injection.

A cleaner attack may not create an obvious process called update.exe. Instead, the activity may appear under a process that already exists. The process name looks normal, but its behavior changes.

That is harder to spot because the defender cannot rely on the name anymore.

The defender has to look at context:

What modules are loaded? Where did they come from? Are they signed? Does the path make sense? Did the process suddenly open a network connection? Did it start after suspicious registry activity? Did it begin behaving outside its normal role?

DLL side-loading and DLL hijacking can also make the picture less obvious.

Instead of launching a suspicious executable directly, a legitimate-looking program may load an unexpected DLL from a location it should not trust.

Living-off-the-land behavior can make things even more confusing. Tools already present on Windows, such as PowerShell, rundll32, regsvr32, mshta, wscript, or scheduled tasks, can be abused in ways that look less obvious than a random file sitting on the desktop.

Persistence can also be quieter.

A simple Run key is easy to notice.

But persistence may appear through scheduled tasks, services, WMI event subscriptions, startup folders, COM-related paths, DLL loading behavior, or other mechanisms that do not immediately look suspicious in a quick check.

Network traffic can be cleaner too.

In our case, Wireshark showed TLS traffic and an SNI domain. That gave us something to follow.

But many legitimate applications use TLS.

So the question is not:

"Is the traffic encrypted?"

Encrypted traffic is normal.

The real questions are:

Which process created it? Where did it connect? How often did it happen? Did the timing look automated? Does the destination make sense for that process? Did this happen after suspicious registry, DLL, or process activity?

This is why harder attacks are not necessarily invisible.

They are just less direct.

The trace may not appear as one obvious file.

It may be split across:

a trusted process, an unexpected DLL, registry access, scheduled execution, network metadata, and timing.

That is why one artifact is not enough.

A clean-looking process name may hide abnormal behavior. A trusted binary may be used in an unexpected way. A normal protocol may carry suspicious communication. A small registry change may explain why the activity returns later.

The defender's job is not to panic over one sign.

The defender's job is to connect signs that should not belong together.

In our lab, update.exe was noisy enough to make the chain easy to see.

In a cleaner case, the same chain may be harder:

a trusted process starts, an unexpected DLL loads, code runs inside another process, a registry key stores configuration, a scheduled task brings it back, and HTTPS traffic blends into normal network activity.

Harder to spot does not mean impossible to investigate.

It only means the defender needs structure.

Process. Parent. Path. Command line. Signer. Loaded modules. Registry activity. Persistence points. Network destination. Timing.

The process name may lie.

The chain usually does not.

DLL side-loading and DLL hijacking can also make the picture less obvious.

Instead of launching a suspicious executable directly, a legitimate-looking program may load an unexpected DLL from a location it should not trust.

For readers who want a deeper explanation of DLL hijacking itself, Okta has a useful article that explains the idea, how DLL search order can be abused, and why tools like Process Explorer can help reveal suspicious DLL loading behavior:

DLL Hijacking Definition Tutorial & Prevention | Okta DLL hijacking refers to the exploitation of dynamic link libraries by malicious actors to execute hidden code. Discover…

Defensive Structure: How to Search Without Getting Lost

The biggest mistake in this kind of investigation is jumping too fast.

You see a strange process, so you call it malware. You see encrypted traffic, so you call it C2. You see a registry key, so you call it persistence.

That is not enough.

One artifact can mislead you.

The better way is to move through the system in a fixed order and let each layer answer one question.

Start with the process.

What ran? Where did it run from? Who launched it? What command line started it? Is it signed? Does the path make sense? Is it running with normal user rights or elevated privileges?

Then move to registry and file activity.

What did the process read? What did it write? Did it touch startup locations? Did it enumerate registry keys? Did it interact with paths that match what we saw in strings or process properties?

Then move to the network.

Did the same process talk outside? What destination did it reach? What port was used? Was TLS involved? Was an SNI domain visible? Was the traffic repeated? Did the timing look like user activity or a quiet check-in?

Then check persistence.

Does the behavior return after reboot? Is there a Run key? A scheduled task? A service? A startup folder entry? A COM-related path? A DLL loading behavior that does not fit?

Finally, connect the timeline.

This is where the investigation becomes strong.

Not:

update.exe looks strange.

But:

update.exe ran from an unusual path → had an autostart clue → exposed registry-related strings → enumerated CLSID registry values → communicated to a remote side → exposed a domain through TLS SNI → matched known behavior categories in MITRE ATT&CK

That is the difference between guessing and analysis.

A defender should not depend on one tool giving a final answer.

Process Explorer gives process context. Strings give static clues. Procmon shows runtime behavior. Wireshark shows network shape. Sysmon can preserve events for timeline analysis. MITRE gives language to classify what was observed.

None of them alone is the full truth.

Together, they let the machine explain itself.

And that is the main point of this article.

A compromised machine does not always look compromised.

The desktop may stay clean. The user may see nothing. Windows Defender may not raise a clear alert at the moment you expect.

But underneath the surface, behavior still has to happen somewhere.

Something runs. Something reads. Something connects. Something persists. Something leaves timing behind.

The job is not to look for Hollywood signs.

The job is to follow the chain.

Process. Path. Parent. Privilege. Registry. Network. Persistence. Timeline.

That structure will not catch everything.

No structure does.

But it gives you a way to think when the screen looks normal and the system is not.

Lab Shape: What We Tried to Simulate

Lab Shape: What We Tried to Simulate

Before going into the Windows evidence, it is important to clarify the shape of the lab.

The goal was not to create a perfect real-world attack.

The goal was to make the behavior realistic enough to investigate.

On one side, we had a Kali Linux machine acting as the operator side, running the controlled C2 environment.

On the other side, we had a Windows 10 machine acting as the target system.

Windows 10 was used because it still represents a very common desktop environment, and it gives us the kind of Windows behavior we want to observe: processes, registry keys, startup locations, Defender, network traffic, and user-level activity.

The C2 side was not treated as a simple local-only connection.

Instead of relying only on a raw local IP, the connection was made through a domain/tunnel-style setup to better mimic how real C2 traffic may appear from the defender's view: a Windows process communicating outward to a remote-looking destination over normal-looking encrypted traffic.

That matters because real-world C2 rarely looks like a clean lab label saying:

"this is the attacker machine."

It may look like:

a domain, TLS traffic, an external destination, a normal port, and a process that quietly checks in.

This is why the lab was useful.

It gave us a controlled place to observe the same kind of traces a defender would care about:

which process ran, where it ran from, what registry areas it touched, whether it had persistence, where it connected, what domain appeared in SNI, and whether the traffic repeated.

Windows Defender was left as part of the environment, but the investigation did not depend on it.

In this case, Defender did not give us the clear warning that a normal user might expect.

That does not mean the behavior was safe.

It means we needed to look deeper.

No alert is not the same as no compromise.

So the lab was built around telemetry, not trust.

Process Explorer showed what was running. Process Monitor showed what was touched. Wireshark showed the traffic shape. Sysmon could help preserve the same behavior as events.

That is the setup behind the investigation.

A controlled Kali side. A Windows 10 target. A domain/tunnel-style C2 path. Real Windows telemetry. And a defensive goal: understand what changes when access exists.