Weekly Threat Recap: Defending Against AI-Assisted PLC Attacks, GitLab Compromise, and Stripe API Key Leaks

This week's recap from The Hacker News reads like a checklist of everything that keeps a SOC lead up at night — not because the techniques are exotic, but because they aren't. The theme is uncomfortable: trusted tools turning hostile, old weak spots getting fresh attention, and AI making offensive security work cheaper. Three threads stand out for defenders: AI-assisted attack tooling reaching industrial control systems (PLCs), continued pressure against GitLab instances (both SaaS accounts and self-hosted servers), and Stripe secret keys leaking into code, logs, and public repositories.

None of these require a zero-day. An internet-exposed PLC, a self-hosted GitLab server lagging on patches, and a sk_live_ key committed to a public repo are all solved problems from an attacker's perspective. The asymmetry is getting worse: generative AI collapses the time needed to write protocol-aware attack scripts for OT environments, enumerate CI/CD misconfigurations, and automate credential validation against payment platforms. What used to take a skilled operator days now takes a motivated novice an afternoon.

If you run OT assets, a self-managed GitLab instance, or any payment integration, this week is your forcing function. Let's walk through the three threat threads and what to do about each.

Technical Analysis

1. AI-Powered Attacks Against PLCs

The headline concern is the commoditization of attacks against programmable logic controllers — the devices that run your building automation, manufacturing lines, water treatment, and energy infrastructure. Historically, attacking a PLC required protocol fluency (Modbus/TCP on 502, Siemens S7comm on 102, EtherNet/IP on 44818, DNP3 on 20000) and a meaningful understanding of ladder logic and process control. That expertise barrier is eroding. AI assistants can now generate syntactically correct protocol traffic, fuzzing harnesses, and read/write tooling against these protocols in minutes, and researchers continue to demonstrate proof-of-concept attacks that "sound harder than they actually are."

The defensive reality hasn't changed, but the urgency has:

• Internet-exposed PLCs remain the primary entry point. Search engines like Shodan and Censys continuously index devices answering on ICS ports. If your PLC answers an unauthenticated Modbus function code from the public internet, assume it has already been catalogued.
• The IT/OT boundary is the second path. Compromised engineering workstations, vendor VPN access, and flat network architectures let attackers pivot from a phished laptop to a level-2 control network without touching an exploit.
• AI lowers the skill floor, not the detection surface. Attack traffic still has to cross a wire. Unexpected hosts speaking ICS protocols, function codes outside your baseline (e.g., write commands from an HMI that only ever reads), and new outbound connections from OT segments are all observable — if you're watching.

2. GitLab Attacks

GitLab remains a high-value target because it sits at the intersection of source code, CI/CD secrets, and deployment infrastructure. The recurring attack patterns we see in IR engagements:

• Self-hosted instances lagging on security patches. GitLab ships security releases roughly twice a month; internet-facing instances running outdated versions are routinely enumerated and exploited. This is not a single-CVE story — it's a patch-hygiene story, and unpatched GitLab instances have been a persistent CISA KEV fixture over multiple release cycles.
• Personal access token (PAT) and CI/CD variable theft. Once an attacker lands on a developer box or a runner, GitLab tokens and pipeline variables are the first things harvested. Tokens with api or read_repository scope enable silent source code exfiltration over HTTPS that blends into normal git traffic.
• Abuse of gitlab-rails console on compromised servers. Attackers with host-level access to a self-hosted GitLab server use gitlab-rails console / gitlab-rails runner to reset admin passwords, create backdoor accounts, and mint tokens — activity that never touches the web audit log in an obvious way.
• Malicious packages and poisoned pipelines. The recap's "a package gets installed" framing is apt: dependency confusion and typosquatted packages that execute during npm install / pip install remain a cheap way into build infrastructure.

3. Stripe Secret Key Leaks

Stripe live secret keys (sk_live_...) continue to surface in public GitHub repositories, CI logs, container images, and client-side JavaScript bundles. A leaked live key is not a "potential" incident — it's direct API access to create charges, issue refunds, enumerate customers, and pivot into connected accounts. Stripe does scan for and disable leaked keys found in public GitHub repos, but that safety net does not cover self-hosted GitLab/Gitea instances, paste sites, build artifacts, or log aggregators. Attackers validate keys at scale against the Stripe API (/v1/charges is the classic validation call), and monetization follows within hours of a public leak.

The defensive failure modes are consistent: keys hardcoded in application code, keys echoed into CI job logs, .env files committed to version control, and debug builds shipping secrets to production.

Exploitation Status

All three threads reflect active, in-the-wild attack patterns, not theoretical risk. Internet-exposed ICS devices are continuously scanned and catalogued. GitLab has a documented history of actively exploited vulnerabilities (several appear in CISA's Known Exploited Vulnerabilities catalog across recent release cycles). Stripe key harvesting is a mature, automated ecosystem. No new CVE is named in this week's recap — the story is about exploitation economics, not a single bug.

Detection & Response

The detections below target observable behaviors from each thread: ICS protocol traffic from unexpected hosts, host-level GitLab server abuse, and Stripe key exposure. Tune the ICS rule against your actual engineering workstation list — that scoping is what keeps it out of the disabled-rules graveyard.

---
title: Unexpected Host Initiating ICS Protocol Connection
title_note: Tune the filter to your approved engineering workstations and HMIs
id: 3f8a2b71-9c4d-4e6a-b1f2-8d7c5a9e0123
status: experimental
description: Detects network connections to common ICS/OT protocol ports (Modbus, S7comm, EtherNet/IP, DNP3) from hosts outside an approved engineering allowlist. AI-assisted and commodity PLC attack tooling still has to traverse the network, and unauthorized sources speaking OT protocols are a high-fidelity signal in segmented environments.
references:
  - https://thehackernews.com/2026/08/weekly-recap-ai-powered-plc-attacks.html
  - https://attack.mitre.org/techniques/T0885/
  - https://attack.mitre.org/techniques/T0843/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.ics.t0885
  - attack.ics.t0843
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort:
      - 502
      - 102
      - 44818
      - 20000
  filter_approved_engineering_hosts:
    SourceIp:
      - '10.20.30.0/24'
      - '192.168.50.0/24'
  condition: selection and not 1 of filter_*
falsepositives:
  - Engineering workstations and HMIs not yet added to the allowlist
  - OT asset inventory / vulnerability scanners during approved windows
level: high
---
title: GitLab Rails Console or Runner Execution on Server
id: 7b1c4d92-3e5f-4a8b-9c0d-2f6e8a1b3456
status: experimental
description: Detects execution of gitlab-rails console or gitlab-rails runner on a self-hosted GitLab server. Attackers with host access abuse these to reset admin passwords, create backdoor accounts, and mint personal access tokens without touching the web UI. Legitimate use is rare and typically tied to maintenance windows.
references:
  - https://thehackernews.com/2026/08/weekly-recap-ai-powered-plc-attacks.html
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.execution
  - attack.t1059
  - attack.persistence
  - attack.t1136
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains:
      - 'gitlab-rails console'
      - 'gitlab-rails runner'
      - 'gitlab-psql'
  condition: selection
falsepositives:
  - GitLab administrators during documented maintenance (correlate with change tickets)
  - Omnibus GitLab backup/restore operations
level: high
---
title: Stripe Live Secret Key in Command Line or Script Content
id: 9d2e5f18-4a6b-4c9d-8e1f-3a7b9c2d4567
status: experimental
description: Detects Stripe live secret keys appearing in process command lines or inline scripts. Developers testing against the live API from shells and attackers validating stolen keys both produce this signal. Sk_test keys are excluded to reduce noise from development activity.
references:
  - https://thehackernews.com/2026/08/weekly-recap-ai-powered-plc-attacks.html
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - 'sk_live_'
      - 'rk_live_'
  condition: selection
falsepositives:
  - Developer local testing (which is itself a policy violation worth surfacing)
  - Secret rotation scripts run by platform teams
level: medium

The following Sentinel queries cover the same ground from the analytics side — one for OT protocol exposure via Syslog/CEF-ingested firewall or sensor data, one for GitLab authentication anomalies, and one for Stripe key strings showing up in process telemetry.

// Hunt 1: Hosts talking to ICS/OT protocol ports outside an approved engineering list
// Ingest OT-facing firewall/sensor logs via Syslog or CEF; adjust allowlist to your environment
let ApprovedOTSources = dynamic(["10.20.30.10", "10.20.30.11", "192.168.50.25"]);
let OTDestPorts = dynamic([502, 102, 44818, 20000]);
union isfuzzy=true
    (CommonSecurityLog
     | where DestinationPort in (OTDestPorts)
     | where SourceIP !in (ApprovedOTSources)
     | summarize ConnectionCount = count(), DistinctDests = dcount(DestinationIP)
         by SourceIP, DestinationPort, DeviceAction
     | order by ConnectionCount desc),
    (Syslog
     | where SyslogMessage has_any (":502", ":102", ":44818", ":20000")
     | extend SourceHost = Computer
     | summarize MsgCount = count() by SourceHost, Facility, SeverityLevel
     | order by MsgCount desc);

// Hunt 2: GitLab authentication and access anomalies
// Assumes GitLab audit/auth logs ingested into Syslog or a custom table
Syslog
| where Computer has "gitlab" or SyslogMessage has "gitlab"
| where SyslogMessage has_any ("Failed login", "sign in", "oauth", "personal_access_token", "SSH key")
| parse SyslogMessage with * "from " SrcIP " " *
| summarize Events = count(), DistinctUsers = dcount(extract(@"user[:=] ?([\w.@-]+)", 1, SyslogMessage))
    by Computer, SrcIP, bin(TimeGenerated, 1h)
| where Events > 20 or DistinctUsers > 5
| order by Events desc;

// Hunt 3: Stripe live keys appearing in endpoint process telemetry
DeviceProcessEvents
| where ProcessCommandLine has_any ("sk_live_", "rk_live_")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, ReportId
| order by TimeGenerated desc;

For endpoint and server-side hunting, Velociraptor is effective at finding secrets that never touched a command line — keys sitting in checked-out repos, .env files, and build artifacts on developer workstations and CI runners.

-- Hunt for Stripe live secret keys and GitLab tokens in common file locations
-- Uses YARA content scanning across likely secret-bearing files
LET cred_rule = yara_rule('''
rule stripe_live_key {
  meta:
    description = "Stripe live secret or restricted key in file content"
  strings:
    $a = /sk_live_[0-9A-Za-z]{16,}/
    $b = /rk_live_[0-9A-Za-z]{16,}/
  condition:
    any of them
}
rule gitlab_pat {
  meta:
    description = "GitLab personal access token in file content"
  strings:
    $a = /glpat-[0-9A-Za-z_-]{20,}/
  condition:
    any of them
}
''')

LET targets <= SELECT FullPath
FROM glob(globs=[
  'C:/Users/*/**/.env',
  'C:/Users/*/**/.env.*',
  'C:/Users/*/**/appsettings*.json',
  'C:/Users/*/**/docker-compose*.yml'
])

SELECT FullPath,
       Rule,
       String.Name AS MatchedString,
       String.Data AS MatchContext
FROM yara(files=targets.FullPath, rules=cred_rule, number=20)

The script below gives Linux-based GitLab servers and build runners a quick triage pass: version check, recent gitlab-rails usage, token/SSH key audit trail, and a secrets sweep of checked-out code.

#!/usr/bin/env bash
# Security Arsenal - GitLab server & secrets triage (Omnibus GitLab)
# Run as root on the GitLab host. Read-only; no changes made.

echo "=== [1] GitLab version (compare against https://about.gitlab.com/releases/categories/releases/) ==="
gitlab-rake gitlab:env:info 2>/dev/null | head -5 || cat /opt/gitlab/version-manifest.txt | head -3

echo -e "\n=== [2] Recent gitlab-rails console/runner invocations in shell histories ==="
grep -rEn "gitlab-rails (console|runner)" /root/.bash_history /home/*/.bash_history 2>/dev/null || echo "None found"

echo -e "\n=== [3] Users with recent admin-token or SSH-key changes (last 7 days of audit log) ==="
grep -Ei "(personal_access_token|ssh key|authentication_token|changed_password)" \
  /var/log/gitlab/gitlab-rails/audit_json.log 2>/dev/null | tail -40 || echo "audit_json.log not found"

echo -e "\n=== [4] Stripe live keys / GitLab PATs in web root and repo checkouts ==="
grep -rEl --exclude-dir={node_modules,.git,log,tmp} \
  -e "sk_live_[0-9A-Za-z]{16,}" -e "rk_live_[0-9A-Za-z]{16,}" -e "glpat-[0-9A-Za-z_-]{20,}" \
  /var/www /srv /home /opt 2>/dev/null | head -50 || echo "None found"

echo -e "\n=== [5] Internet-facing ICS ports listening on this host (should be NONE on IT systems) ==="
ss -lntup 2>/dev/null | grep -E ":(502|102|44818|20000)\b" || echo "No ICS protocol listeners"

echo -e "\nTriage complete. Review output and escalate any hits to IR."

Remediation

Industrial / PLC environments:

1. Remove PLCs from the public internet — full stop. Audit your external IP space against Shodan/Censys for your ASN and domains. Anything answering on 502, 102, 44818, or 20000 from the internet is an incident, not a finding. Vendor remote access belongs behind a brokered jump host with MFA and session recording, not port-forwarded.
2. Enforce the IT/OT boundary. Segment per IEC 62443 zones/conduits; deny ICS protocols at the boundary except from an explicitly allowlisted set of engineering workstations and HMIs. Deploy the Sigma rule above against your allowlist — unapproved sources speaking OT protocols is one of the highest-fidelity alerts an OT SOC can produce.
3. Baseline and alert on function codes. A historian that only ever issues read commands issuing a write/program-download is an immediate investigation trigger, regardless of source.
4. Assume AI-assisted adversaries. The expertise barrier is gone; your defense cannot rely on protocol obscurity. Unauthenticated Modbus was never a security control — now it isn't even a speed bump.

GitLab (self-hosted and SaaS):

1. Patch to the latest GitLab security release now. GitLab publishes security releases with CVE details roughly twice a month; review the current release notes at https://about.gitlab.com/releases/categories/releases/ and upgrade self-hosted instances on a defined SLA (treat criticals as 72-hour items). Subscribe to the GitLab security release notifications.
2. Audit tokens and keys. Rotate personal access tokens and deploy keys older than 90 days; enforce token expiration instance-wide (Admin → Settings → Access token expiration). Review CI/CD variables for masking and protection, and scope runner registration tokens down.
3. Alert on gitlab-rails console/runner usage (Sigma rule above) and review audit_json.log for admin user creation, password resets, and token generation outside change windows.
4. Gate package installation in CI. Pin dependencies by hash, run private registries/proxies, and block postinstall script execution on untrusted packages to blunt dependency-confusion and install-time malware.

Stripe key exposure:

1. Search and destroy. Run secret scanning (gitleaks, trufflehog, GitHub/GitLab native scanning) across all repositories including history, CI logs, container images, and artifact stores for sk_live_ / rk_live_ patterns.
2. Roll any exposed key immediately in the Stripe Dashboard (Developers → API keys → Roll key). Assume any key found in a repo, log, or client-side bundle is compromised; Stripe's automatic revocation only covers public GitHub leaks.
3. Move to restricted keys (rk_live_) with least-privilege permissions per service, store secrets in a vault or the platform's secret manager, and inject at runtime — never via committed .env files.
4. Prevent recurrence with pre-commit hooks and CI-stage secret scanning as merge-blocking gates. A key caught at commit time costs nothing; a key caught by a fraudster costs a fraud investigation.

Executive Takeaways

• The expertise moat around OT attacks is gone. If your segmentation strategy assumed attackers couldn't speak Modbus, rebuild that assumption this quarter.
• Self-hosted GitLab is production internet-facing infrastructure — manage its patching with the same rigor as your VPN and email gateways, and monitor host-level abuse (gitlab-rails console) in addition to web logs.
• Secrets are a pipeline problem, not a developer problem. Scanning at commit and build time is the only control that scales; cleanup after exposure is always more expensive than prevention.
• The common denominator is visibility. Every attack path described this week crosses an observable boundary — a port, a process, a token string. Instrument the boundaries and the attacks announce themselves.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub