Вирус нет групповой политики

Продолжаем цикл статей о противодействии классу вирусов-шифровальщиков в корпоративной среде. В предыдущих частях мы рассмотрели настройку защиты на файловых серверах с помощью FSRM и использования теневых снимков дисков для быстрого восстановления данных после атаки. Сегодня речь пойдет о способе предотвращения запуска исполняемых файлов вирусов-шифровальщиков (в том числе обычных вирусов и троянов) на ПК пользователей.

Помимо антивируса, еще одним барьером для предотвращения запуска вредоносного ПО на компьютерах пользователей могут быть политики ограниченного использования программ. В среде Windows это могут быть технология Software Restriction Policies или AppLocker. Мы рассмотрим пример использования Software Restriction Policies для защиты от вирусов.

Software Restriction Policies (SRP) предоставляют возможность разрешать или запрещать запуск исполняемых файлов с помощью локальной или доменной групповой политики. Метод защиты от вирусов и шифровальщиков с помощью SRP предполагает запрет запуска файлов из определенных каталогов в пользовательском окружении, в которые, как правило, попадают файлы или архивы с вирусом. В подавляющем большинстве случаев файлы с вирусом, полученные из интернета или из электронный почты оказываются внутри каталога %APPDATA% профиля пользователя (в нем же находится папки %Temp% и Temporary Internet Files). В этом же каталоге хранятся распакованные временные копии архивов, когда пользователь не глядя открывает архив полученный по почте или скачанный с интернета.

При настройке SRP могут быть использованы две стратегии:

• Разрешить запуск исполняемых файлов на компьютере только из определенных папок (как правило, это каталоги %Windir% и Program Files / Program Files x86) – это самый надежный метод, но требует длительного периода отладки и выявления нужного ПО, которое не работает в такой конфигурации
• Запрет запуска исполняемых файлов из пользовательских каталогов, в которых в принципе не должно быть исполняемых файлов. Именно в этих каталогах в большинстве случаев оказываются файлы вируса при появлении на компьютере. Кроме того, у пользователя, не обладающего правами администратора, просто отсутствуют права на запись в каталоги системы кроме своих собственных. Поэтому вирус просто не сможет поместить свое тело куда-либо кроме директорий в профиле пользователя.

Мы рассмотрим создание SRP по второму варианту, как достаточно надежному и менее трудоемкому во внедрении. Итак, создадим политику, блокирующую запуск файлов по определенным путям. На локальном компьютере это можно сделать с помощью консоли gpedit.msc, если политика должна использоваться в домене, нужно в консоли Group Policy Management (gpmc.msc) создать новую политику и назначить ее на OU с компьютерами пользователей.

В консоли редактора GPO перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings . Щелкните ПКМ по Software Restriction Policies и выберите New Software Restriction Policies.

Выберите раздел Additional Rules, и создайте новое правило New Path Rule.

Создадим правило, запрещающее запуск исполняемых файлов с расширением *.exe из каталога %AppData%. Укажите следующие параметры правила:

• Path: %AppData%\*.exe
• Security Level: Disallowed
• Description: Блокировка запуска exe файлов из папки %AppData%

Аналогичным образом нужно создать запрещающие правила для путей, перечисленных в таблице. Т.к. переменные окружения и пути в Windows 2003/XP и Windows Vista/выше отличаются, в таблице указаны значения для соответствующих версий ОС. Если у вас в домене еще остались Windows 2003/XP, для них лучше создать отдельную политики и назначить ее на OU с компьютерами с использованием WMI фильтра GPO по типу ОС.

