C:\myapplication\myapplication.exe
      C:\myapp\subfolder\myapp.exe
      C:\SoftwareCompany\software.exe
      C:\myapplication\myapplication.dll
      C:\myapp\subfolder\myapp.dll
      C:\SoftwareCompany\software.dll
           

**Практическая ментальная модель такова:**

процесс загружает libeay32.dll

→ процесс вызывает OPENSSL_config(NULL)

→ OpenSSL читает openssl.cnf

→ секция engine вызывает попытку загрузки указанной dll

→ загрузчик Windows принимает dll и её зависимости

***Если какой-либо шаг отсутствует, ваша DLL не загрузится.***

Минимальное правило, которое можно использовать при отладке:

Если процесс загружает только libeay32.dll, этого недостаточно.
Он также должен вызывать загрузку конфигурации OpenSSL и не отключать её.

- Он должен вызывать OPENSSL_config, чтобы работать, или
- CONF_modules_load_file, или
- OPENSSL_no_config не установлен.


Никакой проверки подписи. Никакой верификации. Любая указанная DLL загружается, если процесс вызывает OPENSSL_config.
Мы можем выполнять запросы по типичным именам DLL, связанным с OpenSSL, чтобы перечислить возможные приложения для дальнейшего тестирования. Мы хотим проверить DLL-файлы OPENSSLDIR и то, вызывает ли процесс OpenSSL_conf.
Мы можем проверить OpenSSLDIR, сравнив хеш файла со списком в этом репозитории, или получить копию криптографической dll и просто запустить openssldir_check на cryptodll (libeay32.dll и т. д.).
Мы также можем использовать ProcMon, чтобы проверить, вызывает ли процесс какой-либо openssl.cnf. Если мы видим openssl.cnf в procmon, то мы точно знаем, что приложение обращается к нему. В других методах мы хотим получить информацию о версии (в полях event.code 7) и о том, из какого пути он загружает файл openssl.cnf, сравнив хеш файла со списком в этом репозитории, получить копию той же DLL и выполнить ручную проверку.


**Пример при запуске openssldir_check.exe**

`openssldir_check32.exe libeay32.dll`

`openssldir_check v1.0 by 0xm1rch`

**Вывод:**

`SSLeay_version() returned OpenSSL 1.0.1g 7 Apr 2014`

`SSLeay_version() returned OPENSSLDIR: "/usr/local/ssl"`

- ref https://github.com/mirchr/openssldir_check
> Аналогичный вывод с кастомно модифицированным openssldir_check, который предварительно скомпилирован в этом репозитории.

> Вывод показывает версию OpenSSL 1.0.1g и что OpenSSLDIR установлен в **/usr/local/ssl**, что **весьма интересно!**

> **Sysmon event.code 7** даёт вам загруженные DLL OpenSSL, а также информацию о версии dll в поле file.pe.file_version.


#### Сценарий эскалации
1. Служба работает как **SYSTEM** и использует OpenSSL
2. DLL OpenSSL вызывает openssl_conf и читает `C:\usr\local\ssl\openssl.cnf` при запуске, но этот файл доступен для редактирования или отсутствует
3. Если низкопривилегированный пользователь может писать в эту папку, он может:
   - Подложить вредоносный `openssl.cnf`
   - Подложить свою DLL
   - Дождаться перезапуска службы
   - Код выполняется как **SYSTEM**

> Результат: локальная эскалация привилегий путём подкладывания openssl.cnf, который загружает openssl dll приложения и заканчивается загрузкой кастомной «вредоносной» dll.



### Уязвимость установщика/деинсталлятора NSIS

NSIS — широко используемый фреймворк для установщиков Windows. Проблема, описанная здесь, заключается в том, что когда установщик или деинсталлятор NSIS запускается с повышенными привилегиями, он может использовать временные каталоги в C:\Windows\Temp таким образом, что обычный локальный пользователь может вмешаться в этот процесс.

На практике это означает, что низкопривилегированный атакующий может получить контроль над файлами, которым доверяет установщик, такими как временные файлы плагинов или файлы деинсталлятора, и превратить это в выполнение кода как SYSTEM. Иными словами, слабость не в том, что «установщик запускается от имени администратора», а в том, что обработка временных файлов установщиком может позволить непривилегированному пользователю перехватить привилегированный процесс установки или удаления.

