JeremyNicoll

Member
  • Content Count

    1509
  • Joined

  • Last visited

  • Days Won

    24

Posts posted by JeremyNicoll


  1. Ok.  I plugged that SHA1 hash into the search option at the VirusTotal website, which then displays what various anti-virus & anti-malware utilities think about a file (regardless of what it's been named) that contains the same thing as your file did.   See: https://www.virustotal.com/gui/file/d0864f12625afab65a023d1231dd518113d0d867ac4e9d275d62636a9ef0696d/details

    When VT looked at an instance of that file - 11 hours ago - none of the 72 utilities they used thought it was infected.

    However, those results are all checks of the file itself.   EAM's Behaviour Blocker looks at what the file does when it is run.   Although the VT website lists some of the things that this program is known to do - files it opens, registry keys it sets etc (on the "Details" tab at the VT results page), neither you nor I have any idea what the Behavior Blocker didn't like.

    It occurs to me that this file is pretty small - only a couple of MB - so probably what it does is contact the Brave server and download the actual browser.  That might look a lot like a piece of malware trying to contact its command & control server.  On the other hand lots of installers do that sort of thing.

    I wouldn't take the risk - Crypto Malware is extremely bad news.  I think you will need to wait until someone from Emsisoft can say if the EAM warning is a mistake or genuine.


  2. Your screenshot looks ok to me.    The forensic log has one entry when a scan completes.  For example, one of your scans terminated at 13/07/2019 16:13:52

    It does make sense to show previous messages which said "in progress" because when they were issued, they /were/ in progress.   The "in progress" message is shown for/at past dates/times,  not for the current time.

    In computing, all logs show things afterwards that were happening at a prior time.   No-one ever writes a program so that it issues messages at the time, then afterwards goes back and changes the language to show that it is now a past event. 

    In your case the details display shows when that scan was started:

    - at 15:59:16  the scan was in progress doing one thing (la zone amorce)
    - at 15:59:16 the scan was then doing something else (the CSIDL_DRIVER line)
    - at 15:59:19 ie 3 seconds later it scanned memory
    - at 15:59:24 it scanned something?  "traces?" I can't quite tell BECAUSE THE DISPLAY NEEDS TO BE SCROLLED
    - if you scroll it down you will find, at the end of the list of detail messages, the one showing that this scan completed at 16:13:52


  3. I think you've misunderstood.   The entry in the forensic log tells you when the scan completed and what it found. When you click on that to get the detailed info you see a series of messages, of which you've highlighted initial ones.  That detaied list scrolls.  Scroll down to the bottom of it and you'll see all the status messages about that scan, including the final one.


  4. Hmm, dragging the grid - can't fully replicate that today.  I /can/ get the buttons off the bottom of the screen (move window as far up screen as possible by dragging second lowest pixel of window border upwards), then stretch grid as open as possible, then move window down so its whole title bar is visible as normal) but the window contracts a little as soon as it is then clicked on.


  5. Hmm.  I see that the grid part of that display has a draggable bottom-righthand corner.  Even with no files listed in the grid it's possible repeatedly to drag the grid size out a little more so that after a while the action buttons are not visible if one scrolls the display back up to the top.    If there's a reason why the grid can be dragged deeper than the screen, it might be more sensible for the buttons to be at the top of the grid and therefore always visible.


  6. Hopefully, as this problem appears to be reproducible, @GT500 will advise debug logs are created - to see why things are listed as being in the Quarantine, and also see why the option to delete is not then presented.  I wonder if the list of what is in the Quarantine is kept separately somewhere (and gets out of step with actual contents) or whether as soon as one investigates the Quarantine actual contents are summarised, in which case they really should be deletable...


  7. > ... and it happens when the notification window auto-closes, not when I manually close it

    That's interesting.  When I had this problem ages ago, I was always manually closing notifications, and I still do.  I have them all set to display for the maximum time (999 seconds) so very very few of them will automatically close - perhaps only if I've been away from the pc for ages.  And then I'd have forgotten precisely what I'd been doing.


  8. WIn 8.1 64bit, EAM 2019.5.0.9476

    I set up and started a custom scan, which would normally take about 45 minutes and scan about 1.2 M files.

    I wasn't watching the machine as it scanned; when I came back to it I found the scan screen saying the scan was complete, only 510 files examined, no report file available.

    I don't know how long that took, though presumably not very long.  Couldn't see anything in event viewer.   I'll PM the debug logs to @GT500


  9. Here (Win 8.1) such a file is shown as 0 bytes by File Explorer... but it's open to a2service, so I suppose what FE shows is misleading.  Sysinternals says:

    C:\Windows\system32>handle -a \temp\tmp

    Nthandle v4.21 - Handle viewer
    Copyright (C) 1997-2018 Mark Russinovich
    Sysinternals - www.sysinternals.com

    a2service.exe      pid: 9140   type: File          27E0: C:\Windows\Temp\tmp0000049d\tmp00000000

    C:\Windows\system32>

    and dir also shows it's empty

    C:\Windows\system32>dir /s "c:\windows\temp\tmp*.*"
     Volume in drive C has no label.
     Volume Serial Number is F607-7930

     Directory of c:\windows\temp

    11/06/2019  20:48    <DIR>          tmp0000049d
                   0 File(s)              0 bytes

     Directory of c:\windows\temp\tmp0000049d

    11/06/2019  20:48                 0 tmp00000000
                   1 File(s)              0 bytes

         Total Files Listed:
                   1 File(s)              0 bytes
                   1 Dir(s)  210,853,363,712 bytes free

    C:\Windows\system32>

     

    So... did something get unpacked into it,then removed, or what?


  10. > Perhaps I can send the debug logs ?

    Only if you had debug logging turned on before and during the problem.  Most users do not ever have it on because it can slow EAM down.   It also creates files which grow in size very fast...    You can check - the place where you'd choose to turn it on is at Settings -> Advanced -> Debug Logging. 

    • Thanks 1

  11. Win 8.1 64bit, EAM 2019.5.0.9476

    Every couple of weeks I run FRST64.exe, just so I have a set of its reports going back through time, for comparison with a current report, if I need it.  Today, having downloaded that file, I used File Explorer's context menu to ask EAM to scan it.  I have a 4 cpu, 8 core machine, and instead of getting a near-instant response, one cpu core went 100% busy - ie Process Hacker showed cpu at 12.5%.    After a quick look at it in PH, and restarting PH under Admin auth, I dumped a2service.    After doing that, EAM reported the scan complete.  I've since scanned an innocuous text file and also FRST64.exe again, both without a2service going mad.  I'll zip up the dump and debug logs and PM them to @GT500 .