Expand 4 remaining SKILL.md stubs with researched content

skills/analyzing-linux-audit-logs-for-intrusion/SKILL.md

@@ -14,20 +14,218 @@ license: Apache-2.0
 
 # Analyzing Linux Audit Logs for Intrusion
 
-Parse auditd logs to detect file access violations, privilege escalation,
-suspicious syscalls, and unauthorized process execution.
-
-
 ## When to Use
 
-- When investigating security incidents that require analyzing linux audit logs for intrusion
+- Investigating suspected unauthorized access or privilege escalation on Linux hosts
-- When building detection rules or threat hunting queries for this domain
+- Hunting for evidence of exploitation, backdoor installation, or persistence mechanisms
-- When SOC analysts need structured procedures for this analysis type
+- Auditing compliance with security baselines (CIS, STIG, PCI-DSS) that require system call monitoring
-- When validating security monitoring coverage for related attack techniques
+- Reconstructing a timeline of attacker actions during incident response
+- Detecting file tampering on critical system files such as `/etc/passwd`, `/etc/shadow`, or SSH keys
+
+**Do not use** for network-level intrusion detection; use Suricata or Zeek for network traffic analysis. Auditd operates at the kernel level on individual hosts.
 
 ## Prerequisites
 
-- Familiarity with log analysis concepts and tools
+- Linux system with `auditd` package installed and the audit daemon running (`systemctl status auditd`)
-- Access to a test or lab environment for safe execution
+- Root or sudo access to configure audit rules and query logs
-- Python 3.8+ with required dependencies installed
+- Audit rules deployed via `/etc/audit/rules.d/*.rules` or loaded with `auditctl`
-- Appropriate authorization for any testing activities
+- Recommended: Neo23x0/auditd ruleset from GitHub for comprehensive baseline coverage
+- Familiarity with Linux syscalls (`execve`, `open`, `connect`, `ptrace`, etc.)
+- Log storage with sufficient retention (default location: `/var/log/audit/audit.log`)
+
+## Workflow
+
+### Step 1: Verify Audit Daemon Status and Configuration
+
+Confirm the audit system is running and check the current rule set:
+
+```bash
+# Check auditd service status
+systemctl status auditd
+
+# Show current audit rules loaded in the kernel
+auditctl -l
+
+# Show audit daemon configuration
+cat /etc/audit/auditd.conf | grep -E "log_file|max_log_file|num_logs|space_left_action"
+
+# Check if the audit backlog is being exceeded (dropped events)
+auditctl -s
+```
+
+If the backlog limit is being reached, increase it:
+
+```bash
+auditctl -b 8192
+```
+
+### Step 2: Deploy Intrusion-Focused Audit Rules
+
+Add rules that target common intrusion indicators. Place these in `/etc/audit/rules.d/intrusion.rules`:
+
+```bash
+# Monitor credential files for unauthorized reads or modifications
+-w /etc/passwd -p wa -k credential_access
+-w /etc/shadow -p rwa -k credential_access
+-w /etc/gshadow -p rwa -k credential_access
+-w /etc/sudoers -p wa -k privilege_escalation
+-w /etc/sudoers.d/ -p wa -k privilege_escalation
+
+# Monitor SSH configuration and authorized keys
+-w /etc/ssh/sshd_config -p wa -k sshd_config_change
+-w /root/.ssh/authorized_keys -p wa -k ssh_key_tampering
+
+# Monitor user and group management commands
+-w /usr/sbin/useradd -p x -k user_management
+-w /usr/sbin/usermod -p x -k user_management
+-w /usr/sbin/groupadd -p x -k user_management
+
+# Detect process injection via ptrace
+-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -k process_injection
+-a always,exit -F arch=b64 -S ptrace -F a0=0x5 -k process_injection
+-a always,exit -F arch=b64 -S ptrace -F a0=0x6 -k process_injection
+
+# Monitor execution of programs from unusual directories
+-a always,exit -F arch=b64 -S execve -F exe=/tmp -k exec_from_tmp
+-a always,exit -F arch=b64 -S execve -F exe=/dev/shm -k exec_from_shm
+
+# Detect kernel module loading (rootkit installation)
+-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_module_load
+-a always,exit -F arch=b64 -S delete_module -k kernel_module_remove
+-w /sbin/insmod -p x -k kernel_module_tool
+-w /sbin/modprobe -p x -k kernel_module_tool
+
+# Monitor network socket creation for reverse shells
+-a always,exit -F arch=b64 -S socket -F a0=2 -k network_socket_created
+-a always,exit -F arch=b64 -S connect -F a0=2 -k network_connection
+
+# Detect cron job modifications (persistence)
+-w /etc/crontab -p wa -k cron_persistence
+-w /etc/cron.d/ -p wa -k cron_persistence
+-w /var/spool/cron/ -p wa -k cron_persistence
+
+# Monitor log deletion or tampering
+-w /var/log/ -p wa -k log_tampering
+```
+
+Reload rules after editing:
+
+```bash
+augenrules --load
+auditctl -l | wc -l   # Confirm rule count
+```
+
+### Step 3: Search for Intrusion Indicators with ausearch
+
+Use `ausearch` to query the audit log for specific events:
+
+```bash
+# Search for all failed login attempts in the last 24 hours
+ausearch -m USER_LOGIN --success no -ts recent
+
+# Search for commands executed by a specific user
+ausearch -ua 1001 -m EXECVE -ts today
+
+# Search for all file access events on /etc/shadow
+ausearch -f /etc/shadow -ts this-week
+
+# Search for privilege escalation via sudo
+ausearch -m USER_CMD -ts today
+
+# Search for kernel module loading events
+ausearch -k kernel_module_load -ts this-month
+
+# Search for processes executed from /tmp (common attack staging)
+ausearch -k exec_from_tmp -ts this-week
+
+# Search for SSH key modifications
+ausearch -k ssh_key_tampering -ts this-month
+
+# Search events in a specific time range
+ausearch -ts 03/15/2026 08:00:00 -te 03/15/2026 18:00:00
+
+# Interpret syscall numbers and format output readably
+ausearch -k credential_access -i -ts today
+```
+
+### Step 4: Generate Summary Reports with aureport
+
+Use `aureport` to produce aggregate summaries for triage:
+
+```bash
+# Summary of all authentication events
+aureport -au -ts this-week --summary
+
+# Report of all failed events
+aureport --failed --summary -ts today
+
+# Report of executable runs
+aureport -x --summary -ts today
+
+# Report of all anomaly events
+aureport --anomaly -ts this-week
+
+# Report of file access events
+aureport -f --summary -ts today
+
+# Report of all events by key (maps to custom rule keys)
+aureport -k --summary -ts this-month
+```
+
+### Step 5: Reconstruct the Attack Timeline
+
+Combine ausearch queries to build a chronological narrative:
+
+```bash
+# Identify the initial access timestamp
+ausearch -m USER_LOGIN -ua 0 --success yes -ts this-week -i | head -50
+
+# Trace what the attacker did after gaining access
+ausearch -ua <UID> -ts "03/15/2026 14:00:00" -te "03/15/2026 18:00:00" -i | aureport -f -i
+
+# Extract all commands executed during the incident window
+ausearch -m EXECVE -ts "03/15/2026 14:00:00" -te "03/15/2026 18:00:00" -i
+
+# Check for persistence mechanisms installed
+ausearch -k cron_persistence -ts "03/15/2026 14:00:00" -i
+ausearch -k ssh_key_tampering -ts "03/15/2026 14:00:00" -i
+```
+
+### Step 6: Forward Audit Logs to SIEM
+
+Configure `audisp-remote` or `auditbeat` to ship logs to a central SIEM:
+
+```bash
+# Using audisp-remote plugin (/etc/audit/plugins.d/au-remote.conf)
+active = yes
+direction = out
+path = /sbin/audisp-remote
+type = always
+
+# Remote target (/etc/audit/audisp-remote.conf)
+remote_server = siem.internal.corp
+port = 6514
+transport = tcp
+```
+
+## Key Concepts
+
+| Term | Definition |
+|------|------------|
+| **auditd** | Linux Audit daemon that receives kernel audit events and writes to `/var/log/audit/audit.log` |
+| **auditctl** | CLI to control the audit system: add/remove rules, check status, set backlog size |
+| **ausearch** | Query tool for searching audit logs by message type, user, file, key, or time range |
+| **aureport** | Reporting tool that generates aggregate summaries for triage and compliance |
+| **audit rule key (-k)** | User-defined label on audit rules for fast filtering with ausearch and aureport |
+| **augenrules** | Merges `/etc/audit/rules.d/` files into `audit.rules` and loads into the kernel |
+
+## Verification
+
+- [ ] auditd is running and rules are loaded (`auditctl -l` returns expected rule count)
+- [ ] No audit backlog overflow (`auditctl -s` shows lost: 0)
+- [ ] ausearch returns events for each custom key
+- [ ] aureport generates non-empty summaries for authentication, executable, and file events
+- [ ] Timeline reconstruction produces a coherent chronological sequence
+- [ ] Critical file watches trigger alerts on test modifications
+- [ ] Logs are forwarding to central SIEM
+- [ ] Audit rules persist across reboot (rules in `/etc/audit/rules.d/`)

