Да, в статье действительно использованы другие термины, на самом деле злоумышленник выставляет ордер на покупку криптовалюты на легальной P2P‑бирже. Легальный продавец крипты получает рубли на свою карту, не подозревая, что это деньги,переведенные жертвой с Avito через посредника "менеджера".
В данной схеме две жертвы : третье лицо, которое хочет купить лего и менеджер на авито. Мошшеник, как один из вариантов событий, Мошенник находит на P2P-бирже продавца (например Вас), который хочет продать USDT за рубли. Он делает вид, что хочет купить у Вас криптовалюту, и получает от Вас реквизиты вашей банковской карты. Затем мошенник находит другого человека (Жертву №2), например, как в нашем случае на Avito. В качестве реквизитов для оплаты он дает реквизиты вашей карты, которые вы только что ему прислали. И в текущей схеме получается две жертвы : тот, кто хотел купить лего, и тот, кто работал так называемым "менеджером". По итогу : покупатель LEGO — потерял деньги, ничего не получил;менеджер на Avito — не теряет денег напрямую, но теряет аккаунт. Мошенник в данной связке по "черному треугольнику" получает криптовалюту без единых вложений. Продавец крипты — не совсем жертва в финансовом смысле, он получил свои деньги за свою крипту, сделка для него формально закрыта. Но именно он потом рискует объясняться с банком или следствием, если цепочку проследят до его карты — вот тут и он попадает в зону риска, просто не как финансовая жертва, а как невольный участник
Мошенник выставляет ордер на продажу USDT на легальной P2P-бирже, указывая способом оплаты карту третьего подставного лица. Им может быть как умышленное лицо, так неумышленное. Покупатель крипты (в нашем случае менджер-жертва с Авито) переводит рубли на эту карту — это на самом деле деньги, украденные у жертвы с Avito. Мошенник видит поступление и отдаёт покупателю крипту. Классическая схема "черного треугольника". Важно отметить, что это лишь вероятный сценарий — возможен и более простой вывод через сеть дропов без крипты вообще.
Риск возникает постфактум: если жертва подаст заявление и цепочку проследят до карты,с которой было поступление ( в нашем случае менеджер-жертва с Авито) счёт заблокируют, и все транзакции по нему могут попасть под проверку как связанные с мошенничеством.
Вы правы, команда 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 — точно известно, что офисный сегмент «лег», атака вероятнее всего распространялась политиками на доменные машины, однако нет информации о том, в какой мере были изолированы их промышленные сегменты и насколько правильно соблюден баланс безопасности и нужд производства. На пресс-конференции заявлялось, что изоляция заводов была произведена в качестве мер предосторожности, что, естественно не дает много информации о «прямоте» архитектуры :) Можно лишь предполагать, что где-то сегментирование/компенсационные ИБ меры были недостаточными, раз не на всем производстве выпуск продукции восстановлен в полном объеме.
Да, в статье действительно использованы другие термины, на самом деле злоумышленник выставляет ордер на покупку криптовалюты на легальной P2P‑бирже. Легальный продавец крипты получает рубли на свою карту, не подозревая, что это деньги,переведенные жертвой с Avito через посредника "менеджера".
Спасибо за бдительность, мы поправили текст!
Добрый день!
В данной схеме две жертвы : третье лицо, которое хочет купить лего и менеджер на авито. Мошшеник, как один из вариантов событий, Мошенник находит на P2P-бирже продавца (например Вас), который хочет продать USDT за рубли. Он делает вид, что хочет купить у Вас криптовалюту, и получает от Вас реквизиты вашей банковской карты. Затем мошенник находит другого человека (Жертву №2), например, как в нашем случае на Avito. В качестве реквизитов для оплаты он дает реквизиты вашей карты, которые вы только что ему прислали. И в текущей схеме получается две жертвы : тот, кто хотел купить лего, и тот, кто работал так называемым "менеджером". По итогу : покупатель LEGO — потерял деньги, ничего не получил;менеджер на Avito — не теряет денег напрямую, но теряет аккаунт. Мошенник в данной связке по "черному треугольнику" получает криптовалюту без единых вложений. Продавец крипты — не совсем жертва в финансовом смысле, он получил свои деньги за свою крипту, сделка для него формально закрыта. Но именно он потом рискует объясняться с банком или следствием, если цепочку проследят до его карты — вот тут и он попадает в зону риска, просто не как финансовая жертва, а как невольный участник
Добрый день! Спасибо за вопрос!
Мошенник выставляет ордер на продажу USDT на легальной P2P-бирже, указывая способом оплаты карту третьего подставного лица. Им может быть как умышленное лицо, так неумышленное. Покупатель крипты (в нашем случае менджер-жертва с Авито) переводит рубли на эту карту — это на самом деле деньги, украденные у жертвы с Avito. Мошенник видит поступление и отдаёт покупателю крипту. Классическая схема "черного треугольника". Важно отметить, что это лишь вероятный сценарий — возможен и более простой вывод через сеть дропов без крипты вообще.
Риск возникает постфактум: если жертва подаст заявление и цепочку проследят до карты,с которой было поступление ( в нашем случае менеджер-жертва с Авито) счёт заблокируют, и все транзакции по нему могут попасть под проверку как связанные с мошенничеством.
Добрый день!
Автор уточняет: "OpenID сам по себе безопасен, но токен, который создаёт сторонний сервис, может быть похищен".
Добрый день!
Спасибо, что обратили внимание, проверим данные и вернемся.
Вы правы, команда 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.