The revolving door of maldocs continues, with OneNote documents the latest seen abused in-the-wild.
The collaborative file format has been leveraged in a limited number of campaigns to deliver malware, with ASyncRAT and xworm among the malware families seen distributed.
Uptake of the document format hasn’t been widespread just yet, but given the novelty and utility of the delivery method, it’s worth familiarising yourself with the tools and techniques needed to analyse such payloads.
A bit of background
While actors can’t embed VBA macros in OneNote files like they can with Word and Excel documents, there are a number of other advantages:
OneNote files are not affected by Protected View/ Mark-of-the-Web;
Allows embedding Malicious Excel/Word/PPT files that will be played without protected view;
Allows embedding HTA, LNK, EXE files and spoof extensions;
The document can be formatted in order to trick users into opening a malicious file or a link;
Can be automated using OneNote.Application and XML.
For a full overview of its potential, have a look at the full article assessing its viability for Red Team activities here.
Analysis Tips
Didier Stevens has shared this write-up of how he extracted an executable embedded in a OneNote file, along with a new Python script (still in beta) he created to help with the task.
If you’ve got more time to spare to watch a video, Josh Stroschein has shared this walkthrough of a OneNote file he picked apart:
Tools for Analysis
A few tools have been flagged by the community, which can help in analysing OneNote files:
As many of you would have already heard, the August breach of LastPass was revealed to have been much worse than originally thought with unencrypted customer data and encrypted password vaults now confirmed to have been nicked by the attackers.
It’s hard to see how this update – the third since their initial disclosure of the breach – wasn’t designed to obfuscate the impact and shift blame to customers, with its release coinciding perfectly with the beginning of the end-of-year holiday season.
I’ve held off on publishing anything on the topic as I was hoping LastPass would come clean on their shoddy handling of the disclosure, but despite a deluge of bad press on the matter, they’ve kept silent.
Hence, this post.
I’ll start with a quick summary of what’s happened so far, before highlighting the impact LastPass’ systemic inaction and evasiveness has had on their customers and business. I’ll close by addressing the ongoing viability of LastPass as both a product, and a vendor, and what this means for the future of password managers as a security measure.
TL;DR:
After discovering evidence of compromise in their developer environment in August 2022, LastPass investigated and reported they evicted the attackers after just four days – no customer data/password vaults were affected, and the hackers only got their hands on a bit of source code and some “technical information”. No worries.
Except that despite claims by CEO Karim Toubba that the network was “physically separated” and that they had since deployed additional “enhanced security controls” and monitoring, we’ve now learned that the attackers were somehow still able to pivot into their cloud-based storage and retrieve the very data LastPass was meant to protect – customer password vaults.
Their latest advisory found the attackers leveraged the information stolen from their original compromise of their development environment in order to obtain “credentials and keys [from another employee] which were used to access and decrypt some storage volumes within the cloud-based storage service.”
While unknown, it’s possible this lateral movement could have been achieved through something as simple as a hard-coded password in a script, pilfered from the development environment in the initial intrusion.
What went wrong?
When considering the events that brought us to this point, a number of failings are apparent in three distinct areas:
The product – specifically, its use of outdated and inconsistent encryption implementations and master password complexity requirements. Futhermore, LastPass’ assurances that the hackers would have trouble cracking stolen password vaults hinges entirely on customers adopting “best practices” for security;
The response – the security team appear to have fixated on securing their source code and Production environment. This diversion of resources ultimately meant they were unable to mitigate or identify the attacker’s lateral movement into their cloud environment and consequently – to secure their crown jewels;
The disclosure – getting lawyers to draft a damage-minimising advisory that shifts blame and understates the risk to users; releasing it three days before Christmas and without any meaningful outcome or means of recourse for customers.
Insufficient PBKDF2 iterations
The LastPass advisory claims their product uses a “stronger-than-typical implementation” of 100,100 cycles of the PBKDF2 algorithm to salt and hash master passwords, in order to increase their resistance to password cracking.
Not only is their implementation unremarkable when compared to other password manager offerings (e.g, the free BitWarden product uses 200,001 iterations) – it’s much less than the 310,000 iterations recommended by the OWASP standard.
Moreover, LastPass only implemented this in 2018, with accounts created prior to that still only configured with the previous 5,000 iterations, making it exponentially easier for their master passwords to be brute-forced.
Worst still – some users have reported their accounts were configured with as few as 500, and even as little as one iteration (yes, a single iteration – the bare minimum) applied to their master password.
Infosec veteran Wladimir Palant has shared this detailed explanation that illustrates the potential consequences of these legacy settings. See below for a key extract from his post:
Figure 1: The average password can barely be considered “protected” by previous iteration counts
Legacy Password Requirements
LastPass currently requires a 12 character master password – increased from 8, back in 2018.
This change was never enforced for existing accounts, with prior users still able to log in using eight character passwords and having never received a prompt or notification warning them of the change.
While four characters may not seem like much, it could potentially increase the time taken for a single RTX 3090 GPU to crack a complex, PBKDF2-protected password up from 10 years to 363 million years.
Figure 2: Password table for cracking a PBKDF2 hash function using an RTX 3090 GPU.
Considering the attackers will likely have more than one graphics card at their disposal, and that some users are bound to have inadvertently used passwords present in public wordlists – those four characters may just mean the difference between compromise and safety for many customers.
Unencrypted URLs & metadata
The attackers were able to exfiltrate a significant amount of sensitive customer metadata, namely:
Company names
End user names
Billing addresses
Telephone numbers
Email addresses
IP addresses which customers used to access LastPass
Website URLs from password vaults
All of these metadata fields were left unencrypted – by design – in LastPass.
Wladimir Palant cites three instances – in November 2015 (page 67), January 2017 and July 2018 – where LastPass were warned that they needed to encrypt URLs and other metadata fields in their product.
As we can see from this breach, LastPass elected to ignore those warnings.
For the hackers, the utility of this information – particularly given their theft of encrypted password vaults – is significant.
It would allow an attacker to:
Prioritise their cracking of vaults for users with company names, email domains, or URLs of interest, for example to:
Gain access to sensitive or valuable networks by abusing valid remote access credentials;
Siphon funds from customer internet banking accounts, crypto-currency wallets, etc.;
Access, search for, and exfiltrate sensitive content from email accounts, or simply hijack them to conduct highly-credible phishing campaigns;
Potentially re-use password reset links that are still valid and hijack accounts;
Perform highly targeted Phishing/Vishing of users based on their sites and associated metadata.
While encrypting URLs might typically be considered overkill, its value is significantly higher when it provides the means for an attacker to easily parse and abuse stolen password vaults.
The likelihood of any one of the above scenarios happening is high, and the impact potentially severe. This is absolutely something which should have been caught in the Threat Modelling phase of LastPass’ product design process.
The issues I’ve highlighted above are just the more well-known ones – this post highlights a litany of additional flaws throughout LastPass that every user should be aware of.
The attackers were able to rummage around LastPass’ developer environment for four days, stealing source code and “technical information” that they later used to pivot into the cloud storage environment and steal customer metadata and password vaults.
The full intrusion took place over the period of four months, and while LastPass claim to have increased monitoring and deployed additional security measures, it seems to have been focused in the wrong area.
Don’t follow the bouncing ball
LastPass CEO Karim Toubba was very intentional in emphasising that the Developer environment was segmented from Production, reassuring customers that only “portions” of source code were impacted; that the attackers had been evicted, and they had taken steps to prevent further attacks.
Given the attackers were observed going after and obtaining LastPass source code in their initial attack, the assumption was likely made that this was their primary objective. Given this, their security teams would have been directed to prioritise protecting it from further unauthorised access, and ensuring the actors never made it to the Production environment.
While seemingly logical, this highlights two points of failure in their response:
They followed the bouncing ball, focusing on protecting their source code while neglecting to consider the need for increased monitoring and hunting for anomalous access to their other crown jewel – customer metadata and password vaults;
They fixated on enforcing and monitoring the boundary between Development and Production environments, neglecting to consider the security of other environments such as their cloud storage.
While assumptions have to be made when deciding how to respond to an incident, defenders need to be mindful that they aren’t following an assumed linear path of intrusion. Attackers can have multiple primary and secondary objectives, and take any one of a multitude of paths to get there.
In this case, it would have also been valuable to review the stolen contents for authentication material/potential lateral movement paths that the attacker could leverage in their attempts to regain access or attack other environments. This would have potentially enabled LastPass to better direct their investigative and remediation efforts in the wake of the initial breach.
Having clearly defined “crown jewels” and operating environments is a core consideration when performing Threat Modelling, and would have been instrumental in ensuring monitoring and hunting resources were appropriately distributed in a planned – not reactive – manner, when seeking to contain and mitigate this long-running attack.
You can tell a lot about a person through the way they acknowledge – or don’t acknowledge – their mistakes, and the same goes for companies.
I won’t delve into this much, because I think LastPass’ handling of this breach speaks for itself.
The bottom line is that I’m unable to trust a company that tries to hide from its responsibility by citing false claims of implementing “stronger-than-typical” cryptography; puts the onus on customers to have followed their best practices guide, and fails to address systemic issues in its core product over a period of years.
LastPass’ viability as a Product
While the headline is that LastPass failed to evict their attackers and a substantial amount of data was stolen, the breach has highlighted fundamental flaws in their product’s design and how they have (or have not, in this case) maintained it.
Improvements to security standards (i.e. the iterations of the PBKDF2 algorithm and master password length requirements) weren’t applied retrospectively to existing accounts, meaning their assurances of how hard it’d be to brute force a master password count for very little. As it turns out, they were prompted multiple times by Wladamir Palant to do so, but appear to have falsely claimed to have done so, in order to get him to stop asking.
Furthermore, by stealing customers password vaults, the attacker can bruteforce the master password at their leisure with the added benefit of having bypassed any value MFA would have provided against a remote attack. Again, this is something that should have been considered as part of a Threat Modelling exercise when designing the product.
It’s clear the LastPass product design is deeply flawed, poorly maintained, and uncompetitive with other free and paid alternatives such as BitWarden and 1Password.
The end of Password Managers?
Password Managers allow the ordinary user to use complex and unique passwords for each site and service they use – that alone makes it an essential protection against credential stuffing, spraying, and brute force attacks.
This breach has simply made it clear that LastPass is in a class of their own, and in all the wrong ways.
Free offerings such as BitWarden implement a total of 200,001 PBKDF2 iterations between the client and server, with important metadata such as your originating IP and site URLs either not being logged, or encrypted within your vault.
1Password is a mature, paid alternative to LastPass that is unique in that in addition to using a master password, it requires an additional Secret Key when attempting to access your password vault. This key is stored locally on your device, meaning even if an attacker was able to dump a copy of your vault like they did with LastPass, they wouldn’t be able to brute-force it without also compromising your device to extract that Secret Key.
Please note I’ve provided these examples not to steer you in either direction, but to give you a starting point in picking an alternative, if you or your organisation are among those affected.
Password managers are a great solution that has real-world benefits to both individuals and businesses – LastPass appears to have simply dropped the ball in spectacular fashion in this case, while there are plenty of others that haven’t.
Cyber criminals will consistently seek out the path of least resistance when searching for victims to attack. Unfortunately for Australia, it has served as the proverbial lighting rod for the latest strikes that have resulted in data theft and extortion attacks against our second largest Telco, Optus; our largest private health insurer, Medibank, and more.
This is part of a larger trend, with one cyber security vendor reporting an 81% increase in attacks on Australian organisations in the 11 months to June 2022, and another finding there was a 56% increase in ransomware attacks targeting entities in Asia over the first three quarters of 2022.
Australian legislators are responding by calling for increased financial penalties and scrutiny for companies that suffer serious data breaches, which builds on a two-part Bill targeting critical infrastructure operators that passed into law earlier this year.
Prepare for a changing regulatory environment, greater oversight
Australia has already significantly bolstered critical infrastructure protections through passing the Security Legislative Amendment (Critical Infrastructure Protection) Bill 2022 (a.k.a. the SLACI Act), and is attempting to achieve a similar outcome for personal data with the Privacy Legislation Amendment (Enforcement and Other Measures) Bill 2022, which was introduced into Parliament on the 26th of October.
Significantly increase the potential penalty for “serious or repeated privacy breaches”;
Provide the Office of the Australian Information Commissioner (OAIC) with powers to:
Request information and conduct compliance assessments of the notifiable data breach regime;
Require entities to conduct external reviews of their internal processes and to notify affected individuals of specific privacy breaches;
Establish information sharing powers for the OAIC and Australian Communications and Media Authority (ACMA).
The government is also taking steps to empower enforcement agencies, announcing in the recent Federal Budget that the OAIC would receive an additional $5.5 million in funding over two years to help it “investigate and respond” to the Optus breach, and a further 48 staff in the next financial year to boost its overall workforce.
As mentioned, all this is in addition to the SLACI Act which applies to organisations operating in 13 critical infrastructure sectors. The Act establishes increased reporting obligations; mandates the adoption of a risk management program, and affords the government step-in powers in the case of a cyber incident impacting an organisation governed by the Act.
A full summary of what this means for affected organisations can be found here.
Recommendations
Organisations operating in a sector governed by the SLACI Act should familiarise themselves with what it means for them and take immediate steps to ensure compliance if you aren’t already, as it is already in force.
Obligations stemming from this Act may be further compounded by measures laid out in the Privacy Legislation Amendment Bill currently before Parliament if it is passed. You can monitor the progress of the Bill by clicking the “Track” button on the official Parliamentary Business page.
Regardless of the outcome, it’s worth noting the key factors that brought the Optus and Medibank breaches into the public spotlight were:
Their market presence, and subsequently the number of individuals impacted;
The criticality of the services provided – both Optus and Medibank are captured under the SLACI Act;
The sensitivity of the stolen data, and its potential to be abused for identity theft and fraud.
Organisations whose business model alligns with the above factors would benefit greatly from proactively evaluating existing data security measures; investing in Data Loss Prevention measures, and establishing Incident Response and Cyber Security Monitoring teams and processes.
***** End Executive Tearline *****
Privacy Matters – How did we get here?
A sudden burst of high-profile breaches this month has cast a spotlight squarely on Australian organisations and government agencies. Specifically, it has raised questions on their ability to both prevent and respond to breaches of their networks and sensitive customer information.
The theft of 9.8 million customer records from Australia’s second-largest Telco, Optus, has been followed swiftly by another data breach impacting Medibank – the largest health insurer in Australia.
Interestingly, in a seven day period in that same week, PII of some 500,000 subscribers to Australian wine retailer Vinomofo were stolen from a test system; online retailer MyDeal suffered a breach of 2.2 million customer records, and energy company EnergyAustralia reported unauthorised access to the accounts of 323 residential and business customers.
Unlike the breaches of Optus and Medibank, these quickly fell out of the news cycle. Why?
At first glance you might think the quantity of breached records for MyDeal or criticality of EnergyAustralia’s systems might warrant more scrutiny or outrage, but what is consistent in these three breaches is the type and sensitivity of data that was stolen.
In the cases of both Medibank and Optus, key identity documents such as drivers license or Medicare details were stolen. A Drivers license alone is sufficient to satisfy regulatory requirements for a bank’s Customer Identification Process, while paired with a Medicare card it will count for 75 of 100 points of ID required for a National Police Check.
The potential for identity theft – and at such a huge scale – clearly delineates the Optus and Medibank breaches from the more commonplace thefts of personal data or credit card information, and has forced the Australian government to take decisive action.
It’s against this backdrop that the Australian Government have introduced a Bill to Parliament which seeks to increase penalties for “serious or repeated privacy breaches” and provide the key privacy watchdog – the Office of the Australian Information Commissioner – more powers to tackle privacy breaches.
Medibank have struggled from the onset to identify and contain the scope of this breach, with each new discovery appearing to have been revealed by the attacker, and not the investigators themselves.
After initially stating they had intercepted the attack before customer data could be obtained, Medibank quickly backtracked after the attacker contacted them with evidence of customer policies and PII they had stolen, claiming to have exfiltrated 200GB of data in total. The attacker further threatened to find data of prominent customers and “people with very interesting diagnoses” and email it to them in order to further exert pressure on Medibank to negotiate a ransom payment.
The scale of this breach has since grown to further encompass customers of the main Medibank brand, and has to potential to impact a further 3.9 million individuals.
Figure 1: Timeline of Medibank’s disclosures relating to IR process (Source)
From what we know so far, three key failings can be observed:
The compromise was not only discovered too late, but mistakenly concluded that the breach was contained without impact to customer data. Investigators failed to uncover evidence of data exfiltration before the actor made contact demanding payment;
More broadly, there appears to be a lack of network visibility, accesses, and/or immature IR capability and practices, which have hampered their ability – at every step – to adequately gauge the scope of the breach;
Medibank’s lack of cyber insurance is expected to result in an estimated cost of $25 – $ 35 million to respond to the cyber incident. This represents as much as 23% of their unallocated capital; does not include “further potential customer and other remediation, regulatory or litigation related costs”, and may climb further, the longer the incident drags on and if systems need to be recovered.
It is imperative that organisations and security practitioners heed the lessons learned here, in order to ensure history doesn’t repeat itself.
Increased targeting of Australian entities in 2022
The recent spate of compromises of Australian companies comes on the tail of a period of increased targeting of entities operating not just in Australia, but the broader Asia region.
Cyber security vendor Imperva recently reported they observed an 81% increase in attacks on Australian organisations in 11 months to June 2022. Attacks they rated as “critical” rose 230% between August 2021 and May this year – nearly twice the global rate during the same period.
Figure 2: The volume of attacks targeting Australian entities increased sharply
A fellow industry player, Sonicwall, has highlighted a drastic shift in targeting away from the US and UK in preference of Europe and Asia-based targets over the first three quarters of 2022. Organisations in Asia saw a 38% increase in malware delivery, and a staggering 56% increase in ransomware attacks compared to 2021.
Where to from here?
Just this week Microsoft released a report looking at a ransomware actor it tracks as DEV-0832, noting that “the group is financially motivated and continues to focus on organizations where there are weaker security controls and a higher likelihood of compromise and ransom payout.”
This brings us back to my original point from the start of this piece – cyber criminals will consistently seek out the path of least resistance, and so it’s imperative that your organisation nails the basics to avoid being targeted.
Figure 3: Real-world cyber security in a nutshell
The vast majority of cyber incidents stem from one of three attack vectors:
Compromising vulnerable internet-facing assets – typically resulting from unpatched vulnerabilities;
Delivering malware via Phishing emails;
Stolen credentials – these can be purchased trivially on the Dark Web; and according to a “source close to the [Medibank] investigation”, were the root cause of the ongoing breach;
Recommendations: Protect & Detect
Implement Multi-Factor Authentication (MFA) across all user accounts
MFA is your best bet to preventing unauthorised access to internal resources and systems – even if a set of valid user credentials are compromised, an attacker won’t be able to log in without that second factor of authentication.
While highly effective against low-sophistication attacks such as password spraying and credential stuffing, no defence is perfect (demonstrated through the 0ktapus compromises, for example), which is where recommendation #2 comes in:
Enforce granular Conditional Access policies
In addition to requiring an additional authentication factor, major identity providers – such as Microsoft’s Azure Active Directory – provide the ability to configure strict requirements for devices that login attempts originate from.
The specific criteria you can apply depends on the technologies you have, but can include things like:
Requiring the device to be enrolled in your company MDM (e.g. Microsoft Intune);
Ensuring the remote asset is fully patched and has an up-to-date antivirus running;
Restricting the physical location and/or IP address space the authentication event can originate from;
Preventing authentication from devices not connected to the company VPN.
Implement/plan for adoption of FIDO Keys
While soft tokens such as SMS or App-based offerings are low-cost and relatively straightforward to implement, FIDO keys (e.g. the Yubikey) can be used as a physical token in the MFA authentication flow. This makes abusing stolen credentials virtually impossible for remote attackers, as they aren’t able to steal physical tokens in the same way they can soft tokens, in order to bypass MFA.
🔑How does a FIDO security key limit the hacks we’re seeing in the news now?🔑 Beyond fun to work with @Yubico & partner with @Twitter to answer that question + demo how social engineering is used to steal passwords & siphon out MFA codes to gain admin access with @evantobac. — Rachel Tobac (@RachelTobac) 5:19 PM ∙ Sep 28, 2022
While initially highly effective, attackers have adapted to bypass soft token-enabled MFA protections, with services such as the EvilProxy (a.k.a. Moloch) Phishing-as-a-Service platform being sold on Dark Web forums for as little as $400 per month, and able to programmatically bypass both Google and Microsoft’s SMS and Mobile App-enabled MFA.
The impact of this approach was seen at scale in the ScatterSwine/0ktapus compromises, with over 130 organisations compromised through a series of attacks that abused stolen user credentials and intercepted MFA codes to access their internal networks and data.
Figure 4: A sample of high-profile companies impacted by the 0ktapus campaign
Microsoft have shared detailed guidance on how to implement stringent MFA and Conditional Access Policies in order to protect against attempts to socially engineer MFA approval, and have recently released an update to their Authenticator app to introduce number matching and provide additional context to MFA requests.
Monitor for PUPs, in particular Remote Management Software
Potentially Unwanted Programs (PUPs) are a challenge for every organisation, though special attention should be paid to Remote Management Software such as AnyDesk, Teamviewer, and Atera.
While predominantly used for legitimate purposes, these tools have been abused by cyber crime and ransomware actors who install attacker-controlled copies of the software in order to gain and maintain access to victim networks.
This research from Synacktiv is an excellent resource for Defenders looking to better understand and detect these tools on your networks.
Monitor for insider threats & unusual user activity
Attackers can’t do much without compromising an identity with the right permissions and accesses – this makes monitoring for uncharacterstic user behaviour an essential measure that can help identify potential compromise. As a minimum, Defenders should look to identify and investigate anomalous login activity and attempts to access resources outside of their business area or remit.
Trusted insiders are one of the most difficult initial access vectors to identify, due to the legitimacy of the recruited insider and their pre-existing knowledge of the network. The Lockbit ransomware crew attempted in August last year to recruit insiders with the promise of multi-million dollar payouts, and the Lapsus$ threat group are known to have paid employees for credentials and MFA approval as part of their wide-ranging hacking spree that hit Microsoft, NVIDIA, Samsung, and more.
Implementing User Behavioural Analytics and Data Loss Prevention solutions can help identify potential Insider Threats, though a good low-cost starting point is to selectively deploy Canary Tokens in your most sensitive network locations and files.
Figure 5: Generate and deploy canary tokens for free
