Memory Injection Inside Sandbox

[Online_Sword]

Several weeks ago, I asked a question in my profile status:

Could a malware running inside the sandbox attack the memory of a process running out of the sandbox?

The link to that status: Online_Sword

Here are some (not all) replies to that profile status:

@Klipsh

Of course, sandbox evasion is not a myth.

@hjlbx

This is how some CVEs work. So possible, yes. Somewhere in OS and all other softs there lies undiscovered vulnerabilities of all types. COMODO functionality address this sort of thing, but technical infos hard to come by...

@DracusNarcrym

Ah, I see. In that case it would be preferred that the sandbox terminate any executable that attempts to perform operations such as injecting code in running process images - since the whole "clone process" deal is not possible.

In my own reply to that profile status, I said that I would do some tests by myself. However, at that time I only had some malware samples which inject the memory of other processes with the technique called "Process Hollowing". By contrast, I hope to do some tests with malware samples that directly injects into other processes instead of using the technique "Process Hollowing". Following is an introduction of "Process Hollowing" written by @itman (thanks ) in wilderssecurity:

"Classic" process hollowing takes the form of the malware starting a legit process in a suspended state. This is usually a system process with high privileges such as svchost.exe. The malware will then "carve out" a memory area in the legit process and injection malicious code into that area. It then readjusts run info in areas like the PEB etc. and then starts the suspended processes.

Recently I got eight malware samples that will directly inject into Explorer.exe. So I can continue my tests. I test them in WinXP running in a virtual machine. The latest version of Sandboxie Free is used in the tests. I also use Outpost Firewall Pro (OFP) to monitor the activities of the malware samples.

In my tests, I found that, when the malware samples launched directly (not in the sandbox), ofp alerts that those samples trying to manipulate the memory of Explorer.exe. By contrast, when those samples launched inside the default sandbox of Sandboxie (with default settings), there is no such alert, and the samples simply collapse. So I think these eight malware sample, when they are launched inside the sandbox, fail to inject into Explorer.exe, which runs outside of Sandbox.

I also test some malware samples that use the technique of Process Hollowing. When these samples launched inside the sandbox, their target processes, such as svchost.exe, will first be launched inside sandbox, then the malwares can successfully inject into the target processes. However, in my tests, since the target system processes also run in the sandbox (this is because their parent processes are sandboxed), they cannot influence the files not in the sandbox.

Please note that the malware samples in my tests are quite few, so I am afraid that we cannot draw a conclusion that generally holds. I would appreciate it if anyone could introduce more theories on this topic or post more test results.

-------------------------------------------------------------------------------------------------------------------

P.S. The reason why I post this thread in the forum of "General Security Discussions" rather than the forum of "Sandboxie" (SBIE) is because here I do not focus on specific features or settings of Sandboxie. The reason why I choose SBIE rather than the Auto-Sandbox of Comodo to do the tests here is only because I need a HIPS to tell me whether the memory injection is carried out, but malwares running inside the auto-sandbox of Comodo will not trigger HIPS alerts, which is inconvenient for the tests here.

 

[DracusNarcrym]

Your tests so far certainly confirm our suspicions that using code injection, from within the sandbox, in non-sandboxed memory images, is not feasible.

At least the two outlined techniques failed.

Perhaps there are other methods, maybe not as effective/advanced, but "primitive" enough for sandbox software to overlook them.

 

[hjlbx]

Several weeks ago, I asked a question in my profile status:

The link to that status: Online_Sword

Here are some (not all) replies to that profile status:

@Klipsh


@hjlbx


@DracusNarcrym


In my own reply to that profile status, I said that I would do some tests by myself. However, at that time I only had some malware samples which inject the memory of other processes with the technique called "Process Hollowing". By contrast, I hope to do some tests with malware samples that directly injects into other processes instead of using the technique "Process Hollowing". Following is an introduction of "Process Hollowing" written by @itman (thanks ) in wilderssecurity:



Recently I got eight malware samples that will directly inject into Explorer.exe. So I can continue my tests. I test them in WinXP running in a virtual machine. The latest version of Sandboxie Free is used in the tests. I also use Outpost Firewall Pro (OFP) to monitor the activities of the malware samples.

