Заметки на полях: RedTeam Tip
Представим ситуацию, что нам необходимо запустить какой-то исполняемый файл (например, calc.exe) из командной строки. Причем из-под непривилегированного пользователя.
Казалось бы все просто: набираем команду cmd.exe /c "c:\windows\system32\calc.exe" и все будет хорошо.
Оказалось не все так радужно (см часть рисунка под цифрой 1) - запуск из-под непривилегированного пользователя невозможен.
Но есть другой способ. Через explorer.exe можно запустить cmd.exe и уже из нового окна запустить calc.exe изначально планируемой командой (см часть рисунка под цифрой 2). И исполняемый файл запустится без каких-либо вопросов. Таким образом можно обойти запрет на запуск исполняемого файла через cmd.exe под непривилегированным пользователем.
На самом деле запустить calc.exe можно и напрямую через explorer.exe командой explorer.exe /root,"c:\windows\system32\calc.exe"
В этом случае родительским процессом будет explorer.exe, что затруднит некоторым сзи детектирование запуска исполняемого файла😉
Представим ситуацию, что нам необходимо запустить какой-то исполняемый файл (например, calc.exe) из командной строки. Причем из-под непривилегированного пользователя.
Казалось бы все просто: набираем команду cmd.exe /c "c:\windows\system32\calc.exe" и все будет хорошо.
Оказалось не все так радужно (см часть рисунка под цифрой 1) - запуск из-под непривилегированного пользователя невозможен.
Но есть другой способ. Через explorer.exe можно запустить cmd.exe и уже из нового окна запустить calc.exe изначально планируемой командой (см часть рисунка под цифрой 2). И исполняемый файл запустится без каких-либо вопросов. Таким образом можно обойти запрет на запуск исполняемого файла через cmd.exe под непривилегированным пользователем.
На самом деле запустить calc.exe можно и напрямую через explorer.exe командой explorer.exe /root,"c:\windows\system32\calc.exe"
В этом случае родительским процессом будет explorer.exe, что затруднит некоторым сзи детектирование запуска исполняемого файла😉
Жаркие летние твои… уязвимости
Лето 2020 года богато на публикацию критических уязвимостей (видимо приближается пандемия в мире ИБ). Пентестер, а тем более RedTeam специалист, должен проверять наличие таких уязвимостей в инфраструктуре заказчика, даже если РоС не опубликован. К сожалению, не все компании обновляются оперативно, а наличие уязвимостей такого рода делает инфраструктуру компании беззащитной перед злоумышленником. Делимся с вами небольшим обзором горячих уязвимостей и рекомендуем проверять их наличие в первую очередь.
Патчи выпущены на все описанные уязвимости. Проверьте, что они установлены (или не установлены)!
1. F5 BIG-IP
TMUI RCE vulnerability CVE-2020-5902
Уязвимость в пользовательском интерфейсе управления трафиком (Traffic Management User Interface) позволяет злоумышленникам, не прошедшим проверку подлинности, выполнять произвольные системные команды, создавать или удалять файлы, отключать службы и (или) выполнять произвольный Java код
CVSSv2: 10
CVSSv3: 9.8
Подробности об уязвимости: https://support.f5.com/csp/article/K52145254
РоС: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/http/f5_bigip_tmui_rce.rb
2. Citrix
5 уязвимостей разного уровня критичности
Подробности об уязвимостях: https://support.citrix.com/article/CTX276688
PoC: проверенных нет, но есть хорошее техническое описание всех уязвимостей: https://blog.unauthorizedaccess.nl/2020/07/07/adventures-in-citrix-security-research.html
Одна из наиболее интересных уязвимостей - CVE-2020-8193
Обход аутентификации в Citrix ADC, Citrix Gateway, Citrix SDWAN WAN-OP
CVSSv2: 5
CVSSv3: 6.5
PoC: https://github.com/jas502n/CVE-2020-8193 (не проверен)
3. Palo Alto
PAN-OS: Authentication Bypass in SAML Authentication
В PAN-OS неправильная проверка подписей в SAML аутентификации позволяет злоумышленнику, не прошедшему проверку подлинности в сети, получить доступ к защищенным ресурсам
CVSSv2: 9.8
CVSSv3: 10
Подробности об уязвимости: https://security.paloaltonetworks.com/CVE-2020-2021
PoC: в открытом доступе нет
4. Windows DNS Server
CVE-2020-1350
Уязвимость, про которую говорят все!
Удаленное выполнение кода на DNS серверах злоумышленником, не прошедшим проверку подлинности
CVSSv2: 10
CVSSv3: 10
Подробности об уязвимости: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350
PoC: Будьте аккуратны с фейковыми PoC!
https://github.com/ZephrFish/CVE-2020-1350 - распространяемый PoC является фейковым
5. Bitrix
Bitrix SSRF CVE-2020-13484
Все версии Bitrix до 20.0.975 позволяют произвести подделку запросов на стороне сервера к внешним IP-адресам + уязвимость позволяет обходить ограничения и генерировать запросы к внутренней инфраструктуре
CVSSv2: 7.5
CVSSv3: 9.8
PoC: https://gist.github.com/mariuszpoplwski/f261a4bc06adde5c78760559db9d63bd
Лето 2020 года богато на публикацию критических уязвимостей (видимо приближается пандемия в мире ИБ). Пентестер, а тем более RedTeam специалист, должен проверять наличие таких уязвимостей в инфраструктуре заказчика, даже если РоС не опубликован. К сожалению, не все компании обновляются оперативно, а наличие уязвимостей такого рода делает инфраструктуру компании беззащитной перед злоумышленником. Делимся с вами небольшим обзором горячих уязвимостей и рекомендуем проверять их наличие в первую очередь.
Патчи выпущены на все описанные уязвимости. Проверьте, что они установлены (или не установлены)!
1. F5 BIG-IP
TMUI RCE vulnerability CVE-2020-5902
Уязвимость в пользовательском интерфейсе управления трафиком (Traffic Management User Interface) позволяет злоумышленникам, не прошедшим проверку подлинности, выполнять произвольные системные команды, создавать или удалять файлы, отключать службы и (или) выполнять произвольный Java код
CVSSv2: 10
CVSSv3: 9.8
Подробности об уязвимости: https://support.f5.com/csp/article/K52145254
РоС: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/http/f5_bigip_tmui_rce.rb
2. Citrix
5 уязвимостей разного уровня критичности
Подробности об уязвимостях: https://support.citrix.com/article/CTX276688
PoC: проверенных нет, но есть хорошее техническое описание всех уязвимостей: https://blog.unauthorizedaccess.nl/2020/07/07/adventures-in-citrix-security-research.html
Одна из наиболее интересных уязвимостей - CVE-2020-8193
Обход аутентификации в Citrix ADC, Citrix Gateway, Citrix SDWAN WAN-OP
CVSSv2: 5
CVSSv3: 6.5
PoC: https://github.com/jas502n/CVE-2020-8193 (не проверен)
3. Palo Alto
PAN-OS: Authentication Bypass in SAML Authentication
В PAN-OS неправильная проверка подписей в SAML аутентификации позволяет злоумышленнику, не прошедшему проверку подлинности в сети, получить доступ к защищенным ресурсам
CVSSv2: 9.8
CVSSv3: 10
Подробности об уязвимости: https://security.paloaltonetworks.com/CVE-2020-2021
PoC: в открытом доступе нет
4. Windows DNS Server
CVE-2020-1350
Уязвимость, про которую говорят все!
Удаленное выполнение кода на DNS серверах злоумышленником, не прошедшим проверку подлинности
CVSSv2: 10
CVSSv3: 10
Подробности об уязвимости: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350
PoC: Будьте аккуратны с фейковыми PoC!
https://github.com/ZephrFish/CVE-2020-1350 - распространяемый PoC является фейковым
5. Bitrix
Bitrix SSRF CVE-2020-13484
Все версии Bitrix до 20.0.975 позволяют произвести подделку запросов на стороне сервера к внешним IP-адресам + уязвимость позволяет обходить ограничения и генерировать запросы к внутренней инфраструктуре
CVSSv2: 7.5
CVSSv3: 9.8
PoC: https://gist.github.com/mariuszpoplwski/f261a4bc06adde5c78760559db9d63bd
Ищем недостатки и уязвимости в Active Directory
Обеспечить безопасность AD - задача непростая. Особенно в больших компаниях с филиалами в разных городах. Поэтому при проведении аудитов, необходимо проверять не встречаются ли в AD компании следующие уязвимости или недостатки:
1. Отсутствие парольной политики в домене
В 2020 году это кажется нереальным. Как у уважающей себя компании может отсутствовать парольная политика??? В мире ИБ существует неразрешимый спор о парольных политиках: кто-то считает, что пароли должны быть огромные, сложные и меняться каждую неделю, а кто-то считает, что такого рода требования бессмысленны и пользователь будет чувствовать себя комфортнее, если не усложнять ему жизнь. Поэтому возникают ситуации, когда компания просто отказывается от парольных политик. Однако отказ от парольной политики влечет за собой сразу 100% существование пункта 2 из нашего списка.
2. Наличие слабых паролей у учетных записей в домене
Наличие словарных паролей или (при отсутствии парольной политики) пустые пароли, а также пароли, состоящие из одной буквы или цифры и т.д.
3. Наличие в домене "мертвых душ"
Очень часто аккаунты, созданные для тестирования, какие-то временные учетные записи, учетки уволенных сотрудников не блокируются, а остаются активными в домене, хотя ими никто не пользуется. А для злоумышленника они являются лакомыми кусочками, потому что очень часто тестовым учетным записям выдают более высокие права, чем обычным пользователям домена.
4. Не истекающие пароли у привилегированных учетных записей
Особенно если это учетная запись какого-то начальника, которому надо что-то смотреть раз в полгода (но надо же! Поэтому ему выдают повышенные права) и которого бесит постоянная смена пароля (и ему ставят, чтобы пароль не истекал). А пароль там обычно - либо 4 цифры, либо 6 (как дата рождения).
5. Хранение учетных данных в папках SYSVOL
Иногда администраторы для запуска приложения на клиентских компьютерах (сразу, при входе в систему), который требует прав администратора - хранят пароли в папке sysvol, к которой может получить доступ любой пользователь, прошедший аутентификацию
6. Отсутствие реакции со стороны средств защиты на DCSync, запуск mimikatz или PSexec
Средства защиты должны быть грамотно настроены, чтобы реагировать на стандартные атаки и утилиты, которые используют злоумышленники. Если кто не знает про DCSync - можно почитать тут (https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync)
7. Большое количество учетных записей в привилегированных группах (domain admins, enterprise admins)
Чем больше учетных записей, тем их сложнее контролировать - тем больше шансов у злоумышленника найти лазейку
8. Наличие "теневых доменных администраторов"
Иногда пользователю не выдают высокие привилегии, однако дают права на совершение каких-то привилегированных действий. Например, возможность сменить пароль другим пользователям или обновление любых атрибутов объекта. О таких пользователях забывают сразу, а с их помощью можно совершить большое количество противоправных действий в домене. Подробнее можно почитать тут (https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces)
9. Возможность проведения атаки Kerberoasting
Наличие "слабых" паролей у сервисных учетных записей позволяет злоумышленнику провести атаку kerberoasting и расшифровать пароли. Подробнее можно почитать тут (https://attack.stealthbits.com/cracking-kerberos-tgs-tickets-using-kerberoasting/)
Мы рассказали вам о наиболее часто встречающихся проблемах, которые есть у 98% компаний и которые стоит проверять как при проведении аудита, так и при проведении RedTeam кампании.
Обеспечить безопасность AD - задача непростая. Особенно в больших компаниях с филиалами в разных городах. Поэтому при проведении аудитов, необходимо проверять не встречаются ли в AD компании следующие уязвимости или недостатки:
1. Отсутствие парольной политики в домене
В 2020 году это кажется нереальным. Как у уважающей себя компании может отсутствовать парольная политика??? В мире ИБ существует неразрешимый спор о парольных политиках: кто-то считает, что пароли должны быть огромные, сложные и меняться каждую неделю, а кто-то считает, что такого рода требования бессмысленны и пользователь будет чувствовать себя комфортнее, если не усложнять ему жизнь. Поэтому возникают ситуации, когда компания просто отказывается от парольных политик. Однако отказ от парольной политики влечет за собой сразу 100% существование пункта 2 из нашего списка.
2. Наличие слабых паролей у учетных записей в домене
Наличие словарных паролей или (при отсутствии парольной политики) пустые пароли, а также пароли, состоящие из одной буквы или цифры и т.д.
3. Наличие в домене "мертвых душ"
Очень часто аккаунты, созданные для тестирования, какие-то временные учетные записи, учетки уволенных сотрудников не блокируются, а остаются активными в домене, хотя ими никто не пользуется. А для злоумышленника они являются лакомыми кусочками, потому что очень часто тестовым учетным записям выдают более высокие права, чем обычным пользователям домена.
4. Не истекающие пароли у привилегированных учетных записей
Особенно если это учетная запись какого-то начальника, которому надо что-то смотреть раз в полгода (но надо же! Поэтому ему выдают повышенные права) и которого бесит постоянная смена пароля (и ему ставят, чтобы пароль не истекал). А пароль там обычно - либо 4 цифры, либо 6 (как дата рождения).
5. Хранение учетных данных в папках SYSVOL
Иногда администраторы для запуска приложения на клиентских компьютерах (сразу, при входе в систему), который требует прав администратора - хранят пароли в папке sysvol, к которой может получить доступ любой пользователь, прошедший аутентификацию
6. Отсутствие реакции со стороны средств защиты на DCSync, запуск mimikatz или PSexec
Средства защиты должны быть грамотно настроены, чтобы реагировать на стандартные атаки и утилиты, которые используют злоумышленники. Если кто не знает про DCSync - можно почитать тут (https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync)
7. Большое количество учетных записей в привилегированных группах (domain admins, enterprise admins)
Чем больше учетных записей, тем их сложнее контролировать - тем больше шансов у злоумышленника найти лазейку
8. Наличие "теневых доменных администраторов"
Иногда пользователю не выдают высокие привилегии, однако дают права на совершение каких-то привилегированных действий. Например, возможность сменить пароль другим пользователям или обновление любых атрибутов объекта. О таких пользователях забывают сразу, а с их помощью можно совершить большое количество противоправных действий в домене. Подробнее можно почитать тут (https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces)
9. Возможность проведения атаки Kerberoasting
Наличие "слабых" паролей у сервисных учетных записей позволяет злоумышленнику провести атаку kerberoasting и расшифровать пароли. Подробнее можно почитать тут (https://attack.stealthbits.com/cracking-kerberos-tgs-tickets-using-kerberoasting/)
Мы рассказали вам о наиболее часто встречающихся проблемах, которые есть у 98% компаний и которые стоит проверять как при проведении аудита, так и при проведении RedTeam кампании.
Заметки на полях: безусловный доступ
Не так давно мы рассказывали вам про условный доступ (https://news.1rj.ru/str/mis_team/141), который используют многие компании для повышения уровня безопасности в AzureAD или Office365.
Однако есть одна фишка - параметры безопасности по умолчанию и условный доступ не работают вместе!
В параметрах безопасности по умолчанию в AzureAD MFA является обязательным. И организации, у которых нет премиум аккаунта, используют параметры безопасности по умолчанию. А те организации, у которых есть премиум аккаунт - должны использовать только условный доступ и тут его надо настроить очень грамотно и не рассчитывать на то, что в параметрах безопасности по умолчанию есть второй фактор.
На картинке приведен пример неправильно настроенного условного доступа у заказчика. При смене user-agent на мобильный второй фактор не запрашивается. Да, для сотрудников заказчика это удобно. Но это также удобно и для злоумышленника.
Поэтому советуем всем при проведении RedTeam кампаний и столкновении со вторым фактором - проверять различные user-agent’ы - велик шанс того, что администратор настроил не совсем корректно политику условного доступа😉
Не так давно мы рассказывали вам про условный доступ (https://news.1rj.ru/str/mis_team/141), который используют многие компании для повышения уровня безопасности в AzureAD или Office365.
Однако есть одна фишка - параметры безопасности по умолчанию и условный доступ не работают вместе!
В параметрах безопасности по умолчанию в AzureAD MFA является обязательным. И организации, у которых нет премиум аккаунта, используют параметры безопасности по умолчанию. А те организации, у которых есть премиум аккаунт - должны использовать только условный доступ и тут его надо настроить очень грамотно и не рассчитывать на то, что в параметрах безопасности по умолчанию есть второй фактор.
На картинке приведен пример неправильно настроенного условного доступа у заказчика. При смене user-agent на мобильный второй фактор не запрашивается. Да, для сотрудников заказчика это удобно. Но это также удобно и для злоумышленника.
Поэтому советуем всем при проведении RedTeam кампаний и столкновении со вторым фактором - проверять различные user-agent’ы - велик шанс того, что администратор настроил не совсем корректно политику условного доступа😉
Заметки на полях: троянская групповая политика
Сегодня делимся с вами статьей от Darren Mar-Elia про троянскую групповую политику.
В чем суть?
Атакующий может создать групповую политику для каких-то своих целей, которую защитнику будет очень сложно найти.
Что нужно, чтобы создать такого рода политику?
1) права на запись к атрибуту gpLink в объекте контейнера в AD
2) доступная SMB шара
Для чего нужно?
Групповые политики позволяют производить различные действия с компьютерами и пользователями. Для RedTeam специалиста будет интересно с их помощью положить какой-нибудь файл на компьютеры пользователей или отключить автоматическое обновление какого-нибудь софта, например, антивируса.
Насколько заметна для защитника эта троянская GPO?
Не заметна совсем. Троянская групповая политика создается внутри легитимной групповой политики в контейнере CN=Machine или CN=User. Поэтому, если не знать, где она находится – найти ее через GPMC (консоль управления групповыми политиками) нереально
На картинке зеленым выделена легитимная групповая политика, а красным – троянская.
Где почитать подробнее?
Подробнее о том, что и как делать – можно почитать в статье https://sdmsoftware.com/security-related/the-attack-of-the-trojan-gpos/
Сегодня делимся с вами статьей от Darren Mar-Elia про троянскую групповую политику.
В чем суть?
Атакующий может создать групповую политику для каких-то своих целей, которую защитнику будет очень сложно найти.
Что нужно, чтобы создать такого рода политику?
1) права на запись к атрибуту gpLink в объекте контейнера в AD
2) доступная SMB шара
Для чего нужно?
Групповые политики позволяют производить различные действия с компьютерами и пользователями. Для RedTeam специалиста будет интересно с их помощью положить какой-нибудь файл на компьютеры пользователей или отключить автоматическое обновление какого-нибудь софта, например, антивируса.
Насколько заметна для защитника эта троянская GPO?
Не заметна совсем. Троянская групповая политика создается внутри легитимной групповой политики в контейнере CN=Machine или CN=User. Поэтому, если не знать, где она находится – найти ее через GPMC (консоль управления групповыми политиками) нереально
На картинке зеленым выделена легитимная групповая политика, а красным – троянская.
Где почитать подробнее?
Подробнее о том, что и как делать – можно почитать в статье https://sdmsoftware.com/security-related/the-attack-of-the-trojan-gpos/
Заметки на полях: Printer Cheat Sheet
Невозможно представить крупную компанию без многофункциональных устройств. Причем такого рода устройства являются полноправными участниками сетевого взаимодействия наравне с компьютерами пользователей. Таким образом МФУ становятся еще одной потенциально уязвимой точкой
Какой функционал есть у МФУ?
Современные устройства могут быть участниками почтового взаимодействия (отправлять сканы на почту пользователя), а также быть подключенными к каким-либо сетевым файловым хранилищам
Зачем такие устройства нужны атакующему при RedTeam?
Функционал МФУ дает возможность RedTeam специалисту получить дополнительную информацию (например, все почтовые ящики пользователей), читать из памяти устройства файлы, получить доступ к сетевому хранилищу и т.д.
Почему это возможно?
Потому что мало кто из администраторов следит за обновлением сетевых устройств, меняет дефолтные пароли, ограничивает доступ
Поэтому проверка безопасности сетевых устройств очень важна
Для проверки существует достаточно давний, но рабочий фреймворк PRET (https://github.com/RUB-NDS/PRET)
Побольше информации о том, чем чревато халатное отношение к сетевым МФУ можно почитать на вики по принтерам - http://hacking-printers.net/wiki/index.php/Main_Page
На картинке представлена небольшая шпаргалка по тестированию безопасности принтера. Она составлена с использованием команд PRET для проверки, но можно просто взять за основу варианты атак и самим придумать проверки для них.
Невозможно представить крупную компанию без многофункциональных устройств. Причем такого рода устройства являются полноправными участниками сетевого взаимодействия наравне с компьютерами пользователей. Таким образом МФУ становятся еще одной потенциально уязвимой точкой
Какой функционал есть у МФУ?
Современные устройства могут быть участниками почтового взаимодействия (отправлять сканы на почту пользователя), а также быть подключенными к каким-либо сетевым файловым хранилищам
Зачем такие устройства нужны атакующему при RedTeam?
Функционал МФУ дает возможность RedTeam специалисту получить дополнительную информацию (например, все почтовые ящики пользователей), читать из памяти устройства файлы, получить доступ к сетевому хранилищу и т.д.
Почему это возможно?
Потому что мало кто из администраторов следит за обновлением сетевых устройств, меняет дефолтные пароли, ограничивает доступ
Поэтому проверка безопасности сетевых устройств очень важна
Для проверки существует достаточно давний, но рабочий фреймворк PRET (https://github.com/RUB-NDS/PRET)
Побольше информации о том, чем чревато халатное отношение к сетевым МФУ можно почитать на вики по принтерам - http://hacking-printers.net/wiki/index.php/Main_Page
На картинке представлена небольшая шпаргалка по тестированию безопасности принтера. Она составлена с использованием команд PRET для проверки, но можно просто взять за основу варианты атак и самим придумать проверки для них.
Заметки на полях: Курс от ATT&CK
Наступил сентябрь, школьники и студенты пошли на учебу. В этот момент безжалостно накатывает ностальгия и возникает желание тоже записаться на какой-то курс, что-то изучить и сдать, обязательно сдать, какой-нибудь профессиональный экзамен! Однако найти хороший курс - дело не из легких. Многие из них длинные, скучные и часто бесполезные. И желание что-то изучать пропадает после первых лекций.
Мы сегодня вам хотим посоветовать небольшой, интересный и полезный для всех специалистов ИБ курс.
Речь идет о курсе Using ATT&CK for Cyber Threat Intelligence (https://attack.mitre.org/resources/training/cti/), подготовленном командой ATT&CK.
Что за курс?
Курс небольшой - состоит из 5 видео уроков, в которых рассказывается о том, что такое ATT&CK, как ее применяют специалисты при анализе киберугроз. Рассматриваются конкретные примеры реальных киберпреступных группировок. Есть задания для самостоятельной практики (с ответами, чтобы потом себя проверить).
Почему полезен?
Курс полезен всем без исключения, потому что база знаний ATT&CK набирает популярность и каждый уважающий себя специалист должен иметь представление о том, что это такое, как использовать, где можно применить в своих каких-то задачах. RedTeam специалистам полезно посмотреть для понимания того, как защитники оценивают угрозы.
Есть минусы у курса?
Есть небольшой недостаток в том, что в июле вышла новая версия ATT&CK. А курс под нее еще не адаптировали и для выполнения заданий курса надо будет использовать предыдущую версию. Но это не делает курс хуже - принцип работы все равно не сильно меняется и курс остается интересным.
P.S. курс бесплатный!
Продуктивной вам учебы!😉
Наступил сентябрь, школьники и студенты пошли на учебу. В этот момент безжалостно накатывает ностальгия и возникает желание тоже записаться на какой-то курс, что-то изучить и сдать, обязательно сдать, какой-нибудь профессиональный экзамен! Однако найти хороший курс - дело не из легких. Многие из них длинные, скучные и часто бесполезные. И желание что-то изучать пропадает после первых лекций.
Мы сегодня вам хотим посоветовать небольшой, интересный и полезный для всех специалистов ИБ курс.
Речь идет о курсе Using ATT&CK for Cyber Threat Intelligence (https://attack.mitre.org/resources/training/cti/), подготовленном командой ATT&CK.
Что за курс?
Курс небольшой - состоит из 5 видео уроков, в которых рассказывается о том, что такое ATT&CK, как ее применяют специалисты при анализе киберугроз. Рассматриваются конкретные примеры реальных киберпреступных группировок. Есть задания для самостоятельной практики (с ответами, чтобы потом себя проверить).
Почему полезен?
Курс полезен всем без исключения, потому что база знаний ATT&CK набирает популярность и каждый уважающий себя специалист должен иметь представление о том, что это такое, как использовать, где можно применить в своих каких-то задачах. RedTeam специалистам полезно посмотреть для понимания того, как защитники оценивают угрозы.
Есть минусы у курса?
Есть небольшой недостаток в том, что в июле вышла новая версия ATT&CK. А курс под нее еще не адаптировали и для выполнения заданий курса надо будет использовать предыдущую версию. Но это не делает курс хуже - принцип работы все равно не сильно меняется и курс остается интересным.
P.S. курс бесплатный!
Продуктивной вам учебы!😉
Заметки на полях: Тулзы для Password Spraying
Все знают, что один из проверенных методов получения авторизационных данных — это брутфорс. Неэстетично, зато надежно. В любой компании найдутся пользователи, у которых пароль встречается в списке самых популярных паролей и его можно сбрутить. Во избежание блокировки аккаунтов используется атака Password Spraying - когда берется несколько самых известных паролей, много-много имен пользователей и происходит проверка одного пароля на всех пользователей.
Очень удобно применять Password Spraying на Office365 и Azure.
Однако у Microsoft есть такая интересная вещь, которая детектирует применение такого рода атак. Называется Azure Smart Lockout. Это интеллектуальная блокировка, которая будет блокировать аккаунт пользователя если:
- было 10 неудачных попыток входа в аккаунт. После этого аккаунт блокируется на одну минуту. Дальше с геометрической прогрессией растет время блокировки аккаунта и уменьшается количество неверно введенных паролей.
- незнакомое местоположение, с которого пользователь пытается войти в систему. Для знакомого и незнакомого местоположений - разные счетчики неудачных попыток. Таким образом, пользователь может ввести неверный пароль 10 раз с известного местоположения и 10 раз с неизвестного.
Такие блокировки очень усложняют жизнь при бруте. Однако, есть инструменты, которые пытаются такие ограничения обойти.
Сегодня делимся с вами двумя тулзами для password spraying
MSOLSpray (https://github.com/dafthack/MSOLSpray) - powershell скрипт, который основан на использовании Microsoft Graph API и предоставляет информацию об аккаунте (включен ли MFA, существует ли пользователь, заблокирована или отключена учетная запись)
TREVORspray (https://github.com/blacklanternsecurity/TREVORspray) - инструмент, написанный на питоне, основанный на MSOLSpray (также использует Microsoft Graph API). Однако добавлена еще возможность распараллеливать через ssh доступ к своим VPS.
Все знают, что один из проверенных методов получения авторизационных данных — это брутфорс. Неэстетично, зато надежно. В любой компании найдутся пользователи, у которых пароль встречается в списке самых популярных паролей и его можно сбрутить. Во избежание блокировки аккаунтов используется атака Password Spraying - когда берется несколько самых известных паролей, много-много имен пользователей и происходит проверка одного пароля на всех пользователей.
Очень удобно применять Password Spraying на Office365 и Azure.
Однако у Microsoft есть такая интересная вещь, которая детектирует применение такого рода атак. Называется Azure Smart Lockout. Это интеллектуальная блокировка, которая будет блокировать аккаунт пользователя если:
- было 10 неудачных попыток входа в аккаунт. После этого аккаунт блокируется на одну минуту. Дальше с геометрической прогрессией растет время блокировки аккаунта и уменьшается количество неверно введенных паролей.
- незнакомое местоположение, с которого пользователь пытается войти в систему. Для знакомого и незнакомого местоположений - разные счетчики неудачных попыток. Таким образом, пользователь может ввести неверный пароль 10 раз с известного местоположения и 10 раз с неизвестного.
Такие блокировки очень усложняют жизнь при бруте. Однако, есть инструменты, которые пытаются такие ограничения обойти.
Сегодня делимся с вами двумя тулзами для password spraying
MSOLSpray (https://github.com/dafthack/MSOLSpray) - powershell скрипт, который основан на использовании Microsoft Graph API и предоставляет информацию об аккаунте (включен ли MFA, существует ли пользователь, заблокирована или отключена учетная запись)
TREVORspray (https://github.com/blacklanternsecurity/TREVORspray) - инструмент, написанный на питоне, основанный на MSOLSpray (также использует Microsoft Graph API). Однако добавлена еще возможность распараллеливать через ssh доступ к своим VPS.
GitHub
GitHub - dafthack/MSOLSpray: A password spraying tool for Microsoft Online accounts (Azure/O365). The noscript logs if a user cred…
A password spraying tool for Microsoft Online accounts (Azure/O365). The noscript logs if a user cred is valid, if MFA is enabled on the account, if a tenant doesn't exist, if a user doesn&am...
Заметки на полях: детектирование действий в AD
Каждый уважающий себя RedTeam специалист при совершении каких-либо действий должен думать о двух вещах:
1. как его действия видит команда защитников
2. как рассказать защитникам о детектировании совершенных действий
Со вторым пунктом все более или менее понятно - в AD для каждого события есть свои Event ID (windows event ID), на наличие которых в логах, можно настраивать SIEM системы. Подробнее про различные windows event ID можно почитать тут:
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx?i=j
А на первом пункте остановимся чуть подробнее и посмотрим какие действия чаще всего приходится делать во внутренней сети и как это все может отражаться в мониторинговых системах заказчика.
1. Password Spraying
Event ID = 4625. Если на один и тот же ресурс, за один и тот же короткий период пытается залогиниться больше 2 пользователей. Скорость проведения атаки - автоматизированные инструменты все-таки совершают большое количество попыток залогиниться в систему - это и становится алертом для защитников, что кто-то пытается найти валидную пару логин/пароль
2. Брутфорс
Event ID = 4740. Большое количество залоченных аккаунтов (аккакунт лочится, когда закончилось предусмотренное доменной политикой количество попыток ввести пароль).
3. Попытки использовать залоченные учетные записи
Event ID = 4625, код 0xC0000072. Поскольку список пользователей составляется путем рекона, либо путем перебора логинов по словарю (на ресурсах, где есть такая возможность), то всегда есть шанс нарваться на учетную запись, которая присутствует в системе, но залочена, потому что сотрудник уволился, учетную запись заблокировали, но не удалили.
4. Pass-the-hash и overpass-the-hash
Pass-the-hash (Event ID = 4624, тип логина - 3), overpass-the-hash (Event ID = 4624, тип логина - 9). Использовать хеш для перемещения между ресурсами сети - невероятно удобно (не нужно знать пароль пользователя, который не всегда удается узнать), однако есть отличия в типах логина с помощью хеша и с помощью пароля.
И эти отличия очень неплохо детектируются.
5. Mimikatz DCSync
Event ID = 4662 и Event ID = 5136. Репликация всех изменений каталога - ключевое свойство, которое показывает, что вероятнее всего произошла атака DCSync.
6. Ключи DPAPI
Event ID = 4692. Извлечение и бэкап DPAPI ключей также отражается в логах и сигнализирует о том, что злоумышленник пошел за ключами на контроллер домена и что нужно принимать активные действия. Подробнее про применение DPAPI можно почитать здесь
https://habr.com/ru/post/434514/
Мы рассмотрели несколько ключевых направлений, которые используются RedTeam специалистами. Конечно, это далеко не все. Помните, что нужно всегда думать о том, что вы делаете.
Каждый уважающий себя RedTeam специалист при совершении каких-либо действий должен думать о двух вещах:
1. как его действия видит команда защитников
2. как рассказать защитникам о детектировании совершенных действий
Со вторым пунктом все более или менее понятно - в AD для каждого события есть свои Event ID (windows event ID), на наличие которых в логах, можно настраивать SIEM системы. Подробнее про различные windows event ID можно почитать тут:
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx?i=j
А на первом пункте остановимся чуть подробнее и посмотрим какие действия чаще всего приходится делать во внутренней сети и как это все может отражаться в мониторинговых системах заказчика.
1. Password Spraying
Event ID = 4625. Если на один и тот же ресурс, за один и тот же короткий период пытается залогиниться больше 2 пользователей. Скорость проведения атаки - автоматизированные инструменты все-таки совершают большое количество попыток залогиниться в систему - это и становится алертом для защитников, что кто-то пытается найти валидную пару логин/пароль
2. Брутфорс
Event ID = 4740. Большое количество залоченных аккаунтов (аккакунт лочится, когда закончилось предусмотренное доменной политикой количество попыток ввести пароль).
3. Попытки использовать залоченные учетные записи
Event ID = 4625, код 0xC0000072. Поскольку список пользователей составляется путем рекона, либо путем перебора логинов по словарю (на ресурсах, где есть такая возможность), то всегда есть шанс нарваться на учетную запись, которая присутствует в системе, но залочена, потому что сотрудник уволился, учетную запись заблокировали, но не удалили.
4. Pass-the-hash и overpass-the-hash
Pass-the-hash (Event ID = 4624, тип логина - 3), overpass-the-hash (Event ID = 4624, тип логина - 9). Использовать хеш для перемещения между ресурсами сети - невероятно удобно (не нужно знать пароль пользователя, который не всегда удается узнать), однако есть отличия в типах логина с помощью хеша и с помощью пароля.
И эти отличия очень неплохо детектируются.
5. Mimikatz DCSync
Event ID = 4662 и Event ID = 5136. Репликация всех изменений каталога - ключевое свойство, которое показывает, что вероятнее всего произошла атака DCSync.
6. Ключи DPAPI
Event ID = 4692. Извлечение и бэкап DPAPI ключей также отражается в логах и сигнализирует о том, что злоумышленник пошел за ключами на контроллер домена и что нужно принимать активные действия. Подробнее про применение DPAPI можно почитать здесь
https://habr.com/ru/post/434514/
Мы рассмотрели несколько ключевых направлений, которые используются RedTeam специалистами. Конечно, это далеко не все. Помните, что нужно всегда думать о том, что вы делаете.
Хабр
«Секретики» DPAPI или DPAPI для пентестеров
Вторая статья по итогам выступления нашей команды на OFFZONE-2018. На этот раз рассмотрим доклад с MainTrack “Windows DPAPI “Sekretiki” or DPAPI for pentesters”. Внимание! Очень много буков! При...
Cheat Sheets: GPO
Могут ли групповые политики чем-то помочь RedTeam специалисту? Да! Еще как могут! И мы сейчас не будем рассматривать создание каких-либо вредоносных политик. Сами групповые политики могут очень-очень многое рассказать об устройстве компании, о средствах защиты, о программном обеспечении, которое стоит на компьютерах пользователей и много еще о чем. Как не потеряться в этом изобилии и на что смотреть в первую очередь?
Основное, на что обращаем внимание - какие параметры активности детектируют защитники. И порой узнать это достаточно сложно.
Сегодня делимся с вами шпаргалкой от Compass Security, предназначенной для BlueTeam, о том какие групповые политики должны быть включены для того, чтобы отслеживать перемещение злоумышленника по домену. И эта шпаргалка - отличная шпаргалка для RedTeam специалистов. Увидев групповые политики с такими флагами - вы точно знаете, что защитники наблюдают за этим параметром.
Например, если вы видите, что у "Turn on PowerShell noscript Block Logging" стоит флаг "Enabled", то использовать PowerShell надо максимально осторожно, потому что все действия об обработке команд и сценариев PowerShell детально записываются и вас могут вычислить по щелчку пальцев.
Могут ли групповые политики чем-то помочь RedTeam специалисту? Да! Еще как могут! И мы сейчас не будем рассматривать создание каких-либо вредоносных политик. Сами групповые политики могут очень-очень многое рассказать об устройстве компании, о средствах защиты, о программном обеспечении, которое стоит на компьютерах пользователей и много еще о чем. Как не потеряться в этом изобилии и на что смотреть в первую очередь?
Основное, на что обращаем внимание - какие параметры активности детектируют защитники. И порой узнать это достаточно сложно.
Сегодня делимся с вами шпаргалкой от Compass Security, предназначенной для BlueTeam, о том какие групповые политики должны быть включены для того, чтобы отслеживать перемещение злоумышленника по домену. И эта шпаргалка - отличная шпаргалка для RedTeam специалистов. Увидев групповые политики с такими флагами - вы точно знаете, что защитники наблюдают за этим параметром.
Например, если вы видите, что у "Turn on PowerShell noscript Block Logging" стоит флаг "Enabled", то использовать PowerShell надо максимально осторожно, потому что все действия об обработке команд и сценариев PowerShell детально записываются и вас могут вычислить по щелчку пальцев.
Цвета информационной безопасности
Мы привыкли, что в информационной безопасности чаще всего встречается два цвета команд - Red и Blue. Однако цветов и функционала у команд, занимающихся информационной безопасностью, гораздо больше. В России пока еще такая колористика не встречается, но в иностранной литературе и в очень крупных компаниях вы сможете увидеть команды следующих цветов: желтая, зеленая, оранжевая, белая, черная, фиолетовая, красная, синяя (см картинку). Давайте поговорим о них и их функционале подробнее, чтобы не удивляться, когда они нам где-нибудь повстречаются.
RedTeam - более менее понятно - команда атакующих, т.е. люди, которые непосредственно ищут уязвимости и проводят атаки
BlueTeam - тоже вроде бы понятно - команда защитников. По сути, BlueTeam — это SOC.
PurpleTeam - посредники при взаимодействии красной и синей команды. Поскольку в RedTeam и BlueTeam представлены именно технические специалисты, которые не всегда могут провзаимодействовать между собой - нужна команда (или отдельные люди), которая будет выстраивать процесс тестирования и взаимодействовать с обеими командами. Представители данной команды встречаются в России.
YellowTeam - по сути это разработчики. Это могут быть как разработчики ПО и различных приложений, так и системные архитекторы.
OrangeTeam - команда, которая обучает разработчиков безопасности и помогает им взглянуть на свою разработку с точки зрения атакующего. Т.е. они по своей сути не разработчики, а атакующие узкого профиля. Например, это специалисты по поиску веб-уязвимостей, которые могут рассказать разработчикам что нужно сделать, чтобы впихнутая злоумышленником кавычка не позволила ему получить данные, которые он хотел бы получить.
GreenTeam - команда, которая пытается внедрить мониторинг и логирование событий на этапе построения какой-либо системы, а также упростить интеграцию новых систем в существующие системы мониторинга. Например, в компании появился новый антивирус, логи которого необходимо как-то обрабатывать и было бы неплохо, чтобы они отображались в глобальной SIEM компании. Это будет делать (в идеале конечно) Green Team.
WhiteTeam - не всегда можно назвать командой - скорее нетехнические люди, которые выстраивают процессы в каждой команде, следят за прогрессом, расставляют организационные приоритеты, помогают во взаимодействии.
BlackTeam - команда, которая подсказывает всем командам какую модель угроз рассматриваем для организации, какие тенденции в ИБ, TTP (тактики, методы и процедуры) злоумышленника. Ее цель – чтобы команды работали в одном направлении и видели ИБ компании одинаково.
Мы привыкли, что в информационной безопасности чаще всего встречается два цвета команд - Red и Blue. Однако цветов и функционала у команд, занимающихся информационной безопасностью, гораздо больше. В России пока еще такая колористика не встречается, но в иностранной литературе и в очень крупных компаниях вы сможете увидеть команды следующих цветов: желтая, зеленая, оранжевая, белая, черная, фиолетовая, красная, синяя (см картинку). Давайте поговорим о них и их функционале подробнее, чтобы не удивляться, когда они нам где-нибудь повстречаются.
RedTeam - более менее понятно - команда атакующих, т.е. люди, которые непосредственно ищут уязвимости и проводят атаки
BlueTeam - тоже вроде бы понятно - команда защитников. По сути, BlueTeam — это SOC.
PurpleTeam - посредники при взаимодействии красной и синей команды. Поскольку в RedTeam и BlueTeam представлены именно технические специалисты, которые не всегда могут провзаимодействовать между собой - нужна команда (или отдельные люди), которая будет выстраивать процесс тестирования и взаимодействовать с обеими командами. Представители данной команды встречаются в России.
YellowTeam - по сути это разработчики. Это могут быть как разработчики ПО и различных приложений, так и системные архитекторы.
OrangeTeam - команда, которая обучает разработчиков безопасности и помогает им взглянуть на свою разработку с точки зрения атакующего. Т.е. они по своей сути не разработчики, а атакующие узкого профиля. Например, это специалисты по поиску веб-уязвимостей, которые могут рассказать разработчикам что нужно сделать, чтобы впихнутая злоумышленником кавычка не позволила ему получить данные, которые он хотел бы получить.
GreenTeam - команда, которая пытается внедрить мониторинг и логирование событий на этапе построения какой-либо системы, а также упростить интеграцию новых систем в существующие системы мониторинга. Например, в компании появился новый антивирус, логи которого необходимо как-то обрабатывать и было бы неплохо, чтобы они отображались в глобальной SIEM компании. Это будет делать (в идеале конечно) Green Team.
WhiteTeam - не всегда можно назвать командой - скорее нетехнические люди, которые выстраивают процессы в каждой команде, следят за прогрессом, расставляют организационные приоритеты, помогают во взаимодействии.
BlackTeam - команда, которая подсказывает всем командам какую модель угроз рассматриваем для организации, какие тенденции в ИБ, TTP (тактики, методы и процедуры) злоумышленника. Ее цель – чтобы команды работали в одном направлении и видели ИБ компании одинаково.
Заметки на полях: Пентест AD. Mindmap
Когда требуется провести пентест только внутренней сети Заказчика (когда заказчик дает только подключение в сеть и больше никакой информации), первое время (вне зависимости от опыта) возникает небольшой ступор и в голове проносится мысль "а с чего начать то?". Чаще всего, конечно, смотрим свой IP, маску, DNS, gateway и, исходя из этого, начинаем сканировать сетку, искать контроллеры и по крупицам составлять картину внутренней сети.
А дальше все зависит от качетсва сети заказчика (насколько у него все настроенно корректно и все гайки закручены-подкручены) и от нашего везения.
Но какую-то последовательность действий составить все-таки можно.
Сегодня делимся с вами очень-очень-очень крутым mindmap от Mayfly. Полезно всем, вне зависимости от количества исследованных AD.
В хорошем качестве mindmap можно найти тут - https://i.ibb.co/TKYNCNP/Pentest-ad.png
Когда требуется провести пентест только внутренней сети Заказчика (когда заказчик дает только подключение в сеть и больше никакой информации), первое время (вне зависимости от опыта) возникает небольшой ступор и в голове проносится мысль "а с чего начать то?". Чаще всего, конечно, смотрим свой IP, маску, DNS, gateway и, исходя из этого, начинаем сканировать сетку, искать контроллеры и по крупицам составлять картину внутренней сети.
А дальше все зависит от качетсва сети заказчика (насколько у него все настроенно корректно и все гайки закручены-подкручены) и от нашего везения.
Но какую-то последовательность действий составить все-таки можно.
Сегодня делимся с вами очень-очень-очень крутым mindmap от Mayfly. Полезно всем, вне зависимости от количества исследованных AD.
В хорошем качестве mindmap можно найти тут - https://i.ibb.co/TKYNCNP/Pentest-ad.png
Заметки на полях: OSINT
Про OSINT знают все. А нужен ли он при проведении RedTeam?
Наш ответ - однозначно нужен!
Качественный OSINT решает сразу несколько задач:
1) находим все сетки и домены компании - чем больше периметр компании, тем больше шанс найти что-то интересное и давным-давно забытое. Ни одна киберпреступная группировка не будет все время пытаться взломать сайт компании, который находится на хостинге и постоянно обновляется, если на периметре есть старые приложения с кучей уязвимостей.
2) составление списка сотрудников компании для дальнейшего брута паролей. Тут принцип простой - чем больше найдено людей, тем больше вероятность, что при бруте подойдет какой-то словарный пароль
3) составление списка для фишинговых рассылок. В социальных сетях на данный момент уже есть абсолютно все. Мы живем в такое время, когда даже бабушки легко используют мессенджеры и скайпы. Поэтому изучение соц сетей важно для понимания возраста сотрудников, их интересов и круга общения.
4) можно найти веб-ресурсы, которые раскрывают информацию о компании. Например, о внутренних именах серверов и доменах
5) показываем заказчику сколько информации о компании и сотрудниках можно найти в открытом доступе. Чаще всего это прям вау-эффект - заказчик не ожидает, что информации настолько много.
У нас был интересный кейс, когда не могли составить список сотрудников, пока не наткнулись в инстаграме на одну общую фотографию с корпоратива, где hr писала пост благодарности всем за шикарный праздник и отметила большинство сотрудников. Перейти по ссылкам на их инстаграмы, понять какие ники используют и развить исследование дальше - не составило труда.
К чему это все? OSINT нужно и важно. И для развития в нем необходимо постоянно совершенствоваться, находить новый инструментарий, новые ресурсы и т.д.
Порекомендуем несколько полезностей, если тематика вам интересна:
https://www.youtube.com/watch?v=eLL6BPKvwlg&list=PLtgaAEEmVe6ByS5bH34HPGBPfbY70RwIY - отличная лекция от SANS с OSINT Summit 2020 (там в плейлисте есть еще 2 видео с саммита, тоже интересные)
https://www.youtube.com/playlist?list=PL423I_gHbWUUOs09899rex4t2l5py9YIk - плейлист с 10 минутными видео про инструментарий и небольшие кейсы. Очень удобный формат по времени, минимум воды. Но некоторые видео прям совсем для новичков.
https://osintcurio.us/ - создатели 10 минутных видео из ссылки выше. Интересные статьи и подкасты
https://osint-i1.thinkific.com/courses/osint-challenge - для тех, кто хочет себя проверить и приобрести опыт - неплохие задания, по типу ctfных. Требуется регистрация. Временные почты принимаются.
Про OSINT знают все. А нужен ли он при проведении RedTeam?
Наш ответ - однозначно нужен!
Качественный OSINT решает сразу несколько задач:
1) находим все сетки и домены компании - чем больше периметр компании, тем больше шанс найти что-то интересное и давным-давно забытое. Ни одна киберпреступная группировка не будет все время пытаться взломать сайт компании, который находится на хостинге и постоянно обновляется, если на периметре есть старые приложения с кучей уязвимостей.
2) составление списка сотрудников компании для дальнейшего брута паролей. Тут принцип простой - чем больше найдено людей, тем больше вероятность, что при бруте подойдет какой-то словарный пароль
3) составление списка для фишинговых рассылок. В социальных сетях на данный момент уже есть абсолютно все. Мы живем в такое время, когда даже бабушки легко используют мессенджеры и скайпы. Поэтому изучение соц сетей важно для понимания возраста сотрудников, их интересов и круга общения.
4) можно найти веб-ресурсы, которые раскрывают информацию о компании. Например, о внутренних именах серверов и доменах
5) показываем заказчику сколько информации о компании и сотрудниках можно найти в открытом доступе. Чаще всего это прям вау-эффект - заказчик не ожидает, что информации настолько много.
У нас был интересный кейс, когда не могли составить список сотрудников, пока не наткнулись в инстаграме на одну общую фотографию с корпоратива, где hr писала пост благодарности всем за шикарный праздник и отметила большинство сотрудников. Перейти по ссылкам на их инстаграмы, понять какие ники используют и развить исследование дальше - не составило труда.
К чему это все? OSINT нужно и важно. И для развития в нем необходимо постоянно совершенствоваться, находить новый инструментарий, новые ресурсы и т.д.
Порекомендуем несколько полезностей, если тематика вам интересна:
https://www.youtube.com/watch?v=eLL6BPKvwlg&list=PLtgaAEEmVe6ByS5bH34HPGBPfbY70RwIY - отличная лекция от SANS с OSINT Summit 2020 (там в плейлисте есть еще 2 видео с саммита, тоже интересные)
https://www.youtube.com/playlist?list=PL423I_gHbWUUOs09899rex4t2l5py9YIk - плейлист с 10 минутными видео про инструментарий и небольшие кейсы. Очень удобный формат по времени, минимум воды. Но некоторые видео прям совсем для новичков.
https://osintcurio.us/ - создатели 10 минутных видео из ссылки выше. Интересные статьи и подкасты
https://osint-i1.thinkific.com/courses/osint-challenge - для тех, кто хочет себя проверить и приобрести опыт - неплохие задания, по типу ctfных. Требуется регистрация. Временные почты принимаются.
YouTube
Weaponizing the Deep Web | SANS OSINT Summit 2020
There’s a lot of talk about data breaches but not much is discussed about where the data ends up and how it can be used for good. In this low-key talk, we’ll discuss where breach data ends up, how you can find copies of it, and most importantly, how you can…
Заметки на полях: второй фактор
Двухфакторная аутентификация — это стильно, модно, молодёжно и соответствует требованиям регуляторов. Чаще всего в качестве второго фактора используют одноразовый код, который приходит в смске. Но в мире все не идеально и очень часто встречаются какие-то недостатки и уязвимости.
Например, для доступа в личный кабинет какого-то веб-ресурса необходимо ввести второй фактор, который присылается смской и состоит из 4 цифр. Однако, при вводе кода выясняется, что код не истекает, а живет до момента, пока не будет выслан новый код и нет каких-то ограничений на количество попыток ввода кода. Таким образом, злоумышленнику остается просто перебрать 4 цифры и получить доступ за пару минут.
Делимся с вами небольшими советами о том, на какие недостатки можно проверить 2FA.
Двухфакторная аутентификация — это стильно, модно, молодёжно и соответствует требованиям регуляторов. Чаще всего в качестве второго фактора используют одноразовый код, который приходит в смске. Но в мире все не идеально и очень часто встречаются какие-то недостатки и уязвимости.
Например, для доступа в личный кабинет какого-то веб-ресурса необходимо ввести второй фактор, который присылается смской и состоит из 4 цифр. Однако, при вводе кода выясняется, что код не истекает, а живет до момента, пока не будет выслан новый код и нет каких-то ограничений на количество попыток ввода кода. Таким образом, злоумышленнику остается просто перебрать 4 цифры и получить доступ за пару минут.
Делимся с вами небольшими советами о том, на какие недостатки можно проверить 2FA.
Заметки на полях: Пароль от точки доступа
Ни для кого не секрет, что при подключении к Wi-Fi сети, пароль запрашивается только один раз - при первом подключении. После его корректного ввода - сразу сохраняется и клиент больше не вводит пароль для подключения к уже известной сети.
Это настолько естественно и обыденно, что подобные вещи мы не замечаем.
Сейчас у большинства организаций сеть для сотрудников идет не по шнурку, а по wi-fi. Это удобнее, но не всегда безопаснее.
Сегодня поделимся с вами небольшим кейсом о том, как использовать информацию о сохраненных паролях Wi-Fi сетей.
Предположим, что в ходе нашей RedTeam кампании мы смогли с помощью фишинга закинуть вредонос на компьютер одного из сотрудников компании. Одним из векторов для продолжения атаки - узнать пароль от Wi-Fi в офисе, приехать туда физически, подключиться по Wi-Fi к сети и дальше работать с внутренними ресурсами. Потому что наш вредонос может быть обнаружен в любой момент, и мы останемся ни с чем. Да, нам нужно физически приехать к офису заказчика и пытаться поймать Wi-Fi сеть. Возникнут трудности, если заказчик в другом городе. Но мы рассматриваем кейс, когда такая возможность есть.
Для того, чтобы узнать пароль от точки доступа нам необходимо:
1. получить список Wi-Fi сетей, к которым пользователь подключался
Для этого выполняем команду:
netsh wlan show profiles
В результате видим список Wi-Fi сетей, к которым пользователь подключался. Причем верхнее имя — это самое свежее по времени подключение.
2. Получаем информацию о пароле интересующей нас сети
netsh wlan show profile name=имя интересной нам сети key=clear
Пароль в открытом виде (см картинку)
3. Едем и подключаемся к сети)
Ни для кого не секрет, что при подключении к Wi-Fi сети, пароль запрашивается только один раз - при первом подключении. После его корректного ввода - сразу сохраняется и клиент больше не вводит пароль для подключения к уже известной сети.
Это настолько естественно и обыденно, что подобные вещи мы не замечаем.
Сейчас у большинства организаций сеть для сотрудников идет не по шнурку, а по wi-fi. Это удобнее, но не всегда безопаснее.
Сегодня поделимся с вами небольшим кейсом о том, как использовать информацию о сохраненных паролях Wi-Fi сетей.
Предположим, что в ходе нашей RedTeam кампании мы смогли с помощью фишинга закинуть вредонос на компьютер одного из сотрудников компании. Одним из векторов для продолжения атаки - узнать пароль от Wi-Fi в офисе, приехать туда физически, подключиться по Wi-Fi к сети и дальше работать с внутренними ресурсами. Потому что наш вредонос может быть обнаружен в любой момент, и мы останемся ни с чем. Да, нам нужно физически приехать к офису заказчика и пытаться поймать Wi-Fi сеть. Возникнут трудности, если заказчик в другом городе. Но мы рассматриваем кейс, когда такая возможность есть.
Для того, чтобы узнать пароль от точки доступа нам необходимо:
1. получить список Wi-Fi сетей, к которым пользователь подключался
Для этого выполняем команду:
netsh wlan show profiles
В результате видим список Wi-Fi сетей, к которым пользователь подключался. Причем верхнее имя — это самое свежее по времени подключение.
2. Получаем информацию о пароле интересующей нас сети
netsh wlan show profile name=имя интересной нам сети key=clear
Пароль в открытом виде (см картинку)
3. Едем и подключаемся к сети)
Заметки на полях: GitHub Dorks
При проведении OSINT особое внимание нужно обращать на GitHub. Почему?
Очень часто разработчики забывают или даже не задумываются над тем, что исходный код проекта перед публикацией следует почистить от данных, которые могут раскрыть чувствительную для компании информацию. Например, пароли, токены аутентификации, приватные ключи и т.д.
Показательны истории компаний DJI и DXC Technologies - случайная публикация ключей доступа aws в открытом репозитории привела к утечке данных и репутационным проблемам.
Сегодня делимся с вами списком dorks, который будет полезен как BlueTeam (для проверки ресурсов компании перед публикацией), так и RedTeam (для поиска чувствительной информации в уже опубликованных проектах)
https://github.com/obheda12/GitDorker/blob/master/Dorks/alldorks.txt
При проведении OSINT особое внимание нужно обращать на GitHub. Почему?
Очень часто разработчики забывают или даже не задумываются над тем, что исходный код проекта перед публикацией следует почистить от данных, которые могут раскрыть чувствительную для компании информацию. Например, пароли, токены аутентификации, приватные ключи и т.д.
Показательны истории компаний DJI и DXC Technologies - случайная публикация ключей доступа aws в открытом репозитории привела к утечке данных и репутационным проблемам.
Сегодня делимся с вами списком dorks, который будет полезен как BlueTeam (для проверки ресурсов компании перед публикацией), так и RedTeam (для поиска чувствительной информации в уже опубликованных проектах)
https://github.com/obheda12/GitDorker/blob/master/Dorks/alldorks.txt
Заметки на полях: Attack Samples
Чаще всего специалисты (как RedTeam, так и BlueTeam) понимают, что за атака произошла, какова ее цель, механизм атаки. Но нет понимания того, как данная атака отображается в журналах событий Windows.
Почему это важно? И для кого это нужно?
RedTeam нужно всегда понимать насколько их действия являются заметными, как на это могут среагировать средства защиты и продумывать какую информацию из журнала событий смогут получить BlueTeam специалисты. В свою очередь, BlueTeam должна понимать какие именно события говорят о возможных угрозах безопасности. Поскольку в журнал событий Windows записывается очень много информации - порой бывает сложно найти какие именно действия выполнял злоумышленник, если не знаешь, что искать.
Для того, чтобы знать, что искать - нужна какая-то практика. Хотя бы практика в изучении журналов событий при проведении атак различных видов.
Например, на картинке можно увидеть часть журнала событий Windows при эксплуатации CVE-2020-1030 (Windows Print Spooler Elevation of Privilege Vulnerability).
Можно самим проводить разного рода атаки, смотреть и изучать журналы событий. Но это трудозатратно в плане разворачивания лаборатории, поиска эксплойтов, инструментов и т.д.
Есть очень крутой, постоянно пополняемый репозиторий (https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES) от Samir (https://twitter.com/SBousseaden) с образцами самых популярных атак. Очень его вам рекомендуем - полезная вещь. Пригодится как BlueTeam, так и RedTeam.
Чаще всего специалисты (как RedTeam, так и BlueTeam) понимают, что за атака произошла, какова ее цель, механизм атаки. Но нет понимания того, как данная атака отображается в журналах событий Windows.
Почему это важно? И для кого это нужно?
RedTeam нужно всегда понимать насколько их действия являются заметными, как на это могут среагировать средства защиты и продумывать какую информацию из журнала событий смогут получить BlueTeam специалисты. В свою очередь, BlueTeam должна понимать какие именно события говорят о возможных угрозах безопасности. Поскольку в журнал событий Windows записывается очень много информации - порой бывает сложно найти какие именно действия выполнял злоумышленник, если не знаешь, что искать.
Для того, чтобы знать, что искать - нужна какая-то практика. Хотя бы практика в изучении журналов событий при проведении атак различных видов.
Например, на картинке можно увидеть часть журнала событий Windows при эксплуатации CVE-2020-1030 (Windows Print Spooler Elevation of Privilege Vulnerability).
Можно самим проводить разного рода атаки, смотреть и изучать журналы событий. Но это трудозатратно в плане разворачивания лаборатории, поиска эксплойтов, инструментов и т.д.
Есть очень крутой, постоянно пополняемый репозиторий (https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES) от Samir (https://twitter.com/SBousseaden) с образцами самых популярных атак. Очень его вам рекомендуем - полезная вещь. Пригодится как BlueTeam, так и RedTeam.
Cheat Sheets: Анализ вредоносных документов
Самая популярная и эффективная атака - рассылка фишинговых писем. В независимости от количества лекций и тренингов в компании - всегда найдется парочка человек, которые перейдут по ссылке или же откроют документ, присланный в фишинговом письме. Это человеческий фактор, о которого никуда не деться. Да и фишинговые письма давно уже перестали быть письмами богатого дядюшки из Зимбабве, который только и мечтает о том, чтобы оставить вам наследство.
Фишинговые кампании порой очень сложно раскусить - подобранные темы письма всегда актуальны, документы выглядят правдоподобно, стилистика безупречна. Одним из примеров таких животрепещущих тем - рассылки, связанные с Covid-19 - от предложений бесплатно сдать тест на коронавирус до рассылок документов с инструкциями об удаленной работе в офисе.
Делимся с вами небольшой шпаргалкой, которая поможет BlueTeam специалистам анализировать вредоносные документы. Это может сильно помочь в расследовании инцидента.
Самая популярная и эффективная атака - рассылка фишинговых писем. В независимости от количества лекций и тренингов в компании - всегда найдется парочка человек, которые перейдут по ссылке или же откроют документ, присланный в фишинговом письме. Это человеческий фактор, о которого никуда не деться. Да и фишинговые письма давно уже перестали быть письмами богатого дядюшки из Зимбабве, который только и мечтает о том, чтобы оставить вам наследство.
Фишинговые кампании порой очень сложно раскусить - подобранные темы письма всегда актуальны, документы выглядят правдоподобно, стилистика безупречна. Одним из примеров таких животрепещущих тем - рассылки, связанные с Covid-19 - от предложений бесплатно сдать тест на коронавирус до рассылок документов с инструкциями об удаленной работе в офисе.
Делимся с вами небольшой шпаргалкой, которая поможет BlueTeam специалистам анализировать вредоносные документы. Это может сильно помочь в расследовании инцидента.
Заметки на полях: Что посмотреть?
Окончание года - время, когда мы мечтаем, что с нового года начнем новую жизнь - успеем все, что не успели раньше, будем соблюдать режим, худеть, много читать... в общему каждый мечтает, что в новом году он будет более продвинутой версией себя. В новогодние каникулы особенно тянет посмотреть или прочитать то, что оставили в закладках "на потом, когда время будет".
Поэтому сегодня мы делимся с вами полезными видео с прошедших классных конференций 2020 года.
SANS Threat Hunting & Incident Response Summit 2020
Наличие даже самых продвинутых средств защиты не гарантирует на 100% безопасность компании. При целенаправленной атаке злоумышленник может обойти даже самые продвинутые системы безопасности. На саммите ведущие специалисты делятся методами и инструментами, которые можно использовать для успешного выявления, сдерживания и устранения злоумышленников, нацеленных на получение доступа к информации организации.
https://youtube.com/playlist?list=PLfouvuAjspTpESwgitHe8roa7XBOnemFa
The SANS Pen Test Hackfest Summit & Training
Основная ценность этого саммита - возможность получения практики - решение различных CTF тасков и проведение пентеста. Но лекции от спикеров также достаточно интересны и полезны.
https://youtube.com/playlist?list=PLdVJWiil7RxoW8rBeKc0flY8bRuD3M68L
SANS DFIR Summit 2020
Ежегодный саммит SANS по цифровой криминалистике и реагированию на инциденты. Все представленные видео - кладезь полезной информации для тех, кто хочет узнать о новейших инструментах судебной экспертизы с открытым исходным кодом, о методах и стратегиях, применяемых в расследованиях.
https://youtube.com/playlist?list=PLfouvuAjspTo4SbbY-ykIdD7MPFWaloSh
Blue Team Summit 2020
Саммит для BlueTeam с полезной информацией. Не очень много видео, но они достаточно интересные
https://youtube.com/playlist?list=PLs4eo9Tja8bjMyah8ZEOlG9sq4070b5_v
DEF CON Safe Mode Red Team Village
Must have для RedTeam специалистов
https://youtube.com/playlist?list=PL9fPq3eQfaaAjHEV1gvvUuaKDrzafx3I-
#HITBCyberWeek2020 - Main Track & Labs
Видео с HITBCyberWeek - ежегодного мероприятия по информационной безопасности, проводимого в ОАЭ (в этом году виртуально)
https://youtube.com/playlist?list=PLmv8T5-GONwR2RnH6nKJtpgxyt4NIMG4t
Окончание года - время, когда мы мечтаем, что с нового года начнем новую жизнь - успеем все, что не успели раньше, будем соблюдать режим, худеть, много читать... в общему каждый мечтает, что в новом году он будет более продвинутой версией себя. В новогодние каникулы особенно тянет посмотреть или прочитать то, что оставили в закладках "на потом, когда время будет".
Поэтому сегодня мы делимся с вами полезными видео с прошедших классных конференций 2020 года.
SANS Threat Hunting & Incident Response Summit 2020
Наличие даже самых продвинутых средств защиты не гарантирует на 100% безопасность компании. При целенаправленной атаке злоумышленник может обойти даже самые продвинутые системы безопасности. На саммите ведущие специалисты делятся методами и инструментами, которые можно использовать для успешного выявления, сдерживания и устранения злоумышленников, нацеленных на получение доступа к информации организации.
https://youtube.com/playlist?list=PLfouvuAjspTpESwgitHe8roa7XBOnemFa
The SANS Pen Test Hackfest Summit & Training
Основная ценность этого саммита - возможность получения практики - решение различных CTF тасков и проведение пентеста. Но лекции от спикеров также достаточно интересны и полезны.
https://youtube.com/playlist?list=PLdVJWiil7RxoW8rBeKc0flY8bRuD3M68L
SANS DFIR Summit 2020
Ежегодный саммит SANS по цифровой криминалистике и реагированию на инциденты. Все представленные видео - кладезь полезной информации для тех, кто хочет узнать о новейших инструментах судебной экспертизы с открытым исходным кодом, о методах и стратегиях, применяемых в расследованиях.
https://youtube.com/playlist?list=PLfouvuAjspTo4SbbY-ykIdD7MPFWaloSh
Blue Team Summit 2020
Саммит для BlueTeam с полезной информацией. Не очень много видео, но они достаточно интересные
https://youtube.com/playlist?list=PLs4eo9Tja8bjMyah8ZEOlG9sq4070b5_v
DEF CON Safe Mode Red Team Village
Must have для RedTeam специалистов
https://youtube.com/playlist?list=PL9fPq3eQfaaAjHEV1gvvUuaKDrzafx3I-
#HITBCyberWeek2020 - Main Track & Labs
Видео с HITBCyberWeek - ежегодного мероприятия по информационной безопасности, проводимого в ОАЭ (в этом году виртуально)
https://youtube.com/playlist?list=PLmv8T5-GONwR2RnH6nKJtpgxyt4NIMG4t
Дорогие друзья, коллеги, единомышленники!
Команда [MIS]Team поздравляет вас с наступающим Новым годом!
Желаем вам в 2021 году здоровья, профессионального роста и душевной гармонии!
Спасибо вам за то, что читаете, репостите, рекомендуете наш канал!
И по традиции небольшой комикс про Little Bobby)
Счастливого Нового года!
Ваши [MIS]Team
Команда [MIS]Team поздравляет вас с наступающим Новым годом!
Желаем вам в 2021 году здоровья, профессионального роста и душевной гармонии!
Спасибо вам за то, что читаете, репостите, рекомендуете наш канал!
И по традиции небольшой комикс про Little Bobby)
Счастливого Нового года!
Ваши [MIS]Team
Заметки на полях: Пентест ELK
ELK - один из самых популярных стеков технологий. В очень многих компаниях используется связка Elasticsearch-Kibana-Logstash, в которой порой хранится очень интересная и важная информация (чаще всего это логи с различных систем). И очень часто при RedTeam эти логи могут помочь - доменные имена, ip-адреса, имена пользователей, какая-то информация, которая может косвенно помочь - все это мы встречали в своей практике в ELK разных компаний.
Речь идет к тому, что если вы встретили ELK - его надо тоже как-то проверить, "пропентестить" и указать Заказчику на недостатки.
Опубликовали небольшой рассказ о том, на что стоит обратить внимание, если столкнулись с elk и что полезного оттуда можно достать.
Надеемся, что информация будет полезной!
https://misteam.medium.com/%D0%BF%D0%B5%D0%BD%D1%82%D0%B5%D1%81%D1%82-elk-250eb4806fab
ELK - один из самых популярных стеков технологий. В очень многих компаниях используется связка Elasticsearch-Kibana-Logstash, в которой порой хранится очень интересная и важная информация (чаще всего это логи с различных систем). И очень часто при RedTeam эти логи могут помочь - доменные имена, ip-адреса, имена пользователей, какая-то информация, которая может косвенно помочь - все это мы встречали в своей практике в ELK разных компаний.
Речь идет к тому, что если вы встретили ELK - его надо тоже как-то проверить, "пропентестить" и указать Заказчику на недостатки.
Опубликовали небольшой рассказ о том, на что стоит обратить внимание, если столкнулись с elk и что полезного оттуда можно достать.
Надеемся, что информация будет полезной!
https://misteam.medium.com/%D0%BF%D0%B5%D0%BD%D1%82%D0%B5%D1%81%D1%82-elk-250eb4806fab
Medium
Пентест ELK
ELK — один из самых популярных стеков технологий. В очень многих компаниях используется связка Elasticsearch-Kibana-Logstash, в которой…