Несколько дней назад эксперт по безопасности Тал Либерман из компании enSilo показал новую технику внедрения кода, которая влияет на все версии Windows вплоть до Windows 10. В силу природы данной техники, к сожалению, вряд ли он может быть пропатчен. В данной статье я хотел бы пролить свет на данную атаку и на ее последствия, а также рассказать, что можно сделать, чтобы защитить себя.

Как работает?

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

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

Лучшее описание, которое Вы можете найти на данный момент, — это это материал Тала в своем блоге "AtomBombing: A Code Injection that Bypasses Current Security Solutions."

Если не существует патча, а угроза заражает все версии Windows, означает ли это, что мы оказались перед лицом большой опасности?

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

Действительно что-то новенькое?

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



Новый, но не опасный… почему же паника?

Как я говорил, сперва вредоносная программа должна быть выполнена на машине, но мы-то знаем, что в какой-то момент это обязательно произойдет (вопрос заключается не в том, что ЕСЛИ, а в том, что КОГДА).

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

Кроме того, многие решения имеют список доверительных процессов. Если внедрение вредоносного кода состоялось в течение одного из них, то все меры безопасности, предпринимаемые таким решением безопасности, «пройдут стороной».

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

Что мы можем сделать для защиты своей корпоративной сети?

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

С другой стороны, мы имеем так называемые «антивирусы следующего поколения». Большинство из них утверждают, что они не используют сигнатуры, а их возможности обусловлены использованием техник машинного обучения, которые существенно эволюционировали за последние несколько лет и показали, что они способны довольно-таки хорошо обнаруживать некоторые новые угрозы. Зная свои слабости в том, что они не так хороши при блокировке всех угроз, они имеют хорошие экспертные наработки в пост-инфекционных сценариях, предлагая огромную добавленную ценность в тех случаях, когда нарушение уровня безопасности уже состоялось. Еще одна проблема у этих решений заключается в том, что машинное обучение не предоставляет черную или белую диагностику, что выливается в высокий уровень ложных срабатываний.

Является ли лучшим вариантом использование традиционного антивируса + антивируса следующего поколения?

Нет, хотя это лучше, чем использование только одного из этих решений, т.к. оба эти решения могут хорошо дополнять друг друга. Однако и в таком подходе тоже есть ряд недостатков. Во-первых, Вам придется заплатить за оба этих решения. Хотя это может быть оправданно из-за повышения общего уровня безопасности, но это означает, что Вам потребуется дополнительный бюджет на дополнительные работы (значительно возрастет уровень ложных срабатываний со стороны «антивируса следующего поколения», придется управлять двумя продуктами из разных консолей управления и т.д.). Также возможны проблемы и с производительностью, т.к. оба решения будут одновременно работать на компьютерах. Наконец, эти решения не взаимодействуют друг с другом, следовательно, Вы не сможете в полной мере воспользоваться всеми преимуществами той информации, которую они обрабатывают.

Какие корпоративные решения сочетают возможности традиционных антивредоносных решений и техник машинного обучения?

На мой взгляд, наилучший способ — это решение, которое сочетает в себе возможности двух таких классов решений (например, Adaptive Defense 360), т.е. мощность традиционных антивредоносных решений, а также многолетний опыт использования техник машинного обучения в сочетании с Большими данными и облаком. Такой подход позволяет обоим классам решений работать вместе, обмениваться информацией, осуществлять непрерывный мониторинг всех запущенных процессов, классифицируя все программы, выполняемые на любом компьютере в Вашей корпоративной сети, и предоставляя экспертные данные в реальном времени в случае любых нарушений безопасности. В этом случае на конечные машины будет внедряться небольшой агент, который позаботится обо всем, используя облако для ресурсоемких процессов, чтобы достичь лучшего уровня производительности на рынке.

Автор: Луис Корронс (антивирусная лаборатория PandaLabs)
Поделиться с друзьями
-->

