security incident response

Security Incident Case Study – A MSSP Run Amok

This is a case study of a security incident that occurred recently. The purpose of sharing this case study is to provide an example as to why proper security measures must be constantly validated both internally AND externally to include Managed Service Providers.

 

NIST Security Incident Response Lifecycle

 

Security Incident Overview

A valid user account (UserX) downloaded a malicious executable file on the Remote Desktop Protocol (RDP) server used by employees for remote desktop access in the middle of the afternoon. The updated security software on the server blocked the file from executing and placed it into Quarantine. Upon closer inspection, after being alerted via email the next day, it was learned that the UserX account also self-created a local administrator account on the RDP server – an uncommon administrative task.

The UserX account already had Domain Administrator-level privileges and belonged to a Manager Services provider (MSSP) that is currently under contract with the Client. However, the physical user works the third shift between 11p and 7a Local. The MSSP confirmed the physical user was not working during the time of the incident.

 

Actions Performed by the Client

  1. Exported logs from RDP server and found two network addresses in two separate European countries had been logging in as UserX for at least a month.
  2. Immediately shut down the RDP server, rebuilt the server from a safe image, and restored services. Placed the RDP server behind a VPN gateway so now employees must first connect via VPN to access the RDP server resulting in better security.
  3. Audited Active Directory users, groups, and permissions to ensure appropriate permissions.
  4. Immediately forced all users, including MSSP, to change network passwords.
  5. Audited firewall for open service ports and only allowed inbound traffic from the US and three countries that Client performs business.
  6. Audited all Windows servers looking for unauthorized local administrator accounts. None found.
  7. Exported security logs from all Windows servers to identify other security breaches. None found.

All activity undertaken by Client was timely and appropriate. Kudos to the IT staff.

 

Root Cause Analysis

The situation leading up to this security incident is two-fold: (1) allowing RDP traffic directly from the Internet is inherently insecure and should always be protected by encryption, and (2) MSSP circumvented security policies currently in place on Client’s network by creating domain administrator accounts with no password complexity, expiration or lockout parameters. It was also noted that MSSP engineers shared passwords and stored them cleartext in Microsoft Excel. This created the opportunity where an unauthorized person having identified a valid username through a Windows NULL session attack could brute force guess the password without being stopped. And because every user in this group is a Domain Administrator, a successful authentication opened the entire computer network to unauthorized access.

 

Remediation

Both security incident vulnerabilities were remediated, (1) RDP is now protected by a VPN gateway, and (2) all MSSP accounts have security policies enforced to require password changes, complexity, and lockout on failed login.

Additionally, an amendment to the seven year, multi-million contract with the MSSP has been drafted, signed and countersigned stating that all MSSP personnel must abide by the security policy of the client, and any further security incident breaches directly attributed to the MSSP will immediately terminate the contract.

 

Final Observations

Always have concrete terms in your contracts with your service providers. A chain is only as strong as it’s weakest link and sometimes we take for granted that a MSSP will always act in our best interests when they themselves may be the weak link.