Статья Пентест менеджера паролей: атаки и харденинг 1Password, Bitwarden и CyberArk

Среда, 14:20, третий день внутреннего пентеста в финтех-компании. Через Responder и NTLM relay получаю foothold на рабочей станции бухгалтера - стандартная связка для initial access во внутренней сети. К 15:00 - полный дамп Bitwarden vault: 340 записей, включая credentials к AWS-консоли, продакшн-базам PostgreSQL и корпоративному Jira. EDR на станции работал, SIEM собирал события, MFA включён на всех критичных сервисах. Точка отказа - разблокированное расширение менеджера паролей в Chrome и отладочный порт, который ни один алерт не покрывал.

По данным Positive Technologies, у 97% компаний, прошедших пентест в 2024–2025 годах, обнаружены проблемы с парольной политикой, причём у 70% уровень риска - критический. Корпоративный менеджер паролей без харденинга и мониторинга - не средство защиты, а единая точка компрометации всей инфраструктуры.

Поверхность атаки корпоративного менеджера паролей​

Kill chain: где стоит credential access через vault​

Пентест менеджера паролей - не отдельная дисциплина. Это этап credential access в уже идущей цепочке: атакующий получил initial access (фишинг, NTLM relay, скомпрометированный VPN), закрепился на рабочей станции и ищет pivot point для lateral movement.

По матрице MITRE ATT&CK атаки на корпоративное хранилище паролей покрывают целый кластер техник:

• T1555.005 - Password Managers (Credential Access): прямое извлечение данных из vault через расширение, CLI или API
• T1539 - Steal Web Session Cookie (Credential Access): перехват сессии веб-vault'а
• T1552.001 - Credentials In Files (Credential Access): экспортированные vault-файлы, session-токены CLI-утилит в файловой системе
• T1056.001 - Keylogging (Collection, Credential Access): перехват мастер-пароля при вводе
• T1078 - Valid Accounts (Defense Evasion, Persistence, Privilege Escalation, Initial Access): использование украденных из vault credentials для lateral movement
• T1621 - MFA Request Generation (Credential Access): MFA-бомбинг после получения пароля из vault

Реальная цепочка: initial access -> foothold -> T1555.005 (Password Managers) -> T1078 (Valid Accounts) -> domain admin. Менеджер паролей тут работает как мультипликатор: один дамп заменяет часы Kerberoasting и AS-REP Roasting.

Почему именно 1Password, Bitwarden и CyberArk​

Три продукта - три разных архитектурных класса, каждый со своей поверхностью атаки:

Критерий	1Password Business	Bitwarden Enterprise	CyberArk PAM
Архитектура	Zero-knowledge, SRP-протокол	Zero-knowledge, open source	Vault Server, session broker
Расширение браузера	Отдельный процесс, изоляция	Стандартное расширение Chrome	Нет (PVWA через браузер)
CLI	op - token в системном keychain	bw - session token экспортируется пользователем в переменную окружения BW_SESSION	PACLI, REST API
SIEM-интеграция	Events API	Event Logs, Syslog	Нативная (Syslog, CEF)
Аудит исходного кода	Проприетарный, внешние аудиты	Open source	Проприетарный
Типичный вектор на пентесте	CDP + расширение, Frida	CDP + расширение, BW_SESSION	RBAC мисконфигурация, PVWA

За рамками обзора: KeePass (нет централизованного управления - не enterprise-класс), LastPass (отдельная история после публичных инцидентов), Keeper и Dashlane (архитектурно близки к 1Password, дублировали бы анализ). CyberArk выбран как наиболее распространённый PAM в российском enterprise - Delinea и BeyondTrust встречались мне на пентестах значительно реже.

Атаки на browser extension: уязвимости 1Password Business и Bitwarden Enterprise​

[Применимо: внутренний пентест, post-exploitation, grey box]

Предусловия: foothold на рабочей станции с установленным расширением менеджера паролей. Расширение разблокировано - пользователь ввёл мастер-пароль и не настроил автоблокировку по таймауту. Chrome запущен.

Chrome DevTools Protocol - от foothold до vault dump​

Chrome DevTools Protocol (CDP) позволяет программно взаимодействовать с браузером, включая доступ к контексту расширений. Если Chrome запущен с флагом --remote-debugging-port или атакующий может присоединить отладчик - открывается прямой путь к расшифрованному содержимому vault.

Требования к окружению: Windows 10/11 или GNU/Linux, Chrome/Chromium с активным процессом, права текущего пользователя (admin-привилегии не нужны), доступ к localhost по порту отладки.

# Проверяем доступность отладочного порта Chrome
curl -s http://127.0.0.1:9222/json | python3 -m json.tool
# Ищем Bitwarden среди 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',''))
"

Подключившись через WebSocket к background page расширения Bitwarden, вызываем Runtime.evaluate для обращения к internal storage. Если vault разблокирован - ключи расшифровки сидят в памяти background-процесса расширения. Через Runtime.evaluate в контексте background page дёргаем internal API (например, CipherService.getAllDecrypted()) и получаем расшифрованные записи; chrome.storage.local содержит только зашифрованные ciphers. Дальше - парсинг JSON и экспорт.

Если отладочный порт не открыт - Chrome можно перезапустить с --remote-debugging-port=9222 при наличии code execution в контексте пользователя. Но это шумно.

Когда техника НЕ работает:

• CrowdStrike Falcon - детектирует запуск Chrome с --remote-debugging-port через правила на command-line аргументы процесса
• SentinelOne - аналогичная детекция через behavioral engine
• Elastic 8.x+ Endpoint Security - фиксирует через process_started с фильтром по аргументам
• 1Password Desktop - использует отдельный нативный процесс для расширения (не в контексте Chrome), CDP-атака неприменима напрямую. Тут нужен Frida: присоединение к процессу десктопного клиента и перехват вызовов internal API расшифровки
• Chrome Enterprise с политикой DevToolsAvailability = 2 - блокирует отладочные порты на уровне групповой политики

XSS автозаполнение и CLI-токены как вектор credential access​

XSS -> автозаполнение - вектор, который я применял трижды за последний год. Находим XSS в корпоративном веб-приложении (портал, CRM, внутренняя wiki), инжектируем скрытую форму с полями username и password. Если менеджер паролей настроен на автозаполнение для домена - credentials попадают в скрытые поля без взаимодействия пользователя.

Разница в поведении продуктов:

• Bitwarden: при включённой настройке "Auto-fill on page load" заполнение происходит автоматически - скрытая форма получает credentials без единого клика. По умолчанию настройка выключена, но в половине корпоративных deployment'ов её активируют "для удобства сотрудников"
• 1Password: в режиме browser extension не заполняет формы в iframe по умолчанию и требует явного действия пользователя через popup. Эксплуатация через XSS существенно сложнее

Ограничение: если auto-fill on page load выключен (Bitwarden) и inline-menu требует клика (1Password) - XSS-вектор на автозаполнение не работает.

CLI-токены - отдельная история для DevOps-окружений. Bitwarden CLI хранит session token в переменной BW_SESSION. На GNU/Linux его можно вытащить через cat /proc/<pid>/environ | tr '\0' '\n' | grep BW_SESSION, на Windows - через WMI-запрос к переменным среды процесса. Получив token, атакующий выполняет bw list items --session <token> - полный дамп vault без знания мастер-пароля (T1552.001).

1Password CLI (op) в версиях v2+ использует системный keychain (macOS Keychain, Windows Credential Manager) - перехват значительно сложнее. Но в legacy-инсталляциях v1 session token экспортировался в переменную OP_SESSION_<account> и был доступен через /proc/<pid>/environ (аналог BW_SESSION). На пентесте проверяйте наличие старых конфигураций: ~/.config/op/config содержит account metadata и device keys, а миграция на v2 не удаляет legacy-файлы автоматически.

CyberArk пентест: мисконфигурации RBAC и эскалация привилегий​

[Применимо: внутренний пентест, grey box с доменными учётными данными]

CyberArk PAM - другая архитектура и другие векторы. Browser extension нет, зато есть PVWA (Password Vault Web Access), CPM (Central Policy Manager) и PSM (Privileged Session Manager). Каждый компонент - потенциальная точка входа.

