Unchecked AI in the workplace quickly becomes a massive loophole for data leaks and security breaches. All too often, employees drop sensitive company data into public chatbots, or install rogue AI assistants on their own — in the process handing over way too much access. In a previous post, we broke down the different types of risky AI systems, and later shared some tips on how to turn off the built-in AI features on major tech platforms. Today let’s take a look at practical ways to block or restrict the unauthorized “helpers” employees might be using — from ChatGPT and Grammarly, to meeting bots like Fireflies and Read AI.

How to detect and restrict ChatGPT

ChatGPT is the biggest culprit when it comes to unauthorized AI use worldwide. A quick word of warning, though: an outright ban only sends users hunting for sketchy third-party sites or messaging app chatbots that hook into the same service. That’s why it’s always a good idea to offer an approved alternative before pulling the plug.

Detecting it: keep an eye on the NGFW or web filter for traffic heading to chat.openai.com, chatgpt.com, oaistatic.com, oaiusercontent.com, or cdn.oaistatic.com. It’s also smart to use EDR/EPP tools to scan browser histories, installed apps, and browser extensions across corporate devices.

Locking it down: use the firewall or web filter to block the entire AI Services category, and set up DNS to reroute traffic away from those OpenAI domains. Browser policies can also be used to ban ChatGPT-powered extensions. Better yet, block all extensions not on a pre-approved allowlist. Finally, use application controls and EPP solutions to stop users from installing the official desktop app (ChatGPT.exe or com.openai.chat).

How to detect and restrict Claude and Claude Code

Detecting it: use the NGFW or web filter to track traffic going to claude.ai, anthropic.com, *.anthropic.com, and api.anthropic.com. EDR/EPP or application control tools can also be used to scan employee computers for the desktop app (claude.exe).

Locking it down: drop a blanket block on the AI Services category through the NGFW or web filter, and tweak DNS settings to reroute traffic away from the aforementioned Anthropic domains. Next, use browser policies to shut down Claude-powered extensions. Finally, use application controls and the EPP platform to prevent users from installing the desktop app.

How to detect and restrict Perplexity AI

Detecting it: keep tabs on the NGFW or web filter to flag any traffic heading to *.perplexity.ai or pplx.ai.

Locking it down: just like the others, add the AI Services category to the NGFW or web filter blocklist, and use DNS routing to redirect traffic away from those domains.

Configure the browser to block third-party extensions from being installed. If Firefox is used in the organization, be aware that recent versions come with Perplexity built in. Luckily, these AI features can be turned-off company-wide using enterprise policies — specifically, by setting SidebarChatbot = blocked. The full list of tweaks can be found in the Firefox documentation.

How to detect and restrict DeepSeek

Detecting it: keep an eye on the NGFW or web filter for traffic hitting deepseek.com, chat.deepseek.com, api.deepseek.com, or platform.deepseek.com. For better precision, analyze the SNI (server name identification) in TLS connection requests. For mobile devices, look out for the official app (com.deepseek.chat).

Locking it down: blocklist the AI Services category on the NGFW or web filter, and reroute traffic to DeepSeek’s domains via DNS settings. Use browser policies to block third-party extensions, and lean on MDM/EMM tools to restrict the mobile app.

How to detect and restrict Mistral, xAI Grok, and Character.ai

The playbook for these tools is exactly the same as DeepSeek, so here’s the quick list of domains to watch for and block: chat.mistral.ai, mistral.ai, console.mistral.ai, grok.com, x.ai, api.x.ai, character.ai, beta.character.ai, and c.ai.

A quick word of warning on Grok: because Grok is baked into X, blocking this specific AI access point means blocking the entire social media platform.

How to detect and restrict Slack AI

Detecting it: in the Slack workspace admin dashboard, look under Analytics → Slack AI usage. If an enterprise plan is used, the detailed Slack logs can be searched for any events starting with the ai_ prefix.

Blocking it with policies: in the organization’s Slack settings, click through the Workspace settings → Roles & permissions → Feature access, and change the permission to “no one”. Slack has a step-by-step guide in their help center.

Locking it down: shutting this down at the network level is tricky; it can be pulled off with a finely tuned CASB solution in place. Also, don’t forget the importance of blocking rogue integrations and keeping external AI services from tapping into Slack data in the first place. We covered how to lock this down using OAuth controls in a previous post.

How to detect and restrict Zoom AI Companion

Detecting it: if a corporate Zoom subscription is in use, just head to Admin Center → Reports → AI Companion usage. Detecting Zoom’s AI when employees join external meetings or use free accounts is a lot tougher, but email filters can be set up to flag incoming AI-generated meeting notes by scanning for subject lines or text containing “Meeting summary” or “Meeting assets”.

Blocking it with policies: for the company’s own Zoom subscription, go to the Admin Portal → Account Management → Account Settings → Meeting → AI Companion and toggle it OFF for everyone.

Locking it down: unfortunately, AI Companion is baked into Zoom’s DNA, so the only real option is blocking Zoom altogether.

How to detect and restrict Grammarly

