With Coronavirus still active across the world, life is far from settled, but the uptake of remote working is surely here to stay. From a security standpoint, organisations[1] may feel less comfortable at the moment simply because staff are working out of sight. Whether that feeling is justified will depend on the technical measures put in place to facilitate remote working. However strong those measures are, proactive monitoring can be used to check that they are functioning, which in turn can help to allay any feelings of security angst.

When it comes to Salesforce, enhanced event monitoring is one of the major advantages of using Shield[2], but some organisations may not yet feel ‘mature’ enough in their Salesforce posture to explore that add-on or, as a commercial offering, it may simply be out of budget. However, Salesforce provides logging of authentication events as part of the standard platform. This article takes a look at monitoring these events in various contexts as a way to increase assurance. For simplicity, it assumes that credentials and two-factor authentication are managed within Salesforce (as opposed to an external identity provider[3]); where this is not the case, the precise event details and log sources may differ, but the principles still hold.

IP address restrictions

If users have access to a corporate VPN then an organisation may have set IP address restrictions for accessing Salesforce. These are applied at the Profile level. But what does it look like when a login attempt occurs from an IP address outside the set of approved ranges? The ‘Login History’ within Setup will have an entry with a Status of ‘Restricted IP’ (along with the source IP address)[4]:

This entry means that the correct password was supplied, as the IP address is only checked against any defined ranges once the user has authenticated successfully with their primary credentials[5]. This isn’t necessarily a security incident, of course – Alice may have simply forgotten to set up the VPN connection and logged in to Salesforce first thing. But what if that failed attempt originated from an IP address associated with a different country? Now it might be worth messaging Alice.

Let’s briefly consider the case where IP address restrictions are not in place. With a mobile workforce and two-factor authentication (2FA) enabled, that’s entirely justifiable for some organisations. First and second factor authentication events are discussed below; here, let’s stick to IP addresses. Variations in source IP address are expected, of course – Alice might be assigned a different IP address by her ISP, she may use a Wi-Fi network at a café, or a mobile data connection, etc. So figuring out when to act isn’t always trivial, something we’ll return to later, but this case highlights that it’s not just failures that need to be logged: unusual success events should also be considered.

Login hours

This is another feature offered by Salesforce to control access. To support flexible working, though, login hours may have been relaxed or even disabled altogether. Nevertheless, monitoring the login times recorded in the Login History could help to build up patterns of normal usage, deviations from which could trigger an alert. If login hours have been enabled, a failed authentication based on this restriction could be of interest too[6]. In this case, the Status in the Login History would read ‘Restricted Time’.

Two-factor authentication (2FA)

Without logging in successfully with a username and password, it’s impossible to know if an Organization has 2FA enabled. If an attacker somehow learns a user’s Salesforce credentials but, on using them, is faced with a second authentication challenge, it’s likely that they would abandon the attempt. They may go on to try to defeat 2FA through a phishing attack, for example, but let’s leave that story for another time. For now, the point is that a login event with credentials followed by no (or a failed) 2FA attempt is potentially interesting.

In the Login History, a Status of ‘Two-factor required’ will be recorded without a subsequent ‘Success’ for that user:

Again, this isn’t necessarily a security incident – Alice may have simply mislaid her phone – but, for example, two successive ‘Two-factor required’ events for the same user from different source IP addresses, especially within a short timeframe, might be worth checking up on.

The 2FA journey itself is logged separately under ‘Identity Verification History’ in Setup:

The equivalent indicator here would be a set of entries under the same ‘Verification Attempt’ number that did not end with a ‘Succeeded’ status. Factoring in the IP address, as suggested above, looks to be more complex, as the ‘Source IP’ column for this log (not shown above) appears not to have been populated for some time[7] (although it is retrievable from the API – more on this later).

It’s also possible that a savvy user could catch this scenario – in the case that their second factor prompted them when they hadn’t logged in. Of course, this would require successful user education and a defined reporting process, but it also depends on the technology in use – for example, a third-party authenticator app (as opposed to Salesforce’s own app) would not alert you to the primary login event.

Device Activation

Even without 2FA, identity verification is required when a user logs in from an unrecognised browser (or app) from outside a trusted IP address range (as defined in ‘Network Access’ within Setup). This additional layer that Salesforce applies is called “device activation”[8]. The strongest available method for identity verification will be used[9], the weakest of which is a code sent by email.

The requirement for device activation can be seen in the Login History by a Status of ‘Failed: Computer activation required’:

Shortly afterwards, in this case, a ‘Success’ from the same source IP address was logged. A missing subsequent ‘Success’, however, could represent an attacker logging in with a username and password but then failing the activation challenge. While an attacker can anticipate device activation with more certainty than 2FA, an organisation may have configured the ‘Network Access’ ranges to be deliberately wide to reduce user friction[10]. Therefore an attacker will not necessarily have to contend with device activation, especially if pivoting from inside the corporate network.

The activation process itself is logged in the Identity Verification History[11]:

