JeremyNicoll

Member
  • Content Count

    1551
  • Joined

  • Last visited

  • Days Won

    24

Posts posted by JeremyNicoll


  1. @GT500  - yes, I keep logging on all the time, so yes I would hope they explain why updates aren't being indicated.

    I still have a red systray icon, and the "Overview" pane is still orange.  I note that the text on that still says the last update was 2 days ago - one might have expected it now to say 3 days....

    The logs screenshot I made yesterday seems to show that updates are being logged properly and the detail view of such log entries (which I did check in several cases yesterday) looks as one would expect.  For example, the most recent one says:

    General Information:
     
    Version 2020.1.0.9926
    Connection: Direct
    Update started: 23/01/2020 09:03:17
    Update ended: 23/01/2020 09:03:26
    Time elapsed: 0:00:09
     
    Update successful
     
    Detailed Information:
     
    58 modules, 3218640 bytes
    a2hosts.dat (4545 bytes) - updated
    a2trust.dat (323 bytes) - updated
    a2wl.dat (382 bytes) - updated
    Signatures\20200122.sig (754 bytes) - updated
    Signatures\BD\e_spyw.cvd (261 bytes) - updated
    Signatures\BD\e_spyw.i00 (389 bytes) - updated
    Signatures\BD\e_spyw.i10 (333 bytes) - updated
    Signatures\BD\e_spyw.i12 (453 bytes) - updated
    Signatures\BD\e_spyw.ivd (377 bytes) - updated
    Signatures\BD\emalware.000 (24830 bytes) - updated
    Signatures\BD\emalware.412 (268 bytes) - updated
    Signatures\BD\emalware.420 (227 bytes) - updated
    Signatures\BD\emalware.421 (288 bytes) - updated
    Signatures\BD\emalware.422 (3313 bytes) - updated
    Signatures\BD\emalware.423 (5966 bytes) - updated
    Signatures\BD\emalware.424 (3550 bytes) - updated
    Signatures\BD\emalware.425 (298185 bytes) - updated
    Signatures\BD\emalware.426 (337252 bytes) - updated
    Signatures\BD\emalware.427 (38046 bytes) - updated
    Signatures\BD\emalware.428 (268986 bytes) - updated
    Signatures\BD\emalware.429 (303257 bytes) - updated
    Signatures\BD\emalware.597 (329 bytes) - updated
    Signatures\BD\emalware.598 (1203 bytes) - updated
    Signatures\BD\emalware.i02 (42515 bytes) - updated
    Signatures\BD\emalware.i05 (14212 bytes) - updated
    Signatures\BD\emalware.i06 (24019 bytes) - updated
    Signatures\BD\emalware.i09 (8673 bytes) - updated
    Signatures\BD\emalware.i10 (314 bytes) - updated
    Signatures\BD\emalware.i11 (19100 bytes) - updated
    Signatures\BD\emalware.i14 (276 bytes) - updated
    Signatures\BD\emalware.i16 (369509 bytes) - updated
    Signatures\BD\emalware.i19 (20163 bytes) - updated
    Signatures\BD\emalware.i22 (5978 bytes) - updated
    Signatures\BD\emalware.i23 (424594 bytes) - updated
    Signatures\BD\emalware.i24 (40643 bytes) - updated
    Signatures\BD\emalware.i25 (3429 bytes) - updated
    Signatures\BD\emalware.i27 (6569 bytes) - updated
    Signatures\BD\emalware.i31 (19698 bytes) - updated
    Signatures\BD\emalware.i32 (2020 bytes) - updated
    Signatures\BD\emalware.i38 (116682 bytes) - updated
    Signatures\BD\emalware.i42 (1449 bytes) - updated
    Signatures\BD\emalware.i44 (236 bytes) - updated
    Signatures\BD\emalware.i49 (3511 bytes) - updated
    Signatures\BD\emalware.i51 (30244 bytes) - updated
    Signatures\BD\emalware.i54 (5096 bytes) - updated
    Signatures\BD\emalware.i56 (125113 bytes) - updated
    Signatures\BD\emalware.i58 (6189 bytes) - updated
    Signatures\BD\emalware.i62 (105896 bytes) - updated
    Signatures\BD\emalware.i67 (136614 bytes) - updated
    Signatures\BD\emalware.i69 (45942 bytes) - updated
    Signatures\BD\emalware.i70 (6304 bytes) - updated
    Signatures\BD\emalware.i71 (14597 bytes) - updated
    Signatures\BD\emalware.i73 (284003 bytes) - updated
    Signatures\BD\emalware.i75 (16217 bytes) - updated
    Signatures\BD\emalware.i80 (24544 bytes) - updated
    Signatures\BD\emalware.i99 (265 bytes) - updated
    Signatures\BD\java.cvd (389 bytes) - updated
    Signatures\BD\update.txt (120 bytes) - updated


  2. Win 8.1, EAM 2020.1.0.9926

    I just noticed my EAM systray icon has turned red.  Looking at the overview screen I see that apparently the system hasn't updated for two days - see screenshot: https://www.dropbox.com/s/8s3rrekbvjeaabx/20200122 1250 partial protection.jpg?dl=0

    I'm pretty sure I've seen regular notification panes saying updates are happening.  And the forensic log seems to say so too: https://www.dropbox.com/s/ihf806q65qgglwg/20200122 1251 but log looks ok.jpg?dl=0


  3. > "I even turned DEBUG ON, but there is nothing interesting being logged"

    Did you disable debug logging afterwards so that the in-use sets of debug logs were closed (and new ones opened)?

    Also... unless you know what Emsisoft's code does, the meaning of return codes etc from their functions, I don't understand how you think you can tell what the flow of logic described in the debug logs actually means. 


  4. @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.


  5. 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.]

     

     

     

     


  6. Which exclusions list did you add the program & folder to?   The exclude-from-scanning one (no use), or the exclude-from-monitoring list (should work)?

    Also, has it recently worked alright?    If it has (in which case it suggests a recently-released version of EAM is the problem), you might be able to tell EAM to use the 'Delayed Feed' (ie an older version of the program) rather than the more-uptodate one.  You could try that by going to EAM's Settings - Updates - Update feed  and choosing "Delayed", then choose "Update now" from the systray icon menu.    If you do do this, as soon as you again reset the feed to "Stable" the newest version of EAM will again be installed.  Sooner or later Emsisoft will ditch whatever older version is on the "Delayed feed" and a newer version will replace it, so - if this change does sort your problem - it won't fix it for ever.


  7. @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. 


  8. 23 hours ago, jjfoto said:

    I have a new TP Link Deco. And there was a profile on it attached to my pc instead of another device. This profile apparently block some downloads.

    I don't know what "profile" means in what you describe - "an optional group of settings" perhaps?

    Google tells me that a feature of some/all Deco models is that it has built-in antivirus and scans all of your network's incoming and outgoing traffic.   


  9. > We keep this info visible until user checked the scan results.

    The blue dot was visible (along with the 100% thing) here, all through yesterday - and maybe today too (until the Beta just updated - now it's gone), but I checked the most recent Custom scan's report, as soon as the scan completed.   (Later: I suppose this was a series of blue dots after a series of context scans.  But it adds nothing to my knowledge.)

    There's no way, in English, that you can reasonably claim that "New scan" is synonymous with "Close".  "Close" means ending something whereas "New scan" implies starting something.

    Edited:  I just tried a context scan of a few files.  At the end of that, not having been told of any problems, the scan screen is displayed, saying "No suspicious files were detected during the scan."    What else am I supposed to do to get rid of the blue dot?  I have (a) not been told of problems /during/ the scan, and (b) been told there were no problems /at the end/ of the scan.  Even if I choose to "view the report" - for which there is no reason because guess what? - it lists no problems - the blue dot is STILL being shown.   


  10. With Win 8.1, and build 9915, I see exactly what Marko describes. 

    I do have separate 'Scan started' and 'Scan finished' log entries (eg for a custom scan earlier today of 1.4 million objects).  Context-menu scanning a smaller number of files - first a folder containing 100 or so, then just a handful of files selected from a folder view, and finally just a single file ... all each produce a pair of log entries.


  11. 7 hours ago, GT500 said:

    It's just a registry key for what we call a Potentially Unwanted Program (PUP). It's a subkey of WOW6432NODE, which is a system key that's used to store registry data for 32-bit applications as part of WoW64 (Windows on Windows 64). It's not a false positive, and it's safe to delete it.

    Doesn't the decision to delete the key depend on whether or not @Daniel Pipe has the software concerned installed (intentionally) or not?  


  12. If you mean "Auto-Silent mode" is being enabled/disabled, it's normal.  Silent mode is turned on when you have a program enter full-screen (ie not in a window) - which is most likely to be if you're running a game, or watching a video.  The point of Silent-mode is that in a game or video you are unlikely to want to have your game/video disturbed by notifications from EAM.

    You asked this question in the wrong part of the forum.  This part is for general discussions of Malware & Computer Security.  Questions about using EAM should really be in the "Customer Support" - "Emsisoft Anti-Malware Home" sub-forum.    


  13. Mobile phones ARE computers, computers one of whose programs pretends to be a (real) phone.   Various companies (including Emsisoft) produce anti-malware/anti-virus programs for mobiles.

    You can read a summary of what these various programs can protect you from.  Obviously iOS (Apple) and Android differ, and - as with PCs - there's several versions of each one's OS in use, and of course with Android some manufacturers supply variants on Android (ie not every Android phone is running the same OS).   That means that odd combinations of phone model, version of Android etc may mean there's exploitable loopholes in subsets of phones, even if most are ok.

    In theory Apple's phones are more secure, partly because there's only their version of iOS in use, and partly because Apple try to make sure that only reputable apps are available.

    You might find it useful to read: https://www.av-comparatives.org/tests/mobile-security-review-2019/

     

     

     

    • Like 1

  14. OK, thank-you for the information.  I'm trying to sort out in my head what the possibilities are.  First, can you tell me what precisely you mean by "streams the file to EAM"?

    My first thought was you meant some sort of "please test the data that's stored 'here' in memory" request (occurring before the file is saved), but since the (Eicar test files) are actually being written to disk I now think you mean simply that the browser saves the file then asks (via integration) for that file to be examined.   Is the "stream" terminology aspect significant?

    Fileguard-wise, you're saying that the action the browser has already taken, to save the file, means that (in my case with Fileguard being "thorough") EAM is separately being asked to look at the just-saved file via FileGuard?

    In the tests I've done here, my impression is that the FileGuard-triggered test, because it was caused by the save of the file, is being processed by EAM before the browser-integration examination starts. Is that always true, or are these examination requests handled asynchronously?    Would eg slow file-systems & a huge file ever mean the browser-integration check happens before the Fileguard/save one?


  15. 21 minutes ago, Peter2150 said:

    Again interesting, but didn't sound like a real life test.   Best solution for Ransomware is to never let it get near your system.   Hard, but not impossible by any means.

    Not a real-life test?   We weren't just trying to avoid ransomware, but also what we'd do if fire or whatever wiped out the building.  Do you think we should have burned down our primary data-centre first?   What more could we do to make it more real?  

    We did these tests to prove that we could: reconfigure the base hardware as needed, IPL a specially-built minimal OS, use it to restore initial ancillary system disk images (onto new disk drives - maybe in trucks in the car-park?) needed for a larger system, and as more and more of a restored system grew, the processes rolled outwards to the teams responsible for application data & backups, database support & eventually programming teams in each business area.  Likewise the operational depts needed to restore a schedule and start to run production work.    Outside IT, the business as a whole had to have a realistic appreciation of what the delays would be before each part of the business's critical services could be restored.  Back-of-an-envelope guesswork wasn't acceptable.  They had to know, and for that we had to test and prove how long each stage would take.  

    In occasional tests (when eg there'd been significant service applied to the OS, or a new version of a critical piece of software) and in any case at least twice a year,  the initial part of this test was done - which 'only' required exclusive use of one machine room overnight.  (That still required migration of normal workload and data away from that room beforehand, and migration back afterwards - itself a process that took a few days to achieve).    Migration of whole machine-rooms-worth of data used the exact same processes as data backup & recovery normally did, so we knew that worked. 

    Large parts of the overall process - eg swapping workloads between particular machine rooms - were done anyway every so often so that we didn't always run production from the same hall and dev/test elsewhere.   It was also done once per year per machine room so that rooms could be isolated for power-system safety tests (and note also that we occasionally ran the whole building on generators for a few days just to prove that that capability still worked properly.)   Hall swaps proved there'd been no oversight and that we no longer had necessary duplication, and the proceses before, during and after each test meant that there were lots of staff in each area who understood their area's role in the whole scheme.  Each machine hall had enough kit in it to run the whole business (that is, non-business-critical workload like giving the programmers a machine to develop & test code would be sacrificed in the short-term in a disaster).   Big, all-weekend tests involved many staff.  We still needed the ops, on-call etc staff to support the live systems throughout that period.


    You might want to ponder what sort of costs a company incurs when they set out to have not just one machine hall/building to run their business from, but more than twice that. (More because although we 'only' had duplicates of all the business-critical stuff, we also had tertiary copies of some things, eg a third robot tape silo in a vault under another building - that was planned before that building was built.)

    We also - despite being high-profile business rivals with another local company - had more of our kit in one of their machine rooms and they had some of theirs in a fenced-off section of our biggest one.   When tech developed to the point where it was possible to sync disk I/O across sites miles apart, we sometimes ran our production service out of their machine room.    

    Nothing about this was cheap.  It was designed, built and regularly tested by people who were not idiots.


    Your "not real life" comment reminds me of the common view that Y2K was a damp squib because nothing went wrong.   For us, Y2K planning took a bit under two years.  It was the single biggest project worked on in that period.  By the time the actual date change rolled around, we'd run simulations of "the moment" many times and we had test systems running test versions of our whole workload for weeks at a time, pretending to be at other significant date points - eg end of business year sometime in 2000, end of tax year, end of the following year's significant dates (as they'd be running year-end processes that harked back across the date change).   We were as sure as we could be that everything would be ok.  Even so, many staff (mostly the senior, on-call, most experienced ones - I suppose the same sort of mix of people as for the major disaster recovery tests - maybe a hundred of us in all ?) were at work when the moment happened, just in case.  I am certain that companies similar to us adopted similar approaches.