CISA предупреждает об активно эксплуатируемой уязвимости в расширении JCE для Joomla, позволяющей выполнять PHP-код.

06.16.26 Агентство по кибербезопасности и защите инфраструктуры США (CISA) внесло уязвимость критического уровня опасности, затрагивающую расширение Widget Factory Joomla Content Editor (JCE), в свой каталог известных эксплуатируемых уязвимостей (KEV), сославшись на свидетельства ее активной эксплуатации.

Данная уязвимость, зарегистрированная под идентификатором CVE-2026-48907, связана с некорректным контролем доступа, что может привести к выполнению произвольного кода.

В расширении Widget Factory Joomla Content Editor обнаружена уязвимость, связанная с ненадлежащим контролем доступа; она позволяет неавторизованным пользователям загружать и выполнять PHP-код путем создания новых профилей редактора

На данный момент нет информации о том, как именно эта уязвимость эксплуатируется в реальных условиях. Федеральным гражданским ведомствам исполнительной власти (FCEB) предписано установить исправление до 19 июня 2026 года.

#news #Joomla #PHP #CVE #vuln

🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

Почему инциденты обходятся так дорого — и при чём тут оргструктура

Средняя стоимость утечки данных в 2023 году — $4.45 млн. Цифра из отчёта IBM, которую любят цитировать все подряд. Но вот что интересно: когда разбираешь post-mortem конкретных инцидентов, дорогими их делает не уязвимость и не отсутствие EDR. Их делает организационный хаос.

❓Кто принимает решение об изоляции скомпрометированного сегмента? Кто уведомляет регулятора в срок? На ком ответственность за финансовые последствия? В компаниях без формализованного governance ответ на каждый из этих вопросов — тишина и импровизация под давлением.

Governance ИБ — это не про комплаенс и не про закупку средств защиты. Это стратегический уровень: кто принимает решения о допустимом уровне риска, что входит в scope ИБ-программы, зачем организация инвестирует в конкретные контроли. Не случайно NIST CSF 2.0 ввёл функцию GOVERN как фундаментальную — в предыдущей версии фреймворка её просто не существовало.

➡️Три модели оргструктуры ИБ, которые встречаются на практике:

• Централизованная — всё под единым CISO. Единые стандарты, понятная ответственность. Минус: bottleneck при масштабировании, особенно если бизнес распределён географически.

• Распределённая — ответственности делегированы подразделениям или регионам. Быстрая реакция на локальные угрозы, но три подразделения с тремя разными подходами к классификации инцидентов делают агрегированный reporting невозможным.

• Гибридная — центральный CISO задаёт стратегию и политики, а в подразделениях работают security-координаторы, адаптирующие требования к локальному контексту. Доминирует в компаниях от 500+ человек.

Выбор зависит не от размера штата, а от трёх факторов: уровень регуляторного давления, географическая распределённость и зрелость ИТ-процессов.

❗️Отдельная боль — подчинение CISO. Самая распространённая схема в российских компаниях — CISO под CIO. И самая проблемная. Структурный конфликт интересов: CIO отвечает за uptime и скорость, CISO — за безопасность. Когда нужно остановить деплой из-за уязвимости, CIO и CISO оказываются по разные стороны. А итоговое решение принимает тот, кому CISO подчиняется, — то есть CIO. Угадайте, в чью пользу.

Ещё один инструмент, без которого governance разваливается — матрица RACI. Она фиксирует для каждого процесса, кто Responsible, кто Accountable, кого Consulted, кого Informed. Без неё в момент инцидента начинается перекидывание ответственности, а время утекает.

👉В полной версии статьи — разбор всех трёх моделей, конкретные примеры RACI-матриц, шаблоны reporting и привязка к техникам MITRE ATT&CK. Полезно и CISO, и тем, кто строит ИБ-функцию с нуля.

https://codeby.net/threads/governance-informatsionnoi-bezopasnosti-orgstruktura-roli-raci-i-reporting-dlya-zreloi-ib-programmy.94136/

💵Сколько зарабатывает пентестер веб-приложений?

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

Цифры по рынку:
▶️Junior ~ 60 000 ₽
▶️Middle ~ 350 000 ₽
▶️Senior — до 600 000 ₽
▶️Bug Bounty — отдельный доход за найденные баги, без потолка

Наш курс WAPT выводит как раз на уровень Middle — и не на теории, а в большой лаборатории из 66 заданий разной сложности.

Чему учим на курсе:
⏺️находить уязвимости из OWASP Top-10 и понимать, как они устроены
⏺️анализировать веб-приложения и эксплуатировать найденное
⏺️свободно работать с nmap, wfuzz, ffuf, Burp Suite, WPScan, nikto, nuclei, sqlmap
⏺️применять методологии анализа защищённости
⏺️автоматизировать рутину

Навыки одинаково работают и в коммерческом пентесте, и в Bug Bounty.

Формат:
▶️4 месяца •144 ак. часа
▶️16 недель: 11 — программа + 5 — подготовка и сдача экзамена
▶️лаборатория на 66 заданий

Кураторы и авторы курса:
Александр Медведев — 10+ лет в ИБ, OSCP / PNPT / CEH / CWAPT / SQLIM, 3-кратный победитель Standoff в составе Codeby
Руслан Русланов — десятки проектов по пентесту крупных компаний и банков

Старт ближайшего потока — 16 июля. При оплате курса сразу, дарим скидку 30%

➡️Записаться

Бесплатная консультация — @CodebyAcademyBot

❓Пятничный опрос

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

А насколько хорошо вы разбираетесь в том, как работает REALITY? Проверим ⬆️

🚩 Новые задания на платформе HackerLab!

⚙️ Категория Реверс-инжиниринг — Dart'с

Приятного хакинга!

Три APK без иконок: как выглядит слежка на Android изнутри

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

И вот что важно: stalkerware и государственный spyware типа Pegasus — это два принципиально разных класса угроз, хотя оба шпионят. Путать их — значит ошибиться в модели угроз и потерять время на неправильных методах обнаружения.

➡️Немного цифр. По данным Kaspersky за 2023 год, 31 031 пользователь стал жертвой stalkerware. Россия лидирует — почти 10 тысяч случаев. Подписка на такое ПО стоит $10–70 в месяц. Pegasus — от сотен тысяч долларов за одну цель. Разница в цене отражает разницу в технологиях.

🔎 Как stalkerware держится на устройстве? Две основные точки закрепления:

• DeviceAdminReceiver — приложение получает права администратора, и пользователь не может его удалить, пока не отзовёт эти права. Проверяется командой adb shell dumpsys device_policy. Любой пакет в списке admin, кроме Google Find My Device или корпоративного MDM — красный флаг.

• Accessibility Services — через этот API stalkerware перехватывает переписки, снимает скриншоты, читает всё на экране. Проверка: adb shell settings get secure enabled_accessibility_services. У обычного пользователя тут один-два легитимных сервиса (TalkBack, Select to Speak). Неизвестное имя пакета — повод копать глубже.

🎇Быстрый чеклист для проверки Android-устройства:

1. adb shell pm list packages -3 — список сторонних пакетов. Ищите имена вроде «System Update Service», «Battery Optimizer», «Wi-Fi Manager» — классика маскировки.
2. Проверьте статус Google Play Protect. Stalkerware-вендоры в инструкциях прямо требуют его отключить.
3. Загляните в adb logcat — аномальные wake lock'и каждые 15 минут, обращения к RECORD_AUDIO, HTTP-запросы к дешёвым shared-хостингам.

А вот с Pegasus так не получится. Он не оставляет отдельного пакета в системе, инжектируется в легитимные процессы, зачищает следы. В logcat — тишина. Для его обнаружения нужен MVT и анализ бэкапов — совсем другой уровень инструментария.

Главный вывод: stalkerware примитивен технически, но именно поэтому его реально обнаружить базовыми средствами. Не нужен дорогой форензик-лаб — достаточно adb, внимательности и знания, куда смотреть.

В полной статье — детальный разбор kill chain обоих классов, таблица сравнения по MITRE ATT&CK и конкретные индикаторы компрометации.

https://codeby.net/threads/stalkerware-obnaruzheniye-na-android-tekhnicheskiye-otlichiya-ot-kommercheskogo-spyware-i-indikatory-komprometatsii.94162/

ИБ без фильтров – онлайн-конференция про реальные боли ИБ-специалистов

Мероприятие, где говорим о реальных проблемах и ищем практические решения. Честный диалог, нестандартные кейсы и полезный опыт — все без фильтров.

В этот раз ключевыми темами мероприятия будут:
✅ Утечки: где один инцидент ломает бизнес-процессы.
✅ 117-й приказ ФСТЭК: как не утонуть в требованиях.
✅ РКН уже рядом: готовы ли вы к цифровым проверкам.
✅ Как уязвимости, подрядчики и ДЗО становятся входом в инцидент.

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

🤝 Зарегистрироваться

Ждем вас на самый честный диалог по теме ИБ.

Учётка бухгалтера в 2:47 ночи на контроллере домена — и SOC почти проспал

Представьте: DLP молчит, SIEM выдаёт один алерт на аномальное время логина, а в это время атакующий через угнанную учётку четыре дня собирает финансовую отчётность и сливает её на Dropbox. Формально пользователь работает с файлами, доступными по роли. Итог — 40 человеко-часов на реагирование и полный пересмотр модели привилегированного доступа.

Это классический пример скомпрометированного инсайдера — одного из трёх типов внутренних угроз, которые стоит различать, если вы хотите их реально детектировать.

🔎По данным Ponemon Institute, 83% организаций зафиксировали хотя бы один инсайдерский инцидент, а средний годовой ущерб — $16,2 млн. При этом только 44% компаний используют UEBA — основной инструмент для обнаружения таких угроз. Разрыв между масштабом проблемы и зрелостью детекции — колоссальный.

Привычное деление на «умышленных» и «случайных» инсайдеров не работает. Методология CERT и отчёты Proofpoint выделяют три категории, и у каждой — свой kill chain и свои индикаторы:

❗️Malicious — злонамеренный инсайдер. Сознательно крадёт данные, саботирует системы, сливает информацию конкурентам. Мотивы — деньги, месть, идеология. Свежий кейс: в марте 2025 компания Deel внедрила сотрудника в штат Rippling под видом менеджера по комплаенсу. Четыре месяца он тихо выкачивал ценовые стратегии и клиентские списки через Slack и Salesforce — и ничего не сработало. DLP видит массовую выгрузку, но слеп к порционному сливу по 300 МБ за две недели.

• Negligent — небрежный инсайдер. Без злого умысла: клик по фишингу, файл не тому адресату, пароль Password123. Отдельная боль — GenAI. 76% организаций зафиксировали, как сотрудники копируют конфиденциальные данные в ChatGPT «для быстрого анализа». Классический DLP этот канал не покрывает, а он сейчас растёт быстрее всех остальных.

• Compromised — скомпрометированный инсайдер. Легитимный пользователь, чьи credentials угнал внешний атакующий. Для SIEM и DLP активность выглядит как обычная работа сотрудника. Kill chain неотличим от APT, и именно этот тип сложнее всего обнаружить.

Ключевой вывод: один detection-rule на все три типа — это путь к пропущенным инцидентам. Каждой категории нужна своя модель риска, свои триггеры и свой набор индикаторов.

В полной статье — MITRE ATT&CK маппинг для каждого типа, конкретные индикаторы и практические модели риска.

https://codeby.net/threads/tipy-insaiderskikh-ugroz-malicious-negligent-i-compromised-indikatory-kill-chain-i-modeli-riska.94167/

Один номер телефона → 14 аккаунтов, два email и след в трёх утечках. Без единого нелегального запроса

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

🔔Шаг 1 — валидация. Прежде чем копать дальше, убедись, что номер вообще активен. HLR-запрос через smsc.ru/testhlr/ или smspilot.ru/test.php покажет статус регистрации в сети, текущего оператора и флаг переноса номера. Важный нюанс: HLR показывает состояние SIM-карты, а не человека. Номер может быть активен, но лежать в ящике стола. Или принадлежать новому владельцу после перевыпуска.

Для российских номеров обязательно проверяй переносимость через реестр ЦНИИС — абонент мог сменить оператора, и префикс больше не соответствует реальности.

