Virtualization question.

This means that hal.dll was still there, because I could boot in my ON-LINE snapshot the first time, which was seriously damaged by DEL and recovered by FDISR.
But I ran DEL a second time after booting in my ON-LINE snapshot and that was probably too much. I will redo the test to be sure.

There could be another reason : the Delete Prevention of my AE isn't marked.

 

Virtualization is useless against new threats as many A/V researchers are finding out. A good virus writer can exploit the exception handling in a VM application to detect if their malicious code is running in a VM. The code behaves itself while in the VM and then causes mischief when it's on your "real" PC.

A criminal will behave while under the watchful eye of a parole officer then re-offend when it ends.

~interact

 

The second test corrupted FDISR also, because of the missing hall.dll.
I also got another message :
Windows cannot find C:\$ISR\$APP\ISRWait.exe
The main reason why it didn't work is that I disabled the "Delete Prevention" (and "Copy Prevention") in my Anti-Executable.
So Anti-Executable is also active in the CMD-window, which is very good.
My on-line snapshot was completely restored, but FDISR itself, didn't work anymore.

I can't enable "Delete Prevention" (and "Copy Prevention"), because it causes errors in the Copy/Update function of FDISR.
I don't need both functions, because my boot-to-restore is supposed to take care of this.

This kind of disaster is included in my recovery solution, so it doesn't matter.
Even a zero-ed harddisk can be recovered this way.

 

It's true that some sofisticated malware can detect if it's running on a VM (VMware or the code emulator of an AV engine) and behave in a harmless way until it's executed in a real system.
Go to this page made by Peter Ferrie (Symantec researcher) and download a Powerpoint presentation called: "Attacks on Virtual Machines v2 (slides)"
However, the virtualization discussed in this thread aims mainly to sandboxes, which do virtualization in a different way (kernel driver and API hooking) than VMware (full emulation of hardware)
The main worries are:
- Can isolated malware leak outside the sandbox?
- Can isolated malware access confidential files and send private data to a remote server?

 

When I clicked on Powerpoint presentation, I got this error:

I had to go to Peter Ferrie's home page first http://pferrie.tripod.com and then click on the Attacks on Virtual Machines v2 (slides) link.

Mike

 

Lucas1985,

One area that I'm currently investigating is to see if API hooks can be rehooked at the kernel level. Many sandboxes / HIP tools use API hooking to detect process starts. If the hook can be removed then it's goodbye to the sandbox and hello hard disc. It's also worth noting that I'm told a process can be started from kernel mode rather than user mode. I've no idea what impact this would have on a sandbox as it may not see a malware process start.

~interact

 

How does a process even begin to do those things?
"If the hook can be removed" - How?
I've seen the creator of SandboxIE ask people how. No one answers him. He asks for details, to patch any vulnerabilities. He doesn't doubt there could be vulnerabilities, but he does ask how. He hears crickets.

 

Pedro,

Here's an interesting article (8.5mb) that got me thinking about doing my own investigations into removing API hooks.

http://www.packetstormsecurity.org/hitb04/hitb04-chew-keong-tan.pdf

I think once this ideology becomes more prevalent in malware then any security tool that uses API hooking could be in trouble.

If you're interested in starting process from kernel mode then I have further info.

~interact

 

Thanks flinchlock. I should have checked the link
Fixed.

If it's possible to start a new process from kernel mode without receiving a prompt from a HIPS, then almost all HIPS and reboot-to-restore solutions will become useless.

 

Hello Lucas,

I don't see the connection between VM/sandbox and reboot-to-restore program. Anything that makes changes to the HD will be gone using a reboot-to-restore solution.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Thanks, but .. over my head
I mean, if it were a document, with explanations and all that, maybe. But it seems to be a presentation where: 1- lacks the presentation by the speaker, 2- assumes that i know what they are talking about, ie, he makes shortcuts from the beggining assuming who is reading already is on top of things.

I hope others can comment on it.

 

Hello Rich,
Reboot-to-restore software uses kernel drivers, right? If a kernel process can be started (don't know how) without prompts from the HIPS/whitelist, it may disable the kernel driver needed for the RTR () software.
Do you remember our conversation about DeepFreeze?

 

No, but you would have to demonstrate a working sample to convince me.

And, of course, how would such malware get onto my computer in the first place.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

That's right.
Each infection has to CHANGE my harddisk to do something evil, that's their WEAKNESS and I use that weakness to kill them by removing the changes on my harddisk during each reboot. Simple but very efficient.

I wished that the change was stopped IMMEDIATELY and not during reboot, like Anti-Executable does, but that software doesn't exist yet.

 

We're talking about the possibility of a malware to execute without warnings from HIPS (Anti-Executable in your case) which could, for example, thaw your frozen snapshot thus surviving the reboot.
At this moment, it's mostly a theoretical discussion with the possibility of some misunderstanding.

It's called Sandboxie

 

No that's NOT Sandboxie. It's a kind of Anti-Executable, but for ALL objects, not just executables.

 

Well, it would be impossible to do anything. For example, the browser needs to write to the cache.

 

You take it all too literally, it's ALL objects with exceptions, if absolutely necessary. I only want to avoid reboots and to have an immediate reaction, not a delayed reaction.

 

Well, then you're contradicting yourself. AE PREVENTS malware from executing at all, while a reboot-to-restore solution lets the malware execute, and then undoes the changes it does. Rmus is correct, SandboxIE would be a much more similar solution to the one you're describing than AE-for-all.

 

Exactly, I didn't know how to describe it, but your substract is fine : Sandboxes can't help as soon as data stealing/remote data extraction is involved somehow.

There are some sandboxes which are taking care of that fact, for example i'm thinking about BufferZone's confidential folder (access forbidden for sandboxed processes), but it doesn't work for all datas located outside the sandbox - programs wouldn't work sandboxed, otherwise; with the LDpinch example again, I do not know any sandbox preventing the user's Windows licence serial from being read , and then possibly uploaded ouch: ).

As said Rmus, layered defense helps to mitigate damages (a good firewall to block outbound access/to block data upload, and why not process execution control, HIPS..), but in my example I only focused on the protection offered by the sandbox on its own.

 

No I'm not contradicting myself, you just don't see the whole picture.
My boot-to-restore does more than just removing the mistakes of my security softwares.

 

SandboxIE's closed file path too. You sound unfamiliar with SandboxIE

I thought you were thinking of XSS or similar problems with javascript, online accounts passwords, etc.

With the closed file path, sandboxed applications do not read my important files. Or do you find it not effective? (when testing)

 

Pedro, I just used Bufferzone as an example, I didn't say it was the only one to provide that kind of protection, about restricted zone/confidential folder.

I don't know how is this protection implemented in Sandboxie (yes, I'm quite unfamiliar with it), but here too I do not think it can't prevent sandboxed process to access system infos like the XP serial number.

 

I have not had time to download an evaluation version of AE.

But, I did do this: DEL /F /S /Q c:\*.*

It deleted a gazillion files (.exe, .dll, all).

I had to turn my PC off/on since the programs for reboot/shutdown were deleted.
My Partition Magic (MBR) menu came up just fine.
The FD-ISR (PBR) pre-boot menu came up just fine.
I choose "F1" and booted into my secondary snapshot just fine.
When I clicked on the systray FD-ISR icon, I got the error message: Can't open FirstDefense-ISR Manager.
I installed FD-ISR.
I clicked on the systray FD-ISR icon and it came up just fine.
I did a Copy/Update from Secondary -> Primary.
It replaced 34,596 missing files and 50 missing folders (4.26GB).
I reboot into my Primary, and all is fine


Mike