Комментарии (9)


  1. datacompboy
    08.11.2016 12:49
    +11

    «использует собственную операционную» я так понимаю, всё таки имелось ввиду «использует собственно операционную»?
    уж больно сильно смысл отличается.

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

    В общем, как-то самого важного — КАК работает актака — в статье и нет.
    Есть какой-то маркетинговый булшит.


    1. xRay
      08.11.2016 13:44
      +1

      В общем, как-то самого важного — КАК работает актака — в статье и нет.

      В заметке есть ссылка http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions и там дальше https://breakingmalware.com/injection-techniques/atombombing-brand-new-code-injection-for-windows/ с картинками и https://github.com/BreakingMalwareResearch/atom-bombing


      1. datacompboy
        08.11.2016 15:25

        Не понял, почему нельзя запатчить NtQueueApcThread для всего кроме вайтлиста функций.


        1. kITerE
          08.11.2016 16:46
          +2

          Суть не в том, что атаку нельзя детектировать, а в том, что контролируемый со стороны Security-продуктов вызов WriteProcessMemory заменили на вызов GlobalAddAtom из своего процесса и вызов GlobalGetAtomName через APC механизм NtQueueApcThread в целевом процессе.


          И новая серия вызовов у Security-продуктов пока вызывает меньше подозрений или не вызывает вообще.


          1. datacompboy
            08.11.2016 22:54

            Цитата статьи:

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


            Я вот с этим не понимаю. NtQueueApcThread c вызовом чего угодно кроме RtlDispatchAPC не имеет смысла (ну, возможно, есть еще 1-2 функции — в общем, передавать надо не адрес а ID функции вызываемой) — и это и есть патчинг ядра, латающий дыру.


            1. kITerE
              09.11.2016 09:25

              Я вот с этим не понимаю. NtQueueApcThread c вызовом чего угодно кроме RtlDispatchAPC не имеет смысла (ну, возможно, есть еще 1-2 функции — в общем, передавать надо не адрес а ID функции вызываемой)

              Уверен, что функцией NtQueueApcThread пользуются не только разработчики MS'а и писатели малвари.


              и это и есть патчинг ядра, латающий дыру.

              И ломает обратную совместимость.


              У ядра нет дыры. Что бы выполнить NtQueueApcThread нужно обладать правом THREAD_SET_CONTEXT для нити целевого процесса. Если вы можете открыть целевую нить с такой маской доступа, то можно выполнить любой код, который загружен в адресное пространство процесса.


              На x64, например, первые 4-е параметра передаются в регистрах, поэтому обладая THREAD_SET_CONTEXT можно выполнить тот же самый вызов с тремя параметрами в целевом процессе функцией SetThreadContext.


              Задача детекта малвари по поведению — задача не ядра, я Security-продуктов. Именно как обход существующих Security-решений и позиционируется новая техника (https://breakingmalware.com/injection-techniques/atombombing-brand-new-code-injection-for-windows/):


              I started poking around to see how hard it would be for a threat actor to find a new method that security vendors are unaware of and bypasses most security products.


              1. datacompboy
                09.11.2016 10:54

                QueueUserAPC — API.
                Nt* — Internal


  1. ildarz
    08.11.2016 14:08

    > В силу природы данной техники, к сожалению, вряд ли он может быть пропатчен.

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


  1. michael_vostrikov
    08.11.2016 16:59

    Примерное описание, взято отсюда. Там же есть комменты, в которых говорят, что эта техника используется уже давно.

    Функции добавления и чтения атома:

    ATOM WINAPI GlobalAddAtom(
      _In_ LPCTSTR lpString
    );
    
    UINT WINAPI GlobalGetAtomName(
      _In_  ATOM   nAtom,
      _Out_ LPTSTR lpBuffer,
      _In_  int    nSize
    );
    


    Функция асинхронного вызова процедуры в user-mode (ее можно выполнить из другого процесса).
    DWORD WINAPI QueueUserAPC(
    _In_ PAPCFUNC  pfnAPC, 
    _In_ HANDLE    hThread, 
    _In_ ULONG_PTR dwData
    );
    
    VOID CALLBACK APCProc(
      _In_ ULONG_PTR dwParam
    );
    


    В atom name записывается код эксплойта. Функции в удаленном процессе вызываются через механизм APC. Нужно иметь права доступа THREAD_SET_CONTEXT на hThread.

    Напрямую передать pfnAPC = GlobalGetAtomName нельзя, так как pfnAPC принимает 1 параметр, а GlobalGetAtomName 3. Но QueueUserApc использует NtQueueApcThread, которая вызывает свою callback-функцию, которая принимает 3 параметра. То есть, через NtQueueApcThread можно вызвать GlobalGetAtomName в другом процессе, которая запишет имя атома куда-нибудь в RW область этого процесса.

    RW область можно найти например в конце секции данных kernelbase.dll.

    Потом надо выделить память с правами RWX и скопировать туда код из области RW. Это можно сделать с помощью ROP Chain (return-oriented programming). Это когда заранее подготавливается стек с адресами возврата сразу на нужные функции, и ret из каждой функции делает переход сразу на начало другой. Последний ret переходит на начало эксплойта.

    Стек также можно подготовить в RW области и вызвать NtSetContextThread для изменения ESP, тоже через APC. Она принимает 2 параметра, а не 3, и текущий стек должен сломаться, но это неважно, так как можно задать и нужный EIP.

    Восстановление выполнения кода делается так же, как оно происходит при APC, с помощью вызова ZwContinue.