What looks like an innocent spellchecker is actually one of the biggest culprits for workplace data leaks.

Detecting it: check the NGFW or web filter logs for traffic hitting grammarly.com, *.grammarly.com, and gnar.grammarly.com. EDR and MDM/EMM tools can also be used to hunt down the standalone desktop apps (Grammarly Desktop.exe and the macOS version), as well as the Grammarly browser extension.

Locking it down: use firewalls to block those domains at the network level, and EPP to stop employees from installing the desktop app, browser extensions, or the Grammarly add-ins for Microsoft Word and Excel.

How to detect and restrict meeting assistants: Fireflies, Read.ai, Tactiq, Fathom, and Granola

This massive category of third-party SaaS tools records and analyzes meetings — creating a massive risk for data leaks. The trickiest part? Outside clients or vendors can bring these bots into a meeting just as easily as employees can.

Detecting them: run an audit on calendar invites, and look for bot participants using email domains like @fireflies.ai, @read.ai, @tactiq.io, @fathom.video, or @granola.ai. Zoom, Teams, or Google Meet logs can also be used to review external participants who joined past calls.

Locking them down: since it’s impossible to control what outsiders do, blocking these bots comes down to tightening meeting rules. The best moves are: blocking users from granting OAuth permissions for bots to join calls, restricting employees from inviting unapproved external participants, or locking down meeting recording access for external users. That last option is usually the least painful way to keep bots out without disrupting business.

How to detect and restrict AI code editors: Cursor, Windsurf, and the like

Detecting them: use EDR/EPP tools to scan for executables like cursor.exe or windsurf.exe. It’s also worth monitoring network traffic heading to cursor.com and windsurf.com, as well as traffic hitting various AI model API providers. Keep in mind that there’s a pretty extensive list of API hosts to monitor here, since these editors aren’t tied to just one specific AI vendor.

Blocking them with policies: these apps can be prevented from being installed by setting up filters based on the developer’s digital signature certificate. Alternatively, a strict application allowlist can be employed where only pre-approved software is allowed to run.

Locking them down: rely on the EPP/EDR platform to actively detect and block these applications from running.

How to detect and restrict local AI tools: Ollama, LM Studio, and GPT4All

On one hand, this category carries fewer data leak risks because the AI models run completely locally on the user’s machine. On the other hand, it opens up a whole new can of worms: these apps themselves aren’t always highly secure, and can become targets for cyberattacks. Plus, it still means that employees can misuse models or process data in unauthorized ways.

Detecting them: EDR/EPP tools are the best line of defense here. They should be used to flag known local AI files and processes like ollama.exe, ollama serve, lmstudio.exe, LM Studio.app, jan.exe, or gpt4all.exe. From a network perspective, it’s worth scanning for open ports on local devices — typically port 1234 for Ollama and LM Studio, or port 8080 for WebUIs (using an additional fingerprint check of the server response). Another massive red flag is the presence of large files (often several gigabytes) containing language model weights. Look out for extensions like .gguf, .bin, or sometimes .safetensors.

Locking them down: use EPP/EDR platforms or windows AppLocker to block these applications by name, or switch to an application allowlist.

How to detect and restrict autonomous agents: OpenClaw, NemoClaw, and NanoClaw

This is easily one of the most dangerous categories of AI tools out there. These agents mix high-level independence with access to untrusted data, making them a massive security headache.

Detecting them: use EPP/EDR tools to sniff out active processes like openclaw, nanoclaw, nemoclaw, or clawdbot. Also keep an eye out for devices running Node.js that suddenly start launching Bash or Python scripts. Another dead giveaway is the appearance of system folders like ~/openclaw, ~/nanoclaw, ~/.claw*, or ~/clawhub. At the network level, monitor connections to the AI model APIs we mentioned earlier, as well as traffic hitting servers like openclaw.ai, nanoclaw.dev, or clawhub.*.

Locking them down: the safest bet is to use strict application allowlisting (only allowing approved software to run), or to specifically ban the known agent apps listed above. On top of that, consider blocking non-developers from installing Node.js and Docker, neither of which they need on their computers anyway.

WhatsApp has detected and stopped spear-phishing campaigns allegedly conducted by the NSO Group after investigating user reports of social engineering attacks. [...]

The company founded by Yossi Torati, Omer Gull, and Yuval Itzchakov has emerged from stealth mode.

The post A Security Raises $37 Million for Autonomous Offensive Security Platform appeared first on SecurityWeek.

Gogs has patched a critical security zero-day flaw that can allow attackers to compromise Internet-facing instances and access any repositories (including private ones). [...]

Enabling security tooling is the starting point. Making it operational—where findings drive decisions, response times are measurable, and your security posture improves week over week—is where most organizations struggle.

