From a1e9ca5a4a931bf9c392a378aae3903573c30237 Mon Sep 17 00:00:00 2001 From: mukul975 Date: Thu, 19 Mar 2026 14:12:17 +0100 Subject: [PATCH] Expand 4 remaining SKILL.md stubs with researched content --- .../SKILL.md | 222 +++++++++++++++++- skills/detecting-oauth-token-theft/SKILL.md | 162 ++++++++++++- .../SKILL.md | 194 ++++++++++++++- .../SKILL.md | 180 +++++++++++++- 4 files changed, 710 insertions(+), 48 deletions(-) diff --git a/skills/analyzing-linux-audit-logs-for-intrusion/SKILL.md b/skills/analyzing-linux-audit-logs-for-intrusion/SKILL.md index 0ad999a9..6eedbd7d 100644 --- a/skills/analyzing-linux-audit-logs-for-intrusion/SKILL.md +++ b/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 -- When building detection rules or threat hunting queries for this domain -- When SOC analysts need structured procedures for this analysis type -- When validating security monitoring coverage for related attack techniques +- Investigating suspected unauthorized access or privilege escalation on Linux hosts +- Hunting for evidence of exploitation, backdoor installation, or persistence mechanisms +- Auditing compliance with security baselines (CIS, STIG, PCI-DSS) that require system call monitoring +- 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 -- Access to a test or lab environment for safe execution -- Python 3.8+ with required dependencies installed -- Appropriate authorization for any testing activities +- Linux system with `auditd` package installed and the audit daemon running (`systemctl status auditd`) +- Root or sudo access to configure audit rules and query logs +- Audit rules deployed via `/etc/audit/rules.d/*.rules` or loaded with `auditctl` +- 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 -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/`) diff --git a/skills/detecting-oauth-token-theft/SKILL.md b/skills/detecting-oauth-token-theft/SKILL.md index e95a2a60..df1df069 100644 --- a/skills/detecting-oauth-token-theft/SKILL.md +++ b/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 -- When building detection rules or threat hunting queries for this domain -- When SOC analysts need structured procedures for this analysis type -- When validating security monitoring coverage for related attack techniques +- Investigating alerts for impossible travel or anomalous token usage in Microsoft Entra ID +- Responding to a suspected session hijacking or pass-the-cookie attack +- Configuring proactive defenses against OAuth token theft in an Azure/M365 environment +- 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 -- Access to a test or lab environment for safe execution -- Python 3.8+ with required dependencies installed -- Appropriate authorization for any testing activities +- Microsoft Entra ID P2 license (required for Identity Protection risk detections and conditional access) +- Global Administrator or Security Administrator role in the Entra admin center +- Microsoft Defender for Cloud Apps (MDCA) license for session anomaly detection +- 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 "" + +# 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 diff --git a/skills/implementing-devsecops-security-scanning/SKILL.md b/skills/implementing-devsecops-security-scanning/SKILL.md index 5cc94bd3..6097ed74 100644 --- a/skills/implementing-devsecops-security-scanning/SKILL.md +++ b/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 -- When establishing security controls aligned to compliance requirements -- When building or improving security architecture for this domain -- When conducting security assessments that require this implementation +- Setting up automated security scanning in a new or existing CI/CD pipeline +- Shifting security left by catching vulnerabilities before production +- Meeting compliance requirements (SOC 2, PCI-DSS, ISO 27001) mandating automated security testing +- 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 -- Access to a test or lab environment for safe execution -- Python 3.8+ with required dependencies installed -- Appropriate authorization for any testing activities +- CI/CD platform: GitHub Actions, GitLab CI, Jenkins, or Azure DevOps +- Container runtime (Docker) for running scanning tools +- A staging environment URL for DAST scanning +- 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 diff --git a/skills/implementing-privileged-session-monitoring/SKILL.md b/skills/implementing-privileged-session-monitoring/SKILL.md index 7d07f537..5dff7b61 100644 --- a/skills/implementing-privileged-session-monitoring/SKILL.md +++ b/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 -- When establishing security controls aligned to compliance requirements -- When building or improving security architecture for this domain -- When conducting security assessments that require this implementation +- Deploying session recording for all privileged access to critical servers and databases +- Meeting compliance requirements (PCI-DSS 10.2, SOX, HIPAA, ISO 27001) mandating privileged activity monitoring +- Investigating incidents where an administrator may have performed unauthorized actions +- 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 -- Access to a test or lab environment for safe execution -- Python 3.8+ with required dependencies installed -- Appropriate authorization for any testing activities +- CyberArk PAM or Privilege Cloud with Digital Vault, or open-source alternative (Teleport) +- PSM (Privileged Session Manager) or PSMP installed on hardened jump server +- Network architecture routing all privileged access through the PSM proxy +- 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 + +# Export session events for SIEM +tsh recordings export --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