"Злоумышленник с удаленным доступом может использовать файл profile.ps1, выполняемый в сессии Администратора PowerShell".
Сессию запускает пользователь с правами локального администратора, малварь же может получить доступ и что-то поменять в profile.ps1 только, если ослабить Execution Policy, в частности, если будет разрешено выполнение скриптов - что отмечено ниже в тексте:
"Однако пользователи часто изменяют политики CurrentUser и LocalMachine, чтобы разрешить выполнение скриптов." И далее, по тексту..
То есть, непременным условием эксплуатации является ослабление Execution Policy, а вот уже последующее изменение profile.ps1, следует предотвращать используя подписанные файлы, ограничение прав доступа и флаг "-NoProfile" как отмечается в разделе "Обнаружение и Устранение"».
Забыли ирониямодофф, поэтому сложно понять, что принимать всерьёз ;)
По названию - в данной статье описываются некоторые примеры работы со стеком. Cогласны, что имеет место не совсем корректный перевод. Наш инженер, помимо нескольких замечаний по тексту, предложил вариант "Разбор происходящего в Stack Memory", что может тоже оказаться не самым удачным переводом. :)
По второму пункту - в целом, описанные в примере из статьи операции производятся с одной целью "запутать следствие". Мало "быстро взять чужое и уйти", в большинстве случаев надо сделать так, чтобы было непонятно, как именно это было сделано (ведь сам метод уже может вывести на исполнителя - вспомним "затопление" домов грабителями из "Один дома"), ну или чтобы на реверс-инжиниринг было потрачено время и ресурсы, которые можно получить только за приличную сумму денег, что может как задержать, так и вовсе остановить расследование.
Вы придираетесь к отдельно взятому слову. В статье мы пишем о том, что "Мы не рекомендуем использовать AutoRuns в качестве единственной формы обнаружения и удаления вредоносного программного обеспечения", также демонстрируем, как этот инструмент может помочь обнаружить разные способы, с помощью которых вредоносы пытаются продолжить свою работу на устройстве.
А чтобы узнать, как мы останавливаем кибератаки, добро пожаловать на нашу демонстрацию кибератак!
Резервные копии – это больше про устранение последствий, нежели про предотвращение. Но напоминать об этом следует, что мы и сделали в самой статье. Однако, любое создание новой резервной копии сопряжено с риском попадания в неё и «спящего агента». Поэтому мест хранения копий в оффлайне может быть больше одного, с цикличной их сменой с каждым последующим бэкапом.
Использование встроенных средств ОС, вместо увеличения разнородной вредоносной нагрузки, “приносимой с собой”, значительно уменьшает риски обнаружения по уже известным сигнатурам компонентов антивирусами, поэтому большая часть разработчиков вредоносного ПО стремится использовать эту тактику.
Использовать триггер на выключение функционала теневого копирования в качестве одного из основных индикаторов компрометации (IoC) – это базовая идея для мониторинга конечных станций и серверов (и контролировать изменения признака, в этом случае, достаточно просто). Но блокировать его выключение совсем, не используя функционал решений по контролю и предотвращению изменений (Change Control), насколько нам известно, невозможно. При этом, решения такого класса – редкие гости в корпоративной среде, чаще их применяют в POS и банкоматах. Раньше были средства, встроенные в антивирусное ПО определённых производителей, которые позволяли выполнять функции оповещения и предотвращения по определённым IoC (изменения конкретных веток реестра, создания файлов в определённых областях и т.д.), но судьба этого функционала на данный момент нам неизвестна. Вероятно, в связи с малой его востребованностью (а жаль), он мог быть урезан в отношении доступа к настройкам и использоваться теперь только для «автоматического» предотвращения распространения уже известных эпидемий по характерным для них признакам последствий активности.
В Red team всегда идёт работа так же, как это делал бы некий хакер или инсайдер. То есть, «сценариев», если вообще использовать это слово, два:
1) внешний атакующий, который должен преодолеть периметральную защиту, чаще всего с использованием социального инжиниринга, но также есть масса иных вариантов, как то:
0-day, некорректная конфигурация средств межсетевого экранирования и/или маршрутизаторов, иной человеческий фактор, и т.д.
2) инсайдер — и ему может потребоваться повышение привилегий, но часто — это «кража у себя же», т.е. в задачи Blue team входит эффективное выявление нестандартного поведения таких пользователей, особенно с критичными данными, до того, как сработают средства обнаружения утечки данных, если они вообще сработают.
По второму вопросу тоже нет такого ответа: «делай так — вот большая красная кнопка Сделать Хорошо» — всё зависит от целей, как это и было указано в предыдущем ответе. На наш взгляд, если цель — повысить квалификацию собственных команд ИБ, СБ и т.д., то стоит обратить пристальное вниманиe на вариант с минимальным количеством внешних специалистов (возможно, с установкой рекомендованных ими средств безопасности), а также если не хочется наступить на грабли «мы пропустили первую же атаку, и увидели только один из векторов, ничему не научились». Ведь в этом случае Red team достигнет «флага», и ей придётся заплатить, а фактическая цель не будет выполнена. В иных случаях выбор будет зависеть от множества факторов, и надо рассматривать их в отдельности.
На наш взгляд, задачей Red Team является демонстрация того, что даже если проведённый пентест конкретной системы не выявил уязвимости непосредственно в ней, и при этом только в ней (якобы) может храниться определённая информация – все равно можно получить искомые данные. Причём, неважен способ, которым эти данные будут получены: взлом сторонней системы или плагина, которые не были затронуты пентестом; нахождение той же информации в иных системах – например, в выгрузках из БД, хранящихся на файловых серверах; или, например – получение «легитимного» доступа к системе, используя аутентификацию и/или авторизацию в ней от имени допущенного к обработке этих данных лица.
Касаемо же тренировки навыков Blue Team – только в случае, если в роли большинства в Blue Team выступают все штатные сотрудники подразделений безопасности, выполняющие в день «учений» роль именно специалистов Blue Team, «разбавленные» небольшим количеством квалифицированных нанятых инженеров и аналитиков, помогающих в принятии решений в моменты обнаружения действий атакующей команды. Но это могут быть и нанятые команды, умеющие работать с внедрёнными системами обеспечения ИБ, работающие в связке с небольшим количеством штатных специалистов, которые смогут оперативно давать пояснения в отношении «ложных срабатываний». Выбор того или иного количественно-качественного состава зависит от конкретных целей и запланированной поверхности атаки.
Скрытость в том, на основании чего был получен верный вариант. То есть, на какой стадии — на этапе получения DCC.
Подборы же пароля «наживую» по описанной в конце статьи схеме чреваты потенциальными локаутами, вдобавок — совершенно не с того компьютера, которым на постоянной основе пользуется «цель» атаки. Что позволит, в свою очередь, как минимум – оперативно сменить пароль (что сведёт на нет усилия по его подбору и всю социальную инженерию), а то и банально по камерам выследить незадачливого злоумышленника, зная физическое местоположение компьютера, с которого велась, возможно, вредоносная активность.
Технически можно отслеживать и появление, пусть и временное, служб на клиентских машинах, вне «окон обслуживания», чтобы отследить связанную с этим сетевую активность по SMB с другого клиентского устройства.
Следует учитывать, однако, что потенциально злоумышленник может использовать для этой цели и сервер, доступ к которому он имеет вполне легитимно, что затруднит распутывание цепочки следов, ведущей к злоумышленнику. Или сделает этот процесс невозможным, при отсутствии должного ведения журналов разных систем или недостаточной глубине их хранения.
Всё верно. Цель статьи – показать на примере доступных инструментов, как происходят типичные атаки, чтобы их лучше понимать. Этим можно пользоваться на отдельном сервере для изучения методик работ хакеров и концепций функционирования решений ИБ. Ни о какой защите корпоративного уровня речи, конечно же, не идёт. И об этом мы ещё поговорим в дальнейших частях.
Как вы верно отметили, мы написали о том, что внешний файлообмен (так, как понимает его Microsoft) заблокировать можно. Более детально об этом вы можете узнать, посмотрев указанный в начале статьи обучающий курс.
Если же отвечать на ваш вопрос так, как он задан:
«есть ли все-таки способ разрешить Teams для части пользователей только с определенных «айпишников»? Говоря по простому только когда они работают внутри корпоративного периметра?»
— то ответ будет скорее нет, чем да, если лица, которым требуется ограничить доступ, будут использовать для работы с O365 из периметра корпоративной сети ноутбуки и/или личные устройства.
В ином случае, есть вариант настроить MFA таким образом, чтобы, используя сертификаты, или ещё какие-либо критерии, ограничивать доступ в облако, связывая условие с конкретными устройствами. Т.е. пользователи, которым таковой доступ извне периметра будет разрешён, будут, например, иметь на носимых устройствах, или домашних компьютерах, соответствующие сертификаты. Разумеется, в таком примере, сертификаты придётся установить и на все рабочие станции/терминальные серверы внутри периметра тоже.
Эту меру можно совместить с указанием «белого списка» IP-адресов для доступа, если планируется также запретить и доступ с динамического диапазона (когда человек находится в дороге или просто решил использовать мобильную точку доступа Wi-Fi с не разрешённым к использованию Вами IP-адресом).
Вероятно, имеются какие-либо продвинутые CASB, которые могут регулировать политику доступа так же, как указано в ответе на комментарий выше (без сертификатов или иных критериев, только по IP-адресам), но разделяя на группы пользователей, для которых применяются строгие и менее строгие ограничения по диапазонам адресов, с которых возможен доступ. Нам о таких решениях неизвестно.
Да, отключить возможность предоставления доступа к файлам пользователями полностью нельзя. Но можно выставить, без применения сторонних средств, ограничения на предоставление доступа внешним пользователям, а также указать диапазон IP-адресов, с которого возможно подключение к O365 для вашего теннанта.
Спасибо, что поделились своим опытом. К сожалению, не можем проконсультировать вас по существу вопроса, поскольку это не в нашей компетенции, и лучше обратиться непосредственно в техподдержку MS.
Спасибо за пояснение! Как было отмечено в статье:
"Злоумышленник с удаленным доступом может использовать файл profile.ps1, выполняемый в сессии Администратора PowerShell".
Сессию запускает пользователь с правами локального администратора, малварь же может получить доступ и что-то поменять в profile.ps1 только, если ослабить Execution Policy, в частности, если будет разрешено выполнение скриптов - что отмечено ниже в тексте:
"Однако пользователи часто изменяют политики CurrentUser и LocalMachine, чтобы разрешить выполнение скриптов." И далее, по тексту..
То есть, непременным условием эксплуатации является ослабление Execution Policy, а вот уже последующее изменение profile.ps1, следует предотвращать используя подписанные файлы, ограничение прав доступа и флаг "-NoProfile" как отмечается в разделе "Обнаружение и Устранение"».
Что конкретно в нашем переводе вы считаете плохим? Давайте конкретику, иначе ваш комментарий не несёт в себе никакого смысла и пользы.
Забыли ирониямодофф, поэтому сложно понять, что принимать всерьёз ;)
По названию - в данной статье описываются некоторые примеры работы со стеком. Cогласны, что имеет место не совсем корректный перевод. Наш инженер, помимо нескольких замечаний по тексту, предложил вариант "Разбор происходящего в Stack Memory", что может тоже оказаться не самым удачным переводом. :)
По второму пункту - в целом, описанные в примере из статьи операции производятся с одной целью "запутать следствие". Мало "быстро взять чужое и уйти", в большинстве случаев надо сделать так, чтобы было непонятно, как именно это было сделано (ведь сам метод уже может вывести на исполнителя - вспомним "затопление" домов грабителями из "Один дома"), ну или чтобы на реверс-инжиниринг было потрачено время и ресурсы, которые можно получить только за приличную сумму денег, что может как задержать, так и вовсе остановить расследование.
Вы придираетесь к отдельно взятому слову. В статье мы пишем о том, что "Мы не рекомендуем использовать AutoRuns в качестве единственной формы обнаружения и удаления вредоносного программного обеспечения", также демонстрируем, как этот инструмент может помочь обнаружить разные способы, с помощью которых вредоносы пытаются продолжить свою работу на устройстве.
А чтобы узнать, как мы останавливаем кибератаки, добро пожаловать на нашу демонстрацию кибератак!
Использование встроенных средств ОС, вместо увеличения разнородной вредоносной нагрузки, “приносимой с собой”, значительно уменьшает риски обнаружения по уже известным сигнатурам компонентов антивирусами, поэтому большая часть разработчиков вредоносного ПО стремится использовать эту тактику.
Использовать триггер на выключение функционала теневого копирования в качестве одного из основных индикаторов компрометации (IoC) – это базовая идея для мониторинга конечных станций и серверов (и контролировать изменения признака, в этом случае, достаточно просто). Но блокировать его выключение совсем, не используя функционал решений по контролю и предотвращению изменений (Change Control), насколько нам известно, невозможно. При этом, решения такого класса – редкие гости в корпоративной среде, чаще их применяют в POS и банкоматах. Раньше были средства, встроенные в антивирусное ПО определённых производителей, которые позволяли выполнять функции оповещения и предотвращения по определённым IoC (изменения конкретных веток реестра, создания файлов в определённых областях и т.д.), но судьба этого функционала на данный момент нам неизвестна. Вероятно, в связи с малой его востребованностью (а жаль), он мог быть урезан в отношении доступа к настройкам и использоваться теперь только для «автоматического» предотвращения распространения уже известных эпидемий по характерным для них признакам последствий активности.
1) внешний атакующий, который должен преодолеть периметральную защиту, чаще всего с использованием социального инжиниринга, но также есть масса иных вариантов, как то:
0-day, некорректная конфигурация средств межсетевого экранирования и/или маршрутизаторов, иной человеческий фактор, и т.д.
2) инсайдер — и ему может потребоваться повышение привилегий, но часто — это «кража у себя же», т.е. в задачи Blue team входит эффективное выявление нестандартного поведения таких пользователей, особенно с критичными данными, до того, как сработают средства обнаружения утечки данных, если они вообще сработают.
По второму вопросу тоже нет такого ответа: «делай так — вот большая красная кнопка Сделать Хорошо» — всё зависит от целей, как это и было указано в предыдущем ответе. На наш взгляд, если цель — повысить квалификацию собственных команд ИБ, СБ и т.д., то стоит обратить пристальное вниманиe на вариант с минимальным количеством внешних специалистов (возможно, с установкой рекомендованных ими средств безопасности), а также если не хочется наступить на грабли «мы пропустили первую же атаку, и увидели только один из векторов, ничему не научились». Ведь в этом случае Red team достигнет «флага», и ей придётся заплатить, а фактическая цель не будет выполнена. В иных случаях выбор будет зависеть от множества факторов, и надо рассматривать их в отдельности.
Касаемо же тренировки навыков Blue Team – только в случае, если в роли большинства в Blue Team выступают все штатные сотрудники подразделений безопасности, выполняющие в день «учений» роль именно специалистов Blue Team, «разбавленные» небольшим количеством квалифицированных нанятых инженеров и аналитиков, помогающих в принятии решений в моменты обнаружения действий атакующей команды. Но это могут быть и нанятые команды, умеющие работать с внедрёнными системами обеспечения ИБ, работающие в связке с небольшим количеством штатных специалистов, которые смогут оперативно давать пояснения в отношении «ложных срабатываний». Выбор того или иного количественно-качественного состава зависит от конкретных целей и запланированной поверхности атаки.
Подборы же пароля «наживую» по описанной в конце статьи схеме чреваты потенциальными локаутами, вдобавок — совершенно не с того компьютера, которым на постоянной основе пользуется «цель» атаки. Что позволит, в свою очередь, как минимум – оперативно сменить пароль (что сведёт на нет усилия по его подбору и всю социальную инженерию), а то и банально по камерам выследить незадачливого злоумышленника, зная физическое местоположение компьютера, с которого велась, возможно, вредоносная активность.
Технически можно отслеживать и появление, пусть и временное, служб на клиентских машинах, вне «окон обслуживания», чтобы отследить связанную с этим сетевую активность по SMB с другого клиентского устройства.
Следует учитывать, однако, что потенциально злоумышленник может использовать для этой цели и сервер, доступ к которому он имеет вполне легитимно, что затруднит распутывание цепочки следов, ведущей к злоумышленнику. Или сделает этот процесс невозможным, при отсутствии должного ведения журналов разных систем или недостаточной глубине их хранения.
Если же отвечать на ваш вопрос так, как он задан:
«есть ли все-таки способ разрешить Teams для части пользователей только с определенных «айпишников»? Говоря по простому только когда они работают внутри корпоративного периметра?»
— то ответ будет скорее нет, чем да, если лица, которым требуется ограничить доступ, будут использовать для работы с O365 из периметра корпоративной сети ноутбуки и/или личные устройства.
В ином случае, есть вариант настроить MFA таким образом, чтобы, используя сертификаты, или ещё какие-либо критерии, ограничивать доступ в облако, связывая условие с конкретными устройствами. Т.е. пользователи, которым таковой доступ извне периметра будет разрешён, будут, например, иметь на носимых устройствах, или домашних компьютерах, соответствующие сертификаты. Разумеется, в таком примере, сертификаты придётся установить и на все рабочие станции/терминальные серверы внутри периметра тоже.
Эту меру можно совместить с указанием «белого списка» IP-адресов для доступа, если планируется также запретить и доступ с динамического диапазона (когда человек находится в дороге или просто решил использовать мобильную точку доступа Wi-Fi с не разрешённым к использованию Вами IP-адресом).
Вероятно, имеются какие-либо продвинутые CASB, которые могут регулировать политику доступа так же, как указано в ответе на комментарий выше (без сертификатов или иных критериев, только по IP-адресам), но разделяя на группы пользователей, для которых применяются строгие и менее строгие ограничения по диапазонам адресов, с которых возможен доступ. Нам о таких решениях неизвестно.