Amir

EAM failed against Ransomware!

Recommended Posts

Hi

I found 12 malware which i posted them on Malwaretips

One of the members tested EAM with them and EAM detected 6 of them by signatures and none of the 6 left item were blocked by behavior blocker!!and unfortunately files were encrypted by a Ransomware

I think EAM could've done better and Emsisoft is far from it's good days

Hope Emsisoft gets to the top soon 

 

Share this post


Link to post
Share on other sites

Thank you for your feedback. Could you please send us the samples that weren't blocked so we can check out why they were able to encrypt files?

Share this post


Link to post
Share on other sites
17 minutes ago, Elise said:

Can you share the password as well? :)

Sorry, i totally forgot😁

INFECTED20

After you checked them, could you please explain why this happened?

I've always believed in EAM Behavior blocker specially against Ransomware

Share this post


Link to post
Share on other sites
1 hour ago, Amir said:

Hi

I found 12 malware which i posted them on Malwaretips

One of the members tested EAM with them and EAM detected 6 of them by signatures and none of the 6 left item were blocked by behavior blocker!!and unfortunately files were encrypted by a Ransomware

I think EAM could've done better and Emsisoft is far from it's good days

Hope Emsisoft gets to the top soon 

 

Also you can see the test here:

https://malwaretips.com/threads/amirs-09-01-2020-12.97712/#post-852709

Share this post


Link to post
Share on other sites

Unfortunately I can't access that topic. I have checked the files and I suspect the issue is with the powershell script (mal.ps1). A script like that one is usually the result of being dropped by other malware or ending up on the system using exploit code, which will be blocked. To simulate that correctly in a test you would need to find out what malware dropped this script and run that instead.

  • Upvote 1

Share this post


Link to post
Share on other sites
11 hours ago, Elise said:

Unfortunately I can't access that topic. I have checked the files and I suspect the issue is with the powershell script (mal.ps1). A script like that one is usually the result of being dropped by other malware or ending up on the system using exploit code, which will be blocked. To simulate that correctly in a test you would need to find out what malware dropped this script and run that instead.

I understand what you say

But that powershell had Ransomwarelike behavior and should have been blocked by BB

Share this post


Link to post
Share on other sites

It depends completely on how this script is executed; in a "normal" malware scenario it will be dropped or downloaded, which will lead it to be blocked.

  • Upvote 1

Share this post


Link to post
Share on other sites

@Elise  - out of curiosity I downloaded the samples, unpacked the archive, and opened some of the files (the VBE, VBS and PowerShell ones) in a text editor.   After looking at each of those, I right-clicked each one and selected 'Delete' - and EAM intercepted the placement of the file in the Recycle Bin (under the system-generated Recycle-Bin filename).   But a right-click context scan of the unpacked archive didn't class those same .vbe/.vbs files as malware.   I was surprised.

Looking back through the log I think I found the reason.  When I unpacked the archive,  FileGuard told me about each malicious file, preventing the unpack from proceeding.  I think I chose 'Allow always'.  That seems to have added each of the unpacked files' full paths to my list of Exclusions.  I suppose that explains why the files were not detected by a later scan of the unpacked folder...  

But... when I clicked 'Allow always', during the unpack, I thought I was allowing the unpack process to continue - specifically I was allowing that instance of 7z.exe to create files.   I do not think that Allowing 7z to do something should translate into allowing the files it created to be excluded from future scans. 

Share this post


Link to post
Share on other sites

I will test this a bit next week, in the mean time you may want to check what the alert was for, because I highly doubt it was for 7zip and rather for the malware file(s).  

Share this post


Link to post
Share on other sites

I didn't say that the alerts were "for" 7zip rather than the malware files.  The alerts /were/ for the malware files.    BUT, it was 7zip that I was running.    The problems here are probably more an issue for @GT500 than you, though.

I've repeated this.  Downloading the .rar file with the samples in it causes no alerts.  As soon as I asked 7zip to unpack the archive and provided the password, I got the first alert.  (None of these alerts happen if FileGuard is set to its Default scan level - but I normally have "Thorough" set.)  Two screenshots, of the alert's first pane and what you see if you scroll that down a bit: https://www.dropbox.com/s/ejwz0ovkpokevgk/20200111 Elise malware alert 01.jpg?dl=0   and  https://www.dropbox.com/s/5twp18fwcbgaq1u/20200111 Elise malware alert 02.jpg?dl=0

This alert follows creation of the file:  0eb7ba6457367f8f5f917f37ebbf1e7ccf0e971557dbe5d7547e49d129ac0e98.doc

