Похищенный сеанс может оставаться пригодным для использования даже после смены пароля. Узнайте, как связаны изоляция устройства, аннулирование токенов, управление сеансами приложений и восстановление доступа к аккаунту.
В веб-приложении сеанс может оставаться активным после смены пароля аккаунта. В зависимости от своих возможностей инфостилер может собирать сохранённые пароли, а также cookie сеансов, токены аутентификации, ключи API и другие локальные данные. Если эти данные уже покинули устройство, удаление вредоносной программы не делает их недействительными.
Пароль — это секрет, который предъявляют при аутентификации. Токен доступа позволяет приложению обращаться к определённым ресурсам, а токен обновления — получать новый токен доступа, если протокол это допускает. Сеанс приложения обычно поддерживается с помощью отдельного cookie или секрета сеанса, выданного после аутентификации. Эти механизмы могут относиться к одному аккаунту, но у них не обязательно совпадают сроки действия и средства отзыва.
Какой доступ может сохраниться после смены пароля?
Смена пароля предотвращает новые входы, для которых нужен старый пароль. При этом нельзя считать, что она аннулирует все действующие токены и завершает все активные сеансы приложений. Согласно рекомендациям Microsoft по экстренному ограничению доступа в Entra, блокировка новых входов и отзыв токенов обновления не позволяют пользователю получать новые токены Entra. Однако уже выданный токен доступа может работать до истечения стандартного срока действия — одного часа. Continuous Access Evaluation может сократить этот период в поддерживаемых сценариях Microsoft 365, но не гарантирует мгновенного аннулирования каждого токена.
Cookie сеанса, выданный приложением, требует отдельных мер. Entra не может напрямую отозвать токен сеанса, выданный самим приложением. NIST SP 800-63B-4 описывает такое же разделение в федеративных системах: поставщик удостоверений (IdP) и полагающаяся сторона (RP) независимо создают и завершают свои сеансы. Завершение сеанса у поставщика удостоверений само по себе не завершает сеансы всех подключённых приложений.
Это различие может использовать злоумышленник. В материалах MITRE ATT&CK описано, как похищенный cookie веб-сеанса, который всё ещё действует и допускает повторное использование, можно импортировать в браузер под контролем злоумышленника. Поскольку сеанс уже прошёл аутентификацию, в некоторых схемах аутентификации новая проверка MFA может не потребоваться. Это описание возможности, а не доказательство захвата конкретного аккаунта.
Изоляция устройства и меры управления аккаунтом
Устройство, на котором подозревают заражение, изолируют в соответствии с планом реагирования на инциденты организации, одновременно оценивая необходимость сохранения относящихся к инциденту доказательств. Если аккаунт обладает привилегиями или даёт доступ к чувствительным данным, блокировать новые входы и закрывать текущие пути доступа могут начать ещё до завершения полного анализа устройства. Пароли меняют, доступ к аккаунту восстанавливают, а административные действия выполняют с доверенного устройства и по доверенному каналу, чтобы новые учётные данные не попали в систему, где подозревают заражение.
Данные для доступа, хранящиеся на устройстве
Проверка не ограничивается паролями, сохранёнными после предполагаемого периода заражения. Точный момент начала заражения может быть неизвестен, а инфостилер способен получить доступ к учётным данным, которые уже хранились на устройстве. С учётом данных об инциденте проверяют профили браузеров, аккаунты, которые использовались на устройстве или хранились локально, cookie сеансов, токены и ключи API. Очистка устройства или переустановка системы на нём не делает недействительными пароли, токены или ключи, которые уже могли быть похищены.
Управление токенами и сеансами
С помощью описанных в документации средств поставщика удостоверений блокируют новые входы, аннулируют токены обновления, если такая возможность поддерживается, и завершают сеансы IdP. Затем отдельно проверяют критически важные приложения и завершают их собственные сеансы средствами самих приложений. Сообщение «Успешно» в интерфейсе администрирования не доказывает, что весь доступ прекращён. По-прежнему важно учитывать тип токена, ожидаемые условия истечения его срока действия и момент, когда каждое приложение вновь потребует аутентификацию.
Пароль и другие данные для доступа, относящиеся к инциденту, меняют или аннулируют с доверенного устройства. Нужно ли при этом менять или аннулировать ключ API, токен разработчика либо другие локально сохранённые учётные данные, зависит от данных об инциденте и поведения затронутой системы. Цель — не вслепую сбросить доступ ко всем аккаунтам, а определить, какие пароли, токены, ключи или cookie сеансов могли покинуть устройство и оставаться пригодными для использования.
Изменения для закрепления в аккаунте
Злоумышленник может создать дополнительный путь доступа к аккаунту, вместо того чтобы полагаться только на текущий сеанс. Рекомендации Microsoft по реагированию на компрометацию почтового аккаунта Microsoft 365 предусматривают проверку незнакомых методов и устройств MFA, нежелательных разрешений на доступ, выданных приложениям, несанкционированных административных ролей, переадресации почты и скрытых правил для входящих писем. Этот список относится именно к Microsoft 365; аналогичные средства и результаты их применения у разных поставщиков отличаются.
Незнакомый или подозрительный метод MFA удаляют или делают недействительным. Если нужно заново зарегистрировать метод законного пользователя, сначала через доверенный канал восстановления проверяют принадлежность аккаунта, а затем регистрируют только новый метод, который контролирует этот пользователь. Повторная регистрация метода, добавленного злоумышленником, сохранила бы путь доступа, а не закрыла его.
MFA не завершает активный сеанс
MFA создаёт дополнительный барьер для начала нового сеанса с похищенным паролем, но сама по себе не делает недействительным cookie ранее аутентифицированного сеанса, допускающий повторное использование. Методы MFA также обеспечивают разную защиту. NIST в своих требованиях к аутентификаторам не считает вводимые вручную одноразовые коды устойчивыми к фишингу и приводит WebAuthn/FIDO2 как пример аутентификации с такой устойчивостью. Более надёжная аутентификация защищает будущие входы, но похищенный сеанс, который всё ещё действует, необходимо завершить отдельно.
Что можно — и чего нельзя — установить по журналам
Если доступны записи о входах и значимых для безопасности действиях за период инцидента, они могут выявить необычные местоположения, время активности, разрешения приложениям и изменения в аккаунте. Для Microsoft 365 поставщик рекомендует не сужать область первоначального поиска в журнале аудита слишком рано и просматривать записи с момента начала подозрительной активности до завершения мер по устранению последствий. Отсутствие подозрительных событий в результатах поиска не доказывает, что аккаунт в безопасности. Результат имеет смысл только с учётом доступной телеметрии, срока хранения данных, проверенных источников и выбранного периода.
Точно так же свидетельства того, что учётные данные или cookie стали доступны посторонним, сами по себе не доказывают успешного несанкционированного использования или захвата аккаунта. Раскрытие данных, наблюдаемые попытки их использования и подтверждённый захват аккаунта — разные ситуации. Для путей доступа, которые потенциально остаются действующими, всё равно нужны соразмерные меры реагирования; их объём определяется привилегиями аккаунта, чувствительностью данных и имеющимися доказательствами. LeakData в своём руководстве по оценке ситуации после утечки рассматривает более общее различие между раскрытием данных и подтверждённым неправомерным использованием.
В отчёте об инциденте перечисляют сеансы, завершённые у поставщика удостоверений и в приложениях, ожидаемые условия истечения срока действия токенов, отменённые несанкционированные изменения и пробелы в проверке журналов. Так становится понятно, по каким путям доступа приняты меры и какие вопросы остаются открытыми.