SAP Fraud Forensics; How far can Security Audit Logs help you?
So…Last week, I was at the 8th Annual ACFE conference and it appeared as though Forensics came out open as a very hot topic amongst exhibitors. Quite a sizeable number of service providers performing forensics came to share their thoughts, and advice on how to deal with fraud investigations with a focus on cross referencing accounting documents in comparison with audit logs. Whilst this methodology has always been used by many CFE’s in SAP run organizations after the facts, it begets the question: How much help can you get from a compromised Audit logs of a SAP system, after it has been compromised? Hence, I thought it would be nice to share some real life case while consulting for a company X on a forensics investigation following a Fraud case in an SAP run environment.
…Usually, after the occurrence of a Fraud incidence on an SAP system, most investigators run to the almighty formula for succor: for most of these victim organizations, audit logs will give answers to the who, when and where the fraud /breach might have come from. In terribly sad cases, as witnessed in another customer Y, they never even activated their audit logs; reason being to “accommodate for and avoid performance issues” (normally, this need not be the case if proper sizing had been established pre-implementation). In other not-so-terribly sad cases, Security Audit Logs could be activated, but unfortunately, most customers have few or NO skills to make deep investigative sense out of the log data. Hence, the get stuck in the forensics, not being able to conclude investigations or atimes, it takes extremely long time to provide investigation outcomes owing to poor skillset on SAP (giving room for evidence to be smeared as investigation prolongs and time is wasted; another sad way to lose money on forensics).
For clarification purpose, the Security Audit Log (SAL) is what allows SAP security administrators to keep track of the activities performed in their SAP systems. Common sense I hear you say? but indeed, few even know how to correctly configure this. Normally, the logs record has the following structure/characteristics – * Event identifier *SAP User ID and client * Terminal Name * Report Name * Time and date * Process ID * Session Number which all need careful attention with configuration.
I once had the opportunity to lead a forensic team from the SAP side on an “ALMOST” perfectly planned fraud on a SAP system. My task was clear: make sense out of the Audit logs to support the forensic investigation for a customer X using ECC6.0, EHP6 SAP. It was then that an interesting anomaly was picked up! Lo and behold: there had been a manipulation of the log data! How could this be? Clearly, we saw that the log data manipulation vulnerability in the security audit log facility in SAP enhancement package (EHP) 6 for SAP ERP 6.0 had been exploited. In plain terms, the Security Audit Log facility in the SAP ERP 6.0 system had been manipulated in order to tamper with clear evidence and this was done remotely by deleting arbitrary log classes though unspecified vectors. This can be likened to having a Forensic abortion even before the beginning of an investigation.
Normally, by default, the SAL facility logs the source of transaction using a “Terminal Name”; Either as the address of the computer that logged the transaction or alternately, the static signature of the IP address of the computer (in a case where the source computer does not transmit a Terminal Name with its communications).
Below information shows information on the vulnerability (CVE-2014-2748) picked up as a function of its Impact
CVSS Severity (version 2.0):
- CVSS v2 Base Score: 7.5 (HIGH)
- Impact Subscore: 6.4
- Exploitability Subscore: 10.0
CVSS Version 2 Metrics:
- Access Vector: Network exploitable (hence, even after the investigation starts, Data can still be manipulated from over the network)
- Access Complexity: Low (very little knowledge is required to exploit)
- Authentication: Not required to exploit
- Impact Type: Allows unauthorized disclosure of information; Allows room for financial fraud; Allows unauthorized modification; Allows disruption of service
This vulnerability can be abused by fraud perpetrators to cover evidence/ cover their tracks since filling the terminal name value in an RFC call is performed by the perpetrators machine.
Upon reconstruction of what the perpetrators had done, it was clear a couple of these three or more things might have happened:
- The perpetrator possibly had TCode Authorization SE92 and deleted messages in table TSL1D (giving the perpetrator complete Anonymity)
- Since the perpetrators has the ability to manipulate the “Terminal Name” of the computer, they could have made different attacks like bruteforce attempts and ensured that each transaction appear to come from a different terminal. (giving him Pseudonymity and confusing the investigators the more)
- They possibly might have set a misleading IP address (or cycle through a range of IP addresses) as the Terminal Name; so as to divert evidence so as to confuse investigators to believing that specific individual requests had their source from the range of IP addresses (also giving Pseudonymity)
But should company X be in this position at all? Losing more money on forensics by the hour? Risking reputational damage when information leaks? Company X could have simply taken the necessary step of performing a prevention/remediation below:
What can be done?
- Make it a point of duty to enable all logs including technical logs too (with proper sizing done ahead)
- Implement the SAP note1497445 1926485
- Store log files in an encrypted format and replicate them to separate time synchronized servers
- Even after implementing the SAP notes, also make sure you restrict S_DEVELOP authorization from users.
Kindly note that whilst this article contains references to the products of SAP SE in Germany and in several other countries all over the world, SAP SE may not be held responsible for the proper use of mis-use of the contents
To know more about SAP Cyber Fraud Forensics, please write to firstname.lastname@example.org for pointers.