Information security

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

29.07.2020 08:08:02 |

Автор: admin

Не так давно, Splunk добавил ещё одну модель лицензирования лицензирование на основе инфраструктуры (теперь их три). Они считают количество ядер CPU под серверами со Splunk. Очень напоминает лицензирование Elastic Stack, там считают количество нод Elasticsearch. SIEM-системы традиционно недешёвое удовольствие и обычно стоит выбор между заплатить много и очень много. Но, если применить смекалочку, можно собрать подобную конструкцию.

Выглядит крипово, но иногда такая архитектура работает в проде. Сложность убивает безопасность, а, в общем случае, убивает всё. На самом деле, для подобных кейсов (я про снижение стоимости владения) существует целый класс систем Central Log Management (CLM). Об этом пишет Gartner, считая их недооценёнными. Вот их рекомендации:

Используйте возможности и инструментальные средства CLM, если существуют ограничения по бюджету и персоналу, требования к мониторингу безопасности и конкретные требования к вариантам использования.
Внедряйте CLM для расширения функций сбора и анализа журналов, когда SIEM-решение оказалось слишком дорогим или сложным.
Инвестируйте в инструменты CLM с эффективным хранилищем, быстрым поиском и гибкой визуализацией для улучшения расследования/анализа инцидентов безопасности и поддержкой поиска угроз.
Убедитесь, что применимые факторы и соображения учтены, прежде чем внедрять решение CLM.

В этой статье поговорим о различиях подходов к лицензированию, разберёмся с CLM и расскажем о конкретной системе такого класса Quest InTrust. Подробности под катом.

В начале этой статьи я рассказал о новом подходе к лицензированию Splunk. Виды лицензирования можно сравнить с тарифами на прокат автомобилей. Давайте представим, что модель по количеству CPU это экономичный автомобиль с неограниченным пробегом и бензином. Можно ехать куда угодно без ограничений по расстоянию, но нельзя ехать очень быстро и, соответственно, проезжать много километров в день. Лицензирование по объёму данных похоже на спортивный автомобиль с моделью оплаты по ежедневному километражу. Можно лихо наваливать и на большие расстояния, но за превышение дневного лимита километража придется заплатить больше.

Чтобы получить выгоду от использования лицензирования по нагрузке, нужно иметь наименьшее возможное соотношение ядер CPU к количеству загружаемых ГБ данных. На практике это означает что-то типа:

Наименьшее возможное количество запросов к загруженным данным.
Наименьшее количество возможных пользователей решения.
Как можно более простые и нормализованные данные (чтобы не нужно было тратить циклы CPU на последующую обработку и анализ данных).

Самая проблемная вещь здесь нормализованные данные. Если вы хотите, чтобы SIEM была агрегатором всех журналов в организации, это требует огромных усилий при разборе и постобработке. Не забывайте, что нужно также продумать архитектуру, которая не развалится от нагрузки, т.е. потребуются дополнительные серверы и, следовательно, дополнительные процессоры.

Лицензирование по объему данных основывается на количестве данных, которые отправляются в пасть SIEM. Дополнительные источники данных наказуемы рублём (или другой валютой) и это заставляет задуматься о том, что не очень-то и хотелось собирать. Чтобы обхитрить такую модель лицензирования, можно обкусать данные до их инжекции в SIEM-систему. Один из примеров такой нормализации перед инжекцией Elastic Stack и некоторые другие коммерческие SIEM.

В итоге имеем, что лицензирование по инфре эффективно, когда нужно собирать только определённые данные с минимальной предобработкой, а лицензирование по объёму не позволит собирать вообще всё. Поиск промежуточного решения наталкивает на следующие критерии:

Упрощение агрегации и нормализации данных.
Фильтрация шумовых и наименее важных данных.
Предоставление возможностей анализа.
Отправка отфильтрованных и нормализованных данных в SIEM

В результате целевым SIEM-системам не нужно будет тратить дополнительную мощь CPU на обработку и можно извлечь выгоду из выявления только самых важных событий без снижения видимости происходящего.

В идеале, такое промежуточное решение должно также обеспечивать возможности обнаружения и реагирования в реальном времени, которые можно использовать для снижения влияния потенциально опасных действий и агрегации всего потока событий в удобный и простой квант данных в сторону SIEM. Ну, а дальше SIEM можно использовать для создания дополнительных агрегаций, корреляции и процессов оповещения.

То самое загадочное промежуточное решение не что иное как CLM, о котором я упоминал в начале статьи. Вот таким его видит Gartner:

Теперь можно попробовать разобраться насколько InTrust соответствует рекомендациям Gartner:

Эффективное хранилище для тех объёмов и типов данных, которые нужно хранить.
Высокая скорость поиска.
Возможности визуализации не то, что требуется для базового CLM, но поиск угроз это как BI-система для обеспечения безопасности и анализа данных.
Обогащение данных для дополнения необработанных данных полезными контекстными данными (вроде геолокации и других).

Quest InTrust использует собственную систему хранения со сжатием данных до 40:1 и высокой скоростью дедупликации, что снижает накладные расходны на хранением для систем CLM и SIEM.

Консоль IT Security Search c google-like поиском

Специализированный модуль с веб-интерфейсом IT Security Search (ITSS) может подключаться к данным о событиях в репозитории InTrust и предоставляет простой интерфейс для поиска угроз. Интерфейс упрощен до такой степени, что работает как Google для данных журнала событий. ITSS использует временные шкалы для результатов запроса, может объединять и группировать поля событий и эффективно помогает при поиске угроз.

InTrust обогащает события Windows идентификаторами безопасности, именами файлов и идентификаторами входа в систему безопасности. InTrust также нормализует события к простой схеме W6 (Who, What, Where, When, Whom и Where From кто, что, где, когда, кого и откуда), чтобы данные из разных источников (собственные события Windows, логи Linux или syslog) можно было видеть в едином формате и на единой консоли поиска.

InTrust поддерживает функции оповещения и обнаружения в реальном времени, а также ответные действия, которые можно использовать в качестве EDR-подобной системы, чтобы минимизировать ущерб, вызванный подозрительной активностью. Встроенные правила безопасности обнаруживают, но не ограничиваются обнаружением следующих угроз:

Password-spraying.
Kerberoasting.
Подозрительная PowerShell-активность, например, исполнение Mimikatz.
Подозрительны процессы, например, LokerGoga ransomware.
Шифрование с использованием логов CA4FS.
Входы с привелигерированным аккаунтом на рабочих станциях.
Атаки с подбором пароля.
Подозрительное использование локальных групп м пользователей.

Теперь покажу несколько скриншотов самого InTrust, чтобы могло сложиться впечатление о его возможностях.

Преодпределённые фильтры для поиска потенциальных уязвимостей

Пример набора фильтров для сбора сырых данных

Пример использования регулярных выражений для создания реакции на событие

Пример с правилом поиска уязвимостей PowerShell

Встроенная база знаний с описанием уязвимостей

InTrust это мощный инструмент, который можно использовать как самостоятельное решение так и в составе SIEM-системы, как я описал выше. Наверное, основное преимущество этого решения, что его можно начинать использовать сразу после установки, т.к. InTrust имеет большую библиотеку правил обнаружения угроз и реакций на них (например, блокировки пользователя).

В статье я не рассказал о коробочных интеграциях. Но сразу после установки можно настроить отправку событий в Splunk, IBM QRadar, Microfocus Arcsight или через вебхук в любую другую систему. Ниже пример интерфейса Kibana с событиями из InTrust. С Elastic Stack интеграция уже тоже есть и, если вы используете бесплатную версию Elastic, InTrust может использоваться как инструмент для выявления угроз, выполнения упреждающих оповещений и отправке уведомлений.

Надеюсь, статья дала минимальное представление об этом продукте. Готовы отдать InTrust вам на тест или провести пилотный проект. Заявку можно оставить в форме обратной связи на нашем сайте.

Почитайте другие наши статьи по теме информационной безопасности:

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

Отслеживание жизненного цикла пользователей без плоскогубцев и изоленты

А кто это сделал? Автоматизируем аудит информационной безопасности

Подробнее..

Категории: Информационная безопасность , It-инфраструктура , Системное администрирование , Security , Софт , Блог компании gals software , Edr , Quest , Intrust , Gals software , Information security , Siem , Clm , Log management , Gartner

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

30.07.2020 20:10:43 |

Автор: admin

Всем, кто пытался запустить виртуальную машину в облаке, хорошо известно, что стандартный порт RDP, если его оставить открытым, будет почти сразу атакован волнами попыток перебора пароля с различных IP-адресов по всему миру.

В этой статье я покажу как в InTrust можно настроить автоматическую реакцию на перебор пароля в виде добавления нового правила на брандмауэр. InTrust это CLM-платформа для сбора, анализа и хранения неструктурированных данных, в которой есть уже сотни предустановленных реакций на различные типы атак.

В Quest InTrust можно настроить ответные действия при срабатывании правила. С агента-сборщика логов InTrust получает сообщение о неудачной попытке авторизации на рабочей станции или сервере. Чтобы настроить добавление новых IP-адресов в брандмауэр, необходимо скопировать существующее специализированное правило обнаружения множественных неудачных авторизаций и открыть его копию для редактирования:

События в журналах Windows используют так называемые InsertionString. Посмотрите соответствия для события с кодом 4625 (это неудачный логон в систему) и увидите, что интересующие нас поля хранятся в InsertionString14 (Workstation Name) и InsertionString20 (Source Network Address), При атаке из интернета, поле с Workstation Name будет, скорее всего, пустым, поэтому важно на это место подставить значение из Source Network Address.

Примерно так выглядит текст события 4625

An account failed to log on.Subject:Security ID:S-1-5-21-1135140816-2109348461-2107143693-500Account Name:ALebovskyAccount Domain:LOGISTICSLogon ID:0x2a88aLogon Type:2Account For Which Logon Failed:Security ID:S-1-0-0Account Name:PaulAccount Domain:LOGISTICSFailure Information:Failure Reason:Account locked out.Status:0xc0000234Sub Status:0x0Process Information:Caller Process ID:0x3f8Caller Process Name:C:\Windows\System32\svchost.exeNetwork Information:Workstation Name:DCC1Source Network Address:::1Source Port:0Detailed Authentication Information:Logon Process:seclogoAuthentication Package:NegotiateTransited Services:-Package Name (NTLM only):-Key Length:0This event is generated when a logon request fails. It is generated on the computer where access was attempted.The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).The Process Information fields indicate which account and process on the system requested the logon.The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.The authentication information fields provide detailed information about this specific logon request.- Transited services indicate which intermediate services have participated in this logon request.- Package name indicates which sub-protocol was used among the NTLM protocols.- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Дополнительно, добавим значение Source Network Address в текст события.

Затем нужно добавить скрипт, который будет блокировать IP-адрес в брандмауэре Windows. Ниже пример, который для этого можно использовать.

Скрипт для настройки брандмауэра

param(         [Parameter(Mandatory = $true)]         [ValidateNotNullOrEmpty()]            [string]         $SourceAddress)$SourceAddress = $SourceAddress.Trim()$ErrorActionPreference = 'Stop'$ruleName = 'Quest-InTrust-Block-Failed-Logons'$ruleDisplayName = 'Quest InTrust: Blocks IP addresses from failed logons'function Get-BlockedIps {    (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue | get-netfirewalladdressfilter).RemoteAddress}$blockedIps = Get-BlockedIps$allIps = [array]$SourceAddress + [array]$blockedIps | Select-Object -Unique | Sort-Objectif (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue) {    Set-NetFirewallRule -Name $ruleName -RemoteAddress $allIps} else {    New-NetFirewallRule -Name $ruleName -DisplayName $ruleDisplayName -Direction Inbound -Action Block -RemoteAddress $allIps}

Теперь можно изменить имя правило и его описание, чтобы потом не возникло путаницы.

Теперь нужно добавить этот скрипт в качестве ответного действия к правилу, включить правило и убедиться, что соответствующее правило включено в политике мониторинга для режима реального времени. На агенте должна быть включена возможность запуска сценарий ответного действия и обязательно указан правильный параметр.

После выполненных настроек, количество неудачных авторизаций снизилось на 80%. Профит? Ещё какой!

Иногда небольшой рост возникает снова, но это из-за появления новых источников атак. Потом всё снова идёт на спад.

За неделю работы в правило брандмауэра попало 66 IP-адресов.

Ниже таблица с 10 частыми именами пользователей, которые использовались для попыток авторизаций.

Имя пользователя	Количество	В процентах
administrator	1220235	40.78
admin	672109	22.46
user	219870	7.35
contoso	126088	4.21
contoso.com	73048	2.44
administrador	55319	1.85
server	39403	1.32
sgazlabdc01.contoso.com	32177	1.08
administrateur	32377	1.08
sgazlabdc01	31259	1.04

Расскажите в комментариях как у вас построено реагирование на угрозы информационной безопасности. Какую систему используете, насколько она удобна.

Если интересно посмотреть InTrust в работе, оставьте заявку в форме обратной связи на нашем сайте или напишите мне в личку.

Почитайте другие наши статьи по теме информационной безопасности:

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

Отслеживание жизненного цикла пользователей без плоскогубцев и изоленты

А кто это сделал? Автоматизируем аудит информационной безопасности

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Подробнее..

Категории: Информационная безопасность , It-инфраструктура , Системное администрирование , Security , Софт , Блог компании gals software , Quest , Intrust , Gals software , Information security , Siem , Clm , Log management , Gartner

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

04.08.2020 12:21:41 |

Автор: admin

Одна из часто встречающихся типов атак порождение злонамеренного процесса в дереве под вполне себе добропорядочными процессами. Подозрение может вызвать путь к исполняемому файлу: частенько вредоносное ПО использует папки AppData или Temp, а это нехарактерно для легитимных программ. Справедливости ради, стоит сказать, что некоторые утилиты автоматического обновления исполняются в AppData, поэтому одной только проверки места запуска недостаточно для утверждения, что программа является вредоносной.

Дополнительный фактор легитимности криптографическая подпись: многие оригинальные программы подписаны вендором. Можно использовать факт отсутствия подписи как метод выявления подозрительных элементов автозагрузки. Но опять же есть вредоносное ПО, которое использует украденный сертификат, чтобы подписать самого себя.

Ещё можно проверять значение криптографических хэшей MD5 или SHA256, которые могут соответствовать некоторым ранее обнаруженным вредоносным программам. Можно выполнять статический анализ, просматривая сигнатуры в программе (с помощью правил Yara или антивирусных продуктов). А ещё есть динамический анализ (запуск программы в какой-либо безопасной среде и отслеживание ее действия) и реверс-инжиниринг.

Признаков злонамеренного процесса может быть масса. В этой статье мы расскажем как включить аудит соответствующих событий в Windows, разберём признаки, на которые опирается встроенное правило InTrust для выявление подозрительного процесса. InTrust это CLM-платформа для сбора, анализа и хранения неструктурированных данных, в которой есть уже сотни предустановленных реакций на различные типы атак.

При запуске программы, она загружается в память компьютера. Исполняемый файл содержит компьютерные инструкции и вспомогательные библиотеки (например, *.dll). Когда процесс уже запущен, он может создавать дополнительные потоки. Потоки позволяют процессу выполнять разные наборы инструкций одновременно. Существует много способов проникновения вредоносного кода в память и его запуска, рассмотрим некоторые из них.

Самый простой способ запустить вредоносный процесс заставить пользователя запустить его напрямую (например, из вложения электронной почты), затем при помощи ключа RunOnce запускать его при каждом включении компьютера. Сюда же можно отнести безфайловое вредоносное ПО, которое хранит скрипты PowerShell в ключах реестра, которые выполняются на основе триггера. В этом случае сценарий PowerShell является вредоносным кодом.

