The Weekly KEV & Hunt Pack

ARARA Message breach: 81 million email addresses taken from Japanese email-delivery service

What happened

Paycloud Holdings' subsidiary ARARA, which runs the ARARA Message email-delivery service used by companies for newsletters and notifications, published its third report on November 6, 2026. A third party used credentials without authorization to access its systems between October 28 and 31, 2026 (October 27 activity looks like reconnaissance), including a shared admin environment and a separate cloud environment ('Environment B'). The latest report adds 3,249,492 addresses from Environment B, bringing the total to 81,329,467 unique email addresses taken; about 47 million of them came with attribute data. ARARA says this was not a new intrusion, that it holds no credit-card numbers, and that the count is addresses, not people. It disabled the abused credentials, has kept the whole service suspended since October 31 with no restart date, and says up to about 380 client companies are involved. Downstream firms including Zaif and Rakuten Securities have issued their own notices.

The fix

• ARARA Message clients: check ARARA's notices and admin console for your exposure (Environment B clients are being contacted separately) and plan an alternate delivery channel while the service is down.
• Rotate any API keys, SMTP credentials and passwords tied to ARARA and other email-delivery providers; limit who holds them and remove unused ones.
• Notify your own customers that a supplier leak occurred, warn them about impersonation emails, and plan for the count to change as the investigation continues.
• Recipients: treat unexpected emails asking for passwords or card details as phishing; ARARA says it will never ask for them by email.

Splunk

index=email (sourcetype=*o365* OR sourcetype=*proofpoint* OR sourcetype=*mimecast*)
(subject="*パスワード*" OR subject="*password*" OR subject="*カード*" OR subject="*card*" OR subject="*アララ*" OR subject="*ARARA*")
| eval sender_domain=lower(mvindex(split(sender,"@"),1))
| lookup newsletter_brand_domains sender_domain OUTPUT is_brand
| where isnull(is_brand)
| stats count dc(recipient) as recipients values(subject) as subjects by sender_domain, src_ip
| sort - recipients
// Brand/newsletter-themed phishing from non-brand domains after the ARARA leak

Sentinel

EmailEvents
| where TimeGenerated > ago(30d)
| where Subject has_any ("ARARA","アララ","password","パスワード","card","カード","newsletter","メルマガ")
| where DeliveryAction == "Delivered" and (AuthenticationDetails has "fail" or ThreatTypes has "Phish")
| summarize Recipients=dcount(RecipientEmailAddress), Msgs=count(), Subjects=make_set(Subject, 10) by SenderFromDomain, SenderIPv4
| order by Recipients desc
// Delivered phishing with failed auth themed on brands/newsletters that used ARARA

Mirae Asset Securities hacked twice in two days: 3,800 customer account numbers and 35,255 staff records leaked

What happened

South Korean brokerage Mirae Asset Securities said on November 7, 2026 that outsiders accessed its systems on November 4 and 5. The first intrusion hit its mobile-web login service that uses phone authentication and exposed about 3,800 customer account numbers; the company says account holder names, passwords and balances were not leaked. The second hit its in-house groupware, mi-global, and exposed data on 35,255 current, former and outsourced staff: mostly names and employee numbers, with some email addresses, mobile numbers and encrypted passwords. The company says no resident registration, passport or driver's license numbers leaked, there was no malware or service disruption, and no customer financial losses have been found. It blocked the access paths after spotting abnormal external IPs, cut external connections to the groupware and related mobile services, and reported to Korea's FSC, FSS and PIPC. It is the fourth Mirae Asset Group affiliate hit since October 26. How the attackers got in has not been disclosed.

The fix

• Mirae customers and staff: ignore calls, texts and emails claiming to be Mirae even if they quote your name, employee ID or account number; never share passwords or one-time codes or install programs on request; verify via known numbers (customer center 1588-6800).
• Staff: change your groupware password and any password reused elsewhere, since encrypted password values were exposed.
• Financial-sector defenders: review internet-facing login services that rely on phone/SMS authentication for enumeration or brute-force patterns, and restrict groupware/webmail exposure to VPN or conditional access.
• Tune phishing defenses for lures impersonating Korean financial brands; this is the fourth Mirae affiliate and follows other Korean brokerage breaches.

Splunk

index=web (sourcetype=access_combined OR sourcetype="ms:iis:auto" OR sourcetype="aws:waf")
  (uri_path="*login*" OR uri_path="*auth*" OR uri_path="*otp*" OR uri_path="*verify*")
| bin _time span=10m
| stats dc(user) as accounts dc(uri_path) as paths count as reqs values(status) as statuses by _time, src_ip
| where accounts>=20 OR reqs>=200
| sort - accounts
// One source enumerating many accounts on phone/OTP login flows = Mirae-style login abuse; then check what data those responses returned

Sentinel

let window = 30d;
let loginAbuse = W3CIISLog
| where TimeGenerated > ago(window)
| where csUriStem has_any ("login","auth","otp","verify")
| summarize Reqs=count(), Accounts=dcount(csUserName), Statuses=make_set(scStatus) by cIP, bin(TimeGenerated, 10m)
| where Accounts >= 20 or Reqs >= 200;
let bulkGroupware = OfficeActivity
| where TimeGenerated > ago(window)
| where Operation in ("FileDownloaded","FileSyncDownloadedFull","SearchQueryPerformed","MailItemsAccessed")
| summarize Ops=count(), Items=dcount(OfficeObjectId) by UserId, ClientIP, bin(TimeGenerated, 1h)
| where Items > 500;
loginAbuse | extend Signal="login-enumeration" | union (bulkGroupware | extend Signal="bulk-groupware-read")
// Adapt table names to your web/groupware logs; flags login enumeration and mass internal data pulls

SonicWall SonicOS SSL-VPN flaw (CVE-2026-19868) lets attackers bypass SAML and MFA; exploited, on CISA KEV

What happened

On November 6, 2026 SonicWall published advisory SNWLID-2026-0014 fixing seven SonicOS vulnerabilities. The headline bug, CVE-2026-19868 (CVSS 7.1), is an authentication-enforcement flaw in the SonicOS SSL-VPN service: a user with valid credentials for an alternate authentication method can bypass SAML authentication controls, including SAML-enforced multi-factor authentication. SonicWall PSIRT says it investigated a report indicating potential exploitation, and CISA added CVE-2026-19868 to its Known Exploited Vulnerabilities catalog the same day. Neither has published attack details, and it is unclear whether it was exploited before the patch. The same advisory also fixes six other SonicOS issues, including two management-interface flaws rated 8.8. There are no workarounds.

The fix

• Upgrade to SonicOS 7.3.4-7013 (Gen7) or 8.2.3-8015 (Gen8) or later now; SonicWall says there is no workaround.
• Patch even if you don't use SAML SSL-VPN, since the same advisory fixes two 8.8-rated management-interface flaws; keep the management interface off the internet.
• Review recent SSL-VPN logins for successes through local, LDAP or RADIUS auth on accounts that should be SAML-only, and disable alternate auth methods you don't need.
• Rotate credentials for accounts able to reach the SSL-VPN and investigate any suspicious sessions before closing out.

Splunk

index=firewall sourcetype="sonicwall*" (msg="*SSL VPN*" OR msg="*SSLVPN*") (msg="*login*" OR msg="*logged in*")
| eval auth_method=coalesce(auth_method, auth, method)
| search NOT auth_method="*SAML*"
| lookup saml_only_vpn_users user OUTPUT saml_only
| where saml_only="true" OR isnull(auth_method)
| stats count min(_time) as first max(_time) as last values(src) as src_ip values(auth_method) as auth_method by user, dvc
// SSL-VPN successes for SAML-only users that did NOT go through SAML = possible CVE-2026-19868 bypass

Sentinel

let vpn = CommonSecurityLog
| where TimeGenerated > ago(30d) and DeviceVendor has "SonicWall"
| where Activity has_any ("SSL VPN","SSLVPN") and Activity has_any ("login","logged in")
| extend User = tolower(coalesce(SourceUserName, DestinationUserName))
| project VpnTime=TimeGenerated, User, SourceIP, DeviceName, Activity;
let idp = SigninLogs
| where TimeGenerated > ago(30d) and ResultType == 0
| extend User = tolower(UserPrincipalName)
| project IdpTime=TimeGenerated, User;
vpn
| join kind=leftouter idp on User
| where isnull(IdpTime) or abs(datetime_diff('minute', VpnTime, IdpTime)) > 10
| summarize Logins=count(), FirstSeen=min(VpnTime), LastSeen=max(VpnTime), IPs=make_set(SourceIP) by User, DeviceName
// VPN logins with no matching IdP/SAML sign-in near the same time

DreamHost File Manager breach: FTP/SFTP passwords and some webmail sessions stolen

What happened

DreamHost disclosed that on the afternoon of Friday, October 23, 2026 it discovered unauthorized access to the server running its web-based File Manager at files.dreamhost.com. Attackers exploited a vulnerability in the third-party File Manager software and obtained FTP/SFTP usernames and passwords for customers who logged into File Manager between approximately August 2026 and October 23, 2026. They also reached certain webmail systems and obtained login credentials for a limited number of webmail users; in a small number of cases DreamHost believes mailbox contents may have been viewed. DreamHost took File Manager offline, patched the vulnerability, reset affected email and FTP/SFTP passwords, ended active sessions, rebuilt File Manager with extra monitoring, and notified regulators. It says it has found no evidence that control-panel logins or billing/payment details were accessed. Current analysis puts affected email and FTP/SFTP accounts well under about 10% of those hosted at DreamHost. Formal breach notices and identity-protection offers (Equifax) followed in early November.

The fix

• DreamHost account holders: reset mail and FTP/SFTP passwords from panel.dreamhost.com (only the account holder can set new ones; changes can take up to ~15 minutes). Update saved passwords in email/FTP clients.
• Review website files for unrecognized changes; check webmail forwarding rules and filters for anything you did not set; rotate any reused passwords on other services.
• Treat DreamHost password-reset or File Manager emails that ask you to sign in via a link as phishing—DreamHost says it will not email asking for your password, and account passwords are only changed inside the control panel.
• If you store customer/client data on DreamHost, assess your own notification obligations; DreamHost is offering Equifax credit monitoring/identity protection to notice recipients.

Splunk

index=* (sourcetype=*ftp* OR sourcetype=*webmail* OR sourcetype=*linux_secure* OR index=email)
(user="*dreamhost*" OR dest_host="*dreamhost*" OR url="*files.dreamhost.com*" OR subject="*DreamHost*" OR subject="*File Manager*")
| stats count min(_time) as first max(_time) as last values(src) as src values(action) as action by user, dest, sourcetype

