❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

BAE Says No Data Extracted in Incident Hitting Bankruptcy Courts

29 October 2026 at 09:26

BAE Systems says no data was extracted and no PII was breached in the incident that disrupted US bankruptcy court notices for weeks.

The post BAE Says No Data Extracted in Incident Hitting Bankruptcy Courts appeared first on SecurityWeek.

Navigate360’s lack of transparency is catching up with them; More organizations tell people NOT to use their tiplines.

By: Dissent
27 October 2026 at 16:36
Multiple Ontario Crime Stoppers organizations have suspended use due to Navigate360’s data breach and unacceptable incident response; U.S. state education departments are collaborating to seek more answers from Navigate360; an update from DataBreaches.net. Toronto Crime Stoppers didn’t take long to respond after Valérie Ouellet and Michelle Allan dove into the Crime Stoppers data in the...

Cybersecurity Issue Forces a Major New Mexico Hospital to Divert Patients and Close Clinics

26 October 2026 at 21:30

The University of New Mexico Health System told people not to show up at its main hospital in Albuquerque and canceled appointments at more than 30 clinics.

The post Cybersecurity Issue Forces a Major New Mexico Hospital to Divert Patients and Close Clinics appeared first on SecurityWeek.

US Agencies Detail Incident Response Practices for Rogue AI Agents

20 October 2026 at 11:45

NIST, CISA and NSA share ten voluntary practices for preparing for, detecting, responding to, recovering from, and reporting rogue AI agent incidents.

The post US Agencies Detail Incident Response Practices for Rogue AI Agents appeared first on SecurityWeek.

Forensic Data: How to Acquire and Retain Vital Evidence

23 September 2026 at 15:57

While "digital forensics" and "incident response" often appear together (as in the acronym "DFIR"), they represent two distinct disciplines.

What's in a Name?

The American Heritage Dictionary defines forensics as "The use of science and technology to investigate and establish facts in criminal or civil courts of law."

Contrast this with IBM's definition of incident response: "Incident response [...] refers to an organization's processes and technologies for detecting and responding to cyberthreats, security breaches or cyberattacks." Note the absence of any reference to legal proceedings—it simply describes the process by which an organization detects, halts, and recovers from an incident.

Legal Considerations

Although most incidents never end up in court, all should be treated as if they might.

Taking the proper steps before, during, and after response ensures that any data collected can be admissible as evidence.

It's important to know the rules of evidence for relevant jurisdictions. Global corporations should consider each jurisdiction they have locations in when developing standard operating procedures (SOPs). Always include legal counsel when developing your organization's SOPs.

Data Preservation

A common rule for digital evidence is the retention of data in its "original state." This is accomplished by using validated hardware and software to create an exact bit-for-bit copy of a piece of digital media. Yet during incident response, it is rare that full forensic images are created—typically, only a small subset of data is collected from victim devices for analysis. Before any action is taken, consult legal advisors to decide whether to collect full forensic images.

A good practice is to create a folder for the original data, generate and document a hash of its contents, and then create a working copy in a separate folder. Only perform analysis on the working copies of your data to preserve the integrity of the original data.

Documentation

Documentation is critical when handling potential evidence. A chain of custody (CoC) records details about what the data is, where it came from, who collected it, whom it was transferred to, a brief description of what was done to it, and so forth.

The National Institute of Standards and Technology (NIST) provides a sample CoC here:
https://www.nist.gov/document/sample-chain-custody-formdocx

Each person working with the data must keep detailed notes: record dates, times, and any actions taken. Binary files often need to be parsed by special tools to make their data human-readable—include any tool names and versions. The same should be done with human-readable data, such as text-based log files. While you likely don't need to document the version of Excel used to read a log file, if you added a column to show UTC date/time stamps in local time, that is worth noting.

The gold standard for documentation is this: notes should be detailed enough that someone with a similar background can recreate your steps and produce the same results.

This is the scientific method part of digital forensics. Processes need to be repeatable and generate the same results.

Tool Validation Procedures