This blog post provides a phased maturity roadmap for organizations that have already enabled AWS Security Hub and Amazon GuardDuty. These two services form the foundation of a cloud-centered security operations capability on AWS. Security Hub provides centralized security posture management and aggregates findings from multiple AWS security services, while GuardDuty provides intelligent threat detection by continuously monitoring for malicious activity and unauthorized behavior. For any production or enterprise AWS environment, having both services enabled across all accounts and AWS Regions is a baseline expectation; not because they’re optional add-ons, but because effective security operations require both the ability to detect threats and the ability to understand your overall security posture. If you haven’t yet enabled them, the Security Hub documentation and GuardDuty documentation provide setup guidance, including multi-account deployment with AWS Organizations.

Customers consistently tell us that while individual AWS security service documentation is thorough, what’s missing is a consolidated operational playbook—one resource that ties the services together into a working security operations practice with clear phases, progression criteria, and an operational cadence. That’s the gap this post fills. Rather than covering how each feature works (the documentation does that well), this post focuses on when and why to use each capability, and how to build the organizational habits that make them effective.

What follows is a six-phase roadmap for moving from these services are active to these services are driving our security operations. Each phase builds on the previous one, and each is designed to deliver tangible, measurable improvement.

Goal: Understand what’s working before changing anything.

Estimated timeline: 1–2 weeks

Move to Phase 1 when: You have a documented current-state assessment covering all the following items.

Before introducing new processes or automation, establish a clear picture of the current environment. This assessment informs every decision that follows.

Actions:

• Findings inventory: Review existing active GuardDuty findings to determine how many there are, the severity distribution, and how old the oldest findings are. A large backlog of untouched HIGH or CRITICAL findings that have been sitting for weeks is a strong signal about where to focus first.
• Security Hub score baseline: Determine your current compliance score against AWS Foundational Security Best Practices (FSBP) and The CIS AWS Foundations Benchmark. Check to see which standards are enabled; if multiple standards are enabled, review for overlapping standards (creating noise) or unused standards.
• Multi-account and multi-Region check: Look to see if GuardDuty is enabled in every account and every Region, or only in Regions with active workloads. Threat actors frequently operate in Regions that organizations don’t actively monitor. Also check to see if Security Hub aggregation is configured with a delegated administrator account or if each account is being managed independently.
• Integration check: Determine if GuardDuty findings are flowing into Security Hub and if Amazon Inspector and Amazon Macie are enabled and feeding findings in. Without integration, Security Hub might be only surfacing its own compliance checks.
• Notification check: See if there’s an Amazon EventBridge rule configured for notifications and if so, how findings are being routed and to whom. Know if notifications are being sent using an Amazon Simple Notification Service (Amazon SNS) topic or a chat channel integration. Without a clear notification and response workflow, findings can accumulate silently in the console with no one looking at them.

Deliverable: A one-page current state assessment that identifies what’s enabled, what’s flowing where, who’s looking at it, and what’s in the existing backlog.

Goal: Make the signal meaningful before asking anyone to act on it.

Estimated timeline: 2–3 weeks

Move to Phase 2 when: Remaining findings represent items requiring real decisions, compliance scores reflect actual posture, and you can articulate why every suppression rule and disabled control exists.

This is the single most important phase. If this step is skipped in favor of jumping straight to automation, the result is automated chaos. Alert fatigue is the primary reason security tooling is ignored, and addressing it first is what makes everything that follows sustainable.

GuardDuty tuning:

• Create suppression rules for known-benign findings. The goal is to suppress activity you’ve already evaluated and accepted—such as expected traffic from corporate egress IPs (based on trusted IP lists), internal tools that trigger DNS-based findings, or internet-facing resources that naturally receive port scanning. The principle: if you’ve investigated a finding and it’s expected, suppress it so your team can focus on what matters.
• Triage every active HIGH and CRITICAL finding into three categories: needs immediate investigation (real threat, not yet reviewed), true positive, already addressed (archive using workflow status), or false positive or expected behavior (create a suppression rule). Every finding must be categorized into one of these three states.
• Review GuardDuty protection plans and enable any that are relevant but not yet active. Organizations that enabled GuardDuty years ago might not have activated protection plans released since then (such as Runtime Monitoring, Malware Protection, RDS Protection, and Lambda Protection). Evaluate each against your workload profile and enable what applies.

Security Hub tuning:

• Disable controls that aren’t relevant to the environment. This is the highest-value quick win. If a service isn’t in use, disable its controls. If a control is addressed by an alternative solution, disable it. A 47% compliance score where half the failures are irrelevant trains teams to ignore the dashboard entirely. See the Security Hub controls reference for the full list.
• Choose a primary standard. AWS Foundational Security Best Practices is a strong default. The CIS AWS Foundations Benchmark adds value when there’s a specific compliance mandate. Avoid enabling PCI DSS or NIST 800-53 standards unless there’s a reporting requirement—they add significant volume without proportional signal for most organizations.
• Configure cross-Region aggregation to the delegated administrator account if not already in place. A single aggregated view eliminates the need to check findings across multiple Regional consoles.
• Use the workflow status field operationally. Findings should progress from NEW to NOTIFIED to RESOLVED or SUPPRESSED. If everything remains in NEW indefinitely, the system carries no operational meaning.