Sentinel

union isfuzzy=true
 (SigninLogs | where AppDisplayName has_any ("DreamHost","FTP","SFTP","webmail") or IPAddress != ""),
 (EmailEvents | where Subject has_any ("DreamHost","File Manager","password reset") and SenderFromDomain !endswith "dreamhost.com")
| where TimeGenerated >= ago(90d)
| summarize Events=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by UserPrincipalName=coalesce(UserPrincipalName, RecipientEmailAddress), AppDisplayName, IPAddress=coalesce(IPAddress, tostring(SenderIPv4)), Subject
// Triage: unexpected FTP/webmail auth and DreamHost-themed phishing outside dreamhost.com

NTT Docomo: up to ~300k customer records leaked from My docomo / Online Shop

What happened

NTT Docomo confirmed unauthorized external access to its Online Shop and My docomo platforms, detected on November 4, 2026. The company halted online procedures from about 01:05 JST on November 5 for emergency maintenance and, in successive notices culminating in a third report dated November 6, 2026 18:00 JST, confirmed that customer information leaked before access was cut off. Maximum scope is about 300,000 records. For all affected customers Docomo lists names, dates of birth/age, addresses, contact phone numbers and email, identity-document numbers, mobile numbers and contract start dates, plus plan/option/discount details. For some customers it also lists agent/guardian contacts, employer/corporate details, bank name/branch/account number/name, and parenting-program information. Cause is described only as external unauthorized access; restoration timing for the online services is undetermined. Docomo says further leakage has not been confirmed since maintenance began.

The fix

• If you or users may be among the affected: watch for Docomo-impersonating email, SMS and phone calls; do not click URLs in unsolicited messages, open attachments, or give passwords, card numbers or personal data over those channels. Docomo published a dedicated inquiry line (0120-451-360, 09:00–20:00 JST).
• Force password resets and MFA review for any account where Docomo-related credentials or personal data might have been reused; treat identity-document numbers and bank details as high-risk for fraud and account takeover.
• For organizations with Japan-facing customers or employees on Docomo: brief helpdesk/SOC on expected scam patterns tied to this disclosure and add detection for Docomo lookalike domains and brand spoofing.

Splunk

index=email OR index=proxy OR index=dns ("docomo" OR "My docomo" OR "ドコモ" OR subject="*docomo*" OR url="*docomo*")
| eval lookalike=if(match(url,"(?i)docomo") AND NOT match(url,"(?i)(\.|^)docomo\.ne\.jp"),"yes","no")
| where lookalike="yes" OR match(subject,"(?i)(password|reset|maintenance|緊急|不正)")
| stats count min(_time) as first max(_time) as last values(src_user) as senders values(url) as urls by subject, recipient

Sentinel

EmailEvents
| where TimeGenerated >= ago(14d)
| where Subject has_any ("docomo","My docomo","ドコモ","不正アクセス","緊急メンテナンス")
    or SenderFromDomain has "docomo"
| where SenderFromDomain !endswith "docomo.ne.jp" and SenderFromDomain !endswith "nttdocomo.com"
| summarize Emails=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
    Subjects=make_set(Subject,10) by SenderFromAddress, SenderFromDomain, RecipientEmailAddress
| order by Emails desc

OpenSSH / Alpine “sshole” CVE-2026-123158: key-only account password-auth bypass

What happened

On musl-based Linux with PAM disabled, sshd can accept a 257–1024 byte password for an existing account whose shadow password field is *. musl crypt() returns * for an oversize password; the error value can match the stored field. At least one other local account with a $5$ or $6$ password hash must exist. Alpine says one reachable SSH connection is enough, with no retries. OpenSSH shipped 10.6p2 on November 5 and calls this a critical security workaround; the CVE is reported as CVSS 3.1 8.1 (High) by Cycode. Alpine’s original advisory said a CVE had not yet been assigned; Cycode now identifies CVE-2026-123158.

The fix

• Patch exposed Alpine SSH hosts now: run apk upgrade -U -a, then rc-service sshd restart. Upgrading the package alone does NOT restart the running daemon. For images, rebuild and redeploy from patched packages; make sure the running sshd is replaced.
• Fixed Alpine openssh packages (same branch, or a later vendor-fixed revision): edge 10.6_p2-r0; 3.24 10.3_p1-r2; 3.23 10.2_p1-r1; 3.22 10.0_p1-r11; 3.21 9.9_p2-r1; 3.20 9.7_p1-r6; 3.19 9.6_p1-r3; 3.18 9.3_p2-r4; 3.17 9.1_p1-r7; 3.16 9.0_p1-r6. These are backports: an older upstream version number can still be fixed. Self-built musl OpenSSH: update to upstream 10.6p2 or the distribution’s patched build.
• If patching must wait: first confirm key login works and keep the current session open. Set PasswordAuthentication no in the effective sshd configuration, including applicable Match blocks. Run sshd -t, restart sshd, and verify a fresh key login and sshd -T output. Consult Alpine’s advisory for its full configuration procedure, especially before 3.19, where default drop-in support differs.
• Verify openssh package revisions with apk info -v openssh-server openssh-server-pam and confirm that the daemon was restarted. Older branches received an emergency fix, not renewed general support: plan migration to a supported Alpine release.
• If an unexplained Accepted password event targets a key-only account, preserve logs, isolate the host and investigate as a possible compromise. Review doas activity, new users and authorized_keys changes; a patch does not undo prior access.