#### Распространённые DLL, встречающиеся в установщиках NSIS

> Примечание: Некоторые из них — **официальные плагины NSIS**, другие — **распространённые сторонние плагины**, часто используемые установщиками NSIS.  
> Обнаружение одной из этих DLL — это подсказка, но не абсолютное доказательство того, что установщик использует NSIS. Путь к файлу вида `C:\Windows\Temp\*.tmp\*.dll` является сильным признаком.

| DLL | Типичное назначение | Тип | Примечания |
|---|---|---|---|
| `System.dll` | Вызывает Win32 API и функции внешних DLL из скриптов NSIS | Официальный плагин NSIS | Один из сильнейших индикаторов NSIS |
| `nsDialogs.dll` | Создаёт кастомные диалоги и элементы управления установщика | Официальный плагин NSIS | Часто встречается в современных установщиках NSIS |
| `nsExec.dll` | Выполняет консольные команды и захватывает вывод | Официальный плагин NSIS | Часто используется для тихих вспомогательных команд |
| `StartMenu.dll` | Позволяет пользователю выбрать папку в меню «Пуск» | Официальный плагин NSIS | Часто встречается в классических установщиках |
| `LangDLL.dll` | Отображает диалог выбора языка | Официальный плагин NSIS | Часто появляется в многоязычных установщиках |
| `Banner.dll` | Показывает баннер/прогресс во время этапов установки | Официальный плагин NSIS | В основном косметический |
| `InstallOptions.dll` | Создаёт кастомные страницы старого стиля из определений INI | Официальный плагин NSIS | В значительной степени заменён на `nsDialogs.dll` |
| `UserInfo.dll` | Получает информацию о текущем пользователе/учётной записи | Официальный плагин NSIS | Используется для проверок привилегий или учётных записей |
| `Dialer.dll` | Управляет поведением коммутируемого/сетевого подключения | Официальный плагин NSIS | В основном устаревший |
| `Math.dll` | Предоставляет арифметические помощники для скриптов NSIS | Официальный плагин NSIS | Реже требуется в новых скриптах |
| `NSISdl.dll` | Загружает файлы из интернета | Официальный плагин NSIS | Старый плагин загрузки; часто заменяется на `inetc.dll` |
| `Splash.dll` | Показывает splash-экран | Официальный плагин NSIS | В основном устаревший/косметический |
| `AdvSplash.dll` | Показывает более продвинутый splash-экран | Распространённый плагин NSIS | Аналогичная роль, что и у `Splash.dll` |
| `BgImage.dll` | Отображает фоновое изображение в UI установщика | Официальный / распространённый плагин NSIS | В основном косметический |
| `inetc.dll` | Загружает файлы по HTTP/FTP | Распространённый сторонний плагин NSIS | Очень часто встречается в веб-установщиках |
| `InetLoad.dll` | Загружает файлы из интернета | Распространённый сторонний плагин NSIS | Альтернатива `NSISdl.dll` / `inetc.dll` |
| `UAC.dll` | Обрабатывает повышение привилегий и поведение, связанное с UAC | Распространённый сторонний плагин NSIS | Сильная подсказка на NSIS |
| `AccessControl.dll` | Изменяет ACL файлов/папок и разрешения | Распространённый сторонний плагин NSIS | Используется в установках, чувствительных к правам администратора |
| `Registry.dll` | Продвинутые операции с реестром Windows | Распространённый сторонний плагин NSIS | В некоторых случаях более функционален, чем встроенные команды реестра |
| `ShellLink.dll` | Создаёт или редактирует ярлыки Windows (`.lnk`) | Распространённый сторонний плагин NSIS | Помощник управления ярлыками |
| `SimpleFC.dll` | Сравнивает файлы или проверяет различия файлов | Распространённый сторонний плагин NSIS | Утилитарный/вспомогательный плагин |
| `FindProcDLL.dll` | Определяет, запущен ли процесс | Распространённый сторонний плагин NSIS | Часто используется перед обновлениями |
| `KillProcDLL.dll` | Завершает запущенные процессы | Распространённый сторонний плагин NSIS | Часто встречается в деинсталляторах/обновляторах |
| `NScurl.dll` | Загружает/передаёт данные с использованием функциональности в стиле curl | Распространённый сторонний плагин NSIS | Более новый/более функциональный сетевой помощник |
| `ZipDLL.dll` | Обрабатывает извлечение или создание ZIP-архивов | Распространённый сторонний плагин NSIS | Утилита для архивов |
| `unzipdll.dll` | Извлекает ZIP-архивы | Распространённый сторонний плагин NSIS | Старый плагин для архивов |
| `untgz.dll` | Извлекает архивы `.tar.gz` | Распространённый сторонний плагин NSIS | Менее распространён, но встречается в некоторых пакетах |
| `VPatch.dll` | Применяет бинарные патчи/обновления | Распространённый плагин, связанный с NSIS | Часто используется в установщиках патчей |
| `CabDLL.dll` | Работает с CAB-архивами | Распространённый плагин, связанный с NSIS | В основном встречается в старых рабочих процессах упаковки |
| `nsJSON.dll` | Парсит или генерирует данные JSON | Распространённый сторонний плагин NSIS | Чаще встречается в современных скриптовых установщиках |
| `StdUtils.dll` | Утилиты общего назначения для NSIS | Распространённый сторонний плагин NSIS | Часто используется для помощников по ОС/версии/путям |
| `ExecDos.dll` | Выполняет команды с лучшим контролем над I/O и ожиданием | Распространённый сторонний плагин NSIS | Альтернатива/расширение для `nsExec.dll` |