Deliverable: A tuned environment where remaining findings represent items that require real decisions. Compliance scores should now reflect your organization’s actual security posture rather than noise.

Goal: Get the right findings to the right people at the right time.

Estimated timeline: 2–3 weeks

Move to Phase 3 when: CRITICAL and HIGH findings reach the security team within minutes, MEDIUM findings create tracked tickets, and notifications include enriched context. No action is taken until a person or an automation is informed that something needs attention.

Architecture: Security Hub to EventBridge rule to routing logic to destination

Tiered notification strategy:

CRITICAL	Page on-call immediately	PagerDuty or Opsgenie	15 minutes
HIGH	Alert security team channel	Slack or Teams channel and ticket creation	4 hours
MEDIUM	Create ticket for review	Jira or ServiceNow	48 hours
LOW or INFORMATIONAL	Batch digest	Weekly email summary or dashboard review	Next review cycle

Key design decisions:

• Route from Security Hub, not individual services. Because findings from GuardDuty, Inspector, Macie, and Security Hub compliance checks all aggregate in Security Hub, build your EventBridge rules there for centralized management.
• Create a fast path for the most dangerous finding types. Certain GuardDuty findings, particularly those involving credential exfiltration, cryptocurrency activity, trojans, and active compromises, warrant a separate, faster routing path that bypasses normal triage. Identify these based on your threat model and the GuardDuty finding types reference.
• Enrich notifications before delivery. A raw JSON finding in a chat channel provides little actionable context. Use an AWS Lambda function to format notifications with the information responders need: account alias, Region, Amazon Resource Name (ARN), finding type, severity, a console deep link, and a plain-language description. The Security Hub CloudWatch Events integration guide describes the event format.

Deliverable: A working notification pipeline where CRITICAL and HIGH findings reach the security team within minutes, MEDIUM findings create tracked work items, and LOW and INFORMATIONAL findings are batched for periodic review.

Goal: For findings where the correct response is deterministic, remove the human from the loop.

Estimated timeline: 3–4 weeks

Move to Phase 4 when: At least 3–5 high-confidence finding types have automated responses deployed with audit trails, and the team has established a process for evaluating new auto-remediation candidates.

The guiding principle: Only auto-remediate when all three conditions are met: the finding is high-confidence, the response is deterministic, and the blast radius of the automated action is limited. Automated remediation must not create the risk of a production outage.

Decision framework:

Confidence level	High – no false positive risk	Medium – context-dependent	Low – requires investigation
Response complexity	Single, well-defined action	Multiple steps or judgment calls	Requires forensic analysis
Blast radius	Limited to one resource	Could affect dependent services	Production-wide impact
Rollback difficulty	Straightforward to reverse	Moderate effort to reverse	Difficult or impossible to reverse

Common auto-remediation categories:

• Instance isolation for confirmed compromise findings (cryptocurrency mining, malware, and trojans): Replace the security group, snapshot volumes for forensics, and notify.
• Credential revocation for confirmed credential compromise: Attach deny-all policies, revoke sessions, and deactivate access keys as appropriate to the credential type.
• Compliance drift correction for deterministic misconfigurations: Re-enable Amazon Simple Storage Service (Amazon S3) Block Public Access, revoke overly permissive security group rules, and re-enable AWS CloudTrail logging.
• Notification-only escalation for findings that require human judgment before action: Amazon Elastic Block Store (Amazon EBS) encryption gaps (require migration) and access key rotation (requires coordination with the key owner).

For implementation, AWS provides Security Hub Automated Response and Remediation (SHARR), a solution that includes pre-built remediation playbooks deployed as AWS Step Functions workflows triggered by EventBridge. This is a strong starting point—evaluate the provided playbooks, enable the ones that fit, and extend with custom remediations as needed.

Note: For findings that recur because the environment lacks preventive guardrails, the best long-term response is often a service control policy (SCP) that prevents the misconfiguration from occurring in the first place. Phase 5 covers this preventive controls layer.

Deliverable: A library of automated and semi-automated remediation runbooks with full audit trails, and a documented decision framework the team uses to evaluate new auto-remediation candidates.

Goal: Turn security findings management into a sustained organizational practice, not a one-time cleanup.

Estimated timeline: 4–6 weeks to establish, then ongoing

Move to Phase 5 when: The weekly cadence has been running consistently for at least 8 weeks, monthly metrics show positive trends, and the first quarterly review has been completed.

This is where many organizations stall, and it’s the most important phase in the entire roadmap. The technology is working, the notifications are flowing, automated remediations are firing, but there’s no organizational habit built around it. Without this phase, everything you’ve built in Phases 0–3 will gradually decay. Suppression rules will go stale, new team members won’t know the system exists, and findings will start accumulating again. The operational rhythm is what converts a security tooling deployment into a security operations practice.

Attendees: Security team lead, cloud platform team representative, rotating engineering lead from an application team

Why the rotating engineering lead matters: Security findings don’t exist in a vacuum; they’re generated by workloads that engineering teams own. Rotating an engineering representative through this meeting accomplishes three things: it builds security awareness across the organization, ensures findings are routed to people with the context to resolve them, and creates organizational accountability beyond the security team.