Opening a Windows Explorer view of the extract-to folder shows that the file has already been created.  When reading the meaning of the "Allow" options, which talk about "letting an action continue", that's misleading.  Most alerts happen before a program is executed or a dodgy file is processed, when "continue" means let it run/be used.

The descriptions of what "Allow once" and "Allow always" could be worded better for this situation.   I think most users would regard "Allow once" and "Allow always" as differing only in the number of times that something is allowed.  But in this case

    Allow once               - lets the just-created file stay where it is

    Allow always            - lets the just-created file stay where it is    AND   in future allow it to be used/run

Creation of the file (by 7zip) is not in itself dangerous.  But future use/execution is extremely dangerous.   The distinction in meaning/effect of these two Allow options is nothing like clear enough.

 

I do understand that there's a difference between EAM intercepting an attempted execution of something.exe, where the .exe itself is the danger, and eg a system utility (like part of the scripting framework eg wscript.exe) or a well-known interpreter (eg python.exe) or utility (eg i_view32.exe) reading a file and interpreting its contents.   I /hope/ that EAM intercepts attempted execution of a .exe during "program load", or maybe while the .exe is being read prior to load. 

But in this case, although EAM did know that the parent process was 7zip (though it doesn't really matter what the parent was - the problem here affects any program that may create files), does EAM know that the alert is for a just-created file, something that is not being read prior to use/execution?

 

As a matter of practicality, a user encountering a series of alerts as some unpacker or whatever creates a series of dodgy files could usefully be offered an option to terminate the program that is creating the files.   If I hadn't been deliberately running 7zip to unpack these samples, I would rapidly have found it annoying to get alert after alert for every single file it created.   As it was, even if I had clicked on "Allow once" (the safe choice of Allows here) I might have clicked on "Allow always" hoping that that would allow this instance of /7zip/ to keep creating files without generating alerts for each one.   Again, clarity in the alert box about precisely what is being allowed would help.

 

There's another problem.  After (in my test recreation of this) I'd allowed the .doc file "once", EAM produced an alert for the next file (a .vbs one).   At that point I looked at EAM's forensic log - see: https://www.dropbox.com/s/adbk1026u856457/20200111 Elise malware alert 04.jpg?dl=0   See the two log entries timestamped 23:21:33.  The .doc file detection happened quite a lot earlier than the .vbs one, but they are listed in the opposite order.   That's confusing.

 

And another problem...   Last night when recreating this I single-clicked one of the .vbs files' names, to highlight it so I could c&p its full name.  Today, I right-clicked one prior to looking at its Properties pane.  In both cases EAM generated an alert saying the file concerned was trying to execute.  Last night that gave me a hell of a fright.  I'm very very careful and had not thought I'd double-clicked the filename.  Today I was absolutely certain it was a right-click.   When it happened this morning I realised I'd probably been ok last night - the alert is badly worded.   Can EAM not tell the difference between standard parts of Windows Explorer's context menu handling (selecting a file's name, or displaying its properties?) and an arbitrary context menu handler offering to do something with the file?

 

[Last night, after the "trying to execute" alert, I clicked on Quarantine on that alert.  EAM then told me it couldn't delete the "infection" and I needed to restart.  I presume the problem would be that either another part of EAM had a handle open on the file, or maybe 7zip still did?  During the reboot a boot-time file deletion was performed, and I did a second full shutdown immediately after that, then a cold reboot.  I've also done a full-scan of the machine since then, and there's no sign of any malware.]

 

 

 

 

Share this post


Link to post
Share on other sites

I haven't been following this topic since Elise has been replying to it (she actually knows our File Guard and Behavior Blocker technologies better than I do), so I may be missing something here.

 

On 1/12/2020 at 5:49 AM, JeremyNicoll said:

Downloading the .rar file with the samples in it causes no alerts.  As soon as I asked 7zip to unpack the archive and provided the password, I got the first alert.  (None of these alerts happen if FileGuard is set to its Default scan level - but I normally have "Thorough" set.)

That behavior is normal for Thorough scan level. EAM would only alert for the RAR file if there are signatures for it, as it doesn't automatically unpack the archive to scan the contents.

You'll see no alerts when File Guard is set to Default scan level while using software that doesn't support IOfficeAntiVirus or AMSI, and I would believe that 7-Zip has yet to implement these technologies.

 

On 1/12/2020 at 5:49 AM, JeremyNicoll said:

But in this case, although EAM did know that the parent process was 7zip (though it doesn't really matter what the parent was - the problem here affects any program that may create files), does EAM know that the alert is for a just-created file, something that is not being read prior to use/execution?

In your example that I quoted above you were extracting files from a RAR archive. When EAM's File Guard is configured for Thorough scan level, it scans every newly written file, so while you're extracting files from an archive EAM is scanning each file. If a file being extracted from the archive is detected as malicious, the File Guard responds to that just like it would for any other file. The program writing the file doesn't generally matter.

The Behavior Blocker is a bit different, since it's monitoring processes and it needs to be aware of cases where a process opens (for instance) a script for processing. A good example is a batch file, executed by cmd.exe, since EAM would be monitoring cmd.exe but would show the name of the batch file in the alert.

 

On 1/12/2020 at 5:49 AM, JeremyNicoll said:

And another problem...   Last night when recreating this I single-clicked one of the .vbs files' names, to highlight it so I could c&p its full name.  Today, I right-clicked one prior to looking at its Properties pane.  In both cases EAM generated an alert saying the file concerned was trying to execute.

EAM was monitoring file system access, and detected the files were accessed. As for whether or not it's possible to tell the difference between execution and reading file properties by just monitoring I/O I'm not certain.

 

On 1/12/2020 at 5:49 AM, JeremyNicoll said:

Last night, after the "trying to execute" alert, I clicked on Quarantine on that alert.  EAM then told me it couldn't delete the "infection" and I needed to restart.  I presume the problem would be that either another part of EAM had a handle open on the file, or maybe 7zip still did?  During the reboot a boot-time file deletion was performed, and I did a second full shutdown immediately after that, then a cold reboot.  I've also done a full-scan of the machine since then, and there's no sign of any malware.

As you suspect, something had a file handle open to it. EAM doesn't like to fight for file access so it can delete things, as it's easier and less problematic to just delete on reboot.

Share this post


Link to post
Share on other sites

@GT500  OK; you say "When EAM's File Guard is configured for Thorough scan level, it scans every newly written file,   If a file being extracted from the archive is detected as malicious, the File Guard responds to that just like it would for any other file."

The point I'm trying to make is that EAM clearly knows it's scanning the file because it's been newly-written.  That being so, the alert pane should look different from how it does when a file is being read for use or execution.  In particular the two Allow options /should/ be clear on the huge difference in effect between 'Allow once' and 'Allow always'.

Also, EAM knew in this instance that 7zip was the program that created the file.  That info is invisible when you first see the alert pane; one needs to scroll the info.  Obviously in this instance I knew what program had created the iffy file, but in the general case - when an arbitrary program creates a file that EAM thinks is bad - it would be much better for less-aware users if the alert pane said right at the start that program xyz.exe has just created file bad.doc ... and ideally also offered the option to terminate xyz.exe (or even just advised that a user might want to do that themselves, eg via task manager).

The whole point of using EAM is to prtect users against themselves.   This experience does not show EAM doing the best job it could do.

 

Regarding single left click, and right-click on a file entry shown in WIndows Explorer, you said ""EAM was monitoring file system access, and detected the files were accessed".   But I don't see why WE would need to open a file or get a handle on it etc just so that in WE a line showing a filename can be selected/editable.    In the general case for right-click, I expect that either the file's full path, or a file system object gets passed to the chain of context menu handlers.  I'm not sure that I'd expect any of those handlers actually to /access/ the file until a user actually selects a specific one off the menu. 

When one issues a "dir" command in a command window one wouldn't expect to have EAM scan the files contained in the folder, so why would trying to do a WE->Properties do that?  At least for the basic Properties that WE itself displays?  Clearly there's an extension mechanism there too (eg that digs ID3 tags out of .mp3 files) which DOES need a file to be accessed, but I'd have thought the bulk of the info presented comes from file metadata.

Share this post


Link to post
Share on other sites
18 hours ago, JeremyNicoll said:

it would be much better for less-aware users if the alert pane said right at the start that program xyz.exe has just created file bad.doc ...

Except that users don't see the alert dialog that you're referring to. They see a smaller notification on the right side of the screen.

 

18 hours ago, JeremyNicoll said:

But I don't see why WE would need to open a file or get a handle on it etc just so that in WE a line showing a filename can be selected/editable.

Windows Explorer loads information about the file when you click on it. I would believe the same would happen if you hovered the mouse pointer over a file long enough for Windows Explorer to display a tooltip with file properties.

 

18 hours ago, JeremyNicoll said:

When one issues a "dir" command in a command window one wouldn't expect to have EAM scan the files contained in the folder, so why would trying to do a WE->Properties do that?  At least for the basic Properties that WE itself displays?  Clearly there's an extension mechanism there too (eg that digs ID3 tags out of .mp3 files) which DOES need a file to be accessed, but I'd have thought the bulk of the info presented comes from file metadata.

Windows Explorer displays information in the "Details" tab that cmd.exe's dir command doesn't. Some of that information is stored in the file itself, and not in the filesystem.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.