Splunk

index=os earliest=-7d (sourcetype=linux_secure OR sourcetype=syslog) "Accepted password for"
| rex field=_raw "Accepted password for (?<ssh_user>\S+) from (?<src_ip>\S+)"
| lookup alpine_musl_hosts.csv host OUTPUT distro openssh_version passwordauthentication usepam
| where isnotnull(distro) AND isnotnull(ssh_user)
| stats count min(_time) as first_seen max(_time) as last_seen values(distro) as distro values(openssh_version) as openssh_version values(passwordauthentication) as PasswordAuthentication values(usepam) as UsePAM by host ssh_user src_ip
| convert ctime(first_seen) ctime(last_seen)
| eval triage="Verify key-only/* account status and doas activity; version/config are inventory, not historical proof"

Sentinel

// Requires the curated AlpineMuslSSHHosts watchlist described in Hunt check.
let HostInventory = _GetWatchlist("AlpineMuslSSHHosts")
| project Computer=tostring(SearchKey), Distro=tostring(distro),
          OpenSSHVersion=tostring(openssh_version),
          PasswordAuthentication=tostring(passwordauthentication), UsePAM=tostring(usepam);
Syslog
| where TimeGenerated >= ago(7d)
| where ProcessName startswith "sshd"
| where SyslogMessage contains "Accepted password for "
| extend SSHUser=extract(@"Accepted password for (\S+) from", 1, SyslogMessage),
         SourceIP=extract(@" from (\S+) port ", 1, SyslogMessage)
| where isnotempty(SSHUser)
| join kind=inner HostInventory on Computer
| summarize Logins=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
    by Computer, SSHUser, SourceIP, Distro, OpenSSHVersion, PasswordAuthentication, UsePAM
// Triage against key-only/* account status and doas activity.
// Current inventory does not establish the host's configuration at login time.

APT29 watering holes hit unpatched iOS/Android; CISA adds Apple CVE-2024-27834 to KEV

What happened

CISA added CVE-2024-27834 (Apple improper authentication / Pointer Authentication bypass, CVSS 5.5) to the KEV catalog on November 4, 2026 after evidence of active exploitation. Sekoia attributes a mid-October 2026 watering-hole campaign with moderate-to-high confidence to APT29 (Midnight Blizzard / Cozy Bear). Attackers compromised legitimate sites, stood up AiTM lookalike domains, and briefly hijacked Ukraine's Plerdy SEO Tracker to inject fingerprinting JavaScript, then served platform-specific n-day exploit chains with no user click. One iOS 16.7 chain pairs WebKit RCE CVE-2025-43529 with the CVE-2024-27834 PAC bypass to steal browser/app cookies; other chains target iOS 18.5 for broader device data and Android Chrome for cookies and Wi-Fi passwords. All targeted flaws are already patched by Apple and Google.

The fix

• Update Apple devices to a release that includes the May 2024 fixes for CVE-2024-27834 (e.g. iOS/iPadOS 16.7.8 or 17.5, macOS Sonoma 14.5, Safari 17.5, and later) and apply the latest iOS/Android/Chrome security updates so the full n-day chains cannot land.
• Block or alert on the published delivery and exfil domains/IPs from Sekoia (flux-telemetry, clouds-stacks, starx-net, AiTM lookalikes).
• If users may have hit a watering hole: force sign-out of browser sessions, rotate passwords for high-value webmail/SSO accounts, and treat stolen cookies as session theft until rotated.

Splunk

index=* (dest_host="*flux-telemetry*" OR dest_host="*clouds-stacks*" OR dest_host="*starx-net*" OR dest_host="america250.holiday" OR dest_host="theowo.club" OR dest="109.104.106.107" OR dest="195.58.140.105" OR dest="95.133.231.28" OR dest="192.121.46.25" OR dest="188.190.17.232" OR url="*/telemetry/v12*")
| stats count min(_time) as first max(_time) as last values(src) as src by dest, dest_host, url

Sentinel

let badDomains = dynamic(["flux-telemetry.com","clouds-stacks.com","starx-net.com","america250.holiday","theowo.club","adsprism-stat.com"]);
let badIPs = dynamic(["109.104.106.107","195.58.140.105","95.133.231.28","192.121.46.25","188.190.17.232"]);
DeviceNetworkEvents
| where RemoteIP in (badIPs) or RemoteUrl has_any (badDomains) or RemoteUrl has "/telemetry/v12"
| summarize Hits=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by DeviceName, RemoteIP, RemoteUrl, InitiatingProcessFileName

Chainstack breached: customer data and password hashes accessed, node credentials treated as exposed

What happened

Blockchain infrastructure provider Chainstack says an outside attacker got into part of its infrastructure through a third-party component. The attacker reached a development environment on October 26, then escalated into parts of production. Chainstack detected the intrusion and cut off access on October 31. It's assessed to be part of a large AI-powered attack campaign that surfaced last week.

The fix

• Rotate your Chainstack node credentials and regenerate your platform API keys now.
• Change your Chainstack password, and any other account where you reused it, since password hashes were taken.
• Watch for phishing that uses your name, org name or Chainstack account details.

