Thank you for your interest in our newsletters. You will receive an email shortly to confirm your subscription.
Darryl Meyer, Security Consultant
23 mins read
Still, like their traditional counterparts, these organizations require solutions for infrastructure, communication, collaboration, identity and access management, device management, and so on. However, they manage them using alternative solutions, such as:
They often also adopt a default cloud-first strategy, removing the need for cloud migration to digitize their infrastructure.
In attacks against organizations that use Windows workstations and Active Directory, the compromise of a Domain Administrator (DA) account would sufficiently enable the final phase of the cyber kill chain – performing actions on objectives. Where AD is not used, a change in tactics is required. Although DA accounts may not exist in these alternative infrastructures, compromising administrator accounts for MDM, cloud, or IdAM solutions can prove just as lucrative.
The consequences of such compromises include, but are in no way limited to:
This walkthrough of a simulated adversarial attack is designed to help Mac-centric companies with alternative approaches to network management and general operations. It is also for organizations planning to move away from Windows architecture, thus seeking guidance on the opportunities and risks of this new venture, as well as the shift in mindset it demands. Either reader will gain an understanding of the techniques used by potential adversaries, their persistence, and what they are capable of.
The scenario loosely replicates an F-Secure engagement with one such company, which, for the purposes of this article, we’ll refer to as TechOrg.
TechOrg is a fintech firm with over 200 employees, offices in multiple countries across the world, no Security Operations Centre (SOC), a cloud-first infrastructure, and MacBook workstations. Access to internally-hosted services, like a source code repository, DevOps, and backend support is facilitated over VPN. All other services, like email, chat, and collaboration, are provided by third parties like Google G Suite, Microsoft Office 365, Slack, and so on. Authentication to these services is performed through an IdAM and secured by hardware security keys.
F-Secure was tasked with simulating a cyber attack against TechOrg. The purpose of this simulation was to demonstrate attack paths leading to the compromise of sensitive company assets, and to provide appropriate recommendations for the flaws and weaknesses identified on said paths.
Persistent attackers have clear goals. In this case, F-Secure's goal was to gain access to users’ data and use it in further attacks to steal their funds and funds from TechOrg itself. Although TechOrg has online business banking accounts, the attack team focused instead on the movement of money through its systems: from one user to another, from the organization to users, and vice versa. As such, the team selected a route that would position it within TechOrg’s live systems to modify payments in transit.
The choice faced by the team was between positioning itself within the production environment on a server that had privileged network access, or embedding itself within the production applications themselves. Either option has advantages from an attacker’s perspective, however, the latter promised a privileged position with fewer triggers of suspicious activity – if the attack team could maintain a low-and-slow position. It would also enable them to withstand cloud infrastructure redeployments.
The engagement bypassed any open source intelligence-gathering stage of the kill chain, instead, assuming a position attempting perimeter breach. Although open source intelligence gathering may have provided unexpected insights and opened other avenues for attack, it would have required significant effort to be relevant and effective. Instead, members of the attack team worked closely with the client to simulate realistic threat actor techniques.
A breach initiated through the compromise of services exposed on internet-facing infrastructure – such as web applications and VPN servers – was quickly ruled out. This is because TechOrg exposed very little internet-facing infrastructure, and it had secured what was exposed well. Phishing was chosen instead, using methods typically seen in attacks against financial companies. This combined a malicious payload delivered via email with credential phishing, in which social engineering is used to convince employees to reveal private credentials.
Using employee credentials to attempt IdAM system access can be very lucrative depending on which are obtained. Compromising an administrator could allow for direct access to the target environment’s servers. However, administrators represent a relatively small attack surface, generally protected by heightened security controls. The privileges of other employees can instead be enough. Examples of this are a developer having excessive permissions within a sensitive infrastructure, or finance staff with unrestricted access to private financial information and applications.
Traditional phishing payloads, like a Microsoft Word document containing macros that run malicious executables, are less likely to work against an organization that use Apple devices. Although Word and Excel are available for MacOS, modern versions of the software run in a sandbox. There is a possibility that the phishing target is running a version of the software un-sandboxed – perhaps even vulnerable to the previously identified sandbox breakout affecting older versions1 – but there is little guarantee.
After assessing the options, the team arrived at a choice of two phishing payloads:
The first of these options is more generic from an attacking perspective, and leaves open many further avenues of attack. It is also possible, however, that employees may be more suspicious about installing an application. Furthermore, the application would be susceptible to any additional endpoint security controls.
The second option aims to gain access to all authorized session tokens stored in the browser for an employee. This would allow the team to connect to whichever internet-facing services it was authenticated to, in anticipation that some would contain sensitive user information. This option relies on the installation process for a configuration profile being more conceivable than the installation of an application and the relative obscurity of a browser add-on.
After consideration, option one was chosen: the signed and notarized executable application. The logic for this centred on its provision of remote code execution on a workstation, allowing the team to gather sensitive files from said workstation and pivot further into the environment. From this position, lateral movement – the next step of the kill chain – could proceed.
The default security mechanisms on macOS won’t stop custom malware like the type F-Secure leveraged against TechOrg. They are intended to prevent the execution of known malware, whilst enabling users to decide what gets executed on their MacBook. If the pretext is sufficiently convincing, that is not a problem to the attacker. The pretext chosen was that the user had to install an application to apply an MDM configuration update that could not be done automatically by the administrators. Added legitimacy was achieved by providing installation instructions in an online document linked from the email, and making sure the email and document matched the company’s brand style.
Persistence (maintaining foothold) on macOS is also possible without default security mechanisms raising any red flags. The chances of detection increase if a MacBook user has installed third-party software to monitor the known and commonly used persistence locations, like Launch Agents or Launch Daemons. Still, with a sufficiently convincing pretext, the user would not be suspicious of the application asking for permission to add a login Item or whatever the case may be.
With remote code execution and persistence achieved, the attack team began its intelligence-gathering exercise on the infected MacBook, conducting internal reconnaissance. With lateral movement complicated by TechOrg’s cloud infrastructure – and no directory service – it was necessary to use information directly available on the compromised workstation and on the internal network. Additionally, with the absence of exploitable open services on other workstations, or remote administration services with shared administrator accounts, other techniques were needed to achieve lateral movement.
It became necessary to exploit an internal system, preferably a dual-homed system so that they could pivot into another environment, or conduct a watering hole attack against other employees, until someone with higher privileges was compromised.
TechOrg developed its proprietary software using DevOps processes, practices, and programs. Through its reconnaissance, the attack team identified the source code repository for the production applications, as well as a build automation system. The latter, it transpires, was continually tasked to build the production applications.
Although it would be possible to push malicious code to the source code repository, the attack team quickly discovered that there were strong controls in place that would likely flag the malicious pull request. It instead concentrated on the build automation system, which was an enticing target for the following reasons:
A secrets management misconfiguration was identified in the build automation system, enabling the team to assume the permissions of an administrative account. This account could alter build pipeline configurations, thus enabling the poisoning of any of the builds completed by the system.
It was agreed that the vulnerability adequately demonstrated the feasibility of backdooring TechOrg’s production code deployments without introducing any malicious code. By poisoning the production application at build time, strong controls placed on the source code repository and cloud environment could be bypassed, whilst still having the malicious code reach the production environment. With that reach, a real attacker would be able to interact directly with the application database to view sensitive user data and adjust account information. It would also have been possible to alter data passing through the system to modify payer or payee information. The implications of this reach signalled the team’s success in achieving the main simulation objectives.
The following recommendations were provided to TechOrg to address the risks discussed above:
Phishing attacks threaten all organizations, regardless of operating system. Minimizing the likelihood of a successful phishing attack is just as possible universally.
Software development businesses should be able to detect security events across all endpoints, including workstations and servers. These events should be aggregated and sent to a security information and event management (SIEM) where rules can be created to identify security events worth investigating and for historical log retention. Once this has been established, their ability to detect realistic attacks should be assessed.
The predict, prevent, detect, and respond (PPDR) framework still applies to modern tech organizations, and should form the foundation of their strategy. Tried and tested prevention strategies still apply to them.
This includes taking measures to ensure the software those organizations create and deploy has been assessed for vulnerabilities. All systems along the path of application creation – from development workstations, to build automation systems and production deployment environments – should be assessed. A single weak link may be all that is required to compromise critical assets.
While prevention is important, its limitations ought to be acknowledged, with detection and response capabilities being introduced and monitored as well. Where alerts were typically focused on the environment, these should now be extended to alert of higher risk DevOps vulnerabilities.
In non-traditional environments like these, the target shifts from user workstations to code in CI/CD pipelines or the cloud server infrastructure. CI/CD pipelines and systems need to be secured and considered instrumental to an organization’s critical assets and thus critical themselves. Cloud infrastructure security is often an afterthought, to some extent secure by default, and the service provider’s responsibility. However, a compromise of either could have disastrous consequences. A compromise of the build environment can result in a production compromise, as in the case of TechOrg, which may lead to unrecoverable losses.
Simulated activity often does not conclude with radical shifts in mindset or bombshell moments. Instead, continuous testing and improvement across offensive, defensive, and collaborative activities offer gradual but visibly incremental improvement. For TechOrg, the F-Secure attack team highlighted shortcomings in its existing controls that could (if exploited) have had a major effect, and also provided the organization with realistic recommendations for remediation.
To find out more, please fill out our contact form and a member of the team will contact you.