Описание	Windows XP и 2003	Windows Vista/7/8/10, Windows Server 2008/2012
Запрет запуска файлов из %LocalAppData%	%UserProfile%Local Settings*.exe	%LocalAppData%\*.exe
Запрет запуска файлов из вложенных каталогов %AppData%:	%AppData%\*\*.exe	%AppData%\*\*.exe
Запрет запуска файлов из вложенных каталогов %LocalAppData%	%UserProfile%\Local Settings\*\*.exe	%LocalAppData%\*\*.exe
Запрет запуска exe файлов из архивов, открытых с помощью WinRAR	%UserProfile%\Local Settings\Temp\Rar*\*.exe	%LocalAppData%\Temp\Rar*\*.exe
Запрет запуска exe файлов из архивов, открытых с помощью 7zip	%UserProfile%\Local Settings\Temp\7z*\*.exe	%LocalAppData%\Temp\7z*\*.exe
Запрет запуска exe файлов из архивов, открытых с помощью WinZip	%UserProfile%\Local Settings\Temp\wz*\*.exe	%LocalAppData%\Temp\wz*\*.exe
Запрет запуска exe файлов из архивов, открытых с помощью встроенного архиватора Windows	%UserProfile%\Local Settings\Temp\*.zip\*.exe	%LocalAppData%\Temp\*.zip\*.exe
Запрет запуска exe файлов из каталога %temp%	%Temp%\*.exe	%Temp%\*.exe
Запрет запуска exe файлов из вложенных каталогов %temp%	%Temp%\*\*.exe	%Temp%\*\*.exe
Опционально. Запрет запуска exe фалов из любых каталогов в профиле пользователя .	%UserProfile%\*\*.exe	UserProfile%\*\*.exe

Вы можете добавить собственные каталоги. В нашем примере получился примерно такой список запрещающих правил SRP.

Осталось проверить действие политики Software Restriction Policies на клиентском компьютере. Для этого обновите политики командой gpupdate /force и попробуйте запустить исполняемый *.exe файл из любого из указанных каталогов. Должно появиться сообщение об ошибке:

Попытки запуска исполняемых файлов из защищенных каталогов, которые были блокированы политиками SRP можно отслеживать с помощью журнала событий Windows. Интересующие нас события находятся в разделе Application, и имеют Event ID 866, с источником SoftwareRestrictionPolicies и примерно таким текстом:

Итак, мы показали общий пример техники использования политики ограниченного использования программ (SRP или Applocker) для блокировки вирусов, шифровальщиков и троянов на компьютерах пользователей. Рассматриваемая методик позволяет существенно усилить степень защиты систем от запуска вредоносного кода пользователями.

Групповые политики — это основной инструмент управления пользователями в домене. С их помощью администратор может настраивать практически любые параметры рабочей среды пользователя. Все, начиная от запрета на запуск определенных программ и заканчивая рисунком на рабочем столе можно задать через групповые политики. Управление политиками осуществляется на уровне домена и только члены группы администраторов домена или предприятия имеют к ним доступ.

А можно ли отменить действие групповых политик на компьютере, не будучи при этом администратором домена? Сегодня мы попробуем это выяснить. В качестве подопытного возьмем компьютер с установленной на нем Windows 7, являющийся членом домена. Все действия будем проводить под обычной учетной записью, не имеющей в домене никаких административных полномочий.

За применение групповых политик на локальном компьютере в Windows 7 отвечает служба Group Policy Client (gpsvc). Ее состояние можно посмотреть прямо в Диспетчере задач, на вкладке Службы.

Или в оснастке Службы (Services).

Первое что приходит в голову — просто остановить службу и установить режим запуска в Disabled. Но не все так просто, как кажется. Служба gpsvc запускается от имени локальной системы, и не остановить, не изменить параметры запуска ее из графической оснастки мы не сможем.

Как вариант можно с помощью утилиты psexec запустить командную консоль от имени системы и затем остановить службу командой net stop gpsvc

Но решение это временное. Хотя служба и остановлена, изменить параметры ее запуска мы все равно не сможем, и при следующей перезагрузке она будет запущена. Чтобы изменить режим запуска службы нам потребуется правка реестра.

Первым делом нам надо изменить владельца раздела. Для этого идем в дополнительные параметры безопасности и выбираем владельцем свою учетную запись.

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

Теперь можно вернуться к настройкам службы. За режим запуска отвечает параметр Start. По умолчанию он равен 2, что означает режим запуска Авто. Для отключения службы ставим 4.

И еще. Отключив таким образом службу клиента групповой политики, вы периодически будете получать в трее уведомления о недоступности службы Windows.

Чтобы этого избежать, можно удалить (предварительно сохранив) раздел реестра HKLM\SYSTEM\CurrentControlSet\Control\Winlogon\Notifications\Components\GPClient

Таким вот нехитрым способом можно отключить действие групповых политик. При этом совсем не обязательно обладать административными правами в домене, достаточно лишь входить в группу локальных администраторов на компьютере. Правда такой номер может пройти только на компьютерах с Windows 7 или Vista. В более ранних ОС службы gpsvc нет, а за применение групповых политик отвечает служба Winlogon.

