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

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

❗️ Команда PT ESC IR уделяет приоритетное внимание автоматизации разбора артефактов для последующего обнаружения вредоносной активности — это ускоряет восстановление картины инцидента.

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

О том, что поддается восстановлению и почему одни подходы дают полную структуру записи, а другие — лишь отдельные поля, читайте в нашем материале на Хабре 🫲

#ir #dfir #tip
@ptescalator

PhantomCore продолжает активно использовать ошибки в конфигурации 1С для атак на российские организации.

Об атаках на 1С с помощью 1cshell мы писали ранее (1, 2, 3).

В рамках расследования инцидента команда PT ESC IR обнаружила компрометацию сервера 1С, работающего на операционной системе семейства Linux 🐧

Среди характерных признаков — наличие вредоносных исполняемых файлов в подкаталогах домашней директории служебного пользователя usr1cv8 и команд в .bash_history того же пользователя — в частности просмотр и удаление файла res.txt, в который записывается результат выполнения кода посредством 1cshell.

/home/usr1cv8/.bash_history: cat res.txt

/home/usr1cv8/.bash_history: rm res.txt

После получения доступа в систему PhantomCore установили ReverseSSH-туннель, что является типичным поведением для данной группировки.

🕵️‍♂️ Помимо часто используемого инструментария, мы встретили и более диковинную утилиту croc, предназначенную для удаленной загрузки и эксфильтрации файлов.

На исследуемом узле были обнаружены команды формата: CROC_SECRET=[REDACTED] ./croc

С помощью нее злоумышленники могли загрузить на скомпрометированный узел файл, который был предварительно отправлен через веб-интерфейс https://getcroc.com/ (на скриншоте) или с другого компьютера, на котором установлен croc.

💡 Для поиска следов использования croc можно поискать исполняемый файл с соответствующим именем, а также использование переменной окружения CROC_SECRET.

В качестве сетевого индикатора может служить домен getcroc.com.

#ir #tip #apt #detect #dfir
@ptescalator

Для ESXi-систем разработчиком был подготовлен отдельный Python-загрузчик, предназначенный для размещения VMkatz в памяти без запуска бинарного файла через execve(). Вместо этого скрипт открывает ELF-бинарь как набор байтов, разбирает его заголовки и загружаемые сегменты, выделяет области памяти в адресном пространстве текущего процесса, копирует туда содержимое ELF и затем передает управление на его точку входа.

В результате VMkatz не запускается как отдельный процесс, а выполняется внутри уже существующего процесса Python. Такой механизм используется для обхода ограничений параметра execInstalledOnly, который запрещает запуск неподписанных бинарных файлов. На скриншоте 1 представлен пример работы VMkatz на ESXi, запущенного с помощью Python-загрузчика. В качестве входных данных инструменту был передан снимок оперативной памяти виртуальной машины. В результате VMkatz извлек доступные учетные данные.

В одном из расследований команда PT ESC IR столкнулась со сценарием, в котором злоумышленники, получив доступ к гипервизору VMware ESXi, использовали подобный подход для извлечения учетных данных из виртуальных машин с помощью следующих команд:

python /tmp/vmkatz_loader.py /tmp/vmkatz --dump lsass /vmfs/volumes/DATA/VM-DC01/VM-DC01-Snapshot.vmsn
python /tmp/vmkatz_loader.py /tmp/vmkatz /vmfs/volumes/DATA/VM-DC01/VM-DC01-Snapshot.vmsn
python /tmp/vmkatz_loader.py /tmp/vmkatz /vmfs/volumes/DATA/VM-DC01/VM-DC01.vmdk

Отдельный риск представляет функция утилиты для извлечения базы данных Active Directory NTDS.dit и раздела реестра SYSTEM с контроллеров доменов (пример показан на скриншоте 2). В таком случае компрометация гипервизора может привести не только к компрометации отдельных виртуальных машин, но и к компрометации всего домена.

Как защититься?

• Включать шифрование всех файлов виртуальных машин.
• Отключать SSH-доступ и не использовать его как основной способ администрирования. SSH должен включаться только временно, когда это необходимо для диагностики или устранения неисправностей. В качестве метода аутентификации следует использовать SSH-ключи вместо паролей. Также необходимо организовать мониторинг событий входа на гипервизор под привилегированными учетными записями.
• Доступ к TCP-порту 22 необходимо ограничить с помощью межсетевых экранов или выделенного административного сегмента. Подключения должны разрешаться только с jump-узлов или доверенных административных IP-адресов, доступ к которым защищен многофакторной аутентификацией.

#ir #dfir #esxi #tip
@ptescalator

В ходе расследования инцидентов мы в PT ESC IR регулярно сталкиваемся с необходимостью анализа баз данных в формате ESE (Extensible Storage Engine), поскольку в подобных артефактах можно найти много интересного.

Чтобы эффективнее работать с такими файлами, важно понимать, как этот формат устроен изнутри. Поэтому по итогам исследования мы подготовили подробный разбор внутреннего устройства ESE (также известного как Jet Blue) — встроенной СУБД от Microsoft, которая используется во многих продуктах компании.

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

🫱 Подробности — на Хабре.

#ir #dfir #win #tip
@ptescalator

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

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

😳 Много лет специалисты, расследовавшие взломы, отмечали и описывали в отчетах, что когда в подобных атаках для туннеля использовался ngrok, при подключении по RDP в логах вместо IP-адреса источника заносилось странное значение — ::%16777216.

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

Но, с другой стороны, нигде не было понятного объяснения, что это за «магическое число», почему именно оно возникает в логах и всегда ли это признак использования именно ngrok.

😎 Мы решили разобраться, и нам удалось получить ответы:

🔴 ::%16777216 появляется в логах в событии 1149 (а еще 4778 и 4779) вместо IP-адреса ::1 в результате ошибки в Windows.

🔴 Ошибка не связана с наличием какой-либо уязвимости, а вызвана несогласованной интерпретацией данных в памяти разными модулями протокола RDP

🔴 Ошибка возникает не только с адресом ::1, но и в любом другом случае, когда происходит подключение к RDP с использованием протокола IPv6 (например, вместо адреса fe80::6e1d:980d:9401:719b вы увидите в логах строку 0:0:fe80::6e1d:980d%2607874452)

🔴 Проблема чаще всего связывалась с утилитой ngrok, так как в ходе туннелирования она создает подключение на узле с использованием IPv6 по умолчанию, в отличие от многих других утилит, которые используют IPv4.

🔴 Адрес в логах «портится» не безвозвратно, его можно восстановить:

1. Взять значение из лога: 0:0:fe80::6e1d:980d%2607874452

2. Часть после % перевести в HEX: 2607874452 dec = 9b710194 hex

3. Убрать слева два нуля, дописать справа полученные цифры с учетом обратного порядка байт: fe80::6e1d:980d:9401:719b

Ошибка существовала как минимум начиная с Windows Server 2012 R2 во всех версиях Windows. В начале лета 2025 года мы направили информацию об этом в Microsoft, и результаты недавних тестов показывают, что в актуальных версиях (с майскими обновлениями 2026 года) ошибка была исправлена (ответа о факте исправления мы не получили).

А о нюансах исследования, интересных подробностях представления IP-адресов и подходах к проведению экспериментов, которые помогли найти объяснение, автор рассказал в докладе на прошедшей в мае конференции ËPRSTCON — запись доклада, презентацию и расшифровку ищите на сайте конференции.

И что же теперь делать? 😨

1️⃣ В старых версиях Windows, которые уже не получают обновлений, продолжать обращать внимание на ::%16777216 в логах.

2️⃣ В актуальных версиях Windows, где, возможно, были установлены обновления, дополнительно проверять на наличие ::1 там, где такого адреса не должно быть в норме.

