[AV-TEST] Windows 10, Home User, October 2017

[Malware Person]

nice to see Bitdefender up there in the list!

 

[Deleted member 65228]

Let's say I get infected with Petya, if I'm backing up my entire ssd drive which consists of the C:\ partition, the EFI system partition and the recovery partition, to Acronis Secure Zone, I'll be able to easily recover it with an acronis boot usb, right? Nothing besides acronis is supposed to be able to access the secure zone, which also has a password protection option, so I should be safe right?

As long as you can boot with Acronis and access the Secure Zone data/it hadn't been touched to be modified then I'd assume it would work, would make sense.

If you get hit with Petya then the Petya boot-loader would still be able to encrypt the Master File Table, then the data in the secure zone will be affected. Without a decrypted MFT, you cannot make sense of what files are what and what-not.

About the Acronis Secure Zone, I wouldn't bet on it being full-proof. It can be bypassed but you'll need a lot more control over the system without a very extraordinary exploit. Petya isn't going to touch it though - some ransomware rely on modified open-source device drivers like DiskCryptor though, and this opens up a gray line because with some more adaptations it would be able to access the data stored in the Secure Zone and write to it.

Very rare and unlikely attack still. I wouldn't worry about it as long as you have a secure backup. However my advice would be to keep some backups stored elsewhere off your actual machine.

 

[Itachi Sempai]

Isn't this what encryption does? No one has access to the encrypted thing unless they can decrypt it? Based on your answer I'd say no, but I still wonder

lets say i wrote sentence on my HDD "i love you ana" after encryption you can imagine that sentence will transform to "hfkwerfW*f2-fP" so that nobody will understand what is written there but they still can delete it

 

[upnorth]

@upnorth My suspicion was correct! If you're elevated, you can force uninstall it.

Good catch! Another reson why I enjoy MT. Thanks alot for the test @Opcode

 

[aceyy]

I'm the author of MBR Filter, upnorth sent me an email asking for me to comment on the thread.

I appreciate the feedback, just wanted to give some context and explanation. MBR Filter is purely meant as something to prevent writing to the MBR. It's a prototype and I didn't want to be too intrusive if something went wrong so no self protections are currently in place. As such it doesn't prevent writing to the registry keys that it uses, but that could be easily fixed by registering a callback as was mentioned in the thread.

I like the idea of adding the process name and path when reporting that the MBR was accessed. Also reporting in a log message besides the message box is a good idea. I definitely don't want to terminate the process accessing the MBR as there are valid tools that require access, which I would prefer to fail correctly, which is why I display the message to reboot to safe mode.

I'll add the better messaging and logging when I do a next revision (I opened issues Add process name/path to message · Issue #14 · Cisco-Talos/MBRFilter · GitHub and Log denial requests (not just the message box) · Issue #15 · Cisco-Talos/MBRFilter · GitHub) and might consider some self-protection along with an easier install / uninstall (in safe mode). I'm still getting scattered reports of boot problems from some users which I've been unable to replicate. It takes a bit of time to get things signed when releasing, so I've been delaying any updates until I could pinpoint that problem. My current suspicion is that people might have accidentally installed the wrong version (32 vs 64) for their operating system, if that's the case then an installer could fix that problem.

 

[upnorth]

Thanks alot @aceyy for the explanation. Looking forward to the next revision.

 

[ZeroDay]

I'm the author of MBR Filter, upnorth sent me an email asking for me to comment on the thread.

I appreciate the feedback, just wanted to give some context and explanation. MBR Filter is purely meant as something to prevent writing to the MBR. It's a prototype and I didn't want to be too intrusive if something went wrong so no self protections are currently in place. As such it doesn't prevent writing to the registry keys that it uses, but that could be easily fixed by registering a callback as was mentioned in the thread.

I like the idea of adding the process name and path when reporting that the MBR was accessed. Also reporting in a log message besides the message box is a good idea. I definitely don't want to terminate the process accessing the MBR as there are valid tools that require access, which I would prefer to fail correctly, which is why I display the message to reboot to safe mode.

I'll add the better messaging and logging when I do a next revision (I opened issues Add process name/path to message · Issue #14 · Cisco-Talos/MBRFilter · GitHub and Log denial requests (not just the message box) · Issue #15 · Cisco-Talos/MBRFilter · GitHub) and might consider some self-protection along with an easier install / uninstall (in safe mode). I'm still getting scattered reports of boot problems from some users which I've been unable to replicate. It takes a bit of time to get things signed when releasing, so I've been delaying any updates until I could pinpoint that problem. My current suspicion is that people might have accidentally installed the wrong version (32 vs 64) for their operating system, if that's the case then an installer could fix that problem.

