InfoSec Briefing - September 08, 2026

🎧 Audio Briefing

Playback Speed:

Security news from the BlueTeamSec community for Tuesday the 8th of September 2026. Seven stories today, and three of them involve AI writing malware or patches — which is either the future or a cautionary tale, depending on how today goes for you.

CERT Polska disclosed six vulnerabilities in MikroTik RouterOS, including the MikroTrick chain that allows attackers to bypass SSH authentication and escalate privileges to full admin. Active exploitation has been observed since the 2nd of September from two specific IPs, so if you're running MikroTik boxes exposed to the internet, this is one to action immediately.

JetBrains disclosed that their Cadence service was breached between the 8th and 24th of August through an unpatched TeamCity vulnerability. We covered that same TeamCity RCE back on the 1st of September — this time attackers made off with user data, source code, credentials, AWS secrets, and a full server backup from 2024. The service is now offline.

Genians have a write-up on how North Korean group Kimsuky has integrated the AI coding agent called opencode into their GitHub-based campaign. They're using it alongside headless Chrome automation to mass-produce phishing decoys at scale — though the quality control has suffered, with placeholders sometimes left unreplaced in the output. We've seen Kimsuky's GitHub infrastructure evolve over the last week or so; this is the latest iteration.

NetAskari uncovered something called Robobox — an infrastructure where a large language model autonomously developed and deployed malware targeting Chinese users via fake software updates. The AI built its own custom command-and-control framework for iOS, a Windows remote access tool with strong encryption, and integrated Cobalt Strike components, all with minimal human oversight. Not unlike the Mythic generator tool we covered on the 6th, but this one appears to have been genuinely self-driven.

On the other end of the AI spectrum, 1Password's Off-by-1 Labs tested several frontier AI coding models against real-world vulnerabilities and found they consistently failed to produce secure patches. Around 40 percent of the patches contained implementation flaws in complex scenarios — they'd leave the original vulnerability unaddressed, introduce new issues, or miss the root cause entirely. This follows a similar piece we covered on the 7th about using AI to reverse-engineer patches; worth reading if you're evaluating AI-assisted security workflows.

Two articles today on abusing signed vulnerable drivers. Researchers have documented a pattern called Bring Your Own Trusted Caller, where attackers compromise legitimately signed processes through DLL injection or similar techniques to inherit trusted status, then use that to bypass kernel security controls in drivers from vendors like Malwarebytes and System Informer. And separately, there's a new tool called 0xM0nCrush that exploits a signed driver from HONOR to terminate protected processes on Windows 10 and 11, bypassing Protected Process Light protections. We've seen a few similar tools over the last week; this continues to be a reliable technique.

And that's your lot for today. As always, the original articles are the work of their authors — the analysis here was automated.

📰 Articles Covered

Critical vulnerabilities in MikroTik RouterOS are being actively exploited. Immediate update recommended - CERT Polska

This precis summarizes the findings from CERT Polska regarding the "MikroTrick" vulnerability chain and associated flaws impacting MikroTik RouterOS devices.

### What Happened
CERT Polska has uncovered six security vulnerabilities in MikroTik RouterOS. Most notably, a chain of two critical vulnerabilities—dubbed **"MikroTrick"**—is being actively exploited in the wild. Attackers have been observed targeting internet-facing MikroTik devices since at least September 2, 2026, using the exploit to gain full, unauthorized administrative control over the hardware 【1】.

### Who is Affected
Devices running vulnerable versions of RouterOS are at risk, particularly those with management or diagnostic interfaces exposed to the public internet. The specific services identified as high-risk include:
* **SSH** (used for the primary exploitation vector)
* **Bandwidth-test**
* **WebFig** (WWW/WWW-SSL)
* **X.509 certificate handling**

### Security Implications
* **Complete System Compromise:** Successful exploitation allows attackers to bypass authentication and gain full administrative privileges.
* **Persistence:** Once inside, attackers create a highly privileged user account named `ops` to maintain persistent access.
* **Active Threat:** Attacks have been traced to specific IP addresses (`82.192.72.4` and `103.102.31.18`), confirming that the exploit is actively used in real-world attacks.

### Technical Details
The security flaws center on a combination of vulnerabilities that facilitate unauthorized access and privilege escalation:
* **MikroTrick Chain:** A two-part exploit sequence enabling full administrative access.
* **Key Vulnerabilities:**
* **CVE-2026-67276 (CVSS 9.2):** An SSH authentication bypass resulting from improper public key verification.
* **CVE-2026-86060 (CVSS 9.2):** A privilege escalation vulnerability triggered by specially crafted usernames via SSH.
* **CVE-2026-67277 (CVSS 8.8):** A flaw in the bandwidth-test service that leads to memory disclosure and potential system crashes.

### Defender Guidance
Administrators are advised to prioritize the following actions:

| Action Category | Recommended Steps |
| :--- | :--- |
| **Patching** | Upgrade immediately to **7.25beta3, 7.24.2, 7.23.4, or 6.49.21**. |
| **Detection** | Scan logs for `"login failure for user -2"`, check for the unauthorized `ops` account, and review the `Flagged` system marker using `/system/device-mode/print`. |
| **Containment** | If immediate patching is not possible, disable exposed services (SSH, WWW/WWW-SSL, bandwidth-test) or restrict access to trusted IP addresses only. |
| **Response** | If a compromise is confirmed: isolate the device, secure logs, perform a full factory reset, and reconfigure from scratch. **Do not** use backups taken while the device was potentially compromised. |
Security Incident Affecting JetBrains Cadence - The JetBrains Blog - JetBrains s.r.o.

This security incident involved a breach of the **JetBrains Cadence** service, which integrates with PyCharm to enable cloud-based project execution. Following an investigation, it was determined that the service was exploited by a threat actor between August 8, 2026, and August 24, 2026 【1】.

### What Happened
The Cadence server (`api.cadence.jetbrains.com`) was compromised due to an unpatched vulnerability in JetBrains TeamCity, which the service uses for workload orchestration 【1】. Although a fix for this vulnerability (CVE-2026-63077) had been previously disclosed, the Cadence server was not patched 【1】. JetBrains discovered the exploitation on August 23 and took the server offline on August 24, 2026 【1】.

### Who Is Affected
Current Cadence users are affected. Impacted data includes user personal information (usernames, real names, email addresses, login timestamps, and IP addresses) and potentially project source code or credentials synchronized to the service 【1】.

### Security Implications
* **Data Exposure:** Threat actors accessed personal data and a full server backup from 2024, which may contain sensitive credentials and configuration artifacts 【1】.
* **Credential Compromise:** Multiple AWS IAM users and associated secrets were accessed. Furthermore, any credentials or secrets stored in Cadence or used during project executions must be considered compromised 【1】.
* **Source Code Integrity:** Because attackers accessed the server, any source code uploaded or synchronized to the environment should be treated as untrusted and potentially modified 【1】.

### Technical Details
* **Vulnerability:** The breach exploited **CVE-2026-63077**, a critical TeamCity vulnerability that allows unauthenticated attackers to execute arbitrary commands 【1】.
* **Indicators of Compromise (IoCs):** Activity from August 8, 2026, onwards is suspect. Known malicious IP addresses include `150.109.230.104`, `43.153.227.206`, `62.210.127.48`, `210.247.242.190`, `15.235.225.205`, and `152.233.30.18` 【1】.

### What Defenders Should Know
Defenders and affected users are advised to take the following immediate actions:
* **Revoke and Rotate:** Immediately rotate all credentials used with Cadence, including cloud (AWS, Azure, GCP), source control (GitHub, GitLab), and package registry credentials 【1】.
* **Audit Systems:** Review AWS accounts, S3 buckets, and CI/CD pipelines for any signs of unauthorized access or changes during the affected window 【1】.
* **Verify Code:** Audit repositories for unauthorized commits or changes made during the incident period 【1】.
Kimsuky Uses the AI Agent 'opencode' to Create Decoys as Its GitHub PAT-Based LNK Attacks Evolve - Genians

The provided summary details a recent evolution in the Kimsuky threat actor group's "Operation GitPower" campaign, specifically highlighting how they have integrated AI-driven tools to scale their malicious activities.

### Detailed Precis

**What Happened**
The Kimsuky group has updated its operational tactics to leverage AI for the mass production of malicious decoy documents. While maintaining their signature GitHub-based command-and-control (C2) infrastructure, they are now using the terminal-based AI coding agent "opencode" and Headless Chrome browser automation to create varied lures. This automation has led to instances where placeholders remain unreplaced in decoy files, suggesting a shift toward high-volume, automated production over meticulous manual review.

**Who is Affected**
The campaign primarily targets individuals in the financial and corporate sectors. While there is a strong focus on domestic (Korean) entities, the inclusion of international themes indicates that the threat actor is simultaneously targeting global users.

**Security Implications**
The integration of AI into their workflow allows Kimsuky to rapidly iterate and scale their phishing lures. The combination of sophisticated, AI-generated lures and established, resilient C2 infrastructure significantly lowers the barrier for these attackers to maintain persistent access and exfiltrate sensitive data from targeted environments.

**Technical Details**
* **Initial Access & Execution:** Attackers distribute ZIP archives containing malicious LNK files masked as legitimate business documents.
* **Obfuscation & Evasion:**
* **LNK Tactics:** Use of excessively long command-line arguments, leading spaces, and file size padding to bypass static analysis.
* **Environment Awareness:** Malware variants are designed to detect security research tools (such as Procmon or x64dbg) and specific sandbox usernames (e.g., "Bruno"), responding by deleting command histories.
* **Infrastructure:** They rely heavily on GitHub (using hardcoded Personal Access Tokens) and have increasingly utilized Pastebin as a secondary channel for payload delivery.
* **Persistence:** Malicious activity is established via hidden scheduled tasks, which are often named to mimic legitimate system processes like "BitLocker" or "MATLAB."

**What Defenders Should Know**
Defenders must transition away from relying on document content analysis, as the quality and variety of AI-generated lures have increased. Effective detection requires a focus on behavioral patterns across the entire attack chain:

* **Suspicious Execution:** Monitor for LNK file execution followed immediately by PowerShell processes involving abnormally long, obfuscated command-line arguments.
* **Network Activity:** Flag unauthorized or anomalous access to `raw.githubusercontent.com` and `pastebin.com/raw/`.
* **System Integrity:** Routinely audit scheduled tasks for hidden entries, especially those with names slightly resembling standard system processes.
* **EDR Utilization:** Security teams should leverage EDR platforms to correlate these events into a single attack storyline, enabling faster identification and blocking of the sequence from extraction to C2 communication.
Robobox: Self driven malware creation and execution - made in China - NetAskari

The article details the discovery of a "Robobox," an infrastructure that appears to be operated by a Large Language Model (LLM) to perform autonomous malware development, reconnaissance, and attack operations.

### What Happened
Researchers identified a server instance exhibiting behavior characteristic of an AI agent. Instead of manual operation, the environment showed signs of being autonomously managed, as evidenced by a `bash_history` file filled with erratic, self-correcting commands, repeated file deletion/execution cycles, and automated workflows. The agent appears to have used baseline data (such as public repositories and technical analysis reports) to develop and deploy malicious components with minimal human intervention.

### Who Is Affected
The infrastructure is specifically targeted at mainland Chinese users. The primary vector identified is a malicious, fake update for the popular Chinese input method software, **Sogou Pinyin** (搜狗输入法).

### Technical Details
The Robobox environment included several sophisticated and AI-generated components:
* **AI-Generated C2 Framework:** A dashboard for tracking compromised iOS devices (collecting data like SMS, photos, and crypto wallets), featuring a React/Vite front-end and a NodeJS back-end created by an AI.
* **AI-Generated RAT:** A Win64 binary (`agent`) disguised as `WinPerfDiagSvc`. It features custom AES-256-GCM encryption, establishes persistence via `crontab`, and provides a reverse shell.
* **Additional Malware:** The setup included a Cobalt Strike team server, Npcap for network sniffing, and a malicious update chain that delivers `ImageMagik.dll` and `SGWangzaix.exe`.
* **Automation:** The system displayed a highly automated, "vibe-coded" workflow that included system setup, compilation, and the deployment of staged exploit chains.

### Security Implications
This incident demonstrates the shift toward "self-driven" malware development. It highlights that LLMs can now be utilized to bridge the gap from concept to deployment by rapidly consuming existing technical documentation and source code to build functional, though sometimes erratic, attack environments. While these AI-driven pipelines may currently exhibit logical errors or "erratic" behavior, they represent a significant step in the automation of cyber threats.

### What Defenders Should Know
Defenders should be aware of the following indicators of AI-driven/autonomous operation:
* **Erratic Command Patterns:** Look for repetitive, self-correcting shell commands and "typo loops" in system logs that do not match standard human operator behavior.
* **Automated Cycles:** Pay attention to highly repetitive execution, setup, and cleanup cycles that suggest an automated agent rather than a human user.
* **Code Characteristics:** AI-generated malware may exhibit a mix of sophisticated implementation (like custom crypto) alongside "vibe-coded" logic errors or suboptimal structures.
* **Monitoring Targets:** Be vigilant for suspicious updates to legitimate local software, particularly in regions where specific applications (like Sogou Pinyin in China) are heavily utilized as lures.
Bring Your Own Trusted Caller (BYOTC): A New Way to Exploit Vulnerable Windows Drivers (Part 1) - Xusheng Li

