Wednesday, 14:20, the third day of the internal pentest in the fintech company. Through Responder and NTM relay, I get foothold at the work station of an accountant - a standard bundle for initial access in the internal network. By 15:00 - full Dampdam Bitwarden vault: 340 records, including credentials to AWS-console, production-base PostgreSQL and corporate Jira. EDR worked at the station, SIEM collected events, MFA is included on all critical services. The opt-out point is the unlocked password manager in Chrome and the debugging port that no alters has covered.
According to Positive Technologies, 97% of companies that passed the pentest in 2024-2025 have problems with the password policy, and 70% of the risk level is critical. Corporate password manager without khardening and monitoring is not a means of protection, but a single point of compromise of the entire infrastructure.
Surface attack of corporate password manager
Kill chain: where is credential access through vault
Pentest password manager is not a separate discipline. This is the stage of credential access in the already running chain: the attacker received an initial access (phishing, NTLM relay, compromised VPN), entrenched himself on the workstation and is looking for a pivot point for lateral movement.
According to the MITRE ATT&CK matrix attacks on the corporate password storage cover a whole cluster of techniques:
• T1555.005 - Password Managers (Credential Access): direct retrieval of data from vault through extension, CLI or API
• T1539 - Steal Web Session Cookie (Creddential Access): interception of the web-vanult session
• T1552.001 - Credentials In Files (Credential Access): exported vault files, session-tools CLI-utility in the file system
• T1056.001 - Keylogging (Collection, Credential Access): Interception of master passwords at the input
• T1078 - Valid Accounts (Defense Evasion, Persistence, Privilege Escalation, Initial Access): use stolen from vault credentials for lateral movement
• T1621 - MFA Request Generation (Credential Access): MFA-bombing after receiving a password from vault
Real chain: initial access -> foothold -> T1555.005 (Password Managers) -> T1078 (Valid Accounts) -> domain admin. The password manager here works as an animator: one dump replaces the Kerberoasting and AS-REP Rosating watches.
Why 1Password, Bitwarden and CyberArk
Three products are three different architectural classes, each with its own attack surface:
Behind the review framework: KeePass (no centralized management - non-standard enterprise class), LastPass (a separate story after public incidents), Keeper and Dashlane (architecturally close to 1Password, would duplicate the analysis). CyberArk is chosen as the most common PAM in the Russian enterprise - Delinea and BeyondTrust met me on pentests much less often.
Attacks on browser extension: vulnerabilities 1Password Business and Bitwarden Enterprise
[Applicable: internal pentest, post-exploitation, grey box]
Predictions: foothold at the workstation with an extension of the password manager. The extension is unlocked - the user entered a master password and did not set up auto-blocking by timeaut. Chrome is running.
Chrome DevTools Protocol - from foothold to vault dam
Chrome DevTools Protocol (CDP) allows you to programmatically interact with the browser, including access to the context of extensions. If Chrome is running with a flag --remote-debugging-port or the attacker can attach the debugger - a straight path opens to the deciphered vault content.
Adjustments to the environment: Windows 10/11 or GNU/Linux, Chrome/Chromium with an active process, current user rights (admin-privileges are not needed), localhost access to the debugging port.
# Check the availability of Chrome's debug port
curl -s http://127.0.0.1:9222/json | python3 -m json.tool
# Search among Bitwarden's extension targets
curl -s http://127.0.0.1:9222/json \
| python3 -c "
import sys, json
for t in json.load(sys.stdin):
if 'bitwarden' in t.get('title','').lower():
print(t['title'], t.get('webSocketDebuggerUrl',''))
"
Connecting via WebSocket to the background page of the Bitwarden extension, call Runtime.evaluate to contact the internal storage. If vault is unlocked, the decryption keys are in the memory of the background-process of the expansion. Through Runtime.evaluate in the context of the background page dammed the internal API (for example, CipherService.getAllDecrypted()) and receive decrypted records; chrome.storage.local contains only encrypted ciphers. Next is JSON parsing and export.
If the debugging port is not open - Chrome can restart with --remote-debugging-port=9222 if there is a code execution in the context of the user. But it's noisy.
When the technique is NOT working:
• CrowdStrike Falcon - detects Chrome launches with --remote-debugging-portthrough the rules on command-line arguments of the process
• SentinelOne - a similar detection through the behavioral engine
• Elastic 8.x+ Endpoint Security - fixes through process_startedwith filter by argument
• 1Password Desktop - uses a separate native process to expand (not in the context of Chrome), CDP attack is not directly applicable. Here you need Frida: joining the process of the desktop client and intercepting the calls of the internal API decryption
• Chrome Enterprise with Politics DevToolsAvailability = 2- blocks debugging ports at the level of group policy
XSS autocomplete and CLI-tokens as a vector credential access
XSS -> autocomplete - a vector that I've used three times over the past year. We find XSS in an enterprise web application (portal, CRM, internal wiki), inject the hidden shape with fields username and password. If the password manager is set to autocomplete for the domain - credentials enter hidden fields without user interaction.
Difference in product behavior:
• BitwardenBitwarden: When the "Auto-fill on page load" is filled automatically - the hidden form receives credentials without a single click. By default, the setting is turned off, but in half of the transaction of corporate companies it is activated "for the convenience of employees"
• 1Password1Password: In browser extension mode, does not fill in the iframe default forms and requires explicit user action via popup. Operation via XSS is significantly more difficult
Restriction: if the auto-fill on page load is off (Bitwarden) and inline-menu requires a click (1Password) - XSS-vector for autocomplete does not work.
CLI to tokens - a separate story for DevOps-surroundings. Bitwarden CLI stores session token in variable BW_SESSION. On GNU/Linux it can be pulled through cat /proc/<pid>/environ | tr '\0' '\n' | grep BW_SESSION, on Windows - through the WMI-request to the variables of the process environment. Receiving a token, the attacker performs bw list items --session <token> - full dump waut without knowledge of master password (T1552.001)
1Password CLI (op) in versions v2+ uses system keychain (macOS Keychain, Windows Credential Manager) - interception is much more complicated. But in legacy installations v1 session token was exported to variable OP_SESSION_<account> and was available through /proc/<pid>/environ (analogue BW_SESSION) On the pentest check the presence of old configurations: ~/.config/op/config contains the account metadata and the device keys, and migration to v2 does not delete legacy files automatically.
CyberArk pentest: RBAC myconfigurations and escalation of privileges
[Applicable: internal pentest, grey box with domain account data]
CyberArk PAM is a different architecture and other vectors. There is no Browser extension, but there is PVWA (Password Vault Web Access), CPM (Central Policy Manager) and PSM (Privileged Session Manager). Each component is a potential entry point.
Typical myconfigurations from real-world projects:
1. CPM service accounts with excessive privileges - the CPM account often has the rights of Vault Admin instead of the minimum necessary. If there is an SPN on this account - Kerberoasting (T1558.003) gives a ticket, and then offline brute-force (T11100.002) and full access to vault
2. PVWA is available from the user VLAN - there is no network segmentation, any employee with a browser sees the administrative interface of CyberArk
3. PSM-sessions are not monitored by SOC - the records of privileged sessions are created, but not analyzed. The attacker uses compromised homageously accounts
4. Master Policy on default parameters - the frequency of password rotation and complexity requirements for accounts of the company are insufficient
Escalation vector in grey box: through the LDAP list, we find the members of the "CyberArk Vault Admins" group in Active Directory. If one of the accounts is subject to Kerberoasting - we get a password, log in to PVWA, the dampim is all cremodentials. Time from domain user to vault admin: 2 to 6 hours in three projects over the past year.
RestrictionCyberArk Enterprise with customized PTA (Privileged Threat Analytics) detects abnormal patterns in real time. Without PTA - detection only with a retrospective analysis of incidents.
Detection-checklist: password manager audit in SIEM
Each password manager pentest should include check: does SOC monitor the actions with vault? In my experience, in four out of five organizations, the answer is “no”. Vault is just in a blind spot.
Correlation rules and insider case
Key events for product monitoring:
1Password Business (Events API): vault.export, item.batch_read (more than 20 records per minute - anomaly), signin.failed (series), device.new, recovery.initiated, two_factor_disabled
Bitwarden Enterprise (Syslog / Admin Console): export_vault, login_failed (series), organization_updated, two_factor_disabled, cipher.batch_read
CyberArk (Syslog, CEF): Retrieve Password, CPM Password Change, PSM Connect, Logon with atypical src_ip, Safe Member Added
Example of the rule for Splunk - export vault and mass reading outside of working hours:
Code:
index=bitwarden_audit OR index=onepassword_events
action IN ("vault.export", "export_vault", "item.batch_read")
| where NOT match(user, "^(backup-svc|admin-pm)$")
| eval is_offhours=if(date_hour<8 OR date_hour>20, "yes", "no")
| where is_offhours="yes" OR action IN ("vault.export", "export_vault")
| stats count by user, src_ip, action
| where count > 0
For Elastic 8.x+, a similar rule is created through Detection Rules with KQL filter event.action
"vault.export" OR "export_vault"). Time-based filtering is implemented through the parameters of the rule level additional and the conditions, and not inside the KQL request - a frequent error when migrating rules from Splunk, where date_hour works inline.
Insider with vault admin rights - a separate case that SOC misses almost always. The vault administrator does not break anything technically, not triggerite alerta on bruteforce or abnormal IP. It simply uses legitimate rights to export or mass reading.
Detection approach: baseline normal behavior of each admin. If admin A usually reads 5-10 entries per day and today read 200 is an anomaly. Implementation: ML Jobs in Elastic or | eventstats avg(count) as baseline + threshold values in Splunk. For CyberArk: each Retrieve Password from an account with the Vault Admin role, not tied to an open incident or change request, is a reason for the investigation.
According to Positive Technologies, 97% of companies that passed the pentest in 2024-2025 have problems with the password policy, and 70% of the risk level is critical. Corporate password manager without khardening and monitoring is not a means of protection, but a single point of compromise of the entire infrastructure.
Surface attack of corporate password manager
Kill chain: where is credential access through vault
Pentest password manager is not a separate discipline. This is the stage of credential access in the already running chain: the attacker received an initial access (phishing, NTLM relay, compromised VPN), entrenched himself on the workstation and is looking for a pivot point for lateral movement.
According to the MITRE ATT&CK matrix attacks on the corporate password storage cover a whole cluster of techniques:
• T1555.005 - Password Managers (Credential Access): direct retrieval of data from vault through extension, CLI or API
• T1539 - Steal Web Session Cookie (Creddential Access): interception of the web-vanult session
• T1552.001 - Credentials In Files (Credential Access): exported vault files, session-tools CLI-utility in the file system
• T1056.001 - Keylogging (Collection, Credential Access): Interception of master passwords at the input
• T1078 - Valid Accounts (Defense Evasion, Persistence, Privilege Escalation, Initial Access): use stolen from vault credentials for lateral movement
• T1621 - MFA Request Generation (Credential Access): MFA-bombing after receiving a password from vault
Real chain: initial access -> foothold -> T1555.005 (Password Managers) -> T1078 (Valid Accounts) -> domain admin. The password manager here works as an animator: one dump replaces the Kerberoasting and AS-REP Rosating watches.
Why 1Password, Bitwarden and CyberArk
Three products are three different architectural classes, each with its own attack surface:
Behind the review framework: KeePass (no centralized management - non-standard enterprise class), LastPass (a separate story after public incidents), Keeper and Dashlane (architecturally close to 1Password, would duplicate the analysis). CyberArk is chosen as the most common PAM in the Russian enterprise - Delinea and BeyondTrust met me on pentests much less often.
Attacks on browser extension: vulnerabilities 1Password Business and Bitwarden Enterprise
[Applicable: internal pentest, post-exploitation, grey box]
Predictions: foothold at the workstation with an extension of the password manager. The extension is unlocked - the user entered a master password and did not set up auto-blocking by timeaut. Chrome is running.
Chrome DevTools Protocol - from foothold to vault dam
Chrome DevTools Protocol (CDP) allows you to programmatically interact with the browser, including access to the context of extensions. If Chrome is running with a flag --remote-debugging-port or the attacker can attach the debugger - a straight path opens to the deciphered vault content.
Adjustments to the environment: Windows 10/11 or GNU/Linux, Chrome/Chromium with an active process, current user rights (admin-privileges are not needed), localhost access to the debugging port.
# Check the availability of Chrome's debug port
curl -s http://127.0.0.1:9222/json | python3 -m json.tool
# Search among Bitwarden's extension targets
curl -s http://127.0.0.1:9222/json \
| python3 -c "
import sys, json
for t in json.load(sys.stdin):
if 'bitwarden' in t.get('title','').lower():
print(t['title'], t.get('webSocketDebuggerUrl',''))
"
Connecting via WebSocket to the background page of the Bitwarden extension, call Runtime.evaluate to contact the internal storage. If vault is unlocked, the decryption keys are in the memory of the background-process of the expansion. Through Runtime.evaluate in the context of the background page dammed the internal API (for example, CipherService.getAllDecrypted()) and receive decrypted records; chrome.storage.local contains only encrypted ciphers. Next is JSON parsing and export.
If the debugging port is not open - Chrome can restart with --remote-debugging-port=9222 if there is a code execution in the context of the user. But it's noisy.
When the technique is NOT working:
• CrowdStrike Falcon - detects Chrome launches with --remote-debugging-portthrough the rules on command-line arguments of the process
• SentinelOne - a similar detection through the behavioral engine
• Elastic 8.x+ Endpoint Security - fixes through process_startedwith filter by argument
• 1Password Desktop - uses a separate native process to expand (not in the context of Chrome), CDP attack is not directly applicable. Here you need Frida: joining the process of the desktop client and intercepting the calls of the internal API decryption
• Chrome Enterprise with Politics DevToolsAvailability = 2- blocks debugging ports at the level of group policy
XSS autocomplete and CLI-tokens as a vector credential access
XSS -> autocomplete - a vector that I've used three times over the past year. We find XSS in an enterprise web application (portal, CRM, internal wiki), inject the hidden shape with fields username and password. If the password manager is set to autocomplete for the domain - credentials enter hidden fields without user interaction.
Difference in product behavior:
• BitwardenBitwarden: When the "Auto-fill on page load" is filled automatically - the hidden form receives credentials without a single click. By default, the setting is turned off, but in half of the transaction of corporate companies it is activated "for the convenience of employees"
• 1Password1Password: In browser extension mode, does not fill in the iframe default forms and requires explicit user action via popup. Operation via XSS is significantly more difficult
Restriction: if the auto-fill on page load is off (Bitwarden) and inline-menu requires a click (1Password) - XSS-vector for autocomplete does not work.
CLI to tokens - a separate story for DevOps-surroundings. Bitwarden CLI stores session token in variable BW_SESSION. On GNU/Linux it can be pulled through cat /proc/<pid>/environ | tr '\0' '\n' | grep BW_SESSION, on Windows - through the WMI-request to the variables of the process environment. Receiving a token, the attacker performs bw list items --session <token> - full dump waut without knowledge of master password (T1552.001)
1Password CLI (op) in versions v2+ uses system keychain (macOS Keychain, Windows Credential Manager) - interception is much more complicated. But in legacy installations v1 session token was exported to variable OP_SESSION_<account> and was available through /proc/<pid>/environ (analogue BW_SESSION) On the pentest check the presence of old configurations: ~/.config/op/config contains the account metadata and the device keys, and migration to v2 does not delete legacy files automatically.
CyberArk pentest: RBAC myconfigurations and escalation of privileges
[Applicable: internal pentest, grey box with domain account data]
CyberArk PAM is a different architecture and other vectors. There is no Browser extension, but there is PVWA (Password Vault Web Access), CPM (Central Policy Manager) and PSM (Privileged Session Manager). Each component is a potential entry point.
Typical myconfigurations from real-world projects:
1. CPM service accounts with excessive privileges - the CPM account often has the rights of Vault Admin instead of the minimum necessary. If there is an SPN on this account - Kerberoasting (T1558.003) gives a ticket, and then offline brute-force (T11100.002) and full access to vault
2. PVWA is available from the user VLAN - there is no network segmentation, any employee with a browser sees the administrative interface of CyberArk
3. PSM-sessions are not monitored by SOC - the records of privileged sessions are created, but not analyzed. The attacker uses compromised homageously accounts
4. Master Policy on default parameters - the frequency of password rotation and complexity requirements for accounts of the company are insufficient
Escalation vector in grey box: through the LDAP list, we find the members of the "CyberArk Vault Admins" group in Active Directory. If one of the accounts is subject to Kerberoasting - we get a password, log in to PVWA, the dampim is all cremodentials. Time from domain user to vault admin: 2 to 6 hours in three projects over the past year.
RestrictionCyberArk Enterprise with customized PTA (Privileged Threat Analytics) detects abnormal patterns in real time. Without PTA - detection only with a retrospective analysis of incidents.
Detection-checklist: password manager audit in SIEM
Each password manager pentest should include check: does SOC monitor the actions with vault? In my experience, in four out of five organizations, the answer is “no”. Vault is just in a blind spot.
Correlation rules and insider case
Key events for product monitoring:
1Password Business (Events API): vault.export, item.batch_read (more than 20 records per minute - anomaly), signin.failed (series), device.new, recovery.initiated, two_factor_disabled
Bitwarden Enterprise (Syslog / Admin Console): export_vault, login_failed (series), organization_updated, two_factor_disabled, cipher.batch_read
CyberArk (Syslog, CEF): Retrieve Password, CPM Password Change, PSM Connect, Logon with atypical src_ip, Safe Member Added
Example of the rule for Splunk - export vault and mass reading outside of working hours:
Code:
index=bitwarden_audit OR index=onepassword_events
action IN ("vault.export", "export_vault", "item.batch_read")
| where NOT match(user, "^(backup-svc|admin-pm)$")
| eval is_offhours=if(date_hour<8 OR date_hour>20, "yes", "no")
| where is_offhours="yes" OR action IN ("vault.export", "export_vault")
| stats count by user, src_ip, action
| where count > 0
For Elastic 8.x+, a similar rule is created through Detection Rules with KQL filter event.action
"vault.export" OR "export_vault"). Time-based filtering is implemented through the parameters of the rule level additional and the conditions, and not inside the KQL request - a frequent error when migrating rules from Splunk, where date_hour works inline.Insider with vault admin rights - a separate case that SOC misses almost always. The vault administrator does not break anything technically, not triggerite alerta on bruteforce or abnormal IP. It simply uses legitimate rights to export or mass reading.
Detection approach: baseline normal behavior of each admin. If admin A usually reads 5-10 entries per day and today read 200 is an anomaly. Implementation: ML Jobs in Elastic or | eventstats avg(count) as baseline + threshold values in Splunk. For CyberArk: each Retrieve Password from an account with the Vault Admin role, not tied to an open incident or change request, is a reason for the investigation.