#### Более сильные индикаторы NSIS

Следующие DLL особенно указывают на NSIS:

- `System.dll`
- `nsDialogs.dll`
- `nsExec.dll`
- `LangDLL.dll`
- `StartMenu.dll`
- `NSISdl.dll`
- `inetc.dll`
- `UAC.dll`

#### Осторожно

Некоторые установщики извлекают эти DLL временно в папку вида:

- `$PLUGINSDIR`

Поэтому они могут появляться только во время выполнения, а не рядом с исполняемым файлом установщика на диске.


### Уязвимости перенаправления DotLocal
**Злоупотребление перенаправлением DotLocal — это проблема перехвата DLL в Windows, при которой доступная для записи папка приложения позволяет атакующему заставить легитимную программу сначала загрузить вредоносную DLL**

Уязвимость перенаправления DotLocal использует встроенную функцию перенаправления DLL .local / DotLocal в Windows. Windows поддерживает перенаправление DLL, учитывая файл или папку с именем вида App.exe.local; при наличии такого файла загрузчик сначала проверяет папку исполняемого файла или эту .local-папку на наличие DLL, и это может применяться даже когда указан полный путь к DLL. Microsoft документирует это как легитимную функцию для перенаправления загрузки DLL.

Почему это становится уязвимостью: если атакующий может писать в каталог исполняемого файла (пути, доступные для записи пользователем) или во временный каталог извлечения, используемый привилегированным процессом, он может создать папку Target.exe.local и поместить туда вредоносную DLL, которую Windows предпочтёт. Это превращает функцию в перехват DLL, так что доверенный процесс загружает библиотеку атакующего вместо предполагаемой библиотеки.

#### Ручной контроль
Идентифицированные высокопривилегированные процессы в путях, доступных для записи всем, должны быть исследованы на предмет уязвимости к перенаправлению DotLocal. Если вы выполните по ним запросы и найдёте приложения. Выполните последний контроль с помощью ProcMon, чтобы увидеть, пытается ли процесс загружать библиотеки из созданной папки .exe.local. Вы можете использовать инструмент GetSxsPath для определения полного пути к файлу. Procmon должен показать вам события NAME NOT FOUND / PATH NOT FOUND, указывающие на каталог .exe.local, если он уязвим. Согласно публичным отчётам, приложения особенно уязвимы во время процесса установки.

**Хорошее практическое правило:**
ProcMon может предоставить доказательства проверки .local, но отсутствие видимого промаха .exe.local не доказывает, что приложение не подвержено уязвимости. Особенно для comctl32.dll трассировка часто отражает привязку manifest/SxS, а не простой поиск DLL в папке приложения.


