Злоумышленники используют DNS-через-HTTPS от Google для загрузки вредоносных программ

    image

    Хакеры, которые маскируют вредоносные программы в поддельных журналах ошибок Windows, теперь научились использовать для этого DNS-через-HTTPS от Google. Зловред читает файл, который выдает себя за журналы событий и имеет расширение .chk.

    image

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

    Исследователи из Huntress Labs заметили подозрительный URL-адрес в коде PowerShell: //dns.google.com/resolve?name=dmarc.jqueryupdatejs.com&type=txt

    Домен jqueryupdatejs.com привлек внимание Джона Хэммонда, старшего исследователя безопасности в Huntress Labs. При использовании DNS-через-HTTPS от Google для его разрешения в ответе содержится полезная нагрузка вредоносного ПО в закодированной форме.

    imageФото: www.bleepingcomputer.com

    Хаммонд отметил, что часто DNS-фильтрация применяется в корпоративной сети, но никому бы не пришло в голову блокировать домен Google.

    По словам исследователя, атаками легче управлять и кастомизировать их при наличии канала управления, для которого всё чаще используют DoH. Чтобы поменять зловредную нагрузку или конфигурацию, больше нет необходимости иметь доступ к целевой сети.

    На первый взгляд значение поля «данные», возвращаемое DNS-запросом Google, может выглядеть как подпись DKIM. Обычно там содержится ключ аутентификации почты для борьбы со спамом. Однако при атаке хакеры спрятали туда данные.

    Это значение похоже на строку в кодировке base64, но попытка декодировать всю строку приводит к получению бессмысленных данных. Это происходит потому, что символ « /» служит разделителем (очень похожим на пробел) и не является частью полезной нагрузки.

    При декодировании каждого значения, разделенного « /» Хаммонд снова получил различные значения base64. Повторная расшифровка этих данных дала большие числа:

    1484238688
    1484238687
    238837
    2388371974
    2388372143

    Это десятичные представления допустимых IP-адресов. Например, если ввести 1484238687/ в адресной строке веб-браузера, то получится следующее: 88.119.175.95/ (но делать так не рекомендуется).

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

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

    В дополнение ко всем методам обфускации зловред пытается скрываться, переименовываясь в какой-нибудь стандартный процесс Windows.

    Хаммонд отметил, что использование нативных утилит Windows и выполнение кода PowerShell затрудняет обнаружение зловреда, а подобное сокрытие команд управления через DoH не сможет заблокировать сетевой антивирус или коммерчески доступный файерволл.

    Данное ПО было обнаружено вручную. Детальные выводы опубликованы в блоге Huntress Labs.
    См. также:

    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 7

      +3
      Пахнет гуглтранслейтом, извините. Вроде бы слова понятные, но в предложения не складываются. Тут описано использование DoH в качестве транспорта? Прокатывает, потому что его админы должны добавить в White-правила фаервола?
        +2
        Кажущиеся шестнадцатеричными символы справа на самом деле являются десятичными символами, используемыми для построения закодированной полезной нагрузки.

        А кажущиеся десятичные символы на самом деле являются шестнадцатеричными символами.

        На первый взгляд значение поля «данные», возвращаемое DNS-запросом Google, может выглядеть как подпись DKIM. Это значение похоже на строку в кодировке base64, но попытка декодировать всю строку приводит к получению бессмысленных данных.

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

        Так и в открытый порт можно записать набор данных, без кодировки в Base64, которые будут контролировать заражённые машины. Одна из самых распространённых атак такого рода заканчивалась переполнением буфера и внедрением зловреда, а не для передаче контрольных комманд.

        Уж очень завуалировано… В тексте Base64, могут передавать не Base64, ожидаемые клиентом, а Base64 для контроля заражённых машин. Ну так и WebPush можно передать с payload подставившись те-же гуглом (хромом), тут и без DoH получится получить коммандный пакет.
          +2
          Так звучит, словно не использование туннелирования DNS как-то убережет от такого способа качания вредоноса (да и вообще чего угодно).

          С тем же успехом можно писать «iOS умеет качать вирусы через DNS» — заголовок «богатый», но ОС тут вовсе не при чем (как и DNS как протокол).

          «Байты не пахнут», ресурсу пофиг.
            +5
            DNS-over-HTTPS это ведь тот же DNS, долько с другим транспортом? И так же как в обычном DNS, можно прятать данные в записях TXT? Надо же…
              0
              Ну можно, только в обычный DNS можно подглядывать, и резать подозрительное, а что внутри DNS-over-HTTPS, корпоративному файерволлу/DNS-серверу не видно.
                0
                А чем это отличается от обычного https? Можно грузить с каких-то гугл драйвов, например или хоть поста с фейсбука (base64 в посте).
                  0
                  Серьезно, кто-то режет данные в TXT-записях именно как способ борьбы с вредоносами?

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

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое