Call Stack Analysis

EDR

Call Stack
Suppose we have a program

main()
↓
Function_A()
↓
Function_B()
↓
Function_C()`

That is, main has called Function_A

Function_A
also called Function_B

Function_B
also called Function_C

Now when Function_C is executing

We can have a picture of the call path that led the program to this point

In very simple language

We can ask

Where did this Function get here from
A simple picture of the Call Stack

┌─ Stack

Of course, in a real system, the issue is a bit more complicated than this simple picture

Because the Stack really doesn't just hold the names of the Functions, various information such as Stack Frame, Return Address, Local Data, and other things can be in the Stack

For now, to get the concept right

This simple picture is enough

Why is the Call Stack important for EDR

Suppose a sensitive API is executed

The API itself alone does not always provide us with complete information about what path led to this point
This is where the Call Stack can provide more Context

For example:

Sensitive Operation
↑
Function_B
↑
Function_A
↑
Application

Now EDR can think about

What path did this operation take?

Does this path fit with the normal behavior of this program

For example, suppose we have a Backup software

Backup.exe
↓
BackupEngine.dll
↓
Memory Manager

This path can be completely normal

Because the Backup program is doing its job

Now imagine another situation Do

Unknown Memory
↓
Unusual Execution
↓
Sensitive Operation

Here the story gets a bit more suspicious
Because the path of the operation execution is different from what we expect

But a very important point
The unusualness of the Stack alone does not mean that an attack has occurred

It may have a completely legitimate reason
So a professional EDR will not come to issue a ruling just by seeing a strange Stack

Stack Walking
Now suppose a security tool wants to check the Stack of a Thread
It can very simply check such a path

Thread
↓
Stack
↓
Return Addresses
↓
Loaded Modules
↓
Memory Regions

That is, the tool checks the addresses in the Thread execution path
Then it asks
Where does this Address belong to
For example, we may see something like this

0x7FF... → known DLL
0x7FF... → known DLL
0x1A3... → private executable memory

The first two may be completely normal
But the last one may need more investigation Okay

Why

Because now we are seeing one of the execution path addresses to a private and executable Memory Region

Again
This alone is not proof of an attack
It is just a Signal
Here is an important point about Stack

Stack
is not an absolute truth
That is, you cannot just look at the Stack and say
Then something bad must have happened
Real programs can have very complex Stacks

For example:
JIT
Different Runtimes
Debugger
Instrumentation
Exception Handling
Thread Pool
All of these can cause unusual paths in the Stack
So professional Detection usually does not rely on just one Signal
It may put several things together
For example:
Process
Thread
Memory
Call Stack
Network
Timing
And other information
Now we come to the more interesting part

Stack, Memory and Thread

So far we have talked about these separately
But in the real world, these are not separate
An EDR can see this information together

Process
│
┌─�
▼ ▼
Memory Thread
│ │
│ ▼
│ Call Stack
│ │
└──────┬────────┘
▼
Behavior

In other words, instead of just saying, "This API is dangerous," you can ask a much bigger question.