Проблема с явным запуском вредоносного программного обеспечения заключается в том, что это известный подход, который легко обнаруживается. Некоторые вредоносные программы предпринимают более хитрые вещи, например, используют другой процесс, чтобы начать исполняться в памяти. Следовательно, процесс может создать другой процесс, запустив определенную компьютерную инструкцию и указав исполняемый файл (.exe) для запуска.

Файл можно указать, используя полный путь (например, C:\Windows\system32\cmd.exe) или неполный (например, cmd.exe). Если исходный процесс небезопасен, он позволит запускать нелегитимные программы. Атака может выглядеть так: процесс запускает cmd.exe без указания полного пути, злоумышленник помещает свой cmd.exe в такое место, чтобы процесс запустил его раньше легитимного. После запуска вредоносной программы она, в свою очередь, может запустить легитимную программу (например, C:\Windows\system32\cmd.exe), чтобы исходная программа продолжала работать должным образом.

Разновидность предыдущей атаки DLL-инъекция в легитимный процесс. Когда процесс запускается, он находит и загружает библиотеки, которые расширяют его функциональные возможности. Используя DLL-инъекцию, злоумышленник создает вредоносную библиотеку с тем же именем и API, что и у легитимной. Программа загружает вредоносную библиотеку, а она, в свою очередь, загружает легитимную, и, по мере необходимости, для выполнения операций, вызывает её. Вредоносная библиотека начинает выполнять роль прокси для хорошей библиотеки.

Еще один способ поместить вредоносный код в память вставить его в небезопасный процесс, который уже запущен. Процессы получают входные данные из различных источников читают из сети или файлов. Обычно они выполняют проверку, чтобы убедиться в легитимности входных данных. Но некоторые процессы не имеют должной защиты при выполнении инструкций. При такой атаке не существует библиотеки на диске или исполняемого файла с вредоносным кодом. Всё хранится в памяти вместе с эксплуатируемым процессом.

Теперь разберемся методикой включения сбора подобных событий в Windows и с правилом в InTrust, которое реализует защиту от подобных угроз. Для начала, активируем его через консоль управления InTrust.

Правило использует возможности отслеживания процессов ОС Windows. К сожалению, включение сбора таких событий далеко не очевиден. Нужно изменить 3 разных настройки групповой политики:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit process tracking

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Detailed Tracking > Audit process creation

Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation > Include command line in process creation events

После включения, правила InTrust позволяют обнаруживать неизвестные ранее угрозы, которые демонстрируют подозрительное поведение. Например, можно выявить описанное тут вредоносное ПО Dridex. Благодаря проекту HP Bromium, известно, как устроена такая угроза.

В цепочке своих действий Dridex использует schtasks.exe, чтобы создать запланированное задание. Использование именно этой утилиты из командной строки считается весьма подозрительным поведением, аналогично выглядит запуск svchost.exe с параметрами, которые указывают на пользовательские папки или с параметрами, похожими на команды net view или whoami. Вот фрагмент соответствующего правила SIGMA:

detection:    selection1:        CommandLine: '*\svchost.exe C:\Users\\*\Desktop\\*'    selection2:        ParentImage: '*\svchost.exe*'        CommandLine:            - '*whoami.exe /all'            - '*net.exe view'    condition: 1 of them

В InTrust всё подозрительное поведение включено в одно правило, потому что большинство этих действий не являются специфическими для конкретной угрозы, а скорее являются подозрительными в комплексе и в 99% случаев используются для не совсем благородных целей. Такой список действий включает, но не ограничивается:

Процессы, выполняющиеся из необычных мест, таких как пользовательские временные папки.
Хорошо известный системный процесс с подозрительным наследованием некоторые угрозы могут попытаться использовать имя системных процессов, чтобы остаться незамеченными.
Подозрительные исполнения административных инструментов, таких как cmd или PsExec, когда они используют учетные данные локальной системы или подозрительное наследование.
Подозрительные операции теневого копирования обычное поведение вирусов-вымогателей перед шифрованием системы, они убивают резервные копии:

Через vssadmin.exe;
Через WMI.
Регистровые дампы целых кустов реестра.
Горизонтальное перемещение вредоносного кода при удаленном запуске процесса с использованием таких команд, как at.exe.
Подозрительные локальные групповые операции и доменные операции с использованием net.exe.
Подозрительные операции брандмауэра с использованием netsh.exe.
Подозрительные манипуляции с ACL.
Использование BITS для эксфильтрации данных.
Подозрительные манипуляции с WMI.
Подозрительные скриптовые команды.
Попытки сдампить безопасные системные файлы.

Объединенное правило очень хорошо работает для обнаружения угроз, таких как RUYK, LockerGoga и других вирусов-вымогателей, вредоносных программ и наборов инструментов для киберпреступлений. Правило проверено вендором в боевых средах, чтобы минимизировать ложные срабатывания. А благодаря проекту SIGMA, большинство этих индикаторов производят минимальное количество шумовых событий.

Т.к. в InTrust это правило мониторинга, вы можете выполнить ответный сценарий в качестве реакции на угрозу. Можно использовать один из встроенных сценариев или создать свой собственный, а InTrust автоматически распространит его.

Кроме того, можно проверить всю связанную с событием телеметрию: скрипты PowerShell, выполнение процессов, манипуляции с запланированными задачами, административную активность WMI и использовать их для постмортемов при инцидентах безопасности.

В InTrust есть сотни других правил, некоторые из них:

Выявление атаки понижения версии PowerShell когда кто-то специально использует старую версию PowerShell, т.к. в более старой версии не было возможности аудита происходящего.
Выявление входа в систему с высоким уровнем привилегий когда учетные записи, которые являются членами определенной привилегированной группы (например, администраторы домена), случайно или из-за инцидентов безопасности интерактивно входят в систему на рабочих станциях.

InTrust позволяет использовать лучшие практики безопасности в виде предустановленных правил обнаружения и реакции. А если вы считаете, что нечто должно работать иначе можно сделать свою копию правила и настроить как нужно. Отправить заявку на проведение пилота или получение дистрибутивов с временными лицензиями можно через форму обратной связи на нашем сайте.

Подписывайтесь на нашу страницу в Фейсбуке, публикуем там краткие заметки и интересные ссылки.

Почитайте другие наши статьи по теме информационной безопасности:

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

Отслеживание жизненного цикла пользователей без плоскогубцев и изоленты

А кто это сделал? Автоматизируем аудит информационной безопасности

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Подробнее..

Sysmon теперь может записывать содержимое буфера обмена

21.09.2020 16:09:27 |

Автор: admin

О релизе 12 версии Sysmon сообщили 17 сентября на странице Sysinternals. На самом деле в этот день вышли также новые версии Process Monitor и ProcDump. В этой статье я расскажу о ключевом и неоднозначном нововведении 12 версии Sysmon типе событий с Event ID 24, в который логируется работа с буфером обмена.

Информация из этого типа событий открывает новые возможности контроля за подозрительной активностью (а также новые уязвимости). Так, вы сможете понимать кто, откуда и что именно пытались скопировать. Под катом описание некоторых полей нового события и парочка юзкейсов.

Новое событие содержит следующие поля:

Image: процесс, данные из которого были записаны в буфер обмена.
Session: сеанс, в котором выполнилась запись в буфер обмена. Это может быть system(0)
при работе в интерактивном или удаленном режиме и т.д.
ClientInfo: содержит имя пользователя сеанса, а в случае удаленного сеанса исходное имя хоста и IP-адрес, если эти данные доступны.
Hashes: определяет имя файла, в котором был сохранен скопированный текст (аналогично работе с событиями типа FileDelete).
Archived: статус, был ли сохранен текст из буфера обмена в архивной директории Sysmon.

Пара последних полей вызывают тревогу. Дело в том, что с версии 11 Sysmon может (при соответствующих настройках) сохранять разные данные в свою архивную директорию. Например, Event ID 23 логирует в себя события по удалению файлов и может их сохранять всё в той же архивной директории. К имени файлов, созданных в результате работы с буфером обмена, добавляется тег CLIP. Сами файлы содержат точные данные, которые были скопированы в буфер обмена.

Так выглядит сохраненный файл

Сохранение в файл включается при установке. Можно устанавливать белые списки процессов, по которым текст сохраняться не будет.

Так выглядит установка Sysmon с соответствующей настройкой архивной директории:

Тут, я думаю, стоит вспомнить о менеджерах паролей, которые также используют буфер обмена. Наличие Sysmon в системе с менеджером паролей позволит вам (или злоумышленнику) захватывать эти пароли. Если допустить, что вам известно какой именно процесс аллоцирует скопированный текст (а это не всегда процесс менеджера паролей, а может быть какой-нибудь svchost), это исключение можно добавить в белый список и не сохранять.

Может вы не знали, но текст из буфера обмена захватывается удаленным сервером при переключении на него в режиме сеанса RDP. Если у вас есть что-то в буфере обмена и вы переключаетесь между сеансами RDP, эта информация будет путешествовать с вами.

Подведем итог возможностей Sysmon по работе с буфером обмена.

Фиксируются:

Текстовая копия вставляемого текста через RDP и локально;
Захват данных из буфера обмена различными утилитами/процессами;
Копирование/вставка текста с/на локальную виртуальную машину, даже если этот текст ещё не был вставлен.

Не фиксируются:

Копирование/вставка файлов с/на локальную виртуальную машину;
Копирование/вставка файлов через RDP
Вредоносная программа, захватывающая ваш буфер обмена, записывает только в сам буфер обмена.

При всей своей неоднозначности, этот тип событий позволит восстановить алгоритм действий злоумышленника и поможет выявить ранее недоступные данные для формирования постмортемов после атак. Если запись содержимого в буфер обмена все же включена, важно фиксировать каждый факт доступа к архивной директории и выявлять потенциально опасные (инициированные не sysmon.exe).

Для фиксации, анализа и реакции на перечисленные выше события можно использовать инструмент InTrust, который сочетает в себе все три подхода и, к тому же, является эффективным централизованным хранилищем всех собранных сырых данных. Мы можем настроить его интеграцию с популярными SIEM-системами для минимизации расходов на их лицензионное обеспечение за счет переноса обработки и хранения сырых данных в InTrust.

Чтобы узнать подробнее про InTrust, прочитайте наши предыдущие статьи или оставьте заявку в форме обратной связи.

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

А кто это сделал? Автоматизируем аудит информационной безопасности

Подробнее..

Категории: Информационная безопасность , It-инфраструктура , Системное администрирование , Security , Софт , Блог компании gals software , Sysmon , Quest , Intrust , Gals software , Information security , Siem , Clm , Log management , Sysinternals

Основные идеи методов шифрования MIMO-OFDM систем на физическом уровне

02.12.2020 18:09:40 |

Автор: admin

Я попытался раскрыть тему простым языком. Мне кажется, чтобы понять этот материал особых знаний не требуется, кроме умения читать тексты на русском и небольшого знания математики. Возможно, где-то я упустил важные детали или рассказал слишком очевидные вещи, но это все ради общедоступности. Не судите строго. Удачного чтения.

Почему это так важно?

Кажется очевидным, что пользоваться беспроводной связью значительно удобнее, чем сидеть на проводе (если вы так не считаете, то просто поверьте мне). Следовательно, требуется быстрый и надежный канал беспроводной связи. Вот тут как раз приходит на помощь OFDM сигнал (позже объясню, что это такое), который использует одновременно несколько поднесущих. А теперь мы еще модернизируем нашу схему установив на приемнике и на передатчике не одну антенну, а несколько вот мы и получили MIMO систему.

Шифрование на физическом уровне крайне выгодно, так как оно позволяет нам установить безопасное и надежное соединение без предположений о вычислительной мощности подслушивающих устройств. Такие схемы шифрования используют свойство случайности беспроводного канала, что усиливает безопасность.

Стартуем

А теперь начнем. Для начала расскажу чуть более подробно про OFDM-сигналы и MIMO и massive-MIMO системы, так как в дальнейшем понимание этих деталей не будет лишним.

Что такое MIMO и massive-MIMO и с чем их едят?

MIMO (Multiple Input Multiple Output) это способ кодирования сигнала, при котором и прием и передача сигнала происходят посредством нескольких антенн. Различают и другие системы:

SISO - Single Input Single Output
SIMO - Single Input Multiple Output
MISO - Multiple Input Single Output
MIMO - Multiple Input Multiple Output

Очевидно, что SIMO самая странная схема реализации общения, так как в этом случае базовая станция состоит из одной антенны, но зато на приемниках стоят много антенн. Представьте, что сотовый оператор ставит себе одну станцию за 1000 руб, а в каждый смартфон ставят по 5000 руб. Очевидно, что такая схема не прижилась в трех измерениях из-за экономической нецелесообразности. Реализации же других схем активно применяются, а MIMO системы в тот момент, когда вы читаете эту статью, совершенно точно собирают на каком-нибудь заводе в Китае и совершенствуют в какой-нибудь лаборатории.

MIMO использует физическое явление, называемое многолучевым распространением. Его эффект заключается в том, что сигналы поступают на приемное устройство с разными задержками и под разными углами. Это позволяет снизить требования к каналу передачи данных (среде распространения). Например, вы можете поставить у себя дома больше устройств, создающих помехи, и при этом вы не ухудшите качество сигнала. Также MIMO увеличивает радиус действия, улучшает пропускную способность беспроводной сети и скорость передачи данных без увеличения диапазона частот.

Более формально можно описать это добавлением нового ресурса:

Время (time diversity) сигнал может передаваться на протяжении фиксированного отрезка времени.
Частота (frequency diversity) невозможно использовать частоты, вне выданного вам диапазона.
Пространство (spatial diversity) одинаковые сигналы могут быть переданы по разным путям (различными антеннами) и, следовательно, на приемнике возможна более точная оценка сигнала с использованием наиболее правдоподобных копий.

Пусть Y принятый сигнал, H матрица канала, X отправленный сигнал, N шумы в канале(AWGN-аддитивный белый гауссовский шум).Тогда принятый сигнал представим в виде:

Один из возможных методов решения минимизация среднеквадратичной ошибки дает аналитическое решение:

$X^* =(H^TH-\sigma^2I)^{-1}H^TY$

Кстати, на практике иногда не так уж и просто найти обратную матрицу.

Massive-MIMO это схема, при которой количество антенн на базовой станции много больше их числа на мобильной. На базовой станции ставят 128, 256 антенн, а на приемнике 2-3 штуки. MIMO активно применяется в WiFi, LTE. Massive-MIMO будет основой для построения сетей 5G и, судя по темпам развития, и 6G.

Вместе с ростом числа антенн возникают и новые и проблемы. В случае MIMO нужно было антенны на одном устройстве разнести друг от друга, дабы уменьшить корреляцию между соседними элементами, теперь же это требование еще более актуально. Также, при увеличении числа антенн увеличиваются и взаимные помехи (часть из этих проблем может быть решена посредством применения технологии автоматического формирования луча в направлении абонента).

Заправим наше MIMO-system блюдо OFDM модуляцией.

OFDM (orthogonal frequency-division multiplexing мультиплексирование с ортогональным частотным разделением каналов) схема модуляции, в которой предоставленный частотный диапазон разбивается на несколько субканалов, в каждом из которых используется своя поднесущая. При этом исходный плотный поток данных разбивается на несколько разреженных субпотоков и каждый передается независимо на своей частоте.

