CyberArk PTA — Threat Analytics, Credential Theft & Golden-Ticket Detection

The interview question that exposes who has actually run PTA

Senior interview: "Which PTA detection needs a Network Sensor or a Domain Controller agent — and what's the catch in 2026?"
Wrong answers: "All of them", "Suspected Credential Theft". Right answer: only Golden Ticket needs the network sensor or DC agent. SCT, Over-Pass-the-Hash and Unmanaged Privileged Account do not. The catch: CyberArk sunset the Network Sensor on 31 Dec 2022 and the DC agent on 31 Jul 2024. So Golden Ticket detection via PTA's own DPI is deprecated — modern shops feed Kerberos detection from Microsoft Defender for Identity into the same SIEM. Knowing this one fact separates a course-pass candidate from someone who has lived a go-live.

💡 The apartment chowkidar analogy — PTA in one image

Think of PTA as the chowkidar at a large Pune apartment complex. He knows everyone's rhythm — Sharma ji leaves at 8 AM, the second-floor family is back by 10 PM. When a resident suddenly enters at 3 AM, heads to the generator room they never visit, and leaves in two minutes, the chowkidar raises an alarm. PTA does exactly this for privileged users. It learns each account's behavioral baseline from 180 days of Vault history, then flags sharp deviations. The "lock the gate and call the manager" part is PTA's automated response — rotate the password, terminate the session — before the damage lands.

4 things you'll be tested on before we begin

① How PTA ingests data and scores risk

PTA is a dedicated, sole-purpose Linux appliance (RHEL 8.6+/9.2+, 8 cores, 16 GB RAM, 500 GB). It does not run any other software. It pulls four data streams: Vault activity over TCP 1858, Active Directory changes, Windows logon events forwarded from a Splunk heavy forwarder, and (historically) raw network traffic. It correlates them against the baseline and emits a risk-scored security event into the PVWA Security Events module and out to SIEM.

[SYSLOG]
SyslogTranslatorFile=Syslog\PTA.xsl
SyslogServerIP=10.50.2.100
SyslogServerPort=514
SyslogServerProtocol=UDP
SyslogMessageCodeFilter=295,308,7,24,31,428,361,359,427,471
# 295=Retrieve Password  428=Change Password  427=Reconcile  471=Initiate CPM change
# Restart the PrivateArk Server service after saving.

Vault data flow .............. GREEN
Events ingested last 60s ..... 1,284
Baseline build ............... in progress (day 1 of import)
Source 10.50.0.10:1858 ....... TLS_1_2 OK

② Golden Ticket — the forged 10-year master key

A Golden Ticket is like a master key forged in a back-alley workshop instead of the society's official key office. Normally every key comes from the authorized locksmith — the Kerberos KDC — with a serial number and an expiry. An attacker who steals the KRBTGT hash (usually via DCSync) mints a TGT valid for any user and any lifetime. Attackers love a 10-year ticket. PTA flags three tells: an impossible ticket lifetime, RC4 encryption in an AES domain, and TGS requests with no matching AS exchange.

③ Behavioral baseline — and the 3am unmanaged account

The baseline is everything. PTA builds a per-user profile from 180 days of Vault history: access times, source IPs, target machines, Safe patterns, session commands. Once "normal" is learned, anything off-pattern lifts the risk score. A brand-new local-admin account, created at 3 AM, connecting from a guest-WiFi laptop PTA has never seen — that spikes hard.

④ Automated response — suspend, rotate, terminate by severity

PTA doesn't just alert — it acts. The three canonical remediations are: UPA → onboard the account, SCT → rotate via CPM, SPC → reconcile via CPM. Session suspend/terminate is configured separately under Privileged Session Analysis and Response. All of it runs through two Vault service accounts — PTAUser (read-only) and PTAAppUser (the one that takes action).

When SCT or a Golden Ticket fires hot, a Splunk SOAR playbook can call the PVWA REST API to terminate the live PSM session and force an immediate rotation. That's the "gone in 12 minutes" containment CyberArk benchmarks against.

# 1. Authenticate to PVWA
POST https://pvwa.bank.internal/PasswordVault/API/auth/CyberArk/Logon
  { "username": "soc_api_svc", "password": "<from-vault>" }
  -> { "token": "eyJhbGciOiJIUzI1NiJ9..." }

# 2. Terminate the compromised session by GUID
POST https://pvwa.bank.internal/PasswordVault/API/LiveSessions/\
  a1b2c3d4-e5f6-7890-abcd-ef1234567890/Terminate
  Authorization: eyJhbGciOiJIUzI1NiJ9...

HTTP/1.1 200 OK
PSM session disconnected within seconds.
Session recording preserved in Vault for forensics.
Caller must be in PSM "Terminating Live Sessions Users and Groups".

⑤ Suspected Credential Theft — the OTP-step analogy

SCT works like the OTP step in your banking app. The bank knows you always log in from your home IP and phone. Log in with the right password from a cyber-café in another city without the OTP, and that's suspicious. PTA is the same: a privileged password must be checked out of the Vault (audit code 295) before it's used. If the password authenticates on a target but PTA sees no matching retrieve in the window, it raises SCT — someone used the credential without the authorized "OTP step". This is how PTA catches Pass-the-Hash and Mimikatz-harvested credentials.

# transforms.conf — route Windows security event IDs to PTA
[pta_syslog_filter]
REGEX    = EventCode=(4624|4720|4723|4724|4732|4728|4756|4964|4672)
DEST_KEY = _SYSLOG_ROUTING
FORMAT   = pta_syslog
# 4624=Logon  4672=Special privileges  4720=Account created  4728/4732=Group change
# Only Splunk is officially supported as the SCT logon-event source.

EVENT  Suspected Credentials Theft (SCT)
class  1   severity 8   risk 90/100
user   svc_dbadmin   target 10.50.18.22
note   no Vault Retrieve (295) in detection window -> rotate queued

Pause & Predict — think before you tap

⑥ SIEM / SOC integration — CEF syslog the right way

Every PTA event also leaves the box as syslog. The format is legacy BSD (RFC 3164, not RFC 5424) carrying a CEF payload. The destination is controlled by syslog_outbound in systemparm.properties — a JSON array, so you can fan out to Splunk and Sentinel at once. The killer field is cs3 = PTALink, a direct URL into the PVWA alert. Your SOC analyst clicks it and lands on the exact event.

# /etc/opt/pta/diamond-resources/local/systemparm.properties
syslog_outbound=[
  {"siem":"Splunk",   "format":"CEF", "host":"10.10.1.50", "port":514,  "protocol":"UDP"},
  {"siem":"Sentinel", "format":"CEF", "host":"10.10.1.75", "port":9301, "protocol":"TCP"}
]
# Apply + verify
service appmgr restart
service appmgr status

All services: RUNNING (mongodb, tomcat, nginx, activemq)
SIEM outbound: ACTIVE -> 10.10.1.50:514/UDP, 10.10.1.75:9301/TCP
Sample CEF: CEF:0|CyberArk|PTA|14.2|5|Golden Ticket|10|suser=svc_trading
            cs2Label=EventID cs2=GT-2024-0847 cs3Label=PTALink cs3=https://...

The 5 mistakes that cost L2/L3 candidates the PTA interview