Sandbox let something change startup entry

Here is the deal:
Win XP SP3 cis 4.1 premium. No other security software
Testing a rouge Windows Protector.

The program ran in the sandbox and nothing was harmed, except for the startup folder. The rogue was able to create an entry in the startup folder. WHen I restarted the PC the application failed to run, however is was able to create that entry.

I have the rogue if the developers need it. The AV does not catch the malware without heur in medium. Already submitted the file to COMODO.

was it listed in start → programs → start up? If so that is normal, what it did is drop a file and/or short cut in the following folder c:\users*name*\appdata\roaming\microsoft\windows\start menu\programs\startup and when windows starts it tries to run any programs or shortcuts in the folder automatically, which is why you got the error. So basically it did the only thing it could do and that is to drop a file.

Thats exactly what happened. Still the sandbox is supposed to virtualize this actions or not? The same way this file was droped any other file could. And it was not a shortcut in startup it was an exe file. My point is if virtualization is on why when i rebooted the entry was there? Does the startup folder does not get virtualized?
Thanks

Not it does not virtualize all folders just the protected windows folders, so the program can still drop files in other folders but if you try to fun that file it will automatically get sandboxed.

AFAIK due to privilege stripping of automated sandboxing it wouldn’t be possible for those apps to carry some operations not possible under Limited user accounts (eg writing HKey Local Machine (HKLM registry) or %programfiles% %windir% folders) but there are additional restrictions (eg Jobs restrictions).

In addition to the sandbox restriction level set for an application, defense + also implements the following restrictions. A sandboxed application cannot:
  • Access non-sandboxed applications in memory
  • Access protected COM interfaces
  • Key log or screen capture
  • Set windows hooks
  • Modify protected registry keys (if virtualization is disabled)
  • Modify EXISTING protected file (if virtualization is disabled)

COM and Hooks will likely trigger alerts and other access rights might be silently denied (and listed in D+ log)

All Protected registry keys will be blocked and this AFAIK includes also automatic startup Registry keys for Current user (HKCU registry)

Sandboxed apps writing new executables into startup folder appear indeed a possibility:

  • In case of automated sandboxing virtualization is disabled
  • Privilege restrictions to sandboxed executable do not restrict access to %userprofile% folder (in similar fashion for LUA accounts)
  • “Startup Folders” File group is listed in protected files (so already existing files in such wildcarded paths should not be modifiable).

PS please check “Startup Folders” File group to confirm trailing * is in place for all paths.

more info at: Introduction to the Sandbox

Wait. I dont get it. Is it ok that a sandboxed app dropped a file into the starup folder or not? I see your point about the features for the sandbox but still, a file was created permanently by a sandboxed app.

I didn’t say if it was ok or not. I only outlined what I was able to gather from the documentation and available info but I don’t even know if such rogue was run automatically sandboxed or not.

In instance to confirm what it is liklely to happen a rogue might not be necessary at all.

The rogue was automatically sandboxed by CIS. THe firewall alerted me that the rogue was trying to connect to the internet. I blocked it. I restarted the PC and then I got an error that the rogue wasnt able to run. When I checked msconfig I saw an entry at the startup folder and there it was, the rogue itself, not a shortcut.

I say it is fine, why you ask. Simple, if another program tries to access that file it will also get sandboxed. And because the startup folder is not a critical folder it will not effect the way windows runs. So when the AV signatures catch up with whatever file got dropped, CIS will find it when scanning or if the file tries to run and it will get deleted by the AV.

right, becasue it was sandboxed it was not able to install all of it’s files all it could do is drop that fine, and it was not the rogue trying to run it was windows trying to run that file and CIS blocking it.

Got it. anyway the PC did not get harm. Everything was running cool. A scan with mbam did not returned one single entry.

thanks guys!