AUTORUN.INF и вирусы на USB: защита и чистка флешки

Файл autorun.inf в корне флешки сегодня — это в первую очередь индикатор, а не механизм: команду open= Windows с флешки не выполняет уже больше пятнадцати лет, но сам файл по-прежнему читается, и заражённый носитель продолжает выглядеть «как надо» — со своей иконкой и меткой. Основное зло приезжает рядом: ярлык .lnk с именем папки, исполняемый файл с двойным расширением, документ-приманка.

Отсюда типичная ошибка: администратор ставит NoDriveTypeAutoRun=255, считает вопрос закрытым и через месяц ловит тот же вирус снова — потому что одной этой настройки недостаточно, а половина советов из статей 2010 года в Windows 11 просто не работает. Ниже — что Windows фактически делает с autorun.inf, какие три политики (а не одна) закрывают автозапуск, как проверить состояние конкретной машины и как безопасно вычистить носитель.

Все технические утверждения сверены с документацией Microsoft, ADMX-файлами Windows 11 и замерами на живой системе; спорные места помечены явно.

TL;DR: закрыть автозапуск за пять минут

Включите политику «Turn off Autoplay» → All drives (значение 255) — параметр NoDriveTypeAutoRun.
Включите политику «Set the default behavior for AutoRun» → Do not execute any autorun commands (значение 1) — параметр NoAutorun.
Включите «Disallow Autoplay for non-volume devices» — закрывает MTP-устройства (телефоны, камеры).
Если носители не нужны на рабочих местах — политика «All Removable Storage classes: Deny all access» (Deny_All=1).
Проверьте результат одной командой:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer' |
    Select-Object NoAutorun, NoDriveTypeAutoRun

Ожидаемо: NoAutorun : 1, NoDriveTypeAutoRun : 255. Если вывод пуст или значения 0/145 — защиты нет, работает поведение по умолчанию.

Что Windows делает с autorun.inf при подключении флешки
Что осталось от автозапуска и что приходит вместо него
Проверка состояния машины
Три политики вместо одного ключа
Реестр без групповых политик
Домен и Intune: раскатка на парк
Запрет доступа к съёмным носителям
Чистка заражённой флешки
Аудит: кто и что подключал
Что изменилось в угрозах
Подводные камни
Чек-лист
FAQ
Итог

Что Windows делает с autorun.inf при подключении флешки

autorun.inf — обычный INI-файл, который оболочка Windows читает из корня носителя. Синтаксис описан в документации Microsoft по командам AutoRun; практически важны семь ключей.

Ключ	Назначение	Что важно знать
`open=`	программа, которая запускается при подключении	с Windows Vista выполнение идёт только через диалог, а не само
`shellexecute=`	то же через `ShellExecute`	обрабатывается так же, как `open=`
`action=`	текст пункта в диалоге AutoPlay	обязателен для съёмных носителей: без него диалог есть, но кнопки запуска нет
`icon=`	иконка диска в Проводнике	файл иконки должен лежать в том же каталоге, что и файл из `open=`
`label=`	метка тома	отображаются только первые 32 символа, остальное обрезается без ошибки
`UseAutoPlay=`	Vista и новее: убирает `open`/`shellexecute` из диалога AutoPlay; Windows 8 и новее: значение `0` отключает AutoPlay для этого устройства	`1` поддерживается везде, `0` — только с Windows 8
`CustomEvent=`	собственный обработчик AutoPlay	имя до 100 символов

Порядок при подключении: система замечает носитель → ищет autorun.inf в корне → разбирает INI → накладывает политики и настройки AutoPlay → показывает диалог или ничего не делает.

Две вещи из этой цепочки объясняют, почему вирусным флешкам до сих пор верят. Первая: icon= и label= применяются независимо от того, разрешён ли запуск команд, — носитель честно выглядит как «флешка Microsoft» или «Диск установки». Вторая: имя файла регистронезависимо, поэтому AutoRun.Inf и autorun.INF работают одинаково, а списки «известных имён» в самодельных сканерах этого не учитывают.

