Failure to monitor
Once upon a time at a Wealth Management Firm in Dallas, a user opened an email payload, unknowingly allowing a Threat Actor remote access to the users’ system. The user was not a “privileged” account, however the firm had not updated the Active Directory functional level recently and since the administrator had recently logged in on users desktop to install an application, Threat Actor was able to immediately escalate privilege and move sideways through the entire domain!
It’s likely that Threat Actor had access for some time in planning their attack, and chose Friday night at 23:00 local time to run Ransomware, encrypting the firms file share, mail server and all on-premises backups.
Wealth Management Firm and its administrator believed they were well protected, since they had backups AND a DR site with hourly replication of all mission-critical VMs.
Monday morning rolled around and nobody had noticed or been alerted to the activities of Threat Actor, so when the office opened all of the systems were essentially gone. “No Problem” they thought; “we’ll just fail-over to the DR site – that’s why we planned so well,” they thought.
Unfortunately, replication had been running hourly all weekend, and most DR platforms only support a maximum of 20-30 replica states. Essentially, the entire DR site had been Ransomed by the time anyone noticed!
Lessons
- Make sure to implement 3-2-1 Backups with at least one location being a Cloud/Immutable Repository
- Consider “windowing” replication when your business is active and not running replicas at night or over the weekend, and keep as many replica restore points as your platform will support.
- Update Active Directory Domain Controllers to latest Windows and update the domain functional level try to mitigate the possibility of privilege-escalation.
- Implement an active monitoring system and endpoint protection and designate on-call personnel to monitor changes to the environment like Ransomware encryption.
- If you detect an attack, immediately stop replication and disconnect any remote sites, VPNs, MPLS, etc.
The device who stole Christmas
There once was a Major Oil Company that engaged in very proactive IT measures such as using MFA for all users and buying the best and most expensive firewalls from major well-known vendors and using best-of-breed Endpoint Protection.
One day, all hell broke loose. A Threat Actor had gained broad network access and began to disrupt delivery nationwide.
“How could this be?” thought Major Oil Company, “we invested in high-end security systems and passed all of our security audits with flying colors” said Major Oil Company.
Turns out many security audits cover Active Directory while ignoring device passwords on things like virtualization hosts and firewalls. Moreover, it is the responsibility of Major Oil Company through its administrators to disclose all devices, especially those which might permit network access, to the auditors for review.
As it turned out, a best-of-breed firewall somewhere on the network had been configured with a too-simple password and remote management was also enabled. Given time, Threat Actor was able to brute-force the firewall password, gain admin access and enable a VPN. Voilà, instant, broad-based access to the entire network.
Lessons
- Make device passwords at least 16 characters, random, complex and not used for everyday access
- Disable remote access for all network firewalls
- Discontinue the use of VPNs for user access as they join unsecure networks to your enterprise network.
- Only use VPNs with certificates or complex secrets to join secure, firewalled networks together for the transport of data.
- Make sure to implement 3-2-1 Backups with at least one location being a Cloud/Immutable Repository
The Plaintext Password ate my homework
A Large School District came to class one Monday Morning to find that all computer systems had been compromised. Furthermore, all of the backups had also been affected by Ransomware and Large School District only protected a very few systems with Cloud-based Immutable Repositories.
Large School District wondered what had happened and hired an Incident Response Team to help get to the bottom of it. Unfortunately, Threat Actor had been so thorough that there was very little left in the Data Center to go on, the systems had been Ransomware-encrypted right down to the actual server hardware, leaving essentially no un-encrypted data.
Threat Actor contacted Large School District within hours of the attack and provided their demands for payment – but Large School District referred the negotiation with Threat Actor to Incident Response Team. “Was paying the Ransom even legal?” “Was it ethical?” “Could Large School District afford it?”
Incident Response Team wisely insisted that Threat Actor prove they could decrypt the data by providing a small sample before engaging in negotiations. Turns out that Threat Actor could not decrypt their own handiwork and refused to provide a reason. Incident Response Team speculated that the routines used may have been run more than once or they may have crashed systems partway through encryption, leaving garbage instead of decryptable data.
Incident Response team, having no server data to work with, began to forensically examine administrators’ workstations, looking for evidence of the initial entry-point. On only the third workstation they were analyzing, not only did Incident Response Team find evidence of remote access software used by Threat Actor and pervasive access to other systems, but they also found a plain-text document on the desktop containing usernames and passwords for all levels of Large School District IT system from Infrastructure to Firewall to Storage. While this was an unauthorized document kept by one administrator, it was enough!
One thing the plain-text document revealed, was that password-hygiene practiced by Large School District was very inadequate, with passwords frequently based on dictionary words, short passwords, and the same exact (simple/short) password shared on most devices and as the local administrator/root password in the environment.
Lessons
- Never store or transmit credentials in plain text!
- Use a secure password manager and enforce its use.
- Do not use the same password pervasively in the environment.
- Make device passwords at least 16 characters, random, complex and not used for everyday access.
- Make sure to implement 3-2-1 Backups with at least one location being a Cloud/Immutable Repository
The Empire Attacks!
A Friendly Public Utility in a faraway land noticed that their systems were being systematically attacked by Threat Actor, apparently from inside the network! “How could this be?,” they thought. “We use the best firewalls and keep all our stuff completely up-to-date,” they thought.
The Friendly Public Utility knew that parts of their land were under attack from an Evil Empire, but had specifically left instructions to disable/destroy any systems before abandoning the office and heading for safer territory.
While trying to figure out how the Evil Empire was accessing the Network, Friendly Public Utility administrator took a look at one of the main switches at their location and noticed link-lights where there should have been none!
It turns out that the Evil Empire had some smart Threat Actors, however, and they were able to dig-up or access fiber links which remained connected in other locations.
Lessons
- Completely disable and disconnect network connections not in use
- Disable all unused network ports
- When under attack, disconnect network links to other locations to prevent propagation.
- If you suspect an attack Isolate your systems or power them off to limit damage
