In this lesson,
we'll explore the theory behind library
and process injection,
focusing on how it can be performed
using the EternalBlue exploit.
After discussing the theory,
we'll move into a more practical demonstration
of the injection technique using Kali Linux.
Understanding both the theory
and practical application of these techniques
is essential for pen testers,
especially when dealing with advanced persistence
and privilege escalation scenarios.
Library and process injection are methods used
to execute code within the address space of another process.
This approach is often employed to evade detection,
escalate privileges, or bypass security controls.
By injecting malicious code into a legitimate process,
an attacker can take advantage of the trust that other parts
of the system have in that process,
making the attack more stealthy and effective.
First, let's discuss DLL injection.
This technique involves loading a dynamic link library
into the memory space of a target process.
Once the DLL is injected, it can execute code
with the same permissions
as the process that it was injected into.
DLL injection is commonly used to manipulate the behavior
of a process or to add malicious functionality.
Next, let's talk about process hollowing.
This is a technique in which an attacker
spawns a new process in a suspended state,
replaces its memory with malicious code,
and then resumes the process.
The newly injected code runs under the context
of the original, often trusted process.
Process hollowing is particularly effective
for evading detection,
because the injected process appears to be legitimate.
Another technique we need to explore
is reflective DLL injection.
This is a stealthy injection method where DLL
is loaded directly from memory
rather than being written to a disc.
Reflective DLL injection is favored by attackers
who want to avoid leaving traces on a file system,
as that DLL never touches the hard drive.
And finally, let's discuss remote thread injection.
This technique involves creating a new thread
in a remote process and pointing it to a memory location
that contains the malicious code.
Remote thread injection allows the attacker
to execute code within the context of an existing process,
potentially bypassing security controls
and escalating privileges.
The EternalBlue is an exploit that takes advantage
of a vulnerability in the SMB version 1 protocol
used by Windows operating systems.
This exploit allows remote code execution
with system level privileges,
making it a powerful tool in a pen tester's arsenal.
By combining EternalBlue with process injection techniques,
we can then gain a foothold on the target system
and move our payload into a more stable or trusted process,
ensuring persistence and avoiding detection.
Now, let's move on into a practical demonstration
of process injection
using EternalBlue exploit on Kali Linux.
For this demonstration, we'll use Metasploit
to exploit a target Windows machine
with the goal of using EternalBlue to deliver
and inject a payload into a process on the target.
Okay, so we're going to start off
in the post-exploitation phase,
meaning I have already exploited the system
with EternalBlue and now I'm using Metasploit's interpreter
to perform process injection.
If you look here,
you can see that I've already exploited the system
with some of the configurations that I have here.
I ran the exploit and it was successful.
So, now, I have a reverse TCP shell on the target.
All right, so now, we're already here.
Now, we need to start the process
of actually process injection.
We will be looking at different processes on the system
and trying to migrate to a more trusted process.
So, let's use the PS, which is the process command
to see what's running and what users
and service profiles are running with them.
Okay, so we see here that we have information like the PID,
which is the process ID, the PPID,
which is the parent process ID, the name of the process,
the architecture type, the sessions running,
the user that's running the session,
and the path to the executable.
Now, let's first get our process ID.
Let's see when we created this reverse TCP shell,
what process did we inject into?
All right, so we're currently 1876.
So, we are the printer service,
which is responsible for managing printing task in Windows.
This might not be the most ideal process
for us to remain in since it's relatively monitored
and might be restarted, which could end our session.
'Cause a lot of security centers are familiar now
that the printer is a prime target or at least used to be.
Now, let's target the SBC host,
which is a critical Windows process
that acts as a container for other services.
It runs many essential system tasks
and because multiple SBC host processes
run under different users and permissions,
it may make a good candidate
for this process injection and migration.
I think that we're probably
going to get a access denied error,
'cause there are granular level permissions
within these hosts.
Just because we have NT authority privilege
doesn't mean we have access to every single process.
So, let's try to migrate to one of these hosts here.
So, let's try 1540.
Let's try another one really quick. So, 2552.
All right, so we see we have access denied.
As I predicted, we were not going to have
sufficient privileges
to migrate to another highly controlled process.
So, let's try to migrate to something else.
Let's try process 2408 WmiPrvSE.
Now, these processes typically have lower level privileges,
making them easier to migrate to.
Also, they are long-running background processes,
which means they are less likely to crash
or be restarted,
giving us persistence on the target machine.
So, let's try and migrate to that.
All right, let's try another one.
Let's try 2080.
Insufficient privileges.
Let's try another one of those.
Let's try to search indexer.
Access denied.
All right, perfect.
We were able to get into 1476 here, this light agent.
So, we've successfully migrated to 1476.
Migrating to this process allows us
to maintain our foothold on the machine,
ensuring that even if the current process is terminated,
we can continue our operations from a more stable process.
So, we started here, process 1876,
and we're now process 1476.
All right, so in summary,
we started by looking at the output
of the PS command to identify available processes.
We found our current process using the get PID
and determined that was running under the printer.
We finally identified a lower level privilege process.
So, this light agent here
that allowed us to migrate properly.
I hope you enjoyed this demonstration
and I will see you in the next one.