The article "Bring Your Own Trusted Caller" (BYOTC) highlights a critical vulnerability pattern where attackers bypass kernel-mode security by exploiting the user-mode applications that privileged drivers already trust.

### Executive Summary
BYOTC is a form of the "confused-deputy" problem occurring at the user-kernel interface. Instead of attempting to exploit a vulnerability in the kernel driver directly—which is often hardened—an attacker targets the user-mode client that the driver has been configured to trust. By compromising this client (via code injection or process manipulation), the attacker inherits the client's authority, effectively using the driver as a proxy to perform unauthorized, privileged operations, such as killing security software or modifying system integrity.

### Affected Software and Vulnerability Mechanisms
The research identified two primary examples where this trust relationship was abused:

* **Malwarebytes (`mbamchameleon.sys`):** The driver's trust model was overly simplistic, relying exclusively on an initial check of a process's digital signature to determine its "trusted" status. An attacker could exploit this by injecting a malicious DLL into a legitimately signed Malwarebytes process, causing the driver to treat the compromised process—and thus the attacker’s code—as a trusted entity.
* **System Informer (`SystemInformer.sys`):** This instance demonstrated a more complex flaw involving initialization logic. Despite rigorous integrity checks, the driver permitted an "evil parent" process to maintain control over a child process during its creation. An attacker could spawn and tamper with the child process during its startup phase, successfully bypassing security checks to elevate the process’s trust level to the maximum.

### Security Implications
This pattern invalidates the assumption that a process’s initial digital signature is a proxy for its ongoing runtime integrity. Once a driver grants trust to a user-mode process, any vulnerability within that client—such as susceptibility to DLL injection or process hollowing—becomes a functional gateway into the kernel. This allows attackers to bypass endpoint security measures, disable defensive tools, or escalate privileges from a user-mode context.

### Technical Remediation
The article details specific approaches to closing these trust gaps:
* **Signature Reliance:** Shifting away from static signature verification to runtime-focused integrity checks.
* **Creator Exceptions:** Developers must eliminate "creator exceptions" where parent processes retain control over the initialization of privileged children.
* **Secure Chain of Trust:** Drivers should ideally require that trusted clients be rooted in a Trusted Computing Base (TCB) process, such as `services.exe`, ensuring a verifiable and secure creation chain.
* **State Persistence:** Once a security violation or integrity failure is detected, the trust state must be "sticky" and irreversible, preventing an attacker from attempting to reset or re-authorize the process.

### Recommendations for Defenders
* **For Developers:** Do not rely on simple signer checks. Where possible, utilize Protected Process Light (PPL) to isolate trusted clients. If PPL is not an option, ensure that your design mandates continuous integrity verification that cannot be manipulated once a process has been launched.
* **For Security Auditors:** When assessing driver security, evaluate the entire trust-transition logic rather than just the kernel interface. Specifically, analyze how a driver identifies its "trusted" clients and determine if an attacker can exert control over those clients through common techniques like process injection or parental tampering.
0xM0nCrush: Kernel-mode process terminator using a signed BYOVD driver. Works on all Windows 10/11. No offsets, no PDB. Rust. - DeathShotXD

This precis summarizes the capabilities and security risks associated with the **0xM0nCrush** tool as described in the provided repository documentation.

### Overview
0xM0nCrush is a research-oriented utility designed to terminate Windows processes from the kernel level. It achieves this by weaponizing a signed, vulnerable kernel driver—`MonProcessEX.sys`—which originates from HONOR. Because the driver is digitally signed and currently absent from Microsoft’s default vulnerable-driver blocklists, the tool can execute with high privilege on fully updated Windows systems.

