Session CRT-20260702 — 2 July 2026 · Afternoon Edition

Halil, my ranking is:

1) Isolate-now + hunt-as-compromised: SimpleHelp CVE-2026-48558.
This is still the nastiest kill chain. The evidence says attackers can forge OIDC login, gain a trusted technician session, then use SimpleHelp’s own remote execution and file transfer to deploy malware and steal cloud keys, SSH creds, source code, package tokens, crypto wallets, and customer-environment access. That is not “patch and move on.” If the SimpleHelp server was internet-facing and OIDC/technician-group conditions apply, isolate it, preserve logs, rotate technician creds, API keys, SSH keys, registry tokens, and assume downstream endpoint access may be dirty.

2) Isolate-now where exposed + hunt-as-compromised: Oracle E-Business Suite CVE-2026-46817.
This moved up operationally because the current evidence says Oracle EBS Payments 12.2.3–12.2.15 is under active attack, with roughly 950 exposed systems, and exploitation can hit /OA_HTML/ibytransmit over HTTP for unauthenticated file read. That closes the chain: file read becomes database credentials, encryption keys, payment processor API keys. If EBS Payments is internet reachable, isolate or restrict access immediately, patch, and hunt logs for suspicious POSTs to /OA_HTML/ibytransmit.

3) Patch-now fast + hunt exposed servers: SharePoint Server CVE-2026-45659.
CISA’s three-day deadline and the DHS HSIN/SharePoint breach context make this urgent, but I would not rank it above SimpleHelp or exposed Oracle EBS unless your SharePoint Server is externally reachable and unpatched. The visible reporting says active exploitation affects SharePoint Server 2016, 2019, and Subscription Edition, and one source describes a network-triggered RCE path requiring low-privileged authentication. That is dangerous, but not the same as unauthenticated exposed EBS or a trusted RMM control plane. Patch inside the CISA window, hunt for webshells/session abuse, and prioritize internet-facing farms first.

4) Hunt-as-compromised for credentials; patching alone is not enough: FortiBleed feeding INC/Lynx ransomware.
This is less about the box and more about stolen identity material. The current handoff ties FortiBleed credential theft to INC and Lynx ransomware activity. If affected Fortinet/VPN edge credentials were exposed, rotating passwords is table stakes; revoke sessions, rotate tokens/certs where relevant, check impossible travel, VPN logins, new admin accounts, and lateral movement. Do not treat this as “firmware updated, incident closed.”

Where I would not overreact: don’t shut down every SharePoint or every remote support tool blindly. Scope matters. SharePoint Online is not the same as on-prem SharePoint Server from the evidence here. SimpleHelp is worst when internet-facing with the vulnerable OIDC/technician path. Oracle EBS is a five-alarm fire only where Payments is exposed or reachable by hostile networks. FortiBleed is a credential-compromise problem first; the right move is identity containment and ransomware hunting, not performative appliance panic.

Halil, yes — this is a live trust-state incident. Fact: the pack ties EvilTokens and Kali365 to Microsoft 365 device-code phishing, LSHIY to Azure CLI password spraying, SimpleHelp to active exploitation, and FortiBleed to credential theft linked with ransomware activity. Unknown: I found no data on ARToken in the visible identity-threat results, so I would not make kit-specific claims there; I’d contain it under the same device-code/OAuth trust model until proven otherwise.

Tonight, I would kill or constrain these trust objects:

• Microsoft 365 sessions and refresh tokens: revoke sessions for any account with device-code, Azure CLI, ROPC, VPN, SimpleHelp, or impossible-travel sign-ins. Password reset alone is not enough.
• Device-code flow: enforce Conditional Access to block device-code flow tenant-wide or as close to tenant-wide as operations allow. Microsoft calls device-code flow high-risk and recommends getting close to a unilateral block.
• OAuth ROPC: disable apps/users that still permit Resource Owner Password Credentials. Microsoft says ROPC is not recommended and is incompatible with MFA; do not trust “MFA enabled” as a sufficient control if password-grant paths remain reachable.
• Legacy authentication: block legacy protocols with Conditional Access, because Microsoft states these protocols do not support multifactor authentication.
• OAuth grants: remove suspicious user-consented apps, pause user consent, require admin-consent workflow, and review grants with mail, files, SharePoint, offline_access, or directory permissions.
• Azure CLI/public-client access: constrain Azure CLI sign-ins to compliant or managed devices and known admin groups; investigate any successful spray-hit accounts before restoring access.
• VPN credentials and sessions: for FortiBleed exposure, invalidate VPN sessions, rotate VPN credentials, and remove local VPN accounts where Entra-backed conditional access can be used.
• SimpleHelp/admin trust: terminate active remote-support sessions, disable exposed technician accounts, rotate any credentials reachable from those hosts, and remove standing admin rights created for support workflows.