Из-за особенностей OFDM-модуляции возникают два типа помех: межсимвольные (ISI inter-symbol interference) и межнесущие (ICI inter-carrier interference).

ISI

В результате многолучевого распространения мы можем получить ситуацию, когда задержанная версия первого символа накладывается на второй символ, приводя к искажениям. Для того, чтобы избежать такой проблемы в каждый символ добавляется защитный временной интервал (guard interval).

ICI

Доплеровский сдвиг приводит к тому, что каждая частота сдвигается на некоторое значение, при этом расстояние между поднесущими также меняется. Это вызывает нарушение требования ортогональности точное равенство расстояния между поднесущими обратному периоду символа. Эта проблема решается добавлением циклического префикса(CP insertion) формально это циклическое повторение сигнала, длина которого, как и в случае ISI, рассчитывается из наибольших возможных помех в канале.

Преимущества OFDM:

Высокая спектральная эффективность
Возможность работы в зашумленных каналах (если одна поднесущая не передает сигнал (помехи в канале в узком диапазоне), то можно переложить эту работу на оставшиеся)
Высокая адаптивность (благодаря независимости поднесущих возможно использование различных методов модуляции и их автоматическая перенастройка в зависимости от стабильности канала)

Недостатки OFDM:

Схема модуляции чувствительна к эффекту Доплера, из-за чего невозможно использование при быстром передвижении
Необходимость точной синхронизации
Высокое энергопотребление

Все, теперь переходим к защите информации. Дальше будет чуть сложнее, но не отчаивайтесь.

Три кита защиты информации

Информационная безопасность в классической модели основывается на трех принципах: конфиденциальность, целостность и доступность (CIA triangle - Confidentiality, Integrity, Availability). Рассмотрим каждый из них.

Конфиденциальность.

Этот принцип является гарантией того, что неавторизованные пользователи не получат доступ к конфиденциальной информации. Предоставление данных третьим лицам должно быть ограничено, распространение данных возможно только среди пользователей, имеющих право на доступ к информации. В настоящее время предлагается несколько способов по улучшению этого уровня безопасности:

Разделение пользователей и данных по категориям в соответствии с потенциальными угрозами при потере информации.
Двухфакторная аутентификация для получения доступа к конфиденциальным данных наиболее популярная практика. Также применяются другие методы, например, проверка биометрии.
Предупреждение пользователей о методах злоумышленников (например, социальная инженерия), ограничение подозрительных контактов, обучение информационной гигиене.

Целостность.

Этот принцип гарантирует тот факт, что данные не были изменены во время передачи. На этом этапе возможны: применение разрешения на доступ к конфиденциальной информации, ведение системы контроля версий, использования контрольным сумм для обнаружения изменений, не вызванных вмешательством человека.

Доступность.

Этот принцип лежит в основе надежного и непрерывного доступа правильных лиц к конфиденциальной информации. Для обеспечения необходимого уровня защиты на данном уровне система должна быть избыточна и отказоустойчива, должна быть приспособлена к действиям в сложных условиях, в том числе при отказах целых блоков систем. Необходимо проведение стресс тестов на предмет возможности работы в условиях DOS (Denial of Service) или DDOS (Distributed Denial of Service) атак. Принцип доступности нередко называют основным в модели информационной безопасности.

Как вы могли заметить, обеспечение высокой степени защиты конфиденциальной информации требует использования криптографических (или некриптографических) методов. Некоторые криптографические алгоритмы используют функции раунда по несколько раз для обеспечения необходимых свойств случайности шифротекста. Рассматриваемые далее методы шифрования на физическом уровне позволяют сократить максимальное число раундов посредством использования свойств случайности и изменчивости канала передачи данных в MIMO-OFDM системах.

В дальнейшем я предлагаю рассмотреть методы шифрования, касающиеся принципов конфиденциальности и целостности. Доступность в данной статье мы не будем рассматривать.

Аутентификация пользователя

На данном уровне существуют два типа атак: Fake client attack (FCA) и Fake access point (AP) attack.

Fake client attack. После получения пробного кадра третье лицо отправляет на сервер поддельную информацию о канале (CSI Channel State Information). Ниже представлено решение проблемы.

Fake access point attack. В этом случае злоумышленник предоставляет клиенту поддельный пробный кадр, из-за которого тот отправляет на сервер неверный ответ. Решение опять же ниже.

Существуют и другие схемы шифрования на физическом уровне. Грубо я выделю следующую классификацию всех существующих алгоритмов.

Симметричное и ассиметричное шифрования используют канал передачи данных для генерации симметричного ключа в первом случае и пары открытый и закрытый ключ во втором случае в предположении о том, что канал является надежным генератором случайных чисел. Недостатком этих двух схем является теоретическая доступность канала связи для злоумышленника, но зато если удалось скрыть канал обмена данными, то данные схемы обеспечивают одновременно и конфиденциальность, и аутентификацию.

Для двух следующих алгоритмов выдвину предположения:

Алиса общается с Бобом и проверяет гипотезу H0 = "сообщение пришло от Боба" против H1 = "сообщение пришло не от Боба"
Канал меняется во времени, матрица канала меняется непрерывно
Матрицу канала можно разбить на вектора, из которых можно составить авторегрессионную схему.

Алгоритм AKBA(asymmetric-key based authentication):

На первом шаге Алиса передает пилоты,а Боб оценивает канал.

$h_n(t) = h_n(t1) + \sqrt{1-^2}z_n(t)$

- коэффициент корреляции, z(t) - независимые одинаково распределённые c.в. из комплексного нормального распределения.

Боб квантует мнимую и действительную части оценки канала при помощи определенного квантователя и уровня квантования, извлекает из них битовую последовательность b.
Боб применяет известную всем пользователям функцию хэширования и сжатия для получения более короткого ключа из битовой последовательности b, создает пару открытый-закрытый ключ (K1, K2)
На втором шаге Боб передает всем пользователям открытый ключ K1, и кодирует данные при помощи созданного закрытого ключа K2, благодаря чему Алиса может его идентифицировать.

Алгоритм SKBA(symmetric-key based authentication):

На первом шаге Алиса передает список пилотных символов Бобу, Боб оценивает канал.

$h_n(t) = h_n(t1) + \sqrt{1-^2}z_n(t)$

На втором шаге происходит обратное общение. Боб передает Алисе список пилотных символов, а Алиса оценивает канал.
В словаре кодовых слов Алиса находит ближайшее к каждой из 2N оценок канала

$c^* = argmin_{cC}||h_A(2) - c||^2$

и отправляет Бобу вектор ошибок.

Боб вычисляет ошибку между принятым вектором и своей оценкой канала

и находит ближайшее кодовое слово из словаря ко всему вектору.

$c^* = argmin_{cC}||h_B c||^2$

Боб и Алиса применяют хэш-функцию к индексу последовательностей для извлечения битов, которые будут использованы как ключ аутентификации.

Сравнительно с остальными методами наибольшей устойчивостью к взлому обладает шифрование на основе регулярных оценок канала (достаточно сложна, поэтому опустим подробное описание работы). В этом случае в ходе общения каждый раз заново оценивается канал общения (вследствие общения в MIMO-OFDM он изменчив) и на основе этих оценок шифруется сообщение. Постоянная смена ключей надежна, но при этом требует высокой вычислительной мощности передающего устройства.

Схема шифрования на основе сравнения пилотных символов принимает решение о корректности идентификации клиента на основе сходства пилотных символов в различных сообщениях.

Алгоритм PLA(Physical Layer Authentication)

На первом шаге Боб передает список пилотных символов Алисе, которая оценивает канал(так же как в прежних схемах).
Во всех последующих передачах Алиса сравнивает оценки каналов на шагах t > 1 с первой оценкой, расстояние вычисляется по формуле:

$(t) = \frac{1}{N {\gamma_{A}}^2(t)} \sum_{n=1}^{N} {|h_n(t)-^{t-1}h_n(1)|^2}$

Алиса принимает решение о том является ли Боб на самом деле Бобом на основе сревнения расстояния с пороговой функцией:

Данный способ не требователен к вычислительным ресурсам, однако имеет некоторые особенности, связанные с требованием к хранению в памяти предыдущих пилотных символов и необходимостью идентификации Боба во время первой передачи. Также в данной схеме рекомендуется настроить дополнительные системы шифрования, так как сравнение пилотов не гарантирует полной защиты.

Можно видеть, что каждая их схем опирается на свойство случайности канала связи, однако теоретически злоумышленник может оценить ваш канал связи и тогда ваша схема аутентификации не будет работать.

Вывод: данные алгоритмы шифрования являются отличным дополнением к высокоуровневым, они просто реализуемы и вычислительно просты, их можно использовать для повышения уровня защиты.

Конфиденциальность данных

В данном пункте я предлагаю рассмотреть различные схемы шифрования, обеспечивающие некоторый уровень безопасности передаваемых данных. Все схемы я условно разделил на 4 мало связанных между собой класса. По каждому из классов я изложу известные(классические или же самые простые) методы шифрования или общие идеи, которые, однако, не являются универсальными(существуют улучшенные реализации, но их описание потребует больше времени). Итак, поехали.

Скремблер

Ниже приведена классическая схема реализации этого типа шифрования. Этот прием довольно часто применяется в области защиты информации и прежде всего для повышения защищенности от перехватов и вредоносных атак в системах связи, где передача данных происходит по открытым каналам.

Сначала поток данных преобразуется в несколько параллельных потоков. После этого эти потоки поступают на вход скремблера, матрица которого может быть построена различными способами (один из возможных - на основе местоположения мобильной станции). Затем данные передаются через канал посредством нескольких антенн на стороне приемника и на стороне передатчика. Сигнал на приемнике представим в виде:

N - AWGN(аддитивный белый гауссовский шум), H - матрица канала, X - входные данные

Приемное устройство проводит обратные операции:

$X^* = S^{-1}H^{-1}Y = X+S^{-1}H^{-1}N$

Скремблер является вычислительно простой схемой шифрования. Однако, если проводить перемешивание входных данных только на основе оценки канала, то это схема может быть взломана. Поэтому для большей надежности следует предусмотреть возможность инициализации скремблера при помощи секретного ключа.

Оценка канала

Я предлагаю к рассмотрению схему шифрования, рассчитанную на ограниченное число M одновременных пользователей.

На базовой станции случайным образом генерируются M ортогональных векторов w размерности число антенн на базовой станции. Затем они нормализуются и каждому из M пользователей рассылаются прекодированные известные символы по формуле

$x = \sum_{i=1}^{M}{w_ms_i}$

Пользователи вычисляют отношение уровня сигнала к уровню шума(SINR - signal-to-interference-plus-noise ratio) по формуле

$\gamma_{k,m} = \frac{P|h_kw_m|^2}{\sum_{i=1, i \neq m}^{M}{P|h_kw_i|^2}+\sigma^2}$

P - мощность передачи каждого луча

Среди всех лучей каждый из пользователей выбирает луч:

$w_{m_k} = arg max_{1mM} {_{k,m}}$

и возвращают базовой станции индекс, соответствующий наибольшему SINR и само значение SINR. После получения всех ответов от мобильных станций, базовая станция принимает решение о выборе векторов для каждого пользователя с наибольшим SINR. При необходимости предыдущий шаг повторяется до установления однозначного соответствия.

Одним из основных минусов данного метода является необходимость дополнительного шифрования во избежание синхронизации злоумышленника с реальными пользователями.

Искусственные помехи и затухание

Идея этого типа шифрования проста: базовая станция предполагает существование воображаемых пользователей и создает матрицу прекодирования на основе всех пользователей. Прекодированный сигнал может быть успешно декодирован только при прохождении через канал легитимного пользователя. Обращаю ваше внимание на то, что в этом случае не требуется отправка ответа базовой станции и по сему злоумышленник не сможет восстановить исходный сигнал.

Схема с искусственными помехами(AN - Artificial Noise)

Алиса искажает передаваемые символы посредством добавления искусственных шумов. Шумы генерируются так, чтобы Боб смог их отбросить, а потому они не ухудшают демодулирование сигнала.

Передаваемый символ на l-й поднесущей:

$x^l_{AN} = ^l_{ZF}u^l + Z^lv^l$ $^l_{ZF} = (H^l)^{+}$

а Z получается из SVD разложения матрицы канала:

На законном приемнике имеем:

На незаконном приемнике:

$y^l_{AN} = G^l x^l_{AN} + n^l = G^l ^l_{ZF}u^l + G^l Z^l v^l + n^l$

Схема с затуханием(AFF - Artificial Fast Fading)

Алиса искусственно домножает исходный сигнал на коэффициенты затухания в соответствии с матрицей канала. При прохождении через канал к Бобу сигнал приходит в исходной форме. До злоумышленника сигнал идет по другому каналу, значит искажется при передаче.

Передаваемый символ на l-й поднесущей:

$x^l_{AFF} = ^l_{AFF}u^l$ $^l_{AFF} = [^l_{rand} ^l_{cancel}]^T$

Как видите, матрица состоит из двух частей: случайной и отменяющей, которая отвечает за удаления эффекта затухания при прохождении через легитимный канал.

$^l_{cancel}=({H^l}_{cancel})^{-1}(I {H^l}_{rand}{^l}_{rand})$

На законном приемнике имеем:

$y^l_{AFF} = H^lx^l_{AFF} + n^l = u^l + n^l$

На незаконном приемнике:

$y^l_{AFF} = G^l x^l_{AFF} + n^l = G^l ^l_{AFF}u^l + n^l$

Общая диаграмма направленности в сочетании с помехами

Рассматривается схема, в которой пользователи объединены между собой в кластеры, которые общаются между собой посредством общего формирования диаграммы направленности и помех. Предполагается, что внутри легальных кластеров нет злоумышленника(сильное требование), он создал отдельный кластер с блэкджеком и ему там не скучно. В каждом из кластеров определяется главное устройство, которое будет управлять передачей данных.

Рассмотрим процесс общения между кластерами. Сначала передающее устройство передает данные пользователям своего кластера, а в принимающем кластере пользователи передают принимающему устройству помехи. Затем передатчик и его соседи передают данные на приемное устройство, а в принимающем кластере соседи принимающего устройства передают те же самые помехи. В итоге, на приемнике имеется и шум, и зашумленный сигнал и остается лишь восстановить исходные данные.

Минусом такой схемы являются требования к синхронизации между большим количеством устройств, а также необходимость проверки легитимности пользователя при его подключении к кластеру.

Выводы

Мы рассмотрели некоторые из методов шифрования на физическом уровне. Снова обращаю ваше внимание на то, что не все из них могут гарантировать безопасную передачу данных. Однако за счет простоты реализации и малой вычислительной сложности могут быть внедрены в современные ЭВМ.

Список литературы:

[] - What is Information Security? The Basics of Information Security

[] - Comparison Between Asymmetric and Symmetric Channel-Based Authentication for MIMO Systems

[] - A Physical Layer Security Scheme Employing Imaginary Receiver for Multiuser MIMO-OFDM Systems

[] - High security orthogonal factorized channel scrambling scheme with location information embedded for MIMO-based VLC system

[] - Mode Selection in MU-MIMO Downlink Networks: A Physical-Layer Security Perspective

[] - Virtual MIMO-based cooperative beamforming and jamming scheme for the clustered wireless sensor network security

[] - Physical Layer Authentication over MIMO Fading Wiretap Channels

[] - Virtual MIMO-based cooperative beamforming and jamming scheme for the clustered wireless sensor network security

Подробнее..

Категории: Информационная безопасность , Сетевые технологии , Беспроводные технологии , Information security , Encryption , Ofdm , Mimo