Agenda template:

5 minutes	Compliance score trend – Review Security Hub scores by account and standard. Is the trend improving, declining, or flat? If declining, why?	Security lead	Identified regression areas
5 minutes	Critical and high findings review – Walk through new HIGH and CRITICAL GuardDuty findings from the past week. Are there any that need immediate escalation?	Security lead	Escalation actions assigned
10 minutes	Top five failing controls – Identify the five Security Hub controls with the most failures. Assign an owner and a target date for each.	Platform lead	Owners and dates documented
5 minutes	Automation review – Did any auto-remediations fire this week? Did they work correctly? Were there any false triggers?	Security lead	Automation adjustments queued
5 minutes	Tuning decisions – Are new suppression rules needed based on this week’s findings? Are any new finding types candidates for auto-remediation?	All	Tuning backlog updated

Running the meeting effectively:

• Keep a running document (such as a wiki page or shared document) that captures decisions and action items week over week. This becomes your institutional memory.
• If the compliance score hasn’t moved in over 3 weeks, that’s a signal. Either the assigned work isn’t happening, or the remaining findings are genuinely difficult to address. Both need to be discussed.
• Track action items from previous weeks. A review that generates action items but never follows up on them will lose credibility and attendance quickly.

Define clear escalation paths before they’re needed:

CRITICAL finding not acknowledged within the SLA	Auto-escalate to security team manager	15 minutes after SLA breach
HIGH finding not resolved within the SLA	Escalate to finding owner’s manager	4 hours after SLA breach
Compliance score drops more than 5 points in a week	Escalate to cloud platform team lead for investigation	Next business day
Auto-remediation failure	Page security on-call	Immediate
New finding type not covered by existing runbooks	Add to weekly review agenda for triage and runbook development	Next weekly review

Compile these metrics monthly and review them with security and engineering leadership. The goal is to tell a story about whether the organization’s security posture is improving, stable, or degrading, and why.

Mean time to acknowledge (MTTA) for CRITICAL findings	Are findings being seen promptly?	Decreasing month over month
Mean time to resolve (MTTR) for CRITICAL and HIGH findings	Are findings being acted on?	Decreasing month over month
Security Hub compliance score by standard, by account	What is the posture trend over time?	Increasing month over month
Number of active GuardDuty findings by severity	Is the backlog growing or shrinking?	Decreasing for HIGH and CRITICAL
Findings auto-remediated compared to manually resolved	Is automation delivering value?	Auto-remediation ratio increasing
Number of suppressed findings (with quarterly justification review)	Is noise being managed, or are problems being hidden?	Stable or decreasing
New findings introduced compared to resolved this month	Is the organization getting ahead or falling behind?	More finding resolved than introduced
SLA adherence rate by severity	Are response commitments being met?	More than 95% for CRITICAL, and more than 90% for HIGH

Building the dashboard: Use Amazon CloudWatch dashboards for real-time operational visibility or Amazon QuickSight connected to Security Hub findings through Amazon Security Lake for historical trend analysis and executive reporting. The dashboard should be visible to—and regularly viewed by—everyone in the weekly review, not locked in a security team tool.

The quarterly review is a deeper inspection of the system itself; not just the findings, but the machinery processing them.

Quarterly review checklist:

• Suppression rules audit: Review every active suppression rule to determine if the underlying condition is still present and the suppression is still justified. Document the review outcome for each rule.
• Disabled controls audit: Review every disabled Security Hub control. Check that the justification is still valid and if the environment changed (for example, a service that wasn’t in use is now in use).
• Automation audit: Review AWS Identity and Access Management (IAM) roles used by remediation functions and verify least privilege. Review execution logs for any anomalies or failures that weren’t caught.
• New capabilities review: Evaluate newly released GuardDuty protection plans and Security Hub controls from that quarter. AWS releases new detection and compliance capabilities regularly. If you’re not reviewing them quarterly, you’re accumulating blind spots.
• Process effectiveness review: Determine if the weekly meeting is well-attended and if action items are being completed. Make sure SLAs are being met. If attendance, action item completion, and SLA compliance aren’t where they should be, explore structural changes to address the gaps.

Use this rubric to assess the maturity of your operational rhythm itself. Score each dimension 1–3 and use the total to track progress over time.

Review cadence	One time reviews when someone remembers	Weekly review happens, but attendance is inconsistent	Weekly review is consistently attended with documented outcomes
Metrics tracking	No metrics captured	Metrics are collected monthly but not acted on	Metrics drive decisions and declining trends trigger specific actions
Finding ownership	Findings sit in queue with no owner	Findings are assigned to teams but SLAs aren’t tracked	Every finding has an owner, SLAs are tracked, and breaches are escalated
Automation management	Set-and-forget automations	Automation logs are reviewed periodically	Automation is reviewed weekly, and new candidates are evaluated continuously
Tuning lifecycle	Suppression rules created but never reviewed	Annual review of suppressions and disabled controls	Quarterly reviews with documented justification for every rule
Cross-team engagement	Security team works in isolation	Platform team participates	Engineering teams actively participate and own remediation

