[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2qe2z6qho9oqw":3},{"success":4,"posts":5,"pagination":56,"availableLocales":59},true,[6],{"_id":7,"slug":8,"title":9,"excerpt":10,"content":11,"coverImage":12,"authorName":13,"authorType":14,"publicationKind":15,"category":16,"tags":17,"metaDescription":22,"metaKeywords":23,"isFeatured":28,"publishedAt":29,"createdAt":30,"updatedAt":29,"readTime":31,"viewCount":32,"contentLocale":33,"availableLocales":34,"hasEnglishTranslation":4,"translations":44},"ca1ba9756e09172be1d6dc5a","why-password-change-may-not-end-infostealer-access","Почему смена пароля не всегда закрывает доступ инфостилеру","Похищенный сеанс может оставаться пригодным для использования даже после смены пароля. Узнайте, как связаны изоляция устройства, аннулирование токенов, управление сеансами приложений и восстановление доступа к аккаунту.","\u003Cp>В веб-приложении сеанс может оставаться активным после смены пароля аккаунта. В зависимости от своих возможностей инфостилер может собирать сохранённые пароли, а также cookie сеансов, токены аутентификации, ключи API и другие локальные данные. Если эти данные уже покинули устройство, удаление вредоносной программы не делает их недействительными.\u003C\u002Fp>\u003Cp>Пароль — это секрет, который предъявляют при аутентификации. Токен доступа позволяет приложению обращаться к определённым ресурсам, а токен обновления — получать новый токен доступа, если протокол это допускает. Сеанс приложения обычно поддерживается с помощью отдельного cookie или секрета сеанса, выданного после аутентификации. Эти механизмы могут относиться к одному аккаунту, но у них не обязательно совпадают сроки действия и средства отзыва.\u003C\u002Fp>\u003Ch2>Какой доступ может сохраниться после смены пароля?\u003C\u002Fh2>\u003Cp>Смена пароля предотвращает новые входы, для которых нужен старый пароль. При этом нельзя считать, что она аннулирует все действующие токены и завершает все активные сеансы приложений. Согласно \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fidentity\u002Fusers\u002Fusers-revoke-access\">рекомендациям Microsoft по экстренному ограничению доступа в Entra\u003C\u002Fa>, блокировка новых входов и отзыв токенов обновления не позволяют пользователю получать новые токены Entra. Однако уже выданный токен доступа может работать до истечения стандартного срока действия — одного часа. Continuous Access Evaluation может сократить этот период в поддерживаемых сценариях Microsoft 365, но не гарантирует мгновенного аннулирования каждого токена.\u003C\u002Fp>\u003Cp>Cookie сеанса, выданный приложением, требует отдельных мер. Entra не может напрямую отозвать токен сеанса, выданный самим приложением. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fsession\u002F\">NIST SP 800-63B-4\u003C\u002Fa> описывает такое же разделение в федеративных системах: поставщик удостоверений (IdP) и полагающаяся сторона (RP) независимо создают и завершают свои сеансы. Завершение сеанса у поставщика удостоверений само по себе не завершает сеансы всех подключённых приложений.\u003C\u002Fp>\u003Cp>Это различие может использовать злоумышленник. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1550\u002F004\u002F\">В материалах MITRE ATT&CK описано\u003C\u002Fa>, как похищенный cookie веб-сеанса, который всё ещё действует и допускает повторное использование, можно импортировать в браузер под контролем злоумышленника. Поскольку сеанс уже прошёл аутентификацию, в некоторых схемах аутентификации новая проверка MFA может не потребоваться. Это описание возможности, а не доказательство захвата конкретного аккаунта.\u003C\u002Fp>\u003Ch2>Изоляция устройства и меры управления аккаунтом\u003C\u002Fh2>\u003Cp>Устройство, на котором подозревают заражение, изолируют в соответствии с планом реагирования на инциденты организации, одновременно оценивая необходимость сохранения относящихся к инциденту доказательств. Если аккаунт обладает привилегиями или даёт доступ к чувствительным данным, блокировать новые входы и закрывать текущие пути доступа могут начать ещё до завершения полного анализа устройства. Пароли меняют, доступ к аккаунту восстанавливают, а административные действия выполняют с доверенного устройства и по доверенному каналу, чтобы новые учётные данные не попали в систему, где подозревают заражение.\u003C\u002Fp>\u003Ch3>Данные для доступа, хранящиеся на устройстве\u003C\u002Fh3>\u003Cp>Проверка не ограничивается паролями, сохранёнными после предполагаемого периода заражения. Точный момент начала заражения может быть неизвестен, а инфостилер способен получить доступ к учётным данным, которые уже хранились на устройстве. С учётом данных об инциденте проверяют профили браузеров, аккаунты, которые использовались на устройстве или хранились локально, cookie сеансов, токены и ключи API. Очистка устройства или переустановка системы на нём не делает недействительными пароли, токены или ключи, которые уже могли быть похищены.\u003C\u002Fp>\u003Ch3>Управление токенами и сеансами\u003C\u002Fh3>\u003Cp>С помощью описанных в документации средств поставщика удостоверений блокируют новые входы, аннулируют токены обновления, если такая возможность поддерживается, и завершают сеансы IdP. Затем отдельно проверяют критически важные приложения и завершают их собственные сеансы средствами самих приложений. Сообщение «Успешно» в интерфейсе администрирования не доказывает, что весь доступ прекращён. По-прежнему важно учитывать тип токена, ожидаемые условия истечения его срока действия и момент, когда каждое приложение вновь потребует аутентификацию.\u003C\u002Fp>\u003Cp>Пароль и другие данные для доступа, относящиеся к инциденту, меняют или аннулируют с доверенного устройства. Нужно ли при этом менять или аннулировать ключ API, токен разработчика либо другие локально сохранённые учётные данные, зависит от данных об инциденте и поведения затронутой системы. Цель — не вслепую сбросить доступ ко всем аккаунтам, а определить, какие пароли, токены, ключи или cookie сеансов могли покинуть устройство и оставаться пригодными для использования.\u003C\u002Fp>\u003Ch3>Изменения для закрепления в аккаунте\u003C\u002Fh3>\u003Cp>Злоумышленник может создать дополнительный путь доступа к аккаунту, вместо того чтобы полагаться только на текущий сеанс. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fdefender-office-365\u002Fresponding-to-a-compromised-email-account\">Рекомендации Microsoft по реагированию на компрометацию почтового аккаунта Microsoft 365\u003C\u002Fa> предусматривают проверку незнакомых методов и устройств MFA, нежелательных разрешений на доступ, выданных приложениям, несанкционированных административных ролей, переадресации почты и скрытых правил для входящих писем. Этот список относится именно к Microsoft 365; аналогичные средства и результаты их применения у разных поставщиков отличаются.\u003C\u002Fp>\u003Cp>Незнакомый или подозрительный метод MFA удаляют или делают недействительным. Если нужно заново зарегистрировать метод законного пользователя, сначала через доверенный канал восстановления проверяют принадлежность аккаунта, а затем регистрируют только новый метод, который контролирует этот пользователь. Повторная регистрация метода, добавленного злоумышленником, сохранила бы путь доступа, а не закрыла его.\u003C\u002Fp>\u003Ch2>MFA не завершает активный сеанс\u003C\u002Fh2>\u003Cp>MFA создаёт дополнительный барьер для начала нового сеанса с похищенным паролем, но сама по себе не делает недействительным cookie ранее аутентифицированного сеанса, допускающий повторное использование. Методы MFA также обеспечивают разную защиту. NIST в своих \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fauthenticators\u002F\">требованиях к аутентификаторам\u003C\u002Fa> не считает вводимые вручную одноразовые коды устойчивыми к фишингу и приводит WebAuthn\u002FFIDO2 как пример аутентификации с такой устойчивостью. Более надёжная аутентификация защищает будущие входы, но похищенный сеанс, который всё ещё действует, необходимо завершить отдельно.\u003C\u002Fp>\u003Ch2>Что можно — и чего нельзя — установить по журналам\u003C\u002Fh2>\u003Cp>Если доступны записи о входах и значимых для безопасности действиях за период инцидента, они могут выявить необычные местоположения, время активности, разрешения приложениям и изменения в аккаунте. Для Microsoft 365 поставщик рекомендует не сужать область первоначального поиска в журнале аудита слишком рано и просматривать записи с момента начала подозрительной активности до завершения мер по устранению последствий. Отсутствие подозрительных событий в результатах поиска не доказывает, что аккаунт в безопасности. Результат имеет смысл только с учётом доступной телеметрии, срока хранения данных, проверенных источников и выбранного периода.\u003C\u002Fp>\u003Cp>Точно так же свидетельства того, что учётные данные или cookie стали доступны посторонним, сами по себе не доказывают успешного несанкционированного использования или захвата аккаунта. Раскрытие данных, наблюдаемые попытки их использования и подтверждённый захват аккаунта — разные ситуации. Для путей доступа, которые потенциально остаются действующими, всё равно нужны соразмерные меры реагирования; их объём определяется привилегиями аккаунта, чувствительностью данных и имеющимися доказательствами. LeakData в своём \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fleakdata.io\u002Fen\u002Fblog\u002Fwhat-is-a-data-breach-what-to-do-if-your-email-was-leaked\">руководстве по оценке ситуации после утечки\u003C\u002Fa> рассматривает более общее различие между раскрытием данных и подтверждённым неправомерным использованием.\u003C\u002Fp>\u003Cp>В отчёте об инциденте перечисляют сеансы, завершённые у поставщика удостоверений и в приложениях, ожидаемые условия истечения срока действия токенов, отменённые несанкционированные изменения и пробелы в проверке журналов. Так становится понятно, по каким путям доступа приняты меры и какие вопросы остаются открытыми.\u003C\u002Fp>\u003Ch2>Источники\u003C\u002Fh2>\u003Cul>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fidentity\u002Fusers\u002Fusers-revoke-access\">Microsoft Learn — Экстренный отзыв доступа пользователя в Microsoft Entra ID\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fdefender-office-365\u002Fresponding-to-a-compromised-email-account\">Microsoft Learn — Реагирование на компрометацию почтового аккаунта в Microsoft 365\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fsession\u002F\">NIST SP 800-63B-4 — Управление сеансами\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fauthenticators\u002F\">NIST SP 800-63B-4 — Требования к аутентификаторам\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1550\u002F004\u002F\">MITRE ATT&CK T1550.004 — Cookie веб-сеанса\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fspecopssoft.com\u002Fblog\u002Finside-infostealer-attacks\u002F\">Specops Software — Атаки инфостилеров изнутри\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>","\u002Fuploads\u002Fblog\u002Finfostealer-sonrasi-parola-degisikligi-neden-yetmeyebilir-dfdf6bda3fb759147214.webp","Команда безопасности LeakData","Organization","blog","güvenlik",[18,19,20,21],"инфостилер","реагирование на инциденты","безопасность сеансов","идентификация и доступ","Почему смена пароля не всегда закрывает доступ инфостилеру. Роль изоляции устройства, отзыва токенов, завершения сеансов и устранения закрепления.",[24,25,26,27],"реагирование на инциденты с инфостилерами","аннулирование токенов","похищенный cookie сеанса","смена пароля",false,"2026-10-09T16:49:52.841Z","2026-09-16T23:36:22.537Z",6,0,"ru",[35,36,37,38,39,40,41,42,43,33],"en","tr","zh","hi","es","ar","fr","bn","pt",{"en":45,"tr":46,"zh":48,"hi":49,"es":50,"ar":51,"fr":52,"bn":53,"pt":54,"ru":55},{"slug":8},{"slug":47},"infostealer-sonrasi-parola-degisikligi-neden-yetmeyebilir",{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"page":57,"limit":58,"total":57,"pages":57},1,12,[35,36,37,38,39,40,41,42,43,33]]