Skip to content
Notifications
Clear all

ELI5: How does Delinea actually 'discover' passwords?

2 Posts
2 Users
0 Reactions
3 Views
(@ci_cd_junkie)
Estimable Member
Joined: 5 months ago
Posts: 134
Topic starter   [#13790]

Okay, so I've been knee-deep in configuring PAM solutions for our container orchestration layer, and Delinea's Secret Server keeps coming up, especially from the security team. They keep throwing around the term "discovery" like it's magic. 🧙

I get the core concept: you have this vault, and it's supposed to find all the service accounts, database passwords, API keys, and whatnot that are sprawled across the estate. But the *mechanics* of it are what I'm curious about. My CI/CD pipelines are already doing some of this with tools like Vault, but it's very explicitβ€”I have to define the secret's path and rotation schedule manually.

So, how does Delinea *actually* perform discovery? Is it just an agent sitting on a Windows server scanning the registry for auto-logon credentials? Or is it more sophisticated? For instance:

* **Network Scanning:** Does it use something like an unauthenticated scan of IP ranges looking for services (SSH, databases, web apps) and then try to catalog them? Or is it credentialed, where you give it a domain admin account and it uses WMI/PowerShell/SSH to interrogate systems?
* **Pattern Matching:** Does it parse configuration files (think `web.config`, `application.yml`, `.env` files) on servers or in code repos for strings that *look* like passwords or keys? Regex patterns for `password=*` or `api_key=*`?
* **Privileged Session Monitoring:** This one I've heard aboutβ€”does it essentially "watch" an admin or service account as it logs into something, intercept the credential exchange, and then vault it? That sounds both brilliant and terrifying from an implementation perspective.

I'm trying to map this to an infrastructure-as-code mindset. If I were to pseudo-code a naive discovery scanner, it might look something like this (oversimplified, of course):

```bash
# Example conceptual flow for a credentialed scan
for target in $(nmap -sL 10.0.0.0/24); do
for common_service in (ssh, mysql, mssql-srv, winrm); do
if port_open(target, common_service.port); then
attempt_connection_with_vaulted_service_account(target, service);
if successful:
log_discovery(target, service, "Live connection validated");
else:
log_discovery(target, service, "Service found, but no valid credential");
fi
done
done
```

But I know real enterprise tools are way more complex. Do they leverage existing AD inventories? Do they integrate with cloud provider metadata services (like AWS IAM or Azure Managed Identities) to find secrets in use?

Also, from a security perspective, how does the discovery process *itself* not become a liability? If the discovery engine needs high-privilege credentials to scan everything, protecting *that* credential becomes a huge deal. Do they use just-in-time access or some kind of ephemeral credential for the scanner?

I'd love to hear from anyone who's set this up, especially in a hybrid environment. What was the actual configuration like? Was it a massive list of IP ranges and domain accounts, or was it more about pointing it at your CMDB or cloud tenant? And most importantly, how noisy was it? Did it flood you with thousands of "discoveries" that were just default accounts on test systems?


pipeline all the things


   
Quote
(@billyj)
Reputable Member
Joined: 1 week ago
Posts: 137
 

You're right to question the "magic" part. Their discovery is credentialed, not some black-box network sweep. You give it a privileged account with permissions, and the Discovery Scanners use that identity to connect via the native protocols you mentioned: WMI for Windows, SSH for Unix/Linux, SQL queries for databases, and specific SDKs for cloud providers.

It's fundamentally a pattern-matching and interrogation engine. For your config file example, yes, it parses files like web.config, .properties, or Kubernetes secrets, looking for strings that match predefined regex patterns for connection strings, API keys, and passwords. It also interrogates services directly, like querying the local Windows Security Account Manager for stored credentials or checking scheduled tasks for embedded service accounts.

The key distinction from your CI/CD approach is that it's post-deployment and continuous. It finds the secrets that were hardcoded or forgotten long before you had a vault, the "shadow IT" service accounts created by a contractor five years ago. The real challenge is tuning the false positives, as those regex patterns can flag benign strings.



   
ReplyQuote