BIS Journal №4(55)2024

12 октября, 2024

От кариеса до пульпита. Заметки безопасника

В конце прошлой заметки я упомянул о теневой инфраструктуре. Сегодня поговорим о не совсем очевидной её части — учётных записях (УЗ). Они очень важны, так как фактически являются ключом для входа, в ряде случаев — напрямую из интернета. Рассмотрим несколько типичных проблем.

 

АКТУАЛЬНЫЙ ВЛАДЕЛЕЦ

Прежде всего, это банальное обеспечение того, чтобы у каждого аккаунта был указан актуальный владелец. «Ничейные» УЗ могут стать лёгкой добычей злоумышленников. Вот пример: в SOC поступил алерт из Azure о подозрительном входе в систему. Соответствующий аккаунт временно заблокировали, а в ходе расследования установили, что:

  • попытка входа была успешной (то есть УЗ действительно была скомпрометирована);
  • аккаунт был неиспользуемым (так как спустя несколько месяцев никто так и не попросил его разблокировать).

 

ACTIVE DIRECTORY

Второй аспект касается Active Directory: неплохо бы периодически проводить аудиты состояния учётных записей в ней. Пример: произошёл инцидент, в ходе которого была скомпрометирована УЗ администратора домена. Затем при очередном аудите AD было обнаружено, что у этой УЗ были изменены определённые параметры, что позволяло злоумышленнику подобрать пароль доменного администратора значительно быстрей обычного. Выявлено это было так: команда Get-Aduser сгенерировала дамп всех учётных записей AD, после чего было проанализировано поле User Account Control. Несмотря на большое количество пользователей, упомянутое поле имело всего порядка 5–6 уникальных значений, а подозрительный флаг присутствовал лишь у скомпрометированной УЗ.

Ещё пример: в ходе пентеста «белые шляпки» обнаружили, что пароли у нескольких сервисных учётных записей были указаны прямо в поле «комментарий» в Active Directory. Надо ли говорить, что после обнаружения этого факта взлом сети пошёл куда веселее…

 

ЛОКАЛЬНЫЕ УЗ

Ну и третий момент — это локальные учётные записи. Отследить их появление и использование значительно труднее, чем в случае централизованных аккаунтов. Да, они обладают меньшим «радиусом действия», но могут доставить немало головной боли. Один из примеров здесь — это практика использования сотрудниками техподдержки аккаунта локального администратора, который имеет одинаковое имя и пароль на всех ПК и серверах. Скомпрометировав любой хост и узнав этот пароль, злоумышленник автоматически получает административный доступ на любом другом хосте сети, куда ему удалось попасть. Одним из возможных решений проблемы называют LAPS; впрочем, организаций, сумевших это внедрить, я видел немного.

Другой пример: как-то раз я запросил у администраторов СУБД список пользователей, имеющих разрешение на обращение к определённой базе данных. Мне прислали список из нескольких сотен активных локальных УЗ, в котором фигурировали имена вроде с, test, victor и так далее. Кому все эти аккаунты принадлежат и какие из них можно отключить, никто, конечно же, не знал.

Поддержание порядка и обеспечение необходимого документирования — дело непростое, и о нём часто забывают под гнётом более приоритетных задач. До поры до времени это можно игнорировать — однако если пустить всё на самотёк, то рано или поздно инфраструктура деградирует настолько, что единственным вариантом останется создавать с нуля новую. Это подобно кариесу, который без должного лечения с большой вероятностью перерастёт в пульпит (а то и чего похуже). На мой взгляд, специалисты и особенно менеджеры ИБ должны постоянно напоминать руководству компании о рисках недостаточного документирования изменений.

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

13.11.2024
ЛК и АМТ-ГРУП совместно защитят АСУ ТП и промышленные объекты
13.11.2024
Скамеры учатся работать с возражениями
13.11.2024
Иран огласил сроки начала приёма «мировых» карт в стране
12.11.2024
Правкомиссия одобрила проект поправок о налогообложении криптотранзакций
12.11.2024
Хакер сёрфит на утечке. Волновой эффект инцидента MOVEit Transfer всё ещё силён
12.11.2024
Иранские хакеры DDoS-ят израильскую финансовую инфраструктуру
12.11.2024
До трети фейкового мобильного ПО — сервисы телеком-компаний
12.11.2024
В России готовят стандарты промышленного ПО и средств АСУ ТП
11.11.2024
Расходы на российские софт и хард зачтут с двойным коэффициентом
11.11.2024
Минцифры (не) меняет правила. Как поправки играют сразу в обе стороны

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных