Jump to content


Most Valued Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by itman

  1. Based on what is posted below if TPM Mode in Policy setting was set to "Must use TPM" and there was an issue with TPM, encryption will fail. There might be a firmware or other issue with the TPM chip/module being used. You can try setting Policy TPM Mode to "Use TPM if possible" and see if that allows encryption to proceed. Ref.: https://help.eset.com/efde/en-US/policy_encryption_options.html Trusted Platform Module Support Policy setting Description Use TPM Enabling the use of TPM will initialize and take ownership of the Trusted Platform Module (TPM). It is your responsibility to ensure that the TPM is not being used by any other software, as this can result in data loss. TPM Mode •Use TPM if possible - Encryption process will attempt to use TPM for the encryption. If the TPM version is not supported or TPM is not present, encryption will continue without TPM. •Must use TPM - Encryption requires TPM. If TPM is not present or it is running in an unsupported version, the encryption will fail to start.
  2. This has absolutely noting to do with network traffic originating from the router. There are connections for these obviously previously created on the router. Otherwise, no Internet traffic could be routed to them. Assume one or both of these connection setups within the router have been hacked in some fashion allowing the hacker to direct his inbound traffic through them. As far as the GRC Shield Up test goes and to begin, it only tests ports 0 - 1055 by default. It also only tests unsolicited incoming traffic on those ports. If the router has been internally hacked or has an unpatched/unknown firmware vulnerability, this test is worthless for all practical purposes.
  3. Here's the issue in a nutshell. All the major browsers; Edge, Chrome, and Firefox, will deny a HTTPS connection using a SHA1 certificate. So as far as browsers go, this Eset root certificate SHA1 problem is non-applicable. The problem is Eset is currently filtering all HTTPS communication. So Eset has two choices here. Fix the issue or stop filtering HTTPS communicating other than for the browser. Otherwise, Eset will again find itself highlighted in the next research publication on AV's performing insecure SSL/TLS protocol filtering.
  4. My recommendation in regards to Huawei routers is if you must use one; e.g. ISP requires it, is to do the following. Purchase a secure router w/firewall, NAT, and statefull inspection features to handle your local network traffic. Then connect the Huawei router to the purchased router setting the Huawei to bridge mode to the purchased router.
  5. Huawei routers and overall all products associated with the company have numerous security issues and vulnerabilities. Their routers have been banned from sale in a number of countries: https://www.theverge.com/2019/4/30/18523701/huawei-vodafone-italy-security-backdoors-vulnerabilities-routers-core-network-wide-area-local . Since 2007, there are 536 recorded vulnerabilities with their products: https://www.cvedetails.com/vendor/5979/Huawei.html .
  6. Correct. Badssl.com point is they used a hacked SHA1 cert. to attempt to exploit this vulnerability as an example of the seriousness of the issue. The fact that CVE-2020-0601 was employed overall is irrelevant to the main issue.
  7. LiveGrid shows good Reputation status; i.e. green status, based on a number of factors including app code signing certificate, Trusted Publisher, number of Eset users, and heuristic analysis statuses. Yellow color just indicates that one of the previous statuses are not at the level to warrant a good status ranking. Red colored status on the hand, indicate risky processes. Eset Reputation status ranking has absolutely nothing to do with the hardware installed in your device. Ref.: https://help.eset.com/eis/13/en-US/idh_page_cloud.html
  8. I would first check if this Google app has been installed. If so, you can remove it as follows: https://support.google.com/chrome/answer/1649523?co=GENIE.Platform%3DDesktop&hl=en
  9. As long as you have the patch, you can't be at least exploited by this SHA1 vulnerability.
  10. There might be an issue here in regards to non-Win 10 and Windows Server 2016/2019 Eset users. Or, anyone who hasn't applied this update patch. Appears the stand-alone badssl.com SHA1-1024 Intermediate root certificate test creates an interesting Win Event log entry shown below. Microsoft patched this exploit in late Jan., 2020 for Win 10 and Windows Server 2016/2019 systems. Don't know if the same applies to Win 7 since it was end-of-life by then. Possible detection of CVE: [CVE-2020-0601] cert validation Additional Information: CA: <Microsoft ECC Product Root Certificate Authority 2018> sha1: 06F1AA330B927B753A40E68CDF22E34BCBEF3352 para: 06052B81040022 otherPara: 30820157020101303C06072A8648CE3D0101023100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFF0000000000000000FFFFFFFF307B0430FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFF0000000000000000FFFFFFFC0430B3312FA7E23EE7E4988E056BE3F82D19181D9C6EFE8141120314088F5013875AC656398D8A2ED19D2A85C8EDD3EC2AEF031500A335926AA319A27A1D00896A6773A4827ACDAC73046104C711162A761D568EBEB96265D4C3CEB4F0C330EC8F6DD76E39BCC849ABABB8E34378D581065DEFC77D9FCED6B39075DE0CB090DE23BAC8D13E67E019A91B86311E5F342DEE17FD15FB7E278A32A1EAC98FC97E18CB2F3B2C487A7DA6F40107AC023100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7634D81F4372DDF581A0DB248B0A77AECEC196ACCC52973020101 This Event is generated when an attempt to exploit a known vulnerability ([CVE-2020-0601] cert validation) is detected. This Event is raised by a User mode process. In regards to CVE-2020-0601: https://securityaffairs.co/wordpress/96414/security/microsoft-cve-2020-0601-flaw-nsa.html
  11. Correction - this is not a cipher issue but an Eset root certificate issue. Looks like it still accepts SHA1-intemediate certificates. Can be verified by disabling SSL/TLS protocol scanning. Then the badssl.com SHA1-intemediate test passes.
  12. BTW - %AppData% is not the only startup location malware can write to but also, C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\ . However, this directory takes a bit more work due to permissions issues. But a UAC bypass should do the trick. Then there are the multiple of registry run keys ..................................
  13. Works for me: If you have coded this, %APPDATA%, in the rule, replace it with, C:\Users\XXXXX\AppData\Roaming\..............
  14. Are you monitoring write activity to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.*? If you're monitoring program startup activity, none be detected for a .lnk file since it is just a shortcut to the actual .exe location. Also if your monitoring write activity to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.*, you have to allow write activity to hidden OS .ini files there. Finally, you just can absolutely block anything written to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.* since legit apps and even the OS may do so although I have yet to find anything that does other than the .ini files mentioned.
  15. We discussed this previously via PM. First, you can't create a HIPS rule blocking for example, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.* because there are legit hidden files in that directory that the OS constantly updates.
  16. So how did this malware pull this off? Ref.: https://fileinfo.com/extension/zone.identifier
  17. Personally, I am tired with what I am seeing here. Sometime ago, I performed my own testing in regards to Eset's monitoring of %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup. I created a .lnk reference to an .exe which BTW is the oldest trick "known to malware mankind" that ran w/o issue. I subsequently had a long PM conversation with Eset about this to apparently no avail. Now I do monitor write activity to this directory via Eset HIPS rules. But in some convoluted fashion since the "stone age" HIPS won't allow me to do so properly by wildcard specification; e.g. *.lnk, etc..
  18. Here's the Hybrid-Analysis detail on it: https://www.hybrid-analysis.com/sample/4cd23a989a8f196b1f49e5e66c6ecfa0cebf63f04950ae4d64127aaedda9e89c?environmentId=120 . It's writing the following to the startup directory, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sentinelone.scr. Suspect this trashes the MBR at boot after forced shutdown. Also there's an an outbound connection. So assume a remote download payload. -EDIT- Yes, sentinelone.scr performing outbound connection: https://www.virustotal.com/gui/file/4cd23a989a8f196b1f49e5e66c6ecfa0cebf63f04950ae4d64127aaedda9e89c/behavior/VenusEye Sandbox
  19. As far as MBR modification by malware, it's time Eset takes a look at incorporating Cisco's MBRFilter code which is open source at Github. An alternative is to backup the MBR at Eset installation time. Then provide a Tools option to restore it when needed.
  20. No, because it is used legitimately by the OS and apps. Additionally if you want to verify a cert. chaining path, the OS will dial-out to the cert. originator web site for verification. This is because not all certs. reside in the Window CA store.
  21. Also there is a flurry of Wiper malware currently floating around: New Wiper Malware impersonates security researchers as prank https://www.bleepingcomputer.com/news/security/new-wiper-malware-impersonates-security-researchers-as-prank/ And these will most definitely bork your OS installation: So be very careful with anything you download. Which again gets us back to Reputational scanning ..............
  22. MITRE has a list of known malicious attack methods deployed using CertUtil.exe and associated APT groups using them here: https://attack.mitre.org/software/S0160/ . Of note is it can also be deployed to install a root certificate in Window root CA store allowing the attacker to perform a man-in-the-middle attack against encrypted communications.
  23. A few more comments here. If pings; i.e. echo request, are being recorded on a local network device, your router firewall is either not correctly configured or deficient. These pings should be blocked within the router's WAN interface. If your posting is a result of performing some web based port scanning site test such as Gibson Research Shields Up test, the test is being performed against your router's ports including those used ICMP echo request. The test per se is irrelevant in regards to verifying current Eset firewall configuration.
  • Create New...