limkedin Skip to main content
Blog

Using SAP systems for CEO fraud

By 26 May 2021January 7th, 2022No Comments
CEO fraud, SAP systems

Business Email Compromise (BEC), more commonly known as “CEO fraud”, is one of the more successful techniques in cybercrime nowadays. 

The number of reported incidents is increasing fast. According to an FBI report, in 2020, the Internet Crime Complaint Center (IC3) of the FBI received 19,369 complaints involving BEC that amounted to a total loss of approximately $1.8 billion.

Indeed, according to the report, BEC attacks account for losses that are a massive 64 times worse than ransomware:

CEO fraud-1

Insider BEC attacks

Typically, BEC fraud is committed by individuals outside the organisation that is targeted. But when BEC fraud is committed by insiders or actual employees of the organisation, the risk level of these attacks is much higher, because they are likely to use internal resources that cannot be detected that easily. 

When such internal resources are used, one cannot rely on e-mail authentication mechanisms (DKIM, SPF, DMARC) to prevent the attack; nor will standard automatic anti-phishing and antispam tools, which look for inconsistencies in technical headers or altered addresses, help.

The only thing that this insider must do is to create an email message with a forged (spoofed) sender address, for example, the CEO’s or CFO’s company email address (or that of another internal user). 

Detection

Closer examination of the mail headers may help to determine the IP address from which the malicious email originated. In Outlook, you can determine the mail header texts by selecting the mail from your inbox and then choosing: <File>, <Properties>. The mail header texts will be visible in the section labelled ‘Internet Headers’.

CEO fraud-2

In the mail header, one can see some lines starting with the word ‘Received:’. The line containing the last instance of ‘Received:’ usually contains the sender’s IP address. 

In addition, there is another mail header label called ‘X-Originating-IP:’ that may also contain the sender’s IP address, depending on whether the label is used by the mail client.

Any inside attacker may want to avoid this detection possibility, for example, by using someone else’s laptop or PC to send the spoofed email, so there is no trace left to themselves. But this means taking substantial risks.

Using SAP to spoof e-mail

There is also another less risky possibility: using an SAP system to spoof email. It is quite easy to do this provided:

– the SAP system has outbound email configured 
– the internal user has access to SAP transactions SU01 (or SU01_NAV) and SBWP (or SO01)

These permissions are usually given to administrators.

Step 1: First use transaction SU01 to change your Last and First name to the person that you want to spoof and update the E-mail Address field and save your user record.

CEO fraud-3

Step 2: compose the mail using transaction SBWP, Menu option ‘New message’

Step 3: Create a fake invoice including a bank account, save it as PDF file

Step 4: create and send the mail to target internal company mail address using transaction SBWP

Example text:

“Hi Gwen,

Could you do me a favour? There’s a pending invoice from one of our providers and because I am out today and tomorrow, I need you to take care of it for me, because I have no access to the accounts. 

Attached please find the invoice. It needs to be paid today, so I would appreciate it if you could give it a priority.

Should you have any questions, I cannot take any calls now, but I will be back in the office this coming Wednesday.

Thanks,

<The main dude>”

=> The mail may also contain links to an external website, for instance, tricking the receiver to click on them, which is another way of spreading malware in a company.

Attach the fake invoice PDF to the mail.

Fill in the recipient address in the Recipient area, Recipient Type = ‘Internet address’ and flag the ‘Express Mail’ option (the lightning arrow icon). 

CEO fraud-4

The scheduled Send jobs will send the mail out automatically. If it is a non-Production system, you may force the send using transaction SCOT (Steps 4 and 5).

Step 4: First, check if the SMTP node is active and when not, flag the ‘Node in use’ flag

CEO fraud-5

Step 5: Also in transaction SCOT, force the mail to be sent out (Actions 1-3)

CEO fraud-6

Step 6: Still in transaction SCOT, clean-up by deleting the selected mail request afterwards (Action 4).

Step 7: Transaction SU1: restore your original user profile changed in Step 1

Step 8: delete the outbound mails in transaction SBWP

When the mail arrives at the recipient, the only way to determine the place of origin is again to look at the mail headers for the ‘Received:’ and ‘X-Originating-IP:’ header. But the IP address, in this case, is that of the SAP server and not an IP address of the Sender’s laptop. 

The mail cannot be traced back to a person anymore unless a forensic investigation is done in the SAP system.

How to detect whether mails are coming from an SAP system

There is another mail header that can be used to check if the mail is coming from an SAP system. It is called ‘X-Mailer’ and the good news is that it is possible to create a rule in Outlook for that:

CEO fraud-7

When a message arrives containing the words ‘SAP Netweaver’ in the ‘X-Mailer’ mail header, put it in a special folder.

CEO fraud-8

This way you can prevent spoofed emails coming from the SAP system from ending up in your inbox. 

If you regularly receive emails from an SAP System (including automatic mails from SAP), you may want to create an SAP folder and direct all email messages coming from SAP systems to that folder. If the SAP folder contains a CEO type mail, you can be pretty sure that it is spoofed.

Prevention of this type of attack

To prevent this type of attack:

  1. Consider limiting the creation of SAP Office mails to SAP Background users (type System) only.
  2. restrict the assignment of SAP_ALL profiles as much as possible. (is always a good thing)
  3. Remove authorisation object S_OC_SEND from all end-user roles. 
  4. lock transactions SBWP, from: SO00 to: SO23. 
    (see also OSS Note 2234192 – Enhancement for locking application start)
  5. Monitor the unlocking of these transactions using report RSAUDIT_BCE
  6. Monitor the use of these transactions in SAP Enterprise Threat Detection.