di_blog_post

Deep Instinct prevents more advanced threats than any EPP or EDR in the world.

Deep Instinct Blog: Breaking News and Updates

Explore Deep Instinct DSX

Prevent Zero-Day Attacks

Real-Time Malicious Verdicts

Real-Time Explainability

Lower TCO

Ensure Privacy & Compliance

Deep Instinct DSX

Cloud

Applications

Endpoints

Use Cases

Asset Library

Blog

Videos

Events & Webinars

Resources

About Deep Instinct

Our Customers

Newsroom

Careers

Contact Us

Company

Request Demo

Customer Portal

Integrations and Compliance

Training

Quick Links

Discover how our revolutionary deep learning-powered solution prevents and explains unknown, never-before-seen threats.

explore deep instinct dsx

why dsx

Prevent zero-day attacks

Detect and prevent threats in <20ms, faster than the blink of an eye.

real-time malicious verdicts

Gain actionable, AI-driven intelligence on zero-day threats in seconds.

Real-Time Insights & Explainability

Reduce cybersecurity costs with efficient, high-performance threat prevention.

Enhance data protection while meeting stringent privacy and regulatory requirements.

DEPLOYMENT

Secure your multi-cloud or hybrid infrastructure against zero-day threats.

CLOUD

Safeguard critical data on Network-Attached Storage systems from advanced cyber threats.

Defend SaaS and custom applications from zero-day vulnerabilities and threats.

APPLICATIONS

Protect devices and endpoints with AI-driven threat prevention.

ENDPOINTS

EXPLORE 

Threat Research

Voice Of SecOps

COMPARE

Deep Instinct complements Microsoft Defender with advanced threat prevention to stop threats before they enter your environment.

+ Microsoft Defender

Deep Instinct and Tanium deliver prevention-first endpoint security to reduce risk and boost productivity.

+ Tanium

EDR is not enough — enhance existing cybersecurity tools with advanced, real-time threat prevention using deep learning to produce defense in depth.

EXTEND/ENHANCE LEGACY AV

Replace outdated, legacy AV solutions with prevention-first, deep-learning-based protection purpose-built for cybersecurity.

REPLACE LEGACY AV

Faster and more accurate – Deep Instinct safeguards your data and protects your NAS storage better than Trellix.

REPLACE TRELLIX

Leadership Team

Board of Directors

Partners

Login

content_block

Perspective & Findings

<h4>Don’t Let Application File Uploads Become Malware Downloads</h4>

file-upload-security-blog.jpg

Recent Blog Posts

Listing preview

Perspective & Findings

image_media_card

Recent Blog Posts

listing_preview

BPFDoor Malware Evolves – Stealthy Sniffing Backdoor Ups Its Game

Who is the only NEW vendor in the 2022 Gartner® Magic Quadrant™ for Endpoint Protection Platforms?

ChatGPT and Malware: Making Your Malicious Wishes Come True

Top-3 Drawbacks of Content Disarm + Reconstruction (CDR) for Malware Prevention

LSASS Memory Dumps are Stealthier than Ever Before

LSASS memory dumps

Trending at Deep Instinct

carousel_cards

Malware authors are always looking for new ways to achieve code injection, as it enables them to run their code in remote processes. Code Injection al

hook-inj.jpg

Malware authors are always looking for new ways to achieve code injection, as it enables them to run their code in remote processes. Code Injection allows hackers to better hide their presence, gain persistence and leverage other processes’ data and privileges.
Finding and implementing new, stable methods for <a href="https://info.deepinstinct.com/whitepaper-remote-code-injection-in-macos" target="_blank" rel="noopener noreferrer">code injection</a> is becoming more and more challenging as traditional techniques are now widely detected by various security solutions or limited by native OS protections.
<a href="https://youtu.be/8-TcLgkPeLc" target="_blank" rel="noopener noreferrer">Inject-Me</a> is a new method to inject code into a remote process in x64. Inject-Me is in fact “injection-less”, meaning that the remote (target) process is manipulated to read data from the injecting process, copy and execute it. The manipulation is mainly based on abusing ReadProcessMemory and calling conventions in X64. In addition to presenting Inject-Me, we mention a generalized approach to copying data in remote processes to recreate shellcode from the injecting process.
<h3>Technical Review</h3>
In this technical review, the method Inject-Me will be described in detailed flow. Since a second method of copying data in remote processes is used to achieve the code injection, it will be referred to while describing Inject-Me.
In addition, because this method is very complicated, from time to time an execution flow will be presented to avoid confusion.
Prior to describing the method, an important restriction should be discussed while looking for this method. The method must be a new method and mustn’t use any of the known injection methods. This means functions like WriteProcessMemory or NtMapViewOfSection can’t be used.
So, what was the idea behind this code injection?
The idea behind this method is that in x86_64 WinAPI, the first four arguments are passed in the registers RCX, RDX, R8, R9 and parameters after that are passed on the stack, in contrast to x86 where all parameters are passed on the stack.
If we will find a function receiving four parameters that read data from somewhere to a destination in memory, we can change the context of a thread in a remote process using SetThreadContext and pass the parameters we want so it will read data from a location we control.

<img data-image="t55vb9pa6xca" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltdefa7d052826773e/6183569c19df7c77cdb1fc6a/ReadProcessMemory-450x175.jpg" data-sys-asset-uid="bltdefa7d052826773e" alt="ReadProcessMemory-450x175.jpg">
The first thought was ReadProcessMemory, we know that this function can read data from the injecting process. Let’s look at the definition of ReadProcessMemory.

<img data-image="mjgl68exin10" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt13b1f7c4c0274402/618356aca1ce11650a8d3113/Parameters-450x254.jpg" data-sys-asset-uid="blt13b1f7c4c0274402" alt="Parameters-450x254.jpg">
Bummer! This function gets five parameters and not four. But if we read carefully the definition of the last parameter lpNumberOfBytesRead we can see that this parameter can be NULL. So, all we need is a stack that contains only NULL in it. This is not hard to achieve since VirtualAllocEx allocates memory in the remote process and zero all the allocated memory! Nice!
Notice that the stack should be big enough for extra function calls, in our POC we allocated a 2kb stack. When the term beginning of stack is presented later in this blog, the real address is the allocated stack address + 1kb. By looking further in the function definition, we can see that ReadProcessMemory gets a handle to a process in which to read from.
Now we need to get a valid handle of the injecting process that will exist in the injected process. Here comes to the rescue the function DuplicateHandle, this function duplicates a handle from one process to another so we can duplicate a handle of our process to the remote process.
The other three parameters are easy to set:
lpBaseAddress is the location of the data we want to copy (our shellcode).
lpBuffer is the address of the allocated buffer in the remote process using VirtualAllocEx (or if you have RWX code cave).
nSize is the size of the data (our shellcode).
The context of a thread executing this function should look like this:
RCX = duplicated handle value in the remote process
RDX = lpBaseAddress
R8 = lpBuffer
R9 = nSize
RSP = Allocated zeroed stack
Execution flow:
<ul>
<li>Find the process to inject to</li>
<li>Duplicate a handle of our process to the remote process using DuplicateHandle</li>
<li>Allocate Memory RWX for our shellcode using VirtualAllocEx</li>
<li>Allocate Memory RW for our dummy stack using VirtualAllocEx</li>
<li>Put our shellcode in our memory (Create a variable)</li>
<li>Save in variable the shellcode size</li>
</ul>
Let’s discuss another problem we need to solve; if our stack is zeroed when ReadProcessMemory returns it is going to read the return address from the stack, the address will be 0 and we will get an Access Violation exception. To solve this, we need to write at the beginning of the stack the address of a function that will exit the thread and won’t return. Windows has such a function at ntdll.dll RtlExitUserThread.
As stated earlier, we are not allowed to write to the remote process using one of the known injection methods.
Here comes to the rescue the function NtQueueApcThread, this function makes a thread to execute code from a certain address and passes to this code three parameters. This could help us since by luck CopyMemory, or more specifically, RtlCopyMemory gets three parameters. By creating a remote thread and invoking RtlCopyMemory we can copy data inside the remote process.