Since device activation and 2FA are both identity verification exercises, monitoring failed (including abandoned) activations could use much the same set of indicators derived for 2FA events. One key difference, though, is that the fact that device activation was required at all could itself be noteworthy, since even a user on the move would not face device activation unless the browser (or app) was unrecognised.

Password policy

A review of the password policy configured in Salesforce might also be useful at this time, especially if an organisation has relaxed its IP address restrictions and has yet to adopt 2FA. First, check that an account lockout policy exists, which will hinder password-guessing attacks. There may be exceptions when an account should not lock out but they should be few in number, well understood and documented. Second, check that the password minimum length and complexity requirements, together with any other appropriate settings, meet the wider corporate policy.

As explained in a previous blog post, be aware that the password policy for the Organization can be overridden by that in a Profile, so checking ‘Password Policies’ within Setup isn’t necessarily enough. NCC Group’s tool SFPolDevChk (available at https://github.com/nccgroup/SFPolDevChk) can help to get quick visibility of any deviations in this area.

From a monitoring perspective, the Login History clearly indicates a failed first-factor authentication as well as an account lockout: the Status is ‘Invalid Password’ and ‘Password Lockout’[12] respectively.

Yes, I want this data!

The Salesforce web portal allows you to download the last six months of Login History in CSV format (or view up to 20,000 records from that period). Identity Verification History can only be viewed, not downloaded – again, up to 20,000 of the most recent events. This is where the API comes in. The following table shows which Salesforce API objects can be used to derive the information in the Setup pages referenced in this article:

Setup page	API objects
Login History	LoginHistory LoginGeo User
Identity Verification History	VerificationHistory LoginGeo User
Activations	LoginIP UserDevice UserDeviceApplication User

This allows authentication event data to be pulled in programmatically, reformatted and pushed wherever and however it’s required. In fact NCC Group’s Managed Detection & Response service has provided assistance with integrating Salesforce event data into a proactive monitoring strategy.

Conclusion

Salesforce provides detailed information about login events as standard. Reviewing this for suspicious activity, as part of a wider proactive monitoring strategy, can help to gain assurance that an organisation’s Salesforce data is secure from unauthorised access. As with all discussions in the SIEM space, ultimately each organisation must arrive at its own definitions of what is and what isn’t normal. These definitions are often fuzzy, however, because “what is and what isn’t normal” can vary between users. It is for this reason that security best practice includes regular user education with a defined and published process allowing anyone to report a potential security incident. This article may be a stimulus for promoting flow in the other direction – where security teams push suspicious events, even regular summaries, to users for review.

Lastly, it’s worth remembering that event monitoring is not exclusively about authentication failures. No matter what technical measures have been implemented to prevent unauthorised access, an organisation cannot rest on the assumption that they will be 100% effective. Monitoring authentication successes can be important in the reactive case of investigating a compromise, but reviewing them for anomalies can help with the proactive case of stopping an attack in its tracks.

Jerome Smith @exploresecurity

---

[1] The term ‘organisation’ has a specific Salesforce context. Because users of Salesforce extend beyond the commercial sector, ‘organisation’ is used in preference to ‘business’ to cover the general Salesforce customer base. When used in a specific Salesforce context, it is capitalised (and spelt as ‘Organization’). Other Salesforce terms are also capitalised.

[2] https://help.salesforce.com/articleView?id=salesforce_shield.htm&type=5

[3] Even when an external identity provider is used, there will always be some accounts in Salesforce to support administrative access, which should not be overlooked.

[4] Certain fields in the screenshots have been changed – they may be technically invalid or nonsensical but serve their purpose for a demo.

[5] In accordance with best security practice, Salesforce doesn’t divulge the fact that IP address restrictions are the reason for a particular authentication failure. At the time of writing, it returns “Please check your username and password. If you still can’t log in, contact your Salesforce administrator”.

[6] Again, Salesforce doesn’t divulge that login hours are the reason for an authentication failure in the error message.

[7] https://trailblazers.salesforce.com/answers?id=9063A000000e59KQAQ

[8] Although it works deeper than the name suggests, as a user logging in from a browser that was previously activated for a different user will also have to go through identity verification.

[9] The set of methods can be found at https://help.salesforce.com/articleView?err=1&id=security_activation_about.htm&type=5.

[10] Salesforce blocks you from entering a range of 0.0.0.0 to 255.255.255.255, though: the range must be “no more than 33,554,432 addresses (2²⁵, a /7 CIDR block)” [https://help.salesforce.com/articleView?id=security_networkaccess.htm&type=5].

[11] Details of previously activated browsers can be found in ‘Activations’ within Setup, from where it’s also possible to revoke entries.

[12] A subtle point but ‘Password Lockout’ does not appear at the point the threshold is reached, only as the reason for a subsequent failure. For example, if ‘Maximum invalid login attempts’ is set to 3, a ‘Password Lockout’ event will only appear after a fourth login attempt (whether or not the password is correct).