Важно: open= не выполняется автоматически с Windows Vista — система по умолчанию спрашивает, а не запускает. Именно поэтому старый совет «положить папку с именем autorun.inf» защищает от конкретного вируса 2008 года, но не от нынешних.

Что осталось от автозапуска и что приходит вместо него

Хронология изменений — она объясняет, почему на разных машинах одна и та же флешка ведёт себя по-разному:

Дата	Изменение	Источник
Октябрь 2008	MS08-067 — уязвимость службы сервера, использованная Conficker; червь активно распространялся через `autorun.inf`	Microsoft Security Bulletin MS08-067
Февраль 2009	KB967715 — исправлено, что параметр `NoDriveTypeAutoRun` не срабатывал на Windows XP и Server 2003	Microsoft Security Advisory 967940
Август 2009	KB971029 — AutoPlay ограничен CD/DVD; на USB-флешках, внешних дисках и сетевых ресурсах автоматический запуск отключён	Advisory 967940
Февраль 2011	KB971029 начал распространяться через Windows Update	Advisory 967940
Июль 2010	MS10-046 (CVE-2010-2568) — уязвимость оболочки, через которую Stuxnet запускался с ярлыка `.lnk`	Microsoft Security Bulletin MS10-046

Отдельная деталь из того же бюллетеня: на Windows Vista и Server 2008 параметры реестра, отключающие AutoRun, начинают действовать только после установки обновления MS08-038. То есть «прописал ключ — заработало» верно не для всех версий, и на старых сборках проверять надо фактическое поведение, а не наличие значения.

Что это значит практически. Команда open= с флешки сегодня почти нигде не выполняется сама, поэтому основная масса «USB-вирусов» приезжает другими путями:

ярлык вместо папки — .lnk с иконкой каталога и именем вида Фото 2026; двойной клик запускает cmd.exe или powershell.exe с командной строкой внутри ярлыка;
двойное расширение — Счёт.pdf.exe, где расширение .exe скрыто включённой по умолчанию опцией «Скрывать расширения для зарегистрированных типов файлов»;
приманка-документ с макросом или внешней ссылкой;
HID-эмуляция (BadUSB) — устройство представляется клавиатурой и печатает команды. Против этого политики автозапуска не помогают вообще: запрет нужен на уровне классов устройств.

Отсюда правильный вывод: autorun.inf на флешке — повод проверить носитель целиком, а не повод удалить один файл и успокоиться.

Проверка состояния машины

Политики важнее пользовательских настроек, поэтому смотреть надо оба места — машинное и пользовательское:

$paths = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer',
    'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer',
    'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Explorer',
    'HKLM:\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices'
)
foreach ($p in $paths) {
    if (Test-Path $p) {
        $v = Get-ItemProperty $p
        [pscustomobject]@{
            Key                = $p
            NoAutorun          = $v.NoAutorun
            NoDriveTypeAutoRun = $v.NoDriveTypeAutoRun
            NoAutoplayNonVolume= $v.NoAutoplayfornonVolume
            DenyAll            = $v.Deny_All
        }
    } else {
        [pscustomobject]@{ Key = $p; NoAutorun = '(ключа нет)'; NoDriveTypeAutoRun = '(ключа нет)';
                           NoAutoplayNonVolume = $null; DenyAll = $null }
    }
}

Замер на тестовой машине (Windows 11 Pro, сборка 10.0.26300) до внесения изменений:

Ключ	Значение	Толкование
`HKCU\...\Policies\Explorer\NoDriveTypeAutoRun`	`145` (`0x91`)	бит `0x04` (съёмные диски) не установлен
`HKLM\...\Policies\Explorer`	ключа нет	машинной политики нет
`HKLM\SOFTWARE\Policies\Microsoft\Windows\Explorer`	ключа нет	AutoPlay для MTP не ограничен
`HKLM\SOFTWARE\Policies\...\RemovableStorageDevices`	ключа нет	доступ к носителям не ограничен

Значение 145 — это состояние «по умолчанию», а не защита. Бит 0x04 в нём не выставлен, поэтому полагаться на пользовательскую настройку нельзя: её же пользователь и снимет через Параметры. Microsoft в таблице битов описывает 0x04, 0x08, 0x10, 0x20, 0x40; остальные биты в значении 0x91 документированного смысла не имеют, и трактовать его как «всё уже выключено» — ошибка.

Три политики вместо одного ключа

Все они лежат в одном месте: Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Политики AutoPlay (файл AutoPlay.admx). Точные имена политик, значения и ключи реестра — из самого ADMX-файла и из справочника CSP, а не из пересказов.

Политика (рус.)	Политика (ADMX)	Параметр реестра	Значения
Отключить автозапуск	`Autorun` — «Turn off Autoplay»	`NoDriveTypeAutoRun` в `SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer`	`181` — CD/DVD и съёмные; `255` — все диски
Поведение AutoRun по умолчанию	`NoAutorun` — «Set the default behavior for AutoRun»	`NoAutorun` в том же ключе	`1` — не выполнять команды; `2` — вернуть поведение до Vista
Запретить AutoPlay для устройств без тома	`NoAutoplayfornonVolume`	`NoAutoplayfornonVolume` в `SOFTWARE\Policies\Microsoft\Windows\Explorer`	`1` — запрещено

Есть и четвёртая, полезная в учебных классах и на общих машинах: «Prevent AutoPlay from remembering user choices» (DontSetAutoplayCheckbox=1) — система каждый раз спрашивает заново, а не запоминает выбор пользователя.

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

Чего эти настройки не делают: не мешают двойному клику по .exe и .lnk, не отключают монтирование носителя, не защищают от BadUSB и не запрещают чтение файлов с флешки. Это ровно три вещи из списка, и остальные закрываются отдельно.

Реестр без групповых политик

Для домашних редакций, Windows PE и скриптов первичной настройки те же значения ставятся напрямую:

$explorer = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer'
$policy   = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Explorer'

New-Item -Path $explorer -Force | Out-Null
New-ItemProperty -Path $explorer -Name NoAutorun          -Value 1   -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $explorer -Name NoDriveTypeAutoRun -Value 255 -PropertyType DWord -Force | Out-Null

New-Item -Path $policy -Force | Out-Null
New-ItemProperty -Path $policy -Name NoAutoplayfornonVolume -Value 1 -PropertyType DWord -Force | Out-Null

# принудительно применить политики и перезапустить оболочку
gpupdate /force
Stop-Process -Name explorer -Force

То же самое через reg.exe — для сценариев установки и WinPE, где PowerShell может быть недоступен:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer" ^
    /v NoAutorun /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer" ^
    /v NoDriveTypeAutoRun /t REG_DWORD /d 255 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Explorer" ^
    /v NoAutoplayfornonVolume /t REG_DWORD /d 1 /f

Два значения NoDriveTypeAutoRun полезно понимать, а не заучивать. Второй параметр той же группы — NoDriveAutoRun — задаёт запрет по буквам диска: бит 0 соответствует A:, бит 1 — B: и так далее, то есть NoDriveAutoRun=0x5 отключает автозапуск на A: и C:.

Биты NoDriveTypeAutoRun (первый байт, по документации Microsoft):

Бит	Класс диска	Что закрывает
`0x04`	`DRIVE_REMOVABLE`	съёмные диски, флешки
`0x08`	`DRIVE_FIXED`	жёсткие диски
`0x10`	`DRIVE_REMOTE`	сетевые диски
`0x20`	`DRIVE_CDROM`	CD/DVD
`0x40`	`DRIVE_RAMDISK`	RAM-диски

Изменения NoDriveTypeAutoRun вступают в силу после перезапуска Проводника — об этом сказано в самой документации. Перезагрузка компьютера не обязательна, но и не вредит.

Домен и Intune: раскатка на парк

В домене политика создаётся один раз и линкуется на OU с рабочими станциями (командлеты модуля GroupPolicy, он же RSAT):

$gpo = 'USB-AutoRun-Off'
New-GPO -Name $gpo | New-GPLink -Target 'OU=Workstations,DC=example,DC=local' -LinkEnabled Yes

$explorer = 'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer'
Set-GPRegistryValue -Name $gpo -Key $explorer -ValueName NoAutorun          -Type DWord -Value 1
Set-GPRegistryValue -Name $gpo -Key $explorer -ValueName NoDriveTypeAutoRun -Type DWord -Value 255
Set-GPRegistryValue -Name $gpo -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows\Explorer' `
    -ValueName NoAutoplayfornonVolume -Type DWord -Value 1

Проверка на клиенте — не «политика создана», а «политика применилась»:

gpresult /h C:\Temp\gpo.html
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer' |
    Select-Object NoAutorun, NoDriveTypeAutoRun

В Intune те же настройки лежат в профиле Administrative Templates → Windows Components/AutoPlay Policies; политики помечены как ADMX-backed и требуют SyncML-формат, поэтому значения задаются через шаблон, а не через «сырой» OMA-URI. Эквивалент в Policy CSP: Autoplay/SetDefaultAutoRunBehavior, Autoplay/TurnOffAutoPlay, Autoplay/DisallowAutoplayForNonVolumeDevices (Windows 10 1703 и новее).

Запрет доступа к съёмным носителям

Если на рабочих местах флешки не нужны вовсе, автозапуск — не главная проблема: носитель всё равно монтируется, и файлы с него можно запустить вручную. Закрывается политиками раздела System → Removable Storage Access:

Политика	Ключ и параметр	Эффект
All Removable Storage classes: Deny all access	`SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices` → `Deny_All=1`	носители не читаются и не пишутся
Removable Disks: Deny write access	`...\RemovableStorageDevices\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}` → `Deny_Write=1`	флешка только на чтение
Removable Disks: Deny execute access	тот же ключ → `Deny_Execute=1`	запрет запуска программ с носителя

Средний вариант — Deny_Write — обычно и нужен: сотрудник может принести файл с флешки, но заразить её обратно уже не получится. Побочные эффекты честно перечислю: перестают работать установка ПО с флешек, BitLocker To Go в режиме записи и часть «умных» принтеров, которые сохраняют сканы на USB. На терминальных серверах с перенаправлением USB-устройств Deny_All может отключить и перенаправленные устройства клиента — проверяйте на пилотной группе.

Чистка заражённой флешки

Порядок важен больше команд: если сначала открыть носитель в Проводнике, а потом «посмотреть, что там», один двойной клик по ярлыку запускает вредоносный код.

Не вставляйте носитель в рабочую машину. Нужен отдельный компьютер, виртуальная машина или Linux-хост — и на нём автозапуск должен быть уже выключен.
Снимите образ до любых изменений: dd if=/dev/sdb of=/evidence/usb.img bs=1M conv=noerror,sync. Это единственный способ потом понять, что именно было на носителе.
Смонтируйте только на чтение и посмотрите корень:

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT
sudo mount -o ro,nodev,nosuid,noexec /dev/sdb1 /mnt/usb
find /mnt/usb -maxdepth 1 \( -iname 'autorun.inf' -o -iname '*.lnk' -o -iname '*.exe' -o -iname '*.scr' \) -printf '%f\t%s\t%TY-%Tm-%Td\n'
sudo umount /mnt/usb

Разберите autorun.inf, если он есть: open=, icon=, shellexecute= называют имя полезной нагрузки. Файл рядом с autorun.inf — почти всегда то, что запускалось.
Удаляйте не по одному файлу, а по списку. Сначала составьте перечень подозрительного, покажите его владельцу данных, и только потом удаляйте. Чужой архив «на флешке для передачи» — не ваша собственность.
Если заражение массовое и данные не нужны — форматирование быстрее и надёжнее любой чистки.

На Windows с уже выключенным автозапуском то же самое делается штатными средствами, без Проводника:

$d = 'F:'
# показать всё, включая скрытое и системное
Get-ChildItem -LiteralPath $d -Force | Select-Object Name, Length, Attributes, LastWriteTime
# прочитать autorun.inf, не запуская ничего
Get-Content -LiteralPath (Join-Path $d 'autorun.inf') -ErrorAction SilentlyContinue
# снять атрибуты и удалить только этот файл
attrib -S -H -R "$d\autorun.inf"
Remove-Item -LiteralPath (Join-Path $d 'autorun.inf') -Force

Отдельная ловушка — атрибуты папок. Многие семейства помечают каталоги как Hidden+System, и после «лечения» файлы остаются невидимыми: пользователь считает, что данные пропали. Восстановление видимости — точечно по списку каталогов, а не одной командой по всему диску:

Get-ChildItem -LiteralPath 'F:\' -Directory -Force |
    Where-Object { $_.Attributes -band [IO.FileAttributes]::System } |
    ForEach-Object { $_.Attributes = $_.Attributes -band (-bnot [IO.FileAttributes]::System) }

Массовый attrib -s -h *.* /s /d по всему носителю снимает атрибуты и с системных файлов, которые действительно должны быть скрытыми, — потом не отличить одно от другого.

Аудит: кто и что подключал

Минимальный набор источников, который есть на любой машине без дополнительного ПО:

# 1. все USB-накопители, которые когда-либо подключались
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR' |
    ForEach-Object {
        $serial = Split-Path $_.PSPath -Leaf
        [pscustomobject]@{
            Device = ($serial -split '&')[0]
            Serial = $serial
            LastWrite = (Get-Item $_.PSPath).LastWriteTime
        }
    } | Sort-Object LastWrite -Descending | Select-Object -First 10

# 2. журнал установки драйверов: время подключения и идентификаторы
Select-String -Path 'C:\Windows\INF\setupapi.dev.log' -Pattern 'USBSTOR' |
    Select-Object -Last 20

Третий источник — операционный журнал Microsoft-Windows-DriverFrameworks-UserMode/Operational. На проверенной машине он выключен по умолчанию (IsEnabled = False), то есть «смотреть события USB» без предварительного включения бессмысленно:

wevtutil sl Microsoft-Windows-DriverFrameworks-UserMode/Operational /e:true
Get-WinEvent -LogName 'Microsoft-Windows-DriverFrameworks-UserMode/Operational' -MaxEvents 20 |
    Where-Object Id -in 2003, 2100, 2102

Номера событий зависят от сборки — включите журнал и посмотрите, какие идентификаторы появляются при подключении заведомо известной флешки. Требует проверки автором на вашем парке: набор ID в Windows 10 и Windows 11 отличается.

Что изменилось в угрозах

Прежняя версия этой статьи приводила проценты из вендорских отчётов («52 % атак в промышленных системах через съёмные носители») и названия кампаний. Я их убрал: методики подсчёта у поставщиков разные, проверить цифру по первоисточнику в рамках статьи невозможно, а читатель воспринимает её как измерение. Если такая статистика нужна — её место в отчёте со ссылкой на конкретный документ и датой.

Что можно утверждать без оговорок, потому что это следует из бюллетеней Microsoft: механизм автозапуска перестал быть основным каналом ещё в 2009–2010 годах — ровно после KB971029 и MS10-046. Дальше борьба сместилась: сначала к ярлыкам и уязвимостям оболочки, затем к социальной инженерии (файл-приманка с двойным расширением), а в целевых атаках — к эмуляции HID-устройств, где политики автозапуска не участвуют вовсе.

Практический смысл для администратора один: защита от «USB-вирусов» — это не один ключ реестра, а три слоя — запрет автозапуска, ограничение доступа к носителям и запрет запуска программ с них, плюс привычка не открывать чужую флешку двойным кликом.

Подводные камни

1. NoDriveTypeAutoRun без NoAutorun оставляет диалог. AutoPlay всё ещё предложит «Открыть папку для просмотра файлов», а пользователь нажмёт «Всегда выполнять это действие». Нужны оба параметра.

2. 181 и 255 — не «настройка силы», а разные охваты. 181 (0xB5) закрывает CD/DVD и съёмные носители, 255 — все диски. На файловом сервере с подключёнными сетевыми дисками разница видна сразу.

3. Значение 145, которое стоит по умолчанию, не защищает флешки. Бит 0x04 в нём не выставлен; «оно же уже настроено» — неверный вывод.

4. Правка HKCU бесполезна против пользователя. Он снимет её через Параметры; при конфликте побеждает компьютерная политика, поэтому писать надо в HKLM и, лучше, через GPO.

5. gpupdate /force не перезапускает Проводник. Для NoDriveTypeAutoRun документация прямо требует перезапуска оболочки — без него эффект появится не сразу и это выглядит как «политика не работает».

6. Папка с именем autorun.inf — не защита, а помеха. Она мешает robocopy и части инсталляторов, ломает резервное копирование носителя, а удаляется целевой атакой в одну команду. Против вирусов 2008 года работала, против нынешних — нет.

7. StorageDevicePolicies\WriteProtect — старый приём без описания в ADMX. Он встречается в советах и иногда работает, но в актуальной документации Microsoft и в шаблонах политик Windows 11 его нет. Требует проверки автором на конкретной сборке: полагаться на него как на штатную защиту нельзя.

8. Deny_All ломает больше, чем кажется. Установка ПО с флешек, BitLocker To Go, сканирование в файл на USB, перенаправление USB на терминальных серверах. Начинайте с пилотной группы и с Deny_Write.

9. Чистка на живой системе может не дать эффекта. Пока носитель подключён к заражённой машине, удалённый autorun.inf может быть создан заново работающим процессом. Сначала изоляция, потом удаление.

10. Аудит без включённого журнала — самообман. DriverFrameworks-UserMode/Operational выключен по умолчанию; «в журнале пусто» означает «журнал не пишется», а не «подключений не было».

Чек-лист

[ ] NoAutorun = 1 в HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer.
[ ] NoDriveTypeAutoRun = 255 (или 181, если CD/DVD должны работать) в том же ключе.
[ ] NoAutoplayfornonVolume = 1 в HKLM\SOFTWARE\Policies\Microsoft\Windows\Explorer.
[ ] Проверено, что политика применилась: gpresult /h, а не только факт создания GPO.
[ ] Проводник перезапущен, поведение проверено на тестовой флешке с autorun.inf.
[ ] Для машин без съёмных носителей решено, нужен ли Deny_Write или Deny_All.
[ ] На рабочих местах, где носители разрешены, включён DontSetAutoplayCheckbox, чтобы выбор не запоминался.
[ ] Журнал DriverFrameworks-UserMode/Operational включён там, где ведётся расследование.
[ ] Есть отдельная изолированная машина (или Linux-хост) для разбора чужих носителей.
[ ] Порядок чистки закреплён регламентом: образ → чтение только на чтение → список → удаление.

FAQ

Достаточно ли отключить AutoPlay в Параметрах Windows 11? Нет. Пользовательская настройка снимается пользователем же и не закрывает AutoRun-команды. Нужны политики в HKLM, а в домене — GPO.

Почему на флешке до сих пор появляется autorun.inf, если автозапуск отключён? Потому что файл создаёт вредоносный код, а не система. Сам по себе он уже ничего не запускает, но icon= и label= продолжают работать, а рядом обычно лежит полезная нагрузка — ярлык или .exe.

Удалить autorun.inf — достаточно? Нет. Нужно проверить корень на .lnk, .exe, .scr, вложенные каталоги с атрибутами Hidden+System и только потом возвращать носитель в работу.

Помогает ли autorun.inf-папка? Против конкретного семейства — да, как «занятое имя». Как средство защиты — нет: она удаляется, мешает бэкапу и не влияет на ярлыки и исполняемые файлы.

Работает ли это на терминальном сервере? Политики применяются к сессии так же, но перенаправление USB-устройств с клиента идёт мимо Deny_All в части конфигураций. Проверяйте на пилоте: сочетание перенаправления и запрета носителей ведёт себя по-разному в зависимости от версии RDP-клиента.

Можно ли просто запретить исполняемые файлы с флешек? Можно — политикой Removable Disks: Deny execute access, но она не мешает запуску .lnk, который вызывает уже системный cmd.exe. Ярлыки закрываются отдельно: отключением отображения расширений не лечится, помогает только запрет автозапуска и обучение.

Итог

autorun.inf давно перестал быть механизмом запуска и остался индикатором: файл читается, иконка и метка применяются, а команда open= с флешки не выполняется с Windows Vista. Полезное действие из этого следует одно — перестать лечить «автозапуск» одним ключом реестра и собрать три уровня: политики AutoPlay (NoAutorun, NoDriveTypeAutoRun, NoAutoplayfornonVolume), ограничение доступа к носителям (Deny_Write или Deny_All) и запрет запуска программ с них.

Отдельно стоит запомнить две цифры: 181 и 255. Первая закрывает CD/DVD и съёмные носители, вторая — все диски; значение 145, которое часто стоит по умолчанию, флешки не защищает вовсе.

Цитата: Автозапуск умер в 2009 году, а привычка лечить его одной строкой реестра — нет; поэтому на флешке по-прежнему лежит autorun.inf, и администратор по-прежнему удивляется, что «всё было отключено».

Связанные материалы

ArkMicroChips ARK3116: USB-UART контроллер — работа с USB-устройствами на уровне драйверов и идентификаторов.
ProFTPD: настройка и ограничения доступа — как устроены ограничения по пользователю и каталогу в другом сервисе.
Рубрика «Информационная безопасность» — остальные материалы по защите рабочих мест.
Рубрика «Системное администрирование» — эксплуатация Windows и Linux в одном месте.

LLM Summary

Тема: autorun.inf, автозапуск с USB-флешек и защита рабочих мест Windows 10/11 в 2026 году.
Ключевой факт: с Windows Vista команда open= не выполняется автоматически (показывается запрос), а обновление KB971029 (август 2009) ограничило AutoPlay только CD/DVD; icon= и label= при этом продолжают работать.
Что закрывает автозапуск: политики Turn off Autoplay (NoDriveTypeAutoRun, 181 — CD/DVD и съёмные, 255 — все диски), Set the default behavior for AutoRun (NoAutorun=1), Disallow Autoplay for non-volume devices (NoAutoplayfornonVolume=1); ключи — HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer и HKLM\SOFTWARE\Policies\Microsoft\Windows\Explorer.
Ограничение носителей: Deny_All=1 или Deny_Write=1 в HKLM\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices (для класса дисков — подключ {53f5630d-b6bf-11d0-94f2-00a0c91efb8b}).
Проверка: Get-ItemProperty 'HKLM:\...\Policies\Explorer' | Select NoAutorun, NoDriveTypeAutoRun; в домене — gpresult /h; замер по умолчанию на Windows 11 (10.0.26300): NoDriveTypeAutoRun=145, машинных политик нет.
Чистка носителя: сначала образ (dd), затем монтирование только на чтение, инвентаризация autorun.inf, *.lnk, *.exe, Hidden+System-каталогов, и лишь потом удаление; форматирование при массовом заражении.
Аудит: HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR, C:\Windows\INF\setupapi.dev.log, журнал Microsoft-Windows-DriverFrameworks-UserMode/Operational (по умолчанию выключен).
Ограничения подхода: политики не защищают от BadUSB/HID-эмуляции, от двойного клика по .exe и .lnk, от копирования файлов на носитель.
Не подтверждено: параметр StorageDevicePolicies\WriteProtect (нет в ADMX и документации) и точные ID событий USB в конкретной сборке — требуют проверки на месте.

AUTORUN.INF и вирусы на USB-флешках: что работает в 2026 году