Scoring (revisit quarterly):

• Beginning: 6–9
• Established: 10–14
• Optimized: 15–18

Deliverable: A documented operational cadence with clear ownership (consider a RACI matrix), metrics dashboards, escalation procedures, and a continuous improvement loop. The cadence should survive team member turnover—if it depends on one person remembering to run it, it’s not yet operational.

Goal: Fill remaining gaps and build toward a comprehensive security operations capability. Estimated timeline: Ongoing. Prioritize based on organizational risk profile and compliance requirements.

• Amazon Inspector integration: Enable Amazon Inspector for Amazon Elastic Compute Cloud (Amazon EC2) instances, Lambda functions, and Amazon Elastic Container Registry (Amazon ECR) container images. Findings flow into Security Hub automatically, adding vulnerability management alongside threat detection and posture management. Prioritize this if you have Amazon EC2 or container workloads without an existing vulnerability scanning solution.
• Amazon Macie: Enable Amazon Macie for S3 buckets containing potentially sensitive data. Particularly important for organizations with compliance requirements around personally identifiable information (PII), protected health information (PHI), or Payment Card Industry (PCI) data. Configure automated sensitive data discovery and route findings to Security Hub.
• Amazon Security Lake: Amazon Security Lake centralizes security-relevant logs in OCSF format for long-term retention, forensic investigation, and threat hunting. This is valuable when you need historical analysis beyond the Security Hub retention window, or when feeding a third-party Security Information and Event Management (SIEM) tool.
• Preventive controls layer: Convert recurring detective findings into preventive policies. Use SCPs to prevent disabling GuardDuty, Security Hub, and CloudTrail, IAM permission boundaries on developer roles, AWS WAF on public endpoints, and AWS Network Firewall for VPC traffic inspection. The pattern is to make recurring misconfigurations impossible to introduce.
• Detective controls expansion: Use AWS IAM Access Analyzer for external access and unused access findings, AWS CloudTrail Lake for long-term queryable audit logs, and AWS Config custom rules for organization-specific compliance checks.
• Incident response readiness: Have incident response playbooks referencing specific GuardDuty finding types, pre-built forensics infrastructure (isolated VPC, forensic AMIs, and pre-configured IAM roles), regular tabletop exercises, and AWS CloudFormation templates to deploy isolation infrastructure on demand. See the AWS Security Incident Response Guide for a comprehensive framework.

In this post, I provided a six-phase roadmap for operationalizing Security Hub and GuardDuty and showed that it isn’t a single project, but a progression. Phase 0 and Phase 1 can typically be completed in 3–5 weeks and deliver immediate clarity. Phases 2 and 3 build the response infrastructure that turns findings into action over the following 5–7 weeks. Phase 4 is what makes everything sustainable and is where you should invest the most attention. And Phase 5 expands the aperture from Security Hub and GuardDuty into a comprehensive security operations capability.

If you walked away from this post and did one thing, run the Phase 0 assessment this week. That single deliverable tells you exactly where to focus next. Use the following self-assessment checklist to identify your current phase, then focus on the next one. A tuned environment with working notifications and a weekly review cadence is dramatically more effective than a fully featured but neglected deployment. Start where you are, reduce the noise, build the habits, and iterate. To learn more, explore the AWS Security Hub User Guide, the Amazon GuardDuty User Guide, and the AWS Security Incident Response Guide. If you’ve implemented a similar operational cadence, or have questions about any phase, share your experience in the comments.

Phase 0	We know how many active GuardDuty findings exist across all accounts	☐
	We know our current Security Hub compliance score	☐
	We know whether GuardDuty is enabled in every account and region	☐
	We know who (if anyone) is reviewing findings today	☐
Phase 1	GuardDuty suppression rules exist for known-benign activity	☐
	Irrelevant Security Hub controls have been disabled with documented justification	☐
	All active HIGH and CRITICAL findings have been triaged	☐
	Security Hub compliance scores reflect actual posture, not noise	☐
Phase 2	HIGH and CRITICAL findings generate real-time notifications to the security team	☐
	MEDIUM findings automatically create tracked work items	☐
	Notifications include enriched context (account alias, resource ARN, and console link)	☐
Phase 3	At least three high-confidence finding types trigger automated remediation	☐
	Auto-remediation actions have full audit trails	☐
	Remediation runbooks are documented and version-controlled	☐
Phase 4	A weekly security review meeting occurs with defined attendees and agenda	☐
	MTTA and MTTR are tracked monthly for CRITICAL and HIGH findings	☐
	Suppression rules and disabled controls are reviewed quarterly	☐
	Security metrics trend positively over the past 3 months	☐
Phase 5	Amazon Inspector, Macie, or Security Lake are integrated	☐
	Preventive controls (SCPs, permission boundaries) address recurring findings	☐
	Incident response playbooks exist and are tested through tabletop exercises	☐

