Jump to content

ESET Live Grid Blank Application Name / Details


Recommended Posts

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!

Edited by rememberSiberia
Link to comment
Share on other sites

  • Administrators

Please provide the file in question or at least its SHA1.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • Administrators

I got it. The fact that no detailed info is shown could be caused by the app being a system app installed in C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*.

image.png

The issue has been reported to developers for further investigation.

P_ESSW-13338

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • ESET Insiders

Are you running Process Explorer as administrator?

Post an example screenshot of the processes you are concerned about.

Link to comment
Share on other sites

Posted (edited)

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?

Edited by rememberSiberia
Link to comment
Share on other sites

1 hour ago, rememberSiberia said:

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.

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:

Eset_Lsalso.thumb.png.bc08413950ce9e1340863d5a76080ddf.png

Link to comment
Share on other sites

Posted (edited)
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:

Eset_Lsalso.thumb.png.bc08413950ce9e1340863d5a76080ddf.png

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)?

Edited by rememberSiberia
Link to comment
Share on other sites

3 hours ago, rememberSiberia said:

LsaIso, whereas in Live Grid it is not, i.e. lsaiso. Is that then the same process?

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

28 minutes ago, rememberSiberia said:

Could you please tell me whether in Process Explorer you can see the path of LsaIso?

Yes. See below screen shot:

Eset_lsalso.thumb.png.05fc4c6005df2d0e7d7f709d92581207.png

 

Edited by itman
Link to comment
Share on other sites

Quote

The Windows Defender Credential Guard is a feature to protect NTLM, Kerberos and Sign-on credentials. Windows 10 Enterprise provides the capability to isolate certain Operating System (OS) pieces via so called virtualization-based security (VBS). NTLM and Kerberos credentials are normally stored in the Local Security Authority (LSA). Once VBS is enabled the LSASS process will be split into an isolated process (protected by virtualization based security)  called LSAiso and the LSASS process. The LSAiso process can not be accessed by other OS components than the LSASS.

https://oliverkieselbach.com/2018/01/11/configuring-windows-defender-credential-guard-with-intune/

My take on the above is lsaiso.exe is the virtualalized version of lsalso.exe and you will only see it if you're running Win 10 Enterprise and using Windows Defender Credential Guard.

Edited by itman
Link to comment
Share on other sites

Posted (edited)

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)?

Edited by rememberSiberia
Link to comment
Share on other sites

Got it figured out. You're only going to get "bullet-proof" Win credential protection with use of Credential Guard:

Eset_Wininit.thumb.png.b0e071c5e342e8d24cabb4035699c453.png

Otherwise you get bogus credential protection. Bogus in that the following Win Event log entry implies Key Guard protection but no VSM-isolated keys were ever generated.

Eset_VSM.png.e042ac9ec013fe7ab4df4d3288921750.png

Link to comment
Share on other sites

1 minute ago, rememberSiberia said:

May I ask if you are on Win10 Entperprise, in which case that is why you can see the path and I cannot? 

No I am using Win 10 Home x(64).

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

16 minutes ago, rememberSiberia said:

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?

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.

Edited by itman
Link to comment
Share on other sites

Posted (edited)
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?

Edited by rememberSiberia
Link to comment
Share on other sites

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.

Edited by itman
Link to comment
Share on other sites

Found the problem.

There's a bug in Process Explorer. See below screen shot. It is not showing the correct name for lsalso.exe  but converting it to lsa - printed capital i - so.exe. Note that a printed capital i is not a valid keyboard character. The character "I" is used for a capital i.

I suspect this why your not seeing the path name in PE on your installation for some reason.

Eset_lsaiso.thumb.png.80cb70b366439a5ff5a240873a1a49c0.png

 

Link to comment
Share on other sites

Posted (edited)

There's also another possibility why you're not seeing any path info for lsalso.exe in your Process Explorer output. Note the following:

Quote

Alternatively, you can check Process Explorer to see if the LsaIso.exe process is running. This isn’t as reliable because it doesn’t guarantee Credential Guard itself is running, just that the host process is running. LsaIso.exe also hosts a feature called Key Guard.

If you run Process Explorer, you’ll notice it’s not like any other process and you can’t see any details about its execution. This is because it’s running in an isolated virtual machine (VM).

thumbnail image 5 of blog post titled                                              Comprehensive protection for your credentials with Credential Guard and HVCI
Figure 5. Lsalso.exe properties

 

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/comprehensive-protection-for-your-credentials-with-credential/ba-p/765314

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 w/o Application Guard implementation. 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.

Edited by itman
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...