Codeby

Oleobj: извлечение встроенных объектов из OLE-файлов oleobj — это инструмент из пакета oletools, предназначенный для извлечения встроенных объектов из OLE-файлов (Microsoft Office 97-2003, MSI, Outlook-сообщения и другие). Он позволяет обнаруживать и сохранять объекты, которые могут содержать вредоносный код, включая исполняемые файлы, скрипты и документы, встроенные в контейнеры OLE. 👉 Основные возможности - извлечение встроенных объектов из OLE-файлов - поддержка рекурсивного поиска в поддиректориях - работа с ZIP-архивами, содержащими OLE-документы - сохранение извлечённых объектов в указанную директорию - режим подробного логирования для отладки - обнаружение начальной стадии эксплуатации CVE-2021-40444 ⬇️ Установка sudo apt install oletools Проверка oleobj -h ⏺️ Базовое извлечение объектов oleobj document.doc ⏺️ Извлечение объектов в указанную директорию oleobj -d ./extracted malicious.doc ⏺️ Рекурсивный анализ всех файлов в каталоге oleobj -r /path/to/documents/ ⏺️ Подробный режим с логированием oleobj -V document.doc #oleobj #oletools #malwareanalysis #security #forensics #tool 🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

🚩 Новые задания на платформе HackerLab! 🧰 Категория PWN — Я в своём познании настолько преисполнился Приятного хакинга!

35 из 40 резюме — в корзину. Что не так с junior-пентестерами? За последний квартал я отсмотрел больше сорока резюме на позицию junior pentester. Тридцать пять из них — под копирку: «Kali Linux, Burp Suite, Nmap. 15 машин на HTB. Сертификат CEH». Ни одно не дошло до технического интервью. Проблема не в знаниях — в подаче. 🔎Лид тратит на резюме 20–30 секунд. За это время он ищет не список инструментов, а три сигнала: • Контекст вместо перечисления. Строка «Nmap, Burp Suite, Metasploit» — как список покупок. Видно, что ходил в магазин, но непонятно, умеешь ли готовить. А вот «Провёл внутренний пентест сегмента на 150 хостов, обнаружил Kerberoasting-вектор через сервисный аккаунт с SPN, восстановил пароль hashcat за 4 часа» — тут уже видно, что человек понимает суть. • Результат вместо процесса. «Изучал OWASP Top 10» — процесс. «Нашёл Blind SQL Injection в форме авторизации стенда, автоматизировал эксплуатацию через sqlmap --technique=T, извлёк 12 таблиц» — результат. Первая формулировка летит в корзину, вторая попадает в шорт-лист. • Честность в грейде. Кандидат пишет «опыт пентеста Active Directory», а на собеседовании не может объяснить разницу между Kerberoasting и AS-REP Roasting. Минус не за незнание, а за враньё. Честный junior всегда ценнее раздутого «мидла». ➡️Отдельная боль — портфолио. Я видел кандидатов с 50 решёнными машинами, которые не могли объяснить, почему nmap -sS отправляет SYN без завершения three-way handshake. И видел тех, у кого 8 машин, но каждая разобрана до винтика с writeup на три страницы. Угадайте, кто получал оффер. Пять качественных writeup-ов на GitHub ценнее пятидесяти флагов без объяснения. Хороший writeup — не скриншот флага, а документ, показывающий мышление: разведка → гипотезы → эксплуатация → постэксплуатация → рекомендации по защите. Кандидат с таким портфолио автоматически проходит в следующий раунд — я вижу, как он думает, ещё до встречи. 🎇Ещё один сильный сигнал — хотя бы один принятый отчёт в bug bounty. Живой продук