In my tests, I found that, when the malware samples launched directly (not in the sandbox), ofp alerts that those samples trying to manipulate the memory of Explorer.exe. By contrast, when those samples launched inside the default sandbox of Sandboxie (with default settings), there is no such alert, and the samples simply collapse. So I think these eight malware sample, when they are launched inside the sandbox, fail to inject into Explorer.exe, which runs outside of Sandbox.

I also test some malware samples that use the technique of Process Hollowing. When these samples launched inside the sandbox, their target processes, such as svchost.exe, will first be launched inside sandbox, then the malwares can successfully inject into the target processes. However, in my tests, since the target system processes also run in the sandbox (this is because their parent processes are sandboxed), they cannot influence the files not in the sandbox.

Please note that the malware samples in my tests are quite few, so I am afraid that we cannot draw a conclusion that generally holds. I would appreciate it if anyone could introduce more theories on this topic or post more test results.

-------------------------------------------------------------------------------------------------------------------

P.S. The reason why I post this thread in the forum of "General Security Discussions" rather than the forum of "Sandboxie" (SBIE) is because here I do not focus on specific features or settings of Sandboxie. The reason why I choose SBIE rather than the Auto-Sandbox of Comodo to do the tests here is only because I need a HIPS to tell me whether the memory injection is carried out, but malwares running inside the auto-sandbox of Comodo will not trigger HIPS alerts, which is inconvenient for the tests here.

Bromium researches showed that a malware could break out of a double-sandbox via an exploit and gain admin privileges.

In that case the malware could do virtually anything.

So theoretically it is possible.

All that needs to be found is a reliably exploitable vulnerability.

* * * * * *

After testing malware after malware inside COMODO sandbox, I stopped testing... because virtually everything that tries to mess with system or other processes just collapses.

Virtual Kiosk is different matter. Virtual Kiosk is, in some ways, like a VM. So it doesn't have the same restrictions as sandbox. It is designed to behave much more like Shadow Defender than Sandboxie.

Remember, Unrecognized files are handled via auto-sandboxing and not the Virtual Kiosk, so the COMODO sandbox is more restrictive by design than the Virtual Kiosk.

Sandbox and Virtual Kiosk use the same virtual container, but their restrictions, by design, are different.

Does that make sense ?

 

[hjlbx]

With malware now able to detect virtualization more and more - eventually sandboxes will be useless.

The future will be emulation...

 

[hjlbx]

Several weeks ago, I asked a question in my profile status:

The link to that status: Online_Sword

Here are some (not all) replies to that profile status:

@Klipsh


@hjlbx


@DracusNarcrym


In my own reply to that profile status, I said that I would do some tests by myself. However, at that time I only had some malware samples which inject the memory of other processes with the technique called "Process Hollowing". By contrast, I hope to do some tests with malware samples that directly injects into other processes instead of using the technique "Process Hollowing". Following is an introduction of "Process Hollowing" written by @itman (thanks ) in wilderssecurity:


Recently I got eight malware samples that will directly inject into Explorer.exe. So I can continue my tests. I test them in WinXP running in a virtual machine. The latest version of Sandboxie Free is used in the tests. I also use Outpost Firewall Pro (OFP) to monitor the activities of the malware samples.

In my tests, I found that, when the malware samples launched directly (not in the sandbox), ofp alerts that those samples trying to manipulate the memory of Explorer.exe. By contrast, when those samples launched inside the default sandbox of Sandboxie (with default settings), there is no such alert, and the samples simply collapse. So I think these eight malware sample, when they are launched inside the sandbox, fail to inject into Explorer.exe, which runs outside of Sandbox.

I also test some malware samples that use the technique of Process Hollowing. When these samples launched inside the sandbox, their target processes, such as svchost.exe, will first be launched inside sandbox, then the malwares can successfully inject into the target processes. However, in my tests, since the target system processes also run in the sandbox (this is because their parent processes are sandboxed), they cannot influence the files not in the sandbox.

Please note that the malware samples in my tests are quite few, so I am afraid that we cannot draw a conclusion that generally holds. I would appreciate it if anyone could introduce more theories on this topic or post more test results.

-------------------------------------------------------------------------------------------------------------------

P.S. The reason why I post this thread in the forum of "General Security Discussions" rather than the forum of "Sandboxie" (SBIE) is because here I do not focus on specific features or settings of Sandboxie. The reason why I choose SBIE rather than the Auto-Sandbox of Comodo to do the tests here is only because I need a HIPS to tell me whether the memory injection is carried out, but malwares running inside the auto-sandbox of Comodo will not trigger HIPS alerts, which is inconvenient for the tests here.

Maybe Excubits MZScanner will log actions inside COMODO sandbox ?

I don't know... I didn't mess with it yet.

 

[Online_Sword]

Maybe Excubits MZScanner will log actions inside COMODO sandbox

I do not know. I think to log the activities related to memory operation, we need Excubits MemProtect rather than MZWriteScanner.

However, I have not figured out how to install MemProtect...

 

[hjlbx]

The bad ju-ju with vitual sandboxes is that session processes and session data is not protected... unless you take additional measures to protect it.

 

[hjlbx]

I do not know. I think to log the activities related to memory operation, we need Excubits MemProtect rather than MZWriteScanner.

However, I have not figured out how to install MemProtect...

Sorry. I quoted wrong one, but you knew what I meant to say...

 

[LabZero]

@Online_Sword

About general sandbox I can say that, like all security applications, it is interesting to do extensive testing.
Speaking specifically of Sandboxie I would like to make some considerations for example: the safe working environment that is referenced, as it must be understood?
If a malicious file is located in the C:\Sandbox\User\Defaultbox\ folder, for example, it can cause damage to the operating system if It starts ?
It means that if I start an application and before I select "start virtual area", then the system is protected, or does it mean that if I start an application directly from within the Defaultbox of Sandboxie, security is still guaranteed?
So, the downloaded files within the Defaultbox (downloads requested by the user during navigation) may jeopardize the security, as well as malware penetrated abusively in Defaultbox?

I did a simple experiment: launching a link of the following type:

%windir%\system32\shutdown.exe/s/t 0/f

through its icon from within C:\Sandbox\User\Defaultbox\, the system shuts down immediately.

This simple shortcut that refers to C:\Windows\System32 sandboxed but ... the effect of this command also involves the real/physical system and consider then the complexity of what.
Most of the time that was reported a bypass of sandboxie (though rarely) the charge was another security software installed on the same system, it is necessary for the proper functioning of the programs within the sandbox, it can't block the driver operations (kernel mode) system.
So any security software that goes to act within the sandbox may lead to a result contrary to the purpose of same sandbox : system infection. Some time ago for example was mentioned a problem to get the handle of an object through OpenProcess resulting in bypass and system infection due to another security software installed.

The "full-isolation" it is however difficult that always works, some keyloggers for example using dll injection SetWindowsHookEx which could be explicitly blocked, however, CreateRemoteThread works as well as more complex variants.
Another limitation is related to the fact that the sandbox needs monitoring systems that alter the behavior of the machine. Mapping memory access, editing records, files and more makes the sandbox still "different" from the real system, and stealth technologies and anti sandbox about these differences the criminals attack.
Finally, it should be mentioned the fact that the same sandbox can be hacked via vulnerability more or less known. This may be a limitation especially considering APT and targeted attacks.
For example, if there's running malicious code, malware creators can create code that automatically lies dormant for a period. If the code is still running after that, probably not in a sandbox and it can infect memory processes.

 

[cruelsister]

Sword- If you will allow me to intrude, I’d just like to point out a few things- mainly about the terms “evasion” and “bypass”. Too often these terms are used interchangeably in the lay press and can lead to confusion.

1). Bypass- this can be done in a number of ways:

a). as Klipsch pointed out above, a simple script run in a sandbox that calls up shutdown .exe will indeed cause the system to stop. Things like this are allowed as there will be no permanent harm to the system itself (scripts making the computer talk or opening up the CD drive will also be allowed); but my Chaos Scriptor should be stopped by the sandbox as it would cause permanent harm to the system itself.

