Jump to content

itman

Most Valued Members
  • Posts

    12,260
  • Joined

  • Last visited

  • Days Won

    322

Posts posted by itman

  1. 1 hour ago, Marcos said:

    3, Windows update should install it alright once it's not detected / blocked. Still, it's just a hunch that it was Windows update that generated the file.

    I think that is a good assumption. On my Win 10 build for example, ntoskrnl.exe was updated as a result of the 4/9 cumulative update.

    Whether the file deleted in C:\Windows\WinSxS\Temp could cause a blue screen is debatable. The only way I see this happening is if C:\Windows\System32\ntosknrl.exe was deleted in the Win Updating processing and the file in C:\Windows\WinSxS\Temp was its replacement. Since Win Updating is performed in isolated off-line fashion, I really don't see how Eset in any fashion could have deleted the file prior to full completion of Win Updating processing. However Win Updating on Win 7 is "pretty primitive" compared to that done on Win 10, so anything in this regard is possible.

  2. 1 hour ago, borislj said:

    It is ok for me if the eset service is running and icone is still available among hidden icons so that i can open eset console. Is there another way to control eset functions if the eset servise is running but there is no icone ?

    On the Win 10 desktop toolbar, click on the up arrow sign located on the right hand side. This will show all hidden icons. Then drag the Eset icon down to the desktop toolbar; best place is preceding the Windows Security Center icon. From this point on, the icon should show on the desktop tool bar at system boot time.

  3. What I read on the web is that directory is used by both installers and Win Updates as basically a work directory during their respective processing. Also, both are supposedly responsible for cleanup; i.e. deletion of files in that directory.

    Note that the last Win 7 cumulative update was pretty much a mess for a lot a devices. You will have to submit those files to Eset for analysis before a definitive verdict can be rendered if they are truly malicious.

  4. ASUS Updates Security Certificates of Motherboards, Graphics Cards, Mini PCs, Workstations and Servers

    Quote

    ASUS is releasing this advisory to provide information related to the new implementation of a tiered certificate structure that upgrades the security infrastructure of our expanding software ecosystem. The upgrade requires the current code-signing certificate of several ASUS products to be revoked. This revocation can cause some existing software utilities to trigger a Windows Security dialog box, and may prevent legitimate ASUS programs, such as Aura, AI Suite III, GPU Tweak II and others, from running normally when users attempt to execute the associated 'Setup.exe' or 'AsusSetup.exe' file.

    The new versions of each ASUS software update, code-signed with a new digital certificate are now available for download at the link provided below. Once the latest version of the respective software is downloaded, the relevant program can be installed and run normally. Further information can be found in the Advisory FAQ section below. Users who have any inquiries or concerns are welcome to contact ASUS Customer Service. ASUS apologizes for any inconvenience caused by this update.

    Updated Software List
    Download links for each software program can be found here: https://www.asus.com/latest-software-update/

    https://www.techpowerup.com/254629/asus-updates-security-certificates-of-motherboards-graphics-cards-mini-pcs-workstations-and-servers

  5. As I recollect, it has been a while since I was using Win 7, Eset's splash screen was a bit irratic in its display.

    Since I have been on Win 10, the splash screen in the last couple of Eset vers. has always appeared after Windows Security Center initializes at system boot time. It's display at sign-on time after prior sign-off is a bit irratic; sometimes it shows; sometimes not.

    What @cyberhash stated is applicable especially on Win 7. That is in a slow boot initialization with absence of Windows Security Center, Eset has fully initialized prior to the desktop appearing. Hence the lack of the splash screen. 

  6. Here's an Eset knowledgebase article on the subject: https://support.eset.com/kb2915/?locale=en_US&viewlocale=en_US

    You should have paid attention to the option to "Save scan logs." That would have enabled you to refer to the log where the source location for the quarantined file was located. Additionally , the Quarantine section would have also shown the source location for the file.

    At this point, it appears your only option is to perform manual searching in directories where the installer was initially downloaded to; most likely C:\Users\xxxxx\Downloads directory. 

  7. Connections to 195.201.191.2 are definitely related to Eset forum web site. Appears to be related to some type of capcha processing it's using; perhaps in conjunction with Cloudfront. The IP address shown in the below screenshot also equates to German same cloud server but this time in Germany. As long as I only see 195.201.191.2 in use by Eset forum, I am not going to worry about it anymore.

    Eset_keycaptcha.thumb.png.a702fa8e541c4a858c3cea25053ebc4e.png

    Newer and slightly different variation:

    Eset_capcha2.thumb.png.fddc332fa061798c8a2fdc10627fbb05.png

     

  8. 7 hours ago, Marcos said:

    It turned out that this was already fixed in the firewall module 1387 which was put on pre-release update servers  about 2 weeks ago. You can switch to pre-release updates in the advanced update setup to get the latest modules instantly.

    Verified via manually connection to Windows Store that the IDS "Incorrect Ethernet Packet" detection has been eliminated.

    Also as a "bonus," I now have Eset deep behavior inspection module.

    How about a "heads up" notification when firewall module 1387 is released so I can switch back to normal update mode.

  9. 20 hours ago, itman said:

    Such a mode would auto create all the new rules for the app and prevent existing HIPS rules from interfering with the installation. The only alternative with Eset's HIPS is to either switch to Learning mode again prior to installation, or manually respond to each alert generated by the installation when Interactive mode is in effect. 

    Also I was in a rush yesterday and didn't state the above correctly.

    What was the case in HIPS's "of old" was that Installer mode temporarily disabled the HIPS. And it was used under the category of "Trusted Installers." In other words, those that were properly signed by trusted publishes. BTW - I believe Comodo's HIPS, Defense+, has this feature.

    Obviously, disabling Eset's HIPS is strongly not recommended since "a bunch" of other Eset protections are dependant upon it including self-protection of Eset. Additionally, a system restart is required to disable Eset's HIPS.

    Finally, you really don't want to run Eset's HIPS in Learning mode when performing installs since it will just allow any malware present to be auto allowed. This leaves Interactive mode as the only viable alternative. And one must have detailed security and system operation knowledge to be able to indentify any malicious actions being performed by the installer. 

  10. 9 hours ago, kamiran.asia said:

    D:\Inprogress\Cleaning\Software\Software\BT101_SR4_2961_UL_Honeywell.exe - Win32/Parite.B virus - cleaned

    BT101_SR4_2961_UL_Honeywell.exe  Size is 180 Mb , After Cleaning 1.41 MB  😐

    Same for 3 other infected exe files , We Try cleaning by Other Vendor and the result is Clean file with 180 MB Size.

    Or ………. The other AV solution didn't actually "clean" the files since before and after file sizes are identical.

    -EDIT- Appears that .exe is indeed approx. 180 MB: https://www.reasoncoresecurity.com/bt101_sr4_2961_ul_honeywell.exe-987c1e38f192b1be390e5c46b61309b99d8c1f4e.aspx

  11. 5 hours ago, Marcos said:

    Unfortunately, we have no clue why it would have done so, however, it won't do any bad if it's there.

    No, I certainly didn't add it.

    Also, not so sure on the "won't do any bad if it's there."

    Part of the browser SSL protocol handshake is for the web site server to download its Root CA certificate issuing cert. to the browser's Intermediate CA store for validation purposes. Also and obviously, IE11 will initially populated its Intermediate CA store with what exists in the Win Intermediate CA store at browser startup time. As I see it, Eset's root CA store certificate should only reside in the Win root CA certificate store since it is only used for internal decryption purposes. 

  12. 5 hours ago, Peter Randziak said:

    On some systems ekrn is used as a proxy to be able to scan the traffic so it may be attributed to it than.

    I believe this might be part explanation since I was blocking connections to that IP address at the time.

    Here's the issue. Connections to that IP address started showing up yesterday in ways that didn't look just right to me. BTW - I am running Win 10 x(64) Home 1809 fully patched.

    Well low and behold, today when I start IE11 and immediately browse to the Eset forum web site, the same IP addresses show again. The port 443 connection is OK since it shows Eset is performing SSL scanning on the packets.

    Perhaps this connection is related to Eset's web site Cloudfront usage? 

    Eset_Russia.thumb.png.16b507ac4282d60e7efb8d2a4a998a57.png

  13. 1 hour ago, Pierrot said:

    If I understood well, the safest mode, would be the policy-based mode because It would block everything else than described by the rules. Correct ?  But what if something is blocked ?  Is there any risk of damage in my computer ?  Will I get a notification ?  Will I have a chance to create a new rule to allow the behavior or not ?

    In Policy mode, process activity will be blocked for which no existing allow rule exists. You will not receive a notification of the blocked activity. This mode is only suitable for installations where no type of system or app update activity occurs.

    1 hour ago, Pierrot said:

    If I choose the smart or the interactive mode, will these modes refer to the custom rules created by the learning mode or not ?  When I get a notifcation, will I have a chance to create a new rule to allow the behavior or not ?

    In Interactive mode, process activity will  alert for which no existing allow rule exists. You will receive a notification of the attempted activity at which time you will be able to create a permanent HIPS rule for the activity.

    As explained, Smart mode is just an enhancement of the default HIPS Auto mode. In either of these two modes, all existing and prior created HIPS rules are in effect.

    Note: Eset's HIPS is not a "user friendly" HIPS. By that, I mean it doesn't have features like some older HIPS software had such as an "Installer mode" one could switch to when installing new app software for example. Such a mode would auto create all the new rules for the app and prevent existing HIPS rules from interfering with the installation. The only alternative with Eset's HIPS is to either switch to Learning mode again prior to installation, or manually respond to each alert generated by the installation when Interactive mode is in effect. 

  14. @Marcos Since this "Incorrect Ethernet Packet" IDS detection is being triggered on TCP packets, Eset should be reviewing TCP Flag setting on the packets from Microsoft associated servers. It may very well be that Microsoft has started using a new flag setting that Eset is erroneous detecting.

    Another possible Eset misidentification:

    Quote

    TCP desynchronization

    TCP desynchronization is a technique used in TCP Hijacking attacks. It is triggered by a process in which the sequential number in incoming packets differs from the expected sequential number. Packets with an unexpected sequential number are dismissed (or saved in the buffer storage, if they are present in the current communication window).

×
×
  • Create New...