Подтянулась тяжелая артиллерия: настоящий Jam, как мы и прогнозировали, еще впереди.

Все это даже после того, как CVE-2021-44228 была исправлена еще 6 декабря с выпуском Log4j 2.15.0, а вызванная этим патчем последующая CVE-2021-45046 (позволявшая эксплуатировать log4shell в некоторых нестандартных конфигурациях с возможностью атак с отказом в обслуживании) также была устранена выпуском самой последней версии Log4j 2.12.2 и 2.16.0, удаляющей функцию поиска сообщений и по умолчанию блокирующей доступ к JNDI.

Тем не менее, более 70 образцов, использующих эксплойт, обнаружено, что достаточно небольшой показатель по сравнению с тем, что, вероятно, уже присутствует в дикой природе.

Но что еще хуже, Bitdefender заметили, что за Log4Shell взялись первые вымогатели. Злоумышленники пытаются использовать ошибку для загрузки двоичного файла .NET с удаленного сервера, который шифрует файлы на целевой машине c расширением khonsari. Записка с требованием выкупа «КАК ПОЛУЧИТЬ СВОИ ФАЙЛЫ BACK.TXT» добавляется на рабочий стол.

Первый инцидент был зафиксирован 11 декабря, когда на уязвимый хост был загружен вредоносный двоичный файл с hxxp://3.145.115.94/zambo/groenhuyzen.exe. Это новое семейство программ-вымогателей, получивших название благодаря своему расширению в зашифрованных файлах. В реальности свое ПО хакеры нарекли именем владельца антикварного магазина в Луизиане. Почему – не ясно.

После запуска Khonsari сканит все диски и шифрует системные папки с документами, видео, изображениями, загрузками и рабочий стол. При этом не шифруются файлы с расширениями .ini и .lnk. Вредоносная программа использует AES 128 CBC с поддержкой алгоритма PaddingMode.Zeros для шифрования. Кроме того, как выяснили BitDefender в более поздних атаках хакеры использовали тот же сервер для распространения RAT Orcus.

Не обошлось и без китайских и иранских АРТ, следы которых выявили спецы из Mandiant. Воспользовавшись ситуацией всеобщего хаоса, АРТ занимались решением традиционных для них задач по кибершпионажу, но помимо прочего иранские субъекты выстраивались и под более агрессивные действия, преследуя подрывные цели. Представители Mandiant отказались сообщать подробную информацию о том, какие конкретно связанные АРТ принимали участие в атаках.

Согласно данным телеметрии Check Point с 44% корпоративных сетей обнаружено более 1,3 миллиона попыток использования уязвимости, большинство из которых были совершены известными вредоносными группами. Всеобщий хакерский ажиотаж и хаос во всем технологическом мире не вызывают удивления, исследование Wiz показывает, что более 89% всех сред имеют уязвимые библиотеки Log4j, разработчики которых в некоторых случаях даже не догадываются об этом. Настоящая черная пятница для хакеров всех мастей.

Учитывая, что Microsoft уже фиксировали имплантаты Cobalt Strike, не стоит считать первый пример эксплойта Log4j, непосредственно устанавливающего ransomware, последним. Вероятно, более увесистые акторы уже вовсю эксплуатируют Log4 Jam, но пока сосредоточены более на максимально широком таргетинге. А по истечении пары тройки недель мест на DLS, судя по всему, не будет хватать, чтоб упорядочить всех новых жертв ransomware.

Тем временем к настоящему моменту помимо исправления уязвимости, перед специалистами по ИБ стоит куда более сложная задача: выявить вероятного злоумышленника в сети.

Набор заявлений от CERT различных стран ЕС по log4j.

https://www.enisa.europa.eu/news/statement-on-log4shell

NIST has released three draft items related to the Workforce Framework for Cybersecurity (NICE Framework).

https://www.nist.gov/itl/applied-cybersecurity/nice/nice-framework-resource-center/workforce-framework-cybersecurity-nice

​​Вызванная Log4Shell киберпандемия в сфере инфосек набирает новые обороты.

Наряду с выявленными более 1,8 млн. попыток эксплуатации первоначальной уязвимости CVE-2021-44228 в Log4j, хакеры начинают использовать вторую и третью уязвимости.

Это все при том, что выявлено более 60 использующих багу семейств malware, которые охватывают весь спектр вредоносных воздействий от майнеров и троянов удаленного доступа до ботнетов и веб-оболочек. И, что еще хуже, по данным MSTIC, брокеры первоначального доступа использовали уязвимость Log4Shell для проникновения в целевые сети, лазейки в которые затем были реализованы вымогателям.

Не менее активны оказались АРТ, связанные с Китаем (Hafnium), Ираном (APT 35 aka Phosphorus), Северной Корей и Турцией, в интересах которых отработать как можно больше уязвимых в моменте систем, начиная от интеграции уязвимости до развертывания полезных нагрузок в реальных условиях.

А теперь Cloudflare сообщают, что буквально вчера злоумышленники переориентировались на вторую CVE, обнаруженную в широко используемой утилите ведения журналов Log4j.

Уязвимость CVE-2021-45046 затрагивает все версии Log4j от 2.0-beta9 до 2.12.1 и от 2.13.0 до 2.15.0 и возникла неполного исправления Apache Software Foundation предыдущей CVE в некоторых нестандартных конфигурациях, отличных от настроек по умолчанию. Неполный патч для CVE-2021-44228 может быть использован для создания вредоносных входных данных с использованием шаблона поиска JNDI, что приводит к атаке типа отказ в обслуживании (DoS). В свою очередь, разработчики ее оперативно пофиксили в Log4j версии 2.16.0.

Еще большую тревогу вызывает исследование Praetorian, в котором исследователи предупреждают о третьей уязвимости в Log4j версии 2.15.0, которая дает возможность кражи конфиденциальных данных при определенных условиях. Технические подробности уязвимости не разглашаются, дабы предотвратить дальнейший коллапс, и, вероятно, еще и потому, что новая версия 2.16.0, по всей видимости, не содержит ее исправлений.

Можете сами оценить, как происходит эксфильтрация конфиденциальных данных в Log4j 2.15.0.

Версия 2.15 log4j уязвима не только к DoS но к RCE.

А теперь стало известно что версия 2.16 тоже уязвима к DoS.

Ряд экспертов указывают, что активные атаки с использованием уязвимостей log4j продлятся еще несколько лет.

https://issues.apache.org/jira/browse/LOG4J2-3230

Обращение Британского ФСТЭК к руководству организаций.

https://twitter.com/NCSC/status/1471807226134343681

Про смерть SOCов, неэффективность аутсорсинговых SOCов, автоматизацию TI и другие наблюдения с SecOps Summit. Продолжение обзора мероприятий по SOC, которые прошли на первой неделе декабря. И это не про SOC Forum, хотя про него тоже будет - https://lukatsky.ru/secops/3-meropriyatiya-po-socam-v-techenie-odnoy-nedeli-chto-obschego-chast-1.html

​💬 true story... Social Engineering.

Вопрос не в том «Взломают Вас или нет?», а «Насколько быстро Вы сможете обнаружить, что Вас уже взломали?!»

🖖🏻 Приветствую тебя user_name.

• Бывает, что одну фирму нанимают проверить качество работы другой. Когда речь идет о социальной инженерии, это особенно актуальная практика.

• Основатель компании The Security Awareness Уинн Швартау занимается аудитом более 25 лет. К нему обычно приходят за экспертной оценкой уже проведенных мероприятий по усилению безопасности. Однажды его попросили сделать это для крупного финансового учреждения в Нью-Йорке. Дело в том, что сотрудников банка только что напугали предыдущие аудиторы, которые нашли тонну проблем. Целый месяц весь персонал инструктировали на интенсивных тренингах. Сотрудники стали настоящими параноиками: не открывают подозрительных писем, не переходят по фишинговым ссылкам, не подбирают флешки, не разглашают ничего по телефону и строго следуют должностным инструкциям.

• «Да это же идеальные жертвы!» — подумал Швартау и принялся за работу. Он скопировал с сайта компании образец шапки делового письма, там же взял часть адресов обычной почты сотрудников, а остальные узнал из справочников. Вместе с помощниками Швартау составил примерно 1200 персонально адресованных бумажных писем, напечатал их на самодельных бланках проверяемой организации и отправил старым дедовским способом.

• В каждом письме говорилось, что недавно репутация их компании сильно пострадала из-за действий отдельных сотрудников, пренебрегавших элементарными мерами безопасности. Руководство не может допустить новых проколов, поэтому идет на беспрецедентные меры.

• Далее для усыпления бдительности следовал детальный план с обилием технических терминов, которые офисный сотрудник вряд ли сможет понять. Затем шла стандартная просьба информировать обо всех подозрительных действиях. В заключение письма говорилось, что с ИТ-отделом и службой безопасности теперь требуется общаться только посредством физической почты, так как это единственный канал связи, недоступный хакерам.

• P.S: указанный адрес не принадлежит компании, чтобы эти письма никто не мог вычислить и перехватить. «Мы будем помещать их в надежно охраняемый почтовый ящик, доступ к которому будет только у руководства и службы безопасности" — говорилось в письме. — "Прямо сейчас вам надлежит прислать свои учетные данные, чтобы мы проверили их вручную и завершили обновление системы». 30% сотрудников ответили на следующий же день, указав в письме все свои данные. Ни один тренинг не помог им понять, что и в 21 веке хакер может отправить письмо на бумаге.

• Вывод: Как бы долго и тщательно организация ни тренировала людей, какие бы административные и технические меры в ней ни принимались, она никогда не достигнет 100% защищенности. Любые высокие показатели безопасности — лишь временный эффект. Люди делают определенные выводы, становятся осторожнее, но не могут эффективно сопротивляться свойствам своей натуры. Каждый раз, сталкиваясь с необходимостью принять безотлагательное решение, испытывая жажду легкой наживы или страх чего угодно, они делают уязвимыми себя и свою компанию. Твой S.E. #СИ #Пентест #Взлом.