След протектора как киберпреступники прятали стилеры в презентации от подрядчика МГУ

14.12.2020 14:08:42 |

Автор: admin

"Привет из МГУ. М.В.Ломоносов,
Внимание: по рекомендации вашей компании мы выступаем в качестве подрядчика МГУ. М.В.Ломоносова под руководством доктора философских наук. Виктор Антонович Садовничий. Нам нужно ваше предложение по нашему бюджету на 2020 год (прилагается). Подайте заявку не позднее 09 ноября 2020 года. Спасибо и всего наилучшего".

Получатель этого странного послания, даже очень далекий от научных кругов, сразу обратит внимание на две вещи: как безграмотно оно написано, а, во-вторых, ректор МГУ может быть философом лишь по состоянию души Виктор Антонович на самом деле доктор физико-математических наук, но никак не философских.

СERT Group-IB подтвердил догадку сентябрьские почтовые рассылки от имени руководства МГУ им. М.В. Ломоносова фейковые, более того они несли на борту популярные вредоносные программы для кражи данных (Data Stealer) Loki или AgentTesla Однако сегодняшний пост не про них, а об одном незаметном помощнике протекторе, которые защищает программы-шпионы от обнаружения. О том, какие техники использует этот протектор и как аналитикам удалось сквозь них добраться до исполняемого файла AgentTesla, рассказывает Илья Померанцев, руководитель группы исследований и разработки CERT-GIB .

Механизм распространения

В самом фишинговым письме его можно хорошенько рассмотреть на скриншоте ниже отправитель представляется подрядчиком вуза и предлагает утвердить бюджет. Среди получателей сообщения финансовые, промышленные и государственные организации России.
Хотя текст написан на русском языке, грубые орфографические, грамматические и стилистические ошибки наводят на мысль о том, что атакующие не носители языка. И, скорее всего, они использовали для составления писем машинный перевод.

В письме два идентичных вложения с разными расширениями:

Заражение

Исходный файл презентация PowerPoint в формате ppt. Дата последнего редактирования 5 ноября, а автором указан некто Masterofyourfather.

В документе три небольших VBA-макроса, которые приведут к выполнению команды:

mshta
http://%748237%728748@j[.]mp/aksnkwsfvyudnddwid

Сокращатель ссылок j.mp перенаправит на ресурс ninjaminjatumhmmkk.blogspot[.]com/p/8a9.html.

При открытии страницы, на первый взгляд, может показаться, что автор еще не разместил полезную нагрузку и дальнейший анализ невозможен.

Однако наша система Group- IB
Threat Hunting Framework и ее модуль Polygon, позволяющий осуществлять поведенческий анализ файлов, извлекаемых из электронных писем, опровергла это предположение, продемонстрировав, как развивается атака дальше.

Если заглянуть в исходный код страницы становится ясна причина такой скрытности. Ресурс Blogspot позволяет вставлять script-теги в теле блога. А поскольку все современные браузеры по умолчанию игнорируют скрипты на VBscript, при обычном открытии страницы ничего не происходит.

Базовый скрипт

Базовый скрипт совмещает три задачи:

Закрепление в системе
Обход систем защиты
Загрузка основного модуля

Рассмотрим каждый пункт в отдельности.

Закрепление в системе

Для персистентности ВПО использует механизм безфайлового закрепления. Для этого в реестре в ветке HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ создаются ключи со значениями mshta vbscript:Execute({Тело скрипта VBS}). Это позволяет хранить полезную нагрузку целиком в реестре, при этом реализуя автозапуск.

Также реализована альтернативная возможность автозапуска через отложенную задачу (строчка 21 на скриншоте сверху). По указанным ссылкам расположены страницы Blogspot с полезной нагрузкой, размещаемой аналогично исходной. На момент анализа ни по одной ссылке вредоносного кода не оказалось.

Ссылки:

zoomba619.blogspot[.]com/p/5e.html
dodumdum6.blogspot[.]com/p/8a9.html
milltu99.blogspot[.]com/p/4w5.html
potatokapoli.blogspot[.]com/p/5e.html

Загрузчик основного модуля закрепляется в ветке HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ в ключе sexformoneyforsex, который приводит к исполнению powershell-скрипта, запускающего сценарий, размещенный по ключу HKCU\Software\juggga.

Модуль обхода встроенных систем защиты Windows закрепляется аналогично по ключу Defeduckgotfucked, который приводит к исполнению powershell-скрипта, запускающего сценарий, размещенный по ключу HKCU\Software\phuttalylo.

Обход систем защиты

Модуль обхода встроенных систем защиты Windows хранится в реестре в обфусцированном виде. Полезная загрузка записана строкой в виде ASCII-кодов, разделенных символом -. После декодирования нас ждет еще один простой скрипт, который содержит отраженную Base64-строку, в которой символ 0 заменен на ..

В итоге мы получим небольшое .NET-приложение.

Основной класс CMSTPBypass выдает механизм работы файла.

CMSTP это приложение, связанное с установщиком профиля Microsoft Connection Manager. Оно принимает файлы INF, которые могут быть снабжены вредоносными командами для выполнения произвольного кода в форме скриптлетов (SCT) и DLL. Это доверенное приложение Microsoft.

ВПО сохраняет в папку %Temp% файл inf с произвольным именем и следующим содержимым:

Строка REPLACE_COMMAND_LINE будет заменена на команду запуска vbs-скрипта из папки %Temp%, который ВПО извлечет из своей секции ресурсов.

В коде можно заметить упоминание NyanCat, автора известных крипторов и data stealer'ов. В его официальном репозитории на GitHub мы нашли исходный код модуля. Видимо, его позаимствовали атакующие.

Запуск осуществляется через c:\windows\system32\cmstp.exe, после чего ВПО начинает отслеживать появление окна cmstp, чтобы послать ему нажатие клавиши ENTER.
Запущенный VBS-скрипт фактически снижает встроенную защиту Windows до нуля:

Если скрипт запущен не с правами администратора он будет перезапущен с повышением привилегий.
Для Windows Defender применяются следующие настройки:
В исключения Windows Defender целиком добавляются диски C:\ и D:\, а также процессы Msbuild.exe, Calc.exe, powershell.exe, wscript.exe, mshta.exe, cmd.exe.
Отключается UAC.
Для пакетов MS Office версий от 11.0 до 16.0 отключаются все настройки безопасности.

Загрузка основного модуля

Загрузчик размещается в реестре по ключу HKCU\Software\juggga. Хотя ВПО предусматривает его автозапуск после перезагрузки, он будет также исполнен во время работы основного скрипта. Для этого запустится оболочка PowerShell в скрытом окне:

Механизм обфускации загрузчика аналогичен рассмотренному в предыдущем разделе:

Загрузка осуществляется по ссылке paste[.]ee/r/ZonQw:

После декодирования получаем исполняемый файл, который представляет собой обновленную версию уже знакомого нам AgentTesla.

Agent Tesla это модульное программное обеспечение для шпионажа, распространяемое по модели malware-as-a-service под видом легального кейлоггер-продукта. Agent Tesla способен извлекать и передавать на сервер злоумышленникам учетные данные пользователя из браузеров, почтовых клиентов и клиентов FTP, регистрировать данные буфера обмена, захватывать экран устройства.

Заключение

Мы рассмотрели любопытный протектор, вобравший в себя большое количество различных технологий по противодействию существующим системам защиты для конечных устройств. Если в организации нет современных систем, способных полностью автоматизировано останавливать целевые атаки на организацию, и детонировать принудительно вскрывать подозрительные почтовые рассылки в изолированной среде, то рассмотренное ВПО позволит протащить на машину и закрепить в системе любую полезную нагрузку, даже такой хорошо известный и выявляемый большинством антивирусов data stealer, как AgentTesla.

Подробнее..

Категории: Информационная безопасность , It-компании , Реверс-инжиниринг , Исследования и прогнозы в it , Cybersecurity , Блог компании group-ib , Вредоносы , Впо , Information security , Компьютерная криминалистика , Cybercriminalistics , Вредоносное по , Вредоносное программное обеспечение , Cybercrime , Реверс инжиниринг , Протектор , Protector , Cyberattack

Почему злой-сосед-хакер не накрутит вам умный счётчик. Защищённость NB-IoT от сетевых атак

24.12.2020 12:19:48 |

Автор: admin

Прошло 2 года с тех пор, как в России появилась возможность разворачивать IoT-системы на базе технологии NB-IoT. Счётчики, сами отправляющие свои показатели в ЖКХ, автоматические микро-метеозонды вдали от цивилизации, умное сельское хозяйство всё это скоро станет частью повседневности.

Важно, чтобы ни система устройств, ни данные, которые она собирает и передаёт, не были использованы против пользователей системы. Если вам интересно, как стандарт NB-IoT защищает их от сетевых атак, то приглашаю под кат.

Об атаках

Как уже говорилось, в сфере сбора и обработки данных с помощью IoT основной интерес и опасения вызывают атаки, направленные на чтение данных (прослушка канала, получение несанкционированного доступа к данным) и их подмену. Для предотвращения прослушки используется шифрование, а от подмены применяют механизмы подтверждения авторства пакетов (аутентификацию), например цифровую подпись (которая тоже является задачей шифрования), или метод для IoT систем, описанный в [1].

Не секрет, что на сегодняшний день обычные компьютеры и смартфоны способны обеспечить криптостойкость шифратора канала связи такую, что на его взлом на современном суперкомпьютере потребуется время, превышающее время жизни вселенной, но у такой криптостойкости есть цена вычислительное время шифрования и мощность, потребляемая устройством. Умный счётчик, одной батарейки в котором должно хватить на 10 лет беспрерывной работы, и месяца не проработает, если каждый день только и будет считать точки эллиптической кривой. В скорости тоже проблема: для выполнения простых операций по снятию и отправке показаний много вычислительной мощности не нужно, чего не скажешь о надёжном шифровании.

Стандартные методы защиты информации от сетевых атак для маломощных устройств не работают из-за нестандартных ограничений на операции, допустимые для этих устройств. С другой стороны, правильное построение сети накладывает ограничения уже на атакующего, и в зависимости от ограничений стандарта выбирается наиболее подходящий легковесный алгоритм ([2]).

Кратко об NB-IoT

Поговорим о стандарте NB-IoT: зачем он нужен, что описывает и как работает то, что он описывает. После этого выясним, какие ограничения накладываются на сеть.

NB-IoT создан для обслуживания сотовыми операторами сетей простых регистрирующих устройств (Оконечные Устройства, или ОУ). Работа ОУ заключается в том, чтобы собирать некоторые данные и в заранее установленные промежутки времени суток передавать их на сервер-обработчик, который распорядится этими данными дальше. Именно технология передачи, от физики до сети, описана в стандарте NB-IoT.

В NB-IoT между внутренней сетью оконечных устройств и внешней сетью сервера-обработчика нет сетевой связности. Другими словами, оператор отделяет сеть ОУ от внешней сети (по-сути, от интернета), и выступает посредником между двумя сетями.

Задачи оператора как посредника:

поддерживать радиоканал связи с каждым ОУ,
передавать потоки данных от сервера-обработчика к ОУ и от ОУ к серверу,
предоставлять доступ к чтению потоков и управлению серверу-обработчику и только ему.

То есть полезные данные проходят через три разделённые сети: сеть устройств, сеть инфраструктуры оператора, интернет. Прослушку или подмену злоумышленник может делать, когда его устройство находится в одной из этих трёх сетей, поэтому вопрос о защищённости потока данных, передаваемого по NB-IoT, разделяется на три: о его защищённости в каждой из сетей отдельно.

Опустив вопрос о защищённости данных внутри сети оператора и оставив его на совести оператора, и рассмотрим остальные два.

Защищённость данных во внешней сети

Поставим себя на место злоумышленника. Перед нами 2 общающихся хоста: сервер-обработчик и предоставленный оператором специально для него интерфейс доступа к данным, собранным ОУ. Что находится за этим интерфейсом нас не интересует это часть инфраструктуры провайдера.

Общение между обработчиком и интерфейсом оператора это обычное общение двух хостов в интернете. Как уже писалось ранее, они достаточно мощные, чтобы обеспечить себе криптостойкие каналы передачи, поэтому вопрос защищённости данных с ОУ во внешней сети интереса не представляет.

Защищённость данных в сети оператора

Рассмотрим теперь внутреннюю сеть.

Первым делом, сеть в определённом смысле изолирована: к ней нет сетевого пути извне, есть только возможность прямого вмешательства в её физику. Физическая связь между ОУ и оператором осуществляется радиоканалом на одной из выделенных частот. Топология сети совокупность прямых подключений между ОУ и оператором, причём все они статические заранее предустановленные. Значит злоумышленнику, который хочет взаимодействовать с узлом в этой сети, необходимо выдавать себя за противоположный узел, при чём так, чтобы настоящий узел не обнаружил имитирующий его трафик. В случае, когда трафик передаётся во по радиоволне, это само по себе нетривиальная задача.

Кроме этого, будем всё так же шифровать пакеты и аутентифицироваться при подключении.

Важно!
Оператор не обязан предоставлять шифрование трафика в сети ОУ-Оператор. Шифрование возможно как отдельная услуга, за которую платит организация, разворачивающая IoT-систему с помощью NB-IoT оператора.

ОУ недостаточно мощны для того чтобы использовать тяжёлые криптостойкие алгоритмы шифрования, а стойкость легковесных алгоритмов заметно более низка, что, в том числе, значит, что злоумышленнику нужно относительно немного пакетов для анализа, прежде чем он сможет выяснить ключ алгоритма.

В NB-IoT эффективность легковесных алгоритмов шифрования достигается тем, что обмен пакетами между ОУ и оператором, просто по концепту, происходит редко: единицы пакетов в день (точнее про необходимую для эффективности редкость трафика можно прочитать в [2]) Выходит, злоумышленнику попросту неоткуда взять большую базу пакетов для анализа в короткие сроки: любой алгоритм шифрования в сети с редким трафиком будет держаться дольше, чем в аналогичной ситуации в сети в частым трафиком.

Итог

NB-IoT вполне надёжный стандарт сервиса. Подмена трафика во внутренней сети (стояние посредине) дорогостоящее предприятие в силу необходимости сокрытия радиосигнала узлов друг от друга. Кроме того, стояние посредине нельзя начинать, пока не будут известны ключи аутентификации узлов, достаточно надёжно защищённые легковесным алгоритмом шифрования, как и все данные, передаваемые от ОУ к оператору.
Попытки чтения или стояния посередине в сети оператора и во внешней сети также не приведут к успеху, поскольку у устройств в этих сетях достаточно вычислительной мощности для надёжного шифрования трафика.

Источники и ссылки:

Yuxiang Feng, Wenhao Wang, Yukai Weng, Huanming Zhang, A Replay-Attack Resistant Authentication Scheme for the Internet of Things
Saurabh Singh, Pradip Kumar Sharma, Seo Yeon Moon & Jong Hyuk Park: Advanced lightweight encryption algorithms for IoT devices: survey, challenges and solutions
3GPP Release 13 Specification Спецификация NB-IoT
Первая статья из цикла о реализации NB-IoT от МТС рекомендую этот цикл как первый шаг в изучении NB-IoT

Подробнее..

Категории: Информационная безопасность , Интернет вещей , Криптография , Iot , Сотовая связь , Nb-iot , Information security , Cryptography

Социотехническое тестирование какое лучше выбрать в 2021 году?

29.12.2020 12:11:44 |

Автор: admin