#### Если программа загружает:

`C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

#### Проверьте это:

`C:\Path\To\Application.exe.local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

**Определение пути перенаправления для SxS DotLocal DLL Hijacking** - https://gist.github.com/rxwx/1717e95e5ec11bea12d33e93a3832508

#### Установщик DotLocal Wiz
**Загрузчик WiX Burn EXE** Затронутые версии >= 4, < 4.0.4 < 3.14.0. Это влияет на любой установщик, собранный с использованием фреймворка установщика WiX.
WiX также позволяет авторам заменять иконку по умолчанию и использовать либо стандартный UI WixStdBA, либо кастомное загрузочное приложение, поэтому EXE можно брендировать так, чтобы он выглядел как вендор, а не как «WiX»

##### Детали
Если bundle запускается не от имени администратора, используется папка TEMP пользователя, а не системная папка TEMP. Утилита может отслеживать папку TEMP пользователя на предмет изменений и немедленно подложить свою DLL в папку .be/.Local, как только папка .be будет создана. Когда движок burn повышает привилегии, вредоносная DLL получает повышенные привилегии.

> **Ref** https://github.com/wixtoolset/issues/security/advisories/GHSA-7wh2-wxc7-9ph5

«Отдельный процесс wixstdba.exe — хороший отпечаток WiX Burn, но сильнейшим индикатором для затронутых версий является сама версия движка Burn: уязвим, если он идентифицирует себя как <3.14.0 или 4.0.0–4.0.3.»


## Предварительные требования
Хорошо настроенная конфигурация SYSMON для перехвата интересующих событий, таких как event.code 1, 7, 11 и 13 для путей, доступных для записи пользователем, и упомянутых кустов реестра.
 - https://github.com/SwiftOnSecurity/sysmon-config
 - https://github.com/olafhartong/sysmon-modular

Включён расширенный аудит для некоторых событий Windows.

Event ID 4688 (создание процесса) должен быть явно включён для регистрации вновь созданных процессов. 
По умолчанию он не захватывает командную строку, использованную для запуска процесса; эта функция должна быть специально включена в политике безопасности.

Запланированная задача — 4698 не включена по умолчанию.


## ACL ⭐
### 🔹 Некоторые распространённые субъекты ACL, охватывающие вошедших пользователей

| Субъект               | Описание                                                                 |
|--------------------------|-----------------------------------------------------------------------------|
| **Everyone**             | Все пользователи, включая гостей (а в старых версиях Windows даже анонимный вход). Очень широкий, обычно ограничен доступом на чтение. |
| **Authenticated Users**  | Любая учётная запись, которая успешно вошла в систему (локальная или доменная). Исключает анонимных пользователей. |
| **BUILTIN\Users**        | Локальная группа **Users** на машине. Включает все стандартные (не административные) локальные учётные записи. |
| **INTERACTIVE**          | Любой пользователь, вошедший **локально за консолью** (клавиатура/сессия). Полезно для различения локального и удалённого доступа. |
| **COMPUTERNAME\\Username** | Конкретная **локальная учётная запись** на этом компьютере (например, `LAPTOP01\Bob`). Разрешения применяются только когда этот пользователь входит локально. |
| **DOMAIN\\Username**     | Конкретная **доменная учётная запись** (например, `CORP\Alice`). Разрешения следуют за пользователем на всех машинах, присоединённых к домену. |


### 📑 Атрибуты ACL (некоторые из интересных для изучения)

Атрибуты списка контроля доступа (ACL) определяют, какие действия пользователь или группа могут выполнять с файлами или папками.  
Вот некоторые ключевые, которые стоит отметить:

| Атрибут | Название / Значение           | Почему это интересно                                                                 |
|-----------|--------------------------|--------------------------------------------------------------------------------------|
| **F**     | Полный доступ              | Предоставляет **все возможные права** (чтение, запись, выполнение, удаление, изменение разрешений, смена владельца). Эквивалент контроля «на уровне владельца». |
| **M**     | Доступ на изменение            | Позволяет читать, записывать и удалять файлы/папки, но **не изменять ACL** или владельца. Наиболее распространён для обычных пользователей. |
| **W**     | Доступ только на запись        | Пользователь может **создавать или изменять содержимое**, но не может прочитать его обратно. Редко, но полезно в сценариях «drop box» (например, безопасная отправка файлов). |
| **WD**    | Запись данных / Добавление файла    | Специально позволяет **создавать файлы в каталоге или записывать в них**. Необходимо для возможности добавлять или перезаписывать файлы внутри папки. |
| **AD**    | Добавление данных / Добавление подкаталога | Для файлов: добавление данных в конец файла (нельзя перезаписать). Для папок: создание новых подкаталогов внутри. |


## Ложные срабатывания
#### Выполняйте запросы, тонко настраивайте их и в конце создавайте из них оповещения. 
Возможно, вам потребуется внести некоторые исключения (см. ниже типичные пути в ProgramData). Идея состоит в том, чтобы запрашивать типичные пути, доступные для записи пользователем, но бывает, что (файлы или папки) имеют корректно установленный ACL. Если наступательное мышление не помогает эскалировать привилегии — добавьте их в исключения.
Отфильтруйте менее интересные: те, что с корректным ACL, рандомизированными именами файлов (отфильтруйте папку). Мы хотим уменьшить шум и иметь базовую линию. Важно делать это после проверки, что это не уязвимость. Чтобы вы не пропустили запланированную задачу, уязвимую на каждом клиенте.


## Внесение в исключения
Вам, вероятно, потребуется добавить запросы в исключения. Проведите охоту, тонко настройте запросы и создайте из них оповещения, чтобы ловить новые события, которые вы ещё не рассматривали.
##### Вероятно, потребуется внести в исключения:
      C:\ProgramData\Microsoft
      C:\ProgramData\Package Cache
      C:\ProgramData\Packages
      и т. д.

Другие, которые могут потребовать внесения в исключения и которые могут быть распространёнными, — это драйверы, связанные с оборудованием, и подобные вещи с рандомизированными именами..
      

## Методология
Не забывайте выполнять запросы в пределах вашего «периода хранения логов».
Хорошая методология — сначала запрашивать за короткий промежуток времени, который постепенно увеличивается.
1) 1 день
2) 1 неделя
3) 2 недели
4) 1 месяц
5) 2 месяца
6) и т. д..

Проводите охоту и проверяйте интересные случаи, тонко настраивайте и вносите в исключения.. в конце создавайте из них оповещения, чтобы ловить новые события..

## Советы и приёмы
Если замена бинарного файла невозможна из-за корректного ACL. Проверьте разрешения на папку и, если у вас есть разрешения на запись файлов,
проверьте, пытается ли исполняемый файл загрузить какие-либо DLL, которых не существует. Если да, создайте их, и у вас есть выполнение кода. Если замена бинарного файла невозможна, потому что это запущенный процесс. Проверьте возможную боковую загрузку DLL или проверьте, есть ли у вас как у обычного пользователя разрешения перезапустить саму службу. Другой способ — проверить, можете ли вы как обычный пользователь выполнить «shutdown», из которого вы вырветесь в последнюю секунду. Инициирование shutdown останавливает процессы, и если вы вырветесь из него, вы, возможно, сможете заменить бинарный файл завершённого процесса. Если служба находится в режиме Autostart и у вас нет разрешений на запуск/остановку службы, что вы можете проверить — есть ли у вас SeShutdownPrivilege, и если да, инициировать перезагрузку с помощью shutdown /r /t 0.

Если служба порождает процесс и если заменить бинарный файл невозможно, бинарный файл не пытается загрузить какие-либо отсутствующие DLL. Не сдавайтесь — может быть, путь не заключён в кавычки, и у вас есть разрешения на запись, и вы можете это использовать?

Стройте ваши запросы слой за слоем.. так проверяйте создание служб/запланированных задач, проверяйте создание процессов с родителем в виде служб или процессов, связанных с запланированными задачами (svchost.exe с аргументом Schedule). Возможно, что какая-то система создаёт службу или запланированную задачу, но путь к бинарному файлу и т. д. не существует, и создание процесса никогда не происходит. Но уязвимость всё ещё существует, и могут быть созданы различные события, связанные с ней.

