itman
-
Posts
12,164 -
Joined
-
Last visited
-
Days Won
319
Posts posted by itman
-
-
11 hours ago, Ming Chou said:
however it looks like that the client connects through IP address(52.160.70.199) and not DNS name(edf.eset.com).
How can we make sure the clients are connecting through DNS name and not IP Address?
Reflecting on this statement, the only way I can think of for this type of behavior is the client modified his Windows hosts file and entered;
52.160.70.199 edf.eset.com
Host file entries override and bypass DNS processing.
Why he would do this is beyond me.
-
Going through the multiple Wi-Fi connection problems in the forum, the only solution to the issue posted was;
QuoteStill, the root of the problem was the mac address. Later, by trial and error when I found out about it, I talked to a senior employee of the Internet provider and only he confirmed the information that I need to register a fake poppy address in my personal router (I don’t use the provider’s router).
none of the other employees by phone or those who came to my house, to replace the ONU equipment (converter from optics to ethernet) , they did not talk about it, everyone was leaning towards a bad wi-fi connection
The first randomly generated mac address did not work (there were problems), it turned out with the second one. Everything is fine now, there are no mistakes. What I understood from the conversation is that there is some kind of binding by mac addresses...(long story). There were no such problems on the old provider, but on the new one, they appeared immediately.
-
I ran tracert edf.eset.com and the final connection was to 52.160.70.199.
Next, I ran DNSChecker for edf.eset.com and all DNS resolutions world-wide were to IP address 52.160.70.199;
As such, whatever DNS resolution issues you are having are on your end and nothing to do with Eset.
-
-
5 hours ago, Ming Chou said:
however it looks like that the client connects through IP address(52.160.70.199) and not DNS name(edf.eset.com).
Per Robtex, edf.eset.com resolves to the following IP addresses;
-
As the article states, Driver Verifier utility analyzing epfw.sys might be able to shed additional info on what is going on here.
In this article: https://answers.microsoft.com/en-us/windows/forum/all/bsod-kernel-mode-driver-attempted-to-access/dc240524-45d9-4219-bd03-184b2725953c , an update of PC manufacturer motherboard chipset drivers fixed the problem.
-
Some further info on why encrypted VHD recovery might be "an effort in futility."
From a May, 2023 Secure Data forum posting;
QuoteESSP Secure Data creates an encryption 'keystore' file called 'premiumkey.dat' in C:\Users\USERNAME\AppData\Local\DESlock+\
If you delete this directory and the files within, then the encryption key is no longer available and your encrypted USB cannot be decrypted or accessed. Re-installing ESSP and enabling Secure Data will generate a new keystore file, which will NOT work for anything encrypted with a different key.
If we're lucky, and you still have the directories and files you deleted in the Recycle Bin, then you should be able to restore them and access your USB stick! If not, perhaps you have a Windows backup that you can restore where the DESlock+ directory and files are intact and can be restored to regain access to your USB.
Failing this, the data on the USB is inaccessible and you will need to format the device for future use.
I checked for this same folder on my device and it does exist. So it appears it is also created when a VHD drive is created.
Since the OP installed a new boot SSD and reinstalled Windows, this original Secure Data keystore folder no longer exists. Therefore even if it was somehow possible to associated the old VHD .eed file with the current Eset Secure Data installation, it would be impossible to decrypt those files. If there was a full backup of the old boot SSD taken prior to drive failure, it might be possible to restore the keystore folder from that.
Finally, Deslock+ documentation clearly states the this "keystore" folder needs to be backup to external media for just this event occurance; something Eset documentation is silent on.
-
Your hosts file is fine.
At this point, I have no clue what G-Data was detecting on the VT scan. Your TCPView screenshot shows a number of processes using 127.0.0.1 among them are Discord and Teamview. Both are known to contain vulnerabilities in other than most current versions. You could start by verifying latest versions are installed.
-
39 minutes ago, AlSky said:
but they say the version 17 will be released only in 2024
Not so according to Eset publication;
-
-
To get to the bottom of this, here's what I did pain in the butt it is.
I activated Secure Data and created a virtual encrypted drive on a non-boot HDD I have installed. Verified I could access it via password and that the drive loaded into Win Explorer.
I then exported my existing Eset settings.
I then uninstalled ESSP. While the uninstaller was running, I saw Secure Data roll by. Oh-oh. Sure enough, when ESSP was uninstalled, all traces of the previously created VHD were wiped from the HDD it was previously installed on. I will continue, but this in itself is enough to state that any VHD created by Secure Data option is 100% dependent upon the current Eset installation.
I then reinstalled ESSP and imported my previously exported settings. Secure Data was still showing as never setup after settings import completed.
"I again say to thee", yes the OP new system shows that an existing old installation VHD exists on his non-boot SDD. But as far as his current ESSP installation on the new system is concerned, this VHD doesn't exist. It is in effect an "orphaned" VHD. Unless Eset developers can come up with a way to associated this old VHD with the current ESSP installation, it will remain inaccessible.
-
You're talking "apples vs. oranges" here.
SSL/TLS protocol Application scan rules relate to Eset Web Access protection and have nothing to do with the Eset firewall which is related to Eset Network protection.
Eset has posted previously in the forum that users are not to modify SSL/TLS protocol Application scan rules. These are maintained internally by Eset.
-
Based on your TCPView screen shot, you are using both Outlook and Thunderbird e-mail clients. Eset e-mail anti-spam processing only works with Outlook; not with Thunderbird.
As far as the VT detection, it's for localhost port 8080. Eset default firewall rules allow all traffic within computer; i.e. 127.x.x.x.. Check your Windows hosts file to see if has been modified.
-
5 minutes ago, Marcos said:
I've found only these 3, all purchased through the Hong Kong distributor Version2:
Appears OP is referring to the currently active NOD32 license.
Multiple past forum postings all refer to license purchases in U.S. dollars are forwarded to Eset N.A. for payment processing. As such, issues with the purchases must be resolved by Eset N.A..
-
7 hours ago, Guest Branko said:
but this year local EXCLUSIVE distributor in Croatia out of his own reasons refused to send an offer for payment stating "his company can choose with whome they work with"
Are you an Eset partner; i.e. value added retailer (VAR), associated with Eset Croatia LLC? If so, it appears they are terminating their business relationship with you.
-
33 minutes ago, iandev said:
but they said I have to ask the US ESET for a refund of US$118.98
Eset North America handles all Eset license purchases made using U.S. dollars. You can contact them here: https://www.eset.com/us/about/contact/ about this matter.
-
I believe you are referring to this registry key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
Malware will store there malware payload in this key for persistence purposes ensuring the malware always runs at system startup time. The point to note is the malware still exists on your system regardless if present in this registry key.
-
4 hours ago, Skier said:
To emphasise, again: I have Secure Data enabled
Pondering more, there is another possibility here and your not going to like it.
First, a clarification of what the .eed file is. It appears to be the Secure Data executable file. The file is used to access Eset encrypted data on a created VHD or removable drive.
When your old device crashed, so did the VHD and any data on it. Unless you backed up that data to external media prior to the crash, I am afraid it is lost. Or if your very lucky, the data still physically exist on the SDD. But I see nothing in the Eset Secure Data documentation this is the case. Also if the Eset encrypted files from the old system still exist on the SDD, there is no documented procedure on how to link those files to the new Eset VHD created on the new system.
Now if you instead had created Secure Data removable media drive, Eset would have created the data on that drive permanently. This is why it can be accessed again when Eset is reinstalled either on the existing device or a new device.
-
Let's "take it from the top" again starting with the very first statement in Eset Secure Data FAQ;
QuoteESET Secure Data is a new feature available in ESET Smart Security Premium that enables you to create encrypted directories on removable drives to protect against data theft in the event of USB flash drive or laptop loss.
https://support.eset.com/en/kb6266-eset-secure-data-faq#deleteVD
Next is when reviewing Eset product on-line help in regards to Secure Data processing are the repeated references to removable drives,
My take here is Eset never fully designed Secure Data to be deployed on internal HDDs. It does so by creation of a virtual hard drive. My assumption is VHD's are directly linked to the device OS where created. Installing the SSD on a new device/OS no longer has an Eset VHD relationship. Did you create a new Secure Data VHD on the new device specifying this SSD as the source? Also, this might not work in that all that is created is a new empty .eed encrypted folder for the new VHD on the new device I assume.
Also if you exported Eset settings prior to the old system crash that contained Secure Data settings and imported those settings after ESSP installation on the new system, the VHD might have been auto created w/o issue. But again, I am not sure this would have worked.
In any case, I believe you need to create a support request for this one.
-EDIT- Pondering a bit more.
The problem here is a way to replace the newly created empty .eed folder associated with the new Secure Data VHD on the new device with the old existing .eed folder created on your old device. This I have no clue on how to do or even if this is possible.
-
14 hours ago, Skier said:
@itman. Yep, I've read that and the 'if prompted' doesn't happen. I have found no way to enter the password to decrypt the drive.
ESSP Secure Data option is not a full encryption solution as exists in Eset commercial products.
It is set up primarily to encrypt removable drives. My guess here is Eset stores the decryption password somewhere on the removable drive.
"My gut is telling me" Eset never anticipated your scenario; using an Eset encrypted non-boot internal HDD in another Windows system.
Another possibility here is the SSD is either damaged or malfunctioning in some way. Did you run chkdsk on that drive? Better yet, the drive manufacturer test tool? You mentioned a catastrophic hardware failure with your old computer. It is within the realm of possibilities that could have impacted this SDD.
-
My take on this is if Eset can recognize the encrypted drive per below;
QuoteTo access the encrypted drive after restarting the computer, locate the encrypted drive file (.eed file type) you created and double-click it. If prompted, type the password you configured when creating the encrypted drive. The drive will be mounted and appear as a local disk under This PC. When the encrypted drive is mounted as a local disk, the local disk and its decrypted content are available to other users on your computer unless you log out or restart the computer.
https://help.eset.com/essp/16.1/en-US/enc_intro.html?enc_encrypted_virtual_drive.html
you're "good to go."
Recognition would be if Eset prompts for the password. The "gotcha" is since the password was created on another device, will Eset recognize this password on the new device?
-
23 hours ago, techpaulb said:
I have tried to follow [KB2939] Exclude an IP address from IDS in ESET Windows home products (15.x – 16.x) but I don't have the zones this KB article talks about my layout of ESET is different to what is pictured in the KB article.
Looks like this KB needs to be updated to reflect ver. 16 changes.
Refer to the below screen shot. Enter Firewalla Gold gateway local subnet IP address as the remote IP address and that should work;
-
4 hours ago, Aurelie said:
This one : https://www.pigier-issec-toulouse.fr/
You have multiple JavaScript malware on this web site per Sucuri analysis: https://sitecheck.sucuri.net/results/https/www.pigier-issec-toulouse.fr/* .
If you can't eliminate the malware, a web malware cleaning entity such as Sucuri will clean the malware for a fee.
-
1 hour ago, Aurelie said:
My site is infected as well and no detection from imunify... thx
Contact Imunify since they are supposed to be protecting your web server.
ML/Augur Detections: not necessarily false positives
in Malware Finding and Cleaning
Posted · Edited by itman
There's a vulnerability in this software although it's rated low risk: https://www.cybersecurity-help.cz/vdb/SB2023091339 .
However, any vulnerability can be exploited. Might be an explanation for what happened here.
-EDIT- Vulnerability rated high risk here: https://nvd.nist.gov/vuln/detail/CVE-2023-3112