{ "id": "d904f14e-ab2c-47e9-b7eb-782a6a6e9598", "created_at": "2026-04-06T00:21:35.741505Z", "updated_at": "2026-04-10T03:24:29.883606Z", "deleted_at": null, "sha1_hash": "08f413ece9389f47a04d18af916048456136cbc5", "title": "Tracking down Maggie", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1211796, "plain_text": "Tracking down Maggie\r\nBy DCSO CyTec Blog\r\nPublished: 2022-10-13 · Archived: 2026-04-05 15:26:41 UTC\r\nIn our recent blog post “MSSQL, meet Maggie” we shared our research on a novel backdoor malware targeting\r\nMicrosoft SQL servers that DCSO CyTec refers to as “Maggie“.\r\nPress enter or click to view image in full size\r\nTracking Down “Maggie”\r\nMaggie can be summarised as malware that comes in form of an “Extended Stored Procedure” DLL, a special\r\ntype of extension used by Microsoft SQL servers. Once loaded into a server by an attacker, it is controlled solely\r\nusing SQL queries and offers a variety of functionality to run commands, interact with files and function as a\r\nnetwork bridge head into the environment of the infected server.\r\nIn this blog post DCSO’s Incident Response Team (DIRT) aims to provide security teams with some insights on\r\nhow to detect this novel threat in their environment.\r\nBlog authored by Denis Szadkowski, Johann Aydinbas and Axel Wauer\r\nAm I affected?\r\nThe first question that probably jumped into the minds of the majority of our readers after reading our blog post\r\n“MSSQL, meet Maggie” was “Are my Microsoft SQL servers affected by this threat?”.\r\nhttps://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nPage 1 of 9\n\nThere are multiple ways of identifying the presence of this threat in your environment. A good starting point for\r\nMicrosoft SQL administrators is to review the “Extended Stored Procedures” (ESP) installed on their Microsoft\r\nSQL servers. One way of doing that is to use a “System Stored Procedures” called sp_helpextendedproc . By\r\nspecifying the name of the ESP it is possible to quickly check if the Microsoft SQL server is affected as shown in\r\nthe following figure. If the SQL query does not return any results this means there is no ESP with the name\r\n“maggie”.\r\nUsing sp_helpextendedproc to check the presence of Maggie\r\nAnother way of verifying if a Microsoft SQL server has been backdoored by this threat actor is to check the\r\napplication log. When a ESP is executed, the event id 8128 is logged in the application log of the system as can\r\nbe seen in the figure below.\r\nExecution of the extended stored procedure “maggie”\r\nhttps://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nPage 2 of 9\n\nFurthermore, the application log can easily be searched with the help of the following PowerShell one-liner. The\r\npresented one-liner can also be used in combination with the PowerShell Cmdlet Invoke-Command to search\r\napplication logs across multiple systems.\r\nGet-EventLog -LogName Application -Source MSSQLSERVER | Where-Object {($_.EventID -eq 8128) -and ($_\r\nIf the Microsoft SQL server is affected by this threat the PowerShell one-liner will return output similar to the one\r\npresented in the figure below.\r\nPress enter or click to view image in full size\r\nPowerShell one-liner output for affected MSSQL server\r\nIn addition to event id 8128 the usage of the ESP will generate the event 33090 that provides information about\r\nthe ESP DLLs that were recently loaded into the memory of the Microsoft SQL server process sqlservr.exe .\r\nOnce the presence of the ESP named “maggie” has been confirmed by using one of the methods described above,\r\nit is recommended to check if the threat actor was able to create a backdoor database user in the Microsoft SQL\r\nserver. This can be accomplished with the SQL query presented below:\r\nselect sp.name,\r\n sp.type_desc,\r\n sp.create_date,\r\n sp.modify_date,\r\n case when sp.is_disabled = 1 then ‘Disabled’\r\n else ‘Enabled’ end as status\r\nfrom sys.server_principals sp order by sp.create_date DESC\r\nAs described in our previous blog post one of the first things that Maggie does after successfully bruteforcing its\r\nway into a Microsoft SQL server is to check if the current database user has the administrative role assigned, if\r\nthis is the case a backdoor database user is created. The SQL query above will show the most recently added users\r\naccounts. It is recommended to verify if the presented accounts are legitimate.\r\nIdentifying malicious ESPs\r\nAfter the publication of our Maggie research it is safe to assume that the use of ESPs as a backdoor mechanism\r\nwill increase among threat actors targeting Microsoft SQL servers. Moreover, it can be assumed that the threat\r\nactors behind Maggie will take the necessary steps to change their backdoor to make it harder for defenders to\r\ndetect it. Because of that a more generic detection approach is needed to identify malicious ESPs.\r\nGet DCSO CyTec Blog’s stories in your inbox\r\nhttps://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nPage 3 of 9\n\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nOne way of accomplishing this goal is to build a baseline of ESPs present in a Microsoft SQL server and then to\r\nmonitor the application log for outliers with the help of event ids 8128 and 33090 . In order to fine-tune\r\ndetection rules additional criteria can be added e.g., the path of the ESP. Under normal circumstances ESP are\r\nlocated in C:\\Program Files\\Microsoft SQL Server\\MSSQL14.MSSQLSERVER\\MSSQL\\Binn , which is not always the\r\ncase for malicious ESPs.\r\nMalicious ESP DLL loaded into sqlservr.exe\r\nFurthermore, tools like Sysmon from Windows Sysinternals can provide added visibility that can help to detect\r\nmalicious ESPs. For example event id 7 (Image loaded) can be leveraged to identify newly loaded ESP DLLs:\r\nhttps://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nPage 4 of 9\n\nESP DLLs loaded into sqlservr.exe\r\nIn addition to Sysmon event id 7 , Sysmon process creation events can be used to detect processes spawned by\r\nthe malicious ESP. In the following example the malicious ESP ExtendedProcedure.DLL is used to execute the\r\nwhoami.exe application to find out the current user context:\r\n$ exec maggie 'Exec whoami';MSSQL Procedure 12/08/2021\r\nExecute Command: Exec whoami\r\nnt service\\mssqlserver\r\nAfter running the command above the following process creation event is logged by Sysmon. As presented in the\r\nfigure below the ParentImage of the whoami.exe application is the Microsoft SQL server process\r\nsqlservr.exe which should ring a bell for the seasoned defender.\r\nhttps://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nPage 5 of 9\n\nSysmon process creation event\r\nFor organisations that use Microsoft SQL servers but are lacking a SIEM solution a good practice might be to\r\noccasionally check which ESPs are installed on their Microsoft SQL servers. This can be done by running the\r\n“System Stored Procedure” called sp_helpextendedproc without specifying any parameters as shown in the\r\nfollowing figure:\r\nhttps://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nPage 6 of 9\n\nListing installed ESPs\r\nWhen reviewing the installed ESPs Microsoft SQL administrators should focus on ESPs that are not part of their\r\nbaseline. Another indicator of a malicious ESP might be the path in which the ESP DLL is located. Under normal\r\ncircumstances ESPs are placed under C:\\Program Files\\Microsoft SQL\r\nServer\\MSSQL14.MSSQLSERVER\\MSSQL\\Binn . In the example above the malicious ESP was placed under\r\nC:\\ProgramData to avoid detection.\r\nMitigation\r\nOne of the ways that Maggie can compromise Microsoft SQL servers is by using its SQL bruteforce functionality.\r\nIn order to thwart bruteforce attempts, it is highly recommend to use strong passwords for Microsoft SQL\r\naccounts and to enforce a strong password policy. Additionally, the Microsoft SQL database port (default: 1433 )\r\nshould never be exposed to the Internet. It is sufficient when the front-end tier systems can reach the Microsoft\r\nSQL database.\r\nYou can find additional information about securing Microsoft SQL servers at the vendors web site under Securing\r\nSQL Server.\r\nYARA\r\nimport \"pe\"\r\nrule maggie_backdoor\r\n{\r\n meta:\r\n description = \"Detect MSSQL extended stored procedure backdoor Maggie files\"\r\n author = \"Johann Aydinbas, TEC / DCSO CyTec\"\r\n reference = \"https://medium.com/@DCSO_CyTec/mssql-meet-maggie-898773df3b01\"\r\n strings:\r\n $ = \"Account Owner Not Found For The SID\"\r\nhttps://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nPage 7 of 9\n\n$ = \"Call SO_UPDATE_ACCEPT_CONTEXT To Get IP\"\r\n $ = \"Socks5 Stopped Failure\"\r\n $ = \"It Has Been Hooked\"\r\n $ = \"AllowedIP IP Port\"\r\n $ = \"Wait 5 To 10 Seconds For TS Taking Effect\"\r\n $ = \"\\\\Binn\\\\sqlservr.exe\"\r\n $ = \"HostList UserList PassList\"\r\n $ = \"opends60.dll\"\r\n $ = \"WinSockScan\"\r\n $ = \"ResetClientData\"\r\n $ = \"ViewClientData\"\r\n $ = \"ElevateTS\"\r\n condition:\r\n pe.is_pe and\r\n 8 of them\r\n}\r\nSIGMA\r\ntitle: MSSQL Extended Stored Procedure Backdoor Maggie\r\nid: 711ab2fe-c9ba-4746-8840-5228a58c3cb8\r\ndescription: This rule detects the execution of the extended storage procedure backdoor named Maggie\r\ntags:\r\n - attack.persistence\r\n - attack.t1546\r\nstatus: experimental\r\ndate: 2022/10/09\r\nmodified: 2022/10/09\r\nreferences:\r\n - https://medium.com/@DCSO_CyTec/mssql-meet-maggie-898773df3b01\r\nauthor: Denis Szadkowski, DIRT / DCSO CyTec\r\nlogsource:\r\n product: windows\r\n service: application\r\ndetection:\r\n selection:\r\n Provider_Name: 'MSSQLSERVER'\r\n EventID: 8128\r\n Message|contains: 'maggie'\r\n condition: selection\r\nfalsepositives:\r\n - Legitimate extended stored procedures named maggie\r\nlevel: high\r\nwin_mssql_sp_maggie.yml\r\nhttps://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nPage 8 of 9\n\nAre you affected?\r\nAre you one of the organisations affected by this novel Microsoft SQL server backdoor? We would like to hear\r\nfrom you! If desired, we can help your organisation to investigate and to respond to this threat.\r\nSource: https://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nhttps://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://medium.com/@DCSO_CyTec/tracking-down-maggie-4d889872513d" ], "report_names": [ "tracking-down-maggie-4d889872513d" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434895, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/08f413ece9389f47a04d18af916048456136cbc5.pdf", "text": "https://archive.orkl.eu/08f413ece9389f47a04d18af916048456136cbc5.txt", "img": "https://archive.orkl.eu/08f413ece9389f47a04d18af916048456136cbc5.jpg" } }