Чтобы уменьшить нагрузку на запросы (производительность) и, вероятно, объём исключений.. может быть хорошей идеей разделить запросы для клиентов/серверов. То есть набор запросов, используемый только для клиентских конечных точек, и такой же набор, используемый для серверных конечных точек.

Общий запрос на создание процесса от SYSTEM — это высокоценный запрос. Он ловит множество сценариев.. помимо служб и schtask, порождающих дочерние процессы, он также ловит msiexec.exe, порождающий дочерний процесс. Он также ловит, если исполняемый файл из c:\windows\ccmcache порождает дочерний процесс из пути, доступного для записи пользователем. Если бы нам нужно было упорядочить исполняемые файлы по уязвимости, я бы всё же сказал, что services.exe связан с ошибками конфигурации программного обеспечения, а schtasks — скорее с ошибками конфигурации администратора..

Если вы попробовали все запросы и не добились успеха. Если вы хотите копать глубже и сделать немного больше работы — займитесь каждым дочерним процессом services.exe и schtasks (svchost.exe с аргументом Schedule), независимо от того, где он находится. Перечислите предприятие и поищите также те, что находятся в типичных административно защищённых путях (Program Files и Program Files (x86)). Это более распространено, чем вы думаете, что вендоры программного обеспечения портят ACL даже в типичных защищённых путях. Используйте события создания процессов и события для служб и запланированных задач. Для запланированных задач — запрашивайте каждое поле Command и поле Argument. Поле argument может указывать на файл скрипта в пути, доступном для записи пользователем, или в корне C. Поля command могут указывать на бинарный файл с небезопасным ACL. Вы также можете посмотреть на C:\PROGRA~3, что является 8.3 коротким именем (DOS) для C:\ProgramData.

## Процессы удаления
Вероятно, что если пользователь может инициировать установку, он также может инициировать удаление. Процессы удаления представляют интерес независимо от того, где находится путь к файлу.
Если ACL некорректен — замена бинарного файла, вероятно, вызовет проблемы.
Запрашивайте также создание файлов типичных файлов удаления, используя Sysmon event.code:11.
Мы хотим делать это, чтобы поймать каждый деинсталлятор, не доверяя событиям создания процессов. Это потому, что не часто пользователи действительно выполняют удаление установленных приложений.. Им просто всё равно, и поэтому будет легче пропустить некоторые события удаления, которые существуют, но никогда не инициируются.

### Пример имён процессов удаления
#### Распространённые общие именаuninstall.exe – наиболее универсальный и широко используемый.
          unins000.exe, unins001.exe – часто встречается в установщиках Inno Setup.
          unwise.exe – часто используется старыми пакетами Wise Installer.
          uninst.exe – сокращённый вариант, часто встречается в устаревшем ПО.
          uninstaller.exe – чуть более длинный, описательный вариант.
          remove.exe – иногда используется в минимальных установщиках.
          setup.exe (с параметром /uninstall или /remove) – некоторые приложения повторно используют исполняемый файл установщика для удаления.
          appname_uninstall.exe (например, chrome_uninstall.exe)
          update.exe (с --uninstall) – встречается в приложениях вроде Slack или Discord, использующих установщики Squirrel.

#### Шаблоны, которые стоит учитывать

          *_uninstall.exe – многие приложения добавляют имя приложения в начало, например teams_uninstall.exe, zoom_uninstall.exe.
          *_cleanup.exe – инструменты удаления часто имеют варианты cleanup, например driver_cleanup.exe.
          *_remover.exe – ещё один распространённый стиль именования AV/вендоров.


## PE / бинарные файлы с выполнением кода при загрузке
### Рассмотрите запрос для перечисленных в списке как в логах windows/sysmon, так и в логах procmon
| Расширение | Тип PE | Выполнение кода при загрузке? | Точка входа / механизм | Примечания |
|-----------|---------|--------------------------|-------------------------|-------|
| `.exe` | PE executable | Да | PE `AddressOfEntryPoint` | Код начинается при запуске исполняемого файла |
| `.dll` | PE DLL | Да | `DllMain` / TLS callbacks | Код может выполняться при загрузке DLL в процесс |
| `.sys` | PE kernel driver | Да | `DriverEntry` | Код инициализации драйвера выполняется при загрузке драйвера |
| `.scr` | PE executable | Да | PE `AddressOfEntryPoint` | По сути исполняемый файл; `.scr` — в основном соглашение |
| `.cpl` | PE DLL | Да | `DllMain` + `CPlApplet` | Загружается инфраструктурой панели управления |
| `.ocx` | PE DLL / ActiveX | Да | `DllMain` + COM/ActiveX entry points | Инициализация DLL происходит при загрузке |
| `.drv` | PE DLL / legacy driver | Обычно | `DllMain` или точка входа, специфичная для драйвера | Зависит от конкретного типа `.drv` |
| `.efi` | PE/COFF EFI binary | Да | EFI entry point | Код выполняется при загрузке через UEFI |
| `.ax` | PE DLL | Да | `DllMain` + DirectShow interfaces | Инициализация DLL происходит при загрузке |
| `.acm` | PE DLL | Да | `DllMain` + ACM entry points | Загружается как кодек Audio Compression Manager |
| `.ime` | PE DLL | Да | `DllMain` + IME entry points | Инициализация DLL происходит при загрузке |
| `.tsp` | PE DLL | Да | `DllMain` + TAPI entry points | Инициализация DLL происходит при загрузке |
| `.pyd` | PE DLL | Да | `DllMain` + Python module initialization | Нативное расширение Python |
| `.node` | PE DLL | Да | `DllMain` + Node.js addon initialization | Нативный аддон Node.js |
| `.xll` | PE DLL | Да | `DllMain` + Excel XLL entry points | Загружается `EXCEL.EXE` |
| `.wll` | PE DLL | Да | `DllMain` + Word add-in loading | Загружается `WINWORD.EXE` |



## Скриптовые файлы
### Рассмотрите запрос для перечисленных в списке
| Расширение | Язык / тип           | Назначение / использование                                         | Контекст выполнения                                          |
|-----------|---------------------------|---------------------------------------------------------|------------------------------------------------------------|
| .bat      | Batch Script               | Задачи автоматизации командной строки из прошлого, простые скрипты     | `cmd.exe` (Command Prompt)                                  |
| .cmd      | Batch Script (NT style)    | Аналогичен `.bat`, предпочтителен в системах на базе NT         | `cmd.exe` (Command Prompt)                                  |
| .vbs      | VBScript                   | Задачи автоматизации, скрипты входа, административные скрипты           | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .vbe      | VBScript (encoded)         | Закодированная версия `.vbs` для обфускации              | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .ps1      | PowerShell Script          | Современные задачи автоматизации и настройки Windows       | PowerShell (`powershell.exe`, `pwsh.exe`)                   |
| .js       | JScript                    | Версия JavaScript от Microsoft для задач WSH          | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .jse      | JScript (encoded)          | Зашифрованная версия `.js` для обфускации               | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .wsf      | Windows Script File (XML)  | Смешивание VBScript, JScript и других скриптов в формате XML       | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .wsh      | Windows Script Host Settings | Настройки конфигурации для скриптов WSH                  | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .jar      | Java Archive               | Java-приложения, упакованные в один файл             | `java.exe` (консоль) / `javaw.exe` (без окна консоли)       |
| .hta      | HTML Application (HTA)     | GUI-скрипты Windows с использованием HTML, CSS и JScript/VBScript | `mshta.exe` (Microsoft HTML Application Host)          |
| .com      | MS-DOS Application / DOS Executable | Устаревшие исполняемые программы, небольшие утилиты командной строки | Выполняется напрямую как программа; в современной Windows классические 16-битные .com-программы работают через NTVDM в 32-битной Windows и не поддерживаются нативно в x64/ARM Windows |
| .chm     | Compiled HTML Help          | Файлы офлайн-справки/документации для программ Windows   | `hh.exe` (Microsoft HTML Help Viewer)                           |

## Скрипты запуска/входа в систему

Скрипты запуска и входа в систему (а также завершения работы или выхода из системы) — это скрипты автоматизации, которые выполняются (gpscript.exe) автоматически на компьютерах, присоединённых к домену, или при входе пользователей в систему, и обычно развёртываются с помощью объектов групповой политики (GPO) с контроллера домена в среде Windows Active Directory.

