MFA and Privilege Management Key to Detecting and Thwarting Latest State Sponsored Attacks; More Reasons to Quickly Patch Firewalls; Prioritize GitLab Update

Great write up. The attack was targeted, but remember that the techniques described are used by other actors as well, and tend to "trickle down" to less sophisticated attacks. Try to read the document considering which part of the attack you would have been able to detect, and how you may be able to fill in some blind spots.

Many lessons to be learned from this one, especially related to the initial attack vector exploiting vulnerabilities in low end firewalls/routers from Fortinet and others. A key takeaway: the attacks harvested credentials from those devices and then took advantage of admin privileges on those accounts to launch hard to detect living off the land attacks. Once again, use of 2FA on all privileged accounts would have thwarted these attacks or made them much easier to detect.

The core mitigations for this type of attack include being able to monitor for unusual activity, not just unexpected commands, but unusual login hours, activation of services or accounts outside of norms. Yeah, modeling normal is challenging. But you can watch for unexpected PowerShell scripts, login behavior, and enabling of proxy-type services which could enable an end-around your access controls. You can also lock down and instrument critical components like your domain controllers, making unexpected activity easy to spot.

This is the hallmark of a classic nation state intelligence operation – gain access, elevate privilege [credentials], burrow deep [living off the land], collect and exfiltrate data. By taking advantage of available IT tools, discovery is made all the more difficult. The primary objective would be intelligence collection, but given the network’s importance, denial of service would be a secondary objective. Every organization should use this discovery to review their patch management process, as well as to review access logs [privilege account]. If organizations are slow to patch, adversary have all the time they need to establish a foothold and elevate privileges.

This breach was caused by the failure to patch a firewall for almost two years after the patch came out. A 1.2M record breach cost the company millions, the fine adds another $.5M – and the cost of patching the firewalls was realistically only in the tens of thousands of dollars.

This agreement between the State of New York and Practicefirst should serve as a wake-up call for companies that routinely collect and store consumer data. Courts are determining what constitutes a standard of reasonableness, or lack thereof, when it comes to a cyber breach. There’s no time like the present for companies to build their cybersecurity program using a well-established security framework, such as the CIS critical security controls.

At core, Practicefirst failed to update their firewalls and conduct penetration tests to validate their security posture. Beyond the obvious statement that this would cost far less than the recovery, fines and legal fees, the question of why securing and validating their boundary and access control systems was not a priority. Whether you're targeted, like healthcare, or not, making sure that these devices and services are secure has to be foundational, to include making sure that all administrative access requires MFA. And while you're double-checking that you're good to go, make sure that accounts, particularly those with administrative rights are reviewed regularly.

An exploit is available for this vulnerability. Only some configurations are vulnerable, but do not delay deploying this patch.

No brainer, apply the fix, take the weekend off. GitLab is developing a regular cadence for updates you also want to be plugged into: make sure that you're subscribed to GitLab's Security Release notifications, either via RSS or email. You may want to ask your team to report back on how you stack up against GitLab's best practices in securing your instance guide. https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/

The law is pretty clear that victim notification is to be made 60-days from discovery. The company doesn’t get a ‘pass’ on the notification requirement simply because they ‘believe’ the attacker’s goal was to obtain funds. Further, Apria has no way of knowing whether personal information was ‘misused’ as a result of this cyber breach. Clearly the board should review the steps taken by the Apria executive leadership team in responding to the breach and hold them accountable.

Apria claims it has taken two years to fully investigate the breach and determine what, if any, data was accessed. Apria is just now offering affected patients a year of credit monitoring and restoration two years after their data was potentially compromised. While important to fully investigate a breach, taking two years to notify affected parties is just too long. Perform a risk assessment and determine what your customers tolerance would be then update your plans to include that goal, so everyone is on the same page.

One reason we use a lot of breach stories in Newsbites is that a CISO’s best ammunition is an incident that happens to a competitor *before* it happens to your company, as Mr. Corridon noted!

Two valuable tools here to avoid being caught unprepared. First, information about breaches affecting peer/competitors in your sector; second, exercises to test your response and recovery capabilities. These exercises also allow you to make sure you've properly designated responsibility and included all the necessary players. Consider tabletop exercises that include the executives and named parties. Now that your executives are onboard/trained, you need to make sure the staff is equally prepared. There is nothing like rebuilding a system from a "pile of backups" and brand-new hardware in isolation to flush out gaps in experience and planning, before actually needed.

A number of Incident Response Plan templates exist today from which an organization can tailor for their own unique needs. Defining roles and responsibilities, to include decision authority, is but one component of an effective plan. What’s equally important is to periodically exercise the incident response plan. You may find that adjustments to the plan are needed.

First, there is a big distinction between a CISO participating in covering up an incident and missing one of many regulatory requirements. Second, while a CISO’s job would be much simpler if there were unified regulations, most successful (and highly paid) CISOs don’t drive their security programs and architectures to meet regulations, they protect their business and customers and then meet regulatory reporting requirements. Third, the SEC has kind of been “Sarbanes-Oxley”-izing the cybersecurity reporting requirements for publicly traded companies, a good thing.

Pretty sure the Uber CISO was covering up the breach, to include paying off the attackers to keep quiet, not struggling with conflicting regulations on breach reporting. While it'd be nice to have consistent guidance, until that time, your CISO needs to develop a plan which works for the business. Intervals of 48 to 72 hours for reporting a confirmed attack are pretty common, and CISOs are going to have to determine who things are reported to. This can be worked in conversations with your local FBI, CISA and regulator (if appropriate). Lastly, the CISO needs to ensure that reporting is consistent between disclosure, messages to customers, regulators, and potential SEC filings.

The malware, written in Python, doesn't appear to include any discovery tools, so the attackers have to use other means to discover systems, IP addresses as well as MySQL credentials needed for the attack to succeed. Watching the introduction of unexpected Python scripts is a good first step here, in addition to making sure your OT systems are properly segmented. Also keep an eye out for recon activities, such as unexpected MySQL stored procedure use, or unusual network connections.

No real surprise here that malware exists to disrupt OT environments. We also know that the energy sector has been a target of attacks over the last decade. Organizations should have a process in place to periodically review attack vectors targeting their OT environment. Connecting IT infrastructure to the OT infrastructure is one such vector. Another is the unscrupulous insider. A third is supply chain. Develop mitigation strategies for each of these attack vectors.

This plugin provides a nice cookie consent process, but failed to properly sanitize input and output, making it vulnerable to XSS. Make sure that you're fully updated to 2.13.0 or higher. Note that 2.10.2 does fully fix the issue while 2.10.1 was an incomplete fix. If you're getting emails on plugin updates, this is trivial to check. The attack should be blocked by your WAF's existing XSS rules; even so, you want to update the plugin.

WordPress continues to be the dominant CMS in use on the internet. As previously reported in SANS NewsBites, poorly developed plugins are the weak link, often resulting in critical security vulnerabilities. The Beautiful Cookie Consent Banner vulnerability is the latest example. Given that a patch was available in January, there is no excuse for organizations not to have updated by now. Should organizations find themselves hauled into court for loss of customer information, the standard of reasonableness test will be easy to determine.