Активираме събирането на събития за стартиране на подозрителни процеси в Windows и разкриваме заплахи с помощта на Quest InTrust

Един от често срещаните типове атаки е създаването на злонамерен процес в дървото на иначе благоприлични процеси. Пътят до изпълняемия файл може да предизвика подозрения: често злонамерен софтуер използва папки AppData или Temp, което не е характерно за легитимни програми. За справедливост, трябва да се отбележи, че някои инструменти за автоматично обновление се изпълняват в AppData, така че проверката само на местоположението на стартиране не е достатъчна, за да се твърди, че програмата е злонамерена.

Допълнителен фактор за легитимност е криптографският подпис: много оригинални програми са подписани от доставчика. Отсъствието на подпис може да се използва като метод за разкриване на подозрителни елементи в автозареждането. Но отново има злонамерен софтуер, който използва откраднат сертификат, за да се подпише сам.

Също така, можем да проверим стойностите на криптографските хешове MD5 или SHA256, които могат да съответстват на някои преди открити злонамерени програми. Може да се извърши статичен анализ, преглеждайки подписите в програмата (чрез правила Yara или антивирусни продукти). Освен това съществува динамичен анализ (стартиране на програмата в безопасна среда и проследяване на действията й) и реверс-инженеринг.

Има много признаци на злонамерен процес. В тази статия ще разкажем как да включим одита на съответните събития в Windows и ще разгледаме признаците, на които се основава вграденото правило InTrust за разкриване на подозрителен процес. InTrust е CLM платформа за събиране, анализ и съхранение на неструктурирани данни, в която вече има стотици предварително зададени реакции на различни типове атаки.

При стартиране на програмата, тя се зарежда в паметта на компютъра. Изпълняемият файл съдържа компютърни инструкции и помощни библиотеки (например, *.dll). Когато процесът вече е стартиран, той може да създава допълнителни потоци. Потоците позволяват на процеса да изпълнява различни набори от инструкции едновременно. Има много начини за проникване на злонамерен код в паметта и неговото стартиране; нека разгледаме някои от тях.

Най-простият начин да се стартира зловреден процес е да се накара потребителят да го стартира директно (например, от прикачен файл в имейл), след което с помощта на ключа RunOnce да го стартира при всяко включване на компютъра. Към това може да се отнесе и „безфайловото“ зловредно ПО, което съхранява PowerShell скриптове в регистровите ключове, които се изпълняват на базата на триггер. В този случай PowerShell скриптът е зловреден код.

Проблемът с директното стартиране на зловреден софтуер е, че това е известен подход, който лесно може да бъде открит. Някои зловредни програми предприемат по-подли действия, например, използват друг процес, за да започнат да се изпълняват в паметта. В резултат на това, процесът може да създаде друг процес, като стартира определена компютърна инструкция и укаже изпълнимия файл (.exe) за стартиране.

Файлът може да бъде указан, използвайки пълния път (например, C:Windowssystem32cmd.exe) или непълния (например, cmd.exe). Ако изходният процес не е безопасен, той ще позволи стартиране на нелегитимни програми. Атаката може да изглежда така: процесът стартира cmd.exe без да укаже пълния път, а атакуващият поставя своя cmd.exe на такова място, че процесът да го стартира пред легитимния. След старта на зловредната програма, тя от своя страна може да стартира легитимна програма (например, C:Windowssystem32cmd.exe), за да продължи оригиналната програма да работи правилно.

Разновидност на предишната атака е DLL-инжекция в легитимен процес. Когато процесът стартира, той намира и зарежда библиотеки, които разширяват функционалността му. Използвайки DLL-инжекция, нападателят създава зловредна библиотека със същото име и API като легитимната. Програмата зарежда зловредната библиотека, а тя от своя страна зарежда легитимната и, при необходимост, за изпълнение на операции, я извиква. Зловредната библиотека започва да изпълнява ролята на прокси за добрата библиотека.

Друг начин за вмъкване на зловреден код в паметта е да се внедри в небезопасен процес, който вече работи. Процесите получават входни данни от различни източници — четат от мрежата или файлове. Обикновено те извършват проверка, за да се уверят в легитимността на входящите данни. Но някои процеси нямат подходяща защита при изпълнението на инструкции. При такова нападение няма библиотека на диска или изпълним файл със зловреден код. Всичко се съхранява в паметта заедно с експлоатирания процес.

Сега ще разгледаме методологията за активиране на събирането на подобни събития в Windows и правилото в InTrust, което реализира защита от подобни заплахи. За начало, активираме го чрез конзолата за управление на InTrust.

Правилото използва възможностите за проследяване на процеси в ОС Windows. За съжаление, включването на събирането на такива събития не е очевидно. Необходимо е да се променят 3 различни настройки на груповата политика:

Конфигурация на компютъра > Политики > Настройки на Windows > Настройки за сигурност > Локални политики > Политика за одит > Одит на проследяване на процеси

Конфигурация на компютъра > Политики > Настройки на Windows > Настройки за сигурност > Конфигурация на разширен одит > Политики за одит > Подробно проследяване > Одит на създаване на процеси

Конфигурация на компютъра > Политики > Административни шаблони > Система > Одит на създаване на процеси > Включи командния ред в събитията за създаване на процеси

След активиране, правилата на InTrust позволяват откриване на неизвестни до момента заплахи, които демонстрират подозрително поведение. Например, може да се идентифицира описаното тук зловреден софтуер Dridex. Чрез проекта HP Bromium се знае как е устроена такава заплаха.

В своята верига от действия Dridex използва schtasks.exe, за да създаде планирано задание. Използването именно на този инструмент от командния ред се счита за доста подозрително поведение, подобно на стартирането на svchost.exe с параметри, които сочат към потребителски папки или с параметри, наподобяващи команди като «net view» или «whoami». Ето фрагмент от съответното правило SIGMA:

откритие:
    селекция1:
        CommandLine: '*svchost.exe C:Users\*Desktop\*'
    селекция2:
        ParentImage: '*svchost.exe*'
        CommandLine:
            - '*whoami.exe \/all'
            - '*net.exe view'
    условие: 1 от тях

В InTrust всичко подозрително поведение е обединено в едно правило, тъй като повечето от тези действия не са специфични за конкретна заплаха, а по-скоро са подозрителни в комплекс и в 99% от случаите се използват за не съвсем благородни цели. Този списък от действия включва, но не се ограничава до:

• Процеси, изпълнявани от необичайни местоположения, като потребителски временни папки.
• Добре известен системен процес с подозрително наследство — някои заплахи могат да се опитат да използват имената на системни процеси, за да останат незабелязани.
• Подозрителни изпълнения на административни инструменти, като cmd или PsExec, когато те използват локални системни данни или подозрително наследство.
• Подозрителни операции на тенево копиране — обичайно поведение на ransomware преди шифриране на системата, те унищожават резервните копия:

  — Чрез vssadmin.exe;
  — Чрез WMI.

• Регистрови дампи на цели клъстери от регистър.
• Хоризонтално придвижване на злонамерен код с отдалечено стартиране на процес, използвайки команди като at.exe.
• Подозрителни локални групови операции и домейн операции с използване на net.exe.
• Подозрителни операции на защитна стена с използване на netsh.exe.
• Подозрителни манипулации с ACL.
• Използване на BITS за ексфилтрация на данни.
• Подозрителни манипулации с WMI.
• Подозрителни скриптови команди.
• Опити да се извлекат безопасни системни файлове.

Обобщеното правило работи много добре за откриване на заплахи като RUYK, LockerGoga и други вируси за откуп, злонамерен софтуер и комплекти инструменти за киберпрестъпност. Правилото е проверено от доставчика в бойни среди, за да се минимизират фалшивите сработвания. И благодарение на проекта SIGMA, повечето от тези индикатори произвеждат минимално количество шумови събития.

Тъй като в InTrust това е правило за мониторинг, можете да изпълните отговорен сценарий в отговор на заплаха. Можете да използвате един от вградените сценарии или да създадете свой собствен, а InTrust автоматично ще го разпространи.

Освен това можете да проверите цялата свързана с инцидента телеметрия: PowerShell скриптове, изпълнение на процеси, манипулации с планирани задачи, административна активност WMI и да ги използвате за постмортем анализи при инциденти със сигурността.

В InTrust има стотици други правила, някои от които:

• Откритие на атака с понижаване на версията на PowerShell — когато някой целенасочено използва по-стара версия на PowerShell, тъй като в по-старата версия няма възможност за одит на събитията.
• Откритие на вход с високи привилегии — когато акаунти, които са членове на определена привилегирована група (например домейн администратори), случайно или поради инциденти със сигурността, влизат интерактивно в системата на работни станции.

InTrust позволява да се използват най-добрите практики за сигурност под формата на предварително зададени правила за откритие и реакция. Ако смятате, че нещо трябва да работи по друг начин, можете да направите своя копия на правилото и да го конфигурирате по необходимия начин. Можете да подадете заявка за провеждане на пилотен проект или получаване на дистрибуции с времеви лицензии чрез формата за обратна връзка на нашия сайт.

Абонирайте се за нашия Facebook страница, публикуваме там кратки бележки и интересни линкове.

Прочетете и другите ни статии по темата за информационната сигурност:

Как InTrust може да помогне за намаляване на честотата на неуспешни опити за авторизация през RDP

Идентифициране на атака от вирус-заключващ софтуер, получаване на достъп до контролера на домейна и опити за справяне с тези атаки.

Каква полезна информация може да се извлече от логовете на работна станция с Windows? (популярна статия)

Проследяване на жизнения цикъл на потребителите без клещи и изолирбанд.

А кой го направи? Автоматизация на одита за информационна сигурност.

Как да намалим разходите за поддръжка на SIEM система и каква е необходимостта от Central Log Management (CLM).

Източник: habr.com