[ Когда Outlook перестает сомневаться ]
Всем привет!👋
В последнее время кампании по социальной инженерии все больше осложняются надстроенными средствами защиты. Одним из часто встречаемых механизмов является плашка в Outlook о внешнем отправителе. Думаю, многие коллеги, работающие с корпоративной почтой, не раз видели огромный алерт желто-красного цвета на пол письма с предупреждением о письме с внешнего доменного имени. Такая сигнализация резко повышает бдительность конечных пользователей, которых пытаются фишить.
Однако с этим механизмом защиты есть нюанс. Недавно мы писали пост об "интернациональных XSS". Главный месседж в нем был в понимании фундаментальных основ. В этом посте я в очередной раз подсвечу, что иногда решение проблемы в offensive-индустрии может скрываться на поверхности и не требовать программирования на ассемблере с бубном в руках.
Если мы сохраним письмо от "внешнего отправителя" как формат HTML в клиенте outlook-а, то увидим, что технически всё наше письмо и является HTML-кодом, в который была вставлена плашка в тело письма с сообщением, настроенным на Exchange-сервере администраторами (рис. 1).
Но раз мы рассылаем письма, значит под нашим контролем всё содержимое HTML-письма, которое мы направляем и корректируем. А для обхода всплывающего содержимого нам достаточно вспомнить CSS и его возможности: попробуем запретить отображение всего кроме нашей легенды письма с помощью магии CSS:
Здесь мы всё красим в белый кроме своего уникального
На рис.2 пример отправки письма без указанных CSS-стилей, а на рис.3 уже с применением нашей хитрости.
P/S стоит отметить, что в окне предпросмотра клиента Outlook-а текст с алертом всё ещё будет виден, если администраторы настроили вставку плашки в начало сообщения (рис. 4). Но тем не менее сама плашка визуально не отображается, и в потоке писем это может дать нам очки бонуса, как атакующим.
В фишинговых кампаниях мелочей не бывает, важны детали и любые нюансы. И если даже одна эта деталь сможет снизить бдительность сотрудника, то фишинговую кампанию можно будет считать успешной.
Об этой технике известно как минимум с 19-21 годов, более развернутое описание вы можете посмотреть тут, а приложенный PoC тут.
Таким образом, если ты понял правила игры, то можешь их адаптировать под себя
@GigaHack
#social #outlook #bypass
Всем привет!
В последнее время кампании по социальной инженерии все больше осложняются надстроенными средствами защиты. Одним из часто встречаемых механизмов является плашка в Outlook о внешнем отправителе. Думаю, многие коллеги, работающие с корпоративной почтой, не раз видели огромный алерт желто-красного цвета на пол письма с предупреждением о письме с внешнего доменного имени. Такая сигнализация резко повышает бдительность конечных пользователей, которых пытаются фишить.
Однако с этим механизмом защиты есть нюанс. Недавно мы писали пост об "интернациональных XSS". Главный месседж в нем был в понимании фундаментальных основ. В этом посте я в очередной раз подсвечу, что иногда решение проблемы в offensive-индустрии может скрываться на поверхности и не требовать программирования на ассемблере с бубном в руках.
Если мы сохраним письмо от "внешнего отправителя" как формат HTML в клиенте outlook-а, то увидим, что технически всё наше письмо и является HTML-кодом, в который была вставлена плашка в тело письма с сообщением, настроенным на Exchange-сервере администраторами (рис. 1).
Но раз мы рассылаем письма, значит под нашим контролем всё содержимое HTML-письма, которое мы направляем и корректируем. А для обхода всплывающего содержимого нам достаточно вспомнить CSS и его возможности: попробуем запретить отображение всего кроме нашей легенды письма с помощью магии CSS:
<html>
<head>
<style type="text/css">
body {
display: none !important;
background:#FFFFFF !important;
}
.id100500 {
display: block !important;
}
div[style] {
display: none !important;
background:#FFFFFF !important;
}
p {
display: none !important;
background:#FFFFFF !important;
}
p[style] {
display: none !important;
background:#FFFFFF !important;
}
span {
display: none !important;
background: #FFFFFF !important;
}
span[style] {
display: none !important;
background:#FFFFFF !important;
}
table[style] {
display: none !important;
background:#FFFFFF !important;
}
table {
display: none !important;
background:#FFFFFF !important;
}
td {
display: none !important;
background:#FFFFFF !important;
}
td[style] {
display: none !important;
background:#FFFFFF !important;
}
tr {
display: none !important;
background:#FFFFFF !important;
}
tr[style] {
display: none !important;
background:#FFFFFF !important;
}
tbody {
background:#FFFFFF !important;
display: none !important;
}
tbody[style] {
display: none !important;
background:#FFFFFF !important;
}
</style>
</head>
<body>
<p class="id100500">Привет!</p>
<p class="id100500">Это обманка </p>
</body>
</html>
Здесь мы всё красим в белый кроме своего уникального
class=id100500.На рис.2 пример отправки письма без указанных CSS-стилей, а на рис.3 уже с применением нашей хитрости.
P/S стоит отметить, что в окне предпросмотра клиента Outlook-а текст с алертом всё ещё будет виден, если администраторы настроили вставку плашки в начало сообщения (рис. 4). Но тем не менее сама плашка визуально не отображается, и в потоке писем это может дать нам очки бонуса, как атакующим.
В фишинговых кампаниях мелочей не бывает, важны детали и любые нюансы. И если даже одна эта деталь сможет снизить бдительность сотрудника, то фишинговую кампанию можно будет считать успешной.
Об этой технике известно как минимум с 19-21 годов, более развернутое описание вы можете посмотреть тут, а приложенный PoC тут.
Таким образом, если ты понял правила игры, то можешь их адаптировать под себя
@GigaHack
#social #outlook #bypass
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍9❤1💘1
[ BUGS ZONE 6.0 ]
Всем привет!👋
Не так давно выступил с небольшим докладом на приватном мероприятии для багхантеров от BI.ZONE Bug Bounty🪲
Интересный опыт выступления в камерном сообществе перед рядом сильнейших хантеров. Приятно удивлен, что часть людей задавала вопросы после выступления как лично на ивенте, так и в ЛС (хотя сам свой доклад оцениваю больше для начинающих).
Также теперь мой ник 1 из 38 "увековеченных" участников ивента на плакате😎
Приятная мелочь, так как помню о первых багах и посещение BUGS 3 ещё в качестве гостя, а не хантера
Спасибо @BIZONE_BB и вендорам за приглашение в приватки, а победителей поздравляю с попаданием в топ-5, вы круты!
Был рад пообщаться со старыми товарищами и познакомиться с новыми людьми в комьюнити!🔝
@GigaHack
#bug_bounty #bugs_zone6 #conference
Всем привет!
Не так давно выступил с небольшим докладом на приватном мероприятии для багхантеров от BI.ZONE Bug Bounty
Интересный опыт выступления в камерном сообществе перед рядом сильнейших хантеров. Приятно удивлен, что часть людей задавала вопросы после выступления как лично на ивенте, так и в ЛС (хотя сам свой доклад оцениваю больше для начинающих).
Также теперь мой ник 1 из 38 "увековеченных" участников ивента на плакате😎
Приятная мелочь, так как помню о первых багах и посещение BUGS 3 ещё в качестве гостя, а не хантера
Спасибо @BIZONE_BB и вендорам за приглашение в приватки, а победителей поздравляю с попаданием в топ-5, вы круты!
Был рад пообщаться со старыми товарищами и познакомиться с новыми людьми в комьюнити!
@GigaHack
#bug_bounty #bugs_zone6 #conference
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍4❤3💋1
[SOC Forum 2025]
А пока я выступал на BUGS — @VlaDriev готовился к выступлению на SOC Forum 2025.
Старт доклада уже скоро👋
Приглашаем вас послушать доклад "Автоматизация рутины пентеста и почему мало кто так делает".
📆 20.11.2025 в 11:00 Мск, зал 4.
Трансляция здесь.🚀
➡️ Проект за проектом, год за годом в процессе проведения пентеста приходится выполнять достаточно много рутинных действий. Это не только утомляет, но и неизбежно приводит к ошибкам, которые могут негативно повлиять на ИТ-инфраструктуру заказчика.
➡️ В рамках доклада мы расскажем о своем опыте автоматизации рутины пентеста, проблемах, с которыми столкнулись, особенностях известных инструментов (Masscan, NetExec, Impacket, NTLM Relay и других), а также о том, как тестировали полученные решения.
@GigaHack
#pentest #soc_forum2025 #conference
А пока я выступал на BUGS — @VlaDriev готовился к выступлению на SOC Forum 2025.
Старт доклада уже скоро
Приглашаем вас послушать доклад "Автоматизация рутины пентеста и почему мало кто так делает".
Трансляция здесь.
@GigaHack
#pentest #soc_forum2025 #conference
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍9🦄1
[ Нюансы RBCD ]
Всем привет, друзья! В завершении года хочу поделиться интересным нюансом, связанным с эксплуатацией ограниченного делегирования на основе ресурсов Kerberos (англ. RBCD) в Active Directory🔩
Многие специалисты по внутреннему пентесту знакомы с различными техниками абуза RBCD, поэтому детально вдаваться в механизм работы не буду, приложу дополнительно пару хороших мануалов про RBCD в целом:
👉 1.
👉 2.
Перейдем сразу к интересной особенности
На проекте мне в очередной раз встретилась группа "Protected Users", в которую коллеги корректно включили всех администраторов домена для защиты их УЗ от ряда техник и атак. (скриншот 1)🐕
В том числе пользователи этой группы не могут быть "олицетворены" (в простонародье "имперсонированы") при делегировании привилегий (абуз RBCD невозможен).
Однако, мне удалось запросить сервисный тикет на учетную запись 111-administrator (это была встроенная УЗ администратора домена с измененным именем; по умолчанию называется просто administrator или "администратор" в ru-доменах с RID-500). Запрос ST можно увидеть на скриншоте 2.
Затем успешно использовать его для захвата необходимой мне машины (скриншот 3 с доступом к C$)⚡️
Прочитав побольше информации о данной УЗ, нашел пару тезисов об этом здесь:
https://sensepost.com/blog/2023/protected-users-you-thought-you-were-safe-uh/
А также нюанс упоминается и на "рецептах хакера" (скриншот 4)
Сам Microsoft пишет следующее😭
Думаю, соответственно, и митигации группы Protected Users на неё не действуют
Таким образом, можно сделать вывод, что Protected Users не панацея от RBCD. Остается помнить об УЗ дефолтного администратора с RID 500 и предпринимать дополнительные меры по защите (возможно, самой лучшей мерой будет являться в целом отключение данной УЗ)
Снова акцентируем внимание на том, что защита должна быть комплексной, не бывает волшебной кнопки в оснастке администратора/волшебной железки вида Ultimate ProMax Security NGWF. Всё должно работать системно, внедрены и оборудование, и мониторинг, применены митигации в самой инфраструктуре, а также конечно же процессы с людьми👨💻
@GigaHack
#pentest #internal #AD
Всем привет, друзья! В завершении года хочу поделиться интересным нюансом, связанным с эксплуатацией ограниченного делегирования на основе ресурсов Kerberos (англ. RBCD) в Active Directory
Многие специалисты по внутреннему пентесту знакомы с различными техниками абуза RBCD, поэтому детально вдаваться в механизм работы не буду, приложу дополнительно пару хороших мануалов про RBCD в целом:
👉 1.
👉 2.
Перейдем сразу к интересной особенности
На проекте мне в очередной раз встретилась группа "Protected Users", в которую коллеги корректно включили всех администраторов домена для защиты их УЗ от ряда техник и атак. (скриншот 1)
В том числе пользователи этой группы не могут быть "олицетворены" (в простонародье "имперсонированы") при делегировании привилегий (абуз RBCD невозможен).
Однако, мне удалось запросить сервисный тикет на учетную запись 111-administrator (это была встроенная УЗ администратора домена с измененным именем; по умолчанию называется просто administrator или "администратор" в ru-доменах с RID-500). Запрос ST можно увидеть на скриншоте 2.
Затем успешно использовать его для захвата необходимой мне машины (скриншот 3 с доступом к C$)
Прочитав побольше информации о данной УЗ, нашел пару тезисов об этом здесь:
https://sensepost.com/blog/2023/protected-users-you-thought-you-were-safe-uh/
А также нюанс упоминается и на "рецептах хакера" (скриншот 4)
Сам Microsoft пишет следующее
The builtin domain Administrator (S-1-5-<domain>-500) is always exempt from Authentication Policies, even when they are assigned to an Authentication Policy Silo
Думаю, соответственно, и митигации группы Protected Users на неё не действуют
Таким образом, можно сделать вывод, что Protected Users не панацея от RBCD. Остается помнить об УЗ дефолтного администратора с RID 500 и предпринимать дополнительные меры по защите (возможно, самой лучшей мерой будет являться в целом отключение данной УЗ)
Снова акцентируем внимание на том, что защита должна быть комплексной, не бывает волшебной кнопки в оснастке администратора/волшебной железки вида Ultimate ProMax Security NGWF. Всё должно работать системно, внедрены и оборудование, и мониторинг, применены митигации в самой инфраструктуре, а также конечно же процессы с людьми
@GigaHack
#pentest #internal #AD
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍8☃4💯2🥱1