Вы правы, команда stat с указанными параметрами выведет время доступа к файлу. Но в нашем случае метки к файлу дампа были изменены, поэтому опираться на них для определения момента выгрузки мы по понятным причинам не можем.
Наша рабочая гипотеза заключается в том, что дамп был выгружен 28.06.2024 после загрузки веб-шелла system.php в период с 11:36 до 11:42 по мск.
По результатам анализа логов за 2024 год успешных обращений к файлу, который содержит дамп БД сайта или его скачивания, не выявлены. Access-логи веб-сервера за 2023 год частично потерты. Мы продолжаем искать следы обращения к файлу и его скачивания, чтобы установить в какой момент атаки произошла компрометация файла.
В принципе pkexec возможно использовать и в headless режиме, все зависит от используемого дистрибутива и ПО. Если Вы планируете остановиться на воркэраунде, то Вам предварительно стоит уточнить нюансы использования polkit и его компонентов у мейнтейнеров используемых Вами дистрибутивов и ПО, и следовать их рекомендациям. Иначе применение воркэраунда остается на Ваш страх и риск. Лучше всего, конечно, установить актуальные патчи.
Уязвим именно pkexec, воркэраунд ломает тот функционал, где задействован pkexec (т.е. через него уже не получится получить повышенные привилегии). Например, управлении системными настройками в Вашем desktop environment через GUI может сломаться. Таким образом, лучше применить патч (хотя, как и в случае с log4shell высока вероятность, что фикс будет обойден). Наличие pkexec следует искать не в системных логах, а на файловой системе, например через
4ekin, спасибо за фидбэк! Конкретно табличка из статьи скорее показательная, чем реальная. Её задача — продемонстрировать подход к вычислению decay_rate под определенный тип инфраструктуры с определенным уровнем зрелости ИБ. Так, для инфраструктур с низким уровнем зрелости скорость выхода срока годности индикаторов будет ниже, чем у более зрелых. Понятно, что для полностью захардеренной инфраструктуры с отлаженными процессами реагирования на инциденты, патчинга, управления уязвимостями и т.п списать эксплуатируемый индикатор можно раньше, чем для инфраструктуры с базовыми методами защиты, т.к. для неё повторное срабатывание будет менее критичным (индикатор с большей долей вероятности будет обнаружен повторно и заблокирован). В реальности же для получения такой статистики нужен некий буферный период, в рамках которого мы начинаем списывать индикаторы после определенного срока и наблюдаем за тем, какие были списаны раньше времени, а какие корректно, причем для каждого контролируемого типа. На основании этих данных определяем decay_rate обратным преобразованием формулы CIRCL. Так у нас получается неправильный decay_rate для рано списанных и правильный для списанных корректно. Затем среднее значение корректного decay_rate нужно умножить на коэффициент уровня зрелости ИБ этой инфраструктуры.
Вредонос был нацелен на Windows узлы, данных по распределению ОС в инфраструктуре, увы, нет. Очевидно только то, что в офисных сегментах большая часть машин была именно под Windows.
Именно об этом и речь. Пока что не ясно, действительно ли данный вредонос создан для вымогательства или это все ширма, а настоящяя цель — уничтожение данных (ввиду полного вывода из строя зараженных узлов в ряде случаев) как у wannacry и notpetya.
Исторически лучшей практикой действительно являлась изоляция промышленного сегмента от корпоративного путем того же «воздушного зазора». Однако в условиях современного техпроцесса это не всегда приемлимо ввиду высокой степени интеграции производства и бизнес-систем.
Касательно hydro — точно известно, что офисный сегмент «лег», атака вероятнее всего распространялась политиками на доменные машины, однако нет информации о том, в какой мере были изолированы их промышленные сегменты и насколько правильно соблюден баланс безопасности и нужд производства. На пресс-конференции заявлялось, что изоляция заводов была произведена в качестве мер предосторожности, что, естественно не дает много информации о «прямоте» архитектуры :) Можно лишь предполагать, что где-то сегментирование/компенсационные ИБ меры были недостаточными, раз не на всем производстве выпуск продукции восстановлен в полном объеме.
Вы правы, команда stat с указанными параметрами выведет время доступа к файлу. Но в нашем случае метки к файлу дампа были изменены, поэтому опираться на них для определения момента выгрузки мы по понятным причинам не можем.
Наша рабочая гипотеза заключается в том, что дамп был выгружен 28.06.2024 после загрузки веб-шелла system.php в период с 11:36 до 11:42 по мск.
По результатам анализа логов за 2024 год успешных обращений к файлу, который содержит дамп БД сайта или его скачивания, не выявлены. Access-логи веб-сервера за 2023 год частично потерты. Мы продолжаем искать следы обращения к файлу и его скачивания, чтобы установить в какой момент атаки произошла компрометация файла.
В принципе pkexec возможно использовать и в headless режиме, все зависит от используемого дистрибутива и ПО. Если Вы планируете остановиться на воркэраунде, то Вам предварительно стоит уточнить нюансы использования polkit и его компонентов у мейнтейнеров используемых Вами дистрибутивов и ПО, и следовать их рекомендациям. Иначе применение воркэраунда остается на Ваш страх и риск. Лучше всего, конечно, установить актуальные патчи.
Уязвим именно pkexec, воркэраунд ломает тот функционал, где задействован pkexec (т.е. через него уже не получится получить повышенные привилегии). Например, управлении системными настройками в Вашем desktop environment через GUI может сломаться. Таким образом, лучше применить патч (хотя, как и в случае с log4shell высока вероятность, что фикс будет обойден). Наличие pkexec следует искать не в системных логах, а на файловой системе, например через
ls -lash /usr/bin/pkexecКасательно hydro — точно известно, что офисный сегмент «лег», атака вероятнее всего распространялась политиками на доменные машины, однако нет информации о том, в какой мере были изолированы их промышленные сегменты и насколько правильно соблюден баланс безопасности и нужд производства. На пресс-конференции заявлялось, что изоляция заводов была произведена в качестве мер предосторожности, что, естественно не дает много информации о «прямоте» архитектуры :) Можно лишь предполагать, что где-то сегментирование/компенсационные ИБ меры были недостаточными, раз не на всем производстве выпуск продукции восстановлен в полном объеме.
В ближайшее время мы опубликуем цикл статей по атакам и защите AD.