If you have feedback about this post, submit comments in the Comments section below.

---

Attackers can chain three already fixed vulnerabilities in the Ubiquiti UniFi OS server to execute remote code with root privileges and without authentication. [...]

Security teams are increasingly overwhelmed by alert fatigue, infrastructure maintenance, and complex hybrid environments. This article explores how Wazuh Cloud helps simplify SIEM/XDR operations through managed infrastructure, automated scaling, and AI-driven security analysis. [...]

Microsoft’s GitHub temporarily disabled over 70 repositories after they were reportedly compromised by a worm in the latest open source supply chain attack. The code shack took down 73 repos within the space of 105 seconds after its alarms were tripped on Friday, June 5, after detecting signs of the Miasma worm infecting its projects, according to StepSecurity’s co-founder and CTO, Ashish Kurmi. “Our priority is to protect customers and the broader ecosystem. We temporarily removed some repositories as we investigated potential malicious content," a Microsoft spokesperson told us on Wednesday, two days after this story was originally published. "All of these repos have been restored after review. As part of our investigation, we notified a small number of customers who may have pulled down content from the affected repositories. We will continue to investigate, and if anything further is identified that requires customer action, we will reach out directly through our established support channels.” Users reported issues quickly on Friday, after visits to those repos all resulted in the same message displayed, indicating that they had been disabled due to terms of service violations. According to StepSecurity’s analysis, the attack kicked off after a compromised contributor account pushed a malicious commit to Azure/durabletask. The commit dropped configuration files that triggered remote code execution on machines when a developer opened the repo in an IDE or AI coding tool, such as Claude Code, Gemini CLI, and Cursor. Several developers soon reported broken CI/CD pipelines, a support thread showed, although a moderator said at the time this was due to “an internal management issue.” "The repo that most immediately caused issues was Azure/functions-action,” Kurmi wrote, used to deploy code to Azure. With it being taken down, every workflow that referenced Azure/functions-action@v1 stopped resolving. GitHub stepped in a few hours after the repos were infected by the malicious commit. Its automated detections kicked in and disabled the repos in under two minutes, in two separate waves. However, it was the borking of the durabletask family that hinted at the bigger picture, that the attack was indeed a re-opening of the previous Miasma worm attack that hit Microsoft last month. Microsoft’s durabletask PyPi package was a previous target of the Miasma worm on May 19. Within a 35-minute window, three versions of the package were uploaded to PyPi, which planted infostealers on developers’ machines, specifically sniffing out cloud secrets and developer tool configurations on Linux systems. Crucially, the re-targeting of durabletask suggests the tokens associated with the compromised developer account used to execute the PyPi attack were not fully rotated, allowing an attacker to gain access and push commits to GitHub, Kurmi said. It was either that, or the contributor was re-compromised through the worm's own propagation loop, or a different contributor's token was used but the attacker altered the metadata to make it look like a repeated attack. Security shop Snyk described Miasma as a descendant of the Mini Shai Hulud worm. It’s the same one that ravaged open source packages over at the npm registry, including Red Hat’s, earlier this month. Cybercrime group TeamPCP claimed responsibility for developing Mini Shai Hulud, which itself is named after an earlier worm of the same name, sans “mini.” However, because TeamPCP open-sourced Mini Shai Hulud, it’s difficult to tell whether it was also behind Miasma or if someone else took the reins on the follow-up project. StepSecurity also reported that two days before the Microsoft attack, the same worm was making a nuisance of itself at npm, compromising more than 50 packages, including a Vapi.ai SDK with more than 408,000 monthly downloads.® Updated on June 10 with new comment from Microsoft and the fact that the repos have now been restored.

Israeli cybersecurity company Check Point has released security updates to patch a critical flaw affecting Remote Access VPN and Mobile Access deployments, which was exploited in zero-day attacks. [...]

Meta has asked a federal judge to hold Israeli spyware maker NSO Group in contempt of court after claiming it caught the surveillance vendor targeting WhatsApp users again despite a permanent injunction ordering it to stop. In a blog post on Monday, Meta said it had disrupted "NSO-linked social engineering attempts" after investigating reports from users. According to the company, the activity involved attempts to lure targets into clicking malicious links that redirected them to websites outside WhatsApp, as well as the creation of test accounts and groups on the messaging platform. "We successfully disrupted NSO-linked social engineering attempts after investigating user reports," Meta said. "They tried to trick people into clicking on malicious links to drive them to external websites outside of WhatsApp, similar to previously reported 1-click phishing campaigns linked to NSO." WhatsApp also published a handful of domains it linked to the campaign, including ikhwancast[.]com, ghazacast[.]com, and fr24cast[.]com, and said it was releasing indicators to help organizations identify related activity. The move marks the latest chapter in the long-running legal battle between Meta and the Israeli spyware maker. A US court found NSO liable in December 2024 for hacking WhatsApp users via its Pegasus spyware. In May 2025, a jury awarded Meta roughly $168 million in damages, but the judge later cut that to $4 million while issuing a permanent injunction barring NSO from targeting WhatsApp or its users. Meta, however, says NSO didn't get the memo. "Last year, WhatsApp made history by securing a landmark verdict and permanent injunction barring NSO Group ... from targeting WhatsApp and its users ever again," the company wrote. "Today, we're asking the court to hold them in contempt of that order." The company provided few technical details about the activity, such as when it occurred, how many users were targeted, whether any compromises were successful, or how it attributed the operation to NSO. Meta did not respond to The Register’s questions. However, the blog post adopts a hard line on the spyware industry than previous updates, repeatedly describing commercial spyware as a national security issue. "When a malicious company on the US government's Entity List continues to defy US courts, existing restrictions must remain firmly in place," WhatsApp wrote. "Easing them would undermine US national security and put American companies and billions of people worldwide who depend on secure communications at risk." If Meta's allegations are accurate, the episode suggests that a court loss is not enough to persuade a spyware vendor to leave a high-value target alone. ®

The University of Oxford disclosed a new data breach last week after being informed by its third-party provider, Group GTI, that its CareerConnect career services platform had been compromised. [...]

Check Point Research has identified active exploitation of CVE-2026-50751, a critical authentication bypass vulnerability affecting Check Point Remote Access VPN and Mobile Access deployments configured to use the deprecated IKEv1 key exchange protocol. By exploiting a logic flaw in certificate validation, an attacker can establish a VPN session without possession of a valid password, effectively bypassing authentication requirements. Additional post-authentication activity is required to access internal resources or escalate privileges. To date, the observed exploitation has been limited to a few dozen targeted organizations globally. One case involved confirmed post-compromise activity associated with Qilin ransomware affiliate. Customers using IKEv1 key […]

The post Security Advisory – Action Required – Active Exploitation of Check Point VPN Authentication Bypass (CVE-2026-50751) appeared first on Check Point Blog.

Meta has revealed that 20,225 Instagram users had their accounts hijacked in a recent incident where attackers used Meta's AI-powered support system to reset passwords. [...]

A new variant of the Gafgyt botnet called C0XMO is targeting DD-WRT router firmware and can move to other device types with various CPU architectures. [...]

The Silent Ransom Group extortion gang is actively targeting U.S. law firms and professional services organizations in social engineering attacks that often lead to data theft within hours of initial contact, according to a new report by cybersecurity firm Mandiant. [...]

Hackers are actively exploiting a critical vulnerability (CVE-2026-3300) in the Everest Forms Pro plugin, which lets them take complete control of a WordPress website. [...]

Oxford University students seeking work will be dismayed to learn that crooks have breached a second external platform provider for the university in as many months. The institution’s CareerConnect platform, provided by Group GTI, was the target of the intrusion, which exposed users’ full names and email addresses. Those who don’t use single sign-on (SSO) had their encrypted passwords leaked, too. CareerConnect forms part of Oxford University’s career services department, supporting students and alumni to find work opportunities. It is available to students, alumni, research staff, and recruiters. The same underlying technology powering the platform, which GTI markets as TargetConnect, is used by other universities in the UK and overseas, according to its website. OxfordUni said the May 28 attack was enabled by a “security vulnerability,” which has since been fixed. GTI has not publicly disclosed the security snafu itself, and did not respond to our requests for more information. The London-based tech company has not confirmed how many individuals were affected by the break-in, nor whether any data was stolen. It has also not explicitly stated which types of individuals were affected, although Oxford’s announcement listed “alumni, research staff, and employer users” as those who had their passwords forcibly reset following the attack. “There is no evidence that course information, uploaded files, appointment information, or financial information were involved in this incident,” the announcement went on to say. “GTI has stated this breach appeared to be focused on gathering credentials which may lead to phishing attempts.” The university did not list current students as among those affected, but told student newspaper Cherwell that names and email addresses might be compromised, and said the attack was entirely separate from the one which hit Instructure’s Canvas last month. Twice bitten Oxford University was just one of the circa 8,800 educational institutions affected by the mega breach at Canvas, a separate platform that’s also relied upon by schools, colleges, and universities. Seemingly timed by ShinyHunters to coincide with exam season, students across multiple countries were left without access to learning materials, tests, and grades at a pivotal time of the year. The scale of the attack was vast, affecting the usernames, email addresses, course names, enrollment information, and messages of up to 275 million students, teachers, and staff. The severity of the situation, coupled with the inopportune timing, led to Instructure “reaching an agreement” with ShinyHunters to prevent the criminal gang from leaking all the data online. In cyberese, this implies Instructure paid the criminals an extortion fee in exchange for their word that they would delete the stolen data. "We received digital confirmation of data destruction (shred logs)," Instructure said, adding "We have been informed that no Instructure customers will be extorted as a result of this incident, publicly or otherwise." ®

Tech giant Toshiba and mega-retailer Muji warned visitors that suspicious sign-in screens popping up on their websites could collect credentials. [...]

CISA warned today that hackers are now actively exploiting a recently patched high-severity SolarWinds Serv-U flaw to crash servers. [...]