Jump to content

itman

Most Valued Members
  • Posts

    12,188
  • Joined

  • Last visited

  • Days Won

    320

Posts posted by itman

  1. If you're stating that Eset is somehow scanning your Epson USB attached printer, then I would say something is wrong with the way that printer is configured in Windows.

    I have a HP USB Laser printer  attached to my PC, and Eset never scans it at system start up time

  2. I am running Win 10 x(64) 1809 fully patched w/ EIS 12.1.34.

    I enabled pre-release updating to resolve the erroneous invalid Ethernet packet IDS detection issue which may or may not be also related to this speed issue.

    My speed tests are downright strange. The speedtest.net test shows a download speed of 26 Mbps and an upload speed of 33.45 Mbps - err, what? Verifying the previous test results, I tried my ISP, AT&T, speed test. The download speed was approximately the same but the upload speed was 43.4 Mbps - err, double what?

    I have never seen upload speeds like this; especially exceeding download speeds.

  3. 21 minutes ago, TomFace said:

    You also might want to review your pop-up setting in your browser.

    On this regard, I found IE11's popup blocker disabled after a screen locker like scam incident. It also took a bit of "finagling" to reenable it. I am still trying to figure out how the attacker could disable the popup blocker.

  4. 12 hours ago, John Ross said:

    Evening of 4/16/2019 I was attempting to update my Eset license from the Eset form when my computer taken over by some outfit I don't recognize.

    I am curious about the "Eset form" you mentioned. Where did this appear from? Was it a popup from your browser for example? In any case, you were obviously redirected to some scam web site. The thing to be established is how this happened. I don't believe the "form" you mentioned was generated from the existing Eset installation GUI.

    For future reference in the U.S., you should always renew from this web site: https://www.eset.com/us/renew/

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

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

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

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

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

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

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

     

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

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

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

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

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

×
×
  • Create New...