Breached by AI, Defended by AI, and Human Error Opens the Holes (February 2026 Security Roundup)
Contents
Four separate incidents in the same week captured where cybersecurity stands today.
An AI-assisted FortiGate intrusion campaign that automatically scanned over 2,500 targets across 106 countries using DeepSeek and Claude; Starkiller, a phishing service that proxies real login pages and still steals sessions even after MFA; reports that AI found more than 500 vulnerabilities long overlooked in production OSS; and PayPal unintentionally exposing SSNs for six months due to a coding error. Each is independent, yet their arrival in one week is telling.
AI-Powered Offense: FortiGate Scans in 106 Countries and Compromises
Campaign overview
From January 11 to February 18, 2026, a Russian-speaking, financially motivated group leveraged multiple commercial AI services to compromise more than 600 FortiGate devices across 55 countries, according to Amazon Threat Intelligence.
Notably, the campaign did not exploit a new FortiGate zero-day. The attackers went after classic misconfiguration. They automatically scanned externally exposed management interfaces on ports 443, 8443, 10443, and 4443, then attempted logins with weak single-factor credentials. No new CVE or sophisticated exploit was required: “management ports exposed to the internet” plus “weak passwords” was enough to seize control of 600+ devices.
AI used and automation stack
Amazon Threat Intelligence rates the operators as having “limited technical skills.” Even so, they achieved scale by leaning on multiple commercial generative AI services.
AI services identified in the operation:
- DeepSeek: Used to generate attack plans. A script named
deepseek_attack_plan.pywas observed. - Claude: Used to prepare vulnerability assessment reports and autonomously run Impacket, Metasploit, and hashcat.
Custom tooling was also built to scale the operation:
- ARXON: A custom MCP server that ingests scan results and calls DeepSeek to generate attack plans—the “bridge” between AI and hacking tools.
- CHECKER2: A Go-based Docker orchestrator capable of scanning 2,516 targets across 106 countries in parallel, automating Nuclei templates and BloodHound reconnaissance.
By December 2025, the scanning server also showed traces of a framework called HexStrike AI.
Code analysis revealed hallmarks of AI-generated code: “overly verbose comments,” “simplistic architecture,” “string-matching for JSON parsing instead of proper deserialization,” and “polyfill-like shims for built-ins with empty doc stubs.” These are typical of code produced by novices relying heavily on AI.
Amazon Threat Intelligence called this an “AI-powered assembly line for cybercrime.” What previously demanded a seasoned, large team is now feasible for a small crew augmented by AI. For another example of AI agents embedded in attack infrastructure, see the article on AI memory-injection attacks and automated smart-contract exploitation.
Post-compromise steps: staging for ransomware
After establishing initial access, the operators executed a multi-stage rollout.
Credential/config theft from FortiGate
Used a read-only account Technical_support to take full backups. Decrypted LDAP bind passwords via CVE-2019-6693 and established FortiSSL VPN to gain a foothold inside the network.
Domain-wide lateral movement
Used DCSync to collect credentials from Active Directory, then moved laterally via pass-the-hash and pass-the-ticket.
Targeting backups and storage
Exploited CVE-2023-27532 and CVE-2024-40711 (both Veeam) against backup infrastructure. QNAP NAS and Veeam servers were targeted—likely staging to destroy or encrypt backups before deploying ransomware.
Impacts spanned South Asia, Latin America, the Caribbean, West Africa, Northern Europe, and Southeast Asia—a truly global spread.
IOCs and recommended actions
Observed IOCs:
| Indicator | Details |
|---|---|
| Scan source IP | 212.11.64.250 |
| Scanning server | 185.196.11.225 (Kali Linux) |
| AS | AS4264 Global-Data System IT Corporation (Zurich) |
Recommended actions:
| Action | Priority |
|---|---|
| Remove management interfaces from the public internet | Highest |
| Enforce multi-factor authentication on admin consoles | Highest |
| Patch Veeam and isolate it from general networks | High |
| Rotate SSL-VPN credentials | High |
| Restrict access to QNAP NAS | High |
| Add detections for DCSync and pass-the-hash | Medium |
The only entry point here was “exposed management ports.” Limiting management access to internal networks or VPN would have blocked most of this campaign. And it’s not just FortiGate—active exploitation of known flaws in network gear remains widespread, as covered in the CISA KEV additions roundup.
Reference: Amazon Threat Intelligence report (via The Hacker News)
Starkiller Phishing: Reverse-proxying real pages to intercept MFA tokens
How it fundamentally differs from classic phishing
Run by Jinkusu, Starkiller is a reverse-proxy PhaaS (Phishing as a Service). Unlike conventional phishing kits that host a static, fake login page “made to look real,” Starkiller’s architecture is different.
Classic kits had two weaknesses: their UIs drifted from the real sites after design updates, and static phishing pages could be fingerprinted by researchers and taken down. Starkiller’s design sidesteps both.
How it works: template-less, real-time proxy
In the backend, Starkiller uses a headless Chrome browser inside Docker to load the actual login page. It acts as a man-in-the-middle reverse proxy through attacker-controlled infrastructure, so victims see the genuine page.
Crucially, it’s “template-less.” There’s no static fake template; the live site is proxied as-is. That makes fingerprinting and blocklists far less effective: because the content originates from the real site, traditional detectors have little to latch onto.
To disguise URLs, it uses a familiar trick:
login.microsoft.com@evil-site.example.com/pathText before @ is ignored by browser URL parsers. The actual landing domain is evil-site.example.com, but many users are fooled by the visible login.microsoft.com string.
Bypassing MFA and real-time monitoring
Starkiller’s biggest threat is the practical nullification of MFA.
When a user enters an SMS or authenticator-app one-time code, the code is forwarded in real time to the legitimate site. Authentication succeeds, but the attacker has already intercepted the session cookie. Using that cookie, they gain independent access to the victim’s account.
Even when users complete MFA correctly, they can still be compromised. Hardware-key authentication such as FIDO2/WebAuthn is an effective countermeasure against this class of attack.
Beyond credential theft, Starkiller offers:
- Real-time session viewing: Operators can live-stream the victim’s browser session.
- Keylogger: Records all keystrokes.
- Geo-tracking: Captures a target’s location.
- Telegram integration: Auto-notifies operators when new credentials arrive.
Operations by “Jinkusu”
Starkiller is sold as PhaaS and built for low-skilled operators. Attackers pick a brand from a dropdown (Apple, Google, Microsoft, and others), generate a spoofed URL, and launch.
The operation is run like a commercial SaaS: community forum, monthly updates, and support via Telegram.
Mitigations
For end users
- Check URLs carefully (confirm the domain after
@is legitimate). - Use FIDO2/WebAuthn hardware security keys (e.g., YubiKey).
- Migrate to passkeys.
For organizations
- Enforce phishing-resistant MFA (mandate FIDO2/SAML/WebAuthn).
- Conditional Access Policies (extra checks for unknown devices/IPs).
- Risk-based authentication (detect anomalous session patterns).
Because it’s template-less, tools tuned for static phishing detection are ineffective against reverse-proxy kits like this. We need to rethink our phishing defenses. For how developer tooling itself can expand your attack surface, see the article on Chrome DevTools and VS Code Copilot vulnerabilities.
Reference: Krebs on Security - Starkiller Phishing Service
Claude Code Security: AI vulnerability detection beyond static analysis
While attackers use AI to close skill gaps, defenders are also deploying AI in production.
Anthropic released Claude Code Security (security features integrated into Claude Code Web) as a limited research preview. It’s powered by Claude Opus 4.6 and available to Enterprise and Team plans. See the Claude Code Security deep-dive for a detailed technical look.
How it differs from existing tools
Existing vulnerability tools fall into two broad camps: pattern-matching (Semgrep, CodeQL) and dependency scanning (Snyk).
| Tool | Strengths | Weaknesses |
|---|---|---|
| Semgrep/CodeQL | Matching known patterns | New patterns beyond rules |
| Snyk | Known-CVE dependencies | App-specific logic flaws |
| Claude Code Security | Business-logic and multi-step issues | Cost at large codebases |
Claude Code Security focuses on “business-logic defects,” such as access-control gaps that require application context to spot—problems that regex/AST-based tools struggle with by design.
Because it’s LLM-based, it can track interactions and data flows across components and flag vulnerabilities that only emerge over multiple steps.
500+ findings in production OSS
Anthropic reports testing on production open-source repositories and discovering 500+ vulnerabilities—issues that had survived expert review and, in some cases, been overlooked for decades.
Independent verification is pending, but the “overlooked for decades” claim is suggestive: it implies traditional tools inherently miss a class of business-logic bugs.
Patch suggestions and dashboard
It can propose concrete code patches, but human review is required. The design explicitly keeps a “human-in-the-loop”—the AI does not auto-edit production code.
From the “Claude Code Security Dashboard,” teams can review findings, patch suggestions, and approvals, with severity and confidence scoring to aid prioritization.
Open-source maintainers can request priority free access at claude.com/contact-sales/security. If many OSS projects indeed harbor “decades-old misses,” prioritizing this access makes sense.
In practice, a layered approach works: use Semgrep to net known patterns and add Claude Code Security for logic flaws. Also note that AI development tools themselves are becoming supply-chain targets—see the Clinejection analysis and the npm supply-chain worm article.
Original post: Making frontier cybersecurity capabilities available to defenders
PayPal Working Capital: a coding mistake exposed ~100 SSNs for six months
Even as AI starts to help defenders, the week also brought a reminder that human development errors can still create severe vulnerabilities.
On February 20, 2026, PayPal disclosed that a code error in its small-business loan service “PayPal Working Capital (PPWC)” left personal information for around 100 customers accessible to unauthorized parties for roughly six months. A data breach notification was filed with the Massachusetts Attorney General. This was not an external cyberattack; it stemmed from PayPal’s own software development mistake.
Timeline
| Date | Event |
|---|---|
| Around July 1, 2025 | The problematic code change was deployed to production |
| December 12, 2025 | PayPal detected the issue |
| December 13, 2025 | Rolled back the code and blocked access |
| February 10, 2026 | Formal breach notices sent to affected customers |
Roughly two months elapsed between discovery and customer notification. PayPal states the delay was not due to a law-enforcement hold; it reflects internal investigation and legal review.
Exposed data and real-world impact
Information that became viewable by unauthorized parties:
- Full name, email address, phone number, and business address
- Social Security Number (SSN)
- Date of birth
In the U.S., the SSN + date-of-birth combination is sufficient for identity theft, account opening, and targeted social engineering. The risk has a long tail.
A small number of customers did suffer fraudulent transactions, which PayPal reports it has refunded. PayPal confirmed about 100 affected individuals.
Technical background
PPWC lets business owners obtain financing against sales history, and the application flow necessarily processes sensitive PII. A code change deployed around July 1, 2025 exposed PII to parties without proper authorization.
PayPal has not disclosed specific mechanics (e.g., whether this was an auth bypass, access-control misconfiguration, or missing data masking).
PayPal’s response
- Rolled back the code change (the day after detection)
- Forced password resets on affected accounts
- Refunded/compensated customers with confirmed fraud
- Offered two years of three-bureau credit monitoring and identity-restoration services via Equifax (enrollment deadline: June 30, 2026)
PayPal previously faced a credential-stuffing incident in December 2022 that affected ~35,000 accounts. While different in nature (external vs internal code error), the recurrence stands out.
Original report: PayPal discloses data breach that exposed user info for 6 months
Since February began, reports on the widening attack surface have been piling up: the Dell RecoverPoint zero-day, attack surface expansion via developer tools, AI agent memory-injection attacks, and the npm supply-chain worm. The most actionable first steps: stop exposing management ports to the internet and move to phishing-resistant MFA.