Threat Intelligence on Senthorus Blog

SAPMAP: What Public Exploit Tooling Changes for SAP Defenders

Tue, 06 Oct 2026 00:00:00 +0000

Introduction

A critical SAP advisory arrives while the team is planning its next maintenance window. A week later, researchers publish a toolkit containing proof-of-concept code for the newly patched flaws. The vulnerable software has not changed. The assumptions behind the response timetable may have.

That is the question raised by SAPMAP: how should defenders react when specialized exploitation knowledge becomes easier to obtain and combine? Answering it requires care. Public code establishes that a capability is available; an incident report establishes that someone used it against a victim.

This assessment uses public information reviewed on October, 6th 2026. It separates reported capabilities from our assessment of their implications for defenders.

What appeared in September

SAP’s 8 September Patch Day included two particularly serious fixes: Security Note 3747649 for CVE-2026-44756, known as OVERPASS, and Note 3759472 for CVE-2026-58240, known as S4GET. SAP rates them 10.0 and 9.8 respectively.

On 15 September, researchers publicly released SAPMAP. Onapsis’s analysis describes discovery and exploitation capabilities, including proof-of-concept code for both flaws. It also reports finding OVERPASS-related code in the repository history despite an initial indication that it was being withheld. At publication, Onapsis said it had not observed threat actors actively using SAPMAP.

Figure 1. A week separates the vendor fixes from publication of the toolkit. Original illustration based on SAP and Onapsis. These are disclosure milestones, not an attack timeline.

Our assessment is that packaging capabilities together could reduce the preparation needed to attempt an intrusion. That is a reason to revisit prioritization. It does not establish mass exploitation, reliable execution in every environment or adoption by a particular criminal group.

OVERPASS reaches a shared component

OVERPASS affects the SAP kernel’s handling of the Extended Passport, a structure used to trace requests between components. Here, “kernel” means the core SAP runtime, not the operating-system kernel. Onapsis, which discovered the flaw, describes access through HTTP, SAP GUI and Remote Function Call traffic. RFC is one of the mechanisms SAP systems use to communicate with each other.

The processing happens before authentication. According to the researchers, successful exploitation can execute commands under the operating-system account running SAP. Restricting one protocol therefore does not necessarily remove the other routes to the same vulnerable code.

For exposure assessment, ask which source networks can reach each relevant service. An internet-facing inventory answers only part of that question. A second view should show what a compromised workstation, partner connection or administration host could reach. This is a defensive scoping exercise, not evidence that those routes have already been used.

S4GET abuses who the cluster trusts

S4GET concerns the Message Server, a component that tracks application servers and helps route client logons. Onapsis’s technical explanation describes an unauthenticated attacker being accepted as a trusted internal node. That trust can then affect access to application-server Gateways and enable command execution as the SAP operating-system user.

The distinction matters when assigning the fix. This is a flaw in how a component establishes trust, not simply an overprivileged business account. Tightening a user’s transaction permissions does not repair it.

SAP’s public bulletin lists kernel releases 9.16, 9.18, 9.19 and 9.20 for S4GET. OVERPASS has a broader list. The security notes should decide whether an installed build is affected; a product label such as “S/4HANA” is not enough to finish that check.

Figure 2. A simplified trust model based on Onapsis’s S4GET analysis. Successful exploitation depends on affected components and network reachability; the diagram does not imply that every SAP deployment is vulnerable.

What the threat assessment should say

A useful assessment makes its reasoning visible. Here, it should distinguish three statements:

Statement	What supports it
The flaws warrant urgent remediation.	Vendor advisories and the impact described by the researchers.
Public tooling may make attempted exploitation easier to organize.	Our assessment of the reported availability and packaging of capabilities.
A specific organization or actor has used SAPMAP maliciously.	This requires incident evidence; the cited toolkit analysis does not establish it.

The final statement should remain open until suitable reporting appears. An absence of observations in one vendor’s telemetry does not prove that attacks are absent everywhere. Equally, an available exploit is not sufficient grounds to announce a campaign.

This approach also helps avoid false attribution. If an incident later contains code found in a public toolkit, that overlap may identify a capability. Attribution would still need independent evidence about the operator, infrastructure or wider activity.

Give the SOC and SAP team a shared task

The first deliverable should be a short, agreed inventory: system owner, kernel build, applicable security note, reachable networks and patch status. CERT-EU’s advisory recommends applying both notes promptly and describes the affected release families.

For practical triage, add one business question to each entry: what depends on this system? A test environment holding copied production data or trusted connections may deserve attention before its label suggests it would. Record the actual dependency rather than assuming that production and non-production are isolated.