🔔Шаг 2 — мессенджеры. Это главный источник после валидации. WhatsApp, Telegram, Viber, Signal — добавление номера в контакты покажет, зарегистрирован ли аккаунт. В WhatsApp можно получить фото профиля, статус и раздел «О себе» (если настройки приватности позволяют). Фото — зацепка для обратного поиска по изображению.

Но учитывай OPSEC: такие проверки — это активная разведка. Ты генерируешь API-запросы к серверам платформ. Используй отдельный «исследовательский» номер и аккаунт — никогда свои основные.

🔔Шаг 3 — краудсорсинговые сервисы. GetContact, Sync.me, NumBuster агрегируют данные из контактных книг миллионов пользователей. Если кто-то записал номер как «Петров Олег логист», сервис это покажет. Но есть ловушка: при установке приложения твоя собственная контактная книга улетает на серверы сервиса. Деанонимизация исследователя в чистом виде.

➡️Где всё это в контексте ATT&CK? Телефонный OSINT — это тактика Reconnaissance: техники T1589 (сбор персональных данных), T1593 (поиск по открытым ресурсам) и T1596 (запросы к техническим базам). Результаты — не финальная точка, а входные данные для следующего этапа. В пентесте собранные идентификаторы идут в social engineering. В защите — каждый публичный корпоративный номер становится потенциальной точкой footprinting.

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

https://codeby.net/threads/osint-po-nomeru-telefona-ot-tsifr-k-polnomu-tsifrovomu-profilyu-instrumenty-i-metodologiya.94242/

4 компании, 4 аудита — и в каждой активные учётки уволенных с доступом к production

Рекорд из моей практики: сотрудник ушёл 11 месяцев назад, а его аккаунт всё ещё читал финансовые отчёты через SharePoint и держал действующий VPN-сертификат. HR закрыл заявку в тот же день, IT получил тикет через неделю, а до IAM-команды информация не дошла вообще.

И это не исключение — это норма.

❗️Проблема инсайдерских угроз не в мотивации человека, а в доступе, который у него остался. Внешнему атакующему нужен initial access — инсайдеру нет. У него уже есть badge, VPN и знание, где лежит ценное. Антивирус и EDR тут бессильны: человек работает штатными инструментами под легитимной учёткой.

Если наложить действия инсайдера на MITRE ATT&CK, цепочка выглядит так:

• T1078 Valid Accounts — credentials уже есть
• T1213 — сбор данных из SharePoint, Confluence (сотрудник знает структуру наизусть)
• T1567.002 — выгрузка через Google Drive или Яндекс.Диск
• T1531 — саботаж: удаление данных, блокировка коллег

Эту цепочку ломают три вещи.

🔔Первая — принцип минимальных привилегий как процесс, а не декларация. Не «доступ к CRM», а «read-only к объектам Contact в Salesforce, region = RU». На внутренних пентестах расхождение между ролевой моделью и реальными правами в AD — критическое в 9 из 10 случаев. BloodHound находит такие дыры за первый час.

🔔Вторая — access review по расписанию. Раз в квартал для обычных пользователей, раз в месяц для привилегированных. Privilege creep — реальная боль: сотрудник за три года переходов между отделами накапливает права пяти ролей и никто этого не замечает. Менеджеры ненавидят эту процедуру, но без неё вы слепы.

🔔Третья — offboarding с SLA в один час. Не в один день, не «когда IT доберётся». Единая система тикетов, автоматическая цепочка: HR фиксирует увольнение → IAM блокирует учётку → VPN-сертификат отзывается → физический пропуск деактивируется. Без ручных передач между отделами в Telegram.

Классический антипаттерн — политика, написанная идеально, но в Okta живёт группа all-employees-full-access, а в AD — вложенные группы от пяти реорганизаций. Документ для аудитора ≠ безопасность.

В полной статье — конкретные запросы для SIEM, скрипты для обнаружения orphan-аккаунтов и пошаговый offboarding-чеклист.

https://codeby.net/threads/zashchita-ot-insaiderskikh-ugroz-access-review-offboarding-i-politiki-ib-na-praktike.94273/