Closed sn1permanky closed 1 month ago
"-nospawn.*-xml SPHardwareDataType(SPNetworkDataType,SPUSBDataType) -detailLevel full" это что-то легитимное, system_profiler, часть утилит для разработки.
Вторая утилита верна определена.
А вообще здесь был список из следующих популярных техник получения информации о системе. Tasks = {
"id",
"uname",
"who",
"dscl . -read \"/Users/$(id -un)\" RealName",
"ioreg -c IOPlatformExpertDevice -d 2",
"ioreg -rd1 -w0 -c AppleAHCIDiskDriver",
"diskutil list",
"sysctl -n hw.model",
"sysctl -n machdep.cpu.brand_string; hostinfo | grep memory;",
"system_profiler SPHardwareDataType",
"system_profiler SPUSBDataType",
"cat /proc/cpuinfo",
"cat /proc/meminfo",
"launchctl list",
"ps ax",
"sw_vers -productName",
"sw_vers -productVersion",
"sw_vers -buildVersion",
"sysctl kern.hostname",
"csrutil status",
"system_profiler SPNetworkDataType",
"networksetup -listallhardwareports",
"networksetup -getinfo Wi-Fi",
"ifconfig -a"
}
Спасибо за пояснение!
При подготовке использовал исследование https://www.sentinelone.com/labs/20-common-tools-techniques-used-by-macos-threat-actors-malware/
Там как раз типичными командами указывается:
/usr/sbin/system_profiler -nospawn -xml SPHardwareDataType -detailLevel full
Плюс специально ввел количество проверок - 4 команды за пять секунд, маловероятно что в скрипте будет четыре раза использоваться эта команда. Соответственно то что вручную при отладке кто-то введет эти команды вручную - тоже невозможно.
Вообще, конечно очень интересно. Из всего списка, наиболее яркими считаю команды:
dscl . -read "/Users/$(id -un)" RealName //На вряд ли какому-то скрипту будет необходимость обращаться к реальному имени (речь именно про баш скрипт, а не про полноценную программу) csrutil status // Специализированная служба контроля целостности, на вряд ли также понадобится в рамках скрипта
Большинство остальных индикаторов, будут, как мне кажется сильно фолзить, при базовой отладке админа, особенно в блоке software - эти команды я на работе ввожу очень часто:).
В моем правиле защита от этого обеспечена увеличением количестве использований. Да и к тому же регулярка охватывает эти выражения, которые указаны в этом списке: "system_profiler SPHardwareDataType", "system_profiler SPUSBDataType",
Так что я полагаю целесообразным сохранить именно эту структуру)
Добавил детект Bundlore.
При анализе сырых логов обратил внимание на то, что вводятся несколько раз команды c используемым синтаксисом вида: -nospawn.*-xml SPHardwareDataType(SPNetworkDataType,SPUSBDataType) -detailLevel full а также команды
Решил построить логику на них.
Специально не стал указывать, то что они начали работать после запуска cкрипта на Python, так как они также реализуемы через bash, а это лишнее усложнение логики
Фолзы почти нереальны(как я полагаю), так как выбран маленький промежуток времени для введения команд. Возможно единичные случаи при работы диагностических скриптов.
Остальные команды не указывал, так как они могут использоваться для базового траблшутинга, и не являются такими яркими маркерами, если верить исследованиям по Bundlore.
В целом можно скрипт расширить для реагирования и на Shlayer cемейство и добавить возможное использование обфусцированного кода, но это уже более сложное решение.