В интернете предостаточно статей о важности социотехнического тестирования. В них разбирается само понятие, методика, инструменты и почему так важно его проводить. Все просто: человек слабое звено в системе защиты любой компании.

В этой статье команда департамента аудита и консалтинга Group-IB решила пойти дальше и поделиться своим опытом социотехнического тестирования, которое проводила в этом году. Расскажем, для каких целей использовать данный вид тестирования, какие форматы предпочитали компании, что лучше выбрать в следующем году, а также каких результатов ждать.

Сразу предупреждаем, что текста получилось немало. Поэтому запасайтесь чаем, теплым свитером и любимой музыкой на фоне перед вами новогоднее чтиво. Также по нашей классике спешим предупредить (внимание: дисклеймер), что все совпадения случайны, а читатель сам в праве думать, что в этих историях правда, а что ложь.

С чего начинается социотехническое тестирование?

Тестирование начинается с формулирования целей. Именно цель определяет остальные составляющие:

время на подготовку к тестированию
объем разведывательных работ
формат тестирования
условия, которые должна обеспечить компания для старта работ
стоимость тестирования (эту составляющую не обсуждаем в статье)

Для чего и как проводить такое тестирование?

Социотехническое тестирование может проводиться для установления:

уровня осведомленности сотрудников и их практических навыков в распознавании социотехнических атак
эффективности функционирования систем обеспечения информационной безопасности
уровня подготовки сотрудников ИТ- и ИБ-отделов к выявлению и реагированию на социотехнические атаки (уровень осведомленности в вопросах безопасности данных сотрудников выше, что повышает сложность тестирования)
возможности компрометации инфраструктуры (социотехническое тестирование может применяться для тестирования на проникновение)

Соотношение цели социотехнического тестирования (социальная инженерия или СИ) и других его составляющих представлено в таблице.

	Определить уровень подготовленности сотрудников	Определить эффективность функционирования СЗИ	Определить уровень подготовленности сотрудников ИТ- и ИБ-отделов	Компрометация инфраструктуры
Формат тестирования	письма со ссылкой на поддельный ресурс (фишинг) письма с исполняемым вложением (нагрузка) телефонное взаимодействие (вишинг)	письма со ссылкой на поддельный ресурс (фишинг) письма с исполняемым вложением (нагрузка)	письма со ссылкой на поддельный ресурс (фишинг) письма с исполняемым вложением (нагрузка) телефонное взаимодействие (вишинг)	письма со ссылкой на поддельный ресурс (фишинг) письма с исполняемым вложением (нагрузка)
Начальные условия	ФИО сотрудников и email-адреса номера телефонов, ФИО и/или должности сотрудников, а также любая другая информация согласно легенде добавление в белые списки (email-адреса, домены, СЗИ и т.д.)	ФИО сотрудников и email-адреса	ФИО сотрудников и email-адреса номера телефонов, ФИО и/или должности сотрудников, а также любая другая информация согласно легенде добавление в белые списки (email-адреса, домены, СЗИ и т.д.)	входная информация не предоставляется
Время на подготовку	Одна неделя	Две недели	Одна-две недели	Три недели

Теория, теория Где же обещанные истории?

Да-да. Раз обещали рассказать про опыт, то и историями поделимся. Основные моменты мы расскажем немного позже в кейсах. А сейчас немного отвлечемся на различные ошибки и просто любопытные моменты.

Очевидно, что одинаковое понимание целей и процедуры проведения социотехнического тестирования обеими сторонами (источником и потребителем), участвующими в тестировании, позволяет избежать ошибок, которые тормозят, угрожают срывом тестирования и негативно влияют на результаты.

Как показывает практика, ошибки, вызванные недопонимаем сторон, встречаются достаточно часто. Например, со стороны компаний, заказывающих социотехническое тестирование, нас поджидали следующие неожиданности:

затягивание согласования легенды и предоставления адресов почты для рассылки
предоставление неактуального списка сотрудников
многократная отработка одной легенды на одних и тех же сотрудниках
загрузка подготовленной полезной нагрузки в используемое СЗИ (да-да, здесь речь про проверку осведомленности/подготовленности сотрудников, а не СЗИ...)
добавление сотрудников ИТ/ИБ-отделов в рабочую переписку (при том что их уровень осведомленности и проверялся)

Но будем честны эксперты тоже не застрахованы от подобных ошибок, влияющих на результаты тестирования. И вот одна из них:

Представим, что в компании N проводится несколько социотехнических тестирований, каждое из которых включает телефонное взаимодействие с сотрудниками. Список сотрудников и их контакты предоставлял представитель компании.

Первое телефонное взаимодействие было успешным: ряд сотрудников, поддавшись на уговоры эксперта, совершили потенциально опасные действия.

Второе тестирование тоже: сотрудники поверили легенде и охотно выполнили все, о чем их попросили.

А вот третье тестирование закончилось, не успев начаться. Уже на втором звонке легенда была раскрыта, сотрудник сказал, что дважды на одну удочку не попадется и оповестит о тестировании всех сотрудников, включая службу безопасности. Тестирование пришлось остановить.

Шок! Как так? Поиск ошибки начали с повторной проверки списка сотрудников, заявленных на каждое из трех тестирований. Совпадений нет. Потом проверили номера телефонов И вот он один номер телефона, только в первом тестировании он заявлен для Ивановой Анны Сергеевны, а в третьем для Петровой Анны Сергеевны (здесь и далее используются вымышленные имена). За время, прошедшее между тестированиями, девушка сменила фамилию.

В ходе первого тестирования Иванова Анна Сергеевна поверила в легенду и выполнила все действия, следуя указаниям эксперта, а вот Петрова Анна Сергеевна быстро поставила на место нерадивого эксперта.

Получается, что ошибка была допущена на этапе подготовки: эксперт проверил только фамилии сотрудников, но проигнорировал номера телефонов.

Что из этого можно вынести? На ошибках учатся, и теперь мы внимательнее проверяем списки сотрудников, по разным критериям, разрабатываем сценарии отхода, а эксперты делятся друг с другом своими ошибками на Вики-страницах, чтобы не повторять их.

Разбираем тренды уходящего года

Форматы социотехнического тестирования

Мы покажем сводную статистику по всем социотехническим тестированиям, которые мы провели в 2020 году, а также разберем кейсы наиболее интересных и показательных проектов.

В проектах использовались следующие форматы социотехнического тестирования:

рассылка фишинговых писем со ссылкой на поддельный ресурс 52%
рассылка фишинговых писем с исполняемым вложением 36%
телефонные звонки (вишинг) 12%

Самым результативным (отношение количества попавшихся к общему числу получателей) из представленных форматов стал вишинг 37%.

О высокой результативности вишинга знают не только эксперты по информационной безопасности, но и реальные злоумышленники, а также различные блогеры и репортеры. Ведь не просто так в последние годы количество вишинг-атак растет.

2020 год отметился настоящим бумом вишинга как в плане звонков от самих злоумышленников, так и в плане расследований СМИ. В этом году легенды вишинга стали более разнообразны и изобретательны: предложение медицинских и юридических услуг, звонки от лица сотрудника прокуратуры, и не стоит забывать о классике расследование подозрительного перевода банком (порядком приевшийся прием, но, к сожалению, все еще работающий).

Высокая результативность вишинга объясняется следующими моментами:

Заранее известна информация, которую нужно получить. Это позволяет сформировать сценарий разговора, проработать вопросы, которые надо задать для достижения цели. Есть возможность подготовить пути отхода, если собеседник начнет что-то подозревать.
Большой объем работ по сбору информации о сотрудниках и компании, которая используется для формирования легенды и сценария разговора. Например:

о сотрудниках: ФИО, номер мобильного телефона, добавочный номер, адрес корпоративной электронной почты, ник в телеграмме, отдел, в котором работает сотрудник, его должность, дата рождения и фото;

о компании: наименования подразделений и имена руководителей ключевых подразделений; используемые внутренние системы.
В разговоре используется информация, которая указывает на осведомленность эксперта во внутренних процессах компании; отсылки на распоряжения, якобы полученные от начальников структурных подразделений компании. Например:

Эксперт: Здравствуйте, Татьяна Игоревна! Звоню вам по просьбе руководителя Владимира Алексеевича Кузнецова. У нас произошел инцидент ИБ: по вашему пропуску сегодня через систему контроля управления доступом был зафиксирован проход в хранилище M.
Эксперт демонстрирует эмоциональную заинтересованность в сложившейся ситуации или схожие интересы, чтобы притупить внимание собеседника:

Эксперт: Вы пользуетесь ноутбуком только как рабочим компьютером или по каким-то еще личным делам?
Сотрудник: Ну, смотрю YouTube еще.
Эксперт: Да-да, я понимаю. Не переживайте. Просто возможно, что ваша доменная учетная запись была скомпрометирована и с ее помощью смогли пройти через СКУД.

Также следует помнить про внезапность звонка (человек может не понять, кто звонит) и возможность подмены номера. Таким образом, все перечисленные приемы позволяют увеличить доверие со стороны сотрудника и ослабить его бдительность.

Что касается диалогов выше, все они приведены из реального разговора, который состоялся в рамках проекта по вишингу. В кейсе 1 подробнее рассказываем про проект и его результаты.

Кейс 1

Цель: получить информацию разной степени критичности (компания определила информацию, которую считала конфиденциальной).
Легенда: сотрудника уведомляют об инциденте ИБ его пропуск использовали для несанкционированного прохода через СКУД в хранилище М. Служба безопасности расследует инцидент и звонит, чтобы узнать текущее местоположение пропуска, где находился пропуск в рабочее время, существуют ли альтернативные способы для прохождения СКУД. Звонят в нерабочее время (выходной день). Эксперт должен убедить сотрудника проверить доменную учетную запись на факт компрометации сотрудника просят аутентифицироваться на резервном портале (фишинговый ресурс).

Количество участников и инфраструктура под спойлером

Количество участников: 50 человек.
Инфраструктура: поддельный домен, поддельный корпоративный портал, который при вводе учетных данных перенаправлял сотрудника на оригинальный портал.

Вернемся к Татьяне Игоревне и информации, которую она предоставила за время разговора:

использует пропуск и специальный браслет для прохождения СКУД
пропуск и браслет находятся дома
использует корпоративную электронную почту дома
предоставила свои учетные данные, введя их на фишинговом ресурсе:

02.03.2020 13:48:25#0.2.0.2#ida****:rsa****55#Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 YaBrowser/19.3.1.828 Yowser/2.5 Safari/537.36

Компания остановила тестирование сотрудников после того как:

29 телефонных взаимодействий было нами произведено;
23 сотрудника раскрыли конфиденциальную информацию различного уровня критичности.

Как видно из примера, вишинг может использоваться не только для получения личной или конфиденциальной информации, но и для получения прямого доступа к инфраструктуре.

Какие могут быть результаты

Если сравнивать результативность рассылки фишинговых писем со ссылками на поддельный ресурс и писем с исполняемым вложением, то лидирует первый тип.

Один из ключевых факторов успеха в том, что рядовой сотрудник зачастую не разбирается в доменах, поддоменах и пр. Как следствие, он не видит разницы между portal-domain.ru и portal.domain.ru. Слова и порядок их употребления совпадают и там, и там, а вот символов можно пропустить по невнимательности или в спешке.

В свою очередь, рассылка фишинговых писем с исполняемым вложением предполагает большую вовлеченность со стороны сотрудников, поэтому данный формат тестирования показывает наименьшую результативность.

Однако сотрудники, открывшие вредоносные вложения, чаще вступают в переписку с экспертами, чем при работе с фишинговым ресурсом. Это позволяет эксперту продолжать воздействие для достижения своих целей.

Например, в попытке спасти якобы утерянные данные об отпусках сотрудники присылали не только свой график отпуска, но и файл на весь отдел, а там тысячи сотрудников со всеми данными и структура компании.

Также сотрудники часто пересылают письма своим коллегам.

Кейс 2

Цель: оценить осведомленность сотрудников в вопросах информационной безопасности.
Легенда: ознакомиться с новой системой премирования. К письму прилагался документ Премии.xls.

Количество участников и инфраструктура под спойлером

Количество участников: 75 человек.
Инфраструктура: поддельный домен, поддельный почтовый адрес (якобы принадлежащий отделу по работе с персоналом), вредоносная нагрузка, которая выполнялась в ОС удаленного компьютера, обеспечивала соединение с ним и собирала данные о конфигурации ОС.

За время тестирования удалось успешно подключиться к компьютерам 11 сотрудников (14% участников). Столкнувшись якобы с проблемой в работе документа, сотрудники вступали в переписку с экспертами в том числе и не заявленные в тестировании сотрудники.

Пример одной из таких переписок ниже:

В итоге сотрудник прислал ответное письмо, которое содержало скриншот рабочего стола.

Окей, возвращаемся к тенденциям

В 2020-м стали чаще появляться новости о том, что злоумышленники используют фишинг и вишинг в рамках одной атаки. К примеру, в начале декабря сообщалось, что злоумышленники рассылают уведомления о долгах за ЖКУ в размере 1020 тысяч рублей, которые якобы появились за время карантина, и просят оплатить поддельные квитанции онлайн.

Если человек проигнорировал письмо ему звонили от имени сотрудника управляющей компании для проверки ранее совершенных платежей. Преступники убеждали, что долг по квартплате есть, и узнавали способы оплаты и реквизиты карты, которая использовалась для платежа, а затем предлагали сделать пробную транзакцию и сообщить им код из SMS.

Для нас это не было новостью, и к тому моменту мы уже опробовали подобную схему на некоторых проектах: сначала рассылали сотрудникам фишинговые письма, а в случае низкого отклика звонили и в ходе разговора провоцировали сотрудника открыть файл или перейти по ссылке и выполнить действия, указанные в письме, или узнавали, почему он отказался выполнять инструкцию.

В результате сотрудники, которые изначально не хотели переходить по ссылке или не были заинтересованы в предлагаемой акции, меняли отношение к нашему фишинговому письму и, поддавшись на уговоры эксперта, делали то, что угрожало безопасности компании.

Таким образом, проекты, в которых одновременно использовались фишинг и вишинг, оказались более результативными, чем те, где использовался только фишинг. Сотрудники, которые подозревали, что проводится тестирование, меняли свое мнение, верили в легитимность писем и охотно шли на контакт с экспертами.

Примечание: для построения третьей диаграммы использовались общие результаты тестирования в формате фишинговых рассылок, дополняемые вишинг-активностью.

Легенды

Следует отметить, что при разработке легенды учитывается сфера деятельности компании и основной вид деятельности тестируемых сотрудников, но в основе всегда лежит сильная эмоция, которая притупляет внимание и провоцирует на необдуманные действия: жадность, любопытство, страх, доверчивость.

Ниже представлены основные примеры легенд:

Изменение в графике работы
Изменение в IT-системах
Система премирования
Скидки и бонусы
События в компании

Самой результативной легендой было информирование об изменениях в системе премирования.

Кроме того, упоминание легитимного сервиса, используемого многими компаниями, такого как Office 365, повышает доверие сотрудника. Такой подход часто используют реальные злоумышленники для проведения социотехнических атак.

Реалии 2020-го привнесли новое веяние в легенды социотехнического тестирования, да и реальных атак тоже. На первый план вышла коронавирусная инфекция и все, что с ней связано.

Когда коронавирус только начинался, компании просили не использовать его в качестве легенды, поскольку отсылка к столь актуальной теме гарантировала высокую результативность и негативно сказывалась на настроении сотрудников. Мы отвечали, что реальные злоумышленники не так этичны и активно используют эту легенду с начала пандемии, но получали категорический отказ. В результате табу на использование COVID-19 было снято с введением новых ограничительных мер осенью. Возможно, именно в этот момент компании осознали, что коронавирус с нами надолго и его игнорирование может привести к рискам.

Первый же проект с COVID-19 продемонстрировал неослабевающий интерес людей к данной тем и, как следствие, больше половины участников тестирования выполнили потенциально опасные действия.

Пожалуйста, прислушивайтесь к экспертам при выборе легенд.

Кейс 3

Цель: оценить осведомленность сотрудников в вопросах информационной безопасности.
Легенда: проверить сервис удаленного доступа, поскольку сотрудники переходят на удаленную работу из-за COVID-19. Для проверки доступа надо ввести учетные данные от рабочего компьютера на фишинговой странице, которая копировала страницу входа на VPN-портал.

Количество участников и инфраструктура под спойлером

Количество участников: 150 человек.
Инфраструктура: поддельный домен, поддельный почтовый адрес (якобы принадлежащий ИТ-отделу), поддельная страница входа на VPN-портал.

Пример письма для рассылки:

Мы получили следующие результаты:

Нужно больше тестирований или что будет в периоде

Каждая подобная статья заканчивается списком рекомендаций, которые позволят повысить осведомленность сотрудников в вопросах информационной безопасности.

К примеру, проверять источник письма или путь, по которому ведет ссылка. В целом, разумная рекомендация, но на практике не всегда работает. Вот смотрите: сотрудник, который получает 15 писем в день (возможно, среди читателей найдутся те, кто мечтает получать *всего* 15 писем в день), а чтение и участие в переписке не его основной вид деятельности, не будет до буквы, до знака проверять адрес отправителя или сверять его ФИО с корпоративным списком контактов.

Он увидит знакомый набор символов (самое время вспомнить про portal-domain.ru и portal.domain.ru), а должность отправителя и тема письма определят, в какую очередь он ответит на письмо. Возможно, ответная реакция на фишинговое письмо случится не сразу, но в свое время ссылка будет открыта, а исполняемое вложение запущено.

Еще одна типичная рекомендация регулярные тестирования персонала. Это замечательно, но тоже не всегда работает. Почему смотрите в кейсе 4.

Кейс 4

Компания М время от времени организовывала социотехническое тестирование своих сотрудников. Какого-то ощутимого прогресса в знаниях основ информационной безопасности не наблюдалось: сотрудники продолжали переходить по ссылкам, вступать в переписку и выполнять просьбы.

Чтобы продемонстрировать, что положительная динамика возможна только при регулярном тестировании, решили провести четыре социотехнических тестирования в течение года (в начале каждого квартала). Все тестирования проводились в одном формате, но под разными легендами, а участвовали в них сотрудники одного подразделения.

Результат регулярного тестирования оказался таким же, как и у нерегулярного: сотрудники переходили по ссылкам, вступали в переписку и раскрывали конфиденциальную информацию. Результативность отдельного тестирования в большей степени определялась актуальностью легенды. В 3 квартале легенда с COVID-19 заставила людей забыть о тренингах, наставлениях и рекомендациях.

Даже сотрудники с достаточными знаниями, умеющие распознавать атаки социальной инженерии, склонны проявлять халатное отношение к социотехническому тестированию: раз это очередной тест, то нет ничего страшного, если написать все, что думаешь по этому поводу. Вот только где уверенность, что это не реальная атака?

Кейс 5

В этом примере демонстрируем, как выявленное на ранних этапах социотехническое тестирование оказалось результативным только из-за того, что сотрудники, распознавшие тестирование, не оповестили о нем коллег.

Цель: получить валидные учетные данные сотрудников.
Легенда: проверить наличие доступа к новому корпоративному порталу.

Количество участников и инфраструктура под спойлером

Количество участников: 200 человек.
Инфраструктура: поддельный домен, поддельный почтовый адрес (якобы принадлежащий отделу техподдержки), поддельный корпоративный портал, который при вводе учетных данных перенаправлял сотрудника на оригинальный портал.

Активная фаза социотехнического тестирования началась 11 февраля 2020 года в 13:30 (МСК).

Первые учетные данные мы получили через 4 минуты:

Дата и время	IP-адрес / MAC-адрес	Введенные логин и пароль	Общая информация о конфигурации рабочей станции
11.02.2020 13:34	0.0.0.1	ni*******a:V****v	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36
11.02.2020 13:34	0.0.0.6	mi**a:2****aB3	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15

Примерно через 30 минут после начала тестирования получили данные, явно указывающие, что легенда раскрыта и сотрудники либо догадались о проводимом тестировании, либо заподозрили атаку: вместо учетных данных в логах собиралась ненормативная лексика.

Дата и время	IP-адрес / MAC-адрес	Введенные логин и пароль	Общая информация о конфигурации рабочей станции
11.02.2020 14:02	0.0.0.71	Idi * sobaka:ahahhahaha	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36

Судя по полученным результатам (IP-адрес и информация о рабочей станции), мы подозревали, что это администратор. К этому моменту получили уже 37 учетных данных. Цель достигнута!

Тестирование можно сворачивать и садиться за отчет, но сотрудники продолжали вводить учетные данные. Последний ввод данных был зафиксирован 17 февраля. Следовательно, сотрудники, распознавшие тестирование (или атаку), не предупредили об этом своих коллег.

