DLL sideloading в WinSCP: как проверить путь загрузки библиотеки
В статье на Хабре автор разбирает подмену version.dll при запуске WinSCP. Windows ищет DLL по заданному порядку: каталог приложения проверяется раньше системных каталогов — это соответствует документации Microsoft. SafeDllSearchMode отодвигает текущий каталог, но не убирает раннюю проверку папки с .exe. Если рядом с программой окажется библиотека с ожидаемым именем, процесс может загрузить её вместо системной.
Сначала автор анализирует Import Table WinSCP и исключает Known DLLs — библиотеки из системного набора. Затем через Procmon проверяет реальные попытки загрузки: NAME NOT FOUND в каталоге приложения и Load Image из SysWOW64 показывают путь загрузчика. Так из 32 импортов выделяется version.dll: она не входит в Known DLLs, используется напрямую и требует трёх функций.
Дальше собран учебный прокси на Rust. Он экспортирует интерфейс штатной библиотеки, передаёт вызовы оригиналу, а в тесте запускает MessageBoxW. WinSCP продолжает работать, поэтому PoC показывает именно механизм перехвата.
Главный результат — практическая методика: смотреть не только на список импортов, но и на фактический порядок поиска DLL. Разработчикам стоит использовать полные пути и безопасные флаги LoadLibraryEx, защитникам — отслеживать неожиданные DLL в каталоге приложения и проверять происхождение дистрибутивов. Сам факт загрузки ещё не доказывает уязвимость WinSCP: риск возникает, если атакующий может подменить файлы или подсунуть изменённую сборку.
Если у кого-то есть приглашение на Хабр, поддержите начинающего автора: отправьте его этой публикации, чтобы материал увидело и обсудило сообщество)
Или просто пошарьте коллегам, будет приятно и мне, и автору статьи!)
🌚 @poxek | 🌚 @poxek_ai | 📲MAX
В статье на Хабре автор разбирает подмену version.dll при запуске WinSCP. Windows ищет DLL по заданному порядку: каталог приложения проверяется раньше системных каталогов — это соответствует документации Microsoft. SafeDllSearchMode отодвигает текущий каталог, но не убирает раннюю проверку папки с .exe. Если рядом с программой окажется библиотека с ожидаемым именем, процесс может загрузить её вместо системной.
Сначала автор анализирует Import Table WinSCP и исключает Known DLLs — библиотеки из системного набора. Затем через Procmon проверяет реальные попытки загрузки: NAME NOT FOUND в каталоге приложения и Load Image из SysWOW64 показывают путь загрузчика. Так из 32 импортов выделяется version.dll: она не входит в Known DLLs, используется напрямую и требует трёх функций.
Дальше собран учебный прокси на Rust. Он экспортирует интерфейс штатной библиотеки, передаёт вызовы оригиналу, а в тесте запускает MessageBoxW. WinSCP продолжает работать, поэтому PoC показывает именно механизм перехвата.
Главный результат — практическая методика: смотреть не только на список импортов, но и на фактический порядок поиска DLL. Разработчикам стоит использовать полные пути и безопасные флаги LoadLibraryEx, защитникам — отслеживать неожиданные DLL в каталоге приложения и проверять происхождение дистрибутивов. Сам факт загрузки ещё не доказывает уязвимость WinSCP: риск возникает, если атакующий может подменить файлы или подсунуть изменённую сборку.
Если у кого-то есть приглашение на Хабр, поддержите начинающего автора: отправьте его этой публикации, чтобы материал увидело и обсудило сообщество)
Или просто пошарьте коллегам, будет приятно и мне, и автору статьи!)
🌚 @poxek | 🌚 @poxek_ai | 📲MAX