I found a file which has the ability to delete itself, for real, in the folder you ran it from; ie:

I have a folder called c:\hold2; which I have sandboxed. If I run something in this folder, unless I am mistaken, it cannot affect the files in that folder... well, this one deletes itself from the real drive. And sandboxie has no recollection of it happening.

So, either I misunderstood what a sandboxed folder will do, or this little thing escapes sandboxie and makes real changes; IE: my sample gets deleted for real.

Oh, btw, I have a dll injected which is supposed to prevent deletion even inside my sandbox; this evades that too.

It's probably a bad file, So unless you want to play, don't run it.

hxxp://bughunter.it-mate.co.uk/ie.rar

hmm ... I am not getting that same deletion. Using a default setting sandbox, and using 'Run Sandboxed' on the file - and also setting the folder as a Forced Folder and just double clicking the file. All I get is a few empty folders in the sandbox that go to System32. My setup doesn't have a dll injected though...

Under the system32 folder you should see an update.reg file; which has randomized contents each run; Has to be removed manually... currently .. shrug. (update: This file is only still there if I have my dll injection enabled. Otherwise, it's deleted too.)

I have been able to duplicate the results I previously mentioned, whether i'm injecting the dll or not. I do not have drop admin rights or anything; and I am using sandboxie v3.43.08....

Suggestions? Kind of makes me a little nervous when I see the little bugger change something which was supposed to be stored in a forced folder. IE: The file really gets whacked as soon as sandboxie shows an unknown executable running for a moment. Yes, it only targets itself; but... if it can do that, it can potentially get more critical files...

I'd feel better if someone else could duplicate my findings.

Update #2: I created a fresh sandbox, default settings. ran my ie.exe sample from \hold2 "run sandboxed". I did enable drop rights on this sandbox. And yet again!, the ie.exe is deleted from my \hold2 folder; I watched it take place.. lol.

sandboxie reports an unknown executable image is running for a moment, the ie.exe file gets deleted, and then the unknown program terminates; leaving nothing behind if I don't enable my dll injection. If I do, I get to see the .reg file it creates each time. Obviously it deletes it from the sandbox as well, but the antidelete dll I have stops it.

What is concerning me is that afaik, the IE.EXE file should *not* be leaving my \hold2 folder. Especially when it's being run under sandboxie.

I tested again and this is what I see - first I make the ie folder a forced folder and double click the ie.exe. This creates the sandboxed folders. That sandbox not set to auto delete. Then I open up the original ie folder and on the ie.exe I right click send to desktop as a shortcut - and close the folder. Then in unsandboxed Windows Explorer I navagate through the sandbox and open the sandboxed System32 folder, which is empty at this time. With that folder open (so I can see what is happening), I double click the shortcut on the desktop. I see the update.reg appear in the sandboxed System32 folder and in a few moments it disappears, again leaving that folder empty.

So for me it is the update.reg that deletes, not the ie.exe.

Very weird... I can prevent the .reg file from deleting. (it's just a text file, with custom desktop icons that will take you to a nasty website)... but the damn ie.exe is leaving my forced folder...

Yes, wierd - we will need more testers.

Interesting. Using the latest Buster Sandbox Analyzer 1.06 beta, I see the following reported...


and the following reported in BSA's API log:


The latest BSA blocks detection of Sandboxie components. Without BSA protection, the sample may be detecting Sandboxie and deleting its traces. I will try it later without BSA in the mix.

Without BSA in place, the sandboxed ie.exe process deletes update.reg and then terminates. The ie.exe sample in its forced folder is not deleted. With BSA in place, update.reg is not deleted.

I don't have bsa presently in place. Just a modified version of tzuk and Busters dll files.

when I use them, I can keep the registry file. if I don't, I just don't get to keep the registry file.. Perhaps somethings amiss then with my sandboxie install..

thanks for looking into it.

Resource access monitor contents when I run the ie.exe sample..

if it matters, this is under windows xp pro sp3.
(Drive) \Device\CdRom0
(Drive) \Device\CdRom1
(Drive) \Device\Floppy0
(Drive) \Device\HarddiskVolume1
(Drive) \Device\LanmanRedirector\;Z:00000000000158e7\Dwenlar\DustinWork
(Unk) 00000002 \Device\CdRom0
(Unk) 00000002 \Device\CdRom1
(Unk) 00000002 \Device\Ide\IdeDeviceP1T0L0-f
(Unk) 00000002 \Device\Ide\IdeDeviceP1T1L0-17
(Unk) 00000022 \Device\SandboxieDriverApi
(Unk) 00000035 \Dfs
(Unk) 00000039 \Device\KsecDD
(Unk) 000000F1 \Device\RasAcd
Clsid -------------------------------
Ipc -------------------------------
Ipc \BaseNamedObjects\{A3BD3259-3E4F-428a-84C8-F0463A9D3EB5}
Ipc \BaseNamedObjects\{A64C7F33-DA35-459b-96CA-63B51FB0CDB9}
Ipc \BaseNamedObjects\ComPlusCOMRegTable
Ipc \BaseNamedObjects\crypt32LogoffEvent
Ipc \BaseNamedObjects\RotHintTable
Ipc \BaseNamedObjects\SBIE_DummyEvent_1568
Ipc \BaseNamedObjects\SBIE_DummyEvent_1996
Ipc \BaseNamedObjects\SBIE_DummyEvent_2808
Ipc \BaseNamedObjects\SBIE_DummyEvent_2920
Ipc \BaseNamedObjects\SBIE_DummyEvent_3016
Ipc \BaseNamedObjects\SBIE_DummyEvent_716
Ipc \BaseNamedObjects\SBIE_ServiceInitComplete_DcomLaunch
Ipc \BaseNamedObjects\SBIE_ServiceInitComplete_RpcSs
Ipc \BaseNamedObjects\ScmCreatedEvent
Ipc \BaseNamedObjects\shell.{210A4BA0-3AEA-1069-A2D9-08002B30309D}
Ipc \BaseNamedObjects\shell.{7CB834F0-527B-11D2-9D1F-0000F805CA57}
Ipc \BaseNamedObjects\shell.{A48F1A32-A340-11D1-BC6B-00A0C90312E1}
Ipc \BaseNamedObjects\userenv: User Profile setup event
Ipc \RPC Control\actkernel
Ipc \RPC Control\epmapper
Ipc O \BaseNamedObjects\Sandboxie_DeviceIdList
Ipc O \BaseNamedObjects\Sandboxie_DeviceSetupClasses
Ipc O \BaseNamedObjects\ShimCacheMutex
Ipc O \BaseNamedObjects\SHIMLIB_LOG_MUTEX
Ipc O \BaseNamedObjects\ShimSharedMemory
Ipc O \KnownDlls\advapi32.dll
Ipc O \KnownDlls\appHelp.dll
Ipc O \KnownDlls\COMCTL32.dll
Ipc O \KnownDlls\comdlg32.dll
Ipc O \KnownDlls\CRYPT32.dll
Ipc O \KnownDlls\CRYPTUI.dll
Ipc O \KnownDlls\gdi32.dll
Ipc O \KnownDlls\imagehlp.dll
Ipc O \KnownDlls\kernel32.dll
Ipc O \KnownDlls\MSASN1.dll
Ipc O \KnownDlls\msvcrt.dll
Ipc O \KnownDlls\NETAPI32.dll
Ipc O \KnownDlls\ole32.dll
Ipc O \KnownDlls\oleaut32.dll
Ipc O \KnownDlls\rpcrt4.dll
Ipc O \KnownDlls\Secur32.dll
Ipc O \KnownDlls\shell32.dll
Ipc O \KnownDlls\SHLWAPI.dll
Ipc O \KnownDlls\user32.dll
Ipc O \KnownDlls\USERENV.dll
Ipc O \KnownDlls\version.dll
Ipc O \KnownDlls\wininet.dll
Ipc O \KnownDlls\WINMM.dll
Ipc O \KnownDlls\WINTRUST.dll
Ipc O \KnownDlls\wldap32.dll
Ipc O \KnownDlls\WS2_32.dll
Ipc O \KnownDlls\WS2HELP.dll
Ipc O \LsaAuthenticationPort
Ipc O \NLS\NlsSectionCType
Ipc O \NLS\NlsSectionLocale
Ipc O \NLS\NlsSectionSortkey
Ipc O \NLS\NlsSectionSortTbls
Ipc O \NLS\NlsSectionUnicode
Ipc O \RPC Control\DNSResolver
Ipc O \RPC Control\SbieSvcPort
Ipc O \Security\LSA_AUTHENTICATION_INITIALIZED
Ipc O \Windows\ApiPort
Pipe -------------------------------
Pipe O \Device\NamedPipe\ShimViewer
Pipe X \Device\NamedPipe\lsarpc
Pipe X \Device\NamedPipe\wkssvc
WinCls -------------------------------
WinCls X Progman
WinCls X RegEdit_RegEdit
WinCls X SHELLDLL_DefView
WinCls X SysListView32

Nice update. I fired up sysinternals process monitor and re-ran my sample. I wasn't imagining things. It is deleting the ie.exe file from the real drive, but; hehe, it's not doing it alone. The "unknown executable" is svchost.exe via LSA, and it's deleted my c:\hold2\ie.exe file.

So I'm probably missing a critical MS patch or something, but sure as hell; this is escaping sandboxie; and it is having a fun time.

I've posted the dump:

1249 10:06:25.0097360 PM svchost.exe 3480 CreateFile C:\hold2\ie.exe SUCCESS Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
1250 10:06:25.0099899 PM svchost.exe 3480 QueryAttributeTagFile C:\hold2\ie.exe SUCCESS Attributes: A, ReparseTag: 0x0
1251 10:06:25.0102294 PM svchost.exe 3480 SetDispositionInformationFile C:\hold2\ie.exe SUCCESS Delete: True
1252 10:06:25.0105591 PM svchost.exe 3480 CloseFile C:\hold2\ie.exe SUCCESS

source file which spawns svchost.exe dump:

409 10:06:18.0833520 PM ie.exe 3500 RegOpenKey HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ie.exe NAME NOT FOUND Desired Access: Read
410 10:06:18.0841240 PM ie.exe 3500 CreateFile C:\hold2 SUCCESS Desired Access: Execute/Traverse, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
411 10:06:18.0843071 PM ie.exe 3500 FileSystemControl C:\hold2 SUCCESS Control: FSCTL_IS_VOLUME_MOUNTED
412 10:06:18.0845440 PM ie.exe 3500 QueryOpen C:\hold2\ie.exe.Local NAME NOT FOUND
477 10:06:18.1199524 PM ie.exe 3500 QueryOpen C:\Sandbox\dummy1\drive\C\hold2 PATH NOT FOUND
478 10:06:18.1201026 PM ie.exe 3500 QueryOpen C:\Sandbox\dummy1\drive\C PATH NOT FOUND
479 10:06:18.1207340 PM ie.exe 3500 QueryOpen C:\Sandbox\dummy1\drive NAME NOT FOUND
480 10:06:18.1210010 PM ie.exe 3500 QueryOpen C:\Sandbox\dummy1\drive\C\hold2\ie.exe PATH NOT FOUND
481 10:06:18.1214624 PM ie.exe 3500 QueryOpen C:\hold2\ie.exe SUCCESS CreationTime: 12/30/2009 10:03:17 PM, LastAccessTime: 12/30/2009 10:06:18 PM, LastWriteTime: 12/24/2009 5:38:46 PM, ChangeTime: 12/30/2009 10:05:58 PM, AllocationSize: 57,344, EndOfFile: 53,384, FileAttributes: A
482 10:06:18.1218286 PM ie.exe 3500 CreateFile C:\hold2\ie.exe SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
483 10:06:18.1220904 PM ie.exe 3500 QueryNameInformationFile C:\hold2\ie.exe SUCCESS Name: \hold2\ie.exe
484 10:06:18.1223705 PM ie.exe 3500 CloseFile C:\hold2\ie.exe SUCCESS
7671 10:06:23.4279931 PM ie.exe 3500 Process Create C:\WINDOWS\SYSTEM32\svchost.exe SUCCESS PID: 3480, Command line: C:\hold2\ie.exe
7672 10:06:23.4298282 PM ie.exe 3500 CloseFile C:\WINDOWS\SYSTEM32\svchost.exe SUCCESS
7673 10:06:23.4475375 PM ie.exe 3500 RegCloseKey HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked SUCCESS
7674 10:06:23.4476035 PM ie.exe 3500 RegCloseKey HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked SUCCESS
7675 10:06:23.4476406 PM ie.exe 3500 RegCloseKey HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Cached SUCCESS
7676 10:06:23.4476871 PM ie.exe 3500 RegCloseKey HKU\SANDBOX_DARWIN_DUMMY1\user\current\software\Microsoft\Windows\CurrentVersion\Shell Extensions\Cached SUCCESS
7677 10:06:23.4497971 PM ie.exe 3500 RegCloseKey HKU\SANDBOX_DARWIN_DUMMY1\user\current\software\Microsoft\Windows\CurrentVersion\Explorer SUCCESS
7678 10:06:23.4498363 PM ie.exe 3500 RegCloseKey HKU\SANDBOX_DARWIN_DUMMY1\user\current\software\Microsoft\Windows\ShellNoRoam SUCCESS
7679 10:06:23.4498713 PM ie.exe 3500 RegCloseKey HKU\SANDBOX_DARWIN_DUMMY1\user\current\software\Microsoft\Windows\ShellNoRoam\MUICache SUCCESS
7680 10:06:23.4499277 PM ie.exe 3500 RegCloseKey HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts SUCCESS
7681 10:06:23.4503131 PM ie.exe 3500 RegOpenKey HKU\Sandbox_DarWin_dummy1\Machine\Software\Microsoft\Windows NT\CurrentVersion SUCCESS Desired Access: Read
7682 10:06:23.4504201 PM ie.exe 3500 RegQueryKey HKU\SANDBOX_DARWIN_DUMMY1\machine\software\microsoft\windows nt\currentversion BUFFER OVERFLOW Query: Basic, Length: 24
7683 10:06:23.4504656 PM ie.exe 3500 RegCloseKey HKU\SANDBOX_DARWIN_DUMMY1\machine\software\microsoft\windows nt\currentversion SUCCESS
7684 10:06:23.4504828 PM ie.exe 3500 RegOpenKey HKU\Sandbox_DarWin_dummy1\Machine\Software\Microsoft\Windows NT\CurrentVersion\GRE_Initialize NAME NOT FOUND Desired Access: Read
7685 10:06:23.4505366 PM ie.exe 3500 RegOpenKey HKLM\Software\Microsoft\Windows NT\CurrentVersion\GRE_Initialize SUCCESS Desired Access: Read
7686 10:06:23.4506219 PM ie.exe 3500 RegQueryKey HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize SUCCESS Query: Name
7687 10:06:23.4507140 PM ie.exe 3500 RegOpenKey HKU\Sandbox_DarWin_dummy1\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize NAME NOT FOUND Desired Access: Read
7688 10:06:23.4507711 PM ie.exe 3500 RegQueryValue HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize\DisableMetaFiles NAME NOT FOUND Length: 20
7689 10:06:23.4508161 PM ie.exe 3500 RegCloseKey HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize SUCCESS
7690 10:06:23.4533728 PM ie.exe 3500 Thread Exit SUCCESS Thread ID: 3496, User Time: 0.0781250, Kernel Time: 1.9687500
7691 10:06:23.4547385 PM ie.exe 3500 Process Exit SUCCESS Exit Status: 0, User Time: 0.0937500 seconds, Kernel Time: 1.5156250 seconds, Private Bytes: 1,765,376, Peak Private Bytes: 3,014,656, Working Set: 4,050,944, Peak Working Set: 4,579,328

as I said, it is leaving sandboxie...

Appears to be XP specific. I was testing on Windows 7 before. I can reproduce what you see on a fully patched XP SP3 with no sandbox injection. My HIPS log:



I does do a lot of stuff after deleting ie.exe...however it's all sandboxed.


Not sure about that. It could just be the way sandboxed folders work. However, I don't think it's a desirable event. I guess it's something for tzuk to look at.

Here is XP SP3 (no patches thereafter) and still the same result, no delete of the ie.exe. interesting .........

According to microsoft, other than not having ie8 installed, I am now fully uptodate patch wise. and I can still reproduce this...

Everything is sandboxed, except for the fact the ie.exe is able to remove itself from the folder I actually stored it in; and that's certainly not a desirable effect, no.

I have tried in XP SP3 fully patched and the file is not able to remove itself.

.reg file gets deleted from sandbox.

nick: I don´t get the "GetModuleHandle(SbieDll.dll)" so I think you have something configured in the sandbox you are using that produces a request to SbieDll.dll but it´s not related to the malware.