Спасибо за вопрос! Мы зададим его нашей команде по расследованиям, но подозреваем, что тут могут, например, быть произвольные пароли, передаваемые вместе с архивом, иными средствами, на C2-сервер. А ответ на вопрос о том, какие типы данных собираются, не столь важен, как тот, чьи данные были похищены. То есть, подбор пароля лишь для одного из архивов не решит задачу поиска всех подвергнувшихся атаке целей.
Да, согласны, но поскольку AD является ядром инфраструктуры, то зачастую даже у организаций, уделяющих внимание поддержанию защищённого состояния AD,
для интеграции и совместимости систем в полях расширенной схемы может храниться чувствительная информация или что-то, что позволяет косвенно к ней приблизиться. А пример из статьи это, возможно, крайность, но и такое в нашей практике встречалось.
Речь в статье идёт про теорию концепции. На практике чем выше безопасность, тем ниже удобство, поэтому каждый сам находит адекватный баланс, который его устраивает. Другими словами, можно аутентифицировать / авторизовать при первом обращении к ресурсу и повторно запрашивать пароль, только если пользователь бездействовал определённый период времени (а-ля блокировка компьютера по таймауту бездействия).
2008R2 действительно шёл с PS version 2, только его поддержка заканчивается уже в январе 2020 года и в связи с этим в корпоративном сегменте использоваться, скорее всего, больше не будет.
NIST — NIST-ом, но есть и иные стандарты, так же носящие, в целом, рекомендательный характер, и в них такой нормы пока не описано, за исключением самых современных.
Да и обязательны к исполнению они лишь там, где такие стандарты взяты за основу политики безопасности, или есть соответствующие требования аудиторов.
Многие (подавляющее большинство) компании до сих пор имеют критикуемую Вами норму в своих политиках безопасности. Именно поэтому, им необходимо иметь такой индикатор «перед глазами».
Чтобы немного контраргументировать, в том же документе NIST есть следующее обязующее условие:
“force a change if there is evidence of compromise of the password.”
Предположим (вполне обоснованно), что у средней компании нет средств эффективного обнаружения данного события. Следует ли именно данной компании отказываться от практики периодической смены пароля(хоть она и неудобна)?
Тот же вопрос, по сути, можно усмотреть и во фразах представителя Microsoft в приводимой Вами же статье:
«If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration?»
«At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.»
Ну и просто чтобы не устраивать холивар по несущественному, на наш взгляд, поводу:
неплохая подборка выдержек из различных актуальных стандартов, и вывод по требуемой сложности и длине паролей: www.diwebsity.com/2019/08/10/password-security-standards, с которым на текущий момент мы согласны, но сложности паролю следовало бы добавлять и региональными символами из Unicode, и, вероятно, псевдографикой, что также предусмотрено в большей части самых новых версий стандартов.
SRP, ПО класса Application Control, и иные инструменты запрета запуска стороннего ПО, а также политики по запрету запуска ПО не из строго определённых каталогов – это эффективные меры, которые входят в пункт 3. под именем «защитные системы конечных устройств». Здесь «и предотвращать заражения» — можно (и следует) читать как «предотвращать заражения, в том числе независимо от того, известно ли уже конкретное вредоносное ПО».
Строго говоря, дискуссия о защите непосредственно конечных точек несколько выходит за рамки данной статьи, а наша компания занимается скорее детектированием угроз и помогает при устранении последствий, а также помогает предотвратить утечки данных, при своевременной реакции на «тревожные звонки», нежели предотвращением заражений как таковых :)
Речь не идёт о национальности. Скорее о стране, где писавший код находился в момент скачивания WinRAR, или какая локаль OS была использована в этот же самый момент.
А что касается второго утверждения – видимо, это то самое «Ы» в названии операции. :)
Конкретно в данном примере отчет с Virus total был неудовлетворительный на дату первоначальной статьи, что собственно и побудило ее написать. В общем же случае этот пример показывает, что зачастую антивирусы не могут обнаружить в почтовом вложении вредонос, который использует запутанные техники обфускации и при этом для выполнения загрузки и укрепления в системе применяются привычные всем администраторам инструменты, начиная от встроенных утилит в составе ОС и заканчивая скриптами на JS и PS. И поэтому не стоит опираться только на защиту периметра, а предположив, что злоумышленники уже внутри периметра организации затруднить их присутствие и постараться обнаружить их с использованием поведенческих моделей и средств оперативного обнаружения угроз.
Локальная учетная запись пользователя является доменной записью и обладает правами админа на исследуемой системе — тут все как в классике. По сути статья является ещё одним предупреждением не давать прав админа, в том числе, и доменным учёткам.
Как было указано выше в статье, предполагается, что доступ для атаки на Hub-Sharepoint уже был получен в рамках отдельных атак: это могли быть фишинг, эксплоиты, соц.инженерия и т.п. В этой статье мы опускаем подробности получения рут-доступа к этому серверу, это будет тема отдельного цикла статей по неуловимой малвари. Поэтому в этот раз это было опущено намеренно, очевидно, здесь просто возникла путаница.
Cергей, вы правильно заметили, что это уже не новость, и мы писали об этой проблеме в нашем корпоративном блоге пару месяцев назад. Но поскольку компании все еще сталкиваются с повышением привилегий в Exchange, перевели заметку на русский. А вас мы приглашаем в наш корпоративный блог за самыми свежими обзорами!
Он проникает через фишинговое письмо.
для интеграции и совместимости систем в полях расширенной схемы может храниться чувствительная информация или что-то, что позволяет косвенно к ней приблизиться. А пример из статьи это, возможно, крайность, но и такое в нашей практике встречалось.
Да и обязательны к исполнению они лишь там, где такие стандарты взяты за основу политики безопасности, или есть соответствующие требования аудиторов.
Многие (подавляющее большинство) компании до сих пор имеют критикуемую Вами норму в своих политиках безопасности. Именно поэтому, им необходимо иметь такой индикатор «перед глазами».
Чтобы немного контраргументировать, в том же документе NIST есть следующее обязующее условие:
“force a change if there is evidence of compromise of the password.”
Предположим (вполне обоснованно), что у средней компании нет средств эффективного обнаружения данного события. Следует ли именно данной компании отказываться от практики периодической смены пароля(хоть она и неудобна)?
Тот же вопрос, по сути, можно усмотреть и во фразах представителя Microsoft в приводимой Вами же статье:
«If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration?»
«At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.»
Ну и просто чтобы не устраивать холивар по несущественному, на наш взгляд, поводу:
неплохая подборка выдержек из различных актуальных стандартов, и вывод по требуемой сложности и длине паролей: www.diwebsity.com/2019/08/10/password-security-standards, с которым на текущий момент мы согласны, но сложности паролю следовало бы добавлять и региональными символами из Unicode, и, вероятно, псевдографикой, что также предусмотрено в большей части самых новых версий стандартов.
Строго говоря, дискуссия о защите непосредственно конечных точек несколько выходит за рамки данной статьи, а наша компания занимается скорее детектированием угроз и помогает при устранении последствий, а также помогает предотвратить утечки данных, при своевременной реакции на «тревожные звонки», нежели предотвращением заражений как таковых :)
А что касается второго утверждения – видимо, это то самое «Ы» в названии операции. :)