Дата и время	IP-адрес / MAC-адрес	Введенные логин и пароль	Общая информация о конфигурации рабочей станции
17.02.2020 14:08	0.0.0.55	Ty******v:T********rah	Mozilla/5.0 (iPhone; CPU iPhone OS 12_1_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1

Всего получили 76 уникальных учетных данных. Валидность каждой пары была подтверждена.

Подобное поведение показывает, что сотрудники не до конца понимают, как себя вести при выявлении социотехнической атаки. Важно научить не только распознавать социотехнические атаки, но и правильно на них реагировать.

В случае распознавания атаки или социотехнического тестирования сотрудник не должен идти на контакт со злоумышленником (или экспертом) ни при каком условии и должен немедленно оповестить ответственных за информационную безопасность.

Итоги, проблемы и рекомендации

Наверное, уже пора заканчивать со всеми этими рассказами и историями.

Может показаться, что конец какой-то пессимистичный (какой год такой и конец): сотрудники необучаемы, рассеяны и бизнес все еще в опасности.

На самом деле все не так плохо и не стоит отчаиваться. Обращайтесь к экспертам в области практической безопасности они расскажут об актуальных тенденциях в социотехнических атаках, порекомендуют лучший именно для вас формат тестирования.

Также не забывайте о простых правилах цифровой гигиены и рекомендациях по повышению осведомленности в ИБ.

Мы уже говорили, что в интернете достаточно статей о социотехническом тестировании (такая есть и у нас), а также статей с рекомендациями по повышению защиты. Поэтому хотим в очередной раз просто напомнить, что здесь нужен комплексный подход, а значит следует помнить о:

регулярном обучении и опросе сотрудников
понятной поставке материалов и гайдов (Вики-страницы, видео и т.п.)
обязательной двухфакторной аутентификации
разграничении доступа и минимизации прав пользователей
хорошей фильтрации электронной почты
средствах защиты от целенаправленных атак

Возвращаясь к основному вопросу: что же выбрать в 2021-м?

Мы решили оставить его на размышление вам. Рекомендуем попробовать фишинг + вишинг или только вишинг. Поможет сотрудникам не только в корпоративной среде, но и при подобных атаках в нерабочей обстановке.

Главное, про что стоит помнить: обучение и социотехнические тестирования должны быть направлены на формирование культуры поведения, которая позволит своевременно выявлять и эффективно реагировать на различные атаки.

Стоит сместить фокус с заучивания обязательных действий по обнаружению социотехнических атак на объяснение, почему их должен выполнять каждый сотрудник в компании. Без осознанного подхода к информационной безопасности со стороны сотрудников ни одна обучающая программа не сработает.

Подробнее..

Категории: Информационная безопасность , Pentest , It-компании , Исследования и прогнозы в it , Cybersecurity , Кибербезопасность , Блог компании group-ib , Социальная инженерия , Пентест , Information security , Penetration testing , Обучение сотрудников , Тест на проникновение , Social engineering

Препарируем Compound File Binary format (CFB), или начинаем парсить DOC

11.01.2021 10:24:00 |

Автор: admin

Compound File это довольно сложный универсальный бинарный формат файлов, лежащий в основе форматов офисных документов до MS Office 2007 (doc, xls, ppt, msg, ), отчасти MS Office 2007+ (например vbaProject.bin внутри xlsm) и других.
Под катом краткое описание как Compound File устроен внутри, которое, надеюсь, будет полезно как ликбез и поможет читателю лучше понимать что делают утилиты или про что пишут в статьях про CFB файлы.

Устройтсво CFB файла сильно напоминает устройство диска с FAT. Логически CFB хранит древовидную структуру объектов, подобную файловой системе с директориями (тип объекта в CFB STORE) и файлами (в CFB STREAM). Каждый объект имеет имя.
Весь файл разбит на сектора размером 512 байт для v3 и 4096 байт для v4. Это, на мой взгляд, главная разница между v3 и v4. Дальше цифры для примеров я буду приводить для v3 (и в скобках для v4). В начальном секторе хранится заголовок файла и начало таблицы DIFAT (см. ниже). Значение содержимого других секторов определяется динамически по таблицам DIFAT и FAT (да, она прям так и называется, как в файловой системе), фиксированных значений сектор n содержит информацию типа t больше нет.
Всего максимум может быть 0xFFFFFFFA секторов. Номера секторов больше 0xFFFFFFFA являются маркерами и фактически ни на какой сектор не указывают. Например 0xFFFFFFFE (EndOfChain) означает, что текущий сектор последний в списке.

DIFAT

DIFAT Double Indirection File Access Table. Это массив 4х байтных номеров секторов, в которых находится FAT. Первые 109 записей хранятся в первом секторе файла (пять из них выделены жёлтым внизу КДПВ). Если файл больше 6.8 Мбайт (436 Мбайт для v4), то следующие сектора DIFAT хранятся как односвязный список. Номер первого сектора из этого списка хранится в заголовке. В кажом из этих секторов хранится 127 (1023) указателей на сектора с FAT, а в последних 4х байтах номер следующего сектора DIFAT.

FAT

FAT File Access Table. Это массив из 4х байтных значений. Работает так же, как в одноимённой файловой системе. Каждому сектору в файле (кроме заголовочного) соответствует 4х байтное значение в FAT.
Для чтения потока данных (STREAM) нужно знать длину потока (в байтах) и номер первого сектора этого потока. Номер следующего сектора всегда записан в элементе FAT, соответствующем текущему сектору. В элементе FAT, соответствующем последнему сектору в потоке, будет записано значение 0xFFFFFFFE (EndOfChain).

Пример цепочки в FAT

Если данные в потоке записаны в 3 сектора: 0, 1 и 4, то в FAT будут записаны такие значения: 1, 4, x, x, 0xFFFFFFFE (где x какое-то значение, к данному потоку отношения не имеющее).
Для чтения этого потока мы читает данные из сектора 0, расположенного сразу после заголовка файла (сам заголовочный сектор имеет номер -1), читаем номер следующего сектора из FAT[0] = 1, читаем данные из сектора 1 и номер следующего сектора из FAT[1] = 4, читаем данные из сектора 4 и в FAT[4] видим что это последний сектор этого потока (EndOfChain).

MiniStream и MiniFAT

В принципе описанного выше достаточно для хранения данных, но в CFB предусмотрена ещё оптимизация для хранения коротких потоков данных меньше 4096 байт.
При хранении потока данных, длина которого не кратна длине сектора, в последнем секторе остаётся некоторое количество неиспользуемых байт. Чем больше сектор тем больше таких байт в среднем остаётся. Для борьбы с этой проблемой все небольшие (меньше 4096 байт) потоки данных хранятся не в обычных секторах по 512 (4096) байт и FAT, а в отдельном потоке, разбитом на сектора по 64 байта. Этот поток называется MiniStream, а информация для сцепления его секторов в потоки хранится в MiniFAT. Работает это всё совершенно аналогично основной FAT.
И MiniFAT, и MiniStream хранятся как обычные (не Mini) потоки данных. Номер первого сектора и длина MiniFAT хранятся в заголовке, а информация о MiniStream в объекте Root Entry (логической причины хранить именно там не вижу).
Получается такая матрёшка: файл разделён на 512 (4096) байтные сектора, а один из потоков, состоящих из этих секторов, рассматривается как последовательность 64 байтных секторов, и в нём уже хранятся мини потоки данных.
Откуда читать поток данных: из большой FAT или из MiniStream, определяется только по его размеру (меньше 4096 из MiniStream, иначе как обычный поток).

Где же текст/картинка/таблица/макрос?

CFB используется как хранилище, позволяющее сохранить данные разных приложений в одном файле. Если вы хотите докопаться до человекочитаемых данных, то надо парсить потоки данных, извлечённые из CFB, в соответствии с форматом данных приложения. Эта тема выходит за пределы данной статьи (но см. ссылки).

Выводы

По идее такая структура файла была разработана для ускорения внесения отдельных изменений в файл без его полной перезаписи. Не думаю, что это свойство ценно сейчас для обычных офисных документов размером несколько мегабайт.
В общем структура файла CFB просто кладезь для стеганографии, основанной на формате файла. Т. е. сделать совершенно корректный файл, который при открытии в ворде покажет Hello world, а внутри будет ещё много, которые правильный парсер будет считать просто мусором вообще не проблема.
С другой стороны огромный простор для ошибок, путаницы и т.п., огромное количество избыточных записей. Например, можно зациклить цепочку секторов, образующую поток. Наивный парсер при чтении такого файла зависнет.
P.S. Файлы MS Office 2007 и старше (docx, xlsx, pptx, docm,) имеют совершенно другой формат. Внутри там тоже дерево директорий, только вместо CFB там используется ZIP (да, их можно прям раззиповать). Однако макросы, например, хранятся внутри документа в файле vbaProject.bin, который является Compound файлом.

Ссылки

Сам CFB очень хорошо (на мой взгляд) документирован: [MS-CFB]: Compound File Binary File Format
[MS-DOC]: Word (.doc) Binary File Format для тех, кто хочет полноценно разобрать doc.
[MS-OVBA]: Office VBA File Format Structure о том, как хранятся макросы, в том числе в Office 2007+ (docm, xlsm, ...)
Ещё пара статей на Хабре про парсинг DOC от Rembish:
Текст любой ценой: WCBFF и DOC и Текст любой ценой: Miette
Для практического анализа файлов MS Office (как до 2007 Офиса, так и после), в том числе подозрительных, рекомендую набор утилит OleTools. Их можно использовать и как отдельные программы, и как модули Python.
Ещё полезный набор утилит OleDump
CFB extractor, появившийся в процессе написания этой статьи. Из полезного умеет доставать из CFB файла все потоки данных (включая потоки, не имеющие соответствующей записи в директории).

Подробнее..

Категории: Информационная безопасность , Ctf , Information security , Infosec , Doc , Ms office , Cfb , Compound file binary format , Compound files , Xls , Msg

Пентестеры Ведьмаки мира ИТ

26.01.2021 14:17:08 |

Автор: admin

Вы замечали, что мир IT очень огромен, но при этом в нем как будто нет места для ИБ, несмотря на то, что довольно много, а порой критично много на самом деле нуждающихся в нём?

Многие сейчас создают, развивают продукты, но очень мало кто хочет платить за их безопасность, люди искоса смотрят на такое решение, ведь многие - в основном, конечно, бизнесмены - не хотят и не готовы платить за то, что не принесет им деньги впоследствии, а потенциал "не потерять" для них, по всей видимости, не звучит громко.

Под катом я хотел бы сравнить и провести параллель ( пусть, быть может, местами, это может казаться утрированно) между ведьмаками и пентестерами ( ведьмаками из мира IT).

По моим наблюдениям, мир ИТ сейчас устроен так, что кругом создается все больше сервисов, больше устройств, больше технологий - следовательно больше затрат cо стороны пользоватей, при этом , внедряя все больше, как правило, платных, подписок и платных возможностей ( в том числе расширенных ), и многие при этом, думая лишь о прибыли, забывают думать о защите.

Основные причины - не рассчитали бюджет на это или же целенаправленно забили на безопасность а-ля "и так сойдет", "да кому мы нужны".

При этом так же бывают случаи, когда не рассчитали время : У тебя есть определенные обязанности перед инвесторами или же начальством и тебе обязательно нужно уложиться в сроки.

Это удается немногим, но ,уложившись в сроки, люди в итоге успевают выпускают , "как есть" , обычно поставив безопасность на последнее место - сделав лишь самый основной функционал, не успев его должным образом протестировать - но это серьезный просчет, ведь всегда присутствует человеческий фактор, нельзя не учитывать сонных , уставших программистов , допустивших ( что , в принципе, не звучит так уж сверхъествественно ) , ошибку(-и) в огромном количестве программного кода.

И это только если не считать дефолтных качеств самих программистов - порой , происходит серьезная халтура, когда бюджет попросту "пилят" - происходит это так:

Выделяется бюджет на тестирование, очень приличный кусок от изначальной цены отламывают и кладут себе в карманы, а оставшееся уже готовы потратить на это самое тестирование.
Ищут за оставшуюся цену специалистов в иб.
Обычно все же находятся те, кто принимают за эту сумму проведение работ, но сами тем временем ищут тех, кто бы сделал эту работу за меньшую сумму, с учетом того, что те потом сами допишут определенные пункты ТЗ.
Эта цепочка движется вниз до тех пор, пока не дойдет до студентов, которые еще вчера "работали за еду" и им бы не помешала практика.
В итоге цепочка движется обратно вверх, где каждый на звено выше дописывает что-то от себя.
Как результат, в руки заказчику возвращается отчет низкого качества, в чем, собственно, они сами и виноваты.

Что касается добросовестных программистов-разработчиков, они на то и разработчики, чтобы именно разрабатывать продукты, а не защищать их.

Да, можно придерживаться принципов безопасной разработки, но никто не заменит полноценную работу пентестера.

Некоторые компании , разрабатывающие инструменты для автоматизации проведения пентеста признают, что хоть инструменты могут выручать, но живую работу пентестера нельзя заменить нечем, а пентестер , вооруженный этими самыми инструментами становится еще мощнее.

Но некоторые этого до сих пор не понимают, всегда необходимы специализированные профессионалы своего дела, эксперты в области иб, "особый отряд" - пентестеры.

Теперь же поговорим о терминологии.

К пентестерам мы вернемся после описания Ведьмаков, которые тоже представляют собой "особый отряд".

Терминология

Кто такие ведьмаки?

Ведьмаки вымышленные персонажи из вселенной "Ведьмака" Анджея Сапковского, мутанты со сверхъестественными способностями, прошедшие специальную подготовку, чтобы стать профессиональными истребителями чудовищ по найму.

Считается, что у ведьмаков нет эмоций, хотя это и не совсем так. За последние годы каста ведьмаков сократилась до горстки действующих охотников; столь мало их осталось, что мир начинает напоминать времена, когда их и вовсе не было.

Имунны ко всем болезням и токсинам, объясняется тем, что перед боем ведьмаки принимают токсичные эликсиры, усиливающие их способности на некоторое время, в то время как обычный человек может не перенести эффекта и умереть.

То есть -в общепризнанном смыслеведьмак это профессия. Обычно под этим словом подразумевают наемных охотников на монстров, однако не любых представителей этого ремесла, а прошедших через ряд мутаций и изменений организма, которые делают ведьмаковсверхлюдьми, обладающими невероятными физическими возможностями. Именно эти данные позволяют им быть как нельзя более приспособленными к охоте на различных тварей и существ, и таким образом быть куда эффективнее любых конкурентов.

Отслеживание монстров v.1

Главного харизматичного героя - Геральта из Ривии вы можете знать, как минимум по одной из лучших игр десятилетия - "Ведьмак 3 : Дикая Охота".

Геральт из Ривии

Пентестеры

Пентестеры - особый "отряд" людей, специально обученный и прошедший подготовку, чтобы стать профессиональными истребителями "чудовищ" - проблем (уязвимостей) в IT.

Считается, что у пентестеров ( читай "хакеров") нет эмоций, что это суровые "компьютерщики" хотя это и не совсем так. За последние годы каста безопасников тоже сократилась до горстки действующих охотников; столь мало их осталось, что мир начинает напоминать времена, когда их и вовсе не было - особенно в России.

Имунны ко всем болезням и токсинам, объясняется тем, что перед боем пентестеры принимают токсичные эликсиры ( большое количество энергетиков, в том числе - кофе ), усиливающие их способности на некоторое время, в то время как обычный человек может не перенести такого количества и соответствующего ему эффекта и умереть.

То есть -в общепризнанном смыслепентестер это профессия. Обычно под этим словом подразумевают наемных охотников на уязвимости и баги, однако не любых представителей этого ремесла, а прошедших через боевую закалку и опыт, и изменений организма, которые делают пентестеровсверхлюдьми, обладающими невероятными физическими возможностями.

А именно эти данные позволяют им выдерживать нагрузку на сердце и быть как нельзя более приспособленными к охоте на различных тварей и существ (вирусы и баги ), и таким образом быть куда эффективнее любых конкурентов - программистов с каким-то уклоном в ИБ.

Отслеживание "монстров" v.2

"Типичный" пентестер

Помимо этих сходств, ведьмаки, как и пентестеры, сталкиваются с недовольством тех, кто их нанял, а иногда и просто встречными прохожими.

На ведьмаков, как и на хакеров смотрят , как на какую-то отдельную касту людей , где те
"не такие ,как все", и иногда даже опасаются.

Порой, ведьмак , гуляя по городу может услышать от "необразованных" в свою сторону "мутант, выродок".

Скриншот из игры Ведьмак 3 : Дикая Охота

Пентестер (он же хакер), может услышать - все от тех же "необразованных" - фрик, задрот.

Обоим в "бою" не обойтись без светящейся в темноте "волшебной" штуковины.

Те же, кто "образован" и "в курсе" наоборот, относятся с уважением и почётом, что в мире ведьмака к самим ведьмакам, что в нашем мире IT - к пентестерам, и уважают их ремесло.

Ведьмакам , после убийства ими чудовища на заказ могут сыпаться предъявы, начиная попытками урезать плату за заказ, осознанной заменой на более дешевую плату, заканчивая полным отказом платить, ссылаясь на разные , порой абсурдные причины, за которыми, конечно же, скрывается понесение ущерба репутации и нежелание признавать свой проигрыш.

Пентестеров тоже не любят, тоже порой хотят урезать плату , осознанно заменить плату на более дешевую или не платить вовсе, ссылаясь на разные, порой абсурдные причины, а так же пытаются заткнуть (1, 2) - ибо не хотят нести репутационный ущерб.

Такое порой нередко встречается , что не всегда, даже тем, кто все правильно сделал, не выплачивают награду за найденные баги и уязвимости по программе bugbounty.

Порой с этих слов состоят многие интро к рассказам на различных конференциях , таких как, например, ZeroNights.

Багбаунти

Кстати о багбаунти, в мире IТ это платформа , где , в каком -то смысле "висит" заказ на убийство за которое полагается награда, но для начала это "чудовище" нужно выследить, может даже выманить и затем устранить, но по умолчанию предполагается, что оно есть, так как жителям оно где-то время от времени мешает спокойно жить.

В Ведьмаке 3 Дикая Охота эту функцию просто выполняет доска объявлений.

Ведьмаки, как и пентестеры, как было сказано ранее, созданы для того, чтобы выполнять задачи , с которыми не способны справиться обычные воины и подготовленные рыцари, не смотря на свои силы.

Так же , обучение пентесту, как и обучение в ведьмачьих школах терпит раскол - при обычных обстоятельствах ты не найдешь возможности этого сделать, единственная возможность - делать это подпольно ( онлайн/оффлайн -курсы ) или же тебя настигает судьба самоучки, никакие вузы и школы не предоставят вам в полной мере всех возможностей для становления "элитным убийцей".

К чему же это я это все?..

Во вселенной Ведьмака, само становление ведьмаком требовало адских мук, через которые способны были пройти лишь единицы, что все таки, в последствии, окупало себя в полной мере - никто не мог выполнять работу лучше.

Вот только было множество пренебрежений к работе ведьмаков , что выражалось в неуважении и, пониженной , по меркам рынка , заработной плате со стороны нанимателей и простых жителей привели к упадку ведьмачьих школ, это не считая многих других нюансов и неудобств, которых им приходилось терпеть.

Там жители считали, мол чудовищ осталось не так много и оставшееся количество ведьмаков справится - но на самом деле ошибались, ведь чудовищ много и все они будут продолжать плодиться ( а с чего бы нет? ), быть может, создавая новые виды, а ведьмаки , хоть и сверхбойцы, но все же смертны, а создание новых бойцов либо идет очень медленно в подполье, либо отсутствует вовсе.

С той же проблемой мы сталкиваемся и в реальной жизни. Плохая гигиена в сфере ИБ, пренебрежение, неуважение по отношению к пентестерам, отсутствие качественных курсов(встречаю очень много воды), качественного обучения (многих интересует не желание научить, а лишь коммерция - проводить уроков как можно больше, рассказывая минимально, чтобы растянуть период на подольше и , следовательно, вытащить денег побольше) , а так же отсутствие его вовсе - ведет к вымиранию качественных проведений тестов на проникновение, качественных продуктов.

А ведь на кону наша с вами жизнь и наши персональные данные, если продолжить в том же духе - в будущем защищать страну будет некому.

В мире ведьмака эту проблему никто не собирается исправлять, но мы - еще можем попытаться это изменить.

Подробнее..

Категории: Информационная безопасность , Pentest , Карьера в it-индустрии , Будущее здесь , Игры и игровые приставки , Терминология it , It , Information security , Penetration testing , Future , Witcher , Pentesters , Warning

Kremlin RATs история одной мистификации

15.02.2021 12:06:03 |

Автор: admin

Этим постом мы начинаем двухсерийный технодетектив, в котором встретились "священная триада" доменов: putin, kremlin, crimea и "крысы" программы удаленного доступа (RAT), а также шпион AgentTesla. Началась история с того, что в конце мая 2020 года сетевой граф Group-IB, наша автоматизированная система анализа инфраструктуры, начал детектировать домены с интересным паттерном *kremlin*.duckdns.org, к которым подключались различные вредоносные файлы. Аналитики Group-IB Threat Intelligence & Attribution исследовали эти домены и установили три кампании по распространению различных RAT. Они шли с 2019 года и были нацелены на пользователей из Польши, Турции, Италии, Украины, России, Казахстана, Болгарии, Беларуси, Греции и Чехии. В ходе расследования была установлена связь между обнаруженными доменами и остальной используемой инфраструктурой, а заодно и с конкретным человеком, который стоит за распространением AgentTesla и других вредоносных программ. Итак, обо всем по-порядку.

Кампания лета 2020 года

В начале список доменов, который привлёк наше внимание, выглядел так:

crimea-kremlin.duckdns.org
kremlin-afghan.duckdns.org
kremlin-crimea.duckdns.org
kremlin-turbo.duckdns.org

Данные домены были зарегистрированы на один IP-адрес 79.134.225.43 15 июня 2020 года. По данным сетевого графа Group-IB, только с этими четырьмя доменами связанно порядка 30 различных вредоносных файлов. Судя по документам-приманкам, данная кампания была нацелена на пользователей из Польши, Турции, Италии, Германии и Болгарии.

Связанная инфраструктура

Дальнейший анализ показал, что в основном файлы были залиты в публичные источники, начиная с 25 июня 2020 года. Самые распространенные имена Potwierdzenie transakcji.xls, lem makbuzu, WACKER - 000160847.xls, Potwierdzenie operacji.xls. Один из таких файлов, SHA1: 95A6A416F682A9D254E76EC38ADE01CE241B3366, является документом-приманкой на польском языке и якобы отправлен от Bank Polski.

Изображения документа-приманки SHA1: 95A6A416F682A9D254E76EC38ADE01CE241B3366

Заражение

После активации макросов в этом документе выполняется PS-скрипт для извлечения команды второго этапа из файла lab.jpg, размещенном на удаленном сервере:

Исполняемый PS-скрипт из макроса

В файле lab.jpg содержится обфусцированная в BASE64 команда, которая после декодирования выглядит следующим образом:

Деобфусцированное содержимое lab.jpg

Данный код считывает содержимое файла http://officeservicecorp[.]biz/rnp.txt, в котором и находится полезная нагрузка.

В результате выполнения данной последовательности PS-скриптов загружается и выполняется популярный NetWire RAT, который и производит подключение к своему C&C-серверу kremlin-crimea[.]duckdns.org на порт 3396.

Конфигурация NetWire RAT

Действительно, если мы вставим изначальные домены в граф с шагом 2, то увидим не только эти домены, но и остальную связанную инфраструктуру, которая участвовала во всех стадиях заражения.

Граф с шагом 2. Связанная инфраструктура

Интересно, что те файлы, которые подключались к office-service-tech[.]info, также производили сетевое подключение к ahjuric[.]si. Пример таких файлов SHA1 a3816c37d0fbe26a87d1cc7beff91ce5816039e7. Это документ-приманка на турецком языке с логотипом государственного банка Турции.

Документ-приманка на пользователей Турции. SHA1: a3816c37d0fbe26a87d1cc7beff91ce5816039e7

Данный документ также содержит вредоносный макрос, исполняющий PS-скрипт, который считывает Code.txt с удаленного сервера и запускает цепочку обфусцированных PS-скриптов.

Исполняемый PS-скрипт из макроса

Содержимое ahjuric[.]si/code.txt

Результатом выполнения обфусцированного PS-скрипта будет выполнение еще одного обфусцированного в Base64 скрипта, который в конечном счете и выполнит полезную нагрузку в виде Netwire Rat из office-service-tech[.]info/pld.txt.

Содержимое office-service-tech[.]info/pld.txt

C&C-сервером данного образца является crimea-kremlin.duckdns[.]org.

Также мы обнаружили файлы, которые производят сетевое подключение одновременно к kremlin-turbo.duckdns[.]org и wshsoft[.]company. Название домена относит нас к WSH RAT, который основан на коде Houdini. Один из таких файлов SHA1: b42a3b8c6d53a28a2dc84042d95ce9ca6e09cbcf. Данный образец RAT отправляет на C&C-сервер kremlin-turbo.duckdns[.]org:3397 запросы вида /is-ready, а в качестве UA у него указан WSHRAT.

Сетевые запросы файла SHA1: b42a3b8c6d53a28a2dc84042d95ce9ca6e09cbcf

На этом этапе важно отметить, что часть используемых доменов в этой кампании была зарегистрирована на почту tetragulf@yahoo.com.

Кампания весны 2020 года

Изучая всю остальную связанную инфраструктуру, мы обратили внимание на домены, зарегистрированные на asetonly@yahoo.com. С начала 2020 года на эту почту были зарегистрированы следующие домены:

nitro-malwrhunterteams.com
office-data-labs.com
putin-malwrhunterteams.com
kremlin-malwrhunterteam.info
skidware-malwrhunterteams.com
screw-malwrhunterteams.com
screw-malwrhunterteam.com
office-services-labs.com
office-cloud-reserve.com
office-clean-index.com
office-cleaner-indexes.com

Мы собрали более 130 различных образцов вредоносных программ из различных источников, связанных только с этими доменами. Судя по названиям и содержимому данных образцов, кампания весны 2020 года была нацелена на пользователей из Европы и стран СНГ мы обнаружили документы-приманки на украинском, белорусском, казахском, русском и греческом языках.

Первые файлы данной кампании были загружены на публичные песочницы 23 марта 2020 года. Один из таких файлов Аналз проекту.docx SHA1-d8826efc7c0865c873330a25d805c95c9e64ad05 распространялся в качестве вложения к письму Електронна розсилка_ Змнене замовлення.eml SHA1-7f1fdf605e00323c055341919173a7448e3641fb, которое было загружено на VirusTotal через веб-интерфейс из Украины.

Содержимое письма Електронна розсилка_ Змнене замовлення.eml

Заражение

Содержимое самого документа не вызывает интереса и выглядит как отсканированный лист со счетом. Однако сам документ во время запуска эксплуатирует уязвимость CVE-2017-0199. В результате выполняется команда, которая загружает полезную нагрузку в виде http://office-cloud-reserve[.]com/hydro.exe.

Исполняемый PS-скрипт

Загружаемой полезной нагрузкой является программа-шпион AgentTesla (почитать о ней вы можете тут, тут и тут). В качестве сервера для эксфильтрации данных используется ftp.centredebeautenellycettier[.]fr легитимный домен, который, по всей видимости, был скомпрометирован.

Установка FTP-соединения.

Другой исследуемый файл SHA1- 19324fc16f99a92e737660c4737a41df044ecc54, который называется Байланыс орталытары.img, распространялся в качестве вложения через электронное письмо SHA1- 403c0f9a210f917e88d20d97392d9b1b14cbe310 на казахском языке c темой, относящейся к COVID-19.

Содержимое письма 403c0f9a210f917e88d20d97392d9b1b14cbe310

Данное вложение является .iso-образом и в некоторых случаях называется Байланыс орталытары.img. Файл монтируется в систему как образ, в котором находится лишь один обфусцированный VBS-файл SHA1: fd274f57e59c8ae3e69e0a4eb59a06ee8fd74f91 под названием Денсаулы сатау бойынша анытамалы жне деректер базасы.vbs. Данный файл по сути является загрузчиком, который выполняет обфусцированный PS-код. При его открытии происходит считывание файла http://office-cleaner-indexes[.]com/loud.jpg.

Содержимое сбрасываемого файла SHA1:fd274f57e59c8ae3e69e0a4eb59a06ee8fd74f91

В результате происходит загрузка и выполнение AgentTesla, который также производит эксфильтрацию данных через ftp.centredebeautenellycettier[.]fr.

Другой документ SHA1: c992e0a46185bf0b089b3c4261e4faff15a5bc15 под названием 060520.xls распространялся через письмо на греческом языке, а его содержимое выглядит так же, как и все другие в этой кампании, только на греческом языке. Его полезная нагрузка в виде NanoCore Rat подключается к screw-malwrhunterteams[.]com.

Содержимое документа-приманки 060520.xls

Кампания 2019 года

Продолжая исследовать инфраструктуру, связанную с tetragulf@yahoo.com, мы обнаружили, что в 2019 году на эту почту было зарегистрировано всего четыре домена, два из которых были зарегистрированы в конце февраля и участвовали в одной кампании по распространению вредоносных документов.

Список зарегистрированных доменов (подчеркнутые точно вредоносные):

east-ge.com
mariotkitchens.com
sommernph.com
kingtexs-tvv.com

Первые файлы, связанные с этими доменами, начали загружаться в публичные песочницы 18 июня 2019 года.

Список вредоносных файлов, связанных с кампанией 2019 года

Основная часть из этих файлов представляет собой RTF-документы, эксплуатирующие уязвимость CVE-2017-11882, а другие исполняемую полезную нагрузку. В ходе исследования этой кампании мы обнаружили письма и документы-приманки на украинском, русском, греческом, испанском и чешском языках.

Заражение

Один из первых документов этой кампании распространялся через электронную почту под разными названиями: CNC 0247.doc, ЧПУ 0247.doc SHA1:443c079b24d65d7fd74392b90c0eac4aab67060c.

Содержимое письма SHA1: b6ff3e87ab7d6bd8c7abd3ee30af24b4e3709601

Согласно данным из нашего графа, этот документ устанавливает подключение к http://68.235.38[.]157/ava.hta и kingtexs-tvv[.]com.

Сетевое взаимодействие файла SHA1: 443c079b24d65d7fd74392b90c0eac4aab67060c

Мы заинтересовались этим хостом и обнаружили дополнительные файлы, которые устанавливали сетевое подключение к http://68.235.38[.]157. Одни из таких файлов, Estos son los documentos adjuntos de junio.doc SHA1: 02799b41c97b6205f1999a72cef8b8991d4b8092 и New Order.doc SHA1: 25abf0f75c56516134436c1f836d9db1e770ff30, эксплуатируют уязвимость CVE-2017-11882. Во время запуска они устанавливают подключение к http://68.235.38[.]157/oyii.hta.

Содержимое http://68.235.38[.]157/oyii.hta

Этот файл содержит код на Visual Basic, который выполняет обфусцированную в Base64 PS-команду на загрузку полезной нагрузки из общедоступного файлового хранилища https://m.put[.]re/Qm8He5E4.exe - SHA1: 523c5e0a1c9bc6d28f08500e96319571b57e4ba7 и сохраняет в директорию temp под именем avantfirewall.exe.

Исполняемый PS-скрипт

Загружаемая полезная нагрузка считывает содержимое из https://paste[.]ee/r/rSrae, вследствие чего выполняется Async RAT, который устанавливает подключение к своему C&C-серверу kizzoyi.duckdns[.]org на порт 8808.

Другой документ из данной кампании SHA1-1230acfd1f6f5b13a218ff8658a835997d1f0774 под названием таблиц.doc распространялся через письмо на украинском языке.

Из-за критически опасной уязвимости CVE-2017-11882, позволяющей выполнить вредоносный код без взаимодействия с пользователем, во время запуска этого документа происходит выполнение кода, содержащегося в OLE-объекте wd32PrvSE.wmf.

Ole объекты содержащиеся в SHA1:1230acfd1f6f5b13a218ff8658a835997d1f0774

В результате выполнения кода из OLE-объектов загружается и выполняется Async RAT.

Заключение

На этой ноте мы заканчиваем первую часть исследования. Мы понимаем, что этот детектив должен закончиться чем-то логичным, и в следующей части вы с новыми силами окунетесь в развязку данной истории. Пока же можете изучить наше ежегодное исследование Hi-Tech Crime Trends или взглянуть на наши вакансии.

Аудит событий Active Directory и других решений Microsoft в Quest Change Auditor анонс вебинара

22.02.2021 12:20:43 |

Автор: admin

Change Auditor инструмент для автоматизации аудита изменений в AD, Azure AD, SQL Server, Exchange, Exchange Online, Sharepoint, Sharepoint Online, Windows File Server, OneDrive for Business, Skype for Business, VMware, NetApp, EMC, FluidFS. Есть предустановленные отчёты на различные виды угроз, а также на соответствие стандартам GDPR, SOX, PCI, HIPAA, FISMA, GLBA.

Change Auditor значительно снижает трудозатраты на аудит в сравнении с использованием встроенных средств аудита или PowerShell-скриптов. В ситуации, когда авторы систем аудита, основанных на скриптах, увольняются (а мы сталкивались с такой ситуацией у одного из заказчиков), наличие промышленной системы аудита играет новыми красками.

Приглашаем вас зарегистрироваться на вебинар, который состоится 24 февраля в 12 часов дня по московскому времени. Вы узнаете о возможностях решения, кейсах использования, лицензировании и сможете задать интересующие вопросы. Под катом ссылки на наши предыдущие статьи с описанием Change Auditor и других решений от Quest по информационной безопасности.

А кто это сделал? Автоматизируем аудит информационной безопасности

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Управление доступом и формирование отчётов безопасности для окружения Microsoft в Quest Enterprise Reporter

Сравним инструменты для аудита изменений в Active Directory: Quest Change Auditor и Netwrix Auditor

Sysmon теперь может записывать содержимое буфера обмена

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Если вы рассматриваете инструменты подобного класса, оставьте заявку в форме обратной связи или свяжитесь другим удобным способом.

А ещё у нас есть:

Группа в Facebook

Канал в Youtube.

Подробнее..

Категории: Информационная безопасность , It-инфраструктура , Системное администрирование , Серверное администрирование , Блог компании gals software , Gals software , Information security , Siem , Quest software , Галс софтвэр , Аудит изменений it-инфраструктуры , Аудит изменений , Change auditor , Intrust siem

Восстановить контроллер домена Active Directory из пепла вебинар по Quest Recovery Manager

24.03.2021 00:15:52 |

Автор: admin

Ошибки иногда случаются. Active Directory (AD) может понести утрату, если администратор в душевном порыве случайно что-то удалит или выполнит массовое обновление, которое приведёт к нежелательным результатам. Восстановление может растянуться на часы или даже дни и, как следствие, привести к вынужденному простою определённых бизнес-процессов. В таких ситуациях не помешает план аварийного восстановления и инструмент восстановления AD для ускорения возвращения в штатный режим работы.

Quest Recovery Manager для Active Directory похож на страховку для среды AD. Решение фиксирует изменения в AD на уровне объектов или атрибутов и позволяет в несколько кликов откатываться назад. В любой момент времени вы будете знать, что произошло, на кого повлияло и что нужно откатить. В интерфейсе можно быстро сравнить текущее состояние с резервной копией, чтобы мгновенно восстановить данные в локальной среде, Azure AD или гибридной среде.

Приглашаем вас зарегистрироваться на вебинар, который состоится 24 марта в 11 часов дня по московскому времени. Если вы не сможете его посетить или прочитаете этот пост после его начала, в любом случае, оставьте ваши контактные данные и мы пришлём вам запись. На вебинаре вы узнаете как восстановить любой объект в AD без необходимости перезапуска контроллеров домена и быстро выявить изменения в настройках AD (и не только AD). Под катом возможности Quest Recovery Manager для AD и несколько скриншотов интерфейса решения и ссылка на другие наши статьи по решениям Quest для работы со средой Microsoft.

Recovery Manager работает из оснастки операционной системы:

Позволяет делегировать восстановление другим пользователям:

Восстанавливает любой объект AD без нужды в перезагрузке контроллера домена:

Восстанавливает определённые атрибуты без необходимости восстановления учетной записи в AD целиком:

Отчётность по произошедшим изменениям (сравнение):

Поддерживает работу через PowerShell для автоматизации рутинных задач:

Если вы хотели бы протестировать Quest Recovery Manager в вашем окружении или вас интересует стоимость решения, оставьте ваши данные в форме обратной связи или свяжитесь другим удобным способом.

А ещё у нас есть:

А кто это сделал? Автоматизируем аудит информационной безопасности

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Управление доступом и формирование отчётов безопасности для окружения Microsoft в Quest Enterprise Reporter

Сравним инструменты для аудита изменений в Active Directory: Quest Change Auditor и Netwrix Auditor

Sysmon теперь может записывать содержимое буфера обмена

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Группа в Facebook

Канал в Youtube.

Подробнее..

Категории: Информационная безопасность , It-инфраструктура , Системное администрирование , Серверное администрирование , Блог компании gals software , Gals software , Information security , Quest software , Галс софтвэр , Аудит изменений it-инфраструктуры , Аудит изменений , Change auditor , Резервное копирование ad , Восстановление active directory , Откат изменений ad

Tactics	Techniques of adversaries	Mitigations & Active Defense Techniques	Group-IB mitigation & protection products
Resource Development	T1583. Acquire Infrastructure ID: T1588.005. Obtain Capabilities: Exploits ID: T1588.001. Obtain Capabilities: Malware	M1056. Pre-compromise M1016. Vulnerability Scanning	Security Assessment Threat Intelligence & Attribution
Initial Access	ID: T1566.001. Phishing: Spearphishing Attachment	M1049. Antivirus/Antimalware M1031. Network Intrusion Prevention M1017. User Training M1050. Exploit Protection M1051. Update Software DTE0035. User Training DTE0019. Email Manipulation DTE0027. Network Monitoring	Threat Hunting Framework Threat Intelligence & Attribution Cyber Education Red Teaming
Execution	T1059. Command and Scripting Interpreter T1204. User Execution T1203. Exploitation for Client Execution	M1049. Antivirus/Antimalware M1038. Execution Prevention M1021. Restrict Web-Based Content M1026. Privileged Account Management DTE0035. User Training DTE0021. Hunting DTE0018. Detonate Malware DTE0007. Behavioral Analytics DTE0003. API Monitoring DTE0034. System Activity Monitoring	Threat Hunting Framework Red Teaming Incident Response Fraud Hunting Platform
Persistence	T1053. Scheduled Task/Job
Defense Evasion	T1036. Masquerading T1027. Obfuscated Files or Information
Credential Access	T1555. Credentials from Password Stores T1552. Unsecured Credentials	M1049. Antivirus/Antimalware DTE0007. Behavioral Analytics DTE0003. API Monitoring DTE0034. System Activity Monitoring	Threat Hunting Framework
Collection	T1005. Data from Local System		Threat Hunting Framework
Command and Control	T1071. Application Layer Protocol T1573. Encrypted Channel	M1038. Execution Prevention M1031. Network Intrusion Prevention DTE0021. Hunting DTE0022. Isolation DTE0027. Network Monitoring DTE0003. API Monitoring DTE0034. System Activity Monitoring DTE0031. Protocol Decoder	Threat Hunting Framework
			Threat Hunting Framework

	Русский
	English

Information security

Почему это так важно?

Стартуем

Что такое MIMO и massive-MIMO и с чем их едят?

Заправим наше MIMO-system блюдо OFDM модуляцией.

Три кита защиты информации

Аутентификация пользователя

Конфиденциальность данных

Выводы

Список литературы:

Механизм распространения

Заражение

Базовый скрипт

Закрепление в системе

Обход систем защиты

Загрузка основного модуля

Заключение

Об атаках

Кратко об NB-IoT

Защищённость данных во внешней сети

Защищённость данных в сети оператора

Итог

Источники и ссылки:

С чего начинается социотехническое тестирование?

Для чего и как проводить такое тестирование?

Теория, теория Где же обещанные истории?

Разбираем тренды уходящего года

Форматы социотехнического тестирования

Кейс 1

Какие могут быть результаты

Кейс 2

Окей, возвращаемся к тенденциям

Легенды

Кейс 3

Нужно больше тестирований или что будет в периоде

Кейс 4

Кейс 5

Итоги, проблемы и рекомендации

Возвращаясь к основному вопросу: что же выбрать в 2021-м?

DIFAT

FAT

Directory

MiniStream и MiniFAT

Где же текст/картинка/таблица/макрос?

Выводы

Ссылки

Терминология

Кто такие ведьмаки?

Пентестеры

Багбаунти

К чему же это я это все?..

Кампания лета 2020 года

Заражение

Кампания весны 2020 года

Заражение

Кампания 2019 года

Заражение

Заключение

Рекомендации

Категории

Последние комментарии