skills/detecting-oauth-token-theft/SKILL.md

@@ -14,20 +14,158 @@ license: Apache-2.0
 
 # Detecting OAuth Token Theft
 
-Analyze OAuth sign-in telemetry for indicators of token theft including
-impossible travel, device fingerprint changes, and token replay attacks.
-
-
 ## When to Use
 
-- When investigating security incidents that require detecting oauth token theft
+- Investigating alerts for impossible travel or anomalous token usage in Microsoft Entra ID
-- When building detection rules or threat hunting queries for this domain
+- Responding to a suspected session hijacking or pass-the-cookie attack
-- When SOC analysts need structured procedures for this analysis type
+- Configuring proactive defenses against OAuth token theft in an Azure/M365 environment
-- When validating security monitoring coverage for related attack techniques
+- Detecting OAuth device code phishing campaigns that bypass MFA
+- Analyzing sign-in logs for token replay indicators
+- Implementing Token Protection conditional access policies to bind tokens to devices
+
+**Do not use** for on-premises Kerberos ticket attacks (pass-the-ticket, golden ticket); use Active Directory-specific investigation techniques for those scenarios.
 
 ## Prerequisites
 
-- Familiarity with identity security concepts and tools
+- Microsoft Entra ID P2 license (required for Identity Protection risk detections and conditional access)
-- Access to a test or lab environment for safe execution
+- Global Administrator or Security Administrator role in the Entra admin center
-- Python 3.8+ with required dependencies installed
+- Microsoft Defender for Cloud Apps (MDCA) license for session anomaly detection
-- Appropriate authorization for any testing activities
+- Access to Entra ID Sign-in Logs and Audit Logs (Diagnostic Settings to Log Analytics or Sentinel)
+- Familiarity with OAuth 2.0 authorization flows (authorization code, device code, client credentials)
+
+## Workflow
+
+### Step 1: Understand the Token Theft Attack Surface
+
+Key token types and theft vectors:
+
+| Token Type | Lifetime | Theft Vector | Impact |
+|---|---|---|---|
+| Access Token | 60-90 min | Memory dump, proxy interception | API access for token lifetime |
+| Refresh Token | Up to 90 days | Browser cookie theft, malware | Persistent access |
+| Primary Refresh Token | Session-based | Mimikatz, AADInternals | Full SSO to all M365/Azure apps |
+| Session Cookie | Varies | XSS, AitM proxy | Full session hijacking |
+
+### Step 2: Configure Entra ID Sign-in Risk Detection
+
+Enable Identity Protection to flag anomalous token usage:
+
+```
+Entra Admin Center > Protection > Identity Protection > Risk Detections
+
+Key risk detections for token theft:
+- Anomalous Token        : Unusual token characteristics
+- Token Issuer Anomaly   : Token from unusual issuer
+- Unfamiliar Sign-in     : New location for user
+- Impossible Travel      : Geographically impossible sign-ins
+- Malicious IP Address   : Known malicious source
+```
+
+Configure risk-based conditional access:
+
+```
+Policy: "Block High-Risk Sign-ins"
+  Users: All users (exclude break-glass accounts)
+  Conditions: Sign-in Risk = High
+  Grant: Block access
+
+Policy: "Require MFA for Medium-Risk"
+  Conditions: Sign-in Risk = Medium
+  Grant: Require MFA + password change
+```
+
+### Step 3: Enable Token Protection
+
+Bind sign-in session tokens to device TPM:
+
+```
+Entra Admin Center > Protection > Conditional Access > New Policy
+
+Policy: "Enforce Token Protection"
+  Users: Pilot group (expand after validation)
+  Cloud Apps: Office 365 Exchange Online, SharePoint Online
+  Conditions: Device Platforms = Windows
+  Session: Require token protection for sign-in sessions
+  Grant: Require compliant or Hybrid Azure AD joined device
+```
+
+### Step 4: Detect Token Replay in Sign-in Logs
+
+KQL queries for Microsoft Sentinel or Log Analytics:
+
+```kusto
+// Detect anomalous token usage
+SigninLogs
+| where TimeGenerated > ago(7d)
+| where RiskDetail contains "token" or RiskEventTypes_V2 has "anomalousToken"
+| project TimeGenerated, UserPrincipalName, IPAddress, Location,
+          RiskDetail, RiskLevelDuringSignIn, AppDisplayName
+| sort by TimeGenerated desc
+
+// Detect impossible travel with token reuse
+SigninLogs
+| where TimeGenerated > ago(7d)
+| where ResultType == 0
+| summarize Locations=make_set(Location), IPs=make_set(IPAddress),
+            Count=count() by UserPrincipalName, bin(TimeGenerated, 1h)
+| where array_length(Locations) > 1
+
+// Detect device code flow abuse (phishing)
+SigninLogs
+| where TimeGenerated > ago(7d)
+| where AuthenticationProtocol == "deviceCode"
+| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName
+```
+
+### Step 5: Investigate and Respond
+
+```powershell
+# Revoke all refresh tokens for compromised user
+Connect-MgGraph -Scopes "User.ReadWrite.All"
+Revoke-MgUserSignInSession -UserId "user@contoso.com"
+
+# Force password reset
+Update-MgUser -UserId "user@contoso.com" -PasswordProfile @{
+    ForceChangePasswordNextSignIn = $true
+}
+
+# Review and revoke malicious OAuth app consent grants
+Get-MgUserOauth2PermissionGrant -UserId "user@contoso.com"
+Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<grant-id>"
+
+# Check for mail forwarding rules (common post-compromise action)
+Get-MgUserMailFolderRule -UserId "user@contoso.com" -MailFolderId "Inbox" |
+    Where-Object { $_.Actions.ForwardTo -ne $null }
+```
+
+### Step 6: Enable Continuous Access Evaluation (CAE)
+
+```
+Entra Admin Center > Protection > Conditional Access > Continuous Access Evaluation
+  Strictly enforce location policies: Enabled
+
+CAE triggers near-real-time token revocation when:
+- User account disabled/deleted
+- Password changed/reset
+- Admin explicitly revokes tokens
+- Identity Protection detects elevated risk
+```
+
+## Key Concepts
+
+| Term | Definition |
+|------|------------|
+| **Primary Refresh Token (PRT)** | Long-lived device-bound token providing SSO to all Azure AD apps |
+| **Token Protection** | Conditional access feature binding tokens to device TPM |
+| **Continuous Access Evaluation** | Near-real-time policy enforcement on token revocation |
+| **AitM (Adversary-in-the-Middle)** | Phishing that proxies auth flow to capture session cookies post-MFA |
+| **Device Code Flow** | OAuth grant for input-constrained devices; abused in phishing campaigns |
+
+## Verification
+
+- [ ] Identity Protection risk detections generating alerts for anomalous tokens
+- [ ] Conditional access policies block high-risk sign-ins and require MFA for medium-risk
+- [ ] Token Protection confirmed working (test from unregistered device fails)
+- [ ] KQL queries return results against synthetic anomaly events
+- [ ] CAE enabled and verified (revoke session, confirm access blocked within minutes)
+- [ ] Incident response runbook includes token revocation and OAuth consent review