3️⃣ Учитывайте, что есть множество различных утилит для создания туннелей, и подобный индикатор никак не подтверждает использование именно ngrok.

0️⃣ По желанию — доработайте свой парсинг логов так, чтобы восстанавливать нормальный IP-адрес: это поможет учитывать адрес в корреляционных правилах и получать больше релевантных результатов при ретроспективном поиске событий или тредхантинге.

P.S.: и не забывайте обращать внимание на появление 127.0.0.1 в неподходящих местах.

P.P.S.: и не только 127.0.0.1, а любого адреса из сети 127.0.0.0/8: все эти адреса соответствуют интерфейсу localhost согласно RFC5735, и это работает во всех популярных ОС. Использовать как источник адрес типа 127.0.13.37 у злоумышленника вряд ли легко получится, а вот указывать в качестве назначения подобные адреса для подключения к процессам на локальном хосте — вполне.

#tip #win
@ptescalator

Читайте также про: Zabbix Agent, TimeProvider, COM Hijacking, WMICLNT.

5️⃣ Systemd Generator

Systemd Generator — это исполняемый файл, который systemd запускает на этапе загрузки системы (или при выполнении daemon-reload) для динамического создания unit-файлов служб, целей и точек монтирования. Злоумышленники используют этот механизм для скрытого закрепления, поскольку генераторы выполняются с привилегиями root до запуска основных служб и редко проверяются администраторами.

Ключевые директории:

• /etc/systemd/system-generators/*
• /usr/local/lib/systemd/system-generators/*
• /lib/systemd/system-generators/* (или /usr/lib/systemd/system-generators/)

😐 Механизм закрепления:

1. Злоумышленник помещает исполняемый файл в одну из ключевых директорий — скрипт или бинарный файл (обычно с маскирующим именем, например systemd-cp-generator).

2. При каждой загрузке системы или выполнении systemctl daemon-reload — systemd запускает все найденные генераторы.

3. Генератор может: создать свой сервис в /run/systemd/system/ и включить его, перезаписать юниты существующих служб (особенно через /run/systemd/generator.early/, где приоритет выше, чем у /etc/systemd/system/), отключить критически важные средства защиты, выполнить полезную нагрузку напрямую.

😮 Рекомендации:

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

1. Мониторинг файловой системы — в первую очередь отслеживайте создание и изменение файлов в перечисленных директориях. Используйте auditd, так как он работает на уровне ядра и может сработать даже при ранней загрузке.

2. Контроль целостности — периодически сверяйте хеш-суммы файлов в директориях генераторов с эталонными.

3. Ограничение прав — запретите обычным пользователям и непривилегированным процессам запись в эти директории.

4. Анализ генераторов — проверяйте нестандартные или недавно появившиеся генераторы, особенно если они не от легитимных пакетов (openvpn, systemd-rc-local-generator и т.п.).

На этом с этой серией постов — пока что все 😉

#ir #dfir #tips
@ptescalator

Читайте также про: Zabbix Agent, TimeProvider, COM Hijacking.

4️⃣ WMICLNT

Эта техника закрепления основана на перехвате DLL, загружаемой легитимной службой Windows Management Instrumentation (WMI), и в MITRE ATT&CK классифицируется как T1546.008 (Event Triggered Execution: Accessibility Features) или как частный случай DLL Hijacking.

Злоумышленники используют особенность запуска консоли WMIC (wmic.exe), которая является стандартным инструментом системного администрирования. При запуске WMIC пытается загрузить библиотеку wmiclnt.dll, но эта библиотека может отсутствовать в стандартной поставке Windows.

Штатный wmic.exe работает и без нее — функциональность может быть ограничена, однако сам факт попытки загрузки позволяет атакующему разместить по пути поиска DLL свою вредоносную библиотеку.

Атакующий размещает вредоносную wmiclnt.dll в C:\Windows\System32\wbem. Для активации может использоваться любой удобный злоумышленнику триггер — как конкретное задание в планировщике, так и перезапуск системной службы.

В первом случае создается Scheduled Task, периодически дергающий легитимную утилиту (например, wmic os get name), что приводит к загрузке DLL и выполнению вредоносного кода в DllMain.

Во втором — применяется циклический перезапуск службы WMI командами net stop winmgmt /y и net start winmgmt, что также провоцирует обращение к подставной библиотеке и обеспечивает закрепление.

⬇️ Для успешной загрузки и скрытной работы вредоносная wmiclnt.dll должна удовлетворять следующим условиям:

• Функции экспорта: вредоносная DLL обязана реализовать и экспортировать все те же функции, которые пытается импортировать wmic.exe (скриншот 3), чтобы процесс не упал с ошибкой.

• Чаще всего вредоносная логика выполняется прямо в DllMain (функция DLL_PROCESS_ATTACH), так как это гарантирует выполнение кода сразу после загрузки библиотеки без необходимости вызова конкретных экспортируемых процедур.

• Проксирование: для максимальной маскировки вредоносная DLL может выступать в роли «прокси», пробрасывая вызовы на реальный системный API, чтобы wmic.exe отрабатывал штатно и не вызывал подозрений.

👀 Признаки компрометации:

• Появление файла wmiclnt.dll в директории C:\Windows\System32\wbem\ (в чистой системе этот файл отсутствует, хотя на старых версиях мог существовать; в современных Windows 10/11 и Server 20xx файл находится в директории C:\Windows\System32\).

• Нестандартные дочерние процессы у wmic.exe (например, если из-под WMIC вдруг запускается powershell.exe или rundll32.exe с сетевым взаимодействием).

• Еще одним признаком компрометации может служить событие Event ID 11 (Image Load), где поле "SignatureLevel": 1 указывает на unsigned/untrusted образ.

{"Event"…"EventID":11,"Version":0,"Level":0,"Task":6,"Opcode":0,"Keywords":"0x8000000000000000","TimeCreated":{"#att  
ributes":{"SystemTime":"2026-02-27T10:26:15.414597Z"}},…,"Channel":"Microsoft-Windows-SecurityMitigations/KernelMode","Computer":“REDACTED","Security":{"#attributes":{"UserID":"S-1-5-  
18"}}},"EventData":{"ProcessPathLength":52,"ProcessPath":"\\Device\\HarddiskVolume4\\Windows\\System32\\svchost.exe  
","ProcessCommandLineLength":56,"ProcessCommandLine":"C:\\Windows\\system32\\svchost.exe -k netsvcs -p -s  
Winmgmt","ProcessId":37383,"ProcessCreateTime":"2026-02-  
27T10:26:15.254827Z","ProcessStartKey":19140298416383003,"ProcessSignatureLevel":0,"ProcessSectionSignatureLevel":0,  
"ProcessProtection":0,"TargetThreadId":29700,"TargetThreadCreateTime":"2026-02-  
25T08:24:13.276875Z","RequiredSignatureLevel":8,"SignatureLevel":1,"ImageNameLength":34,"ImageName":"\\Windows\  
\System32\\wbem\\wmiclnt.dll"}}}

Продолжение будет в следующем посте 🔽

#ir #dfir #tips
@ptescalator

Читайте также про: Zabbix Agent, TimeProvider.

3️⃣ COM Hijacking

Для закрепления в инфраструктуре злоумышленники использовали редкую технику Component Object Model Hijacking (перехват COM-объектов).

Суть метода — не в прямой подмене DLL системного сервиса (что легко обнаруживается), а в манипуляции структурой реестра Component Object Model. Атакующие создают собственный COM-объект, указывающий на вредоносную библиотеку, и перенаправляют на него вызовы доверенных системных компонентов через легитимный механизм совместимости.

Ключевым элементом атаки выступает раздел реестра TreatAs, изначально предназначенный для прозрачного перенаправления запросов с одного COM-объекта на другой. Злоумышленники находят системный CLSID, обращение к которому происходит регулярно и незаметно, и подменяют его обработку на свой объект.

Особый интерес представляет COM-объект Network List Manager с идентификатором {DCB00C01-570F-4A9B-8D69-199FDBA5723B}, отвечающий за управление сетевыми профилями (netprofm). Обращения к нему происходят при каждой смене сетевого подключения, запуске диагностики сети и старте операционной системы.

Злоумышленники модифицируют ветку:
HKLM\Software\Classes\CLSID{DCB00C01-570F-4A9B-8D69-199FDBA5723B}\TreatAs,

прописывая в значении по умолчанию CLSID своего вредоносного COM-объекта. В результате при работе с сетевыми профилями система автоматически перенаправляет вызов и загружает вредоносную DLL, размещенную по пути %systemroot%\system32\netprofmaaa.dll (имя мимикрирует под оригинальную netprofm.dll).

❗️ Требования к DLL: библиотека должна быть полноценным COM-сервером, реализующим все интерфейсы, ожидаемые от подменяемого объекта Network List Manager, и корректно экспортировать стандартные функции (скриншот 2): DllGetClassObject(), DllCanUnloadNow(), DllRegisterServer() и DllUnregisterServer().

При вызове DllGetClassObject() она должна возвращать фабрику классов, способную создавать экземпляры объекта с ожидаемыми интерфейсами (включая INetworkListManager). Это необходимо для безаварийной работы вызывающих процессов и сохранения скрытности — в противном случае приложения, обращающиеся к сетевому менеджеру, будут аварийно завершаться и демаскировать присутствие вредоносного кода.

Продолжение будет в следующих постах 🙂

#ir #dfir #tips
@ptescalator

За первые шесть месяцев 2026 года команда PT ESC IR зафиксировала ряд редких техник закрепления на скомпрометированных хостах, которые мы и обсудим в ближайших постах.

1️⃣ Zabbix Agent

Zabbix Agent — это легковесная служба сбора метрик с хоста и их передачи на сервер, штатно используемая администраторами.

Суть техники закрепления злоумышленников (например, группы PhantomCore) сводится к превращению легитимного агента в скрытый бэкдор. Они доставляют на хост собственный установщик (zabbix.msi) и подменяют в конфигурационном файле адрес сервера на подконтрольный C2.

Ключевые поля конфигурации для атаки:

• Server= и ServerActive= задают IP или домен C2-сервера для пассивных и активных проверок;

• Hostname= служит уникальным идентификатором жертвы в панели C2;

• ListenPort= переназначает порт (по умолчанию 10050), чтобы избежать конфликта с родным агентом;

• UserParameter= является ключевым элементом, позволяя регистрировать произвольные команды ОС как метрики Zabbix;

• AllowKey=system.run[*] разрешает прямое выполнение команд.

Канал управления работает по нативному протоколу Zabbix (JSON поверх TCP/TLS), маскируя вредоносный трафик под легитимный мониторинг и позволяя агентам в активном режиме самостоятельно «стучаться» к C2. В рамках постэксплуатации злоумышленник через графическую оболочку Zabbix-сервера централизованно получает доступ к файлам, процессам и возможность бесшумно доставлять и запускать дополнительные скрипты на скомпрометированном хосте.

Основные признаки компрометации: внезапные исходящие соединения с нестандартными портами мониторинга (10050/10051) на внешние IP-адреса и наличие в конфигурационном файле агента вызовов оболочек (cmd, sh, powershell).

2️⃣ TimeProvider

Злоумышленники применяли редкую технику закрепления через механизм TimeProvider (поставщик времени Windows), соответствующую тактике MITRE ATT&CK T1543.003.

Суть метода в том, что служба времени Windows (W32Time) при каждом запуске системы автоматически загружает все библиотеки, зарегистрированные в ветке реестра: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders

Атакующие создавали в этом разделе собственного поставщика: в параметре DllName прописывали путь к вредоносной DLL, а параметру Enabled присваивали значение 1. После перезагрузки ОС служба W32Time загружает указанную библиотеку в контексте процесса svchost.exe с привилегиями Local System, что обеспечивает скрытное и надежное закрепление в системе.

Требования к DLL: для успешной загрузки она должна экспортировать функцию TimeProvOpen() (скриншот 1), которую W32Time вызывает при инициализации провайдера. Эта функция служит точкой входа и обычно используется злоумышленниками для запуска основной полезной нагрузки.

Продолжение завтра (в следующих постах) 🔽

#ir #tips #dfir
@ptescalator

В ходе анализа дампов PT ESC IR периодически сталкивается с новыми семействами ВПО, которые не обнаруживаются по известным индикаторам и YARA-сигнатурам и хорошо мимикрируют под легитимные или системные файлы.

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

🧐 На первом скриншоте показано распределение исполняемых файлов nix-подобной системы с учетом размера файлов (масштаб «обратно-логарифмический»: большие файлы системы расположены ближе к центру, малые — на периферии). Для группировки файлов с учетом их размера и сходства содержимого (необходимо учитывать, что данные переменные не всегда являются независимыми — например, при использовании алгоритма TLSH) потребуется провести процедуру «кластеризации» с учетом матрицы «перекрестных расстояний» между всеми (N) файлами системы, которая будет иметь размер (N^2).

Очевидно, что для сокращения размера данной матрицы возможно ввести разбиение диапазона размеров файлов одной либо нескольких совместно анализируемых систем — весь диапазон размеров может быть представлен как совокупность непересекающихся отрезков [x-ax;x+ax], где a<1, а x — центральная точка отрезка. Опыт показывает, что такое разделение позволяет, как правило, получить менее сотни размерных «поясов» при значении a=0.1. При дальнейшем анализе в пределах отдельных «поясов» количество образцов будет существенно меньше исходного общего количества.

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

Финальным этапом подобного анализа является выявление в пределах полученных для каждой из анализируемых систем «аномальных» групп файлов, которые удовлетворяют следующим критериям:

1️⃣ имеют малое количество схожих образцов либо высокое среднее расстояние до остальных образцов (для формализации можно задаться верхней половиной динамического диапазона);

2️⃣ не имеют в пределах одной системы файлов с идентичным именем, но отличным путем (что позволяет фильтровать системные файлы nix-подобных систем);

3️⃣ имеют малое количество файлов с аналогичным путем/именем на совместно анализируемых системах (или не имеют аналогов вовсе — то есть не являются обязательными для функционирования системы).

👀 Результатом подобного анализа является картина, показанная на втором скриншоте: размер файлов снова в «обратно-логарифмическом» масштабе, «максимально отличающиеся» файлы в пределах «размерного пояса» стремятся к угловой координате π радиан, а минимально отличающиеся — к 0. «Условно аномальные», т.е. практически уникальные по размеру файлы, имеют угловую координату 3π/2.

Общее количество определенных «аномалий» составляет для различных систем от 0,7% до 8% от исходного количества анализируемых исполняемых файлов, что позволяет проводить дальнейший анализ в ряде случаев просто «глазами» — из исходных тысяч файлов остается около полусотни.

Первый же «существенно отличающийся» файл в данном случае действительно представляет собой ВПО, причем для ансамбля из 12 анализируемых систем аналогичный образец уверенно обнаруживается еще на одной машине, а дальнейший поиск при «TLSH-расстоянии» не более 70 единиц позволяет выявить еще 5 образцов на различных машинах ансамбля с одинаковыми путями — все они принадлежат к одному семейству и реализуют закрепление ВПО посредством использования system-generators.

#tip #ir #malware
@ptescalator