RSA SecurID Authentication Security: Detecting and Foiling Break-In Attempts

UPDATE (Apr 3): An RSA representative has passed along a link to the best practices that customers should follow in order to secure their SecurID installations. This guidance is now publicly available here.

In the wake of the recent RSA SecurID breach, it is important for affected organizations to be able to detect and prevent possible break-in attempts against their authentication systems. RSA has so far failed to openly disclose the details of the breach. This is unfortunate, since it makes effective mitigation and response more difficult for customers. However, given that it is very likely that the so-called “token seed records” have been compromised, the following are some steps organizations can take to detect and defend against possible exploitation attempts.


Step 1: Instruct users to protect their accounts, token serial numbers and PINs/passwords and immediately report any attempts to elicit this information from them.

Step 2: Implement a strong out-of-band authentication process for users calling help desk to request PIN/password resets.

Step 3: Configure adequate PIN/password strength and account lockout policies on the Authentication Manager server.

Step 4: Configure the Authentication Manager servers to forward their audit logs to a central syslog host or SIEM appliance that supports parsing and alerting on syslog messages (see bottom of this article for instructions).

Step 5: On the syslog server or SIEM appliance, set up custom parsing rules and alerting scripts to notify administrators and security teams of the tell-tale signs of malicious activity described below.

NOTE: If your SIEM solution cannot be configured to parse, report and alert on the syslog messages described here, I strongly urge you to reevaluate your SIEM strategy.


  1. The most obvious indicator of an attack is a sharp increase in the number of failed login attempts and account lockouts. This type of activity points to a very clumsy and unsophisticated attacker, perhaps using an automated tool to try to enumerate accounts and PINs. It is more a nuisance than a real threat, since a policy of locking out an account after a reasonable number of invalid login attempts renders this mode of attack largely ineffective.
  2. Here is what an account lockout event looks like in the audit log (all on one unbroken line):

    <14>2011-03-23 18:55:45,881,,

  3. A more sophisticated attacker will obtain a list of valid account names before launching the attack (this can be approached via standard social engineering and network reconnaissance methods). If we assume that the attacker is in possession of a list of valid accounts, and the ability to leverage a database of stolen token seed records, their next objective will be to tie individual accounts to their corresponding token seed records. Each token seed record can be mapped to a user account via a token serial number. This is again information that an attacker would obtain most effectively via social engineering or other out-of-band methods. It is therefore crucial to instruct users to protect their token serial numbers as if they were passwords and report any attempts to elicit this information from them.
  4. Supposing that a patient and sophisticated adversary successfully obtained all the required preliminary information (a list of valid accounts with corresponding token seed records), he is now fully equipped to launch a direct attack. His objective will be to defeat the final layer of security: the user’s PIN or password. This is typically much weaker in a two-factor system like SecurID than it would be in a password-only authentication system. Since a token-based login process is already quite cumbersome, most users are likely to choose the simplest and shortest PIN that is permitted by policy, with a 4-digit numeric PIN being typical.
  5. In an effort to be as stealthy as possible and avoid causing noisy account lockouts, the attacker will patiently try a very low-volume series of login attempts, giving enough time between successive attempts for the invalid login counter to reset itself. Alternatively, the attacker will again resort to social engineering methods such as calling the help desk to request a reset of the PIN/password (this mode of attack must be defended against by ensuring that the out-of-band authentication of callers to help desk is sufficiently strong). The audit log records PIN resets, and a report of such events should be reviewed and verified with account owners on a periodic basis. This at least gives a fighting chance of detecting accounts which have been compromised through this technique.
  6. Here is what a successful PIN reset looks like in the audit log (all on one unbroken line):

    <14>2011-03-23 18:45:02,585,,

  7. Having successfully cleared all the obstacles so far, there is one final hurdle the attacker must overcome: The determination of clock drift between the RSA token’s clock and the Authentication Manager server’s clock. Since the two clocks are never perfectly in sync, it is very likely that the 6-digit code displayed on the token will differ from that calculated by the authentication server based on its local clock time. The RSA protocol compensates for this by asking the user for the next code displayed on the token (to identify the exact spot in the tokencode sequence that the token is currently at), calculates the delta between the two clocks and resynchronizes itself to match the token’s clock. An attacker who is generating tokencodes by leveraging stolen seed records is likely to trigger this mechanism at least once per compromised account. Such ‘next tokencode’ events are recorded in the audit log and are another indicator of possible malicious activity.
  8. Here is what a ‘next tokencode’ event looks like in the audit log (all on one unbroken line):

    <14>2011-03-23 18:50:45,773,,


  • Track and investigate attempts to elicit sensitive information (PINs, serial numbers, etc.) from users.
  • Treat help desk calls for PIN/password resets with caution and use strong out-of-band processes to verify the caller’s identity.
  • Track and verify PIN/password reset events in the audit log.
  • Establish a baseline for the typical volume of failed login attempts and account lockouts. Review failed login and account lockout reports on a daily basis and investigate any significant deviations from the norm.
  • Look for repeated, regular sequences of failed login attempts against individual accounts in the audit trail.
  • Look for ‘next tokencode’ events in the audit trail and verify with the account owners whether they represent legitimate logins. Tokens with unreliable clocks which routinely generate ‘next tokencode’ events due to clock drift should be replaced.


To export Authentication Manager audit logs to an external syslog host, perform the following two steps. In the instructions, replace <syslog-ip> with the IP address of the syslog host. The instructions assume that Authentication Manager 7.1 is running on a Linux server or RSA SecurID 3.0 appliance.

  1. Edit the file ‘/usr/local/RSASecurity/RSAAuthenticationManager/utils/resources/’ and add the following entries:

    ims.logging.audit.admin.syslog_host = <syslog-ip>
    ims.logging.audit.admin.use_os_logger = true

    ims.logging.audit.runtime.syslog_host = <syslog-ip>
    ims.logging.audit.runtime.use_os_logger = true

    ims.logging.system.syslog_host = <syslog-ip>
    ims.logging.system.use_os_logger = true

  2. Edit the file ‘/etc/syslog.conf’ and add the following entry:
    *.* @<syslog-ip>
    Restart the syslog service.
  3. Advertisements

8 Responses to RSA SecurID Authentication Security: Detecting and Foiling Break-In Attempts

  1. Javier Jarava says:


    I’d like to point that another likely way the hypothetical über-attacker armed with “almost all” the pieces (Seed Records and token Serial #, usernames, user-to-serial mapping) would try to bypass SecurID, and somewhat simpler than asking for a PIN reset, would be just trying to “bruteforce” the user’s PIN. This would result in authentication attempts where the TokenCode is good, but the PIN is bad. This generates a different message in the logs (BAD PIN GOOD TOKEN or something like this – I don’t have an Authentication Manager setup handy to test) that is very important to monitor!!!

    • Jacob Gajek says:

      Indeed, thank you Javier. I believe this possibility is mentioned in point 4. It would have to be a very slow and methodical brute force attempt, so as not to trigger account lockouts after the threshold for invalid attempts is reached. Not a very efficient approach, in my opinion, and a fairly easy one to defend against with appropriate account lockout and password strength policy settings.

      • Javier Jarava says:

        Hi, jgajek

        Agree that this is what is mentioned when talking about “try a very low-volume series of login attempts” – my point is not that you can defeat them with proper lockout policies, as I agree they’re the best prevention, but rather I was trying to highlight that given the specific profile of the attack (good tokencode and bad PIN), the Authentication Manager server will warn you of the attack, using a specific message that you have to watch for. The likehood of this happening in “normal use” is pretty low, so it’s a good sign of an attempted compromise… As a matter of fact, a SecurID token will be locked out sooner (3 attempts vs. 5, IIRC) with this kind of authentication failures than with normal errors.

        It might be interesting to readers that RSA has published guidance on the recommended countermeasures and what messages to look for/montor.
        They’re now available to everybody (previously you needed a SecurCare Online account) at

        The message I’m talking about is “Bad PIN, Good Tokencode Authentications”.

      • Jacob Gajek says:

        Good to know, thank you Javier!

  2. Dave says:

    Any idea what all of the comma-seperated fields in those log samples represent? (other than the obvious ones…).

    • Jacob Gajek says:

      I’m not aware of any information published by RSA explaining these fields. The last field (12-digit sequence) appears to be the token serial number.

  3. Laura Deitch says:

    Thank you for providing this information. I have also read about TeleSign’s phone based two-factor authentication product which works with any phone and easily deployed worldwide.

    Few months ago I have gone through the demo of Salesforce with TeleSign’s Two-Factor Authentication at .

  4. sdf says:

    Date and Time Log Level Activity Key Description Action Result Key Result Key Result User ID User First Name User Last Name User Security Domain User Identity Source Agent Type Agent Name Agent IP Agent Security Domain Authentication Method Policy Expression Argument 1 Argument 2 Argument 3 Argument 4 Argument 5 Argument 6 Argument 7 Argument 8 Argument 9 Argument 10 Instance Name Client IP Server Node IP More Arguments Actor GUID Session ID Agent GUID

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: