За версия 12 на Sysmon беше обявено на 17 септември на . Всъщност на същия ден излязоха и нови версии на 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).
За фиксиране, анализ и реакция на изброените по-горе събития може да се използва инструмент, , който обединява всичките три подхода и, освен това, е ефективно централизирано хранилище на всичките събрани сурови данни. Можем да настроим интеграцията му с популярни SIEM системи, за да минимизираме разходите им за лицензиране, като преместим обработката и съхранението на суровите данни в InTrust.
За да научите повече за InTrust, прочетете нашите предишни статии или .
(популярна статия)
Източник: habr.com