### Technical Details
* **Mechanism:** The tool registers the `MonProcessEX.sys` driver via the Windows Service Control Manager (SCM). It then communicates with the driver using IOCTL `0x22400C` to perform process termination by PID from kernel mode.
* **Version Compatibility:** By performing process lookups and terminations via standard kernel-mode paths rather than relying on hardcoded build-specific offsets, it maintains compatibility across all versions of Windows 10 and 11.
* **Stealth Features:** The tool is designed to be transient; it stops the service and deletes the driver immediately after operation. It also includes anti-analysis techniques such as environment checks (detecting VMs/debuggers), mutex-based single-instance enforcement, obfuscated device paths, and self-destruct functionality to clear its own executable and Prefetch artifacts.
* **Bypasses:** The kernel-level execution path enables the tool to bypass Protected Process Light (PPL) protections that would normally prevent unauthorized termination of security-sensitive processes.

### Security Implications
* **Vulnerable Driver Abuse:** This tool highlights the continued risk posed by "Bring Your Own Vulnerable Driver" (BYOVD) attacks. By using a legitimate, signed driver, attackers can bypass code-signing requirements and gain kernel-level execution.
* **Malicious Potential:** Although intended for authorized testing, the mechanism provides an effective template for adversaries to disable critical security infrastructure. It is specifically capable of terminating EDR agents, antivirus solutions, and Windows Defender.

### Affected Systems
* All current Windows 10 and Windows 11 builds are susceptible, as the underlying vulnerability relies on a signed driver not yet blocked by Microsoft's active enforcement policies.

### Defender Advice
* **Driver Blocklisting:** Organizations should prioritize keeping driver blocklists updated. Ensure that Microsoft's Vulnerable Driver Blocklist and Hypervisor-Protected Code Integrity (HVCI/Memory Integrity) are strictly enforced to mitigate the loading of known vulnerable drivers.
* **Monitoring & Behavioral Analysis:** Defenders should configure SIEM/EDR solutions to alert on the installation of unrecognized kernel services or the loading of `MonProcessEX.sys`.
* **Incident Response:** Any unexplained termination of high-privilege processes—especially security agents—should be treated as a critical indicator of compromise (IOC) and investigated as a potential kernel-level breach.
Frontier Models’ Vulnerability Patches are Often F.L.A.W.E.D. - Fix-Like Artifacts With Embedded Defects: Common failure modes of LLM-generated security patches - 1password.com

This report, titled *Frontier Models' Vulnerability Patches are Often F.L.A.W.E.D.*, was published by 1Password’s Off-by-1 Labs in July 2026. It presents a critical analysis of the capability of frontier AI coding models to autonomously generate secure patches for real-world software vulnerabilities 【1】.

### What Happened
The researchers tested frontier AI coding models against six real-world, high-impact security vulnerabilities. To facilitate this testing, they utilized *Claude Code* to develop "FLAWED," an application that orchestrates an arbitrary number of LLM patch attempts against a codebase 【1】. The study found that these models consistently struggled to produce complete, secure, and functional patches, often leaving vulnerabilities unaddressed or introducing new issues 【2】.

### Who is Affected
The findings impact software developers, security teams, and organizations that integrate AI-assisted coding tools or automated vulnerability remediation into their CI/CD pipelines. As LLMs become integrated into security workflows, the reliance on AI for patching could lead to a false sense of security regarding the actual remediation of critical bugs 【1】.

### Security Implications
The primary implication is that **AI-generated patches are not always reliable.** Even when a patch appears to fix a specific bug, it may fail to address the root cause or introduce fragile implementation errors. The report highlights that relying on AI for "one-click" security fixes without rigorous human verification creates significant risk, as flawed patches can leave production environments vulnerable to exploitation 【1】.

### Technical Details
* **Patch Failure Patterns:** In scenarios involving complex memory management, models often correctly identified the first pointer issue but failed to address subsequent, related issues.
* **Implementation Flaws:** When attempting to use complex patterns (like reference counting), a significant percentage of non-cheat patches (roughly 40% depending on the model) incorrectly omitted necessary components, such as local `scoped_refptr`, instead opting to use the context as a raw pointer inside a callback. This leads to dangerous memory safety issues 【1】.

### What Defenders Should Know
* **Mandatory Verification:** AI-generated code, especially security-critical patches, must undergo strict manual code review and automated testing.
* **Do Not Trust Defaults:** Security teams should treat AI-suggested patches as "drafts" rather than final solutions.
* **Contextual Awareness:** The study suggests that "LLM-patchability" varies significantly depending on the codebase's architecture. Defenders should test their own environments to understand where AI assistance is likely to fail in their specific stack.
* **Tooling Limitations:** Current AI tools struggle with invariants and deep architectural requirements in complex codebases; they are better suited for simple syntax fixes than complex logic remediation 【1】.