Splunk

index=proxy (dest="*.chainstacklabs.com" OR dest="*.p2pify.com" OR dest="*.core.chainstack.com" OR url="*chainstack*")
| stats count dc(src_ip) as sources values(src_ip) as src by dest, http_user_agent
| sort - count

Sentinel

// Find every app/host still calling Chainstack endpoints so you know what to re-key after rotation
DeviceNetworkEvents
| where RemoteUrl has_any ("chainstack","p2pify.com","chainstacklabs.com")
| summarize Calls=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by DeviceName, InitiatingProcessFileName, RemoteUrl

Attackers set French blood bank plasma freezers to 110°C through refrigeration vendor Coolworld

What happened

Overnight Nov 1-2, attackers compromised Coolworld, the refrigeration and maintenance provider for France's national blood service (EFS), and remotely changed temperature and defrost setpoints on plasma cold-storage units from about -30°C to 110°C. EFS confirmed three plasma cold-storage sites in Bourgogne-Franche-Comté were affected. 110°C was the commanded target, not a temperature actually reached. Monitoring alarms and an on-call technician caught the rising temperatures, and the Health Ministry says no blood products, samples or patients were affected. The intrusion method and attackers haven't been disclosed. It follows a wave of attacks on networked supermarket refrigeration controllers in France and other European countries, though investigators haven't formally linked them.

The fix

• Eliminate public internet exposure of refrigeration/temperature controller panels; if remote access is required, put it behind a firewall or updated edge device (FBI/CISA CSA).
• Change default passwords, enforce strong password policy, and use phishing-resistant MFA wherever feasible; inventory every vendor remote-access path and require per-session approval.
• Isolate OT on a dedicated VLAN from business networks; define device/IP allowlists for who can make controller changes; keep firmware patched and retire unsupported EOL devices.
• Define safe setpoint/defrost ranges on downstream devices, alert on any out-of-range or off-hours setpoint/defrost/alarm-threshold change, and keep independent temperature monitoring the controller cannot override.
• Enable and regularly review controller and remote-access logs (or collect OT network traffic when device logs are unavailable); maintain tested offline/offsite backups; make sure on-call staff have a runbook for cold-chain alarms including manual override and product transfer.

Splunk

index=vpn OR index=remote_access (user="*coolworld*" OR vendor_account=true)
| eval hour=strftime(_time,"%H")
| where hour<7 OR hour>19
| stats count min(_time) as first max(_time) as last by user, src_ip, dest

Sentinel

// Off-hours vendor remote access (tag vendor accounts in a watchlist named VendorAccounts)
let vendors = _GetWatchlist('VendorAccounts') | project SearchKey;
SigninLogs
| where UserPrincipalName in (vendors) and ResultType == 0
| extend Hour = datetime_part("hour", TimeGenerated)
| where Hour < 7 or Hour > 19
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, Location

Attackers drain BTCPay Server hot wallets on version 2.4.1 and older

What happened

BTCPay Server says attackers stole Bitcoin and Litecoin from hot wallets (wallets whose spending keys sit on the server) on servers running 2.4.1 or earlier. They used a new method to exploit the vulnerability fixed in 2.4.2 back in August. The first known drain was Nov 1 at 13:46 UTC. BTCPay warned users to shut down servers, and hosting providers including LunaNode took instances offline as a precaution.

The fix

• On 2.4.1 or earlier, don't just update: sweep remaining hot-wallet funds to a brand-new wallet with a new seed, made on a trusted device.
• Take the old server offline (keep its logs), build a fresh VM with the latest BTCPay release, and don't restore the old server onto it.
• From a trusted device, rotate every credential the old server could reach: hosting, SSH, app, API and Lightning keys.

Splunk

index=* ("bc1p0f7wmcnesrapznymf9ljdn04pudgmh96sqtrm9vmgqxdh666fh8qvn63r7" OR "ltc1qp49tmfdueyaqrmgrx0uyx4uegyygt8yt02whee"
 OR (sourcetype=docker* container_name="*btcpayserver*" ("Login" OR "/login" OR "/server/users")))
| stats count min(_time) as first max(_time) as last by host, sourcetype, src_ip

Sentinel

let wallets = dynamic(["bc1p0f7wmcnesrapznymf9ljdn04pudgmh96sqtrm9vmgqxdh666fh8qvn63r7","ltc1qp49tmfdueyaqrmgrx0uyx4uegyygt8yt02whee"]);
union isfuzzy=true
 (Syslog | where SyslogMessage has_any (wallets) or (ProcessName has "btcpay" and SyslogMessage has_any ("Login","/server/users"))),
 (ContainerLogV2 | where ContainerName has "btcpay" and (LogMessage has_any (wallets) or LogMessage has "Login"))
| project TimeGenerated, Computer, ProcessName, SyslogMessage, LogMessage

OPSSHIELD cPGuard update channel hijacked: fake updates ran as root on ~2,950 Linux hosting servers

What happened

