| 👉🏿back to blog series or to GitHub repos with ready-to-run playbooks. |
Dear community,
There are various problematic attack vectors for SAP backends, but only a few are as severe as losing access to the SAP audit log from your security tooling. In part 3 we discussed malicious deactivation of the SAP audit log. Now, what if the SAP RFC user to collect the audit log info gets locked, deleted, or disabled in any other way too?
At that point you are fully blind and might not even get the audit-log deactivation message anymore if the attacker is fast.
Today you will see an automated response flow to deal with that situation. But wait!
How about regular SAP or Sentinel Collector VM maintenance? How do we distinguish between normal operations and actual attacks?
Stay tuned – Azure Center for SAP solutions (ACSS) comes to the rescue🐕🦺⛑️ to wade through the false positives and emphasize the impactful true positives.
Fig.1 Overview remediation workflow for the Sentinel Collector attack scenario powered by ACSS
Cyber-attacks require the quickest possible reaction
The provided playbook posts an adaptive card to Microsoft Teams with a color-coded message scoring the likelihood of an attack based on the signals coming from the Sentinel Collector for SAP, and the SAP system state. The Azure Center for SAP Solutions provides a set of managed APIs to query such info in a scalable and secure way.
The playbook is wired to listen to the pre-built Sentinel alert “SAP - Data collection health check”. But you may customize yourself to whatever scenario you need.
In the scenario depicted in fig.1 the Sentinel Collector for SAP is healthy while SAP is running fine too.
That causes the playbook to raise the attack likelihood based on the alert “RFC LOGON FAILURE” to medium. After all there is still a little chance that someone unintentionally performed a breaking user setup change. Up to you to configure this as “high” or “OMG run for your lives” based on how likely you think that is in your landscape.
See here how to register your SAP system with ACSS and be ready for upcoming out of the box integrations.
| In case the Collector or SAP would have been down, the likelihood of attack gets set to low with the suggestion to double check and investigate further through Sentinel, since this likely a planned maintenance or an outage. See here how to communicate SAP maintenance via Microsoft Teams in an interactive way. Integration with the SharePoint list using the SID known to Sentinel enables you to enhance the presented flow further. What else would you like to see here? Reach out or let me know in the comments. |
Fig.2 Screenshot of adaptive card with Sentinel’s SAP incident in Microsoft Teams
As per the inferred info from the various sources, the playbook suggests a couple of options to remediate the situation. This is customizable according to your needs.
Let the community know what additional remediation paths you would like to see here. Happy to dive deeper.
The simplest option addresses the possible process glitch on the Collector VM. Hit the corresponding button (see lower section on above screenshot) to trigger an automatic restart of the VM.
Fig.3 Screenshot of Sentinel Collector VM restart logic
This suggested remediations (see fig.2) are a natural fit for the upcoming Microsoft Security Copilot. Will get into details once it gets more widely available.
The true power lies in the correlation of multiple signals in addition to the ACSS metadata leading to the event of the SAP Collector being "blinded"
Fig.4 Screenshot from Sentinel security video series about multi-staged attacks to SAP
In the above scenario you can see a sequence of alerts painting the larger picture of the attack from RDP activity to login attempts in various places leading to a successful data download from SAP sending the file to an unknown IP address. In addition to that Microsoft Defender already compiled which attacker group was responsible based on the attack footprint, techniques and tools used.
See the full video here.
Additional automation scenarios
Another popular RFC attack vector (Capture-Replay vulnerability in NetWeaver AS for ABAP; SAP security Note 3089413) can be addressed like this. How about blocking the user corresponding to that new SAP system connection? Have a look at part 1 of the series.
Last weeks publication in the German SAP security tech press re-inforces the need to deal with RFC vulnerabilites. Would you like to get the recommended security setting change for the function module "RFC_TRUSTED_SYSTEM_SECURITY" to be performed automatically from such a workflow? Or would you consider that too high a risk because it could be used to attack from a different angle?
Part 4 concludes the first wave of my blog series.
Looking to you now to request additional scenarios and share your own as Pull Requests on GitHub.
Final words
That’s a wrap 🌯today you saw another SAP security automation scenario in action. We deployed a playbook that scores potential attacks to the audit log ingestion pipeline of Microsoft Sentinel. The required signals to determine the severity of the alert are fed by Azure Center for SAP solutions to get reliable information about the operational state of SAP.
In case all involved systems are up and running while only audit log ingestion is impacted, there is a considerable chance for an ongoing attack. The playbook offers pre-configured actions to act immediately directly from Microsoft Teams.
That brings down the time to action while avoiding to “shoot” from the hip with security incidents when SAP is just down for maintenance. Whooza, whoooza Sentinel. Nothing to worry about 🧘🏻 ☮
This integration pattern overall is applicable to any SAP API. Got another SAP threat at your hands that needs automatic remediation? Let me know in the comments or reach out directly.
Cheers
Martin
- SAP Managed Tags:
