The unofficial Shadow Defender Support Thread.

As I make it a rule not to run alpha/beta software on my one and only PC, I'll wait for the final release of SBIE v4 to give it a go.

But I appreciate the suggestion Bo.

TS

 

Thanks for that tidbit Bo, I didn't realize that was still true when Drop Rights wasn't enabled in SBIE. Would you happen to know how that's accomplished?

Wendi

 

Hi Wendy, read this:

http://www.sandboxie.com/index.php?SBIE2103

Bo

 

Thanks Bo, but that doesn't explain how "pograms running under the supervision of Sandboxie are stripped of privileges required to start drivers"... - i.e., how does SBIE know that the program is going to install a driver?

Wendi

 

I don't know. What I know is that drivers wont install unless you make the changes that are mentioned at the bottom of this link:

http://www.sandboxie.com/index.php?BlockDrivers

I also know the reason why SBIE does not allow drivers to install is because drivers work at a lower level than Sandboxie does. If drivers were allowed to install, Sandboxie would not have any control over them.

Bo

 

I'm hardly infuential, maybe just more loud than others; but then again I'm Greek and we are quite loud as a nation

Patrick has actually contributed a lot more than myself and many others, especially during the hard period when Tony was AWOL. Also Cutting for starting this thread, the place where us SD faithfuls would gather, commune, and find solace with each other during the barren years when our Great Dear Leader Tony was off to parts unknown.

If there was ever an infuential SD supporter award, Patrick would get my full vote

 

While I'm sure that amazing process must be a proprietary to tzuk, if he accomplished that I would imagine Tony also could.

TS

 

TS, I am sure Tony can do it too if he wanted. But personally, I am delighted the way that SD is now. If Drop Rights and restrictions like blocking drivers installation were available in SD as they are in SBIE, there would be very little that we could try under SD.

Bo

 

Bo, that's a very good point (which alluded me). Therefore, I'll be very satisfied if Tony would implement a Drop Rights 'option' (similar to that of SBIE).

----
Ps. I've been experiencing some very strange posting issues on this forum today!

 

This is why I said earlier that some software installations in Shadow Mode will not work if drop rights is activated. I would like this to be completely optional, so we can still test stuff that don't require reboots in Shadow Mode.

I'll drop a line to Tony next week. To tell you the truth I'm not optimistic that he will go for it, unless of course many of us e-mail him and request it; he may then yield under popular demand.

 

Some form of policy restriction sounds like one of the best options for preventing the nasties that could potentially bypass SD. As already mentioned some technology similar to that Sandboxie uses. I don't really need it though to be honest since I already use Appguard. I see no harm in it though as long as it is made as an optional mode, and it does not cause compatibility issues with other software like Appguard.

 

Has this already been posted? Here are the results of some rootkits that were tested against Shadow Defender being tested against Diskshot. Sinowal bypassed Diskshot to. -http://malwaretips.com/Thread-Diskshot-Home-3-7-970-vs-5-MBR-VBR-Rootkits

 

I saw that too. Looks like Sinowal is "da bomb" ATM where sturdy malware are concerned. I wish we could have an executable sample to send to Tony.

Maybe our resident Polish speakers (Ichito, Artur) could contact the people that have performed the tests and ask for the samples?

 

Possible Sources...

-http://forums.malwarebytes.org/index.php?showtopic=115426- (must register/login, etc.)
-http://minus.com/mbkiPTU7Bc-


...adding to the concern of this seemingly deadly trojan - read this 2012 account from an infected user!

 

i like developer add simple registry Exclusion
please say to that
thanks

 

That is one hell of a trojan. Cannot be repaired? You actually have to buy new hardware to get rid of it? Seems like the ultimate malware. Hopefully the AVs will detect it upon download.

It would be interesting to see if SD could add protection against this new infection technique. I'd also like to know if SD is an honest company these days after being abandonware for years.

 

The incident I quoted above had nothing to do with the registry (it affects/replaces the MBR)!

 

Thanks for the links Shadow, unfortunately the minus.com links don't seem to work. Maybe an account needs t be created, I don't know.

So this bug could survive a full backup restore plus a boot sector restore? I don't mean a normal post-infection clean-up plus a boot sector repair, I mean the whole disk surface (including the boot sector), being completely overwritten by a sector-by-sector restore of a previously saved clean image. This bug can survive this? How can this be?

A short prison sentence is too good for people who write such crimeware. Criminals like these should get life, and a burly cellmate called Bubba...

 

Sinowal, Mebroot, Torpig, or whatever its name, is a rapidly evolving dangerous trojan, so much so that it's very difficult to keep up with its evolution. Imho the best protection SD could implement (in addition to its 'virtualized container') would be to copy-cat Sandboxie's 'Drop Rights' (to an LUA) option. And whenever running SD with Admin privileges (e.g., to test-run a new app, etc.) I would first manually scan the app with Hitman Pro or the like.

 

CM, perhaps it also attacks the BIOS? ...I really don't know (the responsible cyber-terrorists are a lot more tech-savvy than me)!

 

I just sent this e-mail to Tony:

Thanks for the reply Tony.

Apparently some Polish users have already tested DiskShot and SD against five very strong malware, including Sinwal. Both software have failed to contain Sinowal.

Here is the DiskShot test link:

http://malwaretips.com/Thread-Diskshot-Home-3-7-970-vs-5-MBR-VBR-Rootkits

Here is the SD test link:

http://malwaretips.com/Thread-Shadow-Defender-1-2-0-370-vs-5-MBR-VBR-Rootkits

If you can't see the YouTube links try using a proxy or a VPN connection.

This is what an infected user said about Sinowal:

We have a machine that is infected with Mebroot/Sinowal. We have "removed it" multiple times now with a variety of antivirus/antimalware applications and each time it appears to return upon reboot. The last time, was using a Kaspersky Rescue CD Scan which claimed to have deleted it but when we run Gmer MBR and/or Gmer MBR -F, this is what is displayed:

device: opened successfully
user: MBR read successfully
kernel: MBR read successfully
user & kernel MBR OK
copy of MBR has been found in sector 0x0BA50E41
malicious code @ sector 0x0BA50E44 !
PE file found in sector at 0x0BA50E5A !

If we scan again with yet another utility, it is almost always not detected - but if it is detected another singular instance of the infection is found with claims of having deleted it. But afterwards, Gmer MBR always shows the message listed above. This helps me to understand why Symantec, Simon and other antivirus/antimalware vendors took down their Removal Tools. I believe the previous versions of this infection could be rightly addressed. But the current version cannot be removed. Since no application appears capable of removing this infection from the boot sector, it would appear that the only resolution to this particular infection is to purchase a new hard disk. This would explain why a low level format, standard format, fdisk /r, fixmbr, fixboot, etc., etc. have absolutely no effect on this infection! Apparently Sinowal can survive even a low level format, standard format, fdisk /r, fixmbr, fixboot, etc., All these solutions have absolutely no effect on this infection!

Here is a decent technical analysis of a Sinowal variant:

http://www.saferbytes.it/2012/06/06...nd-it-always-brings-some-new-clever-features/

There is a page with many samples but the links don't seem to work. Maybe you need to sign up for the links to work:

http://minus.com/mbkiPTU7Bc

Unfortunately I couldn't download any samples from there, but if you do manage to get them you must be very careful with Sinowal. Only test it on an isolated system with a single hard disk, and better to use an old hard disk that you won't mind throwing away if it gets infected beyond repair.

There is also an idea that a lot of SD users have been discussing lately: It would be great for SD to have a Drop Rights option under Shadow Mode, the same like Sandboxie. Of course this should be optional, people would turn Drop Rights on and off if they want. Part of Drop Rights policy should also be a suboption that would allow or block driver install while in Shadow Mode. With Drop Rights and Block Drivers options in Shadow Mode no malware could actually be installed. This is how Sandboxie works and those options are actually enabled by default.

It would be great if you could develop similar Drop Rights and Block Drivers options for Shadow Mode. I think that these options should be enabled by default. Users that want to test software under Shadow Mode could turn those options off if they want to. This would make SD even stronger and would bring peace of mind to many people who worry about MBR protection.

People in the Wilders forum have been discussing about this. Do you think it is possible to include such options? Personally I think that it is a great idea, and that you should look into it. I hope that it can be done!

 

That's the only thing I could have thought off as well. But on every info I have read about Sinowal there have never been a mention that the code actually targets the BIOS. If this is the case, then I think that a full sector-by-sector restore of a clean backup including the boot sector would still resolve the issue.

The infected guy on Shadow's post mentioned attempts of post-infection cleanups, formatting and repairing the boot sector. There was no actual mention of restoring the disk from an image, and overwriting all sectors. That's why I thought that the mention of having to discard the disk and buy a new one was probably too much.

The disk's buffer itself would get flushed upon reboot; so if the kit doesn't target the BIOS chip, where could it possibly hide its code upon a complete sector by sector overwrite?

I still suggested to Tony to use an old disk on an isolated system, just in case...

 

CM,

An S-B-S restore implies that one created an S-B-S backup and I don't see why that should be necessary - unless one has raw data sectors (or another OS) to be preserved. Otherwise, I don't believe S-B-S accomplishes anything worthwhile in restoring a clean system.

I believe that a 'normal' (used sectors only) image backup and restore would be sufficient (that is as long as that normal image backup was created before the infection). However I would advise running a complete format of the system drive/partition before restoring the normal (clean) image!

TS

----
Ps. Thanks for relating my Drop Rights idea to Tony.

 

You're welcome brother.

I only mentioned sector-by-sector simply because I have RX installed; so my backups are always raw to preserve the snapshots. Of course a normal restore +bootsector should also resolve this. The only thing that can beat a full restore is a BIOSkit like Niwa.

If BIOSkits become more "popular" in the future, I'd love to have the piece of mind that would come with a reinforced SD that is capable to drop rights/block drivers. Shadow, if you have any additional suggestions on how such options should be implemented, drop a line to Tony directly.

BTW Here's a decent analysis of such a BIOSkit infection:

http://blogs.mcafee.com/mcafee-labs/bioskits-join-ranks-of-stealth-malware

 

Ah yes, Rx's snapshots are raw data sectors, and the only way to capture those Rx snapshots is with an S-B-S image backup. I also used to be an Rx user until the day it messed-up my system worse than any malware I've ever experienced. But that's a sad story for some other time.

Thanks for the BIOSkit info - ugly stuff...