CISA Red Team Assessment Report; Singapore Banks Getting Rid of SMS One-Time Passwords

CISA is emulating the behavior of a nation-state attacker, to include attempting to exploit trust relationships with third parties. In this case, they not only compromised an unpatched Solaris web server, they also used phishing to obtain Windows credentials, elevated to an unsecured administrator account, obtained domain admin, and pivot into their partner networks, while remaining undetected in the first phase. Lessons learned here include having sufficient monitoring and alerting to detect malicious activity, not having sufficient centralized logging and having better cohesion/communication between the defender teams. Read the report to identify areas where you could have similar risks.

I haven't mentioned the Critical Security Controls in quite a while but the one line summary of this 29 page report is 'Focus on the Basic Hygiene levels of the Critical Security Controls first Ð without that foundation you can never stop even rudimentary attacks, let alone sophisticated ones.'

Red Team exercises have been used for several decades, starting with the Defense Department. Most red team exercises are successful. They typically exploit missing patches or weak credential management. One takeaway is that while bugs listed in the known exploit vulnerability catalog help focus attention, federal agencies often have weeks to months too patch. That's well within the attack cycle of cyber criminals. Organizations must shorten their patch cycle.

Zero days can be impactful. But given how many CVEs there are a year (are we over 40,000 yet?) N-Days are the real danger. Most companies do not realistically patch in any normal window of time. Why 'burn' a 0 Day when an N-Day is 'good enough?' The write-up is 'good enough' to understand how to run through a long-term engagement.

While any form of MFA is better than reusable passwords, the bank is moving from SMS based OTP to mobile app-based OTPs. While this does raise the bar, it's best to ensure that your solution is both phishing and authenticator fatigue resistant. Consider that smartphones are also able to support passkeys and other stronger authenticators. If you're electing to raise the authentication bar in stages, make sure you implement a solution that can get you to the desired end-state through configuration management as opposed to rip and replace.

I would imagine in a country like Singapore, this would be possible, mostly because larger populations and decentralized banking would make it difficult for a country like the US to support this. Maybe in 30 years. People in the U.S. still use checks, let that sink in.

Most of the enterprises that I do business with, already notify me if they see activity from a new device. This is true MFA, not merely 2FA.

Note that the data compromised was from May 1 to October 31, 2022, as well as January 2, 2023. While the breach doesn't seem to include decrypted message bodies, it does include not only the meta-data about the messages/calls but also often the cell tower location data. While the dataset doesn't include subscriber names, it's not difficult to map that using OSINT, allowing mapping of not only who is talking to who, but from where, which makes the data set attractive. AT&T notifications are being sent to account holders, which means that your corporate account representative is being notified rather than end users for enterprise accounts, leaving that job in your court. While this notification from AT&T doesn't include offers of identity protection, this is a good time to decide how you'd handle a corporate notification where end-user privacy data was exposed through use of a third-party employer provided service.

This trove of data contains the kind of association data which intelligence and law enforcement use but which in the US they are Constitutionally restricted in collecting. Apparently this breach could impact you even if you are not an AT&T customer, but have merely talked to one. If you are an AT&T customer you may be notified of the breach, though there is little you can do reduce your small risk of guilt by association. In today's environment this risk is already sufficiently high that consumers should be blocking access to their data in the three credit bureaus. Businesses should not open accounts in the name of a consumer without access to their data with a credit bureau.

Indications are CDK paid the ransom within two days of the attack and was able to commence service restoration immediately. Given that the estimated financial impact of the outage is estimated at least $600 million, payment makes financial sense in hindsight. Even so, it's still best not to pay. Not only for concerns about the reliance on the gang being paid, but also regulatory/OFAC consequences of making that payment. If you find yourself in that position, have a heart-to-heart with both your regulator and the FBI before electing to move forward.

The answer is not to pay the ransom, but that easy for me to say. The reality though, is that it's a bit more complicated. The CEO must balance loss of revenue, impact to customers, and company reputation in making the decision to pay or not. Sometimes even the insurance carrier gets to weigh in on the decision. Until payment of a ransom is made illegal, it will always be a business decision.

In addition to cancelled or rescheduled services, NHS is still calling for type O donations, which are universal, to bridge the gap in blood type matching operations. Time to reflect on how long your planned mitigations in such an outage are viable. What would happen if your service restoration time was extended longer than planned? Document your conclusions/mitigations, just in case.

Organizations should use the Synnovis breach as an opportunity to review their incident response planning and recovery procedures. Tabletop exercises using cybersecurity events as input, can help expose gaps in the return to normal business operations.

It's trivial to stand up a cloud service using reusable passwords, to include skipping implementing the provider's security best practices. Your cloud service approval process should include both verification of the security profile and adherence to company security standards, such as MFA and logging/monitoring and BC/DR. Ideally, have SME's who can help implement quickly and consistently to allow you to support mission needs while both knowing where your data is being processed and that it's being done securely. Consider reviewing existing services to verify security measures are still in place, to include reviewing the providers guidance for updated requirements or best practices.

It's only a matter of time before use of MFA becomes a standard (i.e., required) cybersecurity practice. Failure to have MFA will be a failure in the standard duty of care, and courts will hold organizations accountable for the data breach.

Many enterprises use URL security services which encapsulate URLs in email and restrict access to known malicious sites by wrapping links to route through their security services when accessed. The hackers are turning these services on themselves by compromising the URL protection service to allow their services or by using their own protected version of the phishing link, allowing a bypass. A multi-layered or defense-in-depth approach is still needed, where EDR or gateway services still need to disallow access to known malicious sites.

I didn't see a list of the compromised URL protection services but make sure you are not using them if the names do come out.