Незримые Scheduled Tasks
Привет, Хабр!
Многие передовые компании в области информационной безопасности в конце 2022 подвели итоги года по самым популярным техникам MITRE ATT&CK, используемым атакующими. Один из таких отчетов по обнаруженным угрозам был предоставлен RedCanary, а другой Лабораторией Касперского, согласно которым одной из наиболее популярных техник закрепления в системе является Scheduled Task(T1053.005) или, говоря русским языком, запланированная задача. На сегодняшний день существует много известных способов проведения данной техники: стандартная оснастка Task Scheduler от Microsoft, утилита schtasks, а также Poweshell командлеты, которые в свою очередь опираются на RPC-функции и др.
В данной статье хочу рассказать вам о нестандартном способе проведения техники Scheduled Task с помощью удаленного реестра (Remote Registry). После чего я представлю возможный вариант детектирования данного способа и попытаюсь раскрыть все сложности, с которыми придется столкнуться в процессе.
Предлагаю начать и сперва ознакомиться с тем, что собой представляет Scheduled Task.
Что такое Scheduled Task
Task Scheduler или Планировщик задач — служба в Windows, которая позволяет автоматизировано выполнять запланированные задачи на устройстве по заранее заданному триггеру (время, наступление определенного события и т.п.). Это одна из самых "древних" служб в Windows: впервые данный компонент появился в Windows 95, а в текущем виде он представлен в Windows Vista. Таким образом, за десятки лет активного использования Scheduled Task появилось достаточное количество способов и инструментов для работы с запланированными задачами.
Данная техника привлекает злоумышленников тем, что запланированные задачи являются легитимными в операционной системе Windows. Это позволяет замаскировать вредоносные действия, а сам функционал планировщика задач не будет отключен администраторами, так как на нем строится работа всей системы. Так, например, запланированные задачи повышают надежность системы, обеспечивая ее бесперебойную работу за счет выполнения обслуживающих задач, таких как, очистка диска, дефрагментация, проверка на ошибки. Также Scheduled Task позволяет повысить производительность системы путем выполнения задач по типу резервного копирования или обновлений в наиболее оптимальное время, которое соответствует определенному триггеру. Еще один плюс — снижение человеческого фактора и рабочей нагрузки на администраторов системы.
Теперь давайте разберемся, где и как запланированные задачи хранятся в памяти системы.
Представление запланированных задач в памяти
При планировании задачи стандартными утилитами (schtasks, оснастка Task Scheduler, командлеты Powershell) создание определенных ключей реестра и xml файла на диске можно отследить с помощью Process Monitor или Sysmon (примеры Sysmon событий будут дальше в статье).
Рассмотрим подробнее какие ключи реестра при этом задействованы:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks— содержит список подразделов, представляющих запланированную задачу. Каждая задача имеет уникальный идентификатор GUID, который выступает в качестве имени ключа в реестре;HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree— представляет собой структуру планировщика заданий Windows. Здесь хранятся метаданные для регистрации задачи в системе;HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID}— содержит все настройки задачи;HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\{Plain\Logon\Boot}\{GUID}— ветка реестра, которая выбирается в зависимости от того, по какому триггеру будет запускаться задача:Plain - по заранее заданному расписанию;
Logon - при входе пользователя;
Boot - при загрузке системы.
На рисунке 2 и 3 представлен пример хранения параметров задачи в ключах реестра перечисленных выше.
Также при создании задачи формируется файл в формате xml с параметрами запланированной задачи по пути C:\Windows\System32\Tasks.
Само содержимое xml-файла с параметрами задачи вы можете увидеть под спойлером.
XML с параметрами задачи
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2023-02-27T13:08:20</Date>
<Author>USER</Author>
<URI>\spawn</URI>
</RegistrationInfo>
<Triggers>
<TimeTrigger>
<StartBoundary>2023-02-27T20:10:00</StartBoundary>
<Enabled>true</Enabled>
</TimeTrigger>
</Triggers>
<Settings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings>
<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>C:\windows\system32\cmd.exe</Command>
</Exec>
</Actions>
<Principals>
<Principal id="Author">
<UserId>USER</UserId>
<LogonType>InteractiveToken</LogonType>
<RunLevel>LeastPrivilege</RunLevel>
</Principal>
</Principals>
</Task>Перейдем к самому интересному и посмотрим как же можно создать запланированную задачу, не используя при этом специально предназначенные для этого утилиты.
Создание задачи с помощью реестра
Для удаленного подключения к реестру можно использовать графический интерфейс regedit.exe или из командной строки утилиту reg.exe.
# Удаленное редактирование реестра с помощью reg.exe
REG ADD \\<REMOTE_COMPUTER>\HKLM\...Для того чтобы изменять требуемые ветки реестра, нам необходима учетная запись SYSTEM, по крайней мере по умолчанию только она обладает нужными правами. Но удаленно подключиться под SYSTEM не получится.
Тогда возникает вопрос как удаленно из-под SYSTEM редактировать реестр, если подключиться под ней нельзя? Тут можно предложить несколько вариантов. Первый — ,заполучив SYSTEM, добавить права на редактирование другой учетной записи и уже все действия осуществлять от ее имени. Второй вариант — использовать psexec из пакета от Sysinternals или от Impacket, также можно использовать smbexec и подобные ей. Еще один из способов повысить привилегии до SYSTEM это использование различных "картошек" (например, RoguePotato, JuicyPotatoNG, RasmanPotato и др.). Либо прибегнуть к атаке Silver Ticket для создания TGS билета с SYSTEM в PAC, но для этого нужен NTLM-хеш учетной записи устройства.
Предположим, что тем или иным способом мы получили возможность удаленно редактировать реестр. Тогда, чтобы не испытывать сложности при создании требуемых веток в реестре и заполнении ключей, мы можем создать задачу локально, а далее перенести ее на удаленную машину.
Пример экспортированной задачи приведен ниже под спойлером.
Пример экспортированной задачи
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\remoteregistry1053]
"SD"=hex:01,00,04,80,88,00,00,00,98,00,00,00,00,00,00,00,14,00,00,00,02,00,74,\
00,04,00,00,00,00,10,18,00,9f,01,1f,00,01,02,00,00,00,00,00,05,20,00,00,00,\
20,02,00,00,00,10,14,00,9f,01,1f,00,01,01,00,00,00,00,00,05,12,00,00,00,00,\
10,18,00,ff,01,1f,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,00,00,00,\
24,00,89,00,12,00,01,05,00,00,00,00,00,05,15,00,00,00,fb,65,0e,da,0c,ec,58,\
4f,d2,95,df,b7,3a,38,00,00,35,00,7d,00,01,02,00,00,00,00,00,05,20,00,00,00,\
20,02,00,00,01,05,00,00,00,00,00,05,15,00,00,00,fb,65,0e,da,0c,ec,58,4f,d2,\
95,df,b7,01,02,00,00
"Id"="{B24EFFF8-2161-46E8-917D-1FF04C433EBE}"
"Index"=dword:00000003
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{B24EFFF8-2161-46E8-917D-1FF04C433EBE}]
"Path"="\\remoteregistry1053"
"Hash"=hex:9b,ea,c8,ba,7a,d1,d4,6c,6f,66,2c,07,83,ff,e9,35,2c,7c,ef,0b,cf,48,\
22,de,4d,65,02,c3,3f,dc,e0,6f
"Schema"=dword:00010002
"Date"="2022-11-04T21:33:12.6610933"
"Author"="DOMAIN\USER"
"URI"="\\remoteregistry1053"
"Triggers"=hex:17,00,00,00,00,00,00,00,01,07,0b,00,00,00,04,00,80,13,62,a9,95,\
f0,d8,01,01,e7,d4,7b,7a,01,00,00,80,d3,cb,d3,5e,f1,d8,01,38,21,41,42,48,48,\
48,48,88,f6,c6,53,48,48,48,48,0e,00,00,00,48,48,48,48,41,00,75,00,74,00,68,\
00,6f,00,72,00,00,00,48,48,00,00,00,00,48,48,48,48,00,48,48,48,48,48,48,48,\
00,48,48,48,48,48,48,48,01,00,00,00,48,48,48,48,1c,00,00,00,48,48,48,48,01,\
05,00,00,00,00,00,05,15,00,00,00,fb,65,0e,da,0c,ec,58,4f,d2,95,df,b7,3a,38,\
00,00,48,48,48,48,1e,00,00,00,48,48,48,48,53,00,45,00,41,00,5c,00,64,00,6b,\
00,6f,00,7a,00,68,00,75,00,73,00,68,00,6f,00,6b,00,00,00,48,48,2c,00,00,00,\
48,48,48,48,00,00,00,00,ff,ff,ff,ff,80,f4,03,00,ff,ff,ff,ff,07,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,48,48,\
48,48,dd,dd,00,00,00,00,00,00,01,07,0b,00,00,00,04,00,80,13,62,a9,95,f0,d8,\
01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,2c,01,00,00,80,51,01,00,ff,ff,ff,ff,00,00,00,00,00,\
00,00,00,00,00,00,00,00,01,4a,7c,01,00,00,00,00,00,00,00,d1,61,00,00,00,00,\
00,00,48,48,48,48
"Actions"=hex:03,00,0c,00,00,00,41,00,75,00,74,00,68,00,6f,00,72,00,66,66,00,\
00,00,00,0e,00,00,00,63,00,6d,00,64,00,2e,00,65,00,78,00,65,00,00,00,00,00,\
00,00,00,00,00,00
"DynamicInfo"=hex:03,00,00,00,59,22,57,e5,7b,f0,d8,01,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Plain\{B24EFFF8-2161-46E8-917D-1FF04C433EBE}]
Посмотрим на алгоритм действий при экспортировании:
Создать задачи с требуемыми параметрами на локальной машине;
Произвести экспорт следующих веток реестра:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\{NAMETASK}Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{Id TASK}`Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Plain{Id TASK}
Произвести импорт этих веток реестра на удаленную машину;
Далее появится созданная задача в списке задач, но при запуске будет ошибка.
Для исправления данной ошибки существует два способа:
Перезапустить службы
Schedule. Таким образом задача подгрузится в память соответствующего процессаsvchost. Для перезапуска службы требуются права SYSTEM, либо можно попросту перезагрузить ПК;Произвести Update задачи из графического интерфейса, schtasks или других подобных инструментов. Согласно документации Microsoft обновлять задачу могут пользователи, создавшие ее, а также члены группы администраторов и учетная запись SYSTEM.
Чтобы не создавать "лишний шум" в журнале событий, связанный с появлением новых ключей в реестре, атакующий вместо создания новой задачи может редактировать отдельные, уже существующие ключи в реестре. Он также имеет возможность осуществлять это как вручную, так и через импорт-экспорт определенных ключей, как было показано выше. В то же время такие задачи требуется активировать с новыми параметрами.
При импорте веток реестра на удаленную машину регистрируются события изменения реестра от имени процесса C:\Windows\system32\svchost.exe -k localService -p -s RemoteRegistry. Данные события можно проследить в журнале Sysmon EventId 12 (RegistryEvent Object create or delete) и 13(RegistryEvent Value Set).
Сразу после импорта ключей реестра задача появится в графическом интерфейсе планировщика задач, но каких-либо событий по созданию задачи в журналах нет, в том числе и события 4698(A scheduled task was created). На следующем этапе данную задачу нужно активировать.
Если в качестве активации выбран Update задачи, то регистрируется событие в Sysmon с EventId 11(FileCreate). То есть происходит создание xml файла в C:\Windows\System32\Tasks с описанием задачи от имени svchost.exe, связанного со службой Schedule. Пример данного события представлен выше на Рисунке 4.
Также в журнале Security регистрируется событие с EventId 4702(A scheduled task was updated), свидетельствующее об обновлении задачи. Как и в событии 4698 данное событие содержит xml с описанием задачи.
При перезапуске службы Schedule не происходит создание xml файла с описанием задачи и нет каких-либо событий, свидетельствующих о подгрузке задачи в память процесса svchost.exe связанный со службой (т.е. отсутствуют события 4698 и 4702).
Чтобы удаленно редактировать реестр потребуется включить службу Remote Registry.
Настройка службы удаленного реестра:
Запустить Remote Registry можно с помощью учетной записи, обладающей правами локального администратора или SYSTEM.
Для этого потребуется выполнить несколько шагов:
Перейти в оснастку "Services.msc"
Открыть свойства "Remote Registry service"
Во вкладке General выбрать тип запуска Automatic
Применить измененияЕсли атакующий захочет как можно дальше спрятать свои действия и тем самым еще больше усложнить жизнь специалистам по мониторингу и расследованиям инцидентов, то он сможет это сделать за счет "трюка", позволяющего скрыть запланированную задачу.
В чем же заключается этот трюк мы разберем дальше.
Скрытие задачи в планировщике задач
На этот раз скрытие происходит из оснастки Task Scheduler и других утилит (schtasks, Powershell Get-ScheduledTask) по работе с запланированными задачами. Трюк заключается в том, чтобы удалить определенные ключи в реестре, связанные с задачей.
Давайте посмотрим, что это за ключи и попробуем объединить два метода: создание задачи с помощью реестра (как описано в предыдущем разделе) и скрытие за счет отсутствие определенных ключей. Таким образом, задача будет создана уже без требуемых ключей. В таком случае для активации задачи не представляется возможным использовать Update, а единственным возможным из мне известных вариантов является перезапуск службы Schedule(если вы знаете альтернативные методы, то пишите о них в комментариях к статье). Если же производить манипуляцию с ключами, перечисленными ниже у уже активированной задачи, то дополнительно перезапускать службы или что-то обновлять не требуется. Тогда задача мгновенно пропадает из рассматриваемых утилит после изменений в реестре.
Первый ключ в реестре, который позволяет скрыть задачу, называется Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\{NAMETASK}\SD. SD отвечает за дескриптор безопасности. Если создать задачу без этого ключа, то она не будет отображаться в планировщике задач.
Второй ключ, который можно попробовать не указывать при создании задачи, является Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\{NAMETASK}\Index. Однако в текущей ситуации в оснастке Task Scheduler перестают отображаться вообще какие-либо задачи, а при открытии планировщика появляется ошибка "An internal server error occurred", при этом сами задачи работают по-прежнему.
Также можно попробовать не удалять полностью ключ Index, а изменить его. Таким образом, значение данного поля зависит от того по какому триггеру будет выполняться задача и, соответственно, она связана с веткой HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\{Plain\Logon\Boot}\{GUID} (при Boot Index=0x1, при Logon Index=0x2, при Plain Index=0x3). Если Index установить равным 0x0, то задача будет скрыта в планировщике, но при этом ее работа не нарушится. Установка Index равным 0x4 и более, не повлияет на скрытие задачи.
Вишенкой на торте является то, что если совершить Update задачу (schtasks /change /TN TASKNAME /TR PROGRAM), производя манипуляции с ключом Index, то она удалится без какого-либо события в журнале Security, в том числе и не будет события 4699 (A scheduled task was deleted).
Изучив особенности проведения техники Scheduled Task с помощью Remote Registry, перейдем к возможным способам ее детектирования.
Детектирование
Выше было рассказано как можно создать запланированную задачу максимально скрытым способом, а теперь мы поговорим, как защитникам детектировать данные случаи. Думаю очевидно, что стандартным способом за счет событий, связанных с задачами (4698, 4699, 4702), детектировать не получиться, так как они попросту будут отсутствовать в журнале.
Первое на что хотелось бы обратить внимание, так это на то, что везде происходило редактирование реестра. При стандартных способах создания запланированных задач по требуемым веткам вносятся изменения от имени C:\\Windows\\system32\\svchost.exe -k netsvcs -p -s Schedule (т.е. службой Schedule). В нашем же случае все изменения происходили от имени C:\Windows\system32\svchost.exe -k localService -p -s RemoteRegistry. В случае использования psexec и подобных, родительским процессом будет используемая утилита по редактированию реестра, например, ею может выступать reg.exe. То, что редактирование определенных веток реестра происходит с помощью процесса отличающегося от службы Schedule, может как раз и служить одним из маркеров. При этом определить какая именно служба производит изменения в реестре возможно с помощью события Sysmon 1 (Process Creation). Сопоставлять 1, 12 и 13 события можно по полю ProcessGuid (если родительским процессом выступает утилита) или ParentProcessGuid (если родительским процессом выступает служба). Ниже, на основе этого анализа, мною будет представлено-псевдо правило для детекта.
Таким образом, псевдо-правило для детекта выглядит так:
SELECT *
FROM (EventCode=1)
WHERE (ParentProcessGuid OR ProcessGuid) IN
(
SELECT ProcessGuid
FROM (EventCode=12 OR EventCode=13)
WHERE TargetObject="HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tree\\*"
)
AND ParentCommandLine!="C:\\Windows\\system32\\svchost.exe -k netsvcs -p -s Schedule"
Также следует отметить, что при активации задачи с помощью Update формируется событие 4702. Данное событие содержит описание задачи, поэтому с помощью ML (Machine Learning) может быть проверено на аномалии. В качестве другой аномалии может выступать тот факт, что были созданы новые ветки реестра, но за этим не последовало события 4698, говорящего о создании задачи.
В совокупности с вышесказанным, но не по отдельности, мы имеем возможность отслеживать перезапуск службы Scheduler с помощью ETW TaskScheduler\Operational события 402 (Service shutting down) и 400 (Service started) или через Process Creation (4688). Почему не стоит полагаться на данные события, как на самостоятельные? Только потому, что данные события происходят при каждом включении ПК, что будет приводить к ложно-положительным сработкам. В свою очередь связать перезапуск службы с перезапуском устройства можно с помощью события 1074 (System has been shutdown by a process/user) в журнале System.
Также не следует забывать о ситуации, когда задача была создана стандартным способом, а после были удалены ключи в реестре для ее сокрытия. Для этого следует следить за удалением/изменением отдельных ключей реестра (SD и Index).
При удаленном способе редактирования веток реестра применяется протокол WINREG. Внутри пакетов трафик зашифрован. Поэтому использовать информацию внутри трафика для детекта нельзя. Но можно зайти с другой стороны и задаться вопросом, а как часто и для каких целей может использоваться протокол WINREG в корпоративной среде? Ответ на этот вопрос зависит от конкретной организации и выстроенных в ней IT-процессов. Так, если в компании администраторы не применяют инструменты для удаленного редактирования реестра или ПО, в основе которого лежит WINREG, то появление событий в трафике с использованием данного протокола, должны выглядеть подозрительно, что будет служить аномалией.
Заключение
В этой статье мы рассмотрели интересный метод создания запланированной задачи в Windows системе, а также возможный способ сокрытия задачи в планировщике задач. В результате чего стало понятно, что стандартные способы детектирования техники по созданию запланированных задач на основе событий из Security журнала 4698, 4699, 4702 не подходят в конкретном случае. Также мною были предложены маркеры, на основе которых можно построить детект. Основная идея заключается в мониторинге изменения определенных веток реестра от имени процесса отличного от Schedule. Для наиболее точного распознавания таких случаев были представлены другие дополнительные маркеры детектирования, но рассматривать их стоит в совокупности, а не каждый по отдельности.
Надеюсь данная статья оказалась для вас полезной! Если у вас появились вопросы, пишите в комментариях!
Автор: Кожушок Диана( @wildresearcher), аналитик-исследователь киберугроз в компании R-Vision