On November 2, 2026 an attacker who had gained command execution on OPSSHIELD's billing and licensing server used a stolen update-storage key to push fake cPGuard updates (versions 5.88.12 through 5.88.19) through the product's trusted update channel. cPGuard is a firewall and malware-protection agent for Linux web-hosting servers. Agents that checked in during the roughly 70-minute window installed the fake update and ran its script as root. OPSSHIELD says the script collected /etc/shadow and /etc/passwd, root MySQL/MariaDB config, root shell history and root SSH files, uploaded them to OPSSHIELD's own licensing server under a compromised account, and planted a hidden setuid root shell. OPSSHIELD (disclosure published Nov 3) estimates about 2,950 servers ran the update, the attacker retrieved 32 collected files (one per customer server), and roughly 7,900 billing-portal account records were copied. It revoked the stolen key, reissued license keys and shipped clean cPGuard 5.88.25/5.88.26 that removes the backdoor.

The fix

• Run cpgcli update --start on every cPGuard server and confirm cpgcli --version shows 5.88.26 or later (OPSSHIELD's advisory names 5.88.25 as the minimum corrective release).
• Check grep 'Successfully updated' /opt/cpguard/logs/install_log for any 5.88.12-5.88.19 entry; if present, treat the server as compromised even after updating.
• On affected servers reset root and all password-enabled local accounts from a trusted recovery environment, rotate database passwords, S3/DigitalOcean/cloud tokens and anything in root's shell history, and replace /root/.ssh keys and remove their old public keys everywhere they are trusted.
• Confirm the hidden root shell, staging directory and scheduled task listed in IOCs are gone, then review for unfamiliar users, SSH keys, services and outbound connections; reset your OPSSHIELD billing-portal password and enable two-factor login.

Splunk

index=linux (sourcetype=linux:audit OR sourcetype=syslog OR sourcetype=sysmon:linux OR sourcetype="cpguard*")
  ("cpguard-v58812-i91511.sh" OR ".cpg91511_sh" OR "/var/tmp/.cpg91511" OR "loot.tgz" OR "i93677"
   OR ("Successfully updated to 5.88.1*"))
| rex field=_raw "Successfully updated to (?<cpg_version>5\.88\.\d+)"
| eval bad_version=if(match(cpg_version,"^5\.88\.1[2-9]$"),"yes",null())
| stats count min(_time) as first max(_time) as last values(cpg_version) as versions values(bad_version) as bad by host
// Any hit = host touched by the fake cPGuard update; rotate root secrets and SSH keys

Sentinel

let iocs = dynamic(["cpguard-v58812-i91511.sh", ".cpg91511_sh", "/var/tmp/.cpg91511", "loot.tgz", "i93677"]);
union isfuzzy=true
  (Syslog | where TimeGenerated > ago(30d) | where SyslogMessage has_any (iocs) or SyslogMessage matches regex @"Successfully updated to 5\.88\.1[2-9]\b" | project TimeGenerated, Computer, Evidence=SyslogMessage),
  (DeviceFileEvents | where TimeGenerated > ago(30d) | where FolderPath has_any (iocs) or FileName has_any (iocs) | project TimeGenerated, Computer=DeviceName, Evidence=strcat(ActionType, " ", FolderPath, FileName)),
  (DeviceProcessEvents | where TimeGenerated > ago(30d) | where ProcessCommandLine has_any (iocs) or (InitiatingProcessFolderPath has "/opt/cpguard" and ProcessCommandLine has_any ("/etc/shadow", "/root/.ssh", ".my.cnf", ".bash_history")) | project TimeGenerated, Computer=DeviceName, Evidence=ProcessCommandLine)
| summarize Hits=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Evidence=make_set(Evidence, 10) by Computer
// Hosts with cPGuard IOC paths, bad 5.88.12-5.88.19 installs, or cPGuard reading root secrets

WordPress Core CVE-2026-119977: upgrade-window RCE now on CISA KEV (due Nov 6)

What happened

CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, 2026 after confirming active exploitation. The flaw is a time-of-check time-of-use (TOCTOU) race in the WordPress Core upgrade process: predictable, web-accessible staging paths during full-package upgrades can let an unauthenticated attacker execute code on the server during the upgrade window. WordPress shipped the fix in 7.1.4 on October 28, 2026 (reported by Picus Security researcher Umut Bayram). Wordfence said it blocked more than 13,000 attack attempts targeting the bug in a 24-hour window.

The fix

• Update WordPress Core to 7.1.4 or the patched security release for your branch immediately (Dashboard → Updates, or your usual deploy path).
• Until patched, deny web access to /wp-content/upgrade/ at the web server, WAF, or CDN so staged upgrade files cannot be reached over HTTP.
• After updating, review web logs around any recent Core upgrade for unexpected requests under /wp-content/upgrade/ and check for unfamiliar plugins, themes, or admin users.

Splunk

index=* (uri_path="*/wp-content/upgrade/*" OR url="*/wp-content/upgrade/*" OR http_uri="*/wp-content/upgrade/*")
| stats count dc(src) as sources values(src) as src min(_time) as first max(_time) as last by uri_path, status, http_user_agent
| sort - count

Sentinel

union isfuzzy=true
 (CommonSecurityLog | where RequestURL has "/wp-content/upgrade/"),
 (AzureDiagnostics | where requestUri_s has "/wp-content/upgrade/"),
 (DeviceNetworkEvents | where RemoteUrl has "/wp-content/upgrade/")
| summarize Hits=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by SourceIP=coalesce(SourceIP, clientIP_s, InitiatingProcessRemoteIP), RequestURL=coalesce(RequestURL, requestUri_s, RemoteUrl), DeviceName

Supermarket freezers hacked overnight in Belgium and Sweden

What happened

Refrigeration systems at about 40 Delhaize stores in Belgium had their settings tampered with overnight, and Delhaize calls it an IT incident; staff paused the forced defrost to save food. Carrefour Belgium reports 15 stores hit. In Sweden, ICA and Coop say freezer temperatures rose sharply at several stores, and one store says its units were set to 50°C. It follows last month's attacks on cooling units at hundreds of French supermarkets.

The fix

• Inventory connected fridge and HVAC controllers and take them off the open internet or put them behind a VPN.
• Change default passwords on controller web interfaces.
• Alert on setpoint or defrost changes outside maintenance windows.

Splunk

index=firewall action=allowed direction=inbound dest_port IN (80,443,502,1911,4911,8080,47808)
dest_category="ot_refrigeration"
| stats count min(_time) as first max(_time) as last by src_ip, dest_ip, dest_port
| sort - count

Sentinel

CommonSecurityLog
| where DeviceAction in~ ("allow","accept") and DestinationPort in (80,443,502,1911,4911,8080,47808)
| where DestinationIP in (_GetWatchlist('RefrigerationControllers') | project SearchKey)
| summarize count(), min(TimeGenerated), max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort

VOLTA infostealer uses AI models to rank victims by what they're worth

What happened

Cisco Talos details VOLTA, a Windows infostealer that bundles stolen data and sends it through OpenRouter to an AI model (Claude Opus 4.6 by default, falling back to Kimi K2 and Gemini 2.5 Flash) to rank victims by financial value. It even searches the victim's Gmail for Amazon, DoorDash, Uber Eats, Walmart and PayPal receipts to confirm a home address, and exfiltrates over Telegram. Its config setup suggests a builder kit sold to customers.

The fix

• Treat any infected machine as fully compromised: revoke Microsoft OAuth tokens and browser sessions, and rotate saved passwords, SSH and cloud keys.
• Move high-value logins to phishing-resistant MFA so stolen cookies and passwords are worth less.
• Block or alert on unapproved Telegram API traffic from corporate endpoints.

Splunk

index=edr (file_hash="57ef4242666d78c50df145b34023df564f0fad38812d6a580e66433d427e2279" OR file_name IN ("9BY0tjwOc3ut.exe","yLP9m5J3i2Aw.exe","volta_debug.txt","volta_dox.zip","volta_log.zip","volta_doxnet.zip") OR (process_name="chrome.exe" CommandLine="*--headless*" NOT parent_process_name IN ("node.exe","python.exe")))
| stats count min(_time) as first by host, user, process_name, file_name, CommandLine

Sentinel

let h = "57ef4242666d78c50df145b34023df564f0fad38812d6a580e66433d427e2279";
union isfuzzy=true
 (DeviceFileEvents | where SHA256 == h or FileName in~ ("9BY0tjwOc3ut.exe","yLP9m5J3i2Aw.exe","volta_debug.txt","volta_dox.zip","volta_log.zip","volta_doxnet.zip")),
 (DeviceProcessEvents | where SHA256 == h or (FileName =~ "chrome.exe" and ProcessCommandLine has "--headless" and InitiatingProcessFileName !in~ ("node.exe","python.exe"))),
 (DeviceNetworkEvents | where RemoteUrl has_any ("openrouter.ai","api.telegram.org") and InitiatingProcessFileName !in~ ("chrome.exe","msedge.exe","firefox.exe","telegram.exe"))
| project TimeGenerated, DeviceName, FileName, FolderPath, ProcessCommandLine, RemoteUrl, InitiatingProcessFileName

HYBE breach: hackers got in through a vendor's document-preview tool

What happened

HYBE, BTS's label, says attackers got in through an outside vendor's document preview software linked to its electronic approval system. Breaches happened Sept 12-13 and Oct 3-5. Exposed data includes resident registration numbers, credit card numbers, medical records, passport numbers, bank details, addresses and phone numbers. HYBE hasn't said how many people were affected and reports no misuse so far.

The fix

• Inventory third-party plugins (document viewers, previewers) wired into approval, HR and ERP systems, and check how they authenticate.
• Review vendor plugin logs for bulk document access.
• Expect HR- and finance-themed phishing aimed at HYBE staff and partners.

Splunk

index=web (uri_path="*preview*" OR uri_path="*viewer*" OR uri_path="*docview*")
| bin _time span=10m
| stats count dc(uri) as docs by _time, src_ip, user, dest
| where docs > 50

Sentinel

// Bulk document reads through preview/viewer endpoints (W3C IIS or WAF logs)
W3CIISLog
| where csUriStem has_any ("preview","viewer","docview")
| summarize Requests=count(), Docs=dcount(csUriStem) by bin(TimeGenerated,10m), cIP, csUserName
| where Docs > 50

Chainalysis discloses breach of customer contact data

What happened

Chainalysis says an external actor using "offensive agentic techniques" accessed customer data. Chainalysis says it is unrelated to the Binance incident.

The fix

• Expect targeted phishing aimed at crypto-compliance staff; verify any Chainalysis contact out of band.

Splunk

index=email (subject="*Chainalysis*" OR subject="*Reactor*" OR subject="*password reset*") NOT src_user="*@chainalysis.com"
| stats count values(subject) as subjects by src_user, recipient

Sentinel

EmailEvents
| where Subject has_any ("Chainalysis","Reactor","password reset")
| where SenderFromDomain !endswith "chainalysis.com"
| summarize count(), make_set(Subject,10) by SenderFromAddress, RecipientEmailAddress, DeliveryAction

Binance hot wallet theft (~$6.3B): losses covered, withdrawals resuming in phases

What happened

At about 20:05 UTC on Oct 29, Binance's hot wallets were compromised and about $6.3B in tokens were withdrawn without authorization. Binance's initial investigation points to a compromised DevOps engineer's laptop that let the attacker reach a service container and submit withdrawal transactions; it says it found no evidence of a private key leak. Binance suspended withdrawals (deposits kept working) and says it will cover all losses from its SAFU fund and company treasury. A technical post-mortem is promised but not yet published.

The fix

• Only trust binance.com and @binance for the withdrawal restart; ignore 'claim refund' or 'verify your wallet' links.
• Warn users about lookalike Binance domains, fake refund emails and SMS lures this weekend.
• Watch for the full Proof of Reserves (Nov 3) and the technical post-mortem before drawing conclusions.

Splunk

index=proxy OR index=dns (query="*binance*" OR dest="*binance*" OR url="*binance*")
NOT (query="*.binance.com" OR query="binance.com" OR dest="*.binance.com")
| stats count dc(src_ip) as clients by query, dest
| sort - count

Sentinel

union isfuzzy=true
 (DnsEvents | where Name has "binance" and not(Name endswith "binance.com") | project TimeGenerated, Computer, Name, ClientIP),
 (EmailUrlInfo | where Url has "binance" and not(UrlDomain endswith "binance.com") | project TimeGenerated, Url, UrlDomain, NetworkMessageId)
| summarize count() by Name, Url, UrlDomain

Florida Dept. of Education: ~4.9M exposed in student financial aid site breach

What happened

The Florida Department of Education says hackers breached its student financial aid website (FloridaStudentFinancialAidSG.org), the hub for the state's scholarship and grant programs. It found the intrusion on October 19 and says it's contained. The department hasn't said how attackers got in, and no group has publicly claimed it. The Florida Digital Service and the Florida Department of Law Enforcement are helping with the response.

The fix

• If you or your kids ever applied for Florida state aid, freeze your credit at Equifax, Experian and TransUnion. It's free and stops new accounts being opened in your name.
• Watch for the department's notice, and treat any calls, texts or emails about the breach or 'scholarship refunds' as suspect until you confirm them on the official site.
• Check your credit reports at annualcreditreport.com and set up an IRS Identity Protection PIN, since exposed SSNs are often used for tax refund fraud.
• Questions go to [email protected].

Splunk

index=email sourcetype IN (ms:o365:reporting:messagetrace, o365:messageTrace, cisco:esa*)
(subject="*financial aid*" OR subject="*Bright Futures*" OR subject="*scholarship*" OR subject="*FLDOE*" OR subject="*data breach*")
NOT (src_user="*@fldoe.org" OR SenderAddress="*@fldoe.org")
| stats count values(subject) as subjects by src_user, recipient

Sentinel

EmailEvents
| where Subject has_any ("financial aid","Bright Futures","scholarship","FLDOE","data breach")
| where SenderFromDomain !endswith "fldoe.org"
| summarize Count=count(), Subjects=make_set(Subject,10) by SenderFromAddress, SenderFromDomain, DeliveryAction

Amadeus airline booking breach hits JAL, ANA, Cathay, Singapore Airlines and others

What happened

Someone used valid system-account credentials to access the Amadeus passenger service system from Aug 10, 2023 to Sep 23, 2026. Korean Air and Asiana are also affected. No card data or passwords.

The fix

• If you flew one of these airlines since 2023, expect a notice. If the airline asks you to change your booking reference, do it through the airline's official site or app.
• Treat emails, texts or calls quoting your itinerary or booking reference as suspect, since that detail makes phishing look real. Don't click links; go to the airline directly.
• Change your frequent flyer account password and turn on any extra login protection the airline offers.
• Review third-party vendor logins: valid creds went unnoticed for 3 years.

Splunk

index=email (subject="*booking*" OR subject="*reservation*" OR subject="*itinerary*" OR subject="*rebook*" OR subject="*KrisFlyer*" OR subject="*Asia Miles*" OR subject="*Mileage*")
NOT src_user IN ("*@jal.com","*@jal.co.jp","*@ana.co.jp","*@cathaypacific.com","*@singaporeair.com.sg","*@malaysiaairlines.com","*@koreanair.com","*@flyasiana.com")
| stats count values(subject) as subjects by src_user, recipient

Sentinel

let airlines = dynamic(["jal.com","jal.co.jp","ana.co.jp","cathaypacific.com","singaporeair.com.sg","singaporeair.com","malaysiaairlines.com","koreanair.com","flyasiana.com"]);
EmailEvents
| where Subject has_any ("booking","reservation","itinerary","rebook","KrisFlyer","Asia Miles","Mileage")
| where not(SenderFromDomain has_any (airlines))
| summarize count(), make_set(Subject,10) by SenderFromAddress, RecipientEmailAddress, DeliveryAction

Get the Weekly KEV & Hunt Pack free — plus the daily SOC brief.

Weekly email; daily brief on the website.

Read the free weekly pack →