🎇Как отличить полезный ИБ-канал от информационного мусора за 30 секунд Полтора года назад у меня было 40+ подписок по кибербезопасности и 847 непрочитанных сообщений. Половина каналов дублировала одни и те же новости, треть репостила чужие скриншоты без контекста, а настоящие write-up'ы я находил случайно перед сном. Знакомо? После ревизии осталось 12 каналов. Через месяц лабы на TryHackMe стал закрывать быстрее, потому что наконец читал осмысленно, а не сканировал заголовки по диагонали. Вот три типа каналов, которые стоит различать до подписки: 📌Авторский блог — автор пишет от своего имени, разбирает техники, делится результатами лабораторных работ. Признаки: связный текст, ответы в комментариях, повторяющиеся рубрики, команды вроде nmap или Burp Suite в постах. 📌Агрегатор — собирает публикации из нескольких источников с минимальным комментарием. Широкий охват повестки, но глубины нет. Годится для мониторинга, не для обучения. 📌Репост-помойка — механический дубль постов из других каналов без добавленной ценности. Кликбейтные заголовки, ноль авторского текста, каша из тем. Таких — большинство. Проходим мимо. Быстрый чек перед подпиской: откройте канал, пролистайте 20 последних постов. Если больше половины — голые ссылки без комментариев, это агрегатор. Если есть разборы с командами и скриншотами терминала — авторский блог. Если всё вперемешку без логики — не тратьте время. А теперь главное — что конкретно читать новичку? Типичная болезнь подборок — сваливать в кучу всё от OSINT до промышленной безопасности АСУ ТП. Без фильтра по уровню входа это бесполезно. Несколько каналов, проверенных на практике: • Авторские блоги с write-up'ами по этичному хакингу — те, где показывают не просто «нашли уязвимость», а почему она критична и каков вектор эксплуатации • Каналы по OSINT — разведка на основе открытых источников, это первый этап любого пентеста (по MITRE ATT&CK — техника Reconnaissance) • Сообщества с живым чатом — где можно задать вопрос по конкретной лабе

🧿 Как браузер получает страницу Вы вводите адрес сайта, и через долю секунды видите страницу. За это время клиент и сервер успевают обменяться целой серией сообщений. Именно так это происходит: ▶️ DNS. Браузер узнаёт IP-адрес сервера по имени сайта. ▶️ TCP-рукопожатие. SYN → SYN-ACK → ACK: клиент и сервер договариваются о соединении на порту 80. ▶️ HTTP-запрос. Сразу за ACK уходит GET /index.html. ▶️ Обработка. Свободный воркер сервера читает файл с диска. ▶️ Ответ 200 OK. HTML возвращается клиенту, разбитый на TCP-сегменты. ▶️ Рендер. Браузер разбирает HTML и рисует страницу. ▶️ Keep-alive. Соединение остаётся открытым, и следующий запрос обходится без рукопожатия. 🔎 При задержке 20 мс в одну сторону весь цикл занимает около 112 мс. Для HTTPS добавляется ещё TLS-рукопожатие на порту 443. 🧠 Эти этапы полезно знать при анализе трафика, расследовании инцидентов и разборе логов веб-сервера: каждый из них оставляет свои следы. #сети #HTTP #TCP #веб #основы 🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

🔎Скрапер не ломает — он просто читает. И в этом главная проблема В 2023 году Chess.com подтвердила утечку данных миллионов профилей. Ни SQL-инъекций, ни компрометации серверов — атакующий просто отправлял валидные GET-запросы к публичному API, подставляя юзернеймы из словаря. Каждый запрос по отдельности выглядел абсолютно легитимно. SIEM молчал. Алертов — ноль. И это не уникальный случай. Паттерн один и тот же: предсказуемые идентификаторы, одинаковый throttling на всех эндпоинтах и полное отсутствие детектирования до момента, когда дамп уже в продаже. ❓Зачем скраперу ваши профили? Не стоит недооценивать «просто чтение». Собранные email, username, дата регистрации и привязанные соцсети — это топливо для: ⏺️Credential stuffing — если email активен на вашей платформе, атакующий прицельно бьёт по нему паролями из других утечек ⏺️Таргетированного фишинга — «Поздравляем с рейтингом 1800, подтвердите аккаунт» работает в разы лучше массовой рассылки ⏺️Перепродажи на теневых площадках — базы с tier-статусами подписчиков имеют прямую коммерческую ценность По OWASP API Security Top 10 это сразу два риска: Unrestricted Resource Consumption и Unrestricted Access to Sensitive Business Flows. 🎯Как распознать скрапера в логах? Вот реальная картина из практики. Эндпоинт /api/v2/users/{id} за выходные обработал в 40 раз больше запросов, чем обычно. RPS с одного /24-подсета — стабильные 12 запросов в секунду, ровно на 2 ниже порога rate-limiter'а. Кто-то аккуратно подобрал скорость. Что выдаёт бота: • Интервал между запросами 83±2 мс — такая периодичность невозможна для человека • Один и тот же User-Agent без единой вариации за 48 часов • Последовательный перебор ID: /api/user/1001, /api/user/1002, /api/user/1003 • Нет навигационного контекста — бот бьёт только в один эндпоинт, как дятел • IP из хостинг-подсетей (DigitalOcean, Hetzner, OVH) • Доля 404-ответов выше 30% — перебор несуществующих ID 📌Ключевой принцип для SOC: алерт должен срабатывать на паттерн, а не на едини