Типичные мисконфигурации из реальных проектов:

1. Сервисные аккаунты CPM с избыточными привилегиями - аккаунт CPM часто имеет права Vault Admin вместо минимально необходимых. При наличии SPN на этом аккаунте - Kerberoasting (T1558.003) даёт тикет, а дальше offline brute-force (T1110.002) и полный доступ к vault
2. PVWA доступен из пользовательского VLAN - отсутствует сетевая сегментация, любой сотрудник с браузером видит административный интерфейс CyberArk
3. PSM-сессии не мониторятся SOC - записи привилегированных сессий создаются, но не анализируются. Атакующий использует скомпрометированные managed accounts незаметно
4. Master Policy на дефолтных параметрах - частота ротации паролей и требования к сложности для managed accounts недостаточны

Вектор эскалации в grey box: через LDAP-перечисление находим членов группы "CyberArk Vault Admins" в Active Directory. Если один из аккаунтов подвержен Kerberoasting - получаем пароль, авторизуемся в PVWA, дампим все managed credentials. Время от доменного пользователя до vault admin: от 2 до 6 часов в трёх проектах за последний год.

Ограничение: CyberArk Enterprise с настроенным PTA (Privileged Threat Analytics) детектирует аномальные паттерны в реальном времени. Без PTA - обнаружение только при ретроспективном разборе инцидентов.

Detection-чеклист: аудит менеджера паролей в SIEM​

Каждый пентест менеджера паролей должен включать проверку: мониторит ли SOC действия с vault? По моему опыту - в четырёх из пяти организаций ответ "нет". Vault просто стоит в слепой зоне.

Правила корреляции и инсайдерский кейс​

Ключевые события для мониторинга по продуктам:

1Password Business (Events API): vault.export, item.batch_read (более 20 записей в минуту - аномалия), signin.failed (серия), device.new, recovery.initiated, two_factor_disabled

Bitwarden Enterprise (Syslog / Admin Console): export_vault, login_failed (серия), organization_updated, two_factor_disabled, cipher.batch_read

CyberArk (Syslog, CEF): Retrieve Password, CPM Password Change, PSM Connect, Logon с нетипичным src_ip, Safe Member Added

Пример правила для Splunk - экспорт vault и массовое чтение за пределами рабочих часов:

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

Для Elastic 8.x+ аналогичное правило создаётся через Detection Rules с KQL-фильтром event.action:("vault.export" OR "export_vault"). Time-based фильтрация реализуется через параметры rule schedule и additional conditions, а не внутри KQL-запроса - частая ошибка при миграции правил из Splunk, где date_hour работает inline.

Инсайдер с правами vault admin - отдельный кейс, который SOC упускает почти всегда. Администратор vault не ломает ничего технически, не триггерит алерты на bruteforce или аномальный IP. Он просто использует легитимные права для экспорта или массового чтения.

Detection-подход: baseline нормального поведения каждого admin. Если admin A обычно читает 5–10 записей в день, а сегодня прочитал 200 - это аномалия. Реализация: ML Jobs в Elastic или | eventstats avg(count) as baseline + пороговые значения в Splunk. Для CyberArk: каждое Retrieve Password от аккаунта с ролью Vault Admin, не привязанное к открытому инциденту или change request, - повод для расследования.

Харденинг 1Password Business, Bitwarden Enterprise и CyberArk: чеклист с приоритизацией​

Пункты [КРИТИЧНО] - закрыть в первую неделю после аудита менеджера паролей.

1Password Business:

1. [КРИТИЧНО] Включить Firewall Mode: доступ к vault только из корпоративной сети или VPN. Настройка: Settings -> Security -> Firewall
2. [КРИТИЧНО] Таймаут автоблокировки расширения: максимум 5 минут. Team Policies -> Lock after idle
3. [КРИТИЧНО] Запретить экспорт для всех кроме владельцев. Team Policies -> Allow vault export -> Deny
4. MFA через FIDO2/WebAuthn вместо TOTP
5. Events API -> SIEM-интеграция
6. Ревизия shared vaults: принцип минимальных привилегий
7. MDM-профиль: запрет установки расширения на неуправляемые браузеры

Bitwarden Enterprise:

1. [КРИТИЧНО] Отключить "Auto-fill on page load" через Organization Policy - закрывает XSS-вектор автозаполнения скрытых форм
2. [КРИТИЧНО] KDF iterations: минимум 600 000 (PBKDF2) или переключить на Argon2id. Для legacy-аккаунтов (созданных до февраля 2023) дефолт мог быть 100 000–200 000 - проверить и поднять до 600 000+. Для новых аккаунтов дефолт уже 600k, но Argon2id предпочтительнее
3. [КРИТИЧНО] Запретить экспорт: Organization Policy -> Disable Personal Vault Export
4. SSO через SAML/OIDC с привязкой к корпоративному IdP
5. Аудит-логи -> SIEM (Syslog или API)
6. Device Approvals: новые устройства требуют подтверждения администратора
7. Vault Timeout Policy: максимум 15 минут

CyberArk PAM:

1. [КРИТИЧНО] Ревизия RBAC: сервисные аккаунты CPM/PSM - минимальные права, не Vault Admin. Аудит через Get-PASAccountACL (модуль psPAS)
2. [КРИТИЧНО] Сегментация PVWA: доступ только из administrative VLAN, закрыть из пользовательского сегмента
3. [КРИТИЧНО] Включить PTA для детекции в реальном времени. Без PTA аномалии credential access не детектируются
4. Ротация managed accounts каждые 24 часа для критичных сервисов
5. PSM-записи: алерты на подозрительные команды в привилегированных сессиях
6. Syslog -> SIEM: минимум - события Retrieve Password, Logon, CPM Password Change
7. Dual control: доступ к критичным safes требует подтверждения второго администратора

Ограничение: для Bitwarden self-hosted чеклист нужно дополнять изоляцией сервера в отдельном VLAN и мониторингом обращений к базе данных vault напрямую (в обход API) - вектор, невозможный в SaaS-варианте.

Правовой контекст: vault содержит учётные данные сотрудников - персональные данные по ФЗ-152 (ст. 3). Компрометация квалифицируется как утечка ПДн с обязанностью уведомления Роскомнадзора (ст. 7). С учётом оборотных штрафов за утечки ПДн финансовый риск для среднего enterprise исчисляется миллионами рублей. Для субъектов КИИ по ФЗ-187 менеджер паролей, управляющий credentials к значимым объектам, попадает под надзор ФСТЭК (ст. 14) с плановыми и внеплановыми проверками.

Что делать прямо сейчас​

Пять шагов по приоритету, если корпоративный менеджер паролей уже развёрнут:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Первые четыре шага не требуют бюджета на закупки. Пятый - вопрос инвестиций, но без него остальные меры строятся на предположениях.

По моему опыту, главная проблема безопасности корпоративных менеджеров паролей - не в архитектуре продуктов и не в конкретных CVE. Организации воспринимают deployment как финальный шаг: "развернули Bitwarden - галочка поставлена". На деле это начало. Менеджер паролей без мониторинга, без политик экспорта и auto-fill, без SIEM-интеграции - не защита, а концентратор рисков. Один compromised endpoint с разблокированным расширением даёт больше credentials, чем месяц Kerberoasting.

За последний год я провёл аудит менеджера паролей в шести организациях. В пяти SOC не мониторил события vault вообще - ни экспорт, ни массовое чтение, ни подключение новых устройств. EDR настроен, SIEM собирал терабайты логов Windows и сетевого оборудования, а парольный менеджер стоял в абсолютной слепой зоне. В ближайший год атаки на vault-инфраструктуру станут стандартным элементом kill chain на внутренних пентестах - это самый эффективный pivot, где один дамп даёт credentials ко всему. Кто выстроит detection на уровне vault audit logs раньше - тот на шаг впереди. На codeby.net в треде по credential access detection разбирают Sigma-правила для мониторинга vault API и аномалий в парольных хранилищах - полезно, если строите этот слой detection с нуля.