Доброго времени суток, %username%. Голосование закончилось, а значит пришло время о*утельных историй от Jeff'a.
Введение
Итак, %username%, давай представим такой сюрреалистичный сюжет:
Ты пошел дальше паблик схем (типа файлообменников и прочего), уже можешь не просто заливать инсталлы на паблик стиллеры, но даже получить доступ в небольшую корп. сеть на, скажем так, условные 10 машин...
Круто, но что дальше? Ты уже чувствуешь, что ты не обычный скрипт-кидди, но уже почти SLAVIK. Ты хочешь быть лучшим, решаешь хакнуть сеть крупнее. Твоя цель уже не тупой стилл аккаунтов, но кража бизнес данных, так как это принесет тебе больший профит. И вот атака началась и... ничего не вышло? Ты не понимаешь, что происходит и почему все накрылось медным тазом. Все инструменты были кастомными / FUD, однако все равно все пошло одним местом...
И тут, мой дорогой %username%, ты уже хочешь сказать:
- Jeff, шо за херня? Твоио*утельные истории меня уже доебали.
Да, понимаю твое негодования, однако этот сюжет был рассказан с целью показать, что AV лишь верхушка айсберга в защитном периметре сети крупной организации, а не рассказать топ-стори про хацкера который не смог.
Современные системы защиты крайне продвинуты, умны и обычно включают в себя целую цепочку различных решений разного уровня, иногда сразу от нескольких вендоров, а также данные системы могут получать информации об ивентах на любом из устройств, подключенных к сети организации.
Примеры: подозрительный траффик (порт скан), некорректный ввод логина и прочее.
В итоге любое специфическое поведение может быть определенно системой как некоторый "security event" и далее будет отправлен в некоторую центральную систему мониторинга.
Подобные системы мониторинга называются IDS (Intrusion Detection System).
В периметре организации и обычно классифицируют следующим образом :
Вот здесь и вступает в игру Security Operations Center (SOC).
Как работает SOC
И так для начала давайте разберемся с тем, что из себя представляет типичная команда мечты любой состоявшейся организации.
Хотя сами команды формируются по разному в зависимости от целей и бюджета (а зачастую только от количества $$$), но в целом команда выглядит так:
Понимание того, как функционирует SOC необходимо для проведение атаки на крупную организацию, ибо этих ребят нам необходимо переиграть.
Одной из самых крупных проблем большинства текущих SOC это время реагирования на инцидент на первой линии.
Время реагирования SOC
Время реагирования - это время, которое потребуется аналитику 1-ой линии на обнаружение ивента, что является величиной переменной.
В последний час до конца смены аналитиков (ранним утром) обычно является овощным периодом для работников, так что в это время время реагирования самое низкое. Во время проведения атаки попытайтесь узнать время работы SOC вашей цели, зачастую это время между 02.00 - 03.00 или 6.00 - 7.00.
Время реагирования также может быть увеличено за счет флуда, создания ложных ивентов. Для этого лучше всего выбрать другую часть инфраструктуры цели (публичный веб-сервис) и провести несколько грязных атак (порт скан, брут форс, сканнер уязвимостей, ддос) для генерирования кучи траффика. Цель - создание как можно больше тикетов между вашей атакой.
Evasion-техники IDS
Как и с AV, так и с IDS можно все переиграть. Что же для этого сделать?
Большенсво популярных вендоров имеют триал версии подобных систем, которые вы можете установить на виртуальные машины. Вы не сможете смоделировать таким образом сеть, но сможете пронаблюдать поведения IDS.
Для примеры можно взять AlienVault, одного из самых крупных вендоров в данной области. Они предоставляют полный комплекс решений от NIDS и HIDS до SIEM. Многие SOC базируются на их наборе инструментов и могут полать данные почти отовсюду. Скачайте их USM и поиграйте с ней, посмотрите на их интеграцию с открытой площадкой по обмену IOC - OTX (Open Threat eXchange).
Одна из главных проблем, где валятся большинство вредоносного ПО - это связь с C2. Соединение должно выглядеть максимально легитимно. Как вариант можно использовать для отправки данных SSH туннелей, что для подобных систем выглядит нормально.
Security Event
В финальной части давайте поговорим о том, как вообще ивенты выбираются для отправки в SIEM.
В подобных системах безопасности наш электрический бро принимает решение о том, стоит ли этот ивент репортить и как его пометить полагаясь на чистую математику, ибо пока настоящего ИИ еще не придумали.
Обычно по подобной формуле:
EventRisk = (AssetValue x EventReliability x EventPriority) / 25
AssetValue - значение от 0 (херня) до 5 (очень ценный), ценность узла
EventReliability - значение от 0 до 10, надежность ивента
EventPriority - значение от 0 до 5, приоритет
В случае атаки наилучшим выбором для проникновения будут те узлы, которые имеют самый низкий Asset. Под данные девайсы попадают разные принтеры, факсы и другие девайсы на которые обычно обращаешь внимание в последнюю очередь. Так же некоторые девайсы могут иметь Asset = 5, однако в силу правил их эксплуатации EventReliability на данном устройстве скорее всего будет низким.
Во время подобных атак вам нужно четко представлять какие действия на каких устройствах будут являться подозрительными.
Заключение
Введение
Итак, %username%, давай представим такой сюрреалистичный сюжет:
Ты пошел дальше паблик схем (типа файлообменников и прочего), уже можешь не просто заливать инсталлы на паблик стиллеры, но даже получить доступ в небольшую корп. сеть на, скажем так, условные 10 машин...
Круто, но что дальше? Ты уже чувствуешь, что ты не обычный скрипт-кидди, но уже почти SLAVIK. Ты хочешь быть лучшим, решаешь хакнуть сеть крупнее. Твоя цель уже не тупой стилл аккаунтов, но кража бизнес данных, так как это принесет тебе больший профит. И вот атака началась и... ничего не вышло? Ты не понимаешь, что происходит и почему все накрылось медным тазом. Все инструменты были кастомными / FUD, однако все равно все пошло одним местом...
И тут, мой дорогой %username%, ты уже хочешь сказать:
- Jeff, шо за херня? Твои
Да, понимаю твое негодования, однако этот сюжет был рассказан с целью показать, что AV лишь верхушка айсберга в защитном периметре сети крупной организации, а не рассказать топ-стори про хацкера который не смог.
Современные системы защиты крайне продвинуты, умны и обычно включают в себя целую цепочку различных решений разного уровня, иногда сразу от нескольких вендоров, а также данные системы могут получать информации об ивентах на любом из устройств, подключенных к сети организации.
Примеры: подозрительный траффик (порт скан), некорректный ввод логина и прочее.
В итоге любое специфическое поведение может быть определенно системой как некоторый "security event" и далее будет отправлен в некоторую центральную систему мониторинга.
Подобные системы мониторинга называются IDS (Intrusion Detection System).
В периметре организации и обычно классифицируют следующим образом :
- NIDS (Network)
Сниффер, который анализирует поступающие данные и мониторит сеть с целью найти потенциальную вредоносную активность.
Обычно подобные снифферы получают информацию напрямую со свитча в сегменте сети.
- HIDS (Host-based)
Обычно некоторый антивирус, который установлен на компьютере работника. Однако не стоит сравнивать его с обычными антивирусными решениями, enterprise-версии обычно куда умнее своих собратьев, имеют строгие политики безопасности, а также еще кучу "silent" ивентов, которые увидят только люди в SOC.
- IDS monitors
Мониторинг траффика на предмет наличия сигнатур, системных логов, пользовательской активности.
Вот здесь и вступает в игру Security Operations Center (SOC).
Как работает SOC
И так для начала давайте разберемся с тем, что из себя представляет типичная команда мечты любой состоявшейся организации.
Хотя сами команды формируются по разному в зависимости от целей и бюджета (а зачастую только от количества $$$), но в целом команда выглядит так:
- Менеджер смены - это тот нуб, который ждет ГГ и отвечает на вопрос: "Доложите текущую обстановку!". Вообщем человек, который информирует прибывших на смену аналитиков, какие знатные проебы они пропуситили и что опять все идет одним местом. (Angela Moss из сериала Mr. Robot)
- Аналитик [1 линия] - чувак, который работает в сменном режиме 24/7, мониторит систему SIEM (Secirity Incident Event Managment) ежесекундно. Как только в сети происходит какая-то неведомая х*йня, то тот сразу же создает тикет и отправляет его аналитику 2-ой линии.
- Аналитик [2 линия] - перец, который доступен 24/7, не обязательно offline. Он проводит первичный анализ, определяет false-positive ли это. Если х*йня все же случилось, то отправляет этот тикет дальше аналитику 3-ей линии.
- Аналитик [3 линии] - полубог, который технически доступен 24/7. Если тикет дошел до этого аналитика, то значит что происходит полная задница, х*йня уже стучит по лицу и кто-то уже воляется в крови и кричит: "Мама, спаси, я не хочу умирать".
Понимание того, как функционирует SOC необходимо для проведение атаки на крупную организацию, ибо этих ребят нам необходимо переиграть.
Одной из самых крупных проблем большинства текущих SOC это время реагирования на инцидент на первой линии.
Время реагирования SOC
Время реагирования - это время, которое потребуется аналитику 1-ой линии на обнаружение ивента, что является величиной переменной.
В последний час до конца смены аналитиков (ранним утром) обычно является овощным периодом для работников, так что в это время время реагирования самое низкое. Во время проведения атаки попытайтесь узнать время работы SOC вашей цели, зачастую это время между 02.00 - 03.00 или 6.00 - 7.00.
Время реагирования также может быть увеличено за счет флуда, создания ложных ивентов. Для этого лучше всего выбрать другую часть инфраструктуры цели (публичный веб-сервис) и провести несколько грязных атак (порт скан, брут форс, сканнер уязвимостей, ддос) для генерирования кучи траффика. Цель - создание как можно больше тикетов между вашей атакой.
Evasion-техники IDS
Как и с AV, так и с IDS можно все переиграть. Что же для этого сделать?
Большенсво популярных вендоров имеют триал версии подобных систем, которые вы можете установить на виртуальные машины. Вы не сможете смоделировать таким образом сеть, но сможете пронаблюдать поведения IDS.
Для примеры можно взять AlienVault, одного из самых крупных вендоров в данной области. Они предоставляют полный комплекс решений от NIDS и HIDS до SIEM. Многие SOC базируются на их наборе инструментов и могут полать данные почти отовсюду. Скачайте их USM и поиграйте с ней, посмотрите на их интеграцию с открытой площадкой по обмену IOC - OTX (Open Threat eXchange).
Одна из главных проблем, где валятся большинство вредоносного ПО - это связь с C2. Соединение должно выглядеть максимально легитимно. Как вариант можно использовать для отправки данных SSH туннелей, что для подобных систем выглядит нормально.
Security Event
В финальной части давайте поговорим о том, как вообще ивенты выбираются для отправки в SIEM.
В подобных системах безопасности наш электрический бро принимает решение о том, стоит ли этот ивент репортить и как его пометить полагаясь на чистую математику, ибо пока настоящего ИИ еще не придумали.
Обычно по подобной формуле:
EventRisk = (AssetValue x EventReliability x EventPriority) / 25
AssetValue - значение от 0 (херня) до 5 (очень ценный), ценность узла
EventReliability - значение от 0 до 10, надежность ивента
EventPriority - значение от 0 до 5, приоритет
В случае атаки наилучшим выбором для проникновения будут те узлы, которые имеют самый низкий Asset. Под данные девайсы попадают разные принтеры, факсы и другие девайсы на которые обычно обращаешь внимание в последнюю очередь. Так же некоторые девайсы могут иметь Asset = 5, однако в силу правил их эксплуатации EventReliability на данном устройстве скорее всего будет низким.
Во время подобных атак вам нужно четко представлять какие действия на каких устройствах будут являться подозрительными.
Заключение