Then check visibility with the SAP Basis team, which administers the platform. Can investigators establish when server membership changed? Can they review unusual Gateway activity and operating-system processes started by SAP services? Are application logs retained centrally, and can their timestamps be aligned with network and identity records?

These questions are proposed investigation priorities, not published SAPMAP signatures. Validate what each deployment logs before writing a detection. Unexpected activity needs comparison with transports, maintenance and legitimate integrations; an event that looks suspicious in isolation may have a documented operational cause.

While remediation proceeds, keep one named owner responsible for checking new vendor and researcher updates. A confirmed exploitation report, a revised affected-version list or a change in reachability should trigger another look at the order of work. Avoid letting the original severity label become the only input after the situation changes.

Conclusion

SAPMAP is a useful case study in how CTI supports a decision before campaign reporting is complete. The immediate work is specific: verify the builds, map reachability, apply the relevant fixes and establish whether the SOC can investigate activity in the SAP environment.

Keep the uncertainty visible as that work progresses. It is possible to justify urgent action from exposure and impact without claiming to have observed an attack. A good assessment tells the team both why it should act and what evidence would change the assessment next.

Sources

NetScaler: Following the Intrusion Beyond the Gateway

Fri, 02 Oct 2026 00:00:00 +0000

Introduction

The gateway is patched. Remote access works again. The emergency change is closed. One question still needs an answer: what happened while the appliance was vulnerable?

September’s NetScaler disclosures make that question particularly relevant. Citrix confirmed exploitation of two vulnerabilities before customers could install the fixes. For a SOC, the job extends beyond checking a version number. It means finding out whether someone established an independent way back in, and whether they used the gateway to reach anything else.

This article examines public research available on 2 October 2026. The intrusion observations belong to the researchers cited below; the investigation priorities are our analysis of their findings.

Two vulnerabilities, different conditions

Citrix’s 27 September bulletin covers eight vulnerabilities. Two of them, CVE-2026-88771 and CVE-2026-88772, were already being exploited. Each can independently allow remote code execution without authentication.

The first is an input-validation flaw affecting vulnerable NetScaler ADC and Gateway deployments, including default configurations. The second is a memory-corruption flaw whose exposure depends on DTLS, the datagram-based transport security protocol enabled by default on VPN virtual servers. They should not be described as a mandatory two-step exploit chain.

Citrix lists fixes in 14.1-73.37 and 13.1-64.23 for the standard release branches. FIPS and NDcPP deployments have their own entries in the bulletin. Match the actual edition and branch before selecting an update.

That distinction also belongs in incident records. “NetScaler exploitation” is useful as an initial label, but it does not tell an analyst which entry point to investigate or which temporary restriction would help.

The intrusion started before the announcement

Mandiant and Google Threat Intelligence Group place the activity associated with CVE-2026-88772 at least as far back as early September. Their assessment includes likely affected organizations in Europe and North America across several sectors, including government and financial services.

Their report describes WHIPSHOT, a PHP webshell, and SLAPSHOT, a Python tunnelling tool. A webshell gives an attacker a way to send commands through a web server. A tunnel lets traffic pass through the compromised appliance to other systems. In at least one intrusion, the researchers observed internal reconnaissance and credential theft through that proxy.

Figure 1. Observation dates and publication dates answer different questions. Original illustration based on Mandiant/GTIG, Citrix and Unit 42; spacing is schematic.

Start the review from the earliest relevant exposure and available evidence. A search beginning on the advisory date would miss the earlier activity described here. If retention does not cover that period, record the gap explicitly; an empty search cannot resolve it.

A familiar-looking file can hide a different job

Unit 42’s investigation provides a separate view of the activity. Its account includes PHP webshells stored with .deb extensions. It also describes a 21 September intrusion associated with CVE-2026-88771, where a hidden implant was made accessible through paths resembling CSS assets.

The useful detail is the web-server configuration. A file extension does not determine how the server executes a file when its handlers and aliases have been changed. A request that looks like a stylesheet download can therefore deserve closer inspection. Unit 42 also documents changes intended to preserve elevated command execution.

For an investigator, this argues for comparing configuration as well as files. Ask whether the current web-server settings match a trusted baseline for that build. Identify who approved deviations. A known hash can find a known implant, but an unexplained handler change remains worth investigating when the payload has a different name.

Figure 2. An investigation map, not a claim that every victim experienced every stage. Original illustration informed by the Mandiant/GTIG and Unit 42 reports.

What to put in front of an analyst

The CERT-FR alert highlights a useful pair of artifacts reported by Google: a DTLS handshake failure with an internal-error reason, followed by abnormal NSPPE packet-engine termination and a watchdog message indicating that the process was not restarted. CERT-FR also links to Google’s indicators and YARA rules, while noting that ANSSI has not qualified them.

Treat that combination as a hunting lead. A single crash or handshake error needs context. Correlate the appliance, virtual server and time with subsequent configuration changes, requests and outbound traffic. Check how timestamps were normalized before assuming two events happened in sequence.

For the internal side, a practical starting point is traffic originating from the appliance towards services it does not normally contact. Review authentication events around those connections, then follow any accounts or hosts that appear. Keep the baseline specific to the deployment: monitoring, directory integration and administration can all generate legitimate connections.

These are investigation hypotheses, not validated detection rules. Before turning them into alerts, establish which logs are actually collected, how quickly they arrive and what normal maintenance looks like. A proposed correlation is of little use if one of its inputs never reaches the SIEM.

Close the exposure, then establish the scope

CERT-EU recommends updating affected software and assessing internet-exposed appliances for compromise. Those are two separate workstreams with different completion criteria.

The update workstream should produce evidence of the installed build on each relevant appliance. The investigation should produce a timeline, a record of the evidence examined and an explanation of any remaining uncertainty. If compromise is suspected, involve the incident-response team and preserve evidence in parallel with containment; urgent isolation should not wait for a perfect collection.

Avoid using service availability as the closure test. A functioning VPN says little about earlier access. Likewise, an assessment of one cluster member should not silently become an assessment of the whole deployment.

Conclusion

For these disclosures, the most useful CTI output is a set of questions the SOC can answer: when was the gateway exposed, what changed on it, and where did its connections lead?

Keep those answers beside the patch record. If the available evidence cannot answer one of them, document the limitation and assign the next action. That leaves the team with an investigation it can defend, rather than a maintenance ticket carrying an unsupported assumption of recovery.

Sources

OAuth Device Code Phishing: Stealing Sessions Without Touching a Password

Fri, 04 Sep 2026 00:00:00 +0000

Introduction

A user logs into the real microsoft.com, completes MFA, and just like this, his account is compromised. How ? He had typed in a code sent to him moments earlier. No fake login page, no stolen password, no MFA bypass exploit. Here is how it works, what it looked like across two real incidents contained by Senthorus SOC, detection patterns included, and what actually stops it.

What Is OAuth Device Code Phishing

OAuth 2.0’s device authorization grant (RFC 8628) exists for devices that cannot easily open a browser or type a password. Smart TVs, CLI tools, printers. The flow: the app requests a short code, shows it to the user, and asks them to enter it at a separate URL on a device that can browse, such as their phone. Microsoft first documented attackers abusing this at scale in February 2025, attributing the campaign to a threat actor it tracks as Storm-2372.

The technique itself isn’t new, but how often it’s being abused is. According to a Cloud Security Alliance research note, device code phishing pages targeting Microsoft 365 organizations surged 37.5x within about six weeks in early 2026, driven largely by the commercial EvilTokens phishing-as-a-service kit.

Attackers abuse this by generating a real device code, then pushing it inside usual phishing vectors (Teams, email, WhatsApp…). The victim enters the code on the actual Microsoft login page. Their session gets authenticated. The attacker’s polling script, sitting on the other end of that same flow, receives the access and refresh tokens directly.

Credentials never change hands, and MFA isn’t bypassed. The victim completes it themselves, on the attacker’s behalf. That’s why the technique slips past awareness training built around spotting fake login pages.

Two Real Incidents

Senthorus SOC detected and contained two of these incidents this past month, across two separate client tenants.

Case 1. The lure was a single email, subject line dressed up as an internal HR update. It carried a link to a compromised WordPress site hosting a device code phishing page. The victim entered the code. Within the same minute, the attacker’s infrastructure had a valid session and used it to register four rogue devices in a burst, roughly one every five seconds. All four came back as Workplace-registered, not joined, the Bring Your Own Device style path that needs nothing beyond a token to complete. Minutes later, the same session made multiple Microsoft Graph API calls, checking the account, pulling mailbox folders, then requesting a batch of recent inbox messages. Scripted mailbox harvesting, not manual browsing.

Case 2 followed the same device code flow, with Workplace-registered devices spun up in rapid sequence, three of them, ten to twenty seconds apart, following the exact same naming convention as Case 1: username, tenant domain, a short hex string, then -p01, -p02 for each additional device. The registration calls themselves came from a scripted OData client, not a browser. The session then went on to make similar Microsoft Graph API calls as in Case 1.

Why Device Registration, Why Multiple Devices

Registering a device isn’t a side effect of the attack, it’s the actual objective once the initial token lands. According to Microsoft’s original writeup on Storm-2372, using the Microsoft Authentication Broker client ID during the device code exchange gets the attacker a refresh token that can be traded for a second token scoped to the device registration service. That second token is what registers an attacker controlled device inside Entra ID. From there, the same refresh token combined with the new device identity is enough to request a Primary Refresh Token (PRT), a high-value Entra ID token.

A PRT is indeed worth more than the original stolen token. It grants seamless single sign-on across every Entra ID connected application without further prompts, and it survives a password reset in most configurations. Sekoia’s analysis of the EvilTokens kit confirms this as the mechanism that lets an attacker authenticate as the victim across Microsoft 365 with no further credential or MFA prompt appearing on either end.

Why register several devices rather than one ? That part is less documented. Neither Microsoft’s advisory nor the public EvilTokens research spells out a specific reason for registering more than one device per compromise. An important note is that in both incidents observed, the registrations happened in a tight burst. It is probably a redundancy measure: if a defender catches and disables one rogue device, any others left standing can still be used to request a fresh PRT. Disabling the first device found is not enough. Every device registered in the compromise window has to go.

The Same Kit, Twice

Line the two cases up and the overlap stops looking like a coincidence. Same device naming template, right down to the -p0X suffix pattern. Same Workplace-registered trust type. Same scripted, non-browser user agents driving the registration calls. And the two attacker IPs sat on the same ISP.

That points to both incidents running on the same phishing-as-a-service kit. The behavior matches EvilTokens: harvest a device code token, register an additional device with it, then request a PRT for persistent access. Whether this is EvilTokens itself or a fork isn’t confirmed, but the technique is a clean match. Both attacker IPs also traced back to GHOSTnet GmbH, a German hosting provider with an active abuse reporting presence on public phishing tracking services.

The pattern to watch for, either way: a device code sign-in event, followed within seconds or minutes by multiple new device registrations, followed by Graph API calls that don’t match the user’s normal behavior.

Remediation

Revoke sessions explicitly. This is the step that actually invalidates the refresh tokens.
Disable or remove every rogue registered device.
Reset the password and MFA methods too, as hygiene, but treat it as a secondary step, not the fix. If an existing MFA method shows a changed last-authenticated timestamp with no new method added, verify with the actual user that it was them, not the attacker riding an already-registered method.
Pull mailbox rules for anything routing internal security or admin senders to Deleted Items or an obscure folder. That’s a common way attackers hide the notifications that would otherwise tip off the victim.
Check delegated and shared mailbox access, not just the primary inbox. Persistence sometimes shows up as access to a resource the user wouldn’t normally touch.
Apply Conditional Access named location blocking to cut off the attacker’s infrastructure, and check whether the same source IP or ASN appears against any other account.

Prevention

MFA doesn’t help here. The victim completes it themselves, on the attacker’s behalf. Domain-reputation and phishing-page blocking can stop the initial lure, but the authentication itself happens on login.microsoftonline.com, a domain no defense should block.

If your org has no legitimate use for the device code flow, block it outright with a Conditional Access authentication flow policy.
Alert specifically on device code sign-in log entries. Don’t rely on generic risky sign-in detections to catch this.
Watch for Microsoft Authentication Broker client ID usage paired with new device registrations. This combination is a strong signal.
Hunt for device display names following a predictable template: username + tenant domain + short hex string, especially with sequential -p01, -p02 suffixes appearing seconds apart. Query provided below.

Hunt Burst Device Registration by Naming Pattern (Device Code Phishing Indicator)

The following KQL query detects multiple devices registered by the same user within a short time window, with display names matching a scripted naming template (username-domain-hex, optionally suffixed -p01/-p02), a pattern consistent with automated device registration following device code phishing observed in real incidents.

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("Add device", "Register device")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend Target = TargetResources[0]
| extend DeviceId = tostring(Target.id)
| mv-expand Prop = Target.modifiedProperties
| where tostring(Prop.displayName) == "DisplayName"
| extend DeviceName = tostring(parse_json(tostring(Prop.newValue))[0])
| where DeviceName matches regex @"^[a-z0-9]+(-[a-z0-9]+)*-[0-9a-f]{6,10}(-p\d{2})?$"
| extend BaseName = extract(@"^(.*?)(-p\d{2})?$", 1, DeviceName)
| summarize DeviceCount = dcount(DeviceId),
Devices = make_set(DeviceName),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by Actor, BaseName
| extend BurstSeconds = datetime_diff('second', LastSeen, FirstSeen)
| where DeviceCount >= 2 and BurstSeconds <= 120
| order by BurstSeconds asc

Conclusion

Device code phishing works precisely because it doesn’t look like phishing. There’s no domain to spoof, no certificate to fake, just a legitimate feature used the way it was designed to achieve malicious goals. Two incidents a few weeks apart, running on what looks like the same kit, is not a coincidence, it’s a pattern worth detecting and raising awareness about.