Sources and References:
An old article on the same topic that I have discussed before: https://databasesecurityninja.wordpress.com/2025/01/11/microsoft-sql-server-unsigned-dlls-and-its-security-implications/
Introduction:
hkdllgen.exe (known as the Hekaton DLL Generator) is an executable utility introduced by Microsoft in SQL Server 2022 (starting with Cumulative Update 17) to manage the compilation and digital signing of In-Memory OLTP (Hekaton) database components.
The parameter “external xtp dll gen util enabled” is enabled as shown below:
select * from sys.configurations where name like ‘%xtp%’;
side remark…to enable it (because it’s not enabled by default):
EXECUTE sp_configure ‘external xtp dll gen util enabled’, 1;
RECONFIGURE;
GO
I will then create a dummy database and enable in-memory feature for it:
create database memorydb2;
// I will add the file group to the database:
USE [master]
GO
ALTER DATABASE [memorydb2] ADD FILEGROUP [memory_file_group2] CONTAINS MEMORY_OPTIMIZED_DATA
GO
ALTER DATABASE [memorydb2]
ADD FILE(NAME = mem_dir,
FILENAME = ‘C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQL2025\MSSQL\DATA\XTP2’)
TO FILEGROUP [memory_file_group2];
GO
// I will create a dummy table
USE [memorydb2]
GO
CREATE TABLE dbo.test(
testo varchar(16) NOT NULL,
Constraint PK_HekatonDataTable_Hekaton PRIMARY KEY NONCLUSTERED (testo)) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
// I will then insert random values in the table
USE [memorydb2]
GO
INSERT INTO dbo.test (testo)VALUES (‘dumm_’ + CAST(ABS(CHECKSUM(NEWID())) % 1000 AS VARCHAR(10)));
GO 300
Its expected that the DLL file generated is digitally signed….however this is not the case as shown in the snpashot image:
Another Method is using sigcheck sysinternal utility:
A third approach, is to check by running the following t-sql query:
select * from sys.dm_os_loaded_modules where description=’XTP Native DLL’;
Conclusion:
While a valid cryptographic digital signature ensures the authenticity and integrity of a compiled binary, targeting dynamic database runtime components—such as In-Memory OLTP (XTP) directories—presents a severe attack vector if integrity controls are bypassed.
Because database services like SQL Server frequently operate under high-privilege service accounts (such as NT AUTHORITY\SYSTEM or a high-privileged virtual account), an adversary who achieves local administrative access could attempt to substitute or hijack dynamic runtime DLLs. A successful payload injection into the SQL Server process memory (sqlservr.exe) would inherit the service’s privileges, facilitating arbitrary code execution, local privilege escalation to SYSTEM, or the establishment of an outbound reverse shell.
Although modern SQL Server architectures and strict Code Integrity policies (along with Endpoint Detection and Response [EDR] solutions) actively block unsigned binaries, organizations must remain vigilant. If administrative exclusions or loose application whitelisting policies are improperly granted to dynamic application directories, it creates a dangerous security blind spot—allowing malicious, non-compliant binaries to be stealthily implanted and executed under the guise of trusted database operations.
The following is Microsoft MSRC response:
Your report describes a scenario in which a generated component is loaded without a signature, which was claimed to enable code substitution. In our review the generation step flags components as produced by a trusted managed installer rather than signing them, and customers can enforce policies to block components that are both unsigned and not from a managed installer; reaching the scenario requires administrative control that is already trusted. On that basis the reported behavior does not meet the definition of a security vulnerability. We are updating the documentation that described this inaccurately.
We appreciate the details provided in your report. The information has been shared with the responsible engineering team for awareness and internal review.
