Вопрос или проблема
Я изучал хост Windows Server 2012 R2, который был скомпрометирован вредоносным ПО IIS SEO Campaign.
Используя Process Monitor, я заметил, что оно внедряет вредоносный DLL, когда загружает легитимный. Все DLL вплоть до этого, включая его, имеют совпадающие md5-хеши с другим Windows Server 2012 R2, который не заражен этим вирусом.
Особенность в том, что легитимный DLL отвечает на операцию CreateFile с REPARSE.
Это предполагает, что установлен точка повторного анализа для DLL жертвы, которая затем ведет к загрузке вредоносного файла.
Проблема в том, что я могу запросить файл через диалог свойств Windows, чтобы увидеть, что он подлинный и подписанный, использовать инструменты, такие как md5sum, чтобы получить некоторую контрольную сумму для сравнения в другом месте, и даже скопировать файл, скажем, в file2.dll, чтобы получить легитимный дескриптор файла и содержимое.
Единственный раз, когда, похоже, я заставляю его перенаправить на вредоносный файл – это когда программа пытается его загрузить.
Вот вывод, который я получаю от ProcMon, когда загружаю зараженный файл:
2:53:54.2321174 PM w3wp.exe 4876 CreateFile C:\Windows\System32\inetsrv\custerr.dll REPARSE Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Superseded
2:53:54.2344554 PM w3wp.exe 4876 CreateFile C:\Windows\Vss\Logs\WsmRes64.dll SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
2:53:54.2353130 PM w3wp.exe 4876 CreateFile C:\Windows\System32\inetsrv\custerr.dll REPARSE Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Superseded
2:53:54.2354092 PM w3wp.exe 4876 CreateFile C:\Windows\Vss\Logs\WsmRes64.dll ACCESS DENIED Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a
Обратите внимание, что последний записанный элемент имеет ACCESS DENIED, потому что в тот момент я уже повредил вредоносный DLL, пытаясь вывести его из директории теневого копирования. Прежде чем он стал недоступным, он, естественно, дошел до шага Load Image и продолжил свои, ну, действия.
Сравните с загрузкой, если я просто бесстыдно скопирую тот самый файл custerr.dll в custerr2.dll и укажу IIS использовать этот DLL:
12:51:54.2194050 PM w3wp.exe 6804 CreateFile C:\Windows\System32\inetsrv\custerr2.dll SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
12:51:54.2196814 PM w3wp.exe 6804 CreateFile C:\Windows\System32\inetsrv\custerr2.dll SUCCESS Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
12:51:54.2200149 PM w3wp.exe 6804 CreateFile C:\Windows\System32\inetsrv\custerr2.dll SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Write Through, Synchronous IO Non-Alert, Random Access, Attributes: SN, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened
12:51:54.2202689 PM w3wp.exe 6804 CreateFile C:\Windows\System32\inetsrv\custerr2.dll SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Write Through, Synchronous IO Non-Alert, Random Access, Attributes: SN, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened
12:51:54.2205066 PM w3wp.exe 6804 Load Image C:\Windows\System32\inetsrv\custerr2.dll SUCCESS Image Base: 0x7fff248a0000, Image Size: 0x10000
Нет ответа на повторный анализ и никакой замены вообще не происходит.
Значит ли это, что IIS использует только createFile, чтобы загружать модули, или есть способы построить правила повторного анализа, которые активируются только при открытии файла, скажем, определенным исполняемым файлом? В конечном итоге, как я могу запросить эти правила (и, возможно, удалить их)? Где бы я ни видел информацию о правилах повторного анализа или инструменте junction, всё касается символических ссылок, и это выглядит немного сложнее, чем просто ссылка.
Ответ или решение
Для понимания проблемы с точечными репарациями NTFS и их потенциальным использованием вредоносным программным обеспечением необходимо рассмотреть ряд ключевых аспектов, связанных с их созданием, управлением и воздействием на файловую систему Windows. Это особенно актуально для сценария, когда легитимные файлы DLL оказываются подвержены манипуляциям, что приводит к загрузке вредоносных компонентов в процессе работы серверного ПО, в данном случае IIS.
Что такое репарационные точки NTFS?
Репарационные точки NTFS (Reparse Points) — это мощный механизм, позволяющий пользователям и программному обеспечению использовать данные, хранящиеся в файловой системе, в различных формах. Их основная функция — это переадресация файловых операций к заранее определённым целям. Они могут исполняться в виде символических ссылок, жестких ссылок или даже в виде специального функционала для программ, требующих динамической маршрутизации данных.
Как работают репарационные точки в Windows?
Когда приложение пытается открыть файл, операционная система выполняет запрос CreateFile, который может сигнализировать о наличии репарационной точки. Если файл является репарационной точкой, система обращается к записанным в ней данным и перенаправляет операцию к целевому объекту. Это может быть код, который в свою очередь загрузит другой файл или выполнит другую операцию. В вашем случае, когда IIS инициирует операцию открытия файла, ведется обращение к репарационной точке, результатом чего становится загрузка вредоносного кода.
Запрос репарационных точек
Для изучения настроенных репарационных точек используйте утилиту fsutil. Зная путь к файлу, который вызывает подозрения, выполните следующую команду:
fsutil reparsepoint query C:\Windows\System32\inetsrv\custerr.dllЭта команда предоставит информацию о типе репарационной точки и целевом объекте, на который она ссылается. Если вам потребуется удалить репарационную точку, вы также можете сделать это с помощью fsutil командой:
fsutil reparsepoint delete C:\Windows\System32\inetsrv\custerr.dllРазработка правил репарации
По вашему вопросу о возможности создания правил репарации, которые срабатывают только при обращении конкретного исполняемого файла, стоит отметить, что такой функционал не предусмотрен в стандартной реализации NTFS. Репарационные точки работают на уровне системного вызова, и их триггер не зависит от конкретного процесса, осуществляющего вызов.
Тем не менее, в некоторых случаях атрибуты и права доступа к файлу могут быть настроены таким образом, чтобы ограничить или изменить поведение при обращении к репарационным точкам. Это может быть достигнуто путем настройки разрешений на уровне файловой системы, что требует более глубоких знаний о том, как работает ACL (Access Control List) в Windows.
Устранение вредоносного кода
Если файл custerr.dll с установленной репарационной точкой вызывает подозрения, необходимо провести следующие шаги:
- Проверить файл на наличие репарационной точки.
- Если она существует, удалить репарационную точку и провести анализ целичности файла, включая сверку с известной безопасной версией.
- Если файл испорчен или отсутствует, замените его на чистую версию.
- Провести полное сканирование системы на вредоносный код с использованием современных антивирусных решений.
- Убедитесь, что все программное обеспечение и операционная система обновлены до последних версий.
Заключение
Работая с репарационными точками в Windows, важно понимать, что они представляют собой мощный инструмент, который может быть использован как для законных целей, так и злоумышленниками. Умелое управление этими функциями поможет сохранить безопасность системы и предотвратить потенциальные угрозы.