<img data-image="2jjn2kf2edso" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt4911913d132a7a49/618356b894e50d5a63800fff/injecting-process-450x237.jpg" data-sys-asset-uid="blt4911913d132a7a49" alt="injecting-process-450x237.jpg">
So now we can copy data, but where can we find a place that contains the address of RtlExitUserThread?
Kernel32.dll uses RtlExitUserThread from ntdll.dll and therefore the address it’s written to is IAT. Because kernel32.dll and ntdll.dll share the same base address in all processes we can look for the address in our memory and it will be at the same address in the remote process memory (We can also scan the remote process, but it’s a more annoying and intrusive process).
After we found the address in our kernel32 IAT we create an alert-able thread in the remote process, call NtQueueApcThread which will invoke RtlCopyMemory in the remote process thread. For the source parameter, we use the address of IAT in kernel32 of RtlExitUserThread and the destination parameter will be the beginning of our allocated stack (the return address). And voila! The address of RtlExitUserThread is at the beginning of the allocated stack.
A short comment:
This method of copying data inside a remote process could be used as another injection method. By looking in our ntdll/kernel32 we can find each byte of our shellcode and make the other process copy byte after byte. (This means the amount of times we will call NtQueueApcThread is equal to the number of bytes in the shellcode).
Execution flow:
<ul>
<li>Find RtlExitThread in kernel32 IAT in our process.</li>
<li>Create an alert-able thread using CreateRemoteThread suspended (call Sleep 1 millisecond).</li>
<li>Find RtlCopyMemory in our ntdll.dll</li>
<li>Call NtQueueApcThread calling the function RtlCopyMemory with src= RtlExitThread IAT location and dst=beginning of our dummy stack.</li>
<li>ResumeThread</li>
<li>WaitForSingleObject on thread to be sure it has done its job before we continue.</li>
</ul>
The next problem we need to solve is that we don’t want to hijack a thread by using SetThreadContext, so we need to do it on a new thread. If we change the RIP of a new thread that hasn’t initialized yet (the suspended thread is not yet initialized) we will receive exception 0xC000000D STATUS_INVALID_PARAMETER and the process will crash. If we want to wait for the thread to initialize, we need a thread that runs for a long time or for an infinite time, so we won’t miss our window of opportunity to manipulate it.
If we look at what happens in the remote process after CreateRemoteThread is called, we can see the new thread starts at RtlUserThreadStart. Let’s look on RtlUserThreadStart

<img data-image="hjvilankr7kw" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt3d2fa68b4a326c0e/618356c7666f1777c9bcec39/flow-chart1-450x315.jpg" data-sys-asset-uid="blt3d2fa68b4a326c0e" alt="flow-chart1-450x315.jpg">
We can see that it calls a function, this function is LdrpDispatchUserCallTarget so we also look on that function.

<img data-image="hp6ud8t5oo7k" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt6b443255bc337b6e/618356d919df7c77cdb1fc6e/flow-chart2-450x558.jpg" data-sys-asset-uid="blt6b443255bc337b6e" alt="flow-chart2-450x558.jpg">
This function runs some tests and then it does a jmp to RAX which is going to be the entry point we passed to CreateRemoteThread.
As stated earlier, we want a thread that will run for an infinite time. We can do this by jumping to a location in memory that has the opcode jmp RBX. We will use jmp RBX since the register is not used by the RtlUserThreadStart function in different versions of windows (tested on Windows 10, 8.1 and 7).&nbsp; We will call CreateRemoteThread with an entry point that points to our jmp RBX opcode, then we will set the value of RBX in the remote thread to point our jmp RBX opcode and resume the thread. First, a jmp from LdrpDispatchUserCallTarget will occur and then it will non-stop jmp to the same address over and over since RBX won’t change.
We can do that the same way we copied RtlExitThread using NtQueueApcThread.
We will look for jmp RBX in ntdll (it is a 2 bytes opcode, so if we can’t find it we can copy byte after byte). And since ntdll location is the same for all process we just need to scan our memory for this opcode in our version of ntdll and then copy it in the remote process.
Execution flow:
<ul>
<li>Allocate memory RWX for our jmp RBX opcode using</li>
<li>Find jmp RBX opcode 0xffe3 in our version of ntdll.</li>
<li>Copy jmp RBX opcode from ntdll version of the remote process to the allocated memory using NtQueueApcThread</li>
</ul>
Now we got to the last stage, the stage where we execute ReadProcessMemory.
<ul>
<li>To do so, we get the address of ReadProcessMemory.</li>
<li>We use CreateRemoteThread and use our copied jmp RBX opcode as the entry point.</li>
<li>We use SetThreadContext to set RBX to point our jmp RBX opcode.</li>
<li>Then we resume the thread.</li>
<li>This will create a remote thread with an infinite loop. We suspend the thread and check that RIP (using GetThreadContext) is really pointing to our jmp RBX opcode (so we know the thread already initialized).</li>
<li>Then we use SetThreadContext:</li>
</ul>
RCX = duplicated handle value in the remote process
RDX = lpBaseAddress
R8 = lpBuffer
R9 = nSize
RSP = Allocated zeroed stack
RBX = Address of ReadProcessMemory
And we resume the thread. Because the opcode that is executed is jmp RBX we are going to jump to ReadProcessMemory with the right parameters. It will read the shellcode from our process and then return to RtlExitUserThread and the thread will terminate. All that is left to do is execute the shellcode using one of the many ways to execute code in Windows, for example, CreateRemoteThread.
<h3>Full Execution Flow</h3>
<ul>
<li>Find the process to inject to</li>
<li>Duplicate a handle of our process into the remote process using DuplicateHandle</li>
<li>Allocate Memory RWX for our shellcode using VirtualAllocEx</li>
<li>Allocate Memory RW for our dummy stack using VirtualAllocEx</li>
<li>Put our shellcode in our memory (Create a variable)</li>
<li>Save the shellcode size in a variable</li>
<li>Find RtlExitThread in kernel32 IAT in our process</li>
<li>Create an alert-able thread using CreateRemoteThread suspended (call Sleep 1 millisecond)</li>
<li>Find RtlCopyMemory in our ntdll.dll</li>
<li>Call NtQueueApcThread calling the function RtlCopyMemory with src= RtlExitThread IAT location and dst=beginning of our dummy stack</li>
<li>ResumeThread</li>
<li>WaitForSingleObject on thread to be sure it has done its job before we continue</li>
<li>Allocate memory RWX for our jmp RBX opcode using VirtualAllocEx</li>
<li>Find jmp RBX opcode 0xffe3 in our version of ntdll</li>
<li>Copy using NtQueueApcThread trick jmp RBX opcode from ntdll version of the remote process to the allocated memory</li>
<li>Get ReadProcessMemory address</li>
<li>CreateRemoteThread pointing to our jmp RBX opcode</li>
<li>Use SetThreadContext to set RBX to point our jmp RBX opcode</li>
<li>Resume the thread and let it execute (so it will get to the infinite loop)</li>
<li>Suspend the thread</li>
<li>Use GetThreadContext to check if RIP equals to our jmp RBX opcode address</li>
<li>Use SetThreadContext to set the context 
RCX = duplicated handle value in the remote process</li>
</ul>
RDX = lpBaseAddress
R8 = lpBuffer
R9 = nSize
RSP = Allocated zeroed stack
RBX = Address of ReadProcessMemory
<ul>
<li>Resume the thread and let ReadProcessMemory execute</li>
<li>Execute the shellcode</li>
</ul>

Inject Me x64 Injection-less Code Injection

Announcing DSX for Cloud - Amazon S3, natively integrated zero-day data security for AWS S3.