b). a bypass can also occur as a result of a flaw in the coding of the sandbox itself. An example of this would be the blindspot that SBIE had for API calls; but once pointed out this was fixed.

c). once again as was noted by K above, things like keyloggers can access and transmit information from within a sandbox; thus it is essential that a sandbox has some sort of Outbound block and/or alert to stop this.

2). Evasion- This is where it is at currently in Blackhat land. Malware can be constructed that will query the environment in a number of ways to determine if it is being run in a sandbox; if it determines that it is, it will shut down. This is done primarily to evade Dynamic Analysis modules that often accompany corporate virtualization defenses. Since old-school stuff like querying system time, timing mouse clicks, Sleep calls, etc are known and will be detected and flagged as malicious by the DA modules the Blackhats have to come up with new ideas (like determining CPU cores a la the recent Dyre banking trojans).

The obvious end purpose for the evasion is to construct a legitimate file with malware added on that will be indistinguishable (by a DA module) from the legit file minus the malware. When run virtually both will act the same, so some IT guy will allow the malware to escape by taking the file out of the virtualized environment himself (note that I’m NOT saying “herself”) thinking the malicious file is actually legit.

Finally please don't worry about things like injection, etc. Although malware can use legitimate processes, it should be precluded from making any changes to these processes. And as to your comment about malware attacking memory: I was at a conference last year where a paper was presented about a POC exploit called “Rowhammer.js”. Currently it is still conceptual, but you may want Google it for a few giggles if you are interested.

(God, I hope that the above was clear and not overly simplistic. My mind is still a bit wine-addled from last night)

 

[DracusNarcrym]

Sword- If you will allow me to intrude, I’d just like to point out a few things- mainly about the terms “evasion” and “bypass”. Too often these terms are used interchangeably in the lay press and can lead to confusion.

1). Bypass- this can be done in a number of ways:

a). as Klipsch pointed out above, a simple script run in a sandbox that calls up shutdown .exe will indeed cause the system to stop. Things like this are allowed as there will be no permanent harm to the system itself (scripts making the computer talk or opening up the CD drive will also be allowed); but my Chaos Scriptor should be stopped by the sandbox as it would cause permanent harm to the system itself.

b). a bypass can also occur as a result of a flaw in the coding of the sandbox itself. An example of this would be the blindspot that SBIE had for API calls; but once pointed out this was fixed.

c). once again as was noted by K above, things like keyloggers can access and transmit information from within a sandbox; thus it is essential that a sandbox has some sort of Outbound block and/or alert to stop this.

2). Evasion- This is where it is at currently in Blackhat land. Malware can be constructed that will query the environment in a number of ways to determine if it is being run in a sandbox; if it determines that it is, it will shut down. This is done primarily to evade Dynamic Analysis modules that often accompany corporate virtualization defenses. Since old-school stuff like querying system time, timing mouse clicks, Sleep calls, etc are known and will be detected and flagged as malicious by the DA modules the Blackhats have to come up with new ideas (like determining CPU cores a la the recent Dyre banking trojans).

The obvious end purpose for the evasion is to construct a legitimate file with malware added on that will be indistinguishable (by a DA module) from the legit file minus the malware. When run virtually both will act the same, so some IT guy will allow the malware to escape by taking the file out of the virtualized environment himself (note that I’m NOT saying “herself”) thinking the malicious file is actually legit.

Finally please don't worry about things like injection, etc. Although malware can use legitimate processes, it should be precluded from making any changes to these processes. And as to your comment about malware attacking memory: I was at a conference last year where a paper was presented about a POC exploit called “Rowhammer.js”. Currently it is still conceptual, but you may want Google it for a few giggles if you are interested.

(God, I hope that the above was clear and not overly simplistic. My mind is still a bit wine-addled from last night)

This is some invaluable insight into the matter, thanks @cruelsister!
It turns out memory injection penetrating the sandbox is largely out of the question and we should be more cautious about the native security flaws of the sandbox in question, in conjunction with mishandled user input that would allow the malware to run un-sandboxed.