Keeping Third Party Applications Secure in the Cloud

In recent years, organisations have become increasingly aware that running third-party applications in their cloud environment exposes their workloads to greater risk. This is especially the case when this third-party software exposes some API functions to the public web.

Today’s modern cloud native workloads are proving an all too tempting target for attackers whose techniques are constantly evolving. Alongside exploiting web APIs to unleash cryptomining campaigns, they’re also abusing free tier offerings of popular cloud CI/CD platforms to easily convert compute power into digital coins.

To understand how vulnerabilities in third party scripts enable cybercriminals to infiltrate and hack, it’s worth getting to grips with the attack practices bad actors employ to mask their activities and the steps they take to avoid being detected.

Anatomy of an attack Part 1: Initial access and defence evasion

Apache Struts 2 is a popular open source cross-platform web application framework used by many developers in their day-to-day work. Here at Aqua Security, we recently dissected how attackers went about exploiting an Apache Struts 2 vulnerability that allows remote code execution (RCE) under the privileges of the Apache web server.

Having initiated an HTTP GET request to check if a server is vulnerable, the hackers launched a second HTTP GET request containing an execution command line that downloads and runs a shell script into an organisation’s container.

With the initial access attack completed, the shell script’s first goal is to undermine security defences and prepare the ground for its next actions. Alongside disabling firewalls, allowing traffic, and deleting LD_PRELOAD, the script executes multiple kill commands to eliminate any competing malware or processes such as cryptominers and cloud agents.

Having completed all these tasks, the attackers next delete log files in a bid to cover their tracks and avoid detection after the fact.

Anatomy of an attack Part 2: Execution

Having cleared the way for the overall attack, the script now sets up variables and a ‘get’ function which is used to download and execute the main malware binary – a cryptominer. Packed by UPX to avoid detection via hashes, this binary has two functions.

Alongside performing cryptomining, it also actively looks to run more cryptominers on more container instances. It does this by gathering all available credential information held within the container itself and using a loop to connect to neighbouring systems, so it can download and execute the same malware script on these lateral systems. The analysis we undertook on this specific attack found the malware executed a massive scan in a bid to find open SSH (port 22) and Redis (port 6379) ports in the internal container network, sending over 24,000 packets to those two ports.

Anatomy of an attack Part 3: The payload

Now safely ensconced in the container, the malware next runs a different instance of the same binary with a different process name, connecting back to the attackers’ command-and-control (C&C) server to download and execute a ‘coinminer’ variant. To support and enhance cryptomining efforts, the attacker also attempted to load an MSR kernel module to boost the overall speed of the mining process.

Understanding the risks

Today’s threat actors are continually looking for ways to exploit known vulnerabilities in third-party software, so they can install cyptominer malware on unsuspecting organisations. Using someone else’s processing resources to conduct the mining process and generate profitable digital treasures is on the rise; last year incidents of cryptomining malware soared by 300%.

While this may sound innocuous, crypto currency mining software can result in significant performance issues in servers, databases and application development frameworks and even Denial of Service (DoS) scenarios. But that’s not all.

Having gained an initial foothold into an organisation’s environment, there’s little to prevent bad actors from pivoting their attack efforts to focus on other higher value assets.

Today’s attackers are constantly honing their tactics to hide their cryptomining activities. Alongside disabling firewalls, they’re also deactivating the non-maskable interrupt that signals attention for non-recoverable hardware errors and system resets. Plus, they’re downloading encoded and obfuscated shell scripts to prevent security tools from understanding their intent. Ultimately, the aim of the game is to evade detection for as long as possible and maximise the potential for a return.

Securing the environment

The relentless speed of the modern DevOps cycle means keeping track of all workloads and software running in the organisation’s cloud environment is a big task. Best practices to improve security include enforcing two-factor authentication for all users, setting branch protection restrictions, and restricting forked pull requests to run on the CI platform.

Alongside finding and fixing known CVEs and security flaws, constantly monitoring containers and troubleshooting suspicious behavioural patterns is now a must have. Utilising runtime analysis, with tools that feature in-built rule sets, on third-party applications like Apache Struts 2 will help flag up potential runtime attacks and exploits.