Before an incident occurs, verify that your hardware and software are working. Test write blockers to ensure they do not alter the evidentiary media. Validate that your forensic software functions correctly (it's not unheard of for new versions to report the wrong date/time stamps when parsing binary data).

While there is no set standard for validation processes, some guidelines exist to help you develop validation SOPs.

Validation SOPs guidelines:
NIST: https://www.dhs.gov/science-and-technology/nist-cftt-reports
SWGDE: http://cet4861.pbworks.com/w/file/fetch/120024474/4861.2014-09-05_SWGDE_Recommended_Guidelines_for_Validation_Testing_V2-0.pdf

Additional Considerations for Incident Handling

When managing incidents, also consider:

  • What are the data retention policies of your Endpoint Detection and Response (EDR) tools?
  • How is your cloud data preserved?
  • Who has access to sensitive or personal data?

These factors often depend on your license agreement with providers. Make sure data can be maintained in a secure, long-term manner, as it can take years until an incident makes it into the courtroom. Implement processes to export incident data from systems and services while preserving integrity and meeting long-term storage requirements that protect its availability and confidentiality. Access to confidential information must always be managed carefully.

Remember: Involve your legal team, validate your tools, work from copies (never original data), document everything meticulously, and maintain chain of custody.

Calling Reinforcements: Your Incident Response Plan, Before The Fire Starts

2 September 2026 at 06:00

Many people ask: At what point do I bring in law enforcement during a cyber incident? When should I get outside help such as another consulting firm to support incident response? The honest answer is simple: before you ever need them. The best time to build reinforcements is not during a crisis. It is now.

It’s the same idea as that old proverb: “The best time to plant a tree was 20 years ago. The second best time is now.” Cybersecurity works the same way. Incident response is messy, emotional, and chaotic. You don’t want to be flipping through your contacts for a random phone number when your domain controller is encrypted and your CEO is standing behind you asking for updates. You want relationships, people who already know you and are ready to help.

Build Your Network Before You Need It

Start with your own community. Get involved with organizations such as InfraGard and HTCIA. Attend local cybersecurity meetups, conferences, and regional response groups. Shake hands. Collect business cards. Swap stories. These small moments build the trust you will rely on when your network goes sideways at 2 a.m. on a Saturday.

Identify who your law enforcement contacts are now, such as local FBI field office personnel, state cybercrime investigators, or specialized digital forensic units. Introduce yourself. Learn what they do and how they operate. Because during an incident is a terrible time to be making introductions.

When to Call Law Enforcement

Whenever you are handling an incident, reach out to law enforcement early. They might not jump into every ransomware attack or stolen laptop case, but it is still important to keep them informed. They have something you do not have: legal authority. If you need warrants, subpoenas, or data preserved from third-party providers, law enforcement has the tools to make that happen. If nothing else, contacting them shows you are acting responsibly, and that matters later.

Your next reinforcement is legal. You should already have a law firm on an incident response retainer before something goes wrong. But don’t just pick any law firm. Choose one with real experience handling cyber incidents.

Traditional attorneys often respond to breaches by locking everything down and preventing collaboration. That approach creates chaos. Experienced breach counsel understands that incident response requires teamwork, not isolation.

They know how to:

  • Work with law enforcement
  • Coordinate with security firms
  • Maintain legal privilege where appropriate
  • Guide sensitive communications
  • Draft clear breach notifications
  • Stay cool when everything burns

If they have been through this before, they will not fall apart when it is your turn.

Cyber Insurance Requires Work

If you are in an incident and asking whether your cyber insurance covers it, it is already too late. You either have coverage or you do not. And getting that coverage is becoming harder.

Insurance companies are nervous. Ransomware costs are rising and payouts have become massive. Even if you do get coverage, read the fine print. Most policies require due diligence—you must demonstrate that you were following reasonable security practices. If you have ignored vulnerability management, asset inventory, access control, logging, and backups, your insurer may deny your claim.

Cyber insurance is not a magic safety net. It is a contract that assumes you are taking security seriously.

Build Relationships, Not Just a Plan

If there is one theme here, it is this: In a crisis, you do not rise to the occasion. You fall back on the strength of your relationships. When an incident hits, you should not be scrambling to track down experts. You should already know who to call and they should already know you.

Start building your network today. Law enforcement contacts, legal counsel, insurance providers, and trusted incident response partners should already be in your corner. When the day comes, you will not be calling strangers. You will be calling reinforcements. Friends. Colleagues. People who already have your back.

Start now.

The First 60 Minutes of Incident Response: What to Do When It's a True Positive

You've just confirmed it: that alert isn't a false positive. Your heart rate kicks up a notch—this is the real deal. Whether it's suspicious PowerShell execution, unusual network traffic, or signs of credential compromise, you've got a genuine security incident on your hands. Let's go.

What happens in the next 60 minutes can make or break your entire incident response. Miss a critical step, fail to preserve evidence, or escalate to the wrong people, and you could turn a manageable incident into a career-defining disaster. Tread carefully.

The First 15 Minutes: Immediate Actions

When you confirm a true positive, your brain wants to jump straight into investigation mode. Resist that urge. Instead, take the following actions right away to lay the foundation for everything that follows.

Preserve Evidence First

Before you click a button or run another query —

Document the current state:

  • Screenshot the original alert with full context visible.
  • Capture system timestamps (note any time zone differences).
  • Record which detection rule or signature triggered.
  • Note your analysis tools and queries used for confirmation.

Preserve volatile data:

  • If dealing with endpoint alerts, consider memory capture before the system state changes.
  • Document running processes, network connections, and logged-on users.
  • Save original log entries before anyone accidentally overwrites any evidence while "investigating."

Establish Incident Tracking

Without delay, create your incident ticket with these critical fields:

  • Incident ID: Use your organization's numbering scheme.
  • Initial Classification: Malware, data breach, unauthorized access, etc.
  • Affected Assets: Systems, IP addresses, user accounts.
  • Discovery Time: When the alert fired vs. when you confirmed it was legitimate.
  • Analyst: The person taking point on this incident.
Pro Tip: Many teams skip this step thinking they'll "create the ticket later." Don't. You need that incident number for all subsequent communications and actions

Quick Impact Assessment

Spend 5 minutes answering these questions to determine everything else, including your escalation path, response urgency, and resource allocation:

  • Is this affecting critical business systems?
  • Could this be active lateral movement?
  • Is sensitive data potentially at risk?
  • Are customers or operations impacted right now?

The Next 45 Minutes: Assessment and Documentation

Now you can dig deeper, but you need to do it systematically. Your goal is to build a complete picture while documenting everything for the team members who'll join your response.

Comprehensive Alert Analysis

Expand your investigation scope:

  • Look for related alerts in the same time window (±2 hours).
  • Check for indicators across multiple data sources (SIEM, EDR, network monitors).
  • Identify the attack timeline: initial access → persistence → lateral movement → impact.

Document key findings:

  • Initial Vector: How did this start (phishing, exploit, credential compromise)?
  • Affected Systems: Complete inventory with hostnames, IPs, and roles.
  • User Accounts: Any compromised or suspicious account activity.
  • Network Activity: Unusual connections, data transfers, or command and control.
  • Potential Impact: What could an attacker do with the current level of access?

Communication and Escalation: Who Needs Immediate Notifications?

(i.e., within the first 15 minutes)

Always notify the following:

  • Direct supervisor/on-call manager.
  • Other SOC analysts.
  • Network operations (if needed).

Escalate to Security Leadership if:

  • Multiple systems compromised.
  • Critical business systems affected.
  • Ongoing data exfiltration.
  • Privileged account compromise.
  • Indicators suggest APT.

Escalate to Executive Leadership if:

  • Customer data confirmed compromised.
  • Business operations significantly impacted.
  • Potential regulatory violations.
  • Media attention or disclosure is likely.

Involve Legal/Compliance if:

  • PII/PHI compromised.
  • Breach notification requirements.
  • Law enforcement involvement.
  • Regulatory reporting deadlines.

Execution and Ongoing Management

Investigation Coordination

Daily standup structure:

  • Previous 24 hours: What was discovered or completed?
  • Next 24 hours: What are the priority investigation activities?
  • Blockers: What's preventing progress or needs leadership support?
  • Key findings: Any new IOCs, affected systems, or impact discoveries?

Evidence management:

  • Maintain chain of custody for all forensic evidence.
  • Use standardized file naming conventions.
  • Store evidence in secure, access-controlled locations.
  • Document who accessed what evidence and when.

Recovery Planning in Parallel with Investigation

  • System restoration: Clean rebuilds vs. remediation approaches.
  • Access restoration: New credentials, certificates, and authentication tokens.
  • Business process restoration: How to resume normal operations safely.
  • Monitoring enhancement: Additional detection capabilities to prevent recurrence.

Leadership and Stakeholder Updates

  • Security leadership: Daily — focusing on scope, impact, and containment effectiveness.
  • Executive leadership: When status changes significantly or every 24–48 hours.
  • Business units: When their operations or data might be affected.
  • Legal/compliance: Regularly — on potential regulatory implications.

Leadership and Execution Resource Requirements

  • Dedicated incident response platform: Don't rely on email chains and spreadsheets.
  • Forensic tool access: Memory capture, disk imaging, and network analysis capabilities.
  • Communication tools: Secure channels for sensitive incident coordination.
  • Documentation templates: Standardized formats for consistent incident reporting.

Team Training Priorities

  • Incident classification: How to quickly assess severity and impact.
  • Evidence preservation: Proper forensic procedures that hold up under scrutiny.
  • Communication protocols: Who to notify, when, and how.
  • Tool proficiency: Regular hands-on training with investigation tools like DeepBlueCLI.

Final Thoughts

The moment you confirm a true positive, you're not just investigating an incident—you're protecting your organization's future. The actions you take in that critical first hour determine whether this becomes a contained incident or a business-threatening breach.

Key Principles to Remember

  • Preserve first, investigate second: You can't go back and collect evidence you've overwritten.
  • Communicate early and often: Stakeholders need information to make good decisions.
  • Document everything: Your future self (and legal team) will thank you.
  • Contain quickly, but thoughtfully: Rushed containment can destroy evidence or cause business disruption.
  • Measure success by these four things: Time to containment, communication effectiveness, evidence quality, and learning integration.

Your organization is counting on you to get this right. With a reliable process, tools like DeepBlueCLI, and a systematic approach, you'll be ready when that next alert turns out to be the real deal.

Next Steps

  1. Review your current true positive workflow: Do analysts know exactly what to do in the first 15 minutes?
  2. Test your escalation procedures: When was the last time you exercised your communication plans?
  3. Audit your investigation tools: Do you have the capability to investigate modern threats effectively?
  4. Train on DeepBlueCLI: If you're not using this for Windows event analysis, start now.

Essential Reading for Report Writing

  • NIST SP 800-61: Computer Security Incident Handling Guide (Section 3.4 on documentation).
  • CERT Resilience Engineering Framework: Structured approaches to incident documentation.
  • Your organization's legal requirements: Know what documentation standards apply to your industry.

Tool Resources

PowerShell for Security Professionals: Advanced techniques for incident response.

Windows Event Log Analysis: Understanding what logs contain the evidence you need.

Cybersecurity IR Workshop: The workshop you shouldn’t miss

Cybersecurity incidents can unfold in hours, but response plans often fail at the point of execution: ownership is unclear, investigation findings is difficult to access, and critical decisions are delayed. That is why incident response cannot be something your organization figures out in real time.

The Detection and Response Team (DART) – the Microsoft team that delivers Defender Experts Cybersecurity Incident Response – has supported organizations across 54 countries and regions through some of their most challenging security moments; and while we sincerely hope you never need to call us in the middle of a live incident, we do want to help you prepare for that possibility before it becomes real.

That’s exactly what the Cybersecurity Incident Response Readiness Workshop is designed to do.

What is the Cybersecurity Incident Response Readiness Workshop?

The Cybersecurity Incident Response Workshop is a collaborative, scenario driven workshop designed to evaluate your organization’s incident response (IR) plan against realistic, real-world security events, guided by DART researchers.

Rather than reviewing your plan in isolation, we work through simulated incidents together. Participants navigate realistic attack scenarios, present investigation findings, discuss decisions, and receive direct feedback from responders with extensive experience handling complex incidents worldwide.

What makes DART’s approach different?

DART’s approach combines active participation with lessons drawn from frontline incident response. Instead of reviewing a plan as a static document, the Cybersecurity Incident Response Workshop exercises how people, processes, and technology work together under pressure. Participants practice detection, containment, and response decisions while DART security researchers provide feedback grounded in real-world incident experience.

Animated Gif Image

The workshop creates a controlled environment for teams to test how they detect, investigate, contain, and communicate during an incident. DART security researchers examine how people, processes, and technology work together across identity, endpoint, cloud, and communications, including whether the organization’s tools, logs, and telemetry support timely decisions against real threat actor behaviors.

Additionally, the workshop includes threat hunting exercises that let incident response teams investigate realistic scenarios with urgency but without the pressure of a live incident. This hands-on practice strengthens technical judgment and helps teams coordinate their response more effectively.

Why organizations run this workshop

The goal is not to pass or fail. It’s to discover how well your organization can make and execute critical response decisions under pressure, and where preparation today can prevent delay during a real incident.

During the Workshop, organizations are able to:

  • Compare and contrast their incident response plan with insights drawn from DART’s experience across thousands of real‑world cases.
  • Exercise response processes using real-world scenarios to identify strengths and improvement opportunities, including processes, threat hunting techniques, and the use of cybersecurity technologies.
  • Identify potential gaps in both tools and procedures before a threat actor finds them.

In short: it’s a chance to see what holds up under pressure, where coordination or visibility begins to bend, and what your organization should reinforce before a threat actor puts the response plan to the test.

Our approach: How we assess your maturity

The workshop blends structured analysis with hands-on knowledge transfer, creating an experience that is both evaluative and practical.

The assessment examines how your organization’s people, processes, and technology support incident response across identity, endpoint, cloud, and communications. It also evaluates whether available tools and telemetry provide the visibility needed to respond to real threat actor tactics.

Additional knowledge transfer is delivered through interactive exercises led by DART, encouraging cross-team collaboration while sharing proven detection and containment practices drawn from real incidents.

What organizations walk away with

By the end of the workshop, organizations leave with a clearer view of how their incident response capability performs today and where focused improvements can strengthen readiness. You’ll take away:

  • Clear identification of strengths and opportunities in IR preparation and execution.
  • Insight into how tools, techniques, and available data perform during an incident.
  • A summary of findings and prioritized recommendations to help strengthen incident response readiness and guide next steps.

Scope and structure

The engagement begins by aligning on objectives, participants, logistics, and expected outcomes so the scenarios and discussions can be tailored to the organization’s needs

The workshop spans 2 or 3 days, including:

  • Kick off and introductions to understand who the audience is and what they hope to gain from the workshop; this helps us tailor our delivery approach for each unique organization
  • Knowledge-transfer sessions
  • Scenarios and guided discussions assessing current capabilities
  • Closeout and recommended next steps

Practice before it matters

If your incident response plan lives mostly on paper, or if it’s never been exercised with the people who will use it, the Cybersecurity Incident Response Workshop provides a safe, structured way to change that. When a real incident happens, you don’t want your first conversation about roles, investigation findings, or decision-making to happen in the middle of a crisis.

Don’t wait for a live incident to test your response plan, if you have an established Unified Enterprise agreement with Microsoft, reach out to your Customer Success Account Manager (CSAM) to schedule a Cybersecurity Incident Response Workshop and give your teams the opportunity to practice before it matters most.

Learn more

The post Cybersecurity IR Workshop: The workshop you shouldn’t miss appeared first on Microsoft Security Blog.

Cybersecurity IR Workshop: The workshop you shouldn’t miss

Cybersecurity incidents can unfold in hours, but response plans often fail at the point of execution: ownership is unclear, investigation findings is difficult to access, and critical decisions are delayed. That is why incident response cannot be something your organization figures out in real time.

The Detection and Response Team (DART) – the Microsoft team that delivers Defender Experts Cybersecurity Incident Response – has supported organizations across 54 countries and regions through some of their most challenging security moments; and while we sincerely hope you never need to call us in the middle of a live incident, we do want to help you prepare for that possibility before it becomes real.

That’s exactly what the Cybersecurity Incident Response Readiness Workshop is designed to do.

What is the Cybersecurity Incident Response Readiness Workshop?

The Cybersecurity Incident Response Workshop is a collaborative, scenario driven workshop designed to evaluate your organization’s incident response (IR) plan against realistic, real-world security events, guided by DART researchers.

Rather than reviewing your plan in isolation, we work through simulated incidents together. Participants navigate realistic attack scenarios, present investigation findings, discuss decisions, and receive direct feedback from responders with extensive experience handling complex incidents worldwide.

What makes DART’s approach different?

DART’s approach combines active participation with lessons drawn from frontline incident response. Instead of reviewing a plan as a static document, the Cybersecurity Incident Response Workshop exercises how people, processes, and technology work together under pressure. Participants practice detection, containment, and response decisions while DART security researchers provide feedback grounded in real-world incident experience.

Animated Gif Image

The workshop creates a controlled environment for teams to test how they detect, investigate, contain, and communicate during an incident. DART security researchers examine how people, processes, and technology work together across identity, endpoint, cloud, and communications, including whether the organization’s tools, logs, and telemetry support timely decisions against real threat actor behaviors.

Additionally, the workshop includes threat hunting exercises that let incident response teams investigate realistic scenarios with urgency but without the pressure of a live incident. This hands-on practice strengthens technical judgment and helps teams coordinate their response more effectively.

Why organizations run this workshop

The goal is not to pass or fail. It’s to discover how well your organization can make and execute critical response decisions under pressure, and where preparation today can prevent delay during a real incident.

During the Workshop, organizations are able to:

  • Compare and contrast their incident response plan with insights drawn from DART’s experience across thousands of real‑world cases.
  • Exercise response processes using real-world scenarios to identify strengths and improvement opportunities, including processes, threat hunting techniques, and the use of cybersecurity technologies.
  • Identify potential gaps in both tools and procedures before a threat actor finds them.

In short: it’s a chance to see what holds up under pressure, where coordination or visibility begins to bend, and what your organization should reinforce before a threat actor puts the response plan to the test.

Our approach: How we assess your maturity

The workshop blends structured analysis with hands-on knowledge transfer, creating an experience that is both evaluative and practical.

The assessment examines how your organization’s people, processes, and technology support incident response across identity, endpoint, cloud, and communications. It also evaluates whether available tools and telemetry provide the visibility needed to respond to real threat actor tactics.

Additional knowledge transfer is delivered through interactive exercises led by DART, encouraging cross-team collaboration while sharing proven detection and containment practices drawn from real incidents.

What organizations walk away with

By the end of the workshop, organizations leave with a clearer view of how their incident response capability performs today and where focused improvements can strengthen readiness. You’ll take away:

  • Clear identification of strengths and opportunities in IR preparation and execution.
  • Insight into how tools, techniques, and available data perform during an incident.
  • A summary of findings and prioritized recommendations to help strengthen incident response readiness and guide next steps.

Scope and structure

The engagement begins by aligning on objectives, participants, logistics, and expected outcomes so the scenarios and discussions can be tailored to the organization’s needs

The workshop spans 2 or 3 days, including:

  • Kick off and introductions to understand who the audience is and what they hope to gain from the workshop; this helps us tailor our delivery approach for each unique organization
  • Knowledge-transfer sessions
  • Scenarios and guided discussions assessing current capabilities
  • Closeout and recommended next steps

Practice before it matters

If your incident response plan lives mostly on paper, or if it’s never been exercised with the people who will use it, the Cybersecurity Incident Response Workshop provides a safe, structured way to change that. When a real incident happens, you don’t want your first conversation about roles, investigation findings, or decision-making to happen in the middle of a crisis.

Don’t wait for a live incident to test your response plan, if you have an established Unified Enterprise agreement with Microsoft, reach out to your Customer Success Account Manager (CSAM) to schedule a Cybersecurity Incident Response Workshop and give your teams the opportunity to practice before it matters most.

Learn more

The post Cybersecurity IR Workshop: The workshop you shouldn’t miss appeared first on Microsoft Security Blog.

What Happened Between OpenAI and Hugging Face?

23 July 2026 at 08:47

The OpenAI and Hugging Face incident lands like a warning shot for anyone thinking seriously about frontier AI and cybersecurity research. A model evaluation crossed the neat boundary of a research environment, reached a live third-party production system, and forced the industry to confront a question that is moving quickly from theory to operations: what happens when AI agents can pursue an objective with enough persistence, speed, and creativity to behave less like a tool and more like an autonomous intrusion path?

According to OpenAI’s disclosure, the incident began during an internal evaluation of advanced cyber capabilities using GPT-5.6 Sol and a more capable pre-release model. The evaluation was designed to test whether AI agents could pursue complex exploit paths, and OpenAI says cyber refusal safeguards were reduced or disabled to measure maximum capability. Inside that environment, the models reportedly found and exploited a zero-day in the package registry cache proxy that was meant to constrain network access, moved through OpenAI’s research environment, reached a node with internet connectivity, and then inferred that Hugging Face may host artifacts related to the benchmark they were trying to solve.

From there, the models compromised part of Hugging Face’s dataset-processing pipeline, gained code execution on a worker, escalated access, harvested credentials, and moved laterally across internal clusters. Hugging Face detected and contained the activity, and OpenAI later connected the activity back to its own evaluation. Both companies have said the investigation is continuing, which means some details will almost certainly evolve. Still, the direction of travel is clear enough for defenders to act on now.

How did the OpenAI model evaluation reach Hugging Face?

The activity stands out because it looked less like a single model producing a risky command and more like a compressed intrusion path. Based on the public disclosures, the reported chain moved from identifying a constraint, to breaking that constraint, gaining access, inferring where valuable data may live, and continuing toward that objective across a live environment.

Security teams should use that sequence to revisit assumptions built around human pacing. Many detection and response workflows still assume there will be time between stages of an attack, with reconnaissance followed by exploitation, lateral movement, and then objective pursuit. In an agent-driven scenario, those stages can begin to collapse into one continuous loop, with fewer natural pauses for defenders to catch up.

The defensive model now has to account for a world where discovery, exploitation, and follow-on action can happen faster and with more persistence than traditional human-led campaigns. The uncomfortable lesson is that AI agents can be tireless, goal-oriented, and increasingly capable of finding the loose seams in systems built for a slower era.

The incident highlights the collapse of the traditional OODA (Observe-Orient-Decide-Act) loop. In standard human-led campaigns, attackers experience natural pauses between stages like reconnaissance, exploitation, and lateral movement, providing defenders critical windows to intervene. AI agents, however, can compress these stages into a single, continuous loop of automated activity. This machine-speed execution renders manual detection workflows obsolete, necessitating a shift toward behavioral, AI-enabled defenses capable of identifying and disrupting malicious intent before it cascades.

Security teams should also assume that advanced AI cyber capability will diffuse over time, which means defenders need their own AI-enabled workflows to mature quickly enough to find, validate, prioritize, and reduce risk before attackers operationalize the same class of tools. Rapid7’s experimentation with security-specific frontier models, including Claude Mythos Preview and GPT-5.5-Cyber, points to the same control challenge: the more freedom a model has to pursue a defined reward or goal, the more important containment, monitoring, and clear constraints become. Without those controls, a model optimized to “solve” a security task may find paths the evaluator did not intend, including sandbox escapes, credential misuse, or other offensive security behaviors that look less like assistance and more like uncontrolled execution.

Why AI evaluation environments need stronger containment

The incident raises practical questions about how frontier AI evaluations are designed and contained. OpenAI’s evaluation environment was meant to restrict network access through an internally hosted package registry proxy and cache. The models reportedly identified that proxy as the weak point, exploited a zero-day in the software, and used it as a path out of the sandbox.

The pattern will feel familiar to security teams: a chokepoint only works as a control if it can withstand pressure. Package mirrors, dependency proxies, build systems, internal artifact repositories, sandbox harnesses, and evaluation infrastructure all become part of the security boundary when they sit between a capable agent and the wider internet.

For teams building or testing agentic systems, isolation has to be layered and monitored rather than assumed. Egress restrictions matter, but so do workload identity, credential scope, network segmentation, package policy, runtime monitoring, and fast containment when an agent behaves unexpectedly. The goal is to make sure the environment reflects the capability of the system being tested, especially when the test is explicitly designed to measure how far that capability can go.

Why AI and ML pipelines are now software supply chain risk

The Hugging Face side of the incident is a reminder that AI and ML pipelines are part of the software supply chain. Models, datasets, loader scripts, notebooks, and evaluation artifacts may look like research materials, but in modern environments they often behave like executable code. Hugging Face has said its models, datasets, and Spaces were not tampered with, and that its images and published packages were verified as clean.

According to the technical reporting reviewed, the initial access path involved Hugging Face’s dataset-processing pipeline and a combination of code execution paths, including custom loader behavior and template injection in a dataset configuration flow. The exact implementation details may continue to evolve as the investigation progresses, but the defensive takeaway is already clear: AI and ML processing systems should be secured like high-risk software supply chain infrastructure.

Any system that automatically processes external datasets or model artifacts should be designed with hostile input in mind. Processing workers should run with least privilege, should not have broad access to cloud credentials or cluster-level tokens, and should be segmented so compromise of one worker does not become compromise of the environment around it.

Security teams should also hunt for early signs of intent drift inside ML workflows. Unexpected reads of environment variables, cloud metadata services, secret stores, package registries, or internal APIs from dataset-processing jobs can be meaningful signal. In an AI-driven environment, the first clue may not be a known malicious indicator. It may be a workload behaving with curiosity it should not have.

What AI guardrails mean for incident response

One of the most useful lessons for security teams came during the response, when Hugging Face’s responders reportedly needed to analyze logs containing exploit payloads, attacker commands, and command-and-control artifacts. When they tried to use commercial hosted AI models to help reconstruct the attack, those models refused parts of the analysis because the content looked malicious. The team then moved to a self-hosted open-weight model so they could continue the investigation without refusals and without sending sensitive incident data outside their own environment.

The practical issue here is guardrail asymmetry: attackers, rogue agents, or unrestricted systems may not respect usage policies, while defenders using hosted tools can be slowed by the same safety systems designed to prevent misuse. Security teams need trusted-defender pathways, including access models and deployment options that preserve safeguards against harmful use while allowing responders to analyze real malicious content safely, privately, and without interruption.

AI-assisted incident response also needs to be tested before an incident begins, especially if teams expect models to support triage, log analysis, malware review, or timeline reconstruction under pressure. Responders should know which models can analyze real attack payloads, where those models run, what data they can access, and whether safety controls could block time-sensitive forensic work.

What security teams should do about agentic AI risk

The practical response to this incident is preparation, with organizations treating AI agents as both powerful tools and potential attack surfaces when those agents can access code, credentials, infrastructure, datasets, or internal systems.

Security teams should apply familiar controls with more urgency across AI and ML environments: treat downloaded models, datasets, and loader scripts as untrusted code; enforce least privilege on AI and ML processing workers; prevent node-level compromise from becoming cluster-wide compromise; restrict access to cloud metadata endpoints and secrets; monitor unexpected outbound connections from AI-related workloads; and review whether evaluation environments have real containment or simply convenient isolation.

Detection logic needs to account for machine-speed activity. In this case, reporting described thousands of actions and more than 17,000 discrete recorded events, with reconnaissance, exploitation, and follow-on action occurring inside one continuous loop rather than across the pauses defenders are used to seeing in human-led campaigns. Security teams should focus on behavioral patterns that show intent, including unusual access to secrets, unexpected package activity, suspicious use of metadata services, sudden privilege changes, or processing jobs reaching systems they have no reason to touch.

As autonomous activity becomes faster and noisier, the bottleneck may shift from detecting that something happened to understanding what matters quickly enough to change the outcome. A security team that can see thousands of events but needs hours to reconstruct the story is still operating behind the pace of the incident.

How preemptive security helps reduce AI-driven risk

At Rapid7, our view is that this is where preemptive security becomes especially important. Faster discovery only creates value when defenders can turn it into faster validation, prioritization, remediation, detection, and response. The same principle applies to agentic AI risk. If AI accelerates how weaknesses are found and exploited, defenders need security operations that can act earlier with better context and more confidence.

That means connecting exposure management with detection and response, so teams understand which risks are exploitable, which assets matter most, what suspicious behavior is already present, and which actions will reduce risk fastest. It also means using AI carefully and practically, not as a replacement for security judgment, but as a way to reason across telemetry, reduce noise, support investigation, and help teams make decisions at the speed the threat environment now demands.

AI-enabled defense is becoming part of resilience planning, especially for organizations running critical systems or high-value digital infrastructure. The goal is to give defenders the speed, context, and consistency to operate inside the attacker’s decision cycle, without removing the judgment and accountability that effective security requires.

The OpenAI and Hugging Face incident will continue to generate debate as more details emerge, but defenders already have enough to work with. Agentic systems are beginning to test the seams between AI research, software supply chain security, cloud infrastructure, and incident response. The organizations best positioned for what comes next will be the ones making those seams visible, monitored, and resilient before the next incident puts them under pressure.

KAPE 101: A Kroll Artifact Parser and Extractor Cheatsheet

By: BHIS
15 July 2026 at 10:00

Spend time performing forensic analysis on the Windows Operating System and you'll see a host of artifacts that can be used to identify adversary activity. From changes to the registry to the System Resource Utilization Monitor, Windows artifacts run deep. The challenge is locating, extracting, and parsing these artifacts in an efficient manner.

The post KAPE 101: A Kroll Artifact Parser and Extractor Cheatsheet appeared first on Black Hills Information Security, Inc..

Former DigitalMint ransomware negotiator who duped clients sentenced to 70 months in jail

9 July 2026 at 20:16

A former ransomware negotiator for DigitalMint was sentenced to 70 months in jail for deceiving his employer’s clients and conspiring with ransomware affiliates to extort a combined $75.3 million from five U.S. companies he was entrusted to aid during their moments of extreme crisis, the Justice Department said Thursday. 

Angelo John Martino III shared confidential information he gained from his work as a ransomware negotiator, including victim organizations’ negotiating positions and insurance policy limits, to extract the maximum payment for himself and other BlackCat affiliates he colluded with in backchannels.

Five of Martino’s victims hired DigitalMint, which assigned the 41-year-old to conduct ransomware negotiations on their clients’ behalf — a rare position he exploited to play both sides, effectively conducting ransomware negotiations with himself and his co-conspirators.

The five victims, all of which paid a ransom between April 2023 and September 2023, include a nonprofit that paid a nearly $26.8 million ransom, a financial services company that paid nearly $25.7 million, and a hospitality company that paid almost $16.5 million. 

DigitalMint hired the South Florida-based man in 2022 after he was already engaging in criminal activity, according to court records. The husband and father of two young children had a long history as a cybersecurity professional, dating back to at least 2015, with previous stints at Booz Allen Hamilton, Tracepoint and TRM Labs.

Martino surrendered to U.S. Marshals in March, was released on a $500,000 bond, and pleaded guilty in April to conspiracy to obstruct, delay or affect commerce or the movement of any article or commodity in commerce by extortion. He faced up to 20 years in prison.

Martino also admitted to conspiring with Kevin Tyler Martin, another former ransomware negotiator at DigitalMint, and Ryan Clifford Goldberg, a former manager of incident response at Sygnia, to deploy BlackCat ransomware, also known as ALPHV, against five additional U.S. companies between April and November 2023. 

Goldberg, Martin and Martino split proceeds from a nearly $1.3 million ransom payment they received from a medical company in May 2023, but did not successfully extort a financial payment from the other four victims.

Goldberg and Martin pleaded guilty in December to participating in a series of ransomware attacks and were each sentenced in April to four years in prison. 

DigitalMint insists it had no knowledge of Martino’s criminal acts. “The actions of Martino and his co-conspirators were deliberately concealed from DigitalMint and were in clear violation of the company’s values, ethical standards and the law,” a company spokesperson told CyberScoop in a statement.

The company also reiterated that it immediately terminated Martino and suspended his access to systems when the Justice Department notified the company it was investigating him in April 2025.

“DigitalMint maintained controls consistent with industry standards, including background checks and compliance procedures, but Martino intentionally hid his conduct from the company, including through separate, unauthorized communication channels that the government’s filings describe as accessible only to Martino and the BlackCat negotiators and affiliates,” the spokesperson added.

DigitalMint has yet to directly answer questions about whether it refunded its clients who were victimized by Martino. 

“We are not able to discuss specific client relationships or fee arrangements due to confidentiality obligations,” the spokesperson said. “We remain committed to our clients and will continue to maintain strict confidentiality on all commercial matters.”

The case against Martino showcases an extreme, albeit rare, example of the dark underbelly of ransomware negotiation as a practice. The pitfalls of ransomware negotiation are excessive and these backchannel negotiations, which remain largely unscrutinized, can go awry for various reasons.

Officials describe Martino as a ‘double agent’ driven by greed

Prosecutors said Martino obtained an ALPHV affiliate account that he shared with his co-conspirators and received a portion of the ransomware payments for his involvement in the conspiracy.

Authorities have seized $10 million in assets, including a bayfront home with an estimated value of $1.68 million, a second single-family home with an estimated value of $396,000, and cryptocurrency wallets controlled by Martino. Law enforcement also seized multiple vehicles, a food truck and a 29-foot luxury fishing boat that Martino obtained using proceeds from his crimes.

“Angelo Martino’s victims shared heartbreaking accounts of how their businesses were nearly destroyed, while the people they hired to help them instead betrayed them to ransomware gangs,” A. Tysen Duva, assistant attorney general at the Justice Department’s Criminal Division, said in a statement. “Today’s sentence accounts for the harm Martino caused and demonstrates that the Department of Justice can and will identify and prosecute cybercriminals to the fullest extent of the law.”

Court records include a series of chats Martino held with co-conspirators and victims that exemplify the lengths he went to betray DigitalMint’s clients and empower his accomplices with crucial tips for a successful negotiation strategy.

During an incident response with one of his victims, Martino told a BlackCat affiliate the company’s insurance carrier “was only approving small accounts,” according to his plea agreement. “Keep denying our offers and I will let you know once I find out the max the[y] want to pay,” he added.

“We don’t know how you came up with your demand but we are losing money operationally and all of our loans are going to turnover on us this year at double the interest rates,” Martino said in a negotiation chat visible to DigitalMint and the victim organization in the hospitality industry. “We are able to give you $1 million now, which is a very serious offer.”

Following Martino’s instructions, the BlackCat accomplice responded: “Well, you can keep that for the penalties and lawsuits which are coming your way in case we expose you. Time is ticking — we know how much you can pay. Contact your insurance. We know about them also. Stop wasting time.”

That victim company ultimately paid a ransom worth nearly $16.5 million at the time to receive a decryptor and the BlackCat affiliate’s commitment to not publish stolen data. Two other victims Martino represented via DigitalMint at the time paid $6.1 million and $213,000 ransoms for similar commitments.

“Angelo Martino sold out the very victims he was hired to represent, handing their confidential negotiating positions to BlackCat actors to drive up ransoms and enrich himself,” Brett Leatherman, assistant director of the FBI’s Cyber Division, said in a statement.

In a sentencing memo, federal prosecutors described Martino as a “double agent working to maximize the harm to his clients and the financial gain to cybercriminals who paid him a part of the ransom.”

Prosecutors added: “This was not a crime of opportunity or momentary weakness; it was a sustained abuse of a fiduciary-like relationship driven by a single purpose: greed.”

ALPHV/BlackCat, which first appeared in late 2021, was a notorious ransomware variant linked to a series of attacks on critical infrastructure providers. The Justice Department disrupted BlackCat in December 2023, seized sites operated by some of its affiliates, and said the FBI developed a decryption tool that helped hundreds of victims restore their systems and save about $99 million in ransom payments at the time. 

Martino is scheduled to return to court Sept. 17 to determine the amount of restitution ordered against him for his crimes.

The post Former DigitalMint ransomware negotiator who duped clients sentenced to 70 months in jail appeared first on CyberScoop.

❌
❌