rememberSiberia
-
Posts
21 -
Joined
-
Last visited
Posts posted by rememberSiberia
-
-
8 minutes ago, itman said:
Refer to this: https://help.eset.com/eis/14/en-US/idh_page_homenetwork_protection.html .
My understanding of this feature is scanning is performed once. Thereafter, it will inform of any new device connection being established. Obviously if you use it on a commercial wi-fi public network, you will be "bombarded" with connecting device notifications.
That's helpful, thanks. Is this scan 'fool proof' in the sense that no device is able to mask itself as hidden from such a scan?
-
3 minutes ago, itman said:
I will also add that a scan of for example a coffee shop public wi-fi network could also inform anyone attached to that network they are being scanned. This would make them aware of your device on the same network. They in turn could launch an attack against your device.
Thanks a lot for the explanation. That was my assumption as well, i.e. I would be effectively saying "Hey look at me, I'm scanning you". But again, my questions actually boils down to - having checked the list of connected devices in the router settings and having cross-checked against the devices actually running/on (they all match), is there a possibility that there are other devices (malicious) on the WiFi network which do not show up on the list of connected devices and therefore I will make them aware of my 'scanning presence' as you explained?
-
Thanks, Marcos. So in the case of this local/home WiFi network where assumingly all devices connected are known (again I am making this assumption on the basis of the list of devices connected to the router which I cross-verified against the MAC addresses - is this a correct assumption to make, i.e. a device cannot be connected AND hidden from the connected devices list?), it would be safe for me to proceed and run the Connected Home process? If yes, can I leave the connection as Public or will ESET force me to switch it to Private/Known first?
-
Hello,
Could someone please explain the reason for why it is dangerous to perform Connected Home scans on networks not marked as "Home" / "Private"? I am visiting close relatives and am using the WiFi as a "Public" network to be on the safe side. The WiFi password is not being shared with anyone and is strong/secure, so as a baseline assumption only those in the house are connected. I would like to use ESET Connected Home from my laptop to perform a scan on the WiFi network to see if there are any vulnerabilities that I might have missed. I already checked the router settings, and everything to my (limited) understanding looks secure (UPnP disabled, all possible firewall options enabled etc.)
What happens if I do perform a Connected Home with the network marked as "Public"? Wil my laptop send information to a potentially unsafe device on the network (which I might not know about) and compromise my laptop's security? As a side point, I checked all connected devices via the router settings and it lists all the devices that I can identify by MAC address (TV, smart phones etc.). Is it possible for someone to be connected to WiFi and not be shown in the device list at all?
Thanks!
-
Sorry what I said above is wrong. You can have both HVCI and Credential Guard enabled, as shown here in the middle of the page (screenshot from someone's MSINFO32):
-
4 minutes ago, itman said:
Yes. But that wouldn't be a factor.
However, Memory Isolation option may be. I have this also enabled. However as the MS article notes, all that is active on my device is the Key Guard feature.
I think this is the explanation (I might be wrong):
"So even if you had Credential Guard running and had LSA configured as a protected process, an attacker could manipulate process execution from within the kernel.
That’s not strictly true anymore with the introduction of Hypervisor-protected code integrity (HVCI), which is specifically designed to protect the kernel against tampering. HVCI works by adding a degree of separation and moving control of the system’s memory to a secure runtime environment created by the hypervisor."
It seems that HVCI supersedes Credential Guard, which is why I see "Hypervisor enforced Code Integrity" in MSINFO32 instead of "Credential Guard" (as detailed in the guide via the link that you provided - huge thanks again).
-
9 minutes ago, itman said:
There's also another possibility why you're not seeing any path info for lsalso.exe in your Process Explorer output. Note the following:
That is Credential Guard is activated on your device. Read the entire article for various ways to verify if Credential Guard is installed and operational. If not, the following paragraph might be the reason.
I do know in recent years Microsoft has implemented protection mechanisms on Win 10 that initially were only reserved for Enterprise versions. One might be to provide credential protection. This would be most applicable when the device conforms to other Microsoft security requirements such as it has a UEFI, TPM module installed, and Secure Boot option enabled.
Wow amazing thanks for sharing this. I think that's exactly my situation. Further down it also describes the Core Isolation functionality, which I have turned on. Perhaps that's ultimately the reason why LsaIso's details are blank. Do you have Core Isolation turned on?
Also, since I have Core Isolation turned on and LsaIso details are blank (as explained this is evidence of VM being turned on, at least one of the two methods to check), then do I need to turn on Virtualisation Based Security in the Group Policy editor?
-
15 hours ago, itman said:
Here's a way to settle your concerns about lsalso.exe .
1. Open Win Task Manager.
2. Mouse click on Processes.
3. Find lsalso.exe and right mouse click on it.
4. Mouse click on Open File Location.
If lsalso.exe is shown in C:\Windows\System32 directory, I would say the path issue is resolved.
Thanks for this. Confirmed the location.
-
1 hour ago, itman said:
It doesn't work that way. If you select the VT submit option, PE will only submit unknown files. I don't believe that's the case here, but you can give it a shot.
Note: if the VT scan option is enabled in PE, all files are being scanned with results shown in a column as my screen shot shows. If the detection rate for lsalso.exe is 0/71 or 1/71, assume the file is clean. I would also assume it's located in C:\Windows\System32 directory.
Again - here's the bottom line. As far as I am aware of, lsalso.exe is not being used for anything unless WD Application Guard is enabled.
Will give it a try thanks. Forgive me, if I am slow to comprehend, but since you are not using Win 10 Enterprise and have WD Credential Guard disabled (I assume this, since you said that you are running the Home version) and neither am I, then why do you suppose that you can see the full description of the process (name, path etc.) and I cannot, assuming that this is in fact a legitimate process on my end (in Live Grid / PE)? My premise is that for the purpose of WD Credential Guard, as you explained very thoroughly, our two systems are alike, so if in my case LsaIso were virtualised (which it isn't), that would be the reason why I would not be able to see the path (and any other details), right?
-
Alright thanks... still a mystery. I noticed that you linked Virus Total to your Process Explorer. I haven't yet. Would you suggest me to link it and submit the results to Virus Total?
-
Thanks so much for your continuous help. May I ask if you are on Win10 Entperprise, in which case that is why you can see the path and I cannot? Otherwise, do you have any clue as to why I cannot see the path (nor any other details)?
-
20 minutes ago, itman said:
Yes. And the question remains why Eset is misnaming it. Personally, I take anything shown in Eset Running processes "with a grain of salt." Both Process Explorer and Win Task Manager show the process name, lsalso.exe, correctly.
Thanks for your responsiveness! Could you please tell me whether in Process Explorer you can see the path of LsaIso? As mentioned above, mine says [Invalid access to memory location.], and that's the only one for which I can't see a path, even with Admin rights. The PID in Process Explorer matches with that in Live Grid, and I can see the path from Live Grid (even though the name is uncapitalised), so I just want to close the loop on this issue and move on (hopefully), if that's not just in my case.
-
28 minutes ago, itman said:
For some strange and unknown reason, Eset's Running Processes display is showing the wrong process name for lsalso.exe. It shows it as lsaiso.exe. There is no process named lsaiso.exe in C:\Windows\System32 directory:
Yes, in my case the PID in Live Grid and Process Explorer match (both 640 in my case). The difference I see is that in Process Explorer the name is capitalised, i.e. LsaIso, whereas in Live Grid it is not, i.e. lsaiso. Is that then the same process? So my question is... can malware hijack the PID number and pose as the same process, or would malware have a different PID (even though the name would be the same)?
-
I just ran it as Administrator, and now all paths are showing properly. Thank you!
Just one item that I do have a question on. LsaIso.exe’s path is [Invalid access to memory location] and there is no description or company name. I checked online and this is part core isolation if I am not mistaken (I have this enabled in the security settings). Is my understanding correct that this is not an issue, as it is purposely isolated from Process Explorer given the isolation, i.e. not even the explorer can recognise it even with Admin rights?
-
Sorry one more question while we are on Process Explorer. I noticed that similarly to this process where no Application Name is shown when I check these processes some of them say “Error: Path not available”. Do you also have these occurences in your Process Explorer? All of these are sub processes of what seem to be legitimate Windows processes, but I’m not sure. Thank you!
-
It looks exactly the same in my Live Grid (blank Application Name, 6 months ago, the same number of users and reputation), however I also do not see any Details, which is hidden on your screenshot.
I also ran Process Explorer and it looks just like on your screenshot, except for the PID (it matches with my Live Grid PID).
Is it safe to assume that this is not an issue/malware?
-
I am not sure how I can provide this file, as I cannot locate it. There is no path, and I do not see it in the running processes or services list. What would you suggest to do?
-
Hi all,
I noticed that the following application: startmenuexperiencehost.exe although with a high reputation and user count does not have an Application Name in ESET Live Grid (all other running processes have one and have high reputations and user counts).
Also, the "Show Details" section for it is completely blank, i.e. no Path, Size, Description etc.
I cannot find the process in either the Processes or Services tabs in Task Manager, even if I search by the PID from Live Grid or by the process name.
Is this normal or should I be concerned that this is not in fact a legitimate process?
Thank you!
-
3 minutes ago, Marcos said:
This was also reported here:
https://forum.eset.com/topic/28960-web-cam-access/
The issue is currently being investigated.
Thank you, Marcos! Could you please tell me where I would see an update on this specific issue? Would it be posted in the topic that you linked?
-
Hi everyone,
I think with the recent update I am receiving notifications whenever I log onto specific sites that Google Chrome is attempting to access my webcam. I'm not sure how this is possible, since I disabled the webcam access completely in the Chrome settings. What is causing Chrome attempting to access my webcam?
Thank you!
Win Update Fiasco
in ESET Internet Security & ESET Smart Security Premium
Posted
Hi, I just had this flagged by my Eset too. I have selected the “clean” option. Is there any other recommended action please? Thanks!