Why privileged accounts are a critical attack surface
Most user accounts in an organisation have limited rights. A small minority — Windows Administrator, Linux root, Active Directory Domain Admin, the database sa account, network device enable passwords, hypervisor root access — can change the entire system, delete logs and create new accounts.
That minority is what attackers are after. Compromising an end-user account is usually only the first step; the real goal is lateral movement towards a privileged account. Once that happens, the attacker becomes indistinguishable from a legitimate administrator.
Privileged Access Management (PAM) is the discipline built to manage exactly this minority. Its core idea is simple: administrators should never know the privileged password.
The concrete problems PAM solves
- Shared passwords: five sysadmins know the same root password, and it is rarely changed when one of them leaves.
- Spreadsheet vaults: server passwords living in a file share, sometimes in an unprotected spreadsheet.
- Untraceable sessions: after an incident, nobody can tell who made a change on a critical server.
- Standing privilege: an account that became Domain Admin once stays Domain Admin for years.
- Orphaned service accounts: accounts created years ago for an application, never rotated, with no known owner.
Every line above is an audit finding. How privileged access is controlled is a question asked directly in ISO 27001 and KVKK audits.
The five components of a PAM architecture
1. Encrypted password vault
All privileged credentials live in a central, encrypted vault. In a properly built vault, passwords are protected with authenticated encryption such as AES-256-GCM, and the master key is not stored in plaintext in the database — it is wrapped by an HSM (PKCS#11) or a HashiCorp Vault transit engine. Even if a database backup leaks, the vault cannot be decrypted without that key.
2. Session proxy and recording
The administrator never connects directly to the target. The connection goes through a proxy that injects the password into the target without ever revealing it. The proxy also records the session: asciinema cast format for SSH gives full-text search over commands, while RDP sessions are captured through Apache Guacamole's guacd protocol translation.
3. Just-in-time (JIT) access
Instead of standing privilege, rights are granted only for the time they are needed — time-boxed AD group membership on Windows via Group Policy Restricted Groups, a temporary file under /etc/sudoers.d/ cleaned up by cron on Linux, and dynamic authorisation over TACACS+ on network devices. The effect is measurable: the number of permanent Domain Admins drops to zero.
4. Approval workflow
Access to sensitive targets can require multiple approvers (an M of N rule), with notifications over e-mail, Slack or Teams. This is the technical implementation of the four-eyes principle.
5. Automatic password rotation
After use, a password is regenerated, pushed to the target and updated in the vault, using target-specific connectors — WinRM/SAMR for Windows, SSH passwd for Linux, Cisco IOS, MikroTik API, T-SQL for MSSQL, ALTER USER for MySQL/PostgreSQL. Rotation can be time-based or triggered after each use.
The commonly missed step: orphaned service accounts
The discovery phase produces the most surprises. A network scan (nmap plus WMI/SMB/SSH scripts) reveals which accounts run active Windows services, scheduled tasks and IIS application pools. A typical organisation finds dozens of forgotten accounts. These are flagged as orphans and resolved with IT operations before rotation is enabled — rotating an unknown dependency can break production.
Command filtering and the audit trail
PAM can restrict behaviour within a session, not just access to it. Regex-based allow/deny lists block specific commands in SSH and PowerShell sessions, and blocked commands are written to the session log with a BLOCKED marker.
On the audit side, immutability is what matters. Events are written as JSONL to a write-once directory, shipped daily to a SIEM via rsyslog or fluent-bit, and archived with AES-GCM encryption — making it much harder for an attacker to erase their tracks.
PAM versus SSO
- SSO simplifies and centralises end-user access to applications.
- PAM restricts and records administrator access to infrastructure. The goal is control and traceability, not convenience.
They complement each other: the PAM portal itself is protected by SSO and MFA, while authorisation inside PAM is driven by Active Directory group membership.
Where to start
- Inventory: run service account discovery to find what privileged accounts exist.
- Top 10 targets: start with domain controllers, hypervisors and database servers.
- Vault and session recording: this step alone closes audit findings.
- Rotation: enable it once the inventory is clean.
- JIT and approvals: remove standing privilege after the process settles.
Marta PAM
Marta PAM, developed in house at Marta Teknoloji, delivers the whole architecture above in one platform: an AES-256-GCM encrypted vault, a Go-based SSH bastion and Guacamole-based RDP session recording, JIT authorisation, M of N approval workflows, target-specific automatic password rotation and MFA with TOTP/FIDO2. Recordings are stored on S3-compatible storage including MinIO, and audit logs are shipped to your SIEM.
Contact us for a free initial assessment of the privileged accounts in your environment.