On our systems we’ve deployed beyondtrust to, if I do a Microsoft sentinel or KQL search for local admin login events, I’m seeing a lot of accounts that start with lenovo_tmp. After some searching, it appears that these are used by the lenovo system updater software to run updates with elevated privileges when a user is not admin. This concerns me because it seems to violate the tamper protection of beyondtrust that disallows the creation of other admin accounts. (lenovo forum for context).
Is anyone else seeing this?
If you can run KQL advanced hunting queries, look at the DeviceLoginEvents table:
DeviceLogonEvents
| where IsLocalAdmin == true
Best answer by Jack
We investigated this issue also, and what we discovered is the following:
The lenovo_tmp_xxxxxxxx accounts are created automatically by Lenovo System Update
Their purpose is to temporarily elevate privileges so drivers, firmware, or BIOS updates can be installed when the signed-in user is not a local admin
These are temporary local admin accounts, used only during the update process and then removed
The end user has no interaction with these accounts at any point. There is no user logon, prompt, or visibility
The accounts are created by the Lenovo System Update service, which already runs under Local System
Because the service operates with Local System access, this activity does not go via BeyondTrust EPM tamper protection, which applies to user-initiated elevation paths
This explains why the logon events appear in DeviceLogonEvents with IsLocalAdmin == true
Regarding BeyondTrust:
BeyondTrust tamper protection prevents user-driven creation of admin accounts
Lenovo System Update uses a service-based mechanism for system updates on non-admin devices
The temporary account creation is service-driven rather than user-driven, and the accounts are not persistent
Recommended approach
Create a BeyondTrust allow rule for Lenovo System Update to elevate when running
This allows updates to complete successfully without creating additional admin account or leaving admin accounts behind
We investigated this issue also, and what we discovered is the following:
The lenovo_tmp_xxxxxxxx accounts are created automatically by Lenovo System Update
Their purpose is to temporarily elevate privileges so drivers, firmware, or BIOS updates can be installed when the signed-in user is not a local admin
These are temporary local admin accounts, used only during the update process and then removed
The end user has no interaction with these accounts at any point. There is no user logon, prompt, or visibility
The accounts are created by the Lenovo System Update service, which already runs under Local System
Because the service operates with Local System access, this activity does not go via BeyondTrust EPM tamper protection, which applies to user-initiated elevation paths
This explains why the logon events appear in DeviceLogonEvents with IsLocalAdmin == true
Regarding BeyondTrust:
BeyondTrust tamper protection prevents user-driven creation of admin accounts
Lenovo System Update uses a service-based mechanism for system updates on non-admin devices
The temporary account creation is service-driven rather than user-driven, and the accounts are not persistent
Recommended approach
Create a BeyondTrust allow rule for Lenovo System Update to elevate when running
This allows updates to complete successfully without creating additional admin account or leaving admin accounts behind
We investigated this issue also, and what we discovered is the following:
The lenovo_tmp_xxxxxxxx accounts are created automatically by Lenovo System Update
Their purpose is to temporarily elevate privileges so drivers, firmware, or BIOS updates can be installed when the signed-in user is not a local admin
These are temporary local admin accounts, used only during the update process and then removed
The end user has no interaction with these accounts at any point. There is no user logon, prompt, or visibility
The accounts are created by the Lenovo System Update service, which already runs under Local System
Because the service operates with Local System access, this activity does not go via BeyondTrust EPM tamper protection, which applies to user-initiated elevation paths
This explains why the logon events appear in DeviceLogonEvents with IsLocalAdmin == true
Regarding BeyondTrust:
BeyondTrust tamper protection prevents user-driven creation of admin accounts
Lenovo System Update uses a service-based mechanism for system updates on non-admin devices
The temporary account creation is service-driven rather than user-driven, and the accounts are not persistent
Recommended approach
Create a BeyondTrust allow rule for Lenovo System Update to elevate when running
This allows updates to complete successfully without creating additional admin account or leaving admin accounts behind
Thank you for all the information! I hadn’t understood that things that run as a service are not subject to the tamper protections of beyondtrust. We do have a beyondtrust rule for the Lenovo publisher to allow elevation with the UAC prompt flag, but perhaps it needs to elevate without the UAC requirement to prevent it from creating these local accounts.
Badge Earners
PaulMuchemihas earned the badge BCA: Password Safe
Yuliyan Levendovhas earned the badge Core Concepts -Endpoint Privilege Management - Windows and Mac
Yuliyan Levendovhas earned the badge 10 Courses Completed - Endpoint Privilege Management - Windows & Mac
Drew Hollingshas earned the badge 25 Courses Completed