Переговорщик по рансомвеару арестован ФБР: где заканчивается белый хакинг? Представьте: вы вызвали слесаря вскрыть замок в своей квартире. Он справился, но тайком снял копию ключа. Формально помог, фактически — получил доступ к вашему дому навсегда. Именно так выглядит обвинение против Эдварда Дубровского — канадского эксперта с 30-летним стажем в кибербезопасности, арестованного ФБР в октябре 2026 года. Человек руководил реагированием на инциденты, преподавал в университете, написал книгу, вёл переговоры с хакерскими группировками от имени жертв. А потом — два обвинения: сговор с целью вымогательства и вмешательство в межштатную коммерцию по Hobbs Act. Контекст шире, чем кажется. Переговорщик по рансомвеару — человек, который знает всё: какие данные украдены, сколько жертва готова заплатить, где её слабые места. И никакого формального контроля над тем, как он этой информацией распоряжается. Нет стандартизированных протоколов, нет обязательной сертификации, нет единых этических требований. Регуляторный вакуум в чистом виде. Параллельно с делом Дубровского всплыла группировка ShinyHunters, которая, по данным следствия, скомпрометировала более 140 организаций и получила свыше 70 миллионов долларов вымогательных платежей. Точка входа? Подрядчик, который не установил доступный патч. Один пропущенный апдейт — и в открытом доступе адреса сотрудников ФБР, их телефоны, медицинские данные, сведения о разведывательных заданиях. 🔑Но главный урок тут не про патчи. Он про границы. Закон не спрашивает о намерениях. В США CFAA определяет любой несанкционированный доступ как преступление — неважно, нашли ли вы уязвимость «во благо». В России картина не мягче: • Ст. 272 УК РФ — неправомерный доступ, до 7 лет • Ст. 273 УК РФ — вредоносные программы, до 7 лет • Ст. 163 УК РФ — вымогательство: нашли уязвимость и требуете деньги за молчание При этом в России до сих пор нет чёткого определения белого хакинга как легальной деятельности. По опросам, только 39% специалистов оцениваю

90 секунд до account takeover: почему password reset — самое слабое звено вашей инфраструктуры Два часа разведки, fingerprinting стека, изучение периметра — а захват аккаунта администратора занял полторы минуты. Один POST-запрос к эндпоинту сброса пароля, и сервер молча принял новый пароль без email-подтверждения. Без токена. Без верификации текущего пароля. Просто взял и сбросил. Это не теоретическая атака. Два свежих CVE показывают, как именно это работает на практике. 🎇CVE-2026-23760 (SmarterMail) — CVSS 9.8, CRITICAL Эндпоинт /api/v1/auth/force-reset-password принимал анонимные запросы. Отправляешь POST с именем пользователя и новым паролем — готово, аккаунт твой. Никакой аутентификации, никакого reset-токена. Уязвимы все версии до билда 9511. Насколько это серьёзно? CISA добавила уязвимость в каталог Known Exploited Vulnerabilities и пометила связь с ransomware-кампаниями. EPSS — 0.9654, то есть Top 0.12% по вероятности эксплуатации среди всех CVE в базе. Публичный PoC на GitHub, готовый Nuclei-шаблон — порог входа для атакующего практически нулевой. 🎇CVE-2026-18963 (Keycloak) — CVSS 9.1, CRITICAL Тут другой паттерн, но результат тот же. Некорректная проверка состояния в потоке reset-credentials: атакующий отправлял специально сформированный запрос, и сессия перескакивала сразу к этапу обновления пароля, минуя email-верификацию. Уязвимы Keycloak до 26.7.2, RHBK 26.4 до 26.4.15, RHBK 26.6 до 26.6.6. Пока активной эксплуатации не зафиксировано, но CISA оценивает автоматизируемость как yes, а технический импакт — total. Три публичных PoC на GitHub. Вопрос не «если», а «когда». Что делать прямо сейчас: • SmarterMail — обновиться до билда 9511+. Если патч невозможен — WAF-правило на блокировку POST к /api/v1/auth/force-reset-password и IP-whitelist для админки • Keycloak — обновиться до 26.7.2. Временная мера: отключить Forgot Password в каждом realm через Realm Settings → Login. Глобального переключателя нет, придётся пройтись по каждому • На пентесте — п