The fastest Microsoft 365/Azure controls are: Conditional Access block for device-code flow, Conditional Access block for legacy authentication, emergency restriction of risky public-client/ROPC usage, session revocation for affected users, privileged-role lockdown with phishing-resistant auth, and sign-in log hunting filtered on device code flow authentication protocol. My bias is showing, but this is exactly why: the attacker is not “logging in” once; they are minting trust artifacts and riding them.

Halil, the difference tonight is that this is not just “patch the box and move on.” The evidence we have points across collaboration platforms, ERP portals, remote support, BI exposure, and object storage: DHS HSIN via a SharePoint collaboration system; Oracle EBS CVE-2026-46817 under active attack; PeopleSoft CVE-2026-35273 exploited in campaigns affecting exposed PeopleSoft instances; SimpleHelp CVE-2026-48558 tied to exploitation and credential/AI-key theft reporting; and Alta Montclair’s public AWS S3 bucket exposing retirement/financial records. For Power BI/AMIGO, I don’t have enough visible evidence here to assert specifics, so I’d treat that as a tenant exposure hypothesis until audit logs confirm it.

What cloud/SaaS owners should do tonight: freeze external collaboration paths first. In Microsoft 365/SharePoint, review and disable anonymous links, guest sharing, externally shared sites, app-only permissions, OAuth consents, and stale service principals; then revoke active sessions for impacted users and rotate any app secrets tied to workflows. For AWS S3, do not just make the bucket private manually and celebrate — check bucket policy, ACLs, Block Public Access at account and bucket level, access points, replication targets, CloudFront origins, and any producer jobs still writing sensitive data into that namespace. “Serverless” and “SaaS” still have servers; you just mostly get logs and policies instead of a shell.

For Oracle EBS/PeopleSoft and SimpleHelp, patching is necessary but incomplete. Owners should isolate exposed portals/VPN-adjacent admin interfaces, snapshot logs before containment, rotate credentials reachable from those systems, hunt for new admin users, web shells, remote agents like MeshCentral where relevant to the PeopleSoft reporting, and unexpected outbound compression/exfiltration tooling. The blast radius is the workflow identity graph: ERP service accounts, payroll exports, BI datasets, SharePoint libraries, S3 buckets, and remote-support credentials.

Shared responsibility boundary: Microsoft, AWS, Oracle, and the vendors own their service/control-plane security and patches; customers own exposure, IAM, sharing policy, app consent, bucket policy, remote-support placement, and log retention. Tonight’s priority is therefore: reduce public/external access, revoke and rotate identities, preserve SaaS/control-plane logs, and only then declare patch status. Classic server patching fixes one vulnerable node; this kind of incident can leave valid tokens, shared links, and data pipelines still bleeding quietly.

Halil, with one emergency window tonight, I’d brief the board this way: preserve evidence first, then use the window on the exposed system that gives attackers remote administration. If SimpleHelp is internet-facing and affected, it is first. The CCB advisory describes CVE-2026-48558 as a critical OIDC authentication-bypass issue where a remote unauthenticated attacker can submit a forged identity token and obtain a fully authenticated technician session; CCB says exploitation may allow creation of technician accounts, remote endpoint access, script execution, software installation, and data access or modification. SC World also lists affected versions as 5.5.15 and earlier plus 6.0 pre-release builds, with fixed versions 5.5.16 and 6.0RC2. So: export logs, snapshot where feasible, restrict technician login sources or remove internet exposure, patch, then hunt for unexpected technician accounts.

If SimpleHelp is not exposed or not vulnerable, the window moves to Oracle E-Business Suite where it is internet-facing or tied to critical business workflows. The current handoff evidence flags Oracle EBS CVE-2026-46817 as actively exploited, and the referenced SecurityAffairs reporting says 950 systems exposed. If both SimpleHelp and Oracle EBS are internal-only and clean, then FortiGate/FortiBleed or SharePoint only jump the queue if your team can confirm internet exposure, active exploitation indicators, or a vendor-identified vulnerable build. I do not have current advisory or patch detail in the visible evidence for the specific SharePoint, FortiBleed/FortiGate, or Microsoft identity items here, so I would not spend the single outage-risk window on those without confirming exposure.

What can wait: broad identity hardening and non-exposed SharePoint/FortiGate patching can wait until the next window, but identity containment should still run in parallel without a change freeze dependency — revoke suspicious sessions, rotate credentials tied to SimpleHelp/EBS administration, and preserve identity logs. The board-level line is simple: “Tonight we keep evidence intact, remove the exposed remote-admin path first, patch the highest-risk verified exposure, and defer anything not internet-facing or not confirmed vulnerable.”