Back
Assessing Microsoft’s Social Engineering Attack
Breaking Down Microsoft’s Response to the Lapsus$ Gang’s Social Engineering Compromise
Microsoft has done an excellent job in explaining the social engineering breach that originated against them from the Lapsus$ group.
In their recent blog post, they detail the Lapsus$ attack and how access was obtained, as well as provide some decent recommendations to enhance security. We’ve received questions from our clients on these recommendations and would like to provide the following additional context for each suggestion from Microsoft.
Microsoft provides the following recommendations to protect against threat actors.
Strengthen MFA Implementation
Specifically, they cite sim hacking and generic yes/no authentication pop-up messaging. So, what does that mean? A) Stop using SMS text messaging as a fall-back. It is not secure, and it’s easy to abuse via sim swapping (cell provider hacking) or account takeover and phone number reset (account hacking). SMS texting has not been considered a secure solution for more than five years now.
Another common abuse of function on MFA applications is just sending hundreds, if not thousands, of requests against a victim, so make sure you have enabled rate-limiting on the number of requests allowed to be sent. Additionally, avoid using MFA applications that only present a ‘yes’ or ‘no’ prompt with no supporting information. Proper MFA applications should present the geo-location that the authentication request originated from, the IP address it is coming from, and anything else it can along with the ‘yes’ or ‘no’ prompt.
Require Healthy and Trusted Endpoints
The pandemic exacerbated the problem of trusted endpoints with the migration to work-from-home. So how do we fix this? Two words: conditional access. Before a device is allowed to connect to your cloud or corporate resources, it should be checked for patch level, software settings for AV/EDR solutions, or, at the strongest level, if the device itself is even authorized to connect (Microsoft Intune enrollment and/or device certificates). If these conditions are not met, the device cannot connect. VPN and Cloud solutions support these settings, and enforcing these requirements to properly limit what devices are allowed to connect to your services limits the attack surface you must protect.
Leverage Modern Authentication Options for VPNs
Make sure your VPN solution supports MFA and uses modern encryption options. PPTP/L2TP protocols have been “dead” for decades. Stop using them. Make sure you are configured to use the latest encryption settings. Additionally, lots of vendors, like Pulse Secure and Fortinet, have been targeted with vulnerability disclosers the past two years, so make sure you are patching your VPN solution monthly at a minimum.
Strengthen and Monitor Your Cloud Security Posture
Cloud security monitoring is ever-changing and needs to be continually evaluated. Additionally, cloud compliance monitoring (divvycloud from Rapid7, Falcon Cloud Workload Protection from Crowdstrike, or new vendors like Orca.secure) is another excellent way to enhance security visibility, while getting continuous testing for vulnerabilities within your cloud environment, and in some cases automated remediation of non-compliant settings.
Improve Awareness of Social Engineering Attacks
Awareness training should be continuous, not just annual. There are plenty of services from insurance providers or add-ons that can be leveraged to train your workforce.
Establish Operational Security Processes in Response to DEV-0537 Intrusions
Take any useful TTPs and IOCs and apply there where possible. At the very least, work with your SOC providers to see what they can do for you.
Need Further Clarification? Let’s Talk.
We hope this helps provide some additional context about their recommendations, and we’d be happy to discuss with you and your organizations. Contact us today.
03.25.22