What a Dev! Now that's support and a Dev who's open to suggestions. Good for you.There's not many Dev's like that no matter the customer base they have. I think Emsisoft and VoodooShield are the only other 2 I've seen offer such support on forums.

 

[Deleted member 65228]

@aceyy Welcome to MalwareTips!

Before I say anything, I'd like to get it off my chest that I am a fan of your work and MBR Filter is one of the additions which I really like (which is open-source and an addition-tool like it is). I used to have it installed and active for many months, it didn't cause me one issue.

Spoiler

When you call IoGetCurrentProcess, you can use the returned EPROCESS pointer structure returned with PsGetProcessId (to obtain the Process ID -> type-cast it to ULONG) and you can also pass that same pointer structure returned to an undocumented function which is however exported by NTOSKRNL called SeLocateProcessImageName (a lengthier alternate which would work perfectly fine as well would be using NtQuerySystemInformation to enumerate the PSYSTEM_PROCESS_INFORMATION structure and compare the Process ID with the one within the pointer structure -> keep looping through until you make a match and then obtain the image name from the pointer structure).

You can find the address to both SeLocateProcessImageName/NtQuerySystemInformation with MmGetSystemRoutineAddress.

You could even think about adding an option which can be toggled via a registry value modification to automatically suspend the process responsible for the boot-sector modification attempt. You could achieve this via KeSuspendProcess (exported by NTOSKRNL -> no need to use NtSuspendProcess). I say this because some ransomware will deploy an alternate payload if it cannot attack the MBR.

Your response is one of the most honest I've ever seen. You're a great developer, you have experience and you're honest. More often than not, I find developers justifying against suggestions/general user feedback because they cannot "handle" it, but yours was perfect.

I was going to drop one of those "I'd be happy to help!" notes but I doubt you would need any haha, I'm looking forward to your future revisions and I'm glad that you liked my suggestions.

 

[Deleted member 65228]

My current suspicion is that people might have accidentally installed the wrong version (32 vs 64) for their operating system, if that's the case then an installer could fix that problem.

I don't think that could be it because Windows should automatically block the installation. The 32-bit compiled driver isn't compatible with 64-bit Windows so it simply won't be allowed to load, and the same applies for 64-bit compilation on a 32-bit environment.

 

[Windows_Security]

I'm the author of MBR Filter, upnorth sent me an email asking for me to comment on the thread.

I appreciate the feedback, just wanted to give some context and explanation. MBR Filter is purely meant as something to prevent writing to the MBR. It's a prototype and I didn't want to be too intrusive if something went wrong so no self protections are currently in place. As such it doesn't prevent writing to the registry keys that it uses, but that could be easily fixed by registering a callback as was mentioned in the thread.

I like the idea of adding the process name and path when reporting that the MBR was accessed. Also reporting in a log message besides the message box is a good idea. I definitely don't want to terminate the process accessing the MBR as there are valid tools that require access, which I would prefer to fail correctly, which is why I display the message to reboot to safe mode.

I'll add the better messaging and logging when I do a next revision (I opened issues Add process name/path to message · Issue #14 · Cisco-Talos/MBRFilter · GitHub and Log denial requests (not just the message box) · Issue #15 · Cisco-Talos/MBRFilter · GitHub) and might consider some self-protection along with an easier install / uninstall (in safe mode). I'm still getting scattered reports of boot problems from some users which I've been unable to replicate. It takes a bit of time to get things signed when releasing, so I've been delaying any updates until I could pinpoint that problem. My current suspicion is that people might have accidentally installed the wrong version (32 vs 64) for their operating system, if that's the case then an installer could fix that problem.

Also add a proper uninstall. Most boot problems are from people not removing the correct registry values.

 

[Windows_Security]

Proper uninstaller in 2017 . I can't remember the last time I uninstalled something and there were no leftovers in Revo Uninstaller Pro with maximum scanning mode, at this point of time it's expected that a program has to be uninstalled with an advanced 3rd party uninstaller if you want to make sure it's fully uninstalled, but yeah it won't hurt too much if he does that

When you remove MBR Filter in the wrong way, it wrecks your system. So goodluck uninstalling MBRfilter with Revo (create an emergency disk/usb and make an image backup and backup all your data before doing so).