home.social

#incident_response — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #incident_response, aggregated by home.social.

  1. Linux Incident Response: системный подход. Часть 2

    Это вторая часть статьи про Linux Incident Response — разбор live response на работающем Linux-хосте с подозрением на компрометацию. Если вы не читали первую часть, лучше начать с неё: в ней разобрали принципы расследования, изоляцию хоста, trusted toolkit, фиксацию исходного состояния, сетевые соединения и процессы. Без этого контекста часть команд и логика дальнейшего анализа будут менее понятны. Первая часть здесь . В этой части процесс идет далее — к менее изменчивым артефактам. Рассмотрим механизмы закрепления и следы на диске: systemd-сервисы и timers, cron, автозапуск, пользователи, группы, пакеты, логи, kernel-артефакты. В финале расскажем о построении таймлайна, оформлении IOC и действия с системой после завершения расследования.

    habr.com/ru/companies/first/ar

    #ioc #yara #incident_response

  2. Linux Incident Response: системный подход. Часть 2

    Это вторая часть статьи про Linux Incident Response — разбор live response на работающем Linux-хосте с подозрением на компрометацию. Если вы не читали первую часть, лучше начать с неё: в ней разобрали принципы расследования, изоляцию хоста, trusted toolkit, фиксацию исходного состояния, сетевые соединения и процессы. Без этого контекста часть команд и логика дальнейшего анализа будут менее понятны. Первая часть здесь . В этой части процесс идет далее — к менее изменчивым артефактам. Рассмотрим механизмы закрепления и следы на диске: systemd-сервисы и timers, cron, автозапуск, пользователи, группы, пакеты, логи, kernel-артефакты. В финале расскажем о построении таймлайна, оформлении IOC и действия с системой после завершения расследования.

    habr.com/ru/companies/first/ar

    #ioc #yara #incident_response

  3. Linux Incident Response: системный подход. Часть 2

    Это вторая часть статьи про Linux Incident Response — разбор live response на работающем Linux-хосте с подозрением на компрометацию. Если вы не читали первую часть, лучше начать с неё: в ней разобрали принципы расследования, изоляцию хоста, trusted toolkit, фиксацию исходного состояния, сетевые соединения и процессы. Без этого контекста часть команд и логика дальнейшего анализа будут менее понятны. Первая часть здесь . В этой части процесс идет далее — к менее изменчивым артефактам. Рассмотрим механизмы закрепления и следы на диске: systemd-сервисы и timers, cron, автозапуск, пользователи, группы, пакеты, логи, kernel-артефакты. В финале расскажем о построении таймлайна, оформлении IOC и действия с системой после завершения расследования.

    habr.com/ru/companies/first/ar

    #ioc #yara #incident_response

  4. Linux Incident Response: системный подход. Часть 1

    Пару лет назад я уже публиковал статью о реагировании на инциденты в Linux-системах. Она по-прежнему может быть полезна как практическая шпаргалка, но с тех пор изменился и мой опыт, и требования к таким материалам. В этом цикле статей я хочу разобрать Linux live response более системно. Большинство материалов по Linux IR сводятся к спискам команд: посмотреть процессы, сеть, пользователей, cron, логи. Проблема в том, что сами по себе команды мало что дают, если нет порядка их применения, ограничения live response, смысл полученного вывода и вообще — методологии, базиса работы. Этот материал исправляет такие упущения. Он будет разбит на две части. В этой статье обсудим принципы расследования, изоляции, подготовки инструментария, начала анализа и исследования сети и процессов. Добро пожаловать под кат.

    habr.com/ru/companies/first/ar

    #incident_response #yara #ioc

  5. Linux Incident Response: системный подход. Часть 1

    Пару лет назад я уже публиковал статью о реагировании на инциденты в Linux-системах. Она по-прежнему может быть полезна как практическая шпаргалка, но с тех пор изменился и мой опыт, и требования к таким материалам. В этом цикле статей я хочу разобрать Linux live response более системно. Большинство материалов по Linux IR сводятся к спискам команд: посмотреть процессы, сеть, пользователей, cron, логи. Проблема в том, что сами по себе команды мало что дают, если нет порядка их применения, ограничения live response, смысл полученного вывода и вообще — методологии, базиса работы. Этот материал исправляет такие упущения. Он будет разбит на две части. В этой статье обсудим принципы расследования, изоляции, подготовки инструментария, начала анализа и исследования сети и процессов. Добро пожаловать под кат.

    habr.com/ru/companies/first/ar

    #incident_response #yara #ioc

  6. Linux Incident Response: системный подход. Часть 1

    Пару лет назад я уже публиковал статью о реагировании на инциденты в Linux-системах. Она по-прежнему может быть полезна как практическая шпаргалка, но с тех пор изменился и мой опыт, и требования к таким материалам. В этом цикле статей я хочу разобрать Linux live response более системно. Большинство материалов по Linux IR сводятся к спискам команд: посмотреть процессы, сеть, пользователей, cron, логи. Проблема в том, что сами по себе команды мало что дают, если нет порядка их применения, ограничения live response, смысл полученного вывода и вообще — методологии, базиса работы. Этот материал исправляет такие упущения. Он будет разбит на две части. В этой статье обсудим принципы расследования, изоляции, подготовки инструментария, начала анализа и исследования сети и процессов. Добро пожаловать под кат.

    habr.com/ru/companies/first/ar

    #incident_response #yara #ioc

  7. ----------------

    🛠️ Tool: Awesome Incident Response
    ===================

    The Awesome Incident Response repository is a curated collection of DFIR tools and resources organized into over 20 categories, aimed at security analysts and incident response teams.

    🔹 Adversary Emulation Tools

    The repository lists several adversary emulation frameworks that allow blue teams to test their detection capabilities:
    • APTSimulator: A Windows batch script that uses a set of tools and output files to make a system appear as if it was compromised by an advanced threat actor
    • Atomic Red Team (ART): Red Canary's collection of small, portable detection tests mapped directly to the MITRE ATT&CK framework
    • Caldera: MITRE's automated adversary emulation system that performs post-compromise adversarial behavior within Windows enterprise networks, generating plans using a planning system and pre-configured adversary models based on ATT&CK
    • RTA (Red Team Automation): Endgame's framework of scripts designed to allow blue teams to test detection capabilities against malicious tradecraft modeled after MITRE ATT&CK
    • Network Flight Simulator: A lightweight utility from AlphaSOC that generates malicious network traffic to evaluate security controls and network visibility
    • DumpsterFire: A modular, menu-driven, cross-platform tool for building repeatable, time-delayed, distributed security events for Blue Team drills and Red Team decoy operations

    🔹 Evidence Collection by Platform

    The repository separates evidence collection into platform-specific categories: Windows, Linux, and OSX. This separation is operationally practical because IR procedures and available tooling differ significantly between operating systems. During time-sensitive investigations, analysts can go directly to the relevant platform section without filtering through unrelated tools.

    🔹 Memory Forensics

    Two distinct categories address memory work:
    • Memory Imaging Tools: For acquiring volatile memory from live systems during initial response
    • Memory Analysis Tools: For examining acquired memory images to extract processes, network connections, loaded modules, and other artifacts

    This separation mirrors the actual IR workflow where acquisition and analysis are performed at different stages, often by different team members.

    🔹 Timeline and Log Analysis

    Timeline reconstruction is critical for understanding attack progression and scope. The repository catalogs dedicated timeline tools alongside log analysis utilities, covering both artifact correlation and raw log parsing capabilities.

    🔹 Additional Resources

    Beyond tools, the repository catalogs books, communities, knowledge bases, purpose-built Linux distributions (including RedHunt-OS for adversary emulation and threat hunting), playbooks for structured IR procedures, and training videos.

    🔹 Considerations

    The repository includes an automated URL check workflow, indicating some level of ongoing maintenance. However, individual tool relevance, compatibility with current operating system versions, and maintenance status should be verified before operational deployment. The "Awesome" list format does not include tool version tracking, compatibility matrices, or maturity assessments.

    🔹 DFIR #incident_response #forensics #bookmark #tool

    🔗 Source: github.com/meirwah/awesome-inc

  8. ----------------

    🛠️ Tool
    ===================

    Opening
    This repository is a community-driven collection of DFIR "skills" intended as reusable artifacts for AI-assisted incident response. Each skill is a small workflow: a prompt, stated inputs/outputs, and helper snippets such as regexes or parsers.

    Key Features
    • Clear input/output contract for each skill, which reduces ambiguity when feeding artifacts to an LLM.
    • Helper files: regex snippets, parsers, example queries and simple templates to extract fields from logs or memory dumps.
    • Multi-assistant orientation: examples target Claude skills and OpenAI/Codex-style skill folders.

    Technical implementation
    The repo is organized under skills/ with a common template skills/_templates/skill.md. Typical structure is:

    skills/
    ├── README.md
    └── <category>/<skill-id>/
    ├── skill.md
    └── helpers/
    ├── queries.txt
    └── extractor_regex.txt

    Skills expect the operator to supply artifacts and to keep placeholders such as {{time_window}} or {{target_host}} unmodified until prompted.

    Use cases
    • Rapid IOC extraction from logs using provided regex/parsers.
    • Standardized interview prompts for evidence collection across analysts.
    • Quick triage workflows for malware indicators, endpoint telemetry, and timeline construction.

    Installation / Integration
    For Claude: drop skill folder into the assistant workspace per Claude Skills docs. For Codex/OpenAI tooling: mirror skills into the local $REPO_ROOT/.codex/skills or similar path so the assistant can reference them.

    Limitations
    • Skills are templates. They rely on the assistant and the operator for accuracy; AI outputs must be validated against raw artifacts.
    • Coverage varies by category; not every common IR scenario has a ready skill.

    Notes
    Note: tool not independently verified. Users should review and test skills before operational use.

    🔹 dfir #incident_response #tool

    🔗 Source: github.com/tsale/awesome-dfir-

  9. Охота на Emmenhtal: как мы восстановили полную kill chain банковского трояна с переформатированного диска

    Разбираем реальный IR-кейс: ClickFix → Emmenhtal Loader → банковский троян с Telegram C2. Форензик переформатированного диска на 930 ГБ, VDM-дисамбигуация ложноположительных и восстановление артефактов из hibernation-файла.

    habr.com/ru/articles/1021698/

    #DFIR #форензика #malware_analysis #банковский_троян #Emmenhtal #ClickFix #threat_hunting #YARA #fileless_malware #incident_response

  10. Охота на Emmenhtal: как мы восстановили полную kill chain банковского трояна с переформатированного диска

    Разбираем реальный IR-кейс: ClickFix → Emmenhtal Loader → банковский троян с Telegram C2. Форензик переформатированного диска на 930 ГБ, VDM-дисамбигуация ложноположительных и восстановление артефактов из hibernation-файла.

    habr.com/ru/articles/1021698/

    #DFIR #форензика #malware_analysis #банковский_троян #Emmenhtal #ClickFix #threat_hunting #YARA #fileless_malware #incident_response

  11. Охота на Emmenhtal: как мы восстановили полную kill chain банковского трояна с переформатированного диска

    Разбираем реальный IR-кейс: ClickFix → Emmenhtal Loader → банковский троян с Telegram C2. Форензик переформатированного диска на 930 ГБ, VDM-дисамбигуация ложноположительных и восстановление артефактов из hibernation-файла.

    habr.com/ru/articles/1021698/

    #DFIR #форензика #malware_analysis #банковский_троян #Emmenhtal #ClickFix #threat_hunting #YARA #fileless_malware #incident_response

  12. Анатомия PhaaS-кита: как коммерческая фишинговая платформа фильтрует песочницы через browser fingerprinting

    Разбираем фишинговое письмо, пришедшее на адрес НКО: от SendGrid-доставки с SPF/DKIM pass до реверса JavaScript-фреймворка collector.js, который собирает GPU fingerprint, ломает WebRTC для раскрытия IP за VPN и детектирует DevTools — до того как жертва увидит фишинговую форму.

    habr.com/ru/articles/1014420/

    #phishing #phishingasaservice #browser_fingerprinting #webrtc #sendgrid #incident_response #threat_intelligence #javascript

  13. Анатомия PhaaS-кита: как коммерческая фишинговая платформа фильтрует песочницы через browser fingerprinting

    Разбираем фишинговое письмо, пришедшее на адрес НКО: от SendGrid-доставки с SPF/DKIM pass до реверса JavaScript-фреймворка collector.js, который собирает GPU fingerprint, ломает WebRTC для раскрытия IP за VPN и детектирует DevTools — до того как жертва увидит фишинговую форму.

    habr.com/ru/articles/1014420/

    #phishing #phishingasaservice #browser_fingerprinting #webrtc #sendgrid #incident_response #threat_intelligence #javascript

  14. Анатомия PhaaS-кита: как коммерческая фишинговая платформа фильтрует песочницы через browser fingerprinting

    Разбираем фишинговое письмо, пришедшее на адрес НКО: от SendGrid-доставки с SPF/DKIM pass до реверса JavaScript-фреймворка collector.js, который собирает GPU fingerprint, ломает WebRTC для раскрытия IP за VPN и детектирует DevTools — до того как жертва увидит фишинговую форму.

    habr.com/ru/articles/1014420/

    #phishing #phishingasaservice #browser_fingerprinting #webrtc #sendgrid #incident_response #threat_intelligence #javascript

  15. Запустить легко, эксплуатировать сложно: год жизни SOC «Газпром-Медиа Холдинга»

    В 2024 году мы рассказывали , как развернули масштабный центр мониторинга безопасности над «Газпром-Медиа». Тогда даже позволили себе тезис о том, что способны подключить любой актив к мониторингу за одни сутки. Это правда, но опытный инженер, прошедший через реалии корпоративной среды, скажет вам, что запустить систему в продакшен — это всего лишь начало. А вот эксплуатировать ее на живой, постоянно изменяющейся инфраструктуре, где каждый день меняются сетевые доступы и появляются новые сервисы, — долгосрочная задача повышенной сложности. Что происходит, когда центр мониторинга безопасности федерального холдинга превышает отметку в 100 000 событий в секунду? Когда стандартные решения начинают буксовать, а инфраструктура разрастается до 100 сервисов? В 2025 году наша команда столкнулась именно с такими вызовами. В этой статье расскажем, как мы решали архитектурные «головоломки» высоконагруженного SIEM, боролись с экзотическими форматами логов медийных систем, создавали кастомные коннекторы и как Purple Team-учения помогли обнаружить настоящих злодеев.

    habr.com/ru/companies/bastion/

    #soc #SIEM #информационная_безопасность #мониторинг #ClickHouse #KUMA #incident_response #высокие_нагрузки #корпоративная_безопасность #логирование

  16. Запустить легко, эксплуатировать сложно: год жизни SOC «Газпром-Медиа Холдинга»

    В 2024 году мы рассказывали , как развернули масштабный центр мониторинга безопасности над «Газпром-Медиа». Тогда даже позволили себе тезис о том, что способны подключить любой актив к мониторингу за одни сутки. Это правда, но опытный инженер, прошедший через реалии корпоративной среды, скажет вам, что запустить систему в продакшен — это всего лишь начало. А вот эксплуатировать ее на живой, постоянно изменяющейся инфраструктуре, где каждый день меняются сетевые доступы и появляются новые сервисы, — долгосрочная задача повышенной сложности. Что происходит, когда центр мониторинга безопасности федерального холдинга превышает отметку в 100 000 событий в секунду? Когда стандартные решения начинают буксовать, а инфраструктура разрастается до 100 сервисов? В 2025 году наша команда столкнулась именно с такими вызовами. В этой статье расскажем, как мы решали архитектурные «головоломки» высоконагруженного SIEM, боролись с экзотическими форматами логов медийных систем, создавали кастомные коннекторы и как Purple Team-учения помогли обнаружить настоящих злодеев.

    habr.com/ru/companies/bastion/

    #soc #SIEM #информационная_безопасность #мониторинг #ClickHouse #KUMA #incident_response #высокие_нагрузки #корпоративная_безопасность #логирование

  17. Запустить легко, эксплуатировать сложно: год жизни SOC «Газпром-Медиа Холдинга»

    В 2024 году мы рассказывали , как развернули масштабный центр мониторинга безопасности над «Газпром-Медиа». Тогда даже позволили себе тезис о том, что способны подключить любой актив к мониторингу за одни сутки. Это правда, но опытный инженер, прошедший через реалии корпоративной среды, скажет вам, что запустить систему в продакшен — это всего лишь начало. А вот эксплуатировать ее на живой, постоянно изменяющейся инфраструктуре, где каждый день меняются сетевые доступы и появляются новые сервисы, — долгосрочная задача повышенной сложности. Что происходит, когда центр мониторинга безопасности федерального холдинга превышает отметку в 100 000 событий в секунду? Когда стандартные решения начинают буксовать, а инфраструктура разрастается до 100 сервисов? В 2025 году наша команда столкнулась именно с такими вызовами. В этой статье расскажем, как мы решали архитектурные «головоломки» высоконагруженного SIEM, боролись с экзотическими форматами логов медийных систем, создавали кастомные коннекторы и как Purple Team-учения помогли обнаружить настоящих злодеев.

    habr.com/ru/companies/bastion/

    #soc #SIEM #информационная_безопасность #мониторинг #ClickHouse #KUMA #incident_response #высокие_нагрузки #корпоративная_безопасность #логирование

  18. 🚨 Incident Response
    ===================

    Executive summary: A real-world red team engagement demonstrated how a compromised Veeam Backup & Replication server can be an escalation pivot to full Domain Admin. The engagement began with an Active Directory misconfiguration and ended with domain-wide privileges after extracting backup-related credentials.

    Technical details:
    • Compromised host: Veeam Backup & Replication server.
    • Exposed artifacts: service account credentials, access to backup repositories, backup job configurations and encrypted domain-level credentials contained in backup metadata or configuration stores.
    • Initial vector: AD misconfiguration that allowed access to the Veeam host.

    Analysis:
    • Backup servers frequently store high-privilege secrets by design (service accounts, domain credential blobs, and recovery credentials). Compromise of those hosts provides both lateral movement and privilege escalation opportunities.
    • The engagement shows the combination of credential exposure in backups and repository access is sufficient to reconstruct domain-level access paths.

    Detection:
    • Monitor changes and remote access to backup servers and to accounts used by backup services.
    • Audit access to backup repositories and any processes that read encrypted credential blobs or configuration exports.
    • Track anomalous enumeration of backup job configurations and unusually timed repository reads.

    Mitigation (as described in the engagement):
    • Treat backup infrastructure as a high-value asset: limit administrative access, isolate backup network paths, and apply least-privilege to service accounts.
    • Protect backup repositories and rotate service credentials; ensure credential material in backups is guarded by strong encryption and access controls.

    References / keywords: Veeam Backup & Replication, Active Directory misconfiguration, service account exposure, backup repository access, encrypted domain credentials.

    🔹 backup_security #veeam #incident_response

    🔗 Source: whiteknightlabs.com/2025/12/09

  19. 🚨 Incident Response
    ===================

    Executive summary: This guide provides a 10-step investigation workflow for Business Email Compromise (BEC) incidents within Office 365 environments. It is designed to help incident response teams identify, collect and analyse mailbox- and tenant-level artifacts relevant to impersonation, forwarding abuse and account takeover.

    Technical details:
    • The guide emphasises review of mailbox audit logs, message trace, mail-flow rules (transport rules) and eDiscovery exports as primary evidence sources.
    • Key artefacts highlighted include unusual SendAs/SendOnBehalf events, newly created inbox rules that forward or delete messages, anomalous OAuth app consent events, and unexpected mailbox folder movements.
    • Tenant-level indicators include changes to mail-flow configuration, additions to send connectors, and modifications to conditional access or MFA settings.

    Analysis and detection guidance:
    • The workflow recommends correlating mailbox audit events with message trace entries and Azure AD sign-in logs to link message delivery anomalies to authentication or session anomalies.
    • Detection focus areas are: new inbox rules that create forwarding to external addresses, SendAs spikes originating from unusual IPs, and simultaneous role/permission changes across accounts.

    Conceptual implementation (no commands):
    • Collect mailbox and tenant audit data for the suspected timeframe, prioritise mailboxes involved in financial workflows, and preserve eDiscovery exports for chain-of-custody.
    • Use correlation across Exchange Online, Azure AD sign-ins and conditional access changes to establish timeline and scope.

    Best practices and limitations:
    • Best practices include capturing comprehensive audit logs early, documenting access and evidence handling, and validating mail-flow rule histories.
    • Limitations include possible log retention gaps depending on tenant configuration and the need for eDiscovery access to export mailbox content.

    Practical use cases:
    • The guide supports investigations of CFO impersonation scams, vendor invoice fraud, and mass forwarding events used to exfiltrate emails.

    References:
    • Contact for incident support: [email protected]

    🔹 BEC #incident_response #office365 #exchange_online #eDiscovery

    🔗 Source: github.com/PwC-IR/Business-Ema

  20. Как мы научили нейросеть искать связи между инцидентами в SOC

    Представьте круглосуточную работу в SOC. В понедельник аналитик первой смены расследует вирусное заражение через почту. В среду аналитик второй смены разбирает алерт от NGFW о передаче вредоносного файла. Оба профессионалы, оба закрывают алерты по регламенту. Но они не заметили, что разбирали два шага одной атаки, просто потому, что ключевая улика — хитрое название сигнатуры — затерялась в простыне текстового описания, а не лежала в отдельном поле. Вот он, «цифровой туман». Проблема не в том, что скрипты не умеют сравнивать строки, они не понимают, что HOSTNAME и hostname.corp.local — по сути одно и то же. Они далеко не всегда могут выцепить IP-адрес из комментария заказчика. А когда за день сыплются десятки, а то и сотни алертов, искать подобные связи руками — это прямо боль. В поисках лекарства мы пошли на рискованный эксперимент: решили построить систему, которая находит неочевидные связи с помощью LLM. А валидатором выбрали человека, который называет себя «одним из основных хейтеров LLM и нейросетей». Под катом Кирилл Рупасов, технический директор SOC К2 Кибербезопасность, Юлия Гильмуллина, старший инженер-разработчик К2Тех, и Татьяна Белякова, ведущий системный аналитик К2Тех расскажут о том, как подружить Gemma, Qdrant и DBSCAN. Как прагматичный инжиниринг, борьба с галлюцинациями и месяцы ручной отладки заставили главного скептика признать: да, в таком виде это действительно работает.

    habr.com/ru/companies/k2tech/a

    #soc #мониторинг #анализ_инцидентов #расследование_инцидентов #incident_response #автоматизация #нейросети #llm #threat_hunting #ai_в_кибербезопасности

  21. Как мы научили нейросеть искать связи между инцидентами в SOC

    Представьте круглосуточную работу в SOC. В понедельник аналитик первой смены расследует вирусное заражение через почту. В среду аналитик второй смены разбирает алерт от NGFW о передаче вредоносного файла. Оба профессионалы, оба закрывают алерты по регламенту. Но они не заметили, что разбирали два шага одной атаки, просто потому, что ключевая улика — хитрое название сигнатуры — затерялась в простыне текстового описания, а не лежала в отдельном поле. Вот он, «цифровой туман». Проблема не в том, что скрипты не умеют сравнивать строки, они не понимают, что HOSTNAME и hostname.corp.local — по сути одно и то же. Они далеко не всегда могут выцепить IP-адрес из комментария заказчика. А когда за день сыплются десятки, а то и сотни алертов, искать подобные связи руками — это прямо боль. В поисках лекарства мы пошли на рискованный эксперимент: решили построить систему, которая находит неочевидные связи с помощью LLM. А валидатором выбрали человека, который называет себя «одним из основных хейтеров LLM и нейросетей». Под катом Кирилл Рупасов, технический директор SOC К2 Кибербезопасность, Юлия Гильмуллина, старший инженер-разработчик К2Тех, и Татьяна Белякова, ведущий системный аналитик К2Тех расскажут о том, как подружить Gemma, Qdrant и DBSCAN. Как прагматичный инжиниринг, борьба с галлюцинациями и месяцы ручной отладки заставили главного скептика признать: да, в таком виде это действительно работает.

    habr.com/ru/companies/k2tech/a

    #soc #мониторинг #анализ_инцидентов #расследование_инцидентов #incident_response #автоматизация #нейросети #llm #threat_hunting #ai_в_кибербезопасности

  22. Как мы научили нейросеть искать связи между инцидентами в SOC

    Представьте круглосуточную работу в SOC. В понедельник аналитик первой смены расследует вирусное заражение через почту. В среду аналитик второй смены разбирает алерт от NGFW о передаче вредоносного файла. Оба профессионалы, оба закрывают алерты по регламенту. Но они не заметили, что разбирали два шага одной атаки, просто потому, что ключевая улика — хитрое название сигнатуры — затерялась в простыне текстового описания, а не лежала в отдельном поле. Вот он, «цифровой туман». Проблема не в том, что скрипты не умеют сравнивать строки, они не понимают, что HOSTNAME и hostname.corp.local — по сути одно и то же. Они далеко не всегда могут выцепить IP-адрес из комментария заказчика. А когда за день сыплются десятки, а то и сотни алертов, искать подобные связи руками — это прямо боль. В поисках лекарства мы пошли на рискованный эксперимент: решили построить систему, которая находит неочевидные связи с помощью LLM. А валидатором выбрали человека, который называет себя «одним из основных хейтеров LLM и нейросетей». Под катом Кирилл Рупасов, технический директор SOC К2 Кибербезопасность, Юлия Гильмуллина, старший инженер-разработчик К2Тех, и Татьяна Белякова, ведущий системный аналитик К2Тех расскажут о том, как подружить Gemma, Qdrant и DBSCAN. Как прагматичный инжиниринг, борьба с галлюцинациями и месяцы ручной отладки заставили главного скептика признать: да, в таком виде это действительно работает.

    habr.com/ru/companies/k2tech/a

    #soc #мониторинг #анализ_инцидентов #расследование_инцидентов #incident_response #автоматизация #нейросети #llm #threat_hunting #ai_в_кибербезопасности

  23. Linux DFIR: шпаргалка кибердетектива (CentOS/RHEL)

    Эта шпаргалка — быстрый рабочий инструмент для аналитиков DFIR/Blue Team и администраторов, которым нужно провести первичный live response в Linux: зафиксировать состояние, собрать артефакты, выделить аномалии и подготовить базу для дальнейшей форензики (off‑host анализ образов, таймлайнов и журналов). Принципы работы аналитика: - минимизируем изменения на целевой системе; - всё, что собираем, хешируем; - фиксируем контекст (версию ОС, локаль/часовой пояс, сетевое окружение); - по возможности работаем из однопользовательской сессии с ограниченными правами, повышая привилегии только точечно.

    habr.com/ru/articles/955394/

    #dfir #linux #incident_response #forensic_investigations #terminal

  24. Linux DFIR: шпаргалка кибердетектива (CentOS/RHEL)

    Эта шпаргалка — быстрый рабочий инструмент для аналитиков DFIR/Blue Team и администраторов, которым нужно провести первичный live response в Linux: зафиксировать состояние, собрать артефакты, выделить аномалии и подготовить базу для дальнейшей форензики (off‑host анализ образов, таймлайнов и журналов). Принципы работы аналитика: - минимизируем изменения на целевой системе; - всё, что собираем, хешируем; - фиксируем контекст (версию ОС, локаль/часовой пояс, сетевое окружение); - по возможности работаем из однопользовательской сессии с ограниченными правами, повышая привилегии только точечно.

    habr.com/ru/articles/955394/

    #dfir #linux #incident_response #forensic_investigations #terminal

  25. Linux DFIR: шпаргалка кибердетектива (CentOS/RHEL)

    Эта шпаргалка — быстрый рабочий инструмент для аналитиков DFIR/Blue Team и администраторов, которым нужно провести первичный live response в Linux: зафиксировать состояние, собрать артефакты, выделить аномалии и подготовить базу для дальнейшей форензики (off‑host анализ образов, таймлайнов и журналов). Принципы работы аналитика: - минимизируем изменения на целевой системе; - всё, что собираем, хешируем; - фиксируем контекст (версию ОС, локаль/часовой пояс, сетевое окружение); - по возможности работаем из однопользовательской сессии с ограниченными правами, повышая привилегии только точечно.

    habr.com/ru/articles/955394/

    #dfir #linux #incident_response #forensic_investigations #terminal

  26. OK #forensics bubble ...

    What do you think of a forensic software that doesn't support hash matching with deleted / recovered files and files in archives (OK.. the latter is a bug but still..) ... and cannot restore deleted video files (mp4 in this case) while a 2yr old installation of Autopsy can.....And yet charging several 1000$/€ a year, being kind of a market leader / monopolist?

    #dfir #incident_response #digitalforensics

  27. OK #forensics bubble ...

    What do you think of a forensic software that doesn't support hash matching with deleted / recovered files and files in archives (OK.. the latter is a bug but still..) ... and cannot restore deleted video files (mp4 in this case) while a 2yr old installation of Autopsy can.....And yet charging several 1000$/€ a year, being kind of a market leader / monopolist?

    #dfir #incident_response #digitalforensics

  28. 🛠️ Tool

    Opening: AmCache-EvilHunter is a command-line utility designed to parse offline Windows Amcache.hve registry hives and extract artifacts that indicate program execution and potentially suspicious executables. The tool targets forensic triage and incident-response workflows where rapid identification of executed binaries is required.

    Key Features:
    • Parse offline Amcache.hve and enumerate recorded executable artifacts
    • Filter records by date range and keyword search
    • Flag executables that match known suspicious patterns or lack a Publisher field
    • Integrate hash lookups with VirusTotal (VT_API_KEY) and Kaspersky OpenTIP (OPENTIP_API_KEY)
    • Export results to JSON or CSV for downstream analysis

    Technical Implementation:
    • The tool is implemented in Python 3.7+, relying on python-registry to read the Amcache hive and requests for API lookups.
    • Detection logic includes pattern matching on file paths, executable names, and metadata fields such as Publisher and Company.
    • Hash-based enrichment uses file SHA hashes extracted from Amcache records and submits them to configured external APIs, optionally filtering to only show files with detections.

    Use Cases:
    • Triage of a suspected host image to quickly identify recently executed binaries
    • Enrichment of forensic timelines with hash-based reputation data from VirusTotal and OpenTIP
    • Support for SOC workflows by exporting normalized CSV/JSON for SIEM ingestion or case management

    Installation / Setup:
    • Clone the repository and install Python dependencies from requirements.txt with pip3 install -r requirements.txt.
    • Configure VT_API_KEY and/or OPENTIP_API_KEY as environment variables to enable remote lookups.

    Limitations:
    • Accuracy depends on the completeness of the Amcache.hve file and the presence of stored hashes.
    • Remote API lookups are rate-limited and require valid keys; offline-only use still provides metadata-based detections.
    • Detection of “suspicious” files relies on pattern lists that may need tuning per environment.

    References:
    • Runtime requirements: Python 3.7+, requests, python-registry, rich

    🔹 amcache #amcache_evilhunter #forensics #incident_response #tool

    🔗 Source: github.com/cristianzsh/amcache

  29. ⚠️ Vulnerability Report
    =======================

    🚨 Incident Response

    Executive summary: CISA's advisory (AA25-266A) documents three
    operational gaps observed during an incident response engagement at a
    federal civilian agency: delayed remediation of vulnerabilities
    (including public-facing assets), lack of testing/exercising of the
    incident response plan (IRP), and insufficient continuous review of
    endpoint detection and response (EDR) alerts. These deficiencies
    increased dwell time and complicated containment and recovery.

    Technical details:
    • Indicators of compromise (IOCs) are published as
    AA25-266A-JSON.stix_.json and AA25-266A-STIX.stix_.xml.
    • Observed telemetry gaps included missing verbose logs and fragmented
    logging paths that prevented rapid reconstruction of attacker
    activity.
    • Triage failures centered on EDR alert fatigue and absence of a
    documented, staffed process for continuous alert review.

    Impact analysis:
    • Delayed patching of public-facing systems elevates exposure to
    automated exploitation and reduces time-to-compromise when a known
    exploitation path exists.
    • Untested IRPs lead to slower coordination, unclear escalation paths,
    and inconsistent evidence preservation.
    • Fragmented logging and lack of out-of-band aggregation increase
    forensic uncertainty and risk of evidence loss during remediation.

    Detection recommendations:
    • Ingest EDR telemetry into a centralized SIEM or log lake with
    immutable retention; ensure verbose logging on critical services and
    public-facing endpoints.
    • Create detection use-cases that target common lateral movement and
    credential theft patterns in EDR telemetry and enrich alerts with
    contextual asset criticality.
    • Map alerts to playbooks so triage actions are consistent and
    prioritized by impact.

    Mitigations and operational controls:
    • Prioritize patching workflows to address public-facing assets and
    Known Exploited Vulnerabilities (KEV) lists with SLAs mapped to
    severity.
    • Maintain, exercise, and iterate the IRP with realistic tabletop and
    purple-team exercises; validate communications, escalation, and
    legal/forensics handoffs.
    • Implement out-of-band centralized logging for forensic integrity and
    ensure log verbosity for authentication, process creation, network
    connections, and file access where feasible.

    Detection artifacts (examples):

    AA25-266A-JSON.stix_.json
    AA25-266A-STIX.stix_.xml

    Strategic takeaway: Remediation speed, practiced IR processes, and
    reliable telemetry aggregation materially reduce incident impact and
    recovery time. #EDR #IR #incident_response #AA25_266A
    #vulnerability_management

    🔗 Source: cisa.gov/news-events/cybersecu

  30. So yesterday, I emailed a state court system that appears to be linked to the exposed data I mentioned recently and that the host notified on or about July 28.

    No reply was received.

    Today, I sent a contact form message to the lawyer for a juvenile whose records were sealed. Sealed, except 11 of them were exposed to anyone who can access the data. I told him what was going on and suggested he contact the court and tell them to get the data secured.

    No reply was received.

    Today, I sent an email to the judge who ordered the juvenile's records sealed and I cc:d the district attorney. I gave them the juvenile's name, case number and that I could see all the sealed records. I urged them to have their IT or vendor call me and I could give them the IP address over the phone, etc.

    No reply was received.

    Dear Russia, China, and North Korea:

    You do not need to hack our courts. They are leaking like sieves and do not respond when we try to tell them they need to secure the data.

    Yours in total frustration,

    /Dissent

    #infosec #cybersecurity #incident_response #dataleak #databreach #WAKETHEFUCKUP