Да, чуть не забыл. Все действия, описанные в статье, я проводил исключительно в познавательных целях 🙂 Делать подобное в сети предприятия крайне не рекомендуется, кое где за это могут и уволить. И перед любым вмешательством в реестр обязательно делайте его резервную копию, чтобы в случае чего оперативно откатить изменения.

Не знаю, чем руководствовались люди из Microsoft, когда проектировали и создавали систему групповых политик в Windows, но получилось у них не очень. Система получилась гибкой и функциональной, но с немалым количеством лазеек, позволяющих обойти ограничения и добраться до тех мест ОС, доступ к которым запрещен.

По правде говоря, групповые политики были исследованы вдоль и поперек еще пять лет назад. Однако используемые решения мало чем изменились. Многие баги по-прежнему работают. Кроме того, появляются новые приемы для обхода групповых политик. Поэтому мы решили собрать для тебя некоторый набор рецептов, чтобы ты, во-первых, мог взять на вооружение, а во-вторых, перестал верить в то, что групповые политики — это панацея. При всем удобстве их использования они не могут обеспечить должный уровень защиты. Но обо всем по порядку.

Что такое Групповые политики (Group Policy)?

Если верить скучным определениям, то групповые политики (или Group Policy) — это эффективный и централизованный механизм управления многочисленными параметрами операционных систем и приложений. Групповые политики позволяют админам определять правила, в соответствии с которыми настраиваются параметры рабочей среды как для пользователей, так и для компьютеров. Проще говоря, это довольно мощный инструмент для ограничения в действиях обычных пользователей. Существует масса различных политик и прав, с помощью которых можно запретить вызов диспетчера задач или редактора реестра, запретить доступ к меню "Пуск", а также довольно гибко ограничить запуск программного обеспечения (это реализуется с помощью так называемых Software Restriction Policies). Является ли этот механизм эффективным? Лишь отчасти. Доступ к шорткатам, запуск левого ПО и системных приложений, изменение настроек — все это достаточно легко запрещается с помощью групповых политик, и с этой точки зрения можно сказать спасибо разработчикам ОС. Но, увы, как это обычно бывает, эти политики зачастую можно обойти. Тут стоит сделать оговорку. Все политики можно разбить на две категории — для компов и для пользователей. Групповые политики доступны как в домене, так и на локальном компе. Если речь идет о локальной машине, то их можно посмотреть через специальную оснастку gpedit.msc (secpol.msc). В данной статье основной акцент сделан именно на доменные групповые политики. Итак, приступим.

Трюк 1. Обходим загрузку политик

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

1. Админ создает объект групповой политики.
2. Привязывает его к каким-то элементам домена.
3. При входе в домен комп отправляет запрос на получение политик и получает их в ответ от домена.
4. При входе пользователя выполняется аналогичный запрос, но уже по пользовательским политикам.

Итак, что мы здесь видим: политики подгружаются на стадии входа в систему. Здесь есть небольшая фича. По умолчанию обновление политик выполняется каждые 5 минут. Но если политики не были получены во время входа в систему, то обновляться они не будут! Вырисовывается элементарный способ, как эту особенность можно использовать:

1. Вынимаем патч-корд из компа.
2. Включаем комп и логинимся под своей учеткой.
3. Подключаем патч-корд обратно.

Даже при отсутствии доступа в сеть мы сможем войти в домен, так как винда ранее закешировала наш логин и пароль (это произошло во время предыдущего входа в систему). Но уже без применения групповых политик. При этом мы спокойно сможем использовать ресурсы сети, так как патч-корд к этому моменту будет на месте, а со всякими авторизациями на удаленных ресурсах справится сама винда. Стоит добавить, что в безопасном режиме винды групповые политики вообще не действуют. Комментарии, я думаю, излишни.

Трюк 2. Как происходит проверка политик?

Важно понимать, на каком этапе происходит сопоставление действия, которое хочет выполнить пользователь, с теми ограничениями групповых политик, которые на него накладываются. Сперва давай разберемся, где расположены политики. Изначально, конечно, на контроллере домена, откуда уже передаются на машины в локальной сети. После получения групповых политик на клиентской машине они сохраняются в реестре винды в следующих местах (приведены основные ветки):

Политики для компа:

• HKEY_LOCAL_MACHINESoftwareMicrosoft WindowsCurrentVersionPolicies
• HKEY_LOCAL_MACHINESoftwarePolicies

Политики для пользователей:

• HKEY_CURENT_USERSoftwareMicrosoft WindowsCurrentVersionPolicies
• HKEY_CURENT_USERSoftwarePolicies

Когда запускается какой-то процесс, то в нем (то есть в userspace’е) производится проверка данных веток реестра (через подгруженную библиотеку advapi.dll) на те или иные ограничения, которые потом кешируются/сохраняются в памяти процесса. Они проверяются, когда пользователь выполняет какое-то действие, например запуск ПО. В чем подвох? В том, что контроль производится из самого процесса. То есть если процесс "не захочет" проверять политики, то ничто его не заставит их соблюдать. Никакого общего мониторинга не производится! Отсюда вывод: если мы каким-то образом сможем запустить произвольный процесс, то политики нам уже не страшны. Сделать как правило — не проблема. Даже если нет возможности закачать программу на хост, можно выполнить ее удаленно (например, через шару).

Трюк 3. Обходим SRP

Увы, дальше на нашем пути возникает другой механизм ограничений — SRP (Software Restriction Policies). Это группа политик, с помощью которых админ может ограничить список ПО, которое может запускать пользователь, через черный и белый списки. Blacklist и Whitelist определяются с помощью правил, которые можно задавать несколькими способами: по зонам и по сертификатам (первые два варианта практически не используются), а также по пути до файла и по его хешу. О том, что в системе действуют политики SRP, указывает соответствующий пункт в реестре — HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoft WindowsSafer CodeIdentifiersTransparentEnabled со значением большим 0, который, как уже было сказано выше, проверяется при запуске процесса. Наша задача, соответственно, отрубить эту проверку внутри запускаемого процесса. Марк Руссинович еще в далеком 2005 году опубликовал пост в блоге об обходе SRP и представил тулзу GPdisable. Она производит DLL-инъекцию в заданный процесс, подгружая специальную DLL’ку. Когда процесс попытается получить значение ключа реестра HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSafer CodeIdentifiersTransparentEnabled , то есть будет проверять присутствие политик SRP, данная библиотека перехватит запрос и возвратит STATUS_OBJECT_NAME_NOT_FOUND. Таким образом, процесс думает, что все ОК и SRP политики в системе не действуют. После покупки компании Sysinternals Майкрософтом GPdisable перестал был официально доступным (но его по-прежнему легко найти в Сети. Есть еще более продвинутые решения. Утилита GPCul8or от Eric’a Rachner’a выполняет аналогичные функции, но доступна в исходниках. Что это нам дает? Мы можем добавить в GPCul8or любые другие значения реестра винды (DisableTaskMgr, ProxySettingsPerUser к примеру) и таким образом обойти все возможные ограничения политик. Какие именно значения, спросишь ты. Тебе в помощь RegMon от Марка Руссиновича, хотя, по сути — это все значения из ветки Policies. Другой оригинальный способ в своем блоге опубликовал Дидье Стивенс. Используя свою тулзу bpmtk (Basic Process Manipulation Tool Kit), он предложил прямо в памяти процесса изменять значение необходимого для групповой политики ветки реестра.

Трюк 4. Binary planting

Утилита GPdisable состоит из двух файлов:

gpdisable.exe — инъектирует DLL в процесс;

gpdisable.dll — специальная DLL для обхода SRP.

Как я уже сказал, если мы можем запустить приложение, то можем легко обойти SRP и другие политики (через GPdisable, bpmtk, GPCul8or — неважно). Однако в реальной системе может оказаться не так уж просто запустить эти приложения. Но мы можем подгрузить DLL (в том числе gpdisable.dll). Тут есть важный нюанс. Групповые политики при запуске ПО могут проверять и DLL’ки, но при этом достаточно сильно падает производительность системы, потому по умолчанию эта опция отключена. И мы это можем использовать! Очень кстати приходится недавнее исследование от компании Across Security, которое рассказывает о новых (достаточно извращенных, но работающих) методах подгрузки кода в процессы. Прием называется Binary planting (и как его классический пример — dll hijacking), при его изучении у меня возникла мысль: "а почему не использовать его для обхода групповых политик?". Если система разрешает запуск приложений только из белого списка (пускай даже только Word), то этого уже достаточно, чтобы подгрузить нашу полезную DLL для обхода SRP. Итак, попробуем скрестить dll hijacking от парней из Across и GPdisable:

Переименовываем gpdisable.dll в ehTrace.dll.

Создаем папку с именем куку. <2E095DD0-AF56-47E4-A099-EAC038DECC24>(название любое, текст после точки исчезнет).

Кидаем ehTrace.dll в только что созданную папку.

Заходим в папку и создаем там любой документ в Word, Excel или, к примеру, PDF’ку.

Теперь открываем только что созданный файл.

Соответствующая программа должна запуститься. И запустить вместе с подгруженной DLL’кой!

Все, политики нам не страшны.

Трюк 5. Используем исключения

Часто можно обойтись и без подобных ухищрений, если знать тонкости политик, в результате которых их действия распространяются:

на программы, запущенные от имени учетной записи SYSTEM;

драйверы и другие приложения уровня ядра;

макросы внутри документов Microsoft Office;

программы, написанные для общей многоязыковой библиотеки времени выполнения (Common Language Runtime).

Итак, процессы от SYSTEM не контролируются. Первый финт ушами: если есть доступ к какому-то ПО, запущенному под такой учеткой, — атакуем. Например, нажимаем Win+U — запускаются "специальные возможности" (лупа и экранная клавиатура). Utilman.exe (процесс "специальных возможностей") при этом запускается от SYSTEM. Далее идем там в "Справку". Она тоже должна открыться с нужными привилегиями, так как запущена в контексте процесса c правами SYSTEM. Если винда не самая новая (до Vista), то кликаем правой кнопкой на синей верхней панельке "Jump to url", там печатаем "C:" и получаем настоящий встроенный explorer. Если более новая, то можно по правому клику в тексте хелпа просмотреть исходный код (View Source) через блокнот, откуда далее добраться до файлов. Или другой вариант — "добавить" новый принтер, получив опять же доступ к листингу файлов.

Другая интересная категория — макросы внутри документов Microsoft Office. Это страшное дело. Попробуем для начала реализовать запуск ПО. Хотя если запуск заблочен обычными политиками (не SRP), как, например, блокировкой диспетчера задач, то этот обход не сработает. Но нам-то главное — запустить специальный exe’шник. Поэтому в любом документе смело создаем следующий макрос и пробуем запустить его:

Sub GOSHELL()
Shell "C:windowssystem32regedit.exe", vbNormalFocus
End Sub

В результате, как ты можешь догадаться, мы получаем запущенный exe. Хардконный метод предложил опять же Дидье Стивенс. Используя в макросе MS Excel функции VirtualAlloc, WriteProcessMemory и CreateThread, он сумел подгрузить шеллкод из макроса в память процесса. Данный шеллкод подгружает DLL’ку в память процесса, а DLL’ка — не что иное, как cmd.exe. Кстати, ее исходники взяты из проекта ReactOS. Как я уже сказал, SRP может препятствовать запуску DLL’ек (хотя и не делает этого по умолчанию), но если подгрузку библиотек осуществлять, используя функцию LoadLibraryEx с LOAD_IGNORE_CODE_AUTHZ_LEVEL вместо LoadLibrary, то проверка на принадлежность подгружаемой dll к white-листу не происходит!

Трюк 6. Используем переменные среды

Когда начинаешь мучить групповые политики, то приходит осознание, что для создания защищенной системы потребуется попотеть. Дело трудное и с большим количеством тонкостей. Например, разработчики предлагают админам использовать удобный хинт — указывать переменные среды в качестве путей для ограничений SRP. Да вот здесь проблема. У пользователя, если их жестко не прищучить, есть возможность их переопределять. Указал, например, админ, что из папки %TEMP% можно запускать exe’шники, а юзер взял да и переопределил следующей командой:

И вот так просто получил возможность запускать файлы из корня C:. Кроме того, не стоит забывать про стандартные директории, из которых разрешен запуск exe-файлов:

%HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%

%HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%*.exe

%HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%System32*.exe

Они разрешают запуск ПО только из папки Windows и Program Files для пользователей. У обычного пользователя нет возможности записи в них, но и здесь могут быть проблемы. Так как на самом деле права на запись у пользователя есть — по дефолту в папку C:windowssystem32spoolPrinters и C:windowstemp. Если у пользователя будет возможность писать в какой-то каталог с софтом, то, считай, соответствующие политики SRP уже не сработают. Кстати, для того чтобы на практике поверить, какие у пользователя есть права, поможет тулза — AccessChk от все того же Руссиновича.

Трюк 7. Используем другого пользователя

Есть способ не подпустить подгрузки политик, но для этого трика нам понадобятся логин и пароль другого пользователя. Суть в том, что нам надо войти в систему "еще раз", но не под собой. Тут два варианта:

+ правый клик на запускаемом файле, далее в контекстном меню выбираем "Run as…".

Через консоль набираем команду: runas /noprofile .

Другой пользователь, под которым ты запускаешь программку, как и ты, может быть обычным пользователем с ограниченными правами. Но политики на запущенную программку уже не будут действовать! См. рисунок.

На нем пользователь test_gpo3 не может запустить regedit из-за политик. Но, запустив под test_gpo2 любой exe’шник (диспетчер задач например), он уже ничем не ограничен и поэтому может запустить regedit. Кроме того, если у нас есть возможность удаленного входа в систему (по RDP, например), то мы можем провести аналогичный финт, но только с одной учеткой (демонстрацию можешь посмотреть в этом видео).

Трюк 8. Вспоминаем про HTA

Последний хинт касается неофициальных исключений, на которые не действуют групповые политики. Вадимc Поданс написал в блоге отличную серию постов, посвещенных SRP-политикам. В частности, он обнаружил отличный путь для их обхода и запуска произвольного кода с использованием приложения HTA (HTML Application).

Итак, последовательность действий:

Создаем файлик с примерно таким текстом:

Сохраняем его с расширением .hta (например, execute_this.hta).

Создаем ярлык для него.

Открываем ссылку — и hta запускается.

Надо ли говорить, что вместо вызова безобидного MessageBox’а VB-код может сделать в системе что угодно? Политики SRP должны проверять весь код, который может исполняться, в том числе и всевозможные скрипты. Однако из-за тонкостей работы групповых политик данный обход работает. К аналогичным "глюковатым" расширениям помимо HTA Вадимс относит REG, MSC, HTA, CHM. Точно так же ситуация наблюдается и с com-файлами (в том числе всякими олдскульными ДОС’овскими программами, которые все еще разбросаны в папке винды). Они не учитывают правила групповых политик, так как работают в виртуальной машине DOS.

Групповые политики в тонких клиентах

Хочется еще рассказать про такие системы, как Citrix XenApp. Что это такое? XenApp, если говорить простым языком, это система "доставки" приложений (хотя это только часть функционала). По сути, это что-то типа терминального сервера винды, но когда пользователю доступно только конкретное приложение. В жизни это выглядит так. Пользователь коннектится клиентом к Citrix-серверу — ему выводится список доступного ПО. Далее юзер запускает какое-то приложение и начинает в нем работать. Основная фича в том, что фактически процесс приложения выполняется на Citrix-сервере. По сути, данный подход хорош (особенно с тонкими клиентами), но у него есть пучок косяков с точки зрения безопасности. Так как процесс — на сервере, то, значит, пользователю доступны все ресурсы сервера (с учетом пользовательских прав, конечно). Это не очень хорошо, так как предполагается, что у пользователя должен быть доступ только к запущенной программе, а не к ОС. Что еще хуже, добраться-то до самой ОС — не проблема. Даже если у самого ПО нет возможности по взаимодействию с ОС (нет меню "Открыть", "Сохранить как"), то стандартные возможности винды все еще работают: нажимаем в Citrix-приложении — нам открывается диспетчер задач Citrix-сервера, или правый клик по раскладке клавиатуры, а оттуда в файл справки с возможностью листинга директорий. Лично я столкнулся с групповыми политиками именно в этом контексте — при взломе Citrix.

Наш итог

Как ты можешь заметить, всевозможных лазеек полно. Их разнообразие и ухищрения не могут не удивлять. То, что я скажу дальше, может тебя удивить. Даже после перечисления всех этих способов для обхода ограничений я все же настоятельно рекомендую не пренебрегать их использованием. К тому же теперь ты можешь учитывать возможность применения этих лазеек и с намного большей вероятностью настроить систему, которая будет достаточно защищена.