Как найти вызывающую функцию Kernel32.Beep по трассировкам ETW?
У нас есть система, в которой некий вредоносный код посылает произвольные звуковые сигналы, вероятно, вызывая функцию Beep() в Win32 API
Мне нужно выяснить, какой исполняемый файл это делает, и я хочу использовать для этого ETW. До сих пор я мог узнать, что фактический звуковой сигнал выполняется Windows Taskhostw.exe, который не дает мне понятия, какое приложение изначально запустило звуковой сигнал.
Есть ли способ узнать, кто вообще вызвал Beep()? Это в системе клиента, поэтому любое взаимодействие с пользовательским интерфейсом запрещено, это должен быть какой-то фоновый сбор трассировки...
Я использую для тестов очень маленькую тестовую программу TestBeep.exe и хочу видеть в своих данных ETW, что TestBeep.exe начал подавать звуковой сигнал...
#include <iostream>
#include <windows.h>
#include <utilapiset.h>
int main()
{
std::cout << "Beeping now...\n";
Beep(440, 1000);
std::cout << "done.\n";
return 0;
}
@YangXiaoPo-MSFT На самом деле я не нашел там ничего, что могло бы мне помочь. Что именно вы имеете в виду?
На самом деле я имею в виду, что могут быть некоторые поставщики, которые вас заинтересуют.
Пока ничего не работает. Я использую очень маленький тестовый проект, и со всеми провайдерами, которые я тестировал (все со звуком... в названии), я никогда не вижу свой TestBeep.exe где-либо в стеках... Я обновил вопрос с помощью теста программа.
Может быть провайдер ETW, который может это сделать, но я подозреваю, что он хорошо известен и задокументирован. Может быть, вам стоит попробовать Process Monitor?
Уже пробовал мониторить процессы, но тоже не дает никакого интересного результата. Этот beep() — действительно странная вещь из прошлого.
Возможно, вам потребуется отправить отзыв по вопросу.
Ответы 1
Вы можете проверить, кто открывает устройство Beep (\Device\Beep), которое представляет собой файл. Вы можете включить отслеживание дескрипторов и, возможно, фильтровать по типу дескриптора. Но вы должны продвинуться довольно далеко, включив отслеживание дескрипторов без каких-либо стеков, чтобы определить, кто открывает устройство Beep. Моя новейшая версия ETWController также может фильтровать по типу дескриптора: https://github.com/Alois-xx/etwcontroller/releases/tag/2.5.2, что является уникальной функцией.
Эти настройки должны работать внутри ETWController:
Если вы не можете фильтровать по типу дескриптора, вам следует удалить события обхода стека, чтобы получить хотя бы представление о том, когда и какой процесс вызвал звуковой сигнал. Добавив позже выборку ЦП, вы сможете определить, что этот процесс делал в тот момент времени.
Обновление 1
Для начала я бы просто включил ключевое слово Handle и надеюсь, что оно будет записываться достаточно долго. Без фильтров Handle все сложнее. Поскольку это проблема клиента, вы можете делать выборку каждый день в рабочее время в течение одного конкретного часа и собирать эти данные каждый день, пока не обнаружите, по крайней мере, какой процесс это сделал, тогда будет проще выяснить, кто это делал.
<SystemProvider Id = "SystemProvider_Handle" Base = "SystemProvider_Monitoring">
<Keywords Operation = "Add">
<Keyword Value = "Handle"/>
</Keywords>
<Stacks>
<!--
<Stack Value = "HandleCreate"/>
<Stack Value = "HandleClose"/>
<Stack Value = "HandleDuplicate"/>
-->
</Stacks>
</SystemProvider>
Это отлично работает! Есть ли способ использовать это в системе клиента без развертывания ETWController, только с помощью wpr.exe?
@Achim: Я добавил несколько идей.
Эти провайдеры ETW работают у вас?