Startup/Shutdown
- Запускаются от имени: учётной записи Local System (высокие привилегии).

Logon/Logoff
- Запускаются от имени: текущего пользователя (высокие привилегии, если администратор).
### Типичное использование:
- Подключение сетевых дисков для всех пользователей
- Установка программного обеспечения
- Применение общесистемных настроек
- Запуск или настройка служб
- Запуск скриптов или исполняемых файлов

### Затрагиваемые разделы реестра

Когда скрипт запуска/входа выполняется через GPO:

| Раздел / путь | Назначение |
|-------------|---------|
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logon | Отслеживает скрипты входа пользователя, порядок их выполнения, статус, время последнего запуска и параметры. |
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logoff | Аналогичное отслеживание для скриптов выхода из системы. |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Startup | Информация отслеживания скриптов запуска (применяется ко всем пользователям). |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown | Информация о скриптах завершения работы. |

#### Ищите доступные для записи пользователем пути для скриптов и исполняемых файлов в дочернем процессе gpscript.exe, либо доступные для записи сетевые ресурсы или общие (SYSVOL). 
Прочитайте запускаемые скрипты и проверьте, нет ли каких-либо ошибок конфигурации, например других доступных для записи пользователем путей, несуществующих путей или конфиденциальной информации. Ищите возможные используемые пароли (net use z: \\server\share /user:domain\username password) или другую конфиденциальную информацию. 

**Категории ошибок конфигурации скриптов входа**
- SS1 – учётные данные в открытом виде
- SS2 – небезопасные разрешения (скрипт входа, изменяемый обычным пользователем)
- SS3 – несуществующие общие ресурсы (которые может создать обычный пользователь)
- SS4 - администраторы со скриптами входа

**Ошибки конфигурации скриптов входа**

1. SS1 - учётные данные в открытом виде внутри скрипта входа
2. SS2 - небезопасные разрешения на общий ресурс
3. SS2 - небезопасные разрешения на файл
4. SS2 - небезопасные разрешения NETLOGON/SYSVOL
5. SS2 - небезопасные разрешения на скрипт входа
6. SS2 - небезопасные разрешения на скрипт входа GPO
7. SS3 - несуществующие общие ресурсы
8. SS4 - администраторы со скриптом входа
9. SS4 - администраторы со скриптами входа, сопоставленными с несуществующим общим ресурсом



## MSIExec / MSI Repairs
##### Наше тестирование не дало никаких результатов в повышении привилегий в сценариях, где мы могли запустить edge и вырваться к командной строке cmd. Вероятно, это связано с тем, что браузеры на основе chromium олицетворяют пользователя/ограничивают процесс рендеринга запуском от имени SYSTEM и не позволяют internet explorer/edge запускать cmd или другие процессы от имени пользователя SYSTEM. Мы полагаем, что если установлен браузер не на основе chromium (например, firefox) или более старые версии, повышение привилегий могло бы быть возможным, если удалось бы запустить такой процесс и вырваться из него к командной строке.

Если вы хотите перечислить возможные события, связанные с этим, выполните запрос для msiexec.exe как родительского процесса с cmd.exe ИЛИ conhost.exe ИЛИ powershell.exe ИЛИ pwsh.exe в качестве дочернего процесса.
Свяжитесь с пользователями, по которым ваш запрос дал результаты, и спросите их, что они устанавливали/восстанавливали. Вы также можете проверить event.provider: "MsiInstaller" и event.code: (1033 OR 11707) или аналогичное, чтобы получить больше контекста о том, какой msi-установщик был установлен примерно в то же время.
Вы также можете попробовать это самостоятельно в Software Center и установить приложения, а затем поискать командные строки, которые можно приостановить до их исчезновения, выделив участок в окне. Затем вырвитесь, используя те же методы, упомянутые по ссылке ниже.



##### Пример запроса```
(event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1 AND winlog.event_data.IntegrityLevel: System AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))
OR
(event.provider: Microsoft-Windows-Security-Auditing AND event.code: 4688 AND winlog.event_data.TokenElevationType: "%%1936" AND winlog.event_data.MandatoryLabel: "S-1-16-16384" AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))