Discussion in 'other anti-malware software' started by co22, Mar 28, 2017.
Will this program alert if something is added to Task Scheduler?
(...do you know some other program that can do that)?
Not currently. RO alerts on changes to parts of the registry as well as the start menu.
We already monitor for new tasks for our heuristics so it'd be pretty easy to tie that into the alerting.
Sounds like another useful idea.
@HeiDef - Does Ransom0ff by chance detect and alert to what might be considered abnormal potential early start services (after reboot/before login) and maybe tied into with the MBR Protection sequence or is that some separate matter?
Really getting a feel for this program and the coverage implemented within it.
We just posted version 5.2017.156.2734 (Beta).
Lots of improvements and bug fixes. Many thanks again to all that keep providing support and feedback.
The version we just posted does now include detection of new services added to the registry as well as new task files.
The MBR protection is a different matter but the regular RansomOff driver boots before other services and looks out for malicious activity.
Understood. Thanks for the reply yet again.
By the way I did a new clean install with this most recent release today. 5.2017.156.2734 (Beta).
Back to hammering with some real baddies again but that notorious (for me anyway) shell locker continues to prove to be a pain. Terminated explorer completely and restarted to get back the desktop back on (it knocked out taskbar once too) but (All Clean) and i might have missed an ALERT where it inserted itself and started next boot and I had no Ransom0ff icon! Tried to restart manually a couple of Ransom0ff services (Not the MBR one), couldn't get the tray icon back but it did say something to the effect of not being able to load database?
I rebooted a second time and all was right back to normal again. I detest that shell locker with a passion. It's vicious.
Autoupgraded on my machine like a charm, but still seems to conflict with ShadowDefender (see pages before, Ransomware is frozen but not blocked). Tried it on a second machine, where RO wasn't installed, with the current build, same here.
Now that we got this build out, we'll put some effort into figuring out the SD issues. We have a good sense of what the conflict may be but need to understand why it's happening if our hunch is correct.
We added mitigations for Shell Locker this build. Shell Locker sends a hide window message to the taskbar so RansomOff just unhides it. That action is triggered though by the alert popup so if you did not see the alert window then it would not have performed that action. RO definitely triggers on Shell Locker ransomware activity but by the time Shell Locker tries to start the file encryption process it has already performed its desktop and taskbar shenanigans. And because RO is not a HIPS or implements full behavior analysis, it isn't designed to preempt something like Shell Locker's initial activities.
You aren't able to start the UI component manually. It's designed to be loaded by the service component during user login. The UI gets passed parameters from the service which is why you get the "unable to load database" message when you try to start it yourself. Did you check task manager to make sure it wasn't running already though? Generally in the case of missing icons, just restarting explorer should be enough to reload everything fresh. But that gives us an idea about maybe adding hotkeys or some second method of accessing the RO UI in the event of something like this.
Thank you, wasn't sure if that was already fixed (Changelog did not mention).
I will do additional test and look for that ALERT WINDOW since in my test the only ALERT I did get was with Ransom0ff main prompt.
This one is been of particular interest on this end by virtue of it's swift and pretty potent intent to blind the user and put things out of reach if only temporarily.
(1) I wouldn't want that any other way but at the time didn't consider the point.
(2) The way this was conducted was allowing Ransom0ff ALERT PROMPT to linger for some many seconds which by then of course Shell Locker had already scrapped the desktop and as you point out the Taskbar also took a dive along with it.
Later today i'll retry a series of same test with that same variant and see if or where something might been missed on this end.
Irregardless of the strange circumstance it was refreshing to reveal on a second restart everything completely engaged again right back to normal.
Of course the ransomware scraps had already been nicely cleaned up too.
Too quiet and too many hours without a word yet LoL but this must be a very good sign that this newest release is stable for most now?
All is still proceeding really well on this end tested with Win 10. It would be interesting to hear from users who are trying Ransom0ff on other platforms.
Took a little time probing and looking into FormClosingEventArgs & FormClosingEventHandler etc. but that's more for developer eyes
Besides not sure if even looking for the right section but I gave it a shot and anyway no matter, Ransom0ff runs off the screen stealers anyway.
I'm sure that I speak for others saying thanks for the config saving addition too.
Quiet is good. Have a couple minor issues reported along with testing SD compatibility but nothing major yet.
Hopefully we can move on from the beta designation shortly.
BTW, is it correct to say that RO would have stopped WannaCry even if it originated from a trusted system process like lsass.exe, because RO watches for suspicious file system behavior, no matter what process is triggering this?
We haven't tested against the full blown EB attack but yes it should not matter that lsass, or any trusted process, launched WannaCry or other ransomware. The parent process does play a role in determining the level of protection that RO applies to a process but it's not a big role.
There are other EB initiated attacks where the ransomware is not dropped to the disk and all of the encryption occurs via lsass or other system processes thanks to an injected thread. RO does have multiple heuristics to look for ransomware activity so in theory that too should be detected. RO doesn't currently, but we plan on adding, thread injection detection which would help mitigate that kind of threat even more so.
OK thanks for the info. And I didn't know that WannaCry wasn't always dropped to disk, sounds a bit scary to be honest. Because that would mean it's basically in-memory malware, and I have never seen this being used in real life attacks.
So this would mean that dedicated anti-exploit that can block the exploit in its early stages will become even more important. But the thing is, certain exploit mitigations could cause problems when applied to system processes. So it's probably best if M$ hardens Windows and system processes even more. And of course behavioral monitoring tools should keep a close eye on system processes too.
I could never install it while in shadow mode because it required a reboot and at this point not willing to commit it with SD. I did install it in virtual box and ran a bunch a malware but also had Malwarebytes. Never got a peep out of Ransomoff but WD and malwarbytes kepps flagging the same replicating Ransom.Virlock and Trojan Virlock in the temp folder. They would not stop so I had to delete the snapshot altogether.
Well, there's some living proof.
Ransom0ff WOULD HAVE decommissioned that thing (clean up the scraps if any) and kick it to the collector array for deletion (or the return pit) LOL
I tested samples minus SD and also disabled ERP plus my favorite app Secure Folders. Even if it takes a few seconds (I sometimes let the Ransom0ff ALERT BOX stand there a long time before pressing DENY), it does the job nicely so far against a bunch of ransomware variants.
The only ransomware so far that gave me fits is shell locker (left a pile of junk files) but even after a second reboot all was cleaned up and back to normal.
Make an image if you can without the other security apps and let it at some test ransomware and you might be surprised what it can do without interference from those other programs, and then work them back in but allow for Ransom0ff to be exempted like it does security apps.
EDIT: I hadn't tested against Virlock.ransom boredog but just did.
Nasty piece of work, Ransom0ff terminated it alright but NOT before it SPAWNED and infected 2 other normal programs which Ransom0ff "detected" and I had to DENY but maintained them. Looks like it uses those others to CALL OUTBOUND...........(something they never do)
TAKE NOTE: I left Ransom0ff App Lockdown disabled and the main new spawned/dropped did INDEED settle into APPDATA/LOCAL/TEMP
Mean Trojan, thanks for bringing this up.
Thanks for the detailed test notes.
We'll see how we can tighten up the cleanup process to make sure those spawned processes get terminated as well. It already does terminate child processes but some can get by depending on the various levels of misdirection that malware sometimes goes through.
From the reports it's actually Cry128 that is running from memory. Apparently other groups have been using the EB exploit well before WannaCry became mainstream.
I also had Voodooshield installed. the nasty appeared to not be doing anything but am not sure.
it was a continuous cycle of detecting after a new file was created. sounds like you didn't encounter that EASTER?
Oh and It was tested with what ever version was available before this latest build. I have not tried the latest build on that bugger yet.
It indeed requires a reboot.
This is why I "dared" to install it on two separate live systems multiple times, with multiple builds. After that, I had SD activated on demand for testing and exited by reboot.
Everything worked fine (never any BSOD, GUI / driver issue already solved with a later build after me reporting) but the SD issues described above , did not try any malware outside the SD environment (you never should).
What I DID encounter was roughly the same but far different too as far as the main ingredient unleashed shell commands-spawns new files/dropped but inactive while others are in fact active, and it was (in my case) at least a pair of additional (those active spawned) processes two of which were injected to call out.
What I found was Ransom0ff also ALERTED to those processes too! That should be considered another important development since those (2) new detected processes were easily recognized by me as previously 100% safe and never call out ever.
It was a surprise to see the detection on this end when they were picked up like that.
Ransom0ff, as currently designed I think, at least from what I could determine, reacted to "new processes" etc. (that exhibit ransomware behavior) but let's be clear here, the particular tested variant Virlock is also a file infector virus since it was learned on additional tests with Shadow Defender (0N) ,things got dirtied up real bad, even the SD executables were rendered disabled/changed what have you. Also because of that a hard reset was required which returned the state of the machine to zero again. This was only AFTER allowing the Ransom0ff ALERT PROMPTS to proceed with ALLOW which is not what you want to do unless testing in a closed environment. .
My inviroment includes Marcrium, SD and Virtual box. Was going to tell you that the Version of windows I installed in VB was Corporate and not Home like I mentioned before and I deleted the first VM, then added the same Corporate VM back and it gives 90 more days of use.