1. Authentication methods
2. User installation
3. Application Installation and Administration
4. Internet Exposure

Based on this and also by working on the analysis of the different versions, we will discuss what we have surprisingly found throughout this article and how it could be utilized as a ‘guide’ for the analysis of any such system.

Splunk Free does not possess any type of authentication, any user which knows the IP address and the corresponding port can start the Splunk session with administrator privileges. In this website, the vendor clearly indicates that this version is not adequate for corporate environments.

Splunk Enterprise possesses various authentication method options to choose from (Splunk, LDAP, Scripted, SAML, ProxySS) which configure within the file:

$SPLUNK_HOME/etc/system/local/authentication.conf.

Splunk’s own authentication (an authentication method selected by default) is neither adequate for corporate environments since the only parameter that the password can be set to is the length, and by default it is set to 0. Splunk does not allow you to set up a blocking rule for failed access attempts, thus it is acceptable to strong attacks; neither does it enforce rules which guarantee password complexity. The user by default is the admin of their corresponding password ‘changeme’. 

Splunk Cloud comes from two different versions, Managed Splunk Cloud and Self-Service Splunk Cloud. In order to differentiate one from the other you can analyze the URL. The URLs from the Self-Service are in this format: https://prd-*.cloud.splunk.com and the URLs from Managed are in this format https://*.splunkcloud.com. In Splunk Self-Service the users can authenticate themselves with their splunk.com account which has long and complex password restrictions. In Splunk Managed the users can authenticate themselves through SAML, although they normally utilize Splunk’s own authentication, since it comes with it by default. Although, it has a length of eight characters set, it is still the only parameter used.

It is important to take into account that by configuring Splunk, in order to utilize another authentication method which is not its own authentication (for example LDAP), all of the local user’s accounts with Splunk’s own authentication will continue to be active (including the admin account). In order to eliminate all of the local accounts you must leave the file $SPLUNK_HOME/etc/passwd blank. This file should not be deleted, since otherwise, it will be returned to the user by the admin with the password ‘changeme’.

Both Splunk Free and Enterprise can be installed with root privileges in the Linux/Unix platforms, with administrator privileges in Windows platforms or with users with less privileges in both platforms, and adequately configuring the necessary permissions in the system files. This last option is the most recommended within corporate environments since it reduces surface attacks in case Splunk becomes compromised. Splunk’s installation guide indicates how to carry out the installation for users with restricted privileges in different platforms. Also the universal forwarders or splunk clients which are installed on the systems from which the logs will be collected from, should be installed with users of limited privileges; since they could be used to execute commands or send scripts from the Splunk server utilizing it as a deployment server.

Splunk Free and Enterprise can administer themselves in different ways: from the web consola, the Splunk CLI, modifying the files from the corresponding settings in the operating system or utilizing the REST API. Splunk Free as well as Enterprise allow the installation of ‘custom’
or user created applications (for example in python), in addition to those present in Splunkbase, which is the official repository of Splunk applications and add-ons. The installation of applications created by the user presents risks, since once the Splunk server is compromised it could install any type of malicious application, which for example allows them to control the server through a web shell or a reverse shell (always taking into account the permissions of the user’s account utilized for Splunk’s installation), or it is sent to the the universal forwarders in order to compromise the Splunk clients’ systems.

In Splunk Cloud you do not have access to administrate Splunk from the CLI nor by the system file to modify the file settings. You can utilize Splunk Web and the REST API in order to carry out some administrative tasks. Neither can you install any application, but only those which are approved by Splunk in order to be used in the cloud environment. Before the applications are approved, they go through a validation process by the tool AppInspect which determines if it complies with the requirements of the defined security, for example: it does not require privilege increases with sudo, su, groupadd or useradd, it does not use reverse shells, it does not manipulate files outside of the application’s directory and it does not manipulate processes outside of the application’s control nor the operating system nor reset the server.

Internet Exposure

Search in Shodan from Splunk browsers

[dirección ip=”” n=””]:[puerto]/en-US/account/login?return_to=%2Fen-US%2F[/puerto][/dirección]

• “isFree”:true it indicates to us that it deals with a Free Splunk Version (without authentication)




• “instance_type”:”cloud” it indicates to us that it deals with a Cloud Splunk Version




• “instance_type”:”download” and “product_type”:”enterprise” it indicates to use that it deals with a Splunk Enterprise Version




• “hasLoggedIn”:false it indicates to us that no user started the session in the system, which is a clear indicator that this Splunk still maintains the default password since nobody could start the session to change it.

As a matter of fact, for this particular case of Splunk analysis, we have found that at the moment of installation, it creates a file with a password to utilize in order to encrypt the authentication information in the file settings and to encrypt the utilized passwords for the different applications. This key is found in the file: 

$SPLUNK_HOME/etc/auth/splunk.secret 

Which is unique for each Splunk installation. The applications which are downloaded from Splunkbase (for example the add-on which allows its integration with the Active Directory, or which allows them to integrate Splunk with communication depositories) they need to store the credentials in the file settings from its own application. Splunk decrypts these passwords by using splunk.secret. The risk in this case, is that once the Splunk server is compromised, you can use the same Splunk API to decrypt the password from these applications with a simple Python script and thus it can compromise other components of the infrastructure.

As with in many other fields, you can protect your equipment within the infrastructure and server where you find SIEM installed, by adequately choosing the version to use and then configuring it in a safe way (following the manufacturer’s best practices). Logically, in the presence of such a delicate infrastructure, any error could expose very valuable information to the attackers, and sometimes it could even let them know passwords from the organization’s internal applications. In this example we have focused upon SPlunk as a ‘case study’, however in general they should consider the following aspects to carry out the SIEM hardening:

• To utilize a non-privileged user (not the root nor the administrator) for the installation
• To modify the default passwords as soon as they are installed
• To select a robust and secure authentication method which does not exist in simple forms to conceal it (as we saw in the Splunk case which needed to erase the file $SPLUNK_HOME/etc/passwd)
• To utilize certificates on the web interface, which are preferably not auto generated
• To disable the web component if you do not use it
• Do not expose the SIEM ports to untrustworthy networks
• To update the SIEM regularly, and to incorporate it into the the audit scope or intrusion test, which are carried out periodically
• To activate SIEMs own audit and monitor the resulting events

Finally, given that we have spoken about Splunk throughout our analysis, we can continue to explore this with the following links from the vendor, which shows the best practices to utilise in order to protect these systems.

• Best practices in protecting splunk enterprise
• Community: Deploy Hardened Splunk
• Documentation Splunk latest security hardeningstandards