Emulating a Ransomware Attack: A Realistic Engagement Story
Since 2006, we’ve consistently earned the attention of international and domestic media outlets and businesses, a testament to the value of our work. Not only are we known for emulating real-world threat actors and innovating new techniques, tactics, and procedures (TTPs) but also for testing our client’s incident detection and response capabilities. We thought we’d share one such story with you from an older engagement which still has takeaways for today’s threat landscape.
Anonymity and Quality
It’s important to note, we believe in protecting our clients’ identities and letting the quality of our work speak for itself. To that end, we’ve altered certain aspects of this story to ensure our client remains anonymous.
The Scenario
Our client, a well-known multinational organization, requested that we emulate a Ransomware Attack using advanced TTP’s. They asked that every aspect of the engagement be realistic, short of exfiltrating and encrypting important data. They had a mature security program and a fully capable SOC with modern solutions deployed. In fact, they maintained a better security posture than most businesses today. To keep things realistic, the CISO did not notify their team about this engagement and expected them to respond to our attacks as if they were real.
Passive Reconnaissance
As ransomware operators, we began performing reconnaissance using passive techniques. Passive reconnaissance does not initiate connections to any system owned or monitored by the target organization. Instead, it uses third party sources of information. Our sources include paid services like Shodan and Censys, as well as less common, paid services like IntelligenceX, District-4 and other aggregators of data released from third party data breaches. We also have access to other sources of information from OSINT services we provide.
Using these data sources along with various OSINT techniques to perform a search against our client’s domain, we were able to extract a wealth of data. This data included current records for employee names, email addresses, titles, phone numbers, passwords, company infrastructure details, and vulnerability information. We were also able to uncover personal data related to home addresses, home IP addresses, email addresses, social media accounts, certain household information, and in some cases financial records.
Since our objective was Ransomware Attack Emulation, we focused on data related to our client’s email addresses, names, and job titles. Based on who our client was and the services they provided, the pretext was clear – we became a large investment firm that we knew our client would be excited to work with.
Identifying the Attack Vector (Hook, Line, and Sinker)
Using the data acquired from the passive reconnaissance above, we identified a specific individual that would let us bypass the normal “contact us” forms and reach the larger sales team. This person, we’ll call John Doe, was a Senior Sales Associate that had been with the company for 3 years. We added a few fake employees to the CC field as a credibility booster and emailed John expressing serious interest in their solution. After a few emails, we were introduced to another sales contact who would be managing the relationship going forward.
The conversation continued with us discussing our requirements for the platform, all the while, our intention was to collect additional intelligence. Our emails contained various trackers (i.e. embedded images in email and Word documents) designed to identify the operating system(s) used by the team. This information would help us develop a custom (safe) malware payload to infect target workstations. Unfortunately for us, the emails were read directly using the Google Apps web interface which blocked our embedded tracking images and our initial attempts at operating system fingerprinting.
To get around this, we drafted a Request For Proposal (RFP) using Microsoft Word. Then, within that RFP, we embedded a Microsoft Excel spreadsheet. To view the spreadsheet, our victim would need to open the Word document using the desktop version of Microsoft Word, which in turn would establish a connection that would inadvertently disclose the operating system, browser type and version, and the true source-ip address of the victim’s computer.
This method worked, and we learned that one team member was using MacOS while other team members were using Microsoft Windows. With this in mind, we developed two custom payloads designed to covertly deploy RADON (our proprietary pseudo-malware) and prepared for the attack.
The Initial Breach
In the context of our pretext, we opted to use GoToMeeting in a unique, offensive capacity. Our approach involved setting up a clone of the actual GoToMeeting website on a domain under our control, specifically https://gotomeeting.us.com. Importantly, we also integrated operating system fingerprinting capabilities into the site to ensure users would be presented with the right software for their operating system.
Once this was done, we created our own GoToMeeting installers, one for Windows and the other for Mac OS X. Of course, the installer was not actually GoToMeeting, but instead a variant of RADON customized to accept and relay a real GoToMeeting ID. The installers were added to our doppelganger site and tested to ensure the right versions were provided to the right operating systems.
After we confirmed functionality, we sent a modified GoToMeeting invitation to John and his team. When the meeting time came, our targets executed the fake GoToMeeting launcher which infected their systems with RADON. Then, after successful infection, the users were redirected to a real meeting to avoid raising suspicion. The following screenshot was taken during the engagement to show what our site looked like.
The moment the meeting started, our Command and Control (C2) infrastructure began receiving connections from the infected systems. The first system we interacted with was John’s, since it was the first to connect. Reconnaissance against his system showed that he was using Slack for internal communications and had access to numerous channels and chats. Given this, we proceeded to extract John’s Slack access tokens as well as browser cookies, history, bookmarks, and his local MacOS Keychain (he was the Mac user). Unfortunately, his keychain was encrypted (as expected) and we did not know his password…yet.
Infiltrating the Incident Response Team (Sliding into Your DMs)
To entice John to provide us with his password, we deployed a Python script via RADON to his computer that, when executed, would emulate the OSX password prompt that appears during privileged actions. Unfortunately for us, the client’s endpoint detection solution caught our attempt to execute the tool and blocked it. Immediately after, someone from the IT Security Incident Response team contacted John requesting that he join a Zoom meeting so they could conduct a remote analysis of the system. We didn’t want to leave them hanging so we joined the Zoom meeting in tandem with John, making it seem like he had connected from two devices. No one seemed to notice.
Now we (the pesky ransomware attackers) had infiltrated our client’s incident response team. We were able to listen in on their conversations, read their Slack communications, and on several occasions -passively participate in calls when they requested live meetings. It was interesting to hear them speculate that we were a sophisticated state sponsored threat. We clearly were not. Our ability to infiltrate the IR team allowed us to stay several steps ahead of, and in some cases even redirect, their efforts.
Pivoting and Domain Compromise
During one of the Incident Response meetings, we learned that our client used the Duo Help Slack bot to support their self-service password reset portal. Using the bot, we were able to enroll a new device into Duo which in turn gave us access to valid MFA tokens. This allowed us to use their self-service portal, which only required the MFA token, to change John’s password after he had gone home for the day.
Upon resetting the password, we could access the Company Portal with the DUO 2FA device we previously enrolled. This allowed Netragard to gain access to the corporate VPN, internal network, and other internal tools like Jira. When logged in as the sales user to the Jira system, we had access to a significant amount of sensitive data such as IT Security projects as well as some critical automation systems which, ultimately, allowed us to fully compromise the infrastructure and deploy our fake ransomware note.
Key Takeaways
Preventing people like us from breaching businesses like yours is an impossible task. However, preventing damages in the event of a breach is entirely attainable. To effectively prevent damage, it’s imperative to understand the threats that correspond to the risks involved in accessing your data. This insight can be used to facilitate early, effective breach detection and response. A breach that causes no damages is largely unimportant and certainly doesn’t impact reputation. In fact, rapid and effective response can improve reputation.
Our regular testing revealed that the same attack methods no longer yield results for our client. Their cost-effective solutions involved configuration adjustments, policy updates, and targeted training. In summary, cybersecurity resilience lies not in a single silver bullet but in a holistic approach that combines prevention, detection, and rapid response. While we have since turned over our doppelganger domain used in this engagement to the real GoToMeeting company, below are some recommendations to improve the security of your own infrastructure.
- Be suspicious of “.us.com” and “.eu.com” domains. Anyone can buy the subdomain for them. Purchase them for your own company if you can.
- Ensure your Incident Response process isolates machines from the Internet during an investigation.
- Perform risk analysis on the implementation of self-help automation tools such as “Slack’s Duo Help Bot.”
- Review the password reset process and have alerting around password changes and/or device enrollments (i.e. only information required for reset was DUO 2FA).
- Review access controls on internal tools such as JIRA and be very restrictive of automation tools that have the ability to deploy to multiple computers and security tiers across the domain.
About Netragard
Founded in 2006, Netragard is a cybersecurity company that specializes in offensive security services such as penetration testing, vulnerability assessments, social engineering, and information security advisory services. We help organizations identify vulnerabilities so they can be resolved before they are exploited to impact the confidentiality, integrity and/or availability of their data. We provide three tiers of service with the top tier being Realistic Threat Penetration Testing. Our services are driven by a unique methodology called Real Time Dynamic Testing™ which is derived from over 15 years of zero-day vulnerability research and exploit development practices. Our objective is to “Protect You from People Like Us.” To learn more about our penetration testing services, please visit www.netragard.com.
