Trojan Multi Accesstr
Trojan Multi Accesstr
Trojan.Multi.Accesstr detection is triggered when KES detects that one of Windows utilities in %systemroot%\system32 folder is
replaced by cmd.exe or powershell.exe.
Please see below for a list of affected files with exact detection names. Detection event looks like this :
Trojan.Multi.Accesstr.a.ok :
"%SystemRoot%\\system32\\osk.exe"
"%SystemRoot%\\syswow64\\osk.exe"
Trojan.Multi.Accesstr.a.mf :
"%SystemRoot%\\system32\\magnify.exe"
"%SystemRoot%\\syswow64\\magnify.exe"
Trojan.Multi.Accesstr.a.ds :
"%SystemRoot%\\system32\\displayswitch.exe"
"%SystemRoot%\\syswow64\\displayswitch.exe"
Trojan.Multi.Accesstr.a.ab :
"%SystemRoot%\\system32\\atbroker.exe"
"%SystemRoot%\\syswow64\\atbroker.exe"
Trojan.Multi.Accesstr.a.um
"%SystemRoot%\\system32\\utilman.exe"
"%SystemRoot%\\syswow64\\utilman.exe"
Trojan.Multi.Accesstr.a.sh
"%SystemRoot%\\system32\\sethc.exe"
"%SystemRoot%\\syswow64\\sethc.exe"
Trojan.Multi.Accesstr.a.ed
"%SystemRoot%\\system32\\easeofaccessdialog.exe"
"%SystemRoot%\\syswow64\\easeofaccessdialog.exe"
Trojan.Multi.Accesstr.a.nr
"%SystemRoot%\\system32\\narrator.exe"
"%SystemRoot%\\syswow64\\narrator.exe"
Replacing aforementioned utilities with cmd.exe/powershell.exe provides adversaries with an easily available backdoor. For
example C:\Windows\System32\sethc.exe is launched when the shift key is pressed five times and
C:\Windows\System32\utilman.exe is launched when the Windows + U key combination is pressed. Both utilities can be executed
from login screen (both offline and when connected through RDP).
If these tools are replaced with cmd.exe/powershell.exe, then a command line with SYSTEM privileges will be launched.
Through Kaspersky Managed Protection service AMR has observed that this attack has been executed several times recently, so a
corresponding record was published in order for KL products to detect the corrupted system files allowing the attack.
How to repair an affected system?
After attack is detected, KES will try to restore the original files by looking for a backup of the file on the endpoint machine.
According to AMR statistics, this operation is successful 60% of the times.
However backup of these files may be missing from the affected PC, so a manual attempt might be in order.
Here's the recommended way to proceed with repairing an affected system manually:
On Windows 7 DISM does not have /RestoreHealth option. Instead you should use /ScanHealth option like this: DISM /Online
/Cleanup-Image /ScanHealth.
Make sure this update is installed before running DISM with /ScanHealth option :
https://support.microsoft.com/en-us/help/2966583/improvements-for-the-system-update-readiness-tool-in-windows-7-and-win
If DISM tool fails to load source files, it might be effective to use a Windows installation media as a repair source. In that case
customer should add /Source: parameter. For example DISM /Online /Cleanup-Image /RestoreHealth
/Source:E:\sources\install.wim where e:\sources is a path to Windows installation media.
Please see relevant Microsoft Docs article for full information on using DISM to repair OS :
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/repair-a-windows-image