Лидеры форума

ИИ — полезная штука, но, к сожалению, бесплатные версии, как тот же Google Gemini Flash, тупенькие на уровне 12b моделей, делают колоссальное число ошибок по мелочам. Яблочко от яблони... Мало того, "новое" у них обычно старое с отставанием на год, и это в лучшем случае. Я сейчас как раз занимаюсь новой, уже 3-й версией своего "Клавиатурного помощника". В нём будет поддержка локального ИИ, горячих ИИ-клавиш, голосовых команд, голосового ввода и вспомогательной LLM для переводов, правки текста и т.п. Именно локального ИИ без необходимости обращения в сеть и сопутствующих утечек данных И это не для старого железа — нужно как минимум много памяти и современный процессор, в идеале хотя бы RTX 5060 Ti 16 ГБ в качестве ускорителя. А результат, ну, такой себе. ИИ слишком склонен ошибаться, и доверять ему что-то серьёзное пока не стоит, даже код пишет, который как-то работает, но в нём масса мелких и незаметных ошибок и уязвимостей. Текст исправлен с помощью Google Gemma 4 E4B.

Вы сказали: "Найди все новые ключи которые появились 2026 г. и ранее не использовались... Можешь ?" *Да, я могу помочь* составить список новых ключей реестра и путей автозагрузки, которые вредоносное ПО использует в текущих кампаниях (включая модификации 2026 года), маскируясь под легальные системные компоненты. ( скопирую частично) : * *|HKLM\SOFTWARE\Classes\Protocols\Filter|* и *|\Handler|* — новые модификации Adware перехватывают протоколы edge:// или msproedg:// для подмены поисковой выдачи. * *|HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss|* — использование подсистемы WSL для скрытого автозапуска Linux-ориентированных рекламных модулей, незаметных для стандартных триггеров автозагрузки Windows. Современные зловреды (особенно Adware и майнеры) научились прописываться в тихий автозапуск без создания классических ключей |Run| или |Services|. Они используют встроенный механизм Windows 10/11 — *псевдонимы выполнения приложений*. * *Суть*: В реестре создается связь в ветке |HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths| или через механизм |AppXPackage|. Зловред подменяет вызов легальной команды (например, при наборе пользователем |notepad| или |calc| в строке «Выполнить») и запускает свое тело. * *Что добавить в памятку*: Обращать внимание на появление кастомных записей в блоке «Псевдонимы приложений» и проверять, куда перенаправляются стандартные системные вызовы. 2. Подмена через каталоги |Lxss| (WSL — Windows Subsystem for Linux) Это одна из самых опасных современных тенденций, так как многие антивирусы до сих пор слабо сканируют Linux-среду внутри Windows. * *Суть*: Майнеры и стилеры прописывают свой запуск внутри дистрибутива WSL (ключ реестра |HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss|). При старте Windows запускается скрытая фоновая сессия WSL, которая активирует ELF-бинарник (Linux-вирус). В логах автозапуска Windows это выглядит как легальный старт службы |wsl.exe|, но с хитрыми аргументами. * *Что добавить в памятку*: Формула «А+В+С»: если |wsl.exe| запускается автоматически с флагами |-d| (конкретный дистрибутив) или скрытыми bash-скриптами — это 100% повод для изоляции и проверки содержимого виртуального диска VHDX. 3. Продвинутый Timestomping с подделкой под апдейты ОС Раньше вирусописатели просто копировали даты у соседних файлов (|kernel32.dll| и т.д.). Теперь они действуют умнее: * *Суть*: Дата создания файла выставляется ровно на день/час крупного официального обновления Windows (например, подстраиваются под график Patch Tuesday от Microsoft). Аналитик смотрит на лог uVS, видит дату (например, |14.10.2025|) и думает: «А, ну это тогда накопительный апдейт прилетел, файл чистый». * *Что добавить в памятку*: Правило проверки контрольных сумм. Не верить датам, даже если они идеально совпадают со временем системного обновления. Если у файла из папки |System32| с «правильной» датой обновления отсутствует валидная ЭЦП (или статус |Цифр. подпись: НЕТ|) — это критический триггер. 4. Атаки типа Living off the Land (LotL) через новые системные утилиты Вместо использования заезженных |powershell.exe| или |cmd.exe|, которые сейчас жестко блокируются любым EDR/антивирусом, малварь перешла на легальные, но редкие утилиты Windows (LOLBins). * *Суть*: Для скачивания и запуска вредоносного кода используются системные компоненты: o |curl.exe| (теперь встроен в Windows) — для скрытой загрузки полезной нагрузки. o |tar.exe| — для распаковки зашифрованных архивов со стилерами прямо «на лету». o |winget.exe| (Windows Package Manager) — для скачивания вредоносных утилит из легальных репозиториев. * *Что добавить в памятку*: В uVS нужно тщательно анализировать параметры запуска командной строки в Планировщике задач (|TASKS|), если там фигурируют |curl|, |tar| или |bitsadmin|, качающие что-то с внешних IP-адресов. 6. Скрытые модификации через COM-объекты (COM Hijacking без изменения файлов) Вместо перезаписи файлов в |System32| или создания явных ключей |Run|, малварь перехватывает легальные системные интерфейсы через реестр. * *Суть*: Зловред прописывает путь к своей вредоносной DLL в ветку *|HKCU\Software\Classes\CLSID\{GUID}\InprocServer32|*. При этом берется GUID легального и часто используемого компонента Windows (например, Проводника, контекстного меню или планировщика). Как только система или пользователь совершает обычное действие (открывает папку, кликает правой кнопкой мыши), Windows автоматически подгружает вредоносную DLL. * *Что добавить в памятку*: В uVS такие объекты часто попадают в категорию «Подозрительные CLSID» или скрытые расширения оболочки. Если в ветке |HKCU| (пользовательский уровень) переопределяется системный GUID, который по умолчанию должен жить только в |HKLM| (уровень системы) — это явный признак перехвата. 7. Спуфинг цифровой подписи через уязвимости каталогов (Catalog Signing Spoofing) Малварь научилась обходить базовую проверку подписей, из-за чего в логах некоторых утилит файл может ошибочно помечаться как «Подписан Microsoft». * *Суть*: Используются уязвимости в механизме проверки файлов через каталоги безопасности Windows (|.cat| файлы). Вредоносный бинарник модифицируется таким образом, что его хэш совпадает с хэшем легального файла в базе данных каталогов (используются коллизии или специфические уязвимости парсинга). * *Что добавить в памятку*: Правило двойной проверки. Если файл находится в нетипичном месте (например, |C:\Users\...\Temp\svchost.exe|), но uVS или ОС рапортует, что у него «Валидная подпись Microsoft» — необходимо принудительно отправлять хэш файла на VirusTotal через встроенную функцию uVS или проверять подпись сторонними утилитами (например, |Sigcheck| от Sysinternals) с проверкой отзывов сертификатов. 8. Эксплуатация механизма «Служб доставки обновлений» браузеров (Edge/Chrome Maintenance) Рекламное ПО (Adware) и кликеры ушли от создания собственных явных служб и теперь паразитируют на легальных планировщиках браузеров. * *Суть*: Вредоносный скрипт не создает новую задачу в Планировщике. Вместо этого он модифицирует параметры /уже существующей/ легальной задачи, например, |MicrosoftEdgeUpdateTaskMachineCore|. В оригинальную команду дописывается скрытый аргумент (аргумент-паразит), который раз в сутки скачивает или запускает рекламный модуль. Аналитик видит знакомое имя задачи Edge, видит легальный путь к апдейтеру и пропускает её. * *Что добавить в памятку*: При анализе задач Планировщика (|TASKS|) в uVS нужно смотреть не только на имя файла, но и *полностью разворачивать строку аргументов*. Любые добавленные URL-адреса, вызовы |cmd /c|, или сторонние пути в параметрах легальных служб обновления — это стопроцентный признак компрометации. 10. Фейковые системные переменные в путях автозапуска Обман визуального восприятия аналитика через манипуляцию переменными среды. * *Суть*: В реестре или планировщике путь к файлу прописывается как |%SystemRoot%\System32\drivers\malware.sys|. Но перед этим на уровне пользователя (|HKCU\Environment|) создается кастомная переменная |%SystemRoot%|, которая указывает вовсе не на |C:\Windows|, а на |C:\Users\Public\Documents|. В итоге аналитик глазами видит «безопасный» системный путь, а система при загрузке идет в скрытую пользовательскую папку. * *Что добавить в памятку*: Всегда проверять блок «Переменные окружения» в начале лога uVS. Любые попытки переопределить стандартные переменные вроде |%SystemRoot%|, |%WinDir%| или |%ProgramFiles%| на уровне текущего пользователя — это критическая угроза.