Privileged accounts — system administrator accounts, service accounts, accounts with root access — are the target of attackers in most sophisticated attacks. If a privileged user is compromised, the attacker gains a direct path to critical data and management systems. That's exactly why controlling and recording privileged sessions isn't an optional PAM feature — it's PAM's functional core.
In this article, we break down how session control is technically built, exactly what the system captures, and how recordings help during incident investigations. For a general introduction to the topic, see "What Is PAM".
How PAM Sits Between the User and the Target System
Before discussing recording, it helps to understand the architecture of session control. The classic scheme is built around the concept of a jump server — an intermediary node through which all privileged traffic passes.
The scheme works like this:
- The privileged user authenticates to PAM — through a web interface or an SSH proxy, with multi-factor authentication.
- PAM checks the access policy: whether the user has permission to access the requested system, at what time, and with what justification.
- If the policy allows access, PAM establishes the connection to the target system on its own behalf — the user never receives the actual password for the target server.
- All actions within the session pass through PAM: it sees the full traffic and records it.
The key consequence of this architecture is isolation. The user doesn't know the target system's password. If their account is compromised, the attacker doesn't gain direct access: they still have to go through PAM with its policies and MFA.
The principle of least privilege is enforced not declaratively but technically: the user simply has no credentials they could use to bypass the system.
What Exactly PAM Records
Session control provides several layers of recording, each solving a different problem.
Screen Video Capture
For RDP sessions and other graphical protocols, PAM records the screen as a video stream. It typically uses a specialized format optimized for storage and playback — not MP4, but a more compact binary format. From the recording, you can replay the session second by second: what the administrator opened, which files were changed, which commands were run in a console within the RDP session.
Use case: incident investigations that require reconstructing the exact timeline of actions. This is especially important in disputes — "I didn't do that" or "I don't know how that happened."
Text-Based Command Logging
For SSH and terminal sessions, PAM captures the exact input: every command the user typed and the command-line output. Text logs:
- are indexed — enabling full-text search. Finding every session where rm -rf was run or the file /etc/passwd was modified takes seconds;
- take up little space — a multi-year archive of text sessions is far more compact than video recordings;
- can be analyzed by scripts — automatically flagging anomalies: atypical commands, activity outside working hours, attempts to modify system files.
Session Metadata
Regardless of the recording depth, PAM always captures metadata:
- who initiated the session (username, Active Directory group);
- which system was accessed (hostname, IP address);
- session start and end time;
- which workstation the request originated from;
- whether a justification was provided (an ITSM ticket, a comment);
- the authentication result — success or failure.
Metadata is what external audits most often request. It answers the question of who had access to a given system and when, without having to review every session recording in sequence.
Real-Time Monitoring
Recording is a retrospective tool. But PAM also provides proactive control: the information security team or the SOC analyst on duty can watch active sessions in real time.
What real-time monitoring enables:
- Keyword alerts. PAM analyzes commands in SSH sessions and immediately notifies responsible staff if a user types suspicious commands: changing permissions, deleting data, downloading configuration files.
- Manual session termination. If an analyst spots suspicious activity, they can kill the session with a single click. The administrator then receives a message that the session was forcibly terminated.
- Policy-based blocking. Some PAM solutions automatically terminate a session when predefined rules trigger — for example, if the user attempts to run a blacklisted command.
This turns PAM from a mere evidence archive into an active tool for preventing incidents, not just investigating them after the fact.
SIEM Integration and the Closed Monitoring Loop
PAM collects a rich set of events: session creation, in-session commands, authentication failures, attempts to access systems outside policy. PAM forwards all of these events to a SIEM in standard formats — syslog, CEF, LEEF.
On the SIEM side, PAM events are correlated with other signals:
- a network traffic anomaly plus a privileged session at the same time — an incident;
- multiple authentication failures followed by a successful login — a potential brute-force attempt;
- a privileged-access session outside working hours — warrants attention.
SIEM integration turns isolated events into a contextual incident signal. Without it, PAM events sit in a separate store that only gets checked after a violation has already occurred.
Regulatory Requirements for Session Control
The requirement to record privileged sessions is established in several regulatory documents:
- GOST R 57580, for financial organizations, explicitly requires logging and controlling privileged access, including retaining recordings for incident investigation.
- FSTEC Orders No. 17 and No. 21 introduce requirements for identification and access management, including mandatory logging of access events to critical resources.
- Federal Law No. 152-FZ — when processing personal data, an audit of privileged access is needed as evidence of the protective measures taken.
During an audit, auditors don't just ask for a statement that "we have PAM" — they request specific logs: who had access to systems containing personal data or critical infrastructure, and when. Without session logs, this kind of confirmation is impossible.
Storing and Protecting Recordings
Session recordings themselves are a critical asset: they're what can confirm or refute an employee's actions during an investigation. They need to be protected with the same care as the privileged systems themselves.
Storage principles:
- Immutability — recordings can't be edited or deleted by the users whose sessions were recorded. Access to the archive is separated from the right to work within PAM.
- Encryption — recordings are stored encrypted. The encryption key is separate from PAM administrators' credentials.
- Retention period — regulatory requirements set a minimum retention period for audit logs: for financial organizations, this is typically at least one year.
Frequently Asked Questions
How does PAM session control differ from regular bash logging?
OS-level bash logging is a partial measure. It doesn't cover RDP, doesn't capture interactive sessions before commands execute, and a privileged user can easily disable or bypass it. PAM recording happens at an intermediary node that the user doesn't control.
Can PAM record sessions to cloud resources?
Yes, if a proxying mode or a target-side agent is configured. Some PAM solutions support connecting to cloud provider APIs — in that case, even access to the cloud console goes through PAM with full recording.
What happens to recordings when an employee leaves?
Session recordings are retained regardless of the account's status. If a former employee is suspected of misconduct, the historical record of all their privileged sessions remains intact and available for investigation.
How can you confirm a session recording hasn't been tampered with?
Mature PAM solutions attach a cryptographic signature to recordings — a checksum that confirms the file hasn't changed since it was created. When presented as evidence, its authenticity can be verified.
Does PAM slow down administrators' work?
Not when configured correctly. The jump server adds one authentication step, but experienced administrators get through it in seconds, especially with SSO configured. Real friction only appears when a mandatory ITSM ticket justification is required — and that's a deliberate control measure, not a technical limitation.
Hands-On Practice on BI.ZONE Cybersecurity Labs
The easiest way to understand how PAM session control works is on a real lab environment. The course Installing and Administering BI.ZONE PAM, on isolated BI.ZONE Cybersecurity Labs environments, gives you hands-on practice with the full cycle: setting up a jump server, connecting target systems, reviewing recorded sessions, and configuring policies and alerts.
The course covers exactly the tasks a BI.ZONE PAM administrator faces in real-world operation — from initial configuration to investigating an incident using the session archive.