skills/implementing-devsecops-security-scanning/SKILL.md

@@ -14,20 +14,190 @@ license: Apache-2.0
 
 # Implementing DevSecOps Security Scanning
 
-Automate SAST, SCA, container image, and secret scanning in CI/CD
-pipelines with fail/pass gates based on severity thresholds.
-
-
 ## When to Use
 
-- When deploying or configuring implementing devsecops security scanning capabilities in your environment
+- Setting up automated security scanning in a new or existing CI/CD pipeline
-- When establishing security controls aligned to compliance requirements
+- Shifting security left by catching vulnerabilities before production
-- When building or improving security architecture for this domain
+- Meeting compliance requirements (SOC 2, PCI-DSS, ISO 27001) mandating automated security testing
-- When conducting security assessments that require this implementation
+- Integrating SAST, DAST, and SCA for comprehensive application security coverage
+- Establishing security gates that block deployments with critical/high vulnerabilities
+
+**Do not use** as a replacement for manual penetration testing. Automated scanning catches common patterns but cannot replace human-driven assessments for business logic flaws.
 
 ## Prerequisites
 
-- Familiarity with application security concepts and tools
+- CI/CD platform: GitHub Actions, GitLab CI, Jenkins, or Azure DevOps
-- Access to a test or lab environment for safe execution
+- Container runtime (Docker) for running scanning tools
-- Python 3.8+ with required dependencies installed
+- A staging environment URL for DAST scanning
-- Appropriate authorization for any testing activities
+- Tool requirements: Semgrep (free), Trivy (free), OWASP ZAP (free), Gitleaks (free)
+
+## Workflow
+
+### Step 1: Add Secrets Detection with Gitleaks
+
+```yaml
+# .github/workflows/security.yml
+name: DevSecOps Security Pipeline
+on:
+  push:
+    branches: [main, develop]
+  pull_request:
+    branches: [main]
+
+jobs:
+  secrets-scan:
+    name: Secrets Detection (Gitleaks)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - name: Run Gitleaks
+        uses: gitleaks/gitleaks-action@v2
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+```
+
+### Step 2: Add SAST Scanning with Semgrep
+
+```yaml
+  sast-scan:
+    name: SAST (Semgrep)
+    runs-on: ubuntu-latest
+    container:
+      image: semgrep/semgrep
+    steps:
+      - uses: actions/checkout@v4
+      - name: Run Semgrep SAST scan
+        run: |
+          semgrep scan \
+            --config p/security-audit \
+            --config p/owasp-top-ten \
+            --severity ERROR \
+            --error \
+            --json --output semgrep-results.json .
+      - uses: actions/upload-artifact@v4
+        if: always()
+        with:
+          name: semgrep-results
+          path: semgrep-results.json
+```
+
+### Step 3: Add SCA and Container Scanning with Trivy
+
+```yaml
+  sca-scan:
+    name: SCA & Container Scan (Trivy)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Trivy filesystem scan (dependencies)
+        uses: aquasecurity/trivy-action@0.28.0
+        with:
+          scan-type: 'fs'
+          scan-ref: '.'
+          severity: 'CRITICAL,HIGH'
+          exit-code: '1'
+          format: 'json'
+          output: 'trivy-fs-results.json'
+      - name: Build and scan container image
+        run: |
+          docker build -t app:${{ github.sha }} .
+      - uses: aquasecurity/trivy-action@0.28.0
+        with:
+          image-ref: 'app:${{ github.sha }}'
+          severity: 'CRITICAL,HIGH'
+          exit-code: '1'
+```
+
+### Step 4: Add DAST Scanning with OWASP ZAP
+
+```yaml
+  dast-scan:
+    name: DAST (OWASP ZAP)
+    runs-on: ubuntu-latest
+    needs: [deploy-staging]
+    steps:
+      - uses: actions/checkout@v4
+      - name: ZAP Baseline Scan
+        uses: zaproxy/action-baseline@v0.14.0
+        with:
+          target: ${{ vars.STAGING_URL }}
+          rules_file_name: '.zap/rules.tsv'
+```
+
+Configure `.zap/rules.tsv` alert thresholds:
+
+```tsv
+40012	FAIL	(Cross Site Scripting - Reflected)
+40014	FAIL	(Cross Site Scripting - Persistent)
+40018	FAIL	(SQL Injection)
+90019	FAIL	(Server Side Code Injection)
+10038	FAIL	(Content Security Policy Header Not Set)
+```
+
+### Step 5: Enforce Security Gates
+
+```yaml
+  security-gate:
+    name: Security Gate
+    runs-on: ubuntu-latest
+    needs: [secrets-scan, sast-scan, sca-scan]
+    if: always()
+    steps:
+      - name: Check scan results
+        run: |
+          if [[ "${{ needs.secrets-scan.result }}" == "failure" ]]; then
+            echo "BLOCKED: Secrets detected"; exit 1
+          fi
+          if [[ "${{ needs.sast-scan.result }}" == "failure" ]]; then
+            echo "BLOCKED: SAST critical/high findings"; exit 1
+          fi
+          if [[ "${{ needs.sca-scan.result }}" == "failure" ]]; then
+            echo "BLOCKED: Vulnerable dependencies"; exit 1
+          fi
+          echo "All security gates passed"
+```
+
+### Step 6: Configure Pre-commit Hooks
+
+```yaml
+# .pre-commit-config.yaml
+repos:
+  - repo: https://github.com/gitleaks/gitleaks
+    rev: v8.22.1
+    hooks:
+      - id: gitleaks
+  - repo: https://github.com/semgrep/semgrep
+    rev: v1.102.0
+    hooks:
+      - id: semgrep
+        args: ['--config', 'p/security-audit', '--error']
+```
+
+```bash
+pip install pre-commit
+pre-commit install
+pre-commit run --all-files
+```
+
+## Key Concepts
+
+| Term | Definition |
+|------|------------|
+| **SAST** | Static Application Security Testing - analyzes source code without execution |
+| **DAST** | Dynamic Application Security Testing - tests running applications |
+| **SCA** | Software Composition Analysis - scans dependencies for known vulnerabilities |
+| **SBOM** | Software Bill of Materials - inventory of all components |
+| **Shift Left** | Moving security testing earlier in the SDLC |
+| **Security Gate** | CI/CD checkpoint blocking deployment on scan failures |
+
+## Verification
+
+- [ ] Gitleaks blocks commits containing hardcoded secrets
+- [ ] Semgrep runs on every PR and reports findings
+- [ ] Trivy detects known-vulnerable dependencies
+- [ ] OWASP ZAP baseline scan runs against staging URL
+- [ ] Security gate blocks merges when critical/high findings exist
+- [ ] Branch protection rules enforce required status checks
+- [ ] Pre-commit hooks catch issues locally before push

skills/implementing-privileged-session-monitoring/SKILL.md

@@ -14,20 +14,176 @@ license: Apache-2.0
 
 # Implementing Privileged Session Monitoring
 
-Monitor privileged sessions (SSH, RDP, database) with real-time command
-logging, anomaly detection, session recording, and compliance reporting.
-
-
 ## When to Use
 
-- When deploying or configuring implementing privileged session monitoring capabilities in your environment
+- Deploying session recording for all privileged access to critical servers and databases
-- When establishing security controls aligned to compliance requirements
+- Meeting compliance requirements (PCI-DSS 10.2, SOX, HIPAA, ISO 27001) mandating privileged activity monitoring
-- When building or improving security architecture for this domain
+- Investigating incidents where an administrator may have performed unauthorized actions
-- When conducting security assessments that require this implementation
+- Implementing real-time alerting for high-risk commands during privileged sessions
+- Establishing a forensic audit trail of all administrative actions on production infrastructure
+
+**Do not use** for monitoring standard user sessions; use EDR/UBA for general user behavior monitoring.
 
 ## Prerequisites
 
-- Familiarity with identity access management concepts and tools
+- CyberArk PAM or Privilege Cloud with Digital Vault, or open-source alternative (Teleport)
-- Access to a test or lab environment for safe execution
+- PSM (Privileged Session Manager) or PSMP installed on hardened jump server
-- Python 3.8+ with required dependencies installed
+- Network architecture routing all privileged access through the PSM proxy
-- Appropriate authorization for any testing activities
+- Sufficient storage for recordings (estimate: 50-250 KB/min for RDP, 5-20 KB/min for SSH)
+
+## Workflow
+
+### Step 1: Route All Privileged Access Through PSM
+
+```
+Architecture:
+  Admin User --> PVWA (Web Portal) --> PSM (Jump Server) --> Target Server
+
+Network Controls:
+  - DENY direct RDP (3389) / SSH (22) to targets from user networks
+  - ALLOW RDP/SSH to targets ONLY from PSM server IPs
+  - ALLOW PVWA access (443) from admin user networks
+```
+
+### Step 2: Configure PSM Connection Components
+
+```
+PVWA > Administration > Connection Components
+
+For Windows RDP:
+  Connection Component: PSM-RDP
+  Record Sessions: Yes
+  Recording Format: AVI (video) + Keystrokes (text)
+  Record Windows Titles: Yes
+
+For Linux SSH:
+  Connection Component: PSM-SSH
+  Record Sessions: Yes
+  Record Unix Commands: Yes
+```
+
+### Step 3: Configure Session Recording Policies
+
+```
+PVWA > Platform Management > Session Management
+
+  Enable Session Recording: Yes
+  Keystroke Logging: Enable Transcript + Window Events
+  Storage: Vault (encrypted, tamper-proof)
+
+  Retention periods (per compliance):
+    PCI-DSS:  1 year available, 3 months accessible
+    SOX:      7 years
+    HIPAA:    6 years
+
+  Per-Safe policies:
+    Production-Servers-Admin: Record all, real-time monitoring
+    Third-Party-Vendor-Access: Record all, dual authorization required
+```
+
+### Step 4: Enable Real-Time Monitoring and Alerting
+
+Configure CyberArk Privileged Threat Analytics (PTA):
+
+```
+PTA > Configuration > Security Events
+
+Rule: High-Risk Command Detected
+  Trigger patterns:
+    - rm -rf /
+    - chmod 777
+    - useradd / passwd root
+    - wget http* | sh / curl * | bash
+    - nc -e /bin/sh
+  Action: Alert SOC + Flag session as high-risk
+
+Rule: Credential Access Attempt
+  Trigger:
+    - mimikatz.exe
+    - procdump.exe targeting lsass
+    - ntdsutil.exe
+  Action: Terminate session + Alert SOC + Lock account
+
+Rule: Unusual Session Duration
+  Trigger: Session > 4 hours
+  Action: Alert SOC for review
+```
+
+### Step 5: Configure Session Review Workflow
+
+```
+PVWA > Recordings > Search and Review
+
+Review features:
+  - Video playback with timeline scrubbing
+  - Keystroke transcript alongside video
+  - Window title log for application tracking
+  - Risk events highlighted on timeline
+  - Text search within keystroke transcript
+  - Auditor can mark: Reviewed-OK, Suspicious, Requires-Investigation
+```
+
+### Step 6: Open-Source Alternative - Teleport
+
+```yaml
+# /etc/teleport.yaml
+teleport:
+  nodename: teleport-proxy.corp.internal
+
+auth_service:
+  enabled: yes
+  session_recording: "node-sync"
+  audit_sessions_uri: "s3://teleport-session-recordings/sessions?region=us-east-1"
+  enhanced_recording:
+    enabled: true
+    command_events: true
+    network_events: true
+```
+
+```bash
+# List recorded sessions
+tsh recordings ls --from=2026-03-15
+
+# Play back a session
+tsh play <session-id>
+
+# Export session events for SIEM
+tsh recordings export <session-id> --format=json > session_events.json
+```
+
+### Step 7: Forward Session Metadata to SIEM
+
+```
+CyberArk PTA > SIEM Integration
+  Protocol: TCP + TLS (Syslog CEF)
+  Destination: siem.corp.internal:6514
+
+Events forwarded:
+  - Session start/stop with user, target, duration
+  - High-risk command alerts
+  - Session termination events
+  - Dual-authorization approvals/denials
+```
+
+## Key Concepts
+
+| Term | Definition |
+|------|------------|
+| **PSM** | Privileged Session Manager - proxy recording all sessions in video and text |
+| **PSMP** | PSM for SSH Proxy - Linux-based proxy for SSH, SCP, SFTP sessions |
+| **PTA** | Privileged Threat Analytics - behavioral analytics and risk scoring for sessions |
+| **Dual Authorization** | Two authorized users must approve before a privileged session is established |
+| **Session Isolation** | All admin access proxied through PAM; no direct connections to targets |
+| **Keystroke Transcript** | Searchable text log of all keystrokes during a recorded session |
+
+## Verification
+
+- [ ] All privileged access routes through PSM (direct RDP/SSH blocked by firewall)
+- [ ] Session recordings stored encrypted with tamper protection
+- [ ] Keystroke transcripts captured and searchable for SSH and RDP
+- [ ] PTA rules trigger alerts for high-risk commands (test with benign trigger)
+- [ ] Real-time monitoring dashboard shows active sessions with correct metadata
+- [ ] Recordings play back in PVWA HTML5 player with timeline and transcript
+- [ ] Retention policies match compliance requirements
+- [ ] Dual authorization enforced for vendor and high-risk access